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
- 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)
- 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.
- 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.
- 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
- I did a security audit of init (one overflow in parsing
/etc/inittab). However that was a long time ago...
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.
Cheers
Chris
-
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