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

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.

Stack Guard

[dusanv]

While we are at the topic of security I was wondering whether there are any similar products to StackGuard (www.immunix.org) available for a newer gcc? StackGuard is commercial and only works with older gcc's. If there were such a thing one could probably do a whole system recompile with it (a la Gentoo). That would beef up the security considerably. The Immunix FormatGuard also looks interesting.

D.

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: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:FUD alert!

[bgeiger]

Isn't this ingenious? Taking potshots at Linux by appearing to support it? ...clients are willing to reduce their servers' feature set, flexibility, and ease of maintainence by switching from Win2k...

I won't rehash the manyfold reasons you're wrong about those assertions (it's been discussed to death already), but I will point out that you're wrong, and you're just trolling. Knock it off.

Besides, while Linux's security is excellent, it can (and should) be improved. It's good, but by no means perfect. (It's much better than anything M$ can put out, though.)

Re:It's a bit of a challenge, and one to be avoide

[jc42]

> 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?


Yeah. Or, for that matter, RedHat.

And with RedHat (or any of the other linux vendors), not only do they know what their code does, but there are also thousands of programmers scattered around the world who know a lot about it.

So if you have a problem, you don't have to beg and plead with a disinterested CS department of a giant corporation. You don't even have to deal with your vendor.

If it's a small problem, you can probably hire one or two of the linux hackers at your local college. For bigger projects that take experience, you can hire a few of the local linux professionals.

You'll be up and running in far less time than it takes to persuade Microsoft to support your needs.

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

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.

Re:I suggest vserver

[Anonymous Coward]

Also check out User Mode Linux. Its an open source project which does similar things. Rather than creating a whole new virtual machine, this allows you to run a linux kernel as a user space process, giving a whole virtual linux system inside it. And it does have a "jail" mode for increased security (separation between virtual server and host).

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.

debugging security patches

[Goodbyte]

I used to run lids and grsecurity, but now I feel that the acl system in grsecurity is more powerful that that in lids.

Grsecurity's non-acl options are awesome. No setup, and almost all programs work as before (execept some programs that nedd stack execution, but that is a piece of cace to fix.)

BUT (and here comes my main point) the acl system (both in grsecurity and form my earlier experience from lids) needs more debugging. LIDS once released a version where you couldn't run (almost) any program because of the LD_LIBRARY flags, and grsecurity give me kernel panic every now and then. No problem on my system, it gives me and excuse for poking in the kernel source, but I would never use the acl on a production system.

Re:chflags/chattr

[someonehasmyname]

in FreeBSD you have a "kernel security level" man securelevel

The kernel runs with four different levels of security. Any super-user process can raise the security level, but no process can lower it. The security levels are:

-1 Permanently insecure mode - always run the system in level 0 mode. This is the default initial value.

0 Insecure mode - immutable and append-only flags may be turned off. All devices may be read or written subject to their permissions.

1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted filesystems, /dev/mem, and /dev/kmem may not be opened for writing; kernel modules (see kld(4)) may not be loaded or unloaded.

2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with filesystems by unmounting them, but also inhibits running newfs(8) while the system is multi-user. In addition, kernel time changes are restricted to less than or equal to one second. Attempts to change the time by more than this will log the message ``Time adjustment clamped to +1 second''.

3 Network secure mode - same as highly secure mode, plus IP packet filter rules (see ipfw(8) and ipfirewall(4)) cannot be changed and dummynet(4) configuration cannot be adjusted.

Absolutely necessary

[octogen]

At least an authorizations/privilege security model instead of the anyone/root distinction is absolutely necessary.

The problem is, that many daemons (like Sendmail and such) override *all* security - of course, this is absolutely unnecessary.
For example, on Argus enhanced systems you run Sendmail with the pv_asn_port privilege instead of root privileges.
If someone manages to hack Sendmail, then the attacker can do nothing else than just open port 25, while on other OSs (even OpenBSD) the attacker gains root privileges.
Sendmail does not need root privileges to run, so why should we give Sendmail root privileges?

One key to more security is the 'principle of least privilege'. Modern Unix Operating Systems like Trusted Solaris show, that it is possible to implement fine-grained privilege control in Unix kernels.

Just securing a few dozens of applications (that's what the OpenBSD project calls OS security?) is not enough.
What if I need to run some other application?

An Operating System should be able to protect data even in the case, that an application gets hacked.

Our real problem is 'root' - it should never be used for any kind of server application (daemon), but only for system administration by an authorized user. There should not be any permanent processes running as root.

LIDS, the grsec patch, NSA's sample implementation of MAC and such things are steps into the right direction.