Slashdot Mirror
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?"
I've been useing the grsecurity patch on the medium level. Seems to help out a bit, haven't had any problems. Performance does not seem to be affected.
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.
http://www.nsa.gov/selinux/
adds some intresting security features, but doesnt support x so i didnt install it on my workcomputer.
Also adds the question do we trust the NSA even if the source is avalible
I'm currently using OpenBSD in a work-related project. It's quite good, if not well documented.
You can't ride two horses with one ass
The Linux Security Model has been included in the upcomming 2.6
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.
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.
"Karma can only be portioned out by the cosmos." -Homer Simpson
There's a program called Snort that does packet sniffing and intrusion detection, among other things. It's at snort.org.
That and good ol' P.G.P.
We're Doomed
... you can try PitBull from Argus Systems. It's a very good product and free for non-commercial use (I think). If you can live without the source to their module.
I tried that - that solution gives more isolation between your virtual machine and main machine, but it's much slower than vserver patch.
I tried to use vserver patch for Mandrake 8.2 on
P1-200MMX with Apache, DNS, Mozilla, X and it worked perfectly.
But on the other hand, you know what idealism is ...
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.
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.
This past January-June, I worked on a project involving LIDS. I was responsible for all the setup/maintenance. Setup for LIDS is extremely easy. The difficult part is setting up the ACL's. For a complex system with many daemons running, this might be a difficult task. Fortunately, you can find plenty of people who make their ACL lists public, so you can see how to setup common things such as Sendmail, Apache, SSH, etc. With a good ACL list, your box will be as secure as it can get. With constant attacks on our LIDS box, no one ever got total control. The one time we let someone get root (for research purposes), that person was not able to do anything (even root can be made to not have certain accesses). I highly recomend LIDS to anyone looking for a more secure linux.
Um, how about libsafe?
-Steve
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
One of the best ways to keep your system secure is to keep it simple: remove daemons, remove kernel modules, remove software you don't need, etc.
I don't know the facts about Linux, specifically, but there is a push in the *BSD world for kernel security features to be incorporated as defaults.
The only one I recall off the top of my head is "non-executable stacks" to keep stack overflow attacks from being quite as easy. I'm sure it has other advantages, as well.
All this does is "raise the bar" for attackers. I'm assuming most of the Linux kernel security tweaks do the same.
-- clvrmnky
It seems to me LSM (Linux Security Module) is the former SELinux (Security Enhanced Linux) from NSA. The LIDS (Linux IDS) is totally independent. The news is that LSM has been accepted into the development kernel tree.
You must feel kinda silly now that the recent OpenSSH ChallengeResponse bug can root a default OpenBSD remotely in seconds...
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.
/" as root, and your system must still be up and running. No need for any integrity checker.
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
{{.sig}}
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.