An introduction to SELinux

It has taken nearly four years for Security Enhanced Linux (SELinux) to make its way into some of the more mainstream distributions, but that process is accelerating. First released by the US National Security Agency (NSA), in December 2000, SELinux has been incorporated into Fedora Core 2 (and the test versions of Fedora Core 3), Debian and Gentoo and will likely see more distributions that support it and more deployments in the future. It seems like a good time to take an in-depth look at how SELinux can increase the security of Linux.

Linux, like UNIX, has its security based on what is known as Discretionary Access Control (DAC) which means that access to objects is governed by the identity of an authenticated user. It is discretionary because the user can (sometimes unwittingly) pass their permissions to others on the system. A simple "chmod a+w somefile" is an example of a command that a Linux user can execute that opens up permissions on a file to all other users in the system. In addition, any program that is run by a user has at least the permissions of that user. This allows malicious, badly configured, or exploitable programs to use the full permissions of the user executing them and can lead to unexpected security breaches. If, for example, the cat program had an exploitable buffer overrun bug and a particular file could trigger that bug and cause it to delete the files in a user's home directory, standard Linux access control would not prevent it. Any user that could be tricked into executing cat badfile would be susceptible.

SELinux, on the other hand, uses a Mandatory Access Control (MAC) mechanism that seeks to only allow a program the access it needs to do its job and not all the access that the user running it has. In the example above, cat could be configured to only have read access to any files that the user has read access to and any attempt to write or delete any file in the system would be prevented. The administrator can prevent programs from having unneeded access and only allow the user to grant that portion of their access that is needed by the normal functioning of the program. MAC embodies the idea that "those things which are not explicitly permitted are forbidden."

At its core, SELinux defines a security attribute called a type and assigns types to various resources handled by the kernel: processes, files, directories, sockets, etc. The usage of the term type is unfortunate in that it implies all files would be one type, all directories another, etc. This is not the case as each individual resource could have its own type. Each type in the system is associated with a set of rights for each other type in the system and those rights govern what kinds of operations can be performed. This model is known as Type Enforcement (TE) and is the subject of a patent granted to Secure Systems Corp. (SSC), one of the contractors that worked with the NSA on parts of SELinux. At one time there were concerns that the patent would preclude SELinux from being distributed under the GPL, but the SSC Statement of Assurance seems to have alleviated those concerns. SELinux augments the traditional TE model with the addition of Role-Based Access Control (RBAC). Instead of directly associating a user with a type, RBAC associates users with one or more roles in the system and associates one or more types with each of those roles. The permissions checks are still handled by the TE system and RBAC just provides a simpler way to manage users.

SELinux provides a much richer set of permissions than the read, write, execute permissions that UNIX users are used to. There are separate permissions that govern all of the kinds of operations you can do on a file (create, delete, rename, unlink, etc.) as well as specific kinds of permissions for directories, sockets, semaphores, etc. Permissions are stored as bits in an access vector and SELinux has three types of these vectors: allowed, auditallow, and auditdeny. The allowed vector governs whether the operation is permitted. Auditallow and auditdeny determine whether the operation is logged if it is allowed or denied.

It should be noted that all of the permissions checking that is done by SELinux is done after the normal Linux permissions checks are performed. If a user cannot read a file due to the rwx permissions, the SELinux access control mechanism is not consulted.

One would guess that with all of this fine-grained control over permissions, SELinux would be very complex to set up and that would be true, but the NSA and the distributions have done a great deal of the necessary groundwork. As part of their release, the NSA also released policy definitions to be used as a starting point for SELinux administrators. Various distributions have tweaked these definitions for their specific needs, but it is still a very complex and somewhat fragile framework. This author had difficulty with various cron jobs on a Fedora Core 2 SELinux system and the mailing list archives have quite a few queries from administrators trying to get the permissions set correctly for their specific needs. Based on this message it would appear that Fedora Core 3 has ratcheted down the checking that SELinux will do in the default install.

An upcoming article will give a more "hands-on" approach to exploring SELinux using Fedora Core 3 test2 including looks at the policies defined and how they are used to provide more protection than a standard Linux installation.

Index entries for this article
GuestArticles	Edge, Jake

---

to post comments

Complexity

Posted Sep 23, 2004 1:24 UTC (Thu) by elanthis (guest, #6227) [Link] (29 responses)

My problem with SELinux is that it is far, far too complex to configure. Even the designers of the system haven't gotten perfect, functioning setups for many common server setups, and those they do have are not yet tested to ensure they are perfectly secure.

The reason why this is is that the configuration language is a very complex beast. In the *vast* majority of cases, you want to make very simple configurations for individual programs. "Bind can only read files in /var/bind and /etc/bind, and can only write to /var/log/named.log, can only listen on ports 53, can only make outgoing connections on port 53. all other permissions are denied." To actually configure that, though, you need to make several "types" for the files, define the bind system role, and then write all the rules and interactions between these objects. It's complex and a pain in the arse. And complexity and tediousness makes it much, much more likely for mistakes to creep in.

If the configuration just let you explicitly say what you wanted the app to do, and not do, and the configuration compiler (yes, you must compile configurations, retag your filesystem on changes, and insert the compiled policy into the running kernel in order to make changes) could generate the necessary roles and types and such, then you could whip up *perfect* configuration for the majority of both server and user applications with little effort and a far lower chance of error. The full complex syntax could be kept around for the more intricate configurations.

The SELinux folks don't seem to like the change because "that's not how a TE security admin thinks." That's great. Here's a hint: 99% of the actual admins implementing and using SELinux aren't TE security experts; they're normal people that think in terms of what they want done, and not the TE implementation details of how to do it.

Complexity

Posted Sep 23, 2004 2:56 UTC (Thu) by walters (subscriber, #7396) [Link] (11 responses)

As for complexity, Stephen Smalley explains it elegantly.

The reason SELinux permissions aren't based on file paths has also been explained many times. Put most simply, there are *many* possible ways to reference a file (inode) in Linux. You can have hard links, bind mounts, symlinks, etc. Having the kernel try to control access via file paths is inherently fragile. You don't want to restrict file paths, you want to restrict access to the actual object.

Complexity

Posted Sep 23, 2004 4:30 UTC (Thu) by dvdeug (subscriber, #10998) [Link] (3 responses)

Good security plans are simple, in part because it's simpler to understand a simple plan, and in part because few people really enjoy working with security and will make shortcuts when it gets too complex. It doesn't matter how wonderful SELinux is and how many smartass comments you can make about real-world systems being complex, if it's too complex, then it isn't going to work for most of us.

Complexity

Posted Sep 23, 2004 4:57 UTC (Thu) by walters (subscriber, #7396) [Link] (1 responses)

The point is that securing a complex system is going to be complex. There simply aren't any shortcuts.

However, as Stephen says, SELinux is very flexible, as is exemplified by the new targeted policy. The targeted policy is really quite simple, and it's *very* easy to just turn restrictions on a particular service off now with the support for runtime boolean policy changes.

Complexity

Posted Sep 30, 2004 8:44 UTC (Thu) by emj (guest, #14307) [Link]

> The point is that securing a complex system is going to be complex.

Well, if setting up an ordinary multiuser shell/ftp/web server is going to be complex, then SELinux is to complex.

Complexity

Posted Sep 23, 2004 6:12 UTC (Thu) by bronson (subscriber, #4806) [Link]

Well, here's a key phrase from that message:

"Being confident in the correctness of an inadequate security model doesn't help much."

If you can figure out a simple model that both works well and is demonstrably secure, you will gain fame and fortune. However, a great number of people have spent long years working on exactly this problem and there's still no magic bullet. If you're not willing to devote the time needed to create an effective security model then, well, you probably don't need one. Most people don't.

Complexity

Posted Sep 23, 2004 9:56 UTC (Thu) by rwmj (guest, #5474) [Link] (5 responses)

The reason SELinux permissions aren't based on file paths has also been explained many times. Put most simply, there are *many* possible ways to reference a file (inode) in Linux. You can have hard links, bind mounts, symlinks, etc.

So why can't the "compiler" work all this stuff out for me? That's what computers are good at: automating all the grunt-work.

Rich.

Complexity

Posted Sep 23, 2004 13:44 UTC (Thu) by walters (subscriber, #7396) [Link] (4 responses)

So why can't the "compiler" work all this stuff out for me? That's what computers are good at: automating all the grunt-work.

How can the compiler know what will later happen on your system? If some attacker gains privileges to bind mount /foo to /, then all of a sudden you have a whole other set of access points.

Complexity

Posted Sep 23, 2004 14:15 UTC (Thu) by mmarsh (subscriber, #17029) [Link] (3 responses)

I think what he meant is that you specify your rules with file paths, and the compiler figures out what device/inode that path references. The final compiled version that actually gets used doesn't have path references. Then you just have to make sure that all of your old path specifications are still correct the next time you compile.

Complexity

Posted Sep 23, 2004 16:24 UTC (Thu) by walters (subscriber, #7396) [Link] (2 responses)

The files ultimately still need to have types assigned to them. No compiler can figure out what a program is actually doing with all of its files and figure out the best way to assign types to the files in order to achieve least privilege. Having a tool that looked at the file paths the application referenced and guesses types for them while constructing a policy would be somewhat useful. But it would be no substitute for a human.

In a number of cases, SELinux has revealed application bugs like the kerberos libraries trying to open /etc/krb5.conf with write permissions.

Complexity

Posted Sep 23, 2004 17:09 UTC (Thu) by mmarsh (subscriber, #17029) [Link] (1 responses)

That's not how I read the comment, but then I'm also not familiar with SELinux, so this may just be an incorrect reading. My impression was that Rich wanted to assign a type to a file by name and let the rules compiler figure out what the actual object is.

After poking through the documentation, it looks like I might just have been off. There are examples of specifying objects by path, and wildcards to assign a type to everything not otherwise specified.

Complexity

Posted Sep 23, 2004 19:14 UTC (Thu) by walters (subscriber, #7396) [Link]

Oh, I guess I misunderstood what you were saying. There is a mapping from file names to contexts that SELinux uses to initialize the system. Defining this mapping is part of writing a security policy for a program.

However Rich and elanthis seemed to want to do away with types entirely and have them somehow automagically created; that doesn't make sense.

Complexity

Posted Sep 24, 2004 3:59 UTC (Fri) by dododge (guest, #2870) [Link]

As for complexity, Stephen Smalley explains it elegantly.

The stuff going on under the hood of a Linux machine can be quite surprising.

One of my favorite examples is the "cardmgr" program, part of the PCMCIA suite. When the program starts up, it creates a new device file with a somewhat unpredictable name based on PID and a one-up counter. It does this in one of several directories; it has a list of places it tries, and no, "/dev" is not at the front of that list. It then opens the device and unlinks the file while holding it open. It does this multiple times and it all happens very quickly. As a sysadmin you are very unlikely to ever come across one of these device files or even know that this is going on. See the "open_dev" function in "cardmgr.c" for the details; it's still there in the current 3.8.2 release.

Aside: pcmcia-cs even had compile-time shenanigans that could bite you. It made its own copy of the kernel's configuration header for its modules to include, but it only bothered to copy the config settings that it knew about and thought were important. If you had a kernel patch (such as LSM) that added new config settings, the PCMCIA code would ignore them and its modules would be compiled without them. If those config settings resulted in changes to the size and layout of kernel data structures (which LSM certainly did), then loading one of those PCMCIA modules could easily wreak havoc with kernel data.

Now that things like LSM and the PCMCIA modules are all in-tree it shouldn't be a problem, though if you were to build your modules out-of-tree from the pcmcia-cs package it might still do this.

Complexity

Posted Sep 23, 2004 7:26 UTC (Thu) by pimlott (guest, #1535) [Link] (15 responses)

I would love to see an article that criticizes the SELinux approach systematically, and proposes some (more unix-like) alternatives. I think that many of us have the feeling that SELinux is too complex and forces too many changes on fundamental unix concepts, but this usually comes out in random curmudgeonly grousing on mailing lists and message boards. Surely someone can (or has?) stated the case forcefully.

I think that a better path from Linux today to a more secure, compartmentalized system would make more flexible use of the basic unit of unix access control, the user id. It would require both better ways to allocate permissions to user ids, and ways for users to specify different user ids to use for different tasks. This could allow a phased transition, building upon existing tools and techniques, without obsoleting the knowledge users and administrators have about unix security.

Complexity

Posted Sep 23, 2004 10:09 UTC (Thu) by zooko (guest, #2589) [Link] (1 responses)

I think you are on the right track. In my view, the ultimate goal should be an object-capability system, as described in Paradign Regained . Paradigm Regained starts with a good, simple motivating question: "How much authority does cp need?".

My litmus test for this issue is: what access control system will allow me to download a dancing bear program from dancingbears.ru and run it on my desktop, without taking any explicit action to indicate that I want it to have limited permissions, and still be safe from any malicious thing that the dancing bear program might try to do?

I saw a demo of exactly that, using the CapDesk object-capability access control system, demoed by Marc Stiegler.

Any access control system that can't do that isn't good enough for me.

So for me, the question of what kind of access control system to use has an obvious answer: use the object-capability paradigm. The question of how to make it sufficiently backwards-compatible to gain users does not have an obvious answer. The CapDesk demo could not run dancing bear .exe's, nor dancing bear x86 glibc executables. It could only run dancing bear programs written in the E language.

Complexity

Posted Sep 23, 2004 13:46 UTC (Thu) by walters (subscriber, #7396) [Link]

It could only run dancing bear programs written in the E language.

Rewriting Apache, cp, GNOME, bind, su, and every other program in E is not feasible. Therefore, even if E exists, it doesn't provide a solution for Linux today. SELinux does.

Complexity

Posted Sep 23, 2004 13:42 UTC (Thu) by walters (subscriber, #7396) [Link] (12 responses)

I would love to see an article that criticizes the SELinux approach systematically, [...] Surely someone can (or has?) stated the case forcefully.

I don't think such an article exists, because the fundamental concepts behind SELinux aren't new. They've been around for decades. SELinux just builds on those decades of secure systems research to create an implementation for Linux.

I think that a better path from Linux today to a more secure, compartmentalized system would make more flexible use of the basic unit of unix access control, the user id.

The Linux uid-based access control is discretionary, meaning if you own an object you can do whatever you like to it. That makes restricting programs to least privilege much more difficult.

Fundamentally, you need a new system.

Complexity

Posted Sep 23, 2004 16:19 UTC (Thu) by bkw1a (guest, #4101) [Link]

> Fundamentally, you need a new system.

How about permissions+capabilities? In the good old VMS days we had
file permissions and process "privileges". Users were granted certain
privileges as part of their account setup, but a process could drop
its privileges. Privileges included things like the ability to do
low-level I/O to disks, or the ability to create new users.

The idea was that you had a set of per-file "permissions" (similar to
Unix's rwxrwxrwx for "owner", "group" and "other", but adding "system")
and an orthogonal set of per-process "privileges" (similar to
"capabilities" in Linux -- which may or may not still be supported).
Together, they allowed pretty fine-grained control over what processes
could do.

This obviously wouldn't do everything that SElinux does, but I wonder
if it might be a useful paradigm for designing a user-friendly
front-end for SElinux, useful for getting simple jobs done quickly.

Complexity

Posted Sep 23, 2004 18:46 UTC (Thu) by pimlott (guest, #1535) [Link] (8 responses)

The Linux uid-based access control is discretionary, meaning if you own an object you can do whatever you like to it. That makes restricting programs to least privilege much more difficult.

I am skeptical about the value of mandatory access control outside of super-high security (think NSA) environments. I've read "The Inevitability of Failure", and I'm largely unconvinced. Regardless, I think you can achieve most of the goals of MAC in a system based on uids. The obvious way is to allow centralized mandatory policies, expressed in terms of uids instead of roles and types (or whatever else SELinux has): deny access for bob to anything in /home outside of /home/bob, or any file owned by alice. This has some of the same problems as SELinux in confusing users and existing tools, but at least it introduces fewer new concepts. Another approach would make use of filesystem namespaces (the part I forgot in my original message): when bob logs in, he gets his own /tmp and only /home/bob in home. What you can't name, you can't access (the tenet behind what security researchers--not Linux developers--call capabilities).

Fundamentally, you need a new system.

I call cop-out. I don't think the unix security model is beautiful, but it's familiar and workable, and at the core has some pretty powerful concepts. You certainly can do much better with it than we do today, which to me means that we should at least push it and see if we can take it far enough. Also remember that there's not a lot of evidence that security is a technological problem (aside from the widespread use of archaic programming languages).

Complexity

Posted Sep 23, 2004 19:10 UTC (Thu) by walters (subscriber, #7396) [Link] (7 responses)

Strong, mandatory access control helps contain a lot of the problems that we see every day on LWN's daily security advisory summary. Locking down Mozilla has a huge amount of value - if there's a Javascript flaw or image loader buffer overflow, Mozilla shouldn't be able to take my ~/.gnupg directory and email it to somewhere in Russia. The NSA aren't the only ones who need this kind of strong security.

As for extending the uid system - I'm very doubtful that you can get a system that approaches the security and flexibility that SELinux provides, and that also doesn't break existing software. SELinux has the advantage that it doesn't change what happens with the existing Linux DAC - calls to setuid(), etc just continue to work as before.

Complexity

Posted Sep 23, 2004 20:29 UTC (Thu) by pimlott (guest, #1535) [Link] (6 responses)

Strong, mandatory access control helps contain a lot of the problems that we see every day on LWN's daily security advisory summary.

Of course I agree that we need better compartmentalization. But you're begging the question with the assumption that MAC is the only way to do it. You can do a lot with uids. It seems perfectly plausible to me that mozilla court run under a uid that has access to a subset of my files. (It probably needs some extensions to the unix model, but relatively modest ones.) BTW, what if the user wants to send his .gnupg config file in a gpg bug report? Does he have to edit a policy that even SELinux advocates seem to acknowledge can only be understood by experts? Or does he just change permissions on the file?

The NSA aren't the only ones who need this kind of strong security.

When I said only the NSA needs this, I was thinking about controlling information leaks, not compartmentalization. Preventing intentional leaks is extremely hard, even with MAC. You can't really do it; at best, you can slow it down or make it detectable. And it's not practical at all without a lot of resources.

As for extending the uid system - I'm very doubtful that you can get a system that approaches the security and flexibility that SELinux provides, and that also doesn't break existing software.

I wish we had a test to find out! And I'm not necessarily aiming for all the flexibility you get with SELinux. (BTW, I consider the statement that any system "provides security" to be sloppy.) And considering how difficult it has proven to deploy SELinux at all, I'm fairly sure that a less radical change would cause less breakage.

Complexity

Posted Sep 23, 2004 22:10 UTC (Thu) by walters (subscriber, #7396) [Link] (5 responses)

How do you propose to transition uids? How to keep them unique? What about the problem of applications which will want to look up little details like the home directory or user name in /etc/passwd? How do I grant access to this new uid for certain objects?

That's just a random selection of generic problems.

Now, even if you ran mozilla under a separate uid, you'd have to grant it access to your X connection. And at that point, you've lost, since with X any malicious client can sniff keystrokes, spawn a terminal and synthesize rm -rf / into it, etc.

SELinux doesn't solve that either right now - but it will, once we have Security-Enhanced X. And that's already in development.

Complexity

Posted Sep 23, 2004 23:16 UTC (Thu) by pimlott (guest, #1535) [Link] (4 responses)

How do you propose to transition uids? How to keep them unique? What about the problem of applications which will want to look up little details like the home directory or user name in /etc/passwd?

These issues seem easy (but bear in mind these are answers I've made up on my own and never tried!). You have a setuid program that allocates additional uids to a user, puts them in /etc/passwd and everything. (Or maybe you pre-allocate a pool of "sub-users" when you create a user.) By default, they would probably have the same home directory, etc as the "main" uid.

How do I grant access to this new uid for certain objects?

The short answer is with usual unix permissions, but here it gets harder. You probably at least want to let users allocate their own groups, and since groups are not that flexible, you probably want ACLs as well. (But ACLs are becoming more common anyway.) Further, you may need to add a notion of relationships between users, so one user might be a "master" of another and be able to chown or chmod his files. This is where I think a genuine extension may be needed, because in traditional unix, every user is an "island".

Now, even if you ran mozilla under a separate uid, you'd have to grant it access to your X connection.

Yes, this is a hard problem, but again you're begging the question when you say SELinux is the answer. A secure, multi-domain X server can just as well be based on uids (or cryptographic keys) as on SELinux. You seem to equate compartmentalization with SELinux, and I think that's simply an unwarranted assumption.

Complexity

Posted Sep 24, 2004 2:29 UTC (Fri) by walters (subscriber, #7396) [Link] (3 responses)

You didn't try to explain transitioning. But really there are so many problems with this scheme it's hard to know where to start. And even if it all sort of worked, it wouldn't be good enough for me. For one thing, it's still totally screwed if there's an exploitable setuid root program. Also any system service running as root, once cracked, compromises the entire system.

I just don't think anyone is really interested in a halfway solution to security like this.

Complexity

Posted Sep 24, 2004 19:27 UTC (Fri) by pimlott (guest, #1535) [Link] (2 responses)

You didn't try to explain transitioning.

Oh, I didn't get what you meant by transitioning before. You mean switching to a new uid? What's difficult about that? You can write your own setuid wrappers, or call a system setuid root program that lets you drop to any sub-user.

But really there are so many problems with this scheme it's hard to know where to start.

I don't think that's a fair way of arguing, and I don't think this discussion has supported that position. Look, we already use uids and namespaces (chroot) to good effect (though not nearly enough) for isolating system services. Bringing this technique to ordinary users seems both plausible and natural to me.

And even if it all sort of worked, it wouldn't be good enough for me.

I think your view on security is too absolutist. You use a computer today, right, even knowing how crappy our security is? Getting to nirvana should not be the goal, making significant improvements should. (And no, I am not ceding that SELinux is ultimately more secure than my system could be. There are way too many factors that go into security to say that SELinux is more secure just because it has a nice design.)

For one thing, it's still totally screwed if there's an exploitable setuid root program.

This statement is equivalent to saying, it's screwed if there's a vulnerability in the trusted base. This is true of any system. BTW, there's no reason you can't write all the setuid root programs in a safe language (which is not practical for in-kernel code).

Complexity

Posted Sep 24, 2004 20:24 UTC (Fri) by walters (subscriber, #7396) [Link] (1 responses)

Oh, I didn't get what you meant by transitioning before. You mean switching to a new uid? What's difficult about that? You can write your own setuid wrappers, or call a system setuid root program that lets you drop to any sub-user.

So you suggest to write a wrapper for each program multiplied by the number of users? And how do you prevent other users from executing the programs which are setuid to a subuser of another user? A massive system setuid program would require a complex configuration to map out the allowed transitions. This is just the start of the problems, in the end you're going to have something that's much weaker than SELinux and is no less complex.

I don't think that's a fair way of arguing, and I don't think this discussion has supported that position. Look, we already use uids and namespaces (chroot) to good effect (though not nearly enough) for isolating system services. Bringing this technique to ordinary users seems both plausible and natural to me.

Here you and I have a fundamental difference. I feel that the current Unix security model just for system daemons is woefully inadequate, completely disregarding users. For example, one cool thing you can do with SELinux now is set up sshd so you can log in as a normal user (user_t), but not as sysadm_r (the SELinux equivalent to "root"). Even supposing you crack sshd and compromise it fully, the SELinux policy prevents sshd from executing anything with elevated privilges. Sure, it has uid 0, but that doesn't matter with SELinux.

Another good example of a problem that SELinux solves that your scheme never would is prevention of /tmp races. Right now, the "staff" type in SELinux (an unprivileged role used by someone who can become a sysadm) simply cannot read files created by the user type. So when the attacker creates a symlink /tmp/predictable_file_name -> /etc/passwd, even if the attacker makes the symlink world-readable, it still won't work.

I could go on here, but I hope the point is made.

I think your view on security is too absolutist. You use a computer today, right, even knowing how crappy our security is? Getting to nirvana should not be the goal, making significant improvements should.

Right, I agree. We just disagree on whether your model is actually a significant improvement or not :)

This statement is equivalent to saying, it's screwed if there's a vulnerability in the trusted base. This is true of any system. BTW, there's no reason you can't write all the setuid root programs in a safe language (which is not practical for in-kernel code).

Yes, but in SELinux, only the kernel is the trusted computing base. In your model, anything with uid 0 can fully compromise any part of the system. setuid root programs are only a part of this problem. I don't see how you can even get close to getting rid of all the uid 0 daemons on the system today. cron, dbus, dhcp, inetd...the list is huge. SELinux is a much easier and much more secure solution.

Complexity

Posted Sep 26, 2004 0:51 UTC (Sun) by pimlott (guest, #1535) [Link]

So you suggest to write a wrapper for each program multiplied by the number of users?

A single "runas" setuid root program, along with a database containing the user hierarchy, would be sufficient. I was just pointing out that users could create their own setuid programs for whatever reason, though they should restrict access to them. All straightforward with vanilla unix semantics--I disagree that this is anywhere near as complicated as SELinux.

I feel that the current Unix security model just for system daemons is woefully inadequate

Your point about sshd is interesting, because I think I can use this to illustrate the "unix way". Of course, you know about privsep. The process that processes network connections has "no" privileges. (Of course it has some, but this is a separate issue; it should be possible to run the child as a user who can do nothing but talk to the parent and the network.) When the client authenticates, the child passes a "proof" to the parent, which sharts a user shell. I think the notion of a high-privilege daemon that executes requests from a low-privilege uid upon suitable proof should be a standard unix service. There's a project called userv that tried to do this.

Now, there is still the problem that the privileged process runs as root. You could say it's just part of the trusted base (which might make even more sense if it were generalized as suggested above). But if you'd like to do better, one idea would be to use the "master user" idea I mentioned before: Allow a uid to switch to any uid of which it is a master, and have the sshd privileged process run as a master of all users who are able to log in remotely.

(SELinux solves the second part in its own way, but obviously does not remove the need for privsep.)

Most daemons are much simpler than sshd in that they don't need to switch to other users based on network input. Those should be much easier to move away from root, and of course some have been. Some changes ought to be made in how access to the network (binding low ports, sending raw packets) is controlled. You might argue that if this is so easy within the unix model, why aren't we further along? I don't have a great answer. Maybe it is people don't care enough about security to do it. Maybe it's because the devil is in the details: figuring out exactly which privileges a daemon needs is hard (as the SELinux people have found out themselves). Maybe all the people who could do it have been seduced by SELinux. ;-)

I don't see how you can even get close to getting rid of all the uid 0 daemons on the system today.

In theory, it's the same process as tightening down a daemon with SELinux: Move it to a user with no privileges, run it, see what breaks, and figure out how to give the user the necessary access (or change the daemon).

We just disagree on whether your model is actually a significant improvement or not :)

Yes, but I remain optimistic. I still think your view is tainted by the historically insecure unix implementation(s), and so you don't give the unix model a chance. Maybe in a few years SELinux will be mainstream and make Linux so secure that this will all be moot. But I'm skeptical that it will gain the necessary acceptance and usability. Or maybe I'm just too tied to unix tradition, and the new SELinux generation will prove me wrong!

Complexity

Posted Sep 23, 2004 20:36 UTC (Thu) by pimlott (guest, #1535) [Link]

I don't think such an article exists, because the fundamental concepts behind SELinux aren't new. They've been around for decades. SELinux just builds on those decades of secure systems research to create an implementation for Linux.

PS. Academics have been known to spend decades on ideas that don't work out well in practice. :-)

Complexity

Posted Sep 24, 2004 6:07 UTC (Fri) by Ross (guest, #4065) [Link]

I think the other poster was suggesting something like heiarchical userids
so that users could run subprocesses with a different set of rights than
the parent process. To avoid priviledge escalation these would have to be
strictly one-directional. Similar support for groups would also be nice.

The question is what would the interface look like and how much would it get
in the way. If it was too difficult to use people might as well use a non-
Unix-like solution like SELinux.

(Capabilities are useless as currently defined in the kernel unless you are
trying to restrict what a program running as uid-0 can do. None of the
operations which normal users can perform can be disabled.)

Complexity

Posted Sep 24, 2004 3:01 UTC (Fri) by dododge (guest, #2870) [Link]

My problem with SELinux is that it is far, far too complex to configure.

You could in theory replace all of the existing SELinux policy generation code with your own. The system is extremely flexible and I don't believe the kernel cares at all if you use the provided types and domains. If you don't want such a granular system, you could make your own policy generator that had very simple input expressions. This would admittedly be a lot of work up-front.

The default ruleset already does some of this in the form of m4 macros, so that you don't have to write out every little rule by hand. I know of projects that have used much more complex macros to abstract away more of the details.

Is is not that complex

Posted Sep 23, 2004 21:49 UTC (Thu) by erich (guest, #7127) [Link] (1 responses)

It isn't that complex.
Granted, the tools could need a bit of polishing. For example when installing the initial policy, it will ask you for several dozens of files wheter you want to install them. For example you will be asked if you want to install "bind.te" and "bind.fc" (type enforcements and file contexts).
For most apps, such files have been written and work.

The more applications you run, the more rule sets you'll have to write on you own. Well, not totally on your own. There are a dozen of macros which will do most you need. So you end up writing single-liners which could be translated to english as "allow application foo to read files of type foo_static_data"

Hell, this is not that complex. A real MAC approach can't get much easier.
It's just the syntax that sucks. But i guess if they had used perl macros to generate the config files a different part of the users would complain.

(And you are free to use different tools to generate your rule files)

Is is not that complex

Posted Sep 23, 2004 22:14 UTC (Thu) by walters (subscriber, #7396) [Link]

Granted, the tools could need a bit of polishing. For example when installing the initial policy, it will ask you for several dozens of files wheter you want to install them.

I spent a while trying to fix that while I was still working on SELinux for Debian. Russell never had time to look at it, but it'd be cool if you could pick it up again. I think the code is still in the ancient versions of my Debian policy packages.

Contrast SELinux with LIDS (most popular alternative), RSBAC?

Posted Sep 23, 2004 22:22 UTC (Thu) by linuxbox (guest, #6928) [Link]

With all respect to the SELinux developers, SELinux is by no means the only MAC framework for Linux. I'm surprised to find no mention of it in this discussion.

I really don't know SELinux at all. However, I'm very familiar with LIDS, and I can substantiate that in the LIDS framework, highly restricted systems can be configured with a relatively small number of ACLs, which are strictly rule-basd. ACLs are applied to fs/inode tuples, not "paths," and no "policy compiler" or similar complexity is introduced. (LIDS does have a "learning mode" facility for automatically generating ACLs based on [ideally normal] activity patterns on a host.)

Hence, just based on reports, it would seem possble that:

1. SELinux object and policy system may deliver (much?) finer-grained security policies than LIDS

2. LIDS rulesets for single-purpose hardened systems appear to be both simpler and _smaller_ than SELinux policies--making them potentially easier to contruct and to understand/audit

It seems like it would be well worth the effort to compare differerent approaches to this problem, before concluding that the MAC concept is unworkable or that it necessarily leads to unmanageable complexity. That has not been my experience with the LIDS system.

Not feeling very reassured

Posted Sep 24, 2004 19:46 UTC (Fri) by Max.Hyre (subscriber, #1054) [Link] (1 responses)

The ``Statement of Assurance'' has some holes you could drive a truck through. Specifically,

Secure Computing will not assert <its rights> with respect to any use, modification or distribution of SELinux software that is permitted by, and is in compliance with, the terms and conditions of Version 2 of the GNU General Public License (the “GPL”).

Hmm...They're saying anything the GPL allows is fine with them. But why that phrase ``of SELinux software''?

The commitment not to assert <its rights> [...] is limited to SELinux software that is release (sic) under, and governed by, the GPL.

Again: ``limited to SELinux software''.

<It may> assert <its rights> with respect to VPN gateways, perimeter and distributed firewalls, URL filtering, authentication and authorization for applications, hosts and devices, and other products, features and functions that are beyond the scope of the Assurance.

So this is GPLed code that I can't take and move into any GPLed version of the applications they call out?

<It> may license or otherwise transfer <its rights>, including the Subject Patent Rights, without any restriction or condition. The recipients of such rights are not bound by this Statement of Assurance, and may assert any rights acquired from Secure Computing without any limitation or restriction.

So this assurance isn't worth the electrons it's written with, should they sell the patents. Hell, they could set up a new corporation with the same board of directors, and sell the patents to it.

No license is granted in this Statement of Assurance with respect to the Subject Patents <....>

So allowing the code's release under the General Public License doesn't give you a license.

It seems to me that this ``Statement of Assurance'' is incompatible with the GPL, and the code cannot be distributed. Not good.

Not feeling very reassured

Posted Oct 2, 2004 17:07 UTC (Sat) by nealmcb (guest, #20740) [Link]

Right on. Also:

• Other Patents. Secure Computing may have rights in other patents that are applicable to SELinux, and similar or related products. Secure Computing retains all of its rights in those other patents, including the right to prosecute any infringement of those patent rights. Nothing in this Statement of Assurance will limit Secure Computing s right to acquire or assert additional patent rights, whether by license, assignment or application.

So they may prosecute SELinux users based on other patents.

I'd like to know whether the patent is likley to be valid.