Slashdot Mirror
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.
Part of the functionality of modules is that you can change core kernel functionality on the fly, no reboot required.
:)
Whaddya think this is, Win95?
Want to learn about race cars? Read my Book
Look at how PAM works.
Your app is PAM aware. You want someone who is ftping in to be authenticated by RADIUS, you set the pam.d/ftpd file up to allow that. You want SMB also, you add that...and so on. Once your app is PAM aware, it does not care what happens on the back end - it says I have this userid and this password - is it valid? YES or NO.
now, on the kernel end, applications don't really need to be modified. There are C calls which deal with files (fopen/open namely). Unless you deal directly with the FS (you sicko!) your app/shell will eventually use these.
(I get a little fuzzy here.) Basically, the libc will tell the kernel "I have this uid accessing this inode - is it okay" and the kernel then decides. Instead of having pam_modules, it may have ACL modules, or a module that only allows access if they are logged in from a certain IP#, or only if the parent process belongs to a certain program.
Behind the scenes, the kernel file system security can be configured however, and you either get a file pointer or EACCES returned to the open/fopen call.
I think this sounds great and allows a lot more flexability (and complexity) in the rather minimal unix security model.
You don't seem to understand completely what is being discussed, which is fine becaues neither do I. However, I have some passing familiarity with products like SELinux, RSBACS, and LIDS.
FreeBSD and OpenBSD may audit their code to make sure that what they have written is secure but that is something completely different from writing code that does what I want it to. Almost all variants of unix are still stuck in a decade's old world view of security, which is ironic since that's what many unix users make fun of Windows for.
Things like implicitly giving uid 0 god like powers, or thinking ports under 1023 are somehow more special than those above.
Projects like SELinux provide Mandatory Access Controls. Granted, I haven't looked at OpenBSD in a while, but I've never heard of any project to provide MACs for OpenBSD. Which is too bad because proper MACs significantly lessen the need for in-depth code auditing. When programs can't misbehave it becomes less important to audit six hundred million lines of code. And what do you do when you don't have enough man power to audit everything that needs to be audited? Have you ever looked at how little code OpenBSD actually audits?
This isn't about patching a hole is a tire. Audits aren't even relevant.
Well, this can be minimized by doing two things:
Installing the initial modules on a fresh install from trusted sources. There are already definitions of "trusted sources" in the industry -- pick the one that suits you best.
ACLs and user compartmentalization. Right now, root==God. In a "trusted" system, this isn't so. Users, including root, are assigned certain rights and if compromised, only those rights are compromised. There is no one account that if breached, compromises the entire system.
Who can install kernsec modules would be very specific and tightly controlled.
--
Charles E. Hill
Learning HOW to think is more important than learning WHAT to think.
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.
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
I guess I'm used to thinking of modules as device drivers, since that's invariably what they're used for. So how do you turn a security feature into a module? How much does the module interface need to be expanded in order to implement something like that? Is there a way of extending the interface in such a way that it minimizes breakage to extant modules? What sorts of security features are we talking about here?
Ultimately, these issues are all going to get discussed in gory detail, but might as well start the discussion here...
Linux thrives precisely because this kind of experimentation takes place -- because this kind of experimentation is possible. And while the PHB's may believe that a product can be secure enough, any systems guy worth his salt will tell you that no system is ever secure enough. Striving to make code more secure is never a bad thing. I would be much more concerned if the kernel developers came forward and said "We don't need to worry about security anymore -- our system is secure enough."
I would like to see more effort put in to development of interfaces to existing security features, though. There's not be a lot of movement to incorporate linux-privs into anything (The LIDS guys are the only ones I know of who are doing anything with it.) All server code should be using Linux privs at this point.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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
Looking for a great online backup: Green Backup
I can't believe someone hasn't posted this yet.
d ule/2001-April/000005.html
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-mo
This should answer some questions people had and also explain how this is different from the "why don't audit everything instead" type posts.
(Linus wrote:)
struct security_checks_struct {
...
... selinux had about 140 points they wanted to hook into ..
... others probably have a few more.
...
int (*execve)(struct task_struct *tsk,struct binprm *new);
int (*file_open)(struct file *);
int (*raise_capability)(...
};
Linus, first of all, for this kind of stuff, they invented C++: easy encapsulation of data and methods on that data in simple objects, no functionpointers in structs anymore, and last but not least: polymorphism!
Second, since the mailinglist is about design aspects, why is code popping up? functionality is designed without looking at CODE. It's designed by defining WHAT functionality should be implemented. THEN you dive into a technical designphase and perhaps you come up with pseudocode. Not in THIS phase.
This new security model can be a big part of the kernel, perhaps a lot has to be changed to adapt the security model in every part of the kernel (like it's done in WIn2k f.e.) to have true ACL driven security inside the OS. You can't design that with codesnippets.
--
Never underestimate the relief of true separation of Religion and State.
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.
Slashdot is jumping the shark. I'm just driving the boat.
Now, thats just FUD....
This is not a push to develop a new security model, rather than a push to develop a way for security models to be integrated with Linux. The problem that exists is that everyone wants to roll their own in security... In Linus's own words:
Everybody has their _own_ particular flavour that they want to push, and don't realize that I cannot accept that as a maintainer.
This security module is an effort to make it so that Linux can have an easy way to implement security without actually having to choose a particular security implementation to stick in the kernel. As has been the rule in Linux, this is not an operating system that tries to be all things to all people, rather it tries to give people the ability to choose everything they need and nothing that they don't.
Do you have Linux and a DotPal? Click here now!
The idea of adding kernel hooks so that a variety of security oriented modules can be loaded at boot time will alow for maximum flexibility and control by admins.
However, the short term consequences may very well be a plethora of security modules releases which could lead to confusion. Fortunately, the OSS community is good at sorting the good from the bad. It will not take long for the best modules to become more standard and make it into the distros.