OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: symlink complaints in /etc/security

From: Luke Mewburn (lukemNetBSD.org)
Date: Sun Dec 07 2003 - 21:15:14 CST


On Sun, Dec 07, 2003 at 09:16:28PM -0500, Perry E. Metzger wrote:
  | > since it doesn't involve adding more special cases to mtree,
  |
  | Well, it does require that we rig mtree to handle this, or somehow
  | build a script that does it for mtree....
  |
  | So how do we do it?

As I mentioned, using awk on the output of "mtree -C -K all" may be
sufficient, although it starts to get slightly messy.

Alternatively, we could implement mtree -M (? - merge) to allow
entries to be replaced with ones of a different type.
In /etc/security we'd then do something like:
        cat $special_files | mtree -C -K all -M > ${SECUREDIR}/specials
and use ${SECUREDIR}/specials appropriately.

Currently spec.c::replacenode() in mtree forbids this (and that
is a sane default to retain); -M could relax that check.
The special case we need to consider is if "type==dir && child!=NULL".
For example, as special has
        ./etc/mail type=dir mode=0755
        ./etc/mail/aliases type=file mode=0644
        ./etc/mail/helpfile type=file mode=0444
if you replace /etc/mail with a symlink to /var/chroot/mail and add
the following to special.local
        ./etc/mail type=link link=/var/chroot/mail
        ./var type=dir mode=0755
        ./var/chroot type=dir mode=0755
        ./var/chroot/mail type=dir mode=0755
        ./var/chroot/mail/etc type=dir mode=0755
        ./var/chroot/mail/aliases type=file mode=0644
        ./var/chroot/mail/helpfile type=file mode=0644
the you don't want ./etc/mail/{aliases,helpfile} in the final
specfile.

Here's a proof of concept diff to mtree. Care to try it out on your
system with special.local whacked appropriately (and _without_ mtree -L)?

Cheers,
Luke.