[apparmor] some urgent questions

[John Johansen]

On 02/13/2011 07:13 AM, alexofen at gmail.com wrote:
> Hi everybody and people enthusiastic about system security,
> 
> let me right away "beg you pardon" for directly asking some question.
> This is  because I have NOT found some conclusive answers by browsing the archives.
> ANY help and comment and hint is appreciated.
> 
> 
> (1) concurrency vulnerability and Apparmor(AA)?
> ->your opinion, is AA safe against vulnerability arrising from execution concurrency in Multiprocessor environments?
> www.cl.cam.ac.uk/teaching/0809/Security/ <http://www.cl.cam.ac.uk/teaching/0809/Security/>*concurrency*.pdf - gives a good introduction to this tread.
>  
It should be within the limits of Linux and the LSM, if it isn't its a bug.

> (2) What is the deal with the complain(I), enforced(II) , "not-yet-enabled"(III) states a executable can be in?
> So to say a root executed executable not having a profile is allowed everything, right?
> Im a sorry for this stupid question, but as I understand AA is not build according to the
> "everything that is not exprlecitely allowed is forbidden" but rather
> "everything that is not exprlecitely forbidden is allowed", true?
No, and yes.

AppArmor allows for partial or gradual deployment (partial confinement), where not
every task in the system is confined.  This would be the not everything that is not
explicitly forbidden is allowed, as the admin must define the confinement for
anything that is confined.  This allows an admin or distro to do a risk reward
analysis and decide what their policy should look like.  There is no question that
choosing partial confinement is less secure than doing a total system confinment.

Once an admin chooses to confine something AppArmor uses white listing, that is
everything the is not explicitly allowed is forbidden.

> 
> (3) Paranonia, do you think the LSM /security part of the linux kernel is "watched" and regularily audited to not
> have a NSA , secret service backdoor? This more general is a concern I am not having any idea to address because
> only by being "open" the source does not manditorily need to have some people with "good intentions" watching/checking it?
> Actually I expect most code not to be audited and feel at loss to the "volume" making it impossible to check it myself.
> any suggestions here?
> 
The code is audited to a degree, every patch that goes in is reviewed and signed
off by multiple people.  The LSM portion of the kernel doesn't have a backdoor, it
is a very simple set of hooks.  The security projects based on top of it are
much more complicated, and I can only vouch for AppArmor not having a back door
but I don't believe that selinux, smack, nor Tomoyo have one either.  I have
been in all of these projects code and there is certainly nothing obvious but
I don't know them intimately.

If you are unsure you either need to audit the code yourself, or determine if
you trust the people involved in a project.

Now if the question had been, is the LSM perfect or is it possible to introduce
errors into the kernel that circumvent the LSM, and are these patches audited
for security.  The answers would be no, yes, and sort of.  The LSM certainly
could be better (see grsecurity for some good arguements against it), and
changes with in the kernel can and do change the position or timing of security
barriers, and people making and reviewing the changes don't always see or
understand the security implications.

Mistakes happen (look for kernel CVEs), the kernel isn't perfect, there has
been only one system that I am aware of that was mathematically provably
perfect, and that is with the assumption that the hardware, and compiler
where perfect, and its set of limitations made the system pretty much useless.


> (4) the Apparmor in Ubuntu 10.10 regular install and its profiles are not "very develloped" right?
Define developed.  It certainly has a limited set of profiles and they are tuned
for the base install system.  If you make changes to the system, whether changes
to default configuration or installing new packages it is possible that you will
have to update/modify the policy.

Now if by developed you mean they cover only a few services, then yes that could
be seen as not very developed.  However it must be viewed from the risk/reward,
resources pov.  Delivering a rigidly locked down system is not in Ubuntu's
interest as a distribution, as it provides for a poor user experience and would
drive people to other distributions.  Nor does their security team have the
resources to develop comprehensive policy for every configuration, or service
out their.  They have chosen to develop policy that targets higher risk
applications, and that it won't break most users with common configurations.
Even without choosing to confine more services you could choose to tighten the
policy for a given configuration.

Is this decision sane?  To some people no, to others its the only sane thing
to do.  It will all depend on your goals resources, and pov.  I think most
people can agree however, assuming there are no bugs, that it is as good as
and probably better than not having it (yes I am aware of arguments to the
contrary and I won't even bother arguing with them anymore).

> Maybe somebody can comment on this, it would help me evaluate if what I see on a ordinary Ubuntu install is already safe?
> I actually do not think so as I would doubt the distributors sacrificed "problem-free-delployment-distro" for less safe. Hence
> not very harsh rules to not risk "problems". Any comment would help
> 
Define safe, I can define safe in such a way that no distribution would pass. As
I have said above and you intoned at, Ubuntu has made a choice about how best to
deploy AppArmor for them given their resources.  This may or may not meet your
needs, from your questioning, I doubt it.

You can deploy AppArmor in a more strict fashion than Ubuntu does, or you can
look at other distros, security projects or operating systems.  For example you
could choose to use selinux on Ubuntu, or you could use RedHat or you could
choose grsecurity. Each system has advantages and disadvantages, and I can't
really tell you which is the best for you, or anyone else, as it will depend
on skill level, time, resources, security goals, user base, etc.