James Morris - SELinux and Security in the 2.6.26 Kernel
SELinux and Security in the 2.6.26 Kernel|
What's new and exciting with SELinux and security in the new 2.6.26 kernel? Expanding some of the items from the excellent Kernel Newbies 2.6.26 page:
- security= boot parameter
This patch by Ahmed Darwish allows a particular security module to be selected at kernel boot time, so that distributions can ship multiple security modules and allow the user to decide which one (if any) to enable. For example:
security=selinux selects SELinux, while
security=smack selects SMACK. (In Fedora, you don't need to do anything: SELinux is the default).
- New SELinux open permission
Until now, opening a file under SELinux invoked the same permission checks as the intended operation on the file, such as read, write, execute and append. There was no separate "open" check: opening a file for write, for example, was considered by SELinux policy as equivalent to actually writing to the file. Experience has shown that this approach is not ideal for handling cases such as IO redirection via the shell, because policy writers cannot usefully guess where users will send redirected output. This is a very common use-case for Linux, so a solution is most definitely necessary, while also preserving strong security. Can it be done? Yes!
Implemented by Eric Paris, the new open permission provides a way to address the issue by providing applications with liberal access to read/write/execute/append permissions but tightly locking down the ability to open a file. In the case of redirecting output via the shell:
bash# /sbin/do-stuff > /tmp/output
the shell forks and creates
/tmp/output, calls dup2(2) to replace stdin with the newly created file descriptor, then execs
do-stuff. With the old permissions,
do-stuff would have required an SELinux write permission on the new file, which it very likely would not have had. By providing
do-stuff with liberal file access permissions, but not the new open permission, its output may now be redirected to the file without needing to give it the ability to directly open the file. The invoking shell of course needs the open permission, which it effectively delegates to
do-stuff via the open file descriptor.
Updated security policy which utilizes this technique should be available soon in rawhide, and integrated into Fedora 10, providing significant usability improvements for sysadmins and power users.
- Permissive Types
Also implemented by Eric, permissive types (aka permissive domains) allows permissive mode to be selected on the fly on a per-domain basis. Permissive mode is where security policy is being checked and logged, but not actually enforced, and was previously only possible on a system-wide basis. By making this per-domain, applications which are experiencing SELinux policy issues may be flipped into permissive mode, allowing them to do what they need until a proper fix is available, without disabling policy enforcement for the rest of the system.
- Network Port SID Cache
Paul Moore implemented a cache to improve the performance of the SELinux networking code, so that network port labels are no longer looked up in the (typically large) kernel policy database on a per-packet basis, and is instead retrieved from an RCU-based cache. This addresses a long standing network performance issue which has been observed with very high loads on network servers.
There's quite a lot happening in security for 2.6.27, some of which has already been merged into Linus' tree. Due to the pervasive nature of some of the patches (including David Howells' credentials rework), I'm feeding all of the SELinux stuff via my security-testing tree. The "devel" branch is where bleeding edge changes are initially stabilized before being applied to the "next" branch, which is in turn fed into to linux-next.
Tags: fedora, foss, kernel, linux, mandatory access control, security, selinux
|Date:||July 15th, 2008 05:14 pm (UTC)|| |
Opting ouf of SELinux on Fedora
I thought SELinux could no longer be built as a kernel module and had to be compiled in or left out entirely. Does the mentioned patch change that?
If so, the boot param is a great thing for user choice, but it's only a start, since libselinux/libsepol and all userland code linked against them would presumably still linger in Fedora, confounding users' efforts to follow two of the oldest and wisest computer security mantras: Don't run untrusted code; Remove all unused code wherever possible. Not all users trust SELinux code, and not all users wish to use SELinux features compiled into userland packages.
For every Fedora package linked against libselinux/libsepol there should be a -noselinux build -- or under a more sane opt-in model, SELinux-linked packages should be labelled with -selinux and their non-linked counterparts should be labelled normally. This would allow users to uninstall (or simply not install from the outset) libselinux and libsepol without breaking anything.
Re: Opting ouf of SELinux on Fedora
passing the 'security=none' boot parameter will not load any security module (including not loading SELinux) as no registered LSM module has the name field = 'none'.
|Date:||July 19th, 2008 11:42 pm (UTC)|| |
I wonder how will users take advantage of permissive types. Is this going to be a new option in semanage/semodule?
Re: Permissive Types
I'm not sure how it'll be integrated -- probably best not to ask users if they want to disable security, but as an admin tool, it should be useful. I'm guessing it will be an semanage option.