[Wolves] Nsa using linux

[Shane M. Coughlan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Simon Morris wrote:
> On 25/08/06, Shane M. Coughlan <shane at shaneland.co.uk> wrote:
>> SELinux and AppArmor are not the same.  AppArmor is less granular and
>> focuses on simplicity for the end user.  SELinux is focused on ensuring
>> that applications act in the way you want them to act.
> 
> Oooh, I'd refute that statement! AppArmor uses a more condensed syntax
> to define the same thing - this doesn't mean that is is less granular.

Well, I'm not convinced AppArmor can scale as well as SELinux.  But you
are quite right.  I made a blanket statement which cannot be empirically
backed up.

<Hits self on head>

However, one example:

==
http://www.bress.net/blog/archives/36-But-our-security-goes-to-11!.html
==
AppArmor comes with a tool that can investigate what a running program
is doing and create a policy based of that. In theory this sounds great,
but it's not without problem. The example policy is for Thunderbird (a
mail client for those of you who don't know).
The important bit here is this:
    capability ipc_lock,
    capability setuid,
Thatt means that for some reason AppArmor has decided that a client side
mail client needs the ability to switch to the superuser (root). It's
likely the result of a bug in Thunderbird. I don't disagree that tools
can help make things easier, but it's rather misleading to claim your
tools are something they are not. Whenever a policy is tool-generated in
this manner, it will require a knowledgeable engineer to interpret the
outcome.
I won't say SELinux is perfect, but I think it's the correct approach
for a hard problem. I would much rather see a comparison of SELinux
versus AppArmor based on technical merit instead of marketing jibberish.
==

Some of the flexibility inherent to AppArmor might actually reduce
security rather than increase it:

==
http://www.linux-magazine.com/issue/69/AppArmor_vs_SELinux.pdf#search=%22SELinux%20vs%20AppArmor%22
==
   AppArmor?s sub-process restrictions
allow you to run, for example, PHP
scripts via mod_php in a context differ-
ent from the context of Apache itself, al-
though both run within the same pro-
cess. The FAQ mentions that this is only
possible with a special version of
Apache with modifications by Novell.
In other words, AppArmor needs to
rebuild, too, from time to time.

  The design of AppArmor has enor-
mous disadvantages: there is nothing to
stop malevolent code injected by an at-
tacker into the PHP context from run-
ning in the Apache context later.
                                                                         ==

Actually, I think
http://www.linux-magazine.com/issue/69/AppArmor_vs_SELinux.pdf#search=%22SELinux%20vs%20AppArmor%22
is a pretty interesting article on the whole.  It's quite biased towards
 SELinux though.

To be fair:

==
http://blog.drinsama.de/erich/en/linux/selinux/2006022802-apparmor-and-selinux.html
==
SELinux has serious deficiencies in documentation and development
community. Almost all the available SELinux documentation is based
around the policy as published by the NSA, which is "superseded by the
reference policy project". This is the policy currently in Debian and
used in the Gentoo SELinux docs - which hasn't received any updates in
months now.
==

Back to my bickering:

==
http://securityblog.org/brindle/2006/04/02/top-down-vs-bottom-up-policy-development/
==
Apparmor is actually designed for application policies only. This severe
limitation in its implementation makes it unable to implement many
security models. Unfortunately this was a design decision in the
mechanism itself, rather than building a general mechanism and making
the policies flexible enough to implement this limited access control or
if the user chooses, something more complex.
==
same article...slightly *above* AppArmor text...
==
In SELinux we take a different approach, bottom-up if you will. The
SELinux reference policy has pre-written policies for many applications
- - 177 at the time of this writing. The policies are written and analyzed
by security professionals and unexpected behavior is tracked down for
the cause. If it turns out the permission was unnecessary for normal
application usage the permission can be dontaudited instead of allowed.
This is only possible if the policy development and analysis is done on
a per-application basis where interactions with other applications as
well as all resources used by that application can be studied and
analyzed in detail. When application configurations change the effects
can be observed and added to the affected application policies without
disturbing the rest of the system.
==

Shane

- --
Shane Martin Coughlan
e: shane at opendawn.com
m: +447773180107 (UK) +353862262570 (Ire)
w: www.opendawn.com
- ---
OpenPGP: http://www.opendawn.com/shane/publickey.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRO808NwG3M95JPpzAQhX5gQAvVzhzlzVL13z/HrFAO/pU7DTmYEeUU96
lf51JlaCrgTlFbldFujyBIkWJCl7mhgYIxXu/eOmsBDorJeHQtziprqBB60kjV/O
Y6SOuvHx/9lQ6BULkOWr/XcN7Co7dbb8eMZNbLYl0FGSqDaSRVlpn9eqTcEeChdf
uE7VC/6ByMM=
=C97G
-----END PGP SIGNATURE-----