linux-kernel - Re: AppArmor FAQ

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1177016615.27654.293.camel@moss-spartans.epoch.ncsc.mil>
Date:	Thu, 19 Apr 2007 17:03:35 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	David Wagner <daw-usenet@...erner.cs.berkeley.edu>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: AppArmor FAQ

On Thu, 2007-04-19 at 20:08 +0000, David Wagner wrote:
> 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.

First, I think there is practical value in providing confidentiality
control on the overt channels, even if covert channels remain.  We have
to start somewhere.

Second, information flow is not just a confidentiality issue - see my
other email.  It is quite important as well for integrity, and integrity
corruption in order to assume control over a privileged subject or trick
it into abusing its power can be done solely via a data channel - it
doesn't require explicit flow of authority.

Lastly, if you want to judge AA as a jail mechanism, I think you'll find
it fails there too.  So where does that leave it?  An easy-to-use yet
inadequate solution for MAC or jail.

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/