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.
The article here on /. has a typo in it. Crispin is actually at crispin@wirex.com, not wizex.com.
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
One thing is that Security means different things to different people. For example the NSA probably does not care much about hackers trying to break into a box. In order to hack into their box you have to get into the building past the guard with the gun and a lot of other types of security. On the other hand they are very worried that someone might take a classified document and make it not classified, or differently classified.
To you and me that does not matter at all. The guy who runs a web hosting firm has a differet set of issues and so on.
Erlang Developer and podcaster
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.
...we really had to work for our Karma points. There wasn't any of this "whoring" crap going on.
Damn you little bastards!!
We also had to walk to school. Five miles uphill in the snow. Both ways even.
You youngsters nowadays don't know how good you've got it!
Co-founder and designer at Music Nearby: http://musicnearby.com
The same way CA_Unicenter implements security as a loadable module in (at least) Solaris. It inserts a few modules that intercept and reruote filesystem access calls, and run them through their security module to see if user X has command Y in their allowed profile, and if so, runs it.
This space for rent. Call 1-800-STEAK4U
Because if it's a permanent code entry, then it has to be changed in the kernel to implement new algorithms and such.
If it's a module, then the API is exported from the kernel in a number of structures, and you can implement whatever type of security thing you want. A few ideas I've seen scroll by:
In fact, there won't have to be anything in the kernel that you will need to explicitly configure. It will be some additional information in the loadable kernel module model that new modules can take advantage of to implement security functions.
This space for rent. Call 1-800-STEAK4U
I will be very intersted in seeing how they solve the problem of validating security modules prior to loading them. Clearly this solution will make the kernel more flexible, but it will also add a layer of complexity in the security/trust relationship as now the system will have to protect against rogue security modules.
Equally obvious is that if someone can put a rogue security module on the system they can probably put a rogue kernel on the system, so this is likely not a real issue. However, it is something that should be addressed to make sure tha the system is as tightly integrated and unabusable as possible.
A firewall won't hack it. It is trivial for an application to find a way to connect out thru your firewall. Or do you not allow outbound DNS and HTTP? That's what I thought.
When my web browser connect to port 80 somewhere, I don't really care. When my new email program or game tries to connect to some third world server with no DNS info, I care. The only place that you have any hope of controlling this is in the kernel.
I would love to have this kind of flexibility. Netscape: port 80 only. Mail: 25 and 110. New binary-only game I'm trying out: nothing
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.
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.
If you read the mailing list post, you will see that what they want to do is add extra hooks in the loadable modules code so more security features would be able to be added as a module. This is great news for people who like to tinker. For instance, say I want to try out a new encrypted filesystem. On modern systems that means patching the kernel, compiling, fixing all the little things I invariably screw up because I am unfamiliar with compiling kernels (I do it rarely) and I skimmed the docs instead of reading thoroughly. With the new hooks (and already running a kernel with the changes, ie not now but a year from now) all I would have to do is compile the module, and tell modules.conf it was there. A reboot later and some configuration and in theory I would be up and running. MUCH easier.
It's both. It is a new security model for the linux kernel. This model involves adding hooks to allow more security features to be implemented as loadable kernel modules
The concepts are totally unrelated. Kernel developers try to make the kernel as secure as possible in the OpenBSD sense, which mostly means "If the spec says an operation isn't allowed, a user can't trick the system into allowing it". ie, "no exploits".
Security modules are about defining new types of policys. You can go a long way on POSIX file permissions, but sometimes you want the extra level of flexiblity that systems like SELinux and LIDS allow. Perhaps they should be called "Security Policy modules" or just "Policy modules", instead.
Check out the selinux and LIDS web pages for more information on what these patches actually provide.
And how many of that minority read slashdot?
-bugg
rwxs wasn't designed for security. The only arguments against ACLs that I've ever encountered are the following:
1) They're too complex.
Er, no. An ACL can be as specific or as simple as you want - rwx permissions are much more complex than a single line ACL. But when you want to be able to set some fine grained permissions, they have the ability to do that. rwxs doesn't.
2) There's no practical use for them.
Oh please. I have some word processor templates on a Linux server for a client. They document templates which contain business sensitive information. This isn't an unusual case:
* The owner should be my own account
* The software group needs read, write, and SetGID permissions
* The staff group needs read permissions
* All other accounts should not have access to these files, as they contain business sensitive information.
I could get around this in a number of ways, but they're all rather hackish.
3) NT uses them and NT sucks.
Grow up. So does Trusted Solaris, TRIX and Trusted BSD. So does Squid and (IIRC) Bind. Regardless of that though, there's no reason to discount a good idea because a company you dislike uses it. In fact, its pretty childish. Its nice to know this usually comes from trolls rather than anyone who works on major Linux based projects I discussed this with at conferences and on mailing lists.
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...
They don't want to do this because it adds bloat to a codebase that is quickly becoming unwieldy.
Sigs are awesome huh?
Your OS is only as secure as the tools you use. You could make Linux Really Really secure by running no servers on it. You could make BSD really really insecure by running insecure servers on it. How many BSD servers out there are running vulnerable NTP servers, for instance?
I'm not slamming the BSD practise of auditing their code, mind you. I did source code auditing as part of Data General's DG/UX B2 certification and we caught a lot of problems that way, but security doesn't end there. Claiming any one thing is the Be-All and End-All is just plain wrong. I wouldn't hire a system administrator whose sole security plan was "Install BSD." Nor would I trust auditors to catch every single hole, and it only takes one to compromise a network.
I'm trying to teach myself to set people on fire with my mind... Is it hot in 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
Read pivot_root(8). Assuming you've already created the encrypted filesystem, this is easy. Not that I've tried this or anything, but the man page makes me think it will work.
--
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.
Say I run an IRC client and there's a bug in it that allows people access to my files. With a better security model I could not allow the IRC app access to my files and the bug would not cause damage.
Another approach would be to audit all applications you run like OpenBSD does but I guess that limits your choice of applications and you end up with very old versions.
Monkey sense
Monkey sense
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!
Looks to me like the new model is a module of some sort. So the answer is: both.
I do not have a signature
ZoneAlarm sucks. It doesn't work, it hangs regularly, it trashes performance, it's nagware and it gives wierd error messages at random intervals.
I find about 1 in 3 apps crash with it. ICQ, Counter-Strike for example... Oh, it gets very upset if NS6 tries to use SSL over it.
And now for the bit of the last message which got cut off: you want a mini firewall. Linux is really good for that, offers far more than ZoneAlarm even if you only stick in some really basic rules.
BTW, has anyone else had proplems with preview cutting text to bits?
Erm, no. Heard of groups? You just need to read up on how to do it, it's not that difficult.
You can't do it at all on NT.
Wall, my sincerest congratulations to you ... they fell for it like flies for ...
--
Matthijs
I'm sad to see a new security module implemented. Why? Because it discredits Linux.
It discredits Linux to admit that the existing security modules aren't good enough. It discredits Linux to admit that security modules themselves are even necessary in the first place.
We must do everything in our power to ensure that Linux thrives. That means playing the marketing game. If it's bad for marketing, then it's bad for the whole project.
Insecurity is simply something that cannot be admitted up front. It must be cloaked in secrecy. If you reveal the cards in your hand, then your enemies will take the pot. It's that simple.
Perhaps it's time to release a completely closed-source version of Linux. One that doesn't let hackers find holes like these. One that'll protect our vital national secrets from the eyes of those who would steal them.
Because if we let them take our secrets, then we're letting them take our lives.
It's then a short trip in a handbasket to the abyss of anarchy and hell as we know it.
Crime breeds more crime. Criminal hacking contributes to murder and mayhem. We must take a stand, here.
Another approach would be to audit all applications you run like OpenBSD does but I guess that limits your choice of applications and you end up with very old versions.
./configure ; make ; make install and thats what I've seen of many adminstrators. Little is done to maintain groups, usage of programs like sudo, etc., to restrict issues regarding security.
Nonsense and here is why. With a secure OS installed you're less likely to worry about issues until you begin to install third party sw, this is one of the biggest problem with security, and often there are limits to even most third party security issues.
Administrating a machine isn't just kill -HUP'ing a daemon, or
With OS's like Free, Open, Net, again many security risks are minimized, and sorry to say but I truly feel tihs can be attributed to the fact that people take their time, and try to get it as right as possible before a release IS released, as opposed to a kernel every other week.
Don't be fooled into thinking that you won't be able to run XXX program or XXX version will be obsolete, a good admin can find a fix for most issues, either by finding a suitable program which will work, tweaking code, and ensuring the program is installed in a secure fashion, even if it means chroot'ing every 3rd party binary.
360 degrees of Karma
Add VMS to that list as well. The first multi-user system I got to program on was a VMS system. It has ACLs (or some form of like) and they aren't hard to learn at all. Unix premissions where totally alien after ACLs. I look forward to using them again.
--
M0571y H@rml355.
It would be nice if there was permission for internet or network access. Anyone who has use zonealarm under windows knows how needed this is. In this day of trojans no application should be connecting to the internet on my computer unless I know specifically what it's doing. That would help linux really become a desktop alternative.
But Yogi, the RIAA won't like that.
I'm not a linux guru and I've never compiled my own kernel so don't get worked up if I say something wrong. I assume what your saying why not just put compile options into the kernel. If you did that you would have to recompile the whole kernel everytime you changed security or tested something new. This way you can just compile your own personal security modules. Lots quicker and more easily configurable.
But Yogi, the RIAA won't like that.
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.