Additional Security in the Linux Kernel?

nyx asks: "Recently, I was looking for some way to improve security on my linux boxes. I found few linux patches like grsecurity, LIDS (now also as Linux Security Module), Medusa DS9. I'm testing grsecurity (and it's ACLs) now and I'm quite satisfied with it, but I wonder, what are pros and cons of other solutions. Anybody tried them and can share his experience with us?"

Comments

Additional Security

[SpanishInquisition]

Lock the door when you leave the computer room.

I suggest vserver

[WetCat]

http://www.solucorp.qc.ca
You can create virtual servers on your machine, tailored for specific tasks.
For example, you can create virtual server where you'll work on your project, virtual server which will run apache, virtual server in which you'll browse web and read mail.
You then can put them on different IP addresses (or no addresses at all) and make them indepedent, changing information only by means YOU approve (shared directory, TCP sockets under firewall, etc).
It's a kernel patch and some user-mode programs.
Virtual servers can share binaries for saving disk space.

LSM has been included in 2.5.27

[daserver]

The Linux Security Model has been included in the upcomming 2.6

Neat Security Trick

[CONTROL_ALT_F4]

I had a friend who ran all of his INET services through a VMWARE instance on his Linux box. He would get hit by a script kiddie, and then use the ROLLBACK feature to undo the damage. He would patch the hole on the virtual machine and start up the site as if nothing happened.

Re:Bastille - No Kernel Patches

[RadioheadKid]

Bastille Linux is user space hardening (e.g. changing file permissions, disabling telnet and other vulnerable services, setting up IPTables and various other security features), no kernel patches as far as I remember.

Stop writing code!

[captain_craptacular]

It's obvious that the only answer to this question is for all kernel developers to stop all productive activities for one month in order to sit through long and boring security lectures in groups of 500. After this month linux will be fully compliant with the "trusted security initiative" and will be magically bug free. Until such time as another bug is discovered.

ACLs

[Black Parrot]

ACLs (access control lists) are a wonderful technology, but for non-trivial systems they become an administrative pain in the @ss. In principle you would set them up and forget about them, or at least let users maintain their own, but in practice users can't maintain their own, and they will pester you to death with requests for changes.

They also tend to drag the sysadmin into office politics. E.g., Secretary A is out on vacation and Secretary B calls you and says Secretary A did not set up her ACLs correctly and would you please give B access to certain of A's files. In addition to the annoyance of having to babysit the users, there's really no correct response to such a request.

ACLs would be great on a system where everyone is a power user. In practice that usually means your home system where you are the only user, so ACLs aren't very helpful anyway.

Conclusion: wonderful technology, hope I never see it again.

BTW, I speak from personal experience, having formerly managed VAXen with their wonderful ACL implementation. I don't object to ACLs on Linux, I just don't want them.

Re:ACLs

[WetCat]

BTW,it's theoretically proven that security provided by Discretory Access Control systems (in which ACL's and unix protection schemes belong to) is algoritmically unprovable - you cannot deduct that system is secure based on system and DAC rules.
That proof is possible if are using mandatory access control or may be other security means.
So DAC are not only pain in the ... - it's also a nonreliable means of security.

Re:ACLs

[ts0003]

The parent post in incomplete at best, and if viewed less charitably it is misleading.

1. The 1976 Harrison, Ruzzo and Ullman result (from "Protection in Operating Systems") pertains to "safety" in the access-matrix model. Inferences about security need to verify the implementation of the model as well.

2. The result only applies to a system where an infinite number of subjects and objects can be created. An implementation on a typical OS does not suffer from this limitation since resources of the host that are used for the digital representation are finite.

3. Their proof reduces a Turing machine to the access-matrix model, introducing a mapping between decidability and the leakage of a right in the access-matrix. Deciding whether a specific leak occurs is the equivalent, then, of solving the Halting problem. This proof, however, says nothing for a system where more specific knowledge of the system is used, where you *can* make stronger inferences. Look to the mono-operational system for a concrete, albeit impractical, example.

4. Their results hold for any model that uses an access-matrix, regardless of whether it is Discretionary or Mandatory.

Re:Small thing...

[kylus]

Yeah there are other components that use the LSM hooks aside from SELinux and LIDS. There's Domain Type Enforcement (I believe).

Back to the original question I've used LIDS, SELinux, and GRSecurity and I've found them all to have their strengths and their weaknesses. The common problem with all of them is there is usually something you forget to configure properly the first time which can really be a pain to fix. SELinux and GRSecurity both solved this by adding a toggle mode and a /proc entry respectively to change the enforcement of their code.

With SELinux, the major advantage is that you gain a VERY flexible architecture you can use to create nearly any type of Mandatory Access policy you need. The specifications of the system make it able to use policies based on Type Enforcement (putting the bitchy SCC patent issues aside for the moment...), Role-Based Access Control, or Multi-Level Security and likely a host of other things. The drawback is that creating a policy that covers the whole system is not a trivial thing...look at the example security policy included with the distribution (http://www.nsa.gov/selinux) and you'll see what I mean.

GRSecurity is not exactly related to SELinux; they do different things. I like GRSecurity because most of its options do not require a lot of extra configuration, they don't break any existing applications (those that do are clearly marked), and they add a lot of small protections without a great deal of overhead to the vanilla kernel. Plus their ACL system is quite well-developed and extremely secure.

Ultimately I think it comes down to figuring out what you need for your box and then going with the option that will provide it to you with the least amount of interference (unless you like fixing things, of course ;) ).

ACL's in Red Hat Limbo beta

[Laven]

ACL support was added to the kernel in Red Hat Limbo beta which will likely become Red Hat 8.0. They also include the command line tools to manipulate the ACL's.

Read about it in the RELEASE-NOTES
ftp://videl.ics.hawaii.edu/mirrors/redhat/linux/be ta/limbo/en/os/i386/RELEASE-NOTES