Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Security Software Linux

Novell Open Sources AppArmor 14

Crispin Cowan writes "Novell has announced the release of their AppArmor security system into open source. AppArmor is an application security system that confines programs, enforcing that they are permitted to do only what they are supposed to do, and nothing else. AppArmor is an LSM module that is an alternative to SELinux, but arguably much easier to use. Now in open source, AppArmor is included with every SUSE Linux distro, including openSUSE."
This discussion has been archived. No new comments can be posted.

Novell Open Sources AppArmor

Comments Filter:
  • Translation please (Score:5, Interesting)

    by Crayon Kid ( 700279 ) on Wednesday January 11, 2006 @03:26AM (#14444095)
    IRTFA.

    But I suspect most of us will still need someone to put some things in plain English. I even read the "detailed description" and no go. Call me Dumbo.

    *Is it kernel space or userspace?
    *What's with those "3rd party config files"? If we wait for [all the] apps to catch up, good luck. See how "widely" the user home config file spec from FDO was implemented, and that one needs just an effort of good will.
    *Isn't it a bit strange to let a 3rd app specify its own security config on YOUR machine's context?
    *What exactly do they mean by "easy to use"? No, miles long text files where you have to write down what files each program can access are not "easy to use".
    • LSM implies kernel space, but the management would be in userspace. As for the rest, let's just say I'll stick with SELinux.
    • by q.kontinuum ( 676242 ) on Wednesday January 11, 2006 @04:18AM (#14444262)
      *Is it kernel space or userspace?


      I'd guess, some userspace tools to do the setting, but the security (enforcement of those rules) has to be implemented in kernel space


      *What's with those "3rd party config files"? If we wait for [all the] apps to catch up, good luck. See how "widely" the user home config file spec from FDO was implemented, and that one needs just an effort of good will.


      For AppArmor it would already help to do the configuration for the most exposed programs, e.g. mail client, ftp server, browser, etc.


      *Isn't it a bit strange to let a 3rd app specify its own security config on YOUR machine's context?


      Why? Most people install software as root without a blink. The default properties (e.g. does the ftp server run as root or does it get it's own user ID) are set by the package maintainer. People with knowledge can tweak the settings to match their standards, but per default the package maintainer maintained already security relevant default settings. Strange would it be if the user couldn't change the settings anymore.


      *What exactly do they mean by "easy to use"? No, miles long text files where you have to write down what files each program can access are not "easy to use".


      I didn't read everyhing about it, but as far as I got it, easy to use means:

      You can configure a single application without the need of configuring the whole system

      Profiling tools are available to track what an application does, so if You trust Your application for an evaluation period You could build a ruleset from the actions the application was required to perform during the test run

    • by Crispin Cowan ( 20238 ) <crispin@crispinc[ ]n.com ['owa' in gap]> on Wednesday January 11, 2006 @05:42AM (#14444525) Homepage
      I don't understand what is unclear. The detailed description [opensuse.org] spends six paragraphs explaining how and why mediation is done in the kernel and not at other layers. It also goes into considerable detail on how the static analysis and dynamic learning tools mean that you do not have to write out long lists of what files each program can use; the software does that for you. That is what makes it "easy to use."

      You do not have to "wait for all the apps to catch up." Anyone can create a profile for an application, all you need is a decent use case for the application. You do not need to modify the application at all.

      IMHO, it is not so strange that the security policy for an application comse from the provider of the application. Consider that without AppArmor, you are completely trusting the application provider, because the application can do absolutely anything the invoking user can do. Providing an AppArmor profile means that you have an explicit declaration of what the application is permitted to do.

      You can even edit it to suit your taste, if you like. For instance, it annoys the crap out of me that Adobe Acrobat actually supports embedded Javascript inside PDF documents. This annoys me because vendors embed Javascript inside documents that act like web-bugs, reporting back to the vendor each time you open the document! Eww! So the Acrobat profile on my personal workstation has been hacked to not provide access to Javascript libraries to the Acrobat program, thus depriving spyware PDF files of the opportunity to execute and squeel on me.

      Crispin

  • (see Subject)
  • Instead of ad-hoc security sandboxes (jails, chroot, now apparmor) wouldn't it be better to just transition to a managed runtime where all apps get all of this for free? I believe Solaris (and maybe now the Linux kernel) supports some sort of kernel-level filter or instrumentation that can apply a policy on a per-application basis, but it seems like moving to a managed runtime with built-in security sandbox accross the board would be a better idea.
    • > Instead of ad-hoc security sandboxes (jails, chroot, now apparmor) wouldn't it be better to just transition to a managed runtime where all apps get all of this for free?

      You can run your apps under qemu if you want, I however will go with the security module. All those apps are already compiled to the bytecode interpreted by some CPU, so your managed runtime needs to jit compile that as if it were an IL (intermediate language).

      Also, nowadays low-level languages like the intel architecture 32 and amd64 i
  • I think a system like this would be useful for a Trusted Computing (TC - http://en.wikipedia.org/wiki/Trusted_computing [wikipedia.org] ) system on Linux. TC does have some good uses, and having the OS cooperate with Intel's hardware (La Grande - http://www.intel.com/technology/security/ [intel.com] )would be great.

To be awake is to be alive. -- Henry David Thoreau, in "Walden"

Working...