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

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

[MrResistor]

From my (very limited) experience with ACLs on HP-UX I thought they were wonderful. You could totally ignore them and function just fine in every way that you can function in the default Linux permissions model. Basically, the only time you needed to deal with ACLs at all was when you wanted to specifically (dis)allow access for certain individuals. Doing that through groups is a pain, since then the user has to change groups to access certain stuff, etc.

ACLs made it really easy to give permission to only the people you wanted to, and you could totally ignore them if you didn't want to use them. I would be really happy about a similar implementation being a part of Linux and not just a patch.

Re: ACLs

[WetCat]

Probably it's the reason that system that implement only DAC cannot be given more than class C in Orange Book.
For class B and A you have to have Mandatory Access control.

Re:ACLs

[ts0003]

1. While you did not introduce the notion of an access-matrix, you referenced a theoretic proof regarding the security of DAC. Acess Control models implicitly build on the access-matrix or a transformation of it.

2. It's true that you did not use the HRU result. If you could point to the work that you did base your claim on, it would be helpful. Alternatively, summarize the insight of the proof so we can understand the merit of your assertion.

3. Again, a statement you make borders on misleading. Your 3rd point is untrue. MAC forces labels and sensitivity designations. The actual policy is responsible for stating the information flow rules.

The trojan of your example can easily be transferred between processes with the same clearance belonging to different subjects.

Apart from that, MAC and DAC refer to *models*. Errors in *implementation* and configuration still abound, and a MAC system will not help in this case.

Re:Neat Security Trick

[dohcvtec]

How often would this happen? It's sort of a novel idea, say if you're just learning about the fundamentals of security and networking, but if you're frequently getting cracked by kiddies, maybe you should take a deeper look at what you're doing right and wrong.