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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
