On 2007-06-21T15:42:28, James Morris <jmorris@namei.org> wrote:

quoted text
> > A veto is not a technical argument. All technical arguments (except=
 for
quoted text
> > "path name is ugly, yuk yuk!") have been addressed, have they not?
> AppArmor doesn't actually provide confinement, because it only operat=
es on=20
quoted text
> filesystem objects.
>=20
> What you define in AppArmor policy does _not_ reflect the actual=20
> confinement properties of the policy.  Applications can simply use ot=
her=20
quoted text
> mechanisms to access objects, and the policy is effectively meaningle=
ss.

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.

quoted text
> You might define this as a non-technical issue, but the fact that App=
Armor=20
quoted text
> simply does not and can not work is a fairly significant consideratio=
n, I=20
quoted text
> 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

--=20
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N=FCrnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wil=
de

-
To unsubscribe from this list: send the line "unsubscribe linux-securit=
y-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html