NAI Labs releases LOMAC, a kernel security extension 62
Tim Fraser writes "NAI Labs
has released a new version of the
Linux LOMAC kernel extension
, their latest in a series of security
extension products they're involved with -- ranging from
components of TrustedBSD to SELinux. LOMAC provides a drop-in
security solution that does not require extensive administration unlike
other kinds of Mandatory Access control (MAC). There's a port of LOMAC to FreeBSD in the works. The release announcement has more details.
Too good to be true? (Score:2)
(oh, and I think fp, but I'm not sure)
Fantastic (Score:2)
--
Re:As long as... (Score:1)
--
Drop in security? (Score:3)
With all of that aside though, any kind of thing like this has got to be good. When high-up people see that something like Linux is getting support like this, they (in my experience) become a little less afraid of it. Didn't Microsoft claim to have some kind of security certification on NT or something like that? My memory is getting sketchy so there's a damn good chance I'm wrong. But if Linux could have something similar to that... it would definitely be a start. To some people, fancy titles mean everything.
Mike.
Good to see true kernel level security solutions (Score:3)
Great Work Guys!
--CTH
--
This is definately off topic (Score:1)
i.e. MAC address
now Media access control.
Maybe some standards would be great.
The slashdot 2 minute between postings limit: /.'ers since Spring 2001.
Pissing off hyper caffineated
This is ok but... (Score:1)
Re:Drop in security? (Score:2)
Re:They can call it "secure"... (Score:1)
--
Re:Too good to be true? (Score:5)
Basically LOMAC's goal is to increase security without being intrusive. (Intrusive systems are hard to get people to use). It doesn't protect against everything, or even close to everything. It does make a class of actions which should basically never be done impossible.
It divides the fs into level 1 and level 2 parts. Level 2 stuff is things like
This keeps someone who compromised your copy of bind running as root from reconfiguring your system. It doesn't stop them from trashing your www data, or anything else going on at level 1.
i.e. it eliminates a certain class of problems.
As to it being drop in, it's a kernel module. What is level 1 vs. level 2 in the file system is defined at compile time. There is _no_ configuration, which makes it very easy to use.
Ok, so what's so great about it... (Score:4)
Ok, so it's nice to just load it, and all your problems will go away. Anyways the standard user won't use it because they haven't heard of it, and they dont know how to get it or compile it.
Anyone with more experience about system should use something like LIDS or SELinux, which lets you do much more fine-grained control, and SELinux really rocks in this aspect. Of course SELinux isn't very stable yet, so using it on a web-server maybe ain't the worlds greatest idea, but this is where LIDS comes to play.
SELinux is of course very cool when building remote administration computers (one computer in the network and all remote administrators has to log in to it, and connect from it to the server they wan't to administer) or shell boxes.
So I really don't think this is anything great, or?
Re:They can call it "secure"... (Score:2)
Since he pretends to be Theo, they can pretend to audit the code.
Re:As long as... (Score:1)
--
Lomac. (Score:3)
Protect your computer from outside forces, befriend LOMAC of the forest people. He will pound intruders with sticks and release hounds upon persons who would scan your ports.
He shall call locusts to protect ftp, floods to guard again DoS and will conceal your serial ports with small bushes and shrubbery.
It is LOMAC! Flee!
He shall create small burrowing animals to scratch at the shins of Chinese hackers who would defile your graduate hompage. He will attach secret undersea creatures to the undersides of your mouse to protect you against static charges. He will warn you when you sit weird and your leg might fall asleep.
It is LOMAC! (Score:-1, Retarded).
Slashdotted already! (Score:1)
Re:Drop in security? (Score:1)
Yeahhhhhhhhh....that's what I was trying to remember. It was in that Linux vs. Win NT BS on their site a year or two ago.
Mike.
Re:This is definately off topic (Score:1)
Good idea, but will never be perfect (Score:1)
I'm currently working on a project that runs on an embedded linux system and after trying to boost security/speed i've come to the conclusion that the only way to be completly anal retentive about it is to know exactly how everything on the system runs, and then removing/modifying whatever is not needed.
Sorry if this is a bit offtopic but i'm just trying to stress that it's impossible to take a task such security and place it into the hands of an idiot with a powerful program. Linux users shouldn't think advancements like this will ever eliminate a saavy administrator. Props to NAI for developing a nice set of extensions as well.
The only statement that cannot be questioned, is that every statement can be questioned.
Re:This is ok but... (Score:3)
Thanks for your interest in LOMAC! LOMAC is my project, and I've talked quite a bit with Amon Ott, RSBAC's creator. We'll both be at the Kernel Security Extension BOF at the upcoming USENIX Annual Technical Conference this June.
LOMAC and RSBAC have different goals. RSBAC's goal is to provide a general framework that can (simultaneously) support a wide variety of access control mechanisms. LOMAC's goal is to be compatible with existing Linux kernels and software. There's a tradeoff between functionality and compatibility: RSBAC provides general support, but requires a kernel patch. The LOMAC LKM supports only one access control mechanism, but it can be loaded into unmodified off-the-CD-ROM Linux kernels.
I've talked to Amon Ott about porting LOMAC to RSBAC's framework. I'm hoping to do a demo-quality port this summer, if I can find the time.
Also, LOMAC allows remote administration via SSH.
- Tim Fraser, NAI Labs
Re:Ok, so what's so great about it... (Score:2)
As to your suggestion about the immutable flag - that keeps files from getting changed at all by anyone. This keeps files from being changed by any proccess that could have been corrupted. Again, not nearly as intrusive as not being able to modify any system files without rebooting.
LIDS, SELinux, etc. are great in many situations. LOMAC has uses in others. It's not a better or worse thing.
Re:Drop in security? (Score:2)
security wall of silence (Score:2)
I just wrote a rebuttal to Kurt Seifried's humorous "Why Linux is more secure then OpenBSD" which can be found here [antioffline.com].
So here's my two cents to it all. Having used Linux for some years then switching back to the BSD's (started with FBSD, now running Open for my server, and FBSD @ home) I'd have to say Linux is as much of a Joke as Windows is when it comes to security, and no I don't mean to be a troll.
People are forgetting some of the core basics involved with security. Auditing. If core codebase was audited prior to releasing a distribution, you wouldn't have that many security advisories coming forward. Sure the process can become tedious especially when your in a large network environment, but why should I run an insecure OS then download an add-on solution, when I could just download OpenBSD for hardcore security?
Give me a break sure lomac sounds great so does did bastille, so does SE-Linux but these to me are just patches. I'd rather take a secure by default installation any time.
And oh yea you could respond with limiting services being run, but that still doesn't account for all the patches you have to install because someone just released another advisory for Linux.
Anyways the article I wrote summarizes some good points and weak ones too. kudos
J. "sil" Oquendo
Uncommon Hax0rin6 Methids
Chief Hax0rin6 Office
AntiOffline.com
(security pimps should get a laugh off the sig
Re:Fantastic (Score:1)
Nothing stopping you from porting it.
But if jail is so important to you, why not run FreeBSD to get that functionality?
Re:Ok, so what's so great about it... (Score:3)
LOMAC is my project, and I was among the NAI Labs contractors working on the NSA's SELinux project for a short while, too. SELinux is indeed an excellent technology. I've found SELinux to be extremely stable - I never had any of the released versions of SELinux crash on me in my (roughly) 6 months of usage.
The NSA's SELinux project and NAI Labs' LOMAC project have different goals. SELinux is designed to provide powerful features like extremely-fine-grained access control and a time-tested highly-general Flask architecture. LOMAC is designed to remain compatible with existing Linux kernels and software, and work without configuration, even at the cost of some features.
So, the LOMAC LKM is completely specialized towards supporting a single, simple, coarse-grained form of access control. However, it can be loaded into unmodified off-the-CD-ROM Linux kernels, and you don't have to configure it to recognize your local users and applications. SELinux provides many more powerful features, but it requires you do some configuration, and to patch your kernel and some of your applications.
It's a tradeoff. Depending on your requirements, you may prefer different choices along the features/compatibility line.
As for the comparison with the immutable flag, LOMAC provides a more flexible solution that allows admins to modify critical files that are immutable to normal users. LOMAC also provides a mechanism to prevent clever attackers from using Trojan horses or input designed to cause buffer overflows to get control of privileged processes.
There's a complete description in the LOMAC manual on ftp.tislabs.com/pub/lomac, if you're curious.
- Tim Fraser, NAI Labs
Re:This is ok but... (Score:1)
Yes, it would be like working with NT.
Long live VNC
--------
Re:Fantastic (Score:1)
--
Re:security wall of silence (Score:1)
real secure systems would fix design problems FIRST (buffer overflows, holes in c libs) and THEN move on to access control and finally end up with audits. audits are the LAST step and not the most vital.
Re:Lomac. (Score:2)
funny stuff
Re:This is definately off topic (Score:1)
Re:Drop in security?/' Holy Grail (Score:2)
Of course drop-in security seems to be a bit of a holy grail that many companies continue to quest for be never achieve. See previous posts on eLiza (IBM's attempt at self-policing networks) and other such things (there is an idea-- a firewall that talks back to the admin...).
I will have to play with this.
This drives us closer to NT/WIN2K security, no? (Score:1)
Re:Oh dear... You linux-heads at it again! (Score:1)
Re:Fantastic (Score:1)
I checked out xMach.org [xmach.org] and did not find any justification for yet another port of BSD.
Why xMach? Why splinter? Why not apply all that energy to making an existing Unix better? Is it hubris? self-promotion? ignorance? NIH?
If I were Microsoft, I would pay people to create yet another port of Unix, and I would sow FUD by saying that version thus-and-so was so lame it couldn't be fixed.
Re:*BSD is dying (Score:1)
Until of course Debian get around to putting out a BSD based debian, then i can see alot of people now using linux taking up using bsd like myself
Re:Lomac. (Score:2)
Re:Ok, so what's so great about it... (Score:1)
I read the document about how LOMAC works, and if I understand it properly, if I installed it on my debian system, `apt-get upgrade` would fail, because the
In fact, it would be impossible to install any software that was downloaded off the web. This is consistent with security, since for all we know the debian mirror I downloaded from has been compromised, but sounds awfully inconvenient.
Is there a good way around this problem? Or is LOMAC just designed to work conveniently on systems (say, debian stable, rather than unstable) in which you don't need to install or upgrade software very often?
Re:Drop in security? (Score:1)
Re:Drop in security?/' Holy Grail (Score:1)
1. Remove network card.
2. Carry to wastebasket.
3. Drop it in.
Re:Ok, so what's so great about it... (Score:1)
Often such physical access in not possible in practical situations.
Re:Drop in security? (Score:1)
Re:Oh dear... You linux-heads at it again! (Score:1)
Problem (Score:1)
Re:.signature (Score:1)
But that's what the BSDL is for. . . (Score:2)
More like Perl tainting (Score:2)
This is much lower-resolution tainting than Perl offers, since entire processes get tainted. This creates a few problems. The designers had to add some gimmickry associated with pipe handling so that you can spawn processes from the shell without tainting the parent shell.
The whole effort is designed to answer the question "Can mandatory security be made liveable?" Highly secure systems with mandatory security have been built, but are painful to use. This system does have some strong properties, and the authors claim it's usable without too much pain. It's thus a good step in the right direction.
Do not use on server boxes (Score:2)
This module is not for you unless it'll be used as a workstation which will not run any servers.
Re:security wall of silence (Score:2)
Take for example a program which is not "part of" OpenBSD, hence not audited. It is suid root, and by manipulating an environment variable you can make it read a tainted file from an unprivileged location, resulting in buffer overflow and root. Lomac, as I understand it, would notice that this privileged process read an unprivileged file and demote the privilege of the process. Hence, no root for the attacker.
Although I agree with you partially; Linux needs more common sense security and less high-tech security addons. I think one reason that NT machines are insecure is that their security model, while admirable, is too complicated.
Re:security wall of silence (Score:1)
Root access from console only? (Score:1)
With a machine in the next room that isn't soo bad. When the machine is 20 minutes away it can be a pain.
"Now, I hope and pray that I will, but, today I am still just a bill"
Re:Ok, so what's so great about it... (Score:1)
Drop-In security, all I need to protect my computer from the evils on the Internet....
They 'set it and forget it (tm)', don't upgrade the server, don't pay attention to security because it is already done. The machine gets 0wn3d by h8x07z with the next security hole.
"Now, I hope and pray that I will, but, today I am still just a bill"
Re:Do not use on server boxes (Score:2)
Thanks for giving LOMAC a shot; I'm sorry you ran into problems. The early versions of LOMAC did prevent remote administration, as you describe. However, LOMAC releases since 1.0.5 provide an exception to allow remote administration via SSH.
- Tim Fraser, NAI Labs
Re:Ok, so what's so great about it... (Score:1)
> I installed it on my debian system, `apt-get upgrade` would fail, because the
This is a good question. Remaining compatible with traditional methods of administration is important to LOMAC. Ultimately, I'd like to have apt-get work with LOMAC just as it does without.
Presently, LOMAC provides a partial solution: there is a program called "lup" you can use to change a level-1 downloaded file (like a
This solution is sub-optimal, because the administrator has to manually bless the
LOMAC has a mechanism for providing this kind of exception. I haven't set it for apt-get yet, but now that you've pointed it out, I'll consider it. Thanks for the feedback!
- Tim Fraser, NAI Labs
Re:Root access from console only? (Score:1)
> if that is true, you won't be able to ssh into your box
Yes, this was a problem with the early LOMAC prototypes. Fortunately, starting with v1.0.5, LOMAC has provided an exception to allow remote administration via SSH.
- Tim Fraser, NAI Labs
Re:Ok, so what's so great about it... (Score:1)
> is there a solution to provide high level access via SSH or something,
Yes, LOMAC releases since v1.0.5 provide an exception that allows remote administration via SSH. The no-remote-administration restriction was a problem in earlier prototypes, though.
- Tim Fraser, NAI Labs
Re:What really pisses me off... (Score:1)
The GPL vs. BSDL debate aside, I'd like to point out that LOMAC does not include TrustedBSD code. However, I've been talking to Robert Watson, TrustedBSD's creator, about porting LOMAC to TrustedBSD's framework sometime after I finish the FreeBSD port. Robert and I both work for NAI Labs; he's presently mirroring LOMAC to help with the slashdot effect.
We'll both be at the Kernel Security Extension BOF at the upcoming USENIX Annual Technical Conference this June. We'll be presenting TrustedBSD and LOMAC papers in the FreeNIX track as well. So, you can come interrogate us there, if you like.
- Tim Fraser, NAI Labs
har har har (Score:1)
Bye.
Does LOMAC need the Clipper chip? (Score:1)
Re:Slashdotted already! (Score:1)
Re:Drop in security?/' Holy Grail (Score:1)
5) Configure system to boot w/o flo1ppy.
6) Carry drive to wastebasket
7) Drop it in.
hey (Score:2)
Re:Drop in security? (Score:2)
See the entry in the Evaluated Products List [ncsc.mil] for the C2 status of NT4 with SP6a and a C2 update. NT4 with SP3 has an E3/F-C2 evaluation from UK ITSEC [itsec.gov.uk].
If you don't already know about these sites, you probably don't want to bother reading the evaluation reports.
Re:hey (Score:1)
However, your question ("why not just chroot jail bind") implies that bind harbors the only exploitable hole in your system. In reality, holes could be in a number of applications besides bind, and it's very hard to know where all of them are. LOMAC automatically applies itself to all processes on your system, so you don't have to identify the dangerous ones before you run LOMAC in order to get protection.
LOMAC also provides some kinds of integrity protection that chroot can't. For example, LOMAC provides integrity protection in cases where the administrator unknowingly executes a Trojan horse with root privilege while doing day-to-day administration tasks. This isn't something chroot is designed to do.
So, defense-in-depth is good. Chroot. Audit your code. Use LOMAC, if you like.
- Tim Fraser, NAI Labs