SELinux Moving Into The Mainstream

PaxTech writes "Security Enhanced Linux is moving into the mainstream rapidly, bringing its implementation of mandatory access control to a wider audience. The agenda for the 2006 SELinux Symposium has just been announced, distributions such as Fedora are including SELinux in the default build, and ports are underway to bring SELinux functionality to BSD and Darwin. Security minded systems administrators should be learning about this technology as it provides another strong layer of security for Linux servers."

Comments

Next priority should be targeted policies for apps

[NZheretic]

Browsers and internet accessing applications really need a series of targeted policies that can limit what third party extention, plugins and applet/scripting systems have access to.

Almost all plugins should only need read access to its install directory/libraries, to a dedicated subdirectory for plugin for each application, and maybe ( at the users agreement ) common incoming and outgoing directory.

You mean like how DARPA funded the internet?

[NZheretic]

A Brief History of the Internet.

Also Larry Wall, author of Perl, was originally funded by the U.S. National Security Administration (NSA) as part of the "Blacker" project ; AND
DARPA grants largely funded the development of UNIX 4.1 BSD (Berkeley Software Distribution) as well as the later development of the TCP/IP networking protocols.

To quote Russell Coker

[NZheretic]

Russell Coker posted one of the most concise rationals to the SELinux Mailing List:

GR Security includes PaX for protection against stack smashing and other similar attacks. But it also has an ACL system of it's own and limited chroot's (IE process in chroot can't touch the outside environment or other chroot's).

SE Linux is an implementation of the domain-type security model. The domain a process is in determines that access it is given. Domains can change automatically on execution of certain processes (eg getty, login, and ping) or when executing a process a SE Linux aware program can specify the security context of the child process (within a certain range), login, sshd, and cron do this.

The grsec ACL system and RSBAC don't support modifying applications to specify the security context, so they don't support giving different access to different non-root users.

I think that Grsec has better support for some aspects of IP networking control, such as controlling which IP address a process can bind to (currently SE Linux only supports controlling bind access by port).

RSBAC has lots of options for a huge number of things as they take the kitchen sink approach. You have to answer about 40 questions at kernel configuration time, and it's not clear which combinations of options are viable.

Also visit the SELinux Frequently Asked Questions.