On Thu, Jul 20, 2017 at 6:13 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > On Wed, 2017-07-19 at 17:08 -0400, Paul Moore wrote: >> On Mon, Jul 17, 2017 at 4:06 PM, Andy Lutomirski <luto@xxxxxxxxxx> >> wrote: >> > On Fri, Jul 14, 2017 at 9:46 AM, Stephen Smalley <sds@xxxxxxxxxxxxx >> > > 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, ... > It depends on exactly what the goal is. For conventional security, if you can play evil games and get a privilege to, say, write a file, then SELinux or its policy has failed. If you can play evil games and get execmem, it's not really a big deal. If you're running an app store and trying to completely prevent the execution of unsigned binary code, that's a different story, but it doesn't seem like the existing SELinux policy language is really geared toward this use case.
