On 2007-06-21T20:33:11, Pavel Machek <pavel@xxxxxx> wrote: > 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. > I believe AA breaks POSIX, already. rename() is not expected to change > 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 slot where permissions are not consistent. This is a different case. > > You _must_ be kidding. The cure is worse than the problem. > Possibly. Yes. > > If that is the only way to implement AA on top of SELinux - and so far, > > noone has made a better suggestion - I'm convinced that AA has technical > > merit: it does something the on-disk label based approach cannot handle, > > 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 can see here, it is not superior to AA for _all_ use cases. > > The code has improved, and continues to improve, to meet all the coding > > 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.html > . 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 -- 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
