On 2007-06-21T20:33:11, Pavel Machek <pavel@ucw.cz> wrote:

quoted text
> inconvenient, yes, insecure, no.

Well, only if you use the most restrictive permissions. And then you'll
suddenly hit failure cases which you didn't expect to, which can
possibly cause another exploit to become visible.

quoted text
> I believe AA breaks POSIX, already. rename() is not expected to chang=
e
quoted text
> permissions on target, nor is link link. And yes, both of these make
> AA insecure.

AA is supposed to allow valid access patterns, so for non-buggy apps +
policies, the rename will be fine and does not change the (observed)
permissions.

The time window in the rename+relabel approach however introduces a slo=
t
where permissions are not consistent. This is a different case.

quoted text
> > You _must_ be kidding. The cure is worse than the problem.
> Possibly.

Yes.

quoted text
> > If that is the only way to implement AA on top of SELinux - and so =
far,
quoted text
> > noone has made a better suggestion - I'm convinced that AA has tech=
nical
quoted text
> > merit: it does something the on-disk label based approach cannot ha=
ndle,
quoted text
> > and for which there is demand.
> What demand? SELinux is superior to AA, and there was very little
> demand for AA. Compare demand for reiser4 or suspend2 with demand for
> AA.

SELinux is superior to AA for a certain scenario of use cases; as we ca=
n
see here, it is not superior to AA for _all_ use cases.

quoted text
> > The code has improved, and continues to improve, to meet all the co=
ding
quoted text
> > style feedback except the bits which are essential to AA's function
> Which are exactly the bits Christoph Hellwig and Al Viro
> vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.htm=
l
quoted text
> . I believe it takes more than "2 users want it" to overcome veto of
> VFS maintainer.

A veto is not a technical argument. All technical arguments (except for
"path name is ugly, yuk yuk!") have been addressed, have they not?



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-fsdevel=
" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html