Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
News

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.
This discussion has been archived. No new comments can be posted.

NAI Labs releases LOMAC, a kernel security extension

Comments Filter:
  • Is this really "drop in security?" Can securing a box really be this easy? Does anyone have experience with this program that can talk about how secure it is? Should I switch from OpenBSD?

    (oh, and I think fp, but I'm not sure)

  • I'm glad to see Linux stuff catching up with the amount of security technology that has been out there in the world. If only RWatson would port jailng to Linux, it'd be probably one of the best platforms for security, since so much cool stuff does tend to get developed. Fad or not, the attention and dollars that are put into Linux make it worthwhile.
    --
  • Commercial software rhetoric.
    --
  • by idistrust ( 66924 ) on Friday May 11, 2001 @12:58PM (#229093) Homepage
    I don't think that anything can be drop in security. Somebody's GOT to know what they're doing. Back in the olden days I messed around with Bastille's "drop-in-security" and ended up with a foobar'd system that I couldn't even get into. That's not security, that's just uselessness.

    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.

  • This is great news for the linux community. It's interestingthat commercial software vendors (vs OSS vendors) seem to think things like this for linux are not viable. Strange. Seems to work for me. Security by closed source is a variant on security through obscurity and we all know what a falacy this is.

    Great Work Guys!

    --CTH

    --
  • but wouldn't it be great if companies, especially in the same sector not use acronyms that have already been defined?
    i.e. MAC address
    now Media access control.

    Maybe some standards would be great.

    The slashdot 2 minute between postings limit:
    Pissing off hyper caffineated /.'ers since Spring 2001.

  • RSBAC (http://www.linuxsecurity.com/feature_stories/feat ure_story-2.html)is better. We need to make an RSBAC module that is this simple to implement. That would be a *really* good thing. Also if I understand the link right this would by default make remote admin tasks impossible and that would suck.
  • Yeah, MS has a C2(I thinK) rating for a specific config of NT. it's a bunch of BS because that config doens't include network access
  • If they pretend to audit the code, can they call it secure?
    --
  • by Lord of the Files ( 10941 ) on Friday May 11, 2001 @01:12PM (#229099) Homepage
    The author gave a talk at our lug last week. This is my understanding of what he said.

    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 /etc, /usr, and anything else only root should be mucking with. Level 1 is everything else. Programs begin running at level 2, and are demoted to level 1 as soon as they read a level 1 file (or from the network which is considered level 1).

    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.
  • by Anonymous Coward on Friday May 11, 2001 @01:12PM (#229100)
    Am I missing something, but how does this differ from giving every critical file the system immutable flag (under BSDs), then when the box has come up nicely you lift the security level, to something that enforces the chflags and doesn't let you change them?

    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?
  • If they pretend to audit the code, can they call it secure?

    Since he pretends to be Theo, they can pretend to audit the code. :)
  • Saying that all software is equal when it comes to security is not Open Source rhetoric. It's sensibility.
    --
  • by Matt2000 ( 29624 ) on Friday May 11, 2001 @01:15PM (#229103) Homepage

    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).
  • Here's the text, unslashdotted. (what sucks is- I'm probibally going to get karma for this, though it dosen't require much effort or creativity. Alas, this is Slashdot =-P ) From owner-lomac-users Fri May 11 12:50:15 2001 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02776 Fri, 11 May 2001 12:48:21 -0400 (EDT) X-Authentication-Warning: bucky.gw.tislabs.com: tfraser owned process doing -bs Date: Fri, 11 May 2001 13:12:12 -0400 (EDT) From: Tim Fraser X-Sender: tfraser@bucky.gw.tislabs.com To: lomac-users@lists.tislabs.com cc: tfraser@tislabs.com, rwatson@tislabs.com Subject: LOMAC v1.1.0 on FTP site Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lomac-users@lists.tislabs.com Precedence: bulk Hi! LOMAC v1.1.0 is now available for download at: ftp://ftp.tislabs.com/pub/lomac/lomac-v1.1.0.tar.g z Changes in LOMAC v1.1.0 since the last release (v1.0.5): o Restructured argument handling to avoid time-of-check/time-of-use errors. o Added mediation on the addition and removal of directory entries. o Changed all -EPERM ("operation not permitted") return values to the proper value: -EACCES ("permission denied"). Summary of Changes in LOMAC v1.1.0 since the v1.0.0 release: The 1.1.0 release improves LOMAC's protective functionality and makes LOMAC easier to use. The 1.1.0 release features restructured system call argument handling to addresses the time-of-check/time-of-use problems present in the 1.0 release, and provides new mediation on directory modification operations. With the 1.1.0 release, LOMAC's default configuration allows the mounting of remote NFS filesystems and the use of SSH for remote administration. - Tim
  • Yeah, MS has a C2(I thinK) rating for a specific config of NT. it's a bunch of BS because that config doens't include network access

    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.

  • errr...the MAC in MAC address stands for media access control
  • I love the idea of any extensions or utilities to improve security or speed, however I dont think there can ever be a one step solution to either of these issues.

    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.
  • by Tim Fraser ( 16824 ) on Friday May 11, 2001 @01:34PM (#229108) Homepage
    Hi!

    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
  • The idea behind LOMAC is that newbies can use it, without it interfering overly much with their normal usage. With one or two exceptions non-root users shouldn't even notice that this has been added.

    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.
  • Your information is old and mine will be incomplete sadly to say. NT did get C2 certified on a network under 6 configurations iirc. I remember checking out the story on the MS website and seeing that the configurations would be posted at a later date. After a month or two, I gave up trying to read about these 6 configurations. I assume they are documented somewhere.

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


  • If only RWatson would port jailng to Linux,

    Nothing stopping you from porting it.

    But if jail is so important to you, why not run FreeBSD to get that functionality?
  • by Tim Fraser ( 16824 ) on Friday May 11, 2001 @02:13PM (#229113) Homepage
    Hi!

    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
  • >>Also if I understand the link right this would by default make remote admin tasks impossible and that would suck.

    Yes, it would be like working with NT. :)
    Long live VNC

    --------
  • I so run FreeBSD, in fact I am avidly Anti-Linux. I was just saying this is a Good Thing(tm) for the Linux community. Can't one say as a third party that something is "good"?
    --
  • your "core basics" are a bit off. auditing is simply pointless at the present time. the fact that the C library functions are full of holes is what should be fixed. its ridiculous that using a perfectly simply function like sscanf results in security holes.
    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.
  • Sort of reminds me of the LOTHAR sketches on Saturday night live, Loooothar of the hill people... Loooothar...

    funny stuff
  • All acronyms are taken ;) MAC has 73 meanings [acronymfinder.com] according to acronymfinder.com [acronymfinder.com].
  • Drop in security is impossible. However, I do agree that these developments will continue to make Linux and other OSS software very attractive to lage companies.

    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.

  • The basic NT security *model* is excellent (particulary compared to the Unix owner/group/world model). It is the *implementation* of that model which sucks rocks. If it actually worked as designed, NT's security would be impressive. Compare this to OpenBSD. OpenBSD may be based on a dated security model, but it is a ROCK SOLID implementation of that model. It dosn't take a rocket scientist to figure out which one to use where security is critical.
  • Oh, come on, it isn't a troll, it is humor! :)
  • 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.

  • > For all practical purposes, *BSD is dead.

    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
  • Actually, Lomac reminds me more of "Lojack", the "anti-theft deteriant system".
  • I have a question (perhaps off-topic on this post).

    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 .debs would have been downloaded over the network.

    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?
  • No, they're only certified if Microsoft doesn't reveal how to do it to any customers. :-)
  • It is possible.

    1. Remove network card.

    2. Carry to wastebasket.

    3. Drop it in.
  • Okay, so, for the 95% of System adminning that is done over the network, is there a solution to provide high level access via SSH or something, so that the box need not be physically accessed?

    Often such physical access in not possible in practical situations.
  • C2 is a very old standard from the "orange book" which was dropped by the people who developed it because it was lacking way too much. That didn't keep someone else from picking it up and deciding it was a good idea. I guess its beter than nothing.
  • Exactly right... er. I mean. HEY!
  • I encountered quite bit of instability (say hello to my friend kernel panic!) running this on 2.2.19 with the openwall [openwall.com] patches [openwall.com] installed. I don't know who is being naughty, but I'd guess LOMAC since Solar Designer has a reputation for being a wonderful coder. OH... and it fucked up my system so getty thought it was still booting and only root could login. Promising though... when these issues are fixed I'll definately run it on my server. Good work. I'd like to see this (and ACLs) ported to OpenBSD also... I'm thinking about making an "ideal" armored server for fun next year and these would be cool features.
  • Oh, so he plays Mao
  • We just had a debate about this. Some folks say that BSDL is too open, but there's tons and tons of folks who say that only the BSDL is truly free. Well, this the natural consequence of that freedom; of using BSDL-- someone can relicense your code (hell, they can make it closed source). If you weren't prepared for that, if it's an unacceptable possibility, then the BSDL, was not the right license in the first place.
  • Actually, this works more like Perl's "taint" feature. The basic idea is that everything has an integrity level, and the goal is to prevent information flow upward in integrity level. Processes drop in integrity level if tainted by reading lower-integrity data. They then can't write higher-integrity data. This keeps trojan horses, viruses, and such at the low integrity level. They can still cause trouble to data down there, but not to the higher integrity data. Of course, anything you download and install is stuck at low integrity level. But for many users, that's OK.

    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.

  • I just tried using LOMAC on a box that was at a NOC remotely. It locked me completely out of my box, no way of connecting or anything. I'm contacting the NOC at this moment to lead them through de-installation.

    This module is not for you unless it'll be used as a workstation which will not run any servers.
  • but why should I run an insecure OS then download an add-on solution, when I could just download OpenBSD for hardcore security?
    OpenBSD does not protect against user error. Like any Unix, it's a springloaded trap - one false move and you've given you're privileges to an attacker. One false move by a root process and the attacker has root. Lomac is clearly trying to prevent this.
    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.
  • Did you perhaps see the part where he says "Next Week Why OpenBSD Is More Secure Than Linux". I think you might have waited until after you could evaluate what he said for the other side.
  • If I understand the division of integrity on the system. All processes that handle remote connectivity are in the low integrity group. If that is true, you won't be able to ssh into your box and 'su' to root to change config files in /etc. Or even restarting apache,bind,qmail ...

    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"

  • The problem with this thinking is the noobs. If they see a nice shrink wrapped product at their local computer store they will buy it.

    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"

  • Hi.

    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
  • Hi!

    > I installed it on my debian system, `apt-get upgrade` would fail, because the .debs would have been downloaded over the network.

    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 .deb) to a level-2 file. (The LOMAC manual describes how lup is implemented to avoid providing a backdoor to malicious users.)

    This solution is sub-optimal, because the administrator has to manually bless the .deb's before installation. A better solution might be to set an exception for the apt-get program, stating that anything apt-get downloads is automatically safe to put at level 2. This should allow apt-get to run without manual intervention, as it does without LOMAC.

    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
  • Hi!

    > 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
  • Hi!

    > 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
  • Hi!

    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
  • I just thought it was funny that I work for a company called LOMAC Information Systems. har har har.

    Bye.

  • This is the same NAI that teamed up with the National Security Agency on SE Linux? Slashdot needs a comedy icon for this story.
  • You're Right. The dumbass that I am forgot that magical thing known as formatting. And later examinations suggest that I was being stupid, and it was MODF(My Own Damn Fault) that I was unable to view the webpage. Apologies.
  • 4) Remove floppy drive

    5) Configure system to boot w/o flo1ppy.

    6) Carry drive to wastebasket

    7) Drop it in.
  • by apofex ( 451729 )
    So this module would do things like make a exploitable bind hole useless? Why not just chroot jail bind and run something like openbsd with bind 4 (which is not as nasty as bind 8 and the evil swiss cheese bind 9) ??? Just an opinion :)
  • 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.

  • Certainly, running bind in a chroot/jail environment is a good idea. With LOMAC or without, it's always wise to have defense-in-depth. It's also a good idea to run only carefully audited code whenever possible, for the same reason.

    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

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...