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.

Re:Additional Security

[dirvish]

Remove the boot floppy from the disk drive.

zerg

[Lord Omlette]

Let's hear it for NSA Security Enhanced Linux! Whoo!

If the NSA security enhanced your machine, would you even know about it? Suspect it?

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.

Re:I suggest vserver

[jelle]

Actually, I run Debian (woody) and I've been running a pristine RedHat7.2 install in a vserver on it for a couple of weeks now. I'm running two distributions in parallel. No more upgrading of distributions, just install new ones additionally. I can always still use the old version (as long as they all accept a common 2.4 kernel)

howto? Simple, install redhat7.2 on an empty disk, and copy all the files including permissions to /vservers/01 (or mount the disk there).

The vserver sources are easy to deb-make (man deb-make) (tip: "RPM_BUILD_ROOT=$(DESTDIR)" in the Makefile).

"vserver 01 start" to boot rh72, and "vserver 01 enter" to enter it as root. edit the ListenAddress in /etc/ssh/sshd_config of your debian to only bind to one IP instead of 0.0.0.0, and then you can start an ssh in the rh72 vserver and there you are, as if you had an extra computer running rh72.

(did I mention the whole thing is diskless remote boot too?)

Bastille

[pauly_thumbs]

I seem to remember kernel patches happening in Bastille Linux... but then again in these autumnal years .... i remember things that never happened more and more....

LSM has been included in 2.5.27

[daserver]

The Linux Security Model has been included in the upcomming 2.6

Small thing...

[Jetifi]

Linux Security module is what adds hooks into the kernel for security. LIDS uses the LSM hooks, and so does SELinux, and (I think?) others. But LIDS != LSM.

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 ;) ).

St. Jude Kernel IDS

[ActMatrix]

You might want to check out Saint Jude - a kernel intrusion detection and response system which detects and blocks 'anomalous' behavior (such as root exploits). The developer first presented it at Defcon 8 and it looked pretty cool. It's been in development for over a year - see its SourceForge page for more.

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: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.

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

[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]

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: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:It's a bit of a challenge, and one to be avoide

[gwernol]

This is such an obvious troll. What a shame it got modded up. Just a few of the more glaring errors:

C, a language that provides no security features such as garbage collection

In what sense is garbage collection a security feature? That makes no sense.

It is a very sad fact, but logically Microsoft's programmers are smarter than those in open source, simply because they're able to earn more money

That's not true at all. As someone who makes their living programming I can tell you that there are plenty of dumb commercial programmers and plenty of smart open source programmers. And vice versa. If you really wanted to be "logical" you'll understand that money earnt is not the same as skill. Plenty of people do highly skilled work without payment - ever heard of a hobby?

go for an operating system controlled by one company, who knows what their code does, and how to fix it if it goes wrong. The only option, in that case, is Microsoft.

Er... or Apple?

Like I said, blatant troll.

use only trusted code

[Pegasus]

Bandaids like lsm, grsecurity & co will only help you cover to some extent the holes already there. I don't feel like this is the ideal solution ... The ideal solution is to write clean and bugfree code and use that. OpenBSD will probably get you there in the quickest way.

But on the other hand, you know what idealism is ...

Re:security

[RinkSpringer]

From http://www.trustedbsd.org:

The TrustedBSD project provides a set of trusted operating system extensions to the FreeBSD operating system

In other words, it's not an OS, it's a set of patches and extensions... please, check your facts before you post something.

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

grsecurity

[bozoman42]

It works marvellously when it works. Randomized pid, randomized sequence numbers, and soon to have ACL's that define resource limits on just about anything. Really powerful.

When it works.

I've been trying to run it on an SMP Xeon for a while now, and any time the machine exerts itself I have to go hit the big red button. And it's not really a machine I'd like to do "testing" on, so no, I won't help with debugging. What "testing" I've done so far has been nothing but infuriating.

Another few tidbits: all the security in grsec basically completely prevents any JVM from running at all. Ditto UML. (Though UML may also have issues with SMP. But now that I've removed a big variable in my equation of horror...)

Since Rusell Coker has package SELinux for Debian, I will definitely have to investigate that sometime in the near future. I think I'll rack some uptime first to bolster my self esteem. :)

Systrace for *bsd

[numatrix]

I'm suprised no one has pointed out systrace yet. Granted, it's not for linux, only OpenBSD and NetBSD at this point, but it seems to be a very promising move in the ACL world. As one other poster commented, the most difficult challenge with any heavily ACL'ed environment is configuring the ACL's and making sure you didn't miss something. It's an extremely tedious process that requires a lot of reloads until it's done right.

Systrace eliminates much (but not all) of that initial trial period with a method of analyzing processes and watching what permissions for what resources they need and generating ACL's based on 'normal' use. This interactive mode ~greatly~ simplifies the otherwise length process of configuring the kind of security modules being discussed.

LOMAC - Perl tainting for Linux

[Animats]

LOMAC has some promise. They have a good idea: there are two integrity levels, high and low. Everything that comes in from the net is at low level, and can't affect anything that is at high level. Level is carried around with files, processes, etc. This severely limits what can be done from the outside.

This has real potential for locked-down servers, kiosk systems, etc. It's a bit stringent for most desktops. But it's not too hard to use.

chflags/chattr

[chrysalis]

All these add-ons are nice, but you can easily have a very hardened server without installing nor patching anything. Linux, *BSD and probably other operating systems have extended fs attributes for ages.

With standard commands like chflags (BSD) or chattr (Linux), you can mark files and directories read-only (immutable) or append-only.

The point is that once you have a working system, and if you have local access to the console, you can set proper attributes to all your files.

You then have the concept of "security levels". Once your box is in multi-user mode, the "security level" can increase, and a lot of thing will be refused by the kernel : changing firewall rules, access to kmem, to raw devices, etc. and changing extended attributes.

So even if an attacker gets root access on your box, he won't be able to alter anything except some ever changing files (something that can be solved by using an NFS mount) . And the append-only log files are really nasty, because he won't be able to hide what he's doing. Patch your favorite shells to always log history files to an append-only file to get even more fun.

On a properly configured box (that you have console access on), you must be able to run "rm -rf /" as root, and your system must still be up and running. No need for any integrity checker.

Re:Current Project with PF_KEY

[CoolVibe]

Also, if you're condemned to Solaris, like me, then Pappillon is another option.