Re: AppArmor FAQ

[daw@cs.berkeley.edu (David Wagner)]

Stephen Smalley  wrote:
>Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM
>Vol 16 No 10) means information flow control, which you have agreed
>AppArmor does not and cannot provide.

Right, that's how I understand it, too.

However, I think some more caveats are in order.  In all honesty,
I don't think SELinux solves Lampson's problem, either.

It is useful to distinguish between "bit-confinement" (confining the
flow of information, a la Lampson) vs "authority-confinement" (confining
the flow of privileges and the ability of the untrusted app to cause
side effects on the rest of the system).

No Linux system provides bit-confinement, if the confined app is
malicious.  AppArmor does not provide bit-confinement.  Neither does
SELinux.  SELinux can stop some kinds of accidental leakage of secrets,
but it cannot prevent deliberate attempts to leak the secrets that are
known to malicious apps.  The reason is that, in every system under
consideration, it is easy for a malicious app to leak any secrets it might
have to the outside world by using covert channels (e.g., wall-banging).
In practical terms, Lampson's bit-confinement problem is just not
solvable.  Oh well, so it goes.

A good jail needs to provide authority-confinement, but thankfully,
it doesn't need to provide bit-confinement.  I don't know enough about
AppArmor to know whether it is able to do a good job of providing
authority-confinement.  If it cannot, then it deserves criticism on
those grounds.

Often the pragmatic solution to the covert channel problem is to ensure
that untrusted apps are never given access to critical secrets in the
first place.  They can't leak something they don't know.  This solves the
confidentiality problem by avoiding any attempt to tackle the unsolvable
bit-confinement problem.

Note that the problem of building a good jail is a little different from
the information flow control problem.