New Security Module For Kernel 2.5

CelestialWizard writes: "After the Linux Kernel 2.5 summit, a new security model is to be created for the next kernel. You can see the post from Cripsin Cowan on BUGTRAQ. " Interested folks should look at the mailing list; my guess is this is gonna be for the techies only.

Comments

Re:crazy curveballs

[IPFreely]

This discussion is not about whether the kernel has bugs or holes. It is about portable/configurable security models. A Model is not the same as an implementation.

A security model is about defining how users will be given permission to perform specified actions. The message gives an example of the POSIX model. Others are possible. You can choose an ACL based model, or a highly restricted class/access or simple user/group/world RWX like unix of old.

Installable security modules allows the user to select what TYPE of security they want to use. Whether any of the implementations of these has holes is up to the implementers. We would prefer that the implementation be well audited as well as well defined.

This has nothing to do with BSD being better audited or better tested. Each of the BSDs has its own model, but just the ONE.

This installable security model is a very good thing for Linux. It allows choice for using linux in areas that require widely different types of security methodology.

The actual post

[dudle]

One of the byproducts of the Linux 2.5 Kernel Summit http://lwn.net/2001/features/KernelSummit/ was the notion of an enhancement of the loadable kernel module interface to facilitate security-oriented kernel modules. The purpose is to ease the tension between folks (such as Immunix and SELinux) who want to add substantial security capabilities to the kernel, and other folks who want to minimize kernel bloat & have no use for such security extensions.

Modules that can be loaded, or not, are the obvious solution, but the current LKM does not export sufficient hooks to support many security mechanisms. Thus many current security enhancements end up existing as kernel patches, which marginalizes their utility by making distribution problematic. The proposed solution is to enhance the LKM with a variety of new kernel elements exported to the module interface, so as to support a reasonable variety of security enhancements.

We have started a new mailing list called linux-security-module. The charter is to design, implement, and maintain suitable enhancements to the LKM to support a reasonable set of security enhancement packages. The prototypical module to be produced would be to port the POSIX Privs code out of the kernel and make it a module. An essential part of this project will be that the resulting work is acceptable for the mainline Linux kernel.

The list is open to all. You can subscribe here http://mail.wirex.com/mailman/listinfo/linux-secur ity-module or by sending e-mail to linux-security-module-request@wirex.com with a subject of subscribe.

Crispin

free karma!!! woo hoo!

[Error27]

I can't believe someone hasn't posted this yet.

It's a fairly informative email that describes what the modules would do and what the reasons behind it are.

http://mail.wirex.com/pipermail/linux-security-mod ule/2001-April/000005.html

This should answer some questions people had and also explain how this is different from the "why don't audit everything instead" type posts.

Re:crazy curveballs

[bellings]

What the hell are you talking about? The type of security that the various "security-enhanced" linux are working for is completely orthogonal with the type of security OpenBSD or Bastille Linux is working for.

The goal of OpenBSD and Bastille Linux is to develop distributions where it is impossible (well, extremely difficult) for users to gain permissions they were not explicitely granted. I.E., you get root access if and only if you were explicitely granted root access.

The goal of the security-enhanced Linux work is to make the permissions more granular -- more levels of permission, and standard methods for defining and granting those permissions. I.E., your name server can connect to port 53 if and only if you grant your name server access to that port. The backup operator can read everyone's email if and only if he's explicitely given permission to read everyone's email.

This doesn't have jack squat to do with user-land security systems, or code auditing, or how easy the OS is to r00t. These pluggable linux security modules will probably never, ever be used by 95% of even the most hardcore h4x0rs reading slashdot. They'll certainly never be used in any sort of application where stock OpenBSD provides the security model the application needs. Why? Because OpenBSD and stock Linux have (nearly) the same security model, differing only in the amount of auditing. If the OpenBSD security model is good enough for your application, if follows that the Linux security model is good enough for your application. This is for people who need a different security model.