On 04/28/2016 09:15 AM, Daniel J Walsh wrote: > > typebounds unconfined_t docker_t; # docker_t is an unconfined domain > > typebounds docker_t spc_t; #spc_t is an unconfined domain > > typeboulds docker_t docker_lxc_net_t; > > > docker, rkt, systemd-nspawn, runc are all executing > setexeccon(svirt_lxc_net_t) > > For container domains. > > Everything works fine until I turn on expand_check in semanage.conf, > which we have been asked to do in Rawhide. > > > Attached is the current Rawhide docker policy. And here is the output > from semodule -i before it crashes, with a segfault. > > > Had to add this rule to make it a little quieter, which is caused by a > rule in policy that says we allow all daemons to connecto spc_t; > > gen_require(` > type unconfined_t; > attribute daemon; > ') > > allow daemon unconfined_t:unix_stream_socket connectto; > > > Why does typebounds care about when a domain is the target of an access, > I think it should only remove options when it is the source. > > Otherwise we end up having to loosen the policy to make this work. > > As long as docker_t does not have any more "allow docker_t" rules then > "allow unconfined_t", shouldn't this be ok? > > It seems that some or the optional code blocks are causing problems also. I agree that typebounds is not very usable in its current form, but I'm not entirely clear on how to fix it. Dropping the target bounds logic is possible; it was actually implemented a while back by KaiGai (see the archives) but reverted because of a side effect on /proc/pid file access. Without the target bounds logic, you had to allow the parent domain to access all child domains' /proc/pid files in order for the child to access their own. That however could be worked around in policy, so possibly we could revive those patches. However, I don't think that solves all of the problems. For example, even with source bounds, I can't allow a child permissions to self or to its entrypoint file type or to its tmp file type without allowing those permissions to the parent, which may unnecessarily escalate the privileges of the parent or expose the parent to risk. We might need more semantics in the policy about inter-type relationships in order to truly evaluate bounds in a manner that permits such usage. Patches/proposals welcome. The other approach would be to use fork()+setcon()+execve() rather than fork()+setexeccon()+execve() in the callers. Then you aren't subject to typebounds at all (NNP only restricts exec-based transitions). _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
