[ubuntu-hardened] targeted policy broken?

Crispin Cowan crispin at novell.com
Tue Sep 19 14:50:55 BST 2006


jeff.schroeder2 at us.army.mil wrote:
> From: Crispin Cowan <crispin at novell.com>
> Subject: Re: [ubuntu-hardened] targeted policy broken?
>   
>> Try AppArmor http://www.linuxalert.org/ubuntu/apparmor/
>> It is really much easier.
>>     
> Easier != better...
>   
"Better" depends on your purpose. But, as I'm about to argue :) AppArmor
is better than SELinux for most Linux user's purposes.

> Longterm, ubuntu will likely be moving towards
> SELinux as SELinux will be in Debian. 
> http://blog.drinsama.de/erich/en/linux/selinux/2006091301-selinux-in-etch
>   
I approached Ubuntu with the idea of including AppArmor in the Ubuntu
distro ahead of Debian, because both Ubuntu and AppArmor have a focus on
ease of use. Clearly it is time for me to approach Debian as well.

AppArmor and SELinux should be able to co-exist in a distro. SELinux has
a lot of dependencies that a pile of packages have the SELinux patches
applied, and AppArmor is oblivious to whether these patches are present
or not. However, you cannot install SELinux and AppArmor on the same
machine; the two modules will not fit into one kernel.

> AppArmor is a great idea with a bad architecture.
>   
"Bad architecture" is a matter of opinion. Many have argued that
SELinux's architecture that requires over 100,000 lines of security
policy to get started is a bad architecture. SELinux is developing tools
to help you deal with its baroque security policy, but that doesn't
address the fundamental problem that the security policy that is being
enforced is far beyond human comprehension, and thus in a real sense is
no security policy at all.

> Stuff like information assurance just isn't
> possible with it.
I question whether information assurance is possible with SELinux.

The most common information assurance property desired by military
organizations is MLS: a policy of "no read up/no write down" applied
universally to all data and processes. However, SELinux can't really do
MLS, which is why RH, Tresys, and TCS are building an MLS solution to
run in parallel with SELinux. Similarly, Novell and Argus intend to
provide a solution that combines the practical security of AppArmor with
the information assurance of MLS 
http://www.echannelline.com/usa/brief.cfm?item=13547

>  Why would I want an easy to use
> tool that isn't as flexible when there are easy to
> use wrappers on the more difficult yet superior one?
>   
Well, you have 2 choices:

    * Use AppArmor, and you get easy-to-use security for preventing
      intrusions into common configurations like network servers and
      workstations.
          o Add MLS if you want information assurance.
    * Use SELinux, which forces you to deal with the complexity of a
      label-based security policy mechanism, but doesn't actually
      deliver information assurance.
          o Add MLS if you want information assurance.

The "tool wrappers" that SELinux is adding are fancy ways to enable and
disable fragments of pre-defined policy. What they don't deliver is:

    * Easy to *create* policy, so that you can protect the 3rd party
      applications that your organization purchased, and the home-grown
      applications that your organization wrote in house or had contracted.
    * Comprehensible policy, so that you can look at it, understand it,
      and decide if it is good enough to satisfy your needs.

AppArmor does deliver these things.

> Besides, with seedit, the policy language syntax was
> copied from Apparmor in large parts:
> http://seedit.sourceforge.net/ note that sf is dead right now.
>   
Leaving out only the important part: dynamic binding.

The SEEdit system is a remarkable work, compiling a syntax that looks
almost exactly like AppArmor into SELinux labels and policies. To
enforce such a policy, it does a massive re-label of your file system.
If you make one change to any profile, you have to re-label the *entire*
file system, because of the transformation that SEEdit has to do to AA
rules to turn them into labels. Worse, because it depends on labels, the
policy is only effective on files that existed at the time you loaded
the policy: any *new* files don't get the right label, and so the policy
doesn't work right.

In a metaphorical sense, SELinux is the Haskell of security policy: type
safe, statically analyzable, and hard to use. AppArmor is Ruby: similar
safety, but dynamically evaluated (ability to embed wildcards like * and
[] in policy) and thus much easier for system administrators to live with.

> Software like setroubleshoot also makes it
> much easier to use SELinux:
> http://fedoraproject.org/wiki/SELinux/setroubleshoot
> Does AppArmor have anything similar integrated into
> yast? I've worked on SLES9 SP3, but never SP4 with
> AppArmor and am curious to know.
>   
AppArmor has had this kind of tool from the beginning. If there is ever
a problem with policy, run either the "update profile wizard" in YaST,
or "logprof" from the command line, and it prompts you to allow events
that have been blocked, and update policy accordingly. More over, the
events logged when policy blocks an access make it obvious what to do to
fix the policy with a text editor if that is your preference.

> Are there plans on adding the ability to do
> information assurance in later versions of Apparmor?
> If not, why?
>   
Per above, our hard core information assurance plan is to stack AppArmor
with the Argus MLS solution
http://www.echannelline.com/usa/brief.cfm?item=13547

There are, of course, plans to add lots of other features to AppArmor,
but they are more about further improving intrusion prevention and ease
of use, rather than information assurance per se, because Linux users
mostly care a lot more about intrusion prevention and ease of use than
they do about information assurance.

And AppArmor is an open source project. If anyone thinks it needs
something, join http://forge.novell.com/mailman/listinfo/apparmor-dev
and help us work on it.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes




More information about the ubuntu-hardened mailing list