On 2007-06-21T15:42:28, James Morris <jmorris@xxxxxxxxx> wrote:
> > A veto is not a technical argument. All technical arguments (except for
> > "path name is ugly, yuk yuk!") have been addressed, have they not?
> AppArmor doesn't actually provide confinement, because it only operates on
> filesystem objects.
>
> What you define in AppArmor policy does _not_ reflect the actual
> confinement properties of the policy. Applications can simply use other
> mechanisms to access objects, and the policy is effectively meaningless.
Only if they have access to another process which provides them with
that data.
And now, yes, I know AA doesn't mediate IPC or networking (yet), but
that's a missing feature, not broken by design.
> You might define this as a non-technical issue, but the fact that AppArmor
> simply does not and can not work is a fairly significant consideration, I
> would imagine.
If I restrict my Mozilla to not access my on-disk mail folder, it can't
get there. (Barring bugs in programs which Mozilla is allowed to run
unconfined, sure.)
If the argument is that AA provides somewhat different semantics - and
for some use cases "weaker" ones - than SE Linux, that is undoubtly
true. However, it appears to be the case that those are the differences
which make AA's model different from SELinux as well, so it appears a
trade-off best left to the admin / user to choose what fits their needs
best.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
