Re: Bug#336452: realtime-lsm-source does not build against the linux-image-2.6.14-1-k7
On Mon, 31 Oct 2005 11:06:16 +0900, Horms <horms@debian.org> said:
> This is a problem that was recently discussed on debian-kernel
> without resolution. My understanding is that there are some security
> implications of making SECURITY_CAPABILITIES modular.
It is my understanding that SELinux does require
SECURITY_CAPABILITIES in order to function. Not having those
available before the root file system is loaded would make the early
boot process unprotected and vulnerable, an may cause havoc with the
startup (I do not know, since I have never tried an SELinux kernel
without SECURITY_CAPABILITIES compiled in).
Gory details behind my understanding follow.
manoj
The original SELinux kernel patch added the SELinux
nondiscretionary access controls as additional restrictions to the
existing Linux access control logic. This left the existing Linux
logic intact and unchanged, including the discretionary access
control logic and the capabilities logic. LSM moves most of the
capabilities logic into an optional capabilities security module and
provides a dummy security module that implements traditional
superuser logic. Hence, the LSM-based SELinux security module
provides support for stacking with either the capabilities module or
the dummy module. Since some existing applications (e.g. named,
sendmail) expect capabilities to be present in Linux, it is
recommended that the SELinux module always be stacked with the
capabilities module.
The selinux_init function initializes the secondary security
module to the dummy security module, which is always resident in the
kernel, prior to registering the SELinux security module. This allows
the SELinux hook functions to safely call the secondary hook
functions. The selinux_register_security hook function sets the
secondary security module to a different module, such as the
capabilities module. The selinux_unregister_security hook function
restores the secondary security module to the dummy security module.
The dummy and capabilities security modules only implement a
very small subset of the hook functions. Hence, at present, the
SELinux security module only calls the secondary security module for
this small set of hooks, along with a few other hooks that were added
upon request for other security module writers. Since some of the
dummy and capability hook functions are implemented in terms of the
capable function, stacking the capable hook is sufficient to cover
several hooks without needing to explicitly call the secondary module
from the individual hook. However, in most cases, there would be no
harm other than performance in always calling the secondary security
module.
There are a few exceptions where calling the secondary module
would pose a problem for SELinux. The capability inode_removexattr
and inode_setxattr functions require CAP_SYS_ADMIN for all attributes
in the security namespace, whereas SELinux applies its own
finer-grained checking to the security.selinux attribute, so SELinux
must completely override the secondary module for these hooks. The
capability vm_enough_memory function would perform duplicate vm
accounting if SELinux called it, so SELinux must override it as
well. The capability netlink_send function sets the effective
capability bitmap in the control buffer for the netlink message from
the current process' credentials, whereas SELinux overrides this
function with one that also applies SELinux permission checking.
--
We just joined the civil hair patrol!
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: