On Wed, 3 May 2000, Chris Evans wrote:
> On Tue, 2 May 2000 lamont@icopyright.com wrote:
>
> > Okay, I wrote up a functional alpha version of this patch, which is at:
>
> Whoa, no hanging around there :-)
=)
> > It reads an md5 password hash from /etc/capabilities.conf and then
> > accepts a command via /dev/initctl containing a value and a passphrase
> > and if the passphrase hashes to the the password hash it changes cap-bound
> > to the value. Obviously /etc/capabilities.conf needs to be immutable.
> > It adds the command /sbin/capset to read the pass phrase and send the
> > command packet to /dev/initctl.
> >
> > Comments, patches welcome.
>
> I haven't checked the patch (will do so when I get a moment). Some things
> worth considering - random things in a random order
>
> - At least, read the md5 hash _once_ on boot rather than once per password
> validation attempt
yup. that's what i do.
> - Option to set capability bounding set from /etc/capability.conf? (with
> warning upon insecure choice such as banning CAP_IMMUTABLE without banning
> CAP_MODULE, CAP_SYS_RAWIO, CAP_MKNOD)
well, that shouldn't be handled from init. another helper program should
probably take care of that kind of stuff as part of the bootsequence.
ideally you might want to hack /etc/rc.d/rc to check /etc/capability.conf
in between all of the SXXfoobar scripts to turn off capabilities as soon
as possible in the bootsequence.
> - To properly secure immutable files you need to prevent updating the raw
> block device. This is possible by banning CAP_MKNOD then _unlinking_ the
> sensitive block device files.
gotta be done after all the devices are fsck'd and mounted, also you need
to re-mknod the devices as part of the bootsequence, then drop CAP_MKNOD.
> - Securing a system in this way is a pain because of the potential of a
> reboot. Loads of files need to be made immutable to prevent subversion of
> the banned capabilities. I mean loads! (kernel, init, loads of config
> files) And you will always forget some.
yeah, that seems to be a problem. that's not really a problem with this
patch, but its a problem with trying to figure out how to correctly use
the bounding set. one thing that the LIDS patches do is that they inform
you of all the programs which run prior to the time when the kernel is
"sealed" so that you know those files need to be protected.
> - In fact a paranoid secured system using capability bounding sets should
> be configured to _not_ boot at all (not even look at the harddisk). The
> reboot cause will want to be carefully analysed
this might not go over well though for systems which need to be available.
definitely should be an option though.
> - I did a security audit of init (one overflow in parsing
> /etc/inittab). However that was a long time ago...
buffer overflow in inittab would indeed suck badly.
> Given the above problems, I'm not sure we can make this a general purpose
> secure mechanism. However, I _do_ believe the securing potential for this
> on an hand tuned installation by installation basis, is high.
yeah, i'd like to deploy this on webservers at colocs. probably also DNS
servers and such.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:11 EST