On Wed, 2017-07-19 at 17:08 -0400, Paul Moore wrote: > On Mon, Jul 17, 2017 at 4:06 PM, Andy Lutomirski <[email protected]> > wrote: > > On Fri, Jul 14, 2017 at 9:46 AM, Stephen Smalley <[email protected] > > > wrote: > > > > At the risk of commenting on SELinux in general: > > > > > There is no way to clone all allow rules from > > > descendants to their ancestors in policy currently, and doing so > > > would > > > be undesirable even if it were practical, as it requires leaking > > > permissions to objects and operations into ancestor domains that > > > could > > > weaken their own security in order to allow them to the > > > descendants > > > (e.g. if a descendant requires execmem permission, then so do all > > > of > > > its ancestors ... > > > > In my mind, permissions like execmem aren't in the same category as > > normal permissions. execmem is the right to do something that > > opens > > the subject to compromise, not the right to do something to an > > object > > that needs protection. Maybe execmem should be exempt from > > typebounds. > > I just realized that this got lost in the rest of the discussion ... > > It's worth nothing that from a practical point of bounded type > transitions aren't likely going to be the solution that will likely > be > used to solve this current systemd problem (see the rest of the > thread). > > However, I understand you were speaking in general terms, and while > there may be some merit to your suggestion, that would be quite a > deviation from how things work at the moment and unless typebounds > takes off (which I am beginning to doubt will happen outside a few > special domains) I'm not sure it is worth the effort and headache.
I also don't see how execmem is fundamentally different than the other examples I gave in the patch description; there would still be the problem of leaking execute access to files, read to symlinks, ...
