On Fre, Nov 30, 2001 at 09:38:00 +0100, Christian Jaeger wrote: > LIDS really makes use of the capabilities stuff that is in the kernel > anyway.
Capability support is in since 2.2.11 i guess. http://pw1.netcom.com/~spoon/lcap/ > Well it complements it with file access control lists (and > maybe some other stuff, I don't have much experience with LIDS), but > not everything in LIDS is it's own invention. Of course not. But it's the first implementation that enforces policies and have extensive logging facilities. > I think really it should be the software (the deamons running as root) > itself which should make use of the capabilities, instead of leaving > this task to the administrator. Of course. Normal root doesn't have any capabilities in his login shell. Only the daemons have specified prviliges. This is fixed on a per exec*() basis which load the specific daemon from a fixed place (inode nr) from the media. > > Also it's probably generally not that a good (well thought out) idea > to transfer the security border from root_space <-> normal_user_space > to lids_protected_space <-> root_and_normal_user_space; there will be > security holes in LIDS too.. there are 3 stages, not 2. root is still living for the normal user. Of course there could be security holes, but check out the sources. This is a simple #ifdef CONFIG_LIDS ... if(!capable(CAP_SYS_RAWIO)) ... /* and the logging support */ ... #endif return -EPERM; LIDS itself is not a monstrous patch which real hardware-low-level changes. It operates (mainly) cleanly on the kernel-userland interface and the VFS. Capability support has been there a long time, but not mandatory.
