On 07/27/2016 12:52 PM, Daniel J Walsh wrote: > > > On 07/27/2016 11:08 AM, Stephen Smalley wrote: >> On 07/27/2016 10:14 AM, Daniel J Walsh wrote: >>> We are now seeing breakage on entrypoint. >>> >>> >>> If I have a less confined domain and I want to allow unconfined_t to >>> transition to it, the compiler and the kernel eliminate entrypoints calls. >>> >>> unconfined_typebounds(svirt_lxc_net_t) >>> >>> Causes thousands of these errors. >>> >>> (allow svirt_lxc_net_t ccs_exec_t (file (entrypoint))) >>> <See previous> >>> (allow svirt_lxc_net_t canna_initrc_exec_t (file (entrypoint))) >>> <See previous> >>> (allow svirt_lxc_net_t canna_exec_t (file (entrypoint))) >>> <See previous> >>> (allow svirt_lxc_net_t callweaver_initrc_exec_t (file (entrypoint))) >>> <See previous> >>> (allow svirt_lxc_net_t callweaver_exec_t (file (entrypoint))) >>> <See previous> >>> (allow svirt_lxc_net_t calamaris_exec_t (file (entrypoint))) >>> <See previous> >>> (allow svirt_lxc_net_t cachefilesd_exec_t (file (entrypoint))) >>> <See previous> >>> (allow svirt_lxc_net_t bumblebee_exec_t (file (entrypoint))) >>> <See previous> >>> >>> Since svirt_lxc_net_t can be entered via an exec_type. But unconfined_t >>> can not. I think this access should be treated like a target also. >>> >>> IE Ignored, I don't want to have to allow unconfined_t or docker_t to be >>> able to be entered by all of the domains that svirt_lxc_net_t could be >>> >>> entered from. >> First question: Why does svirt_lxc_net_t need so many entrypoints? >> Optimally each domain would only have a single entrypoint type, for the >> executable used to initially enter that domain. >> >> Regardless, the correct way to handle this situation is to define a >> typebounds on the _exec_t types too, e.g. >> typebounds unconfined_exec_t ccs_exec_t; >> will cause the first rule above to pass as long as you have: >> allow unconfined_t unconfined_exec_t:file entrypoint; >> in your policy. >> >> However, you'll need to do this for all of the _exec_t types that are >> entrypoints for your domain. >> >> This was case #2 in the typebounds logic in my kernel patch description: >> 2. If we have: >> typebounds A B; >> typebounds A_exec B_exec; >> then: >> allow B B_exec:file <permissions>; >> will satisfy the bounds constraint iff: >> allow A A_exec:file <permissions>; >> is also allowed in policy. >> >> This is essentially the same as #1; it is merely included as >> an example of dealing with object types related to a bounded domain >> in a manner that satisfies the bounds relationship. Note that >> this approach is preferable to leaving B_exec unbounded and having: >> allow A B_exec:file <permissions>; >> in policy because that would allow B's entrypoints to be used to >> enter A. Similarly for _tmp or other related types. >> >> _______________________________________________ >> 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. >> >> > Reason for container domains to be use exec_type entrypoints was policy > was originally written to allow you to start a container on any > executable in /usr. > > Basically we are doing > > runcon -t svirt_lxc_net_t /usr/bin/httpd Do you still need that or is there a common entrypoint now (even if it is just a script)? > > Can't do > typebounds unconfined_exec_t exec_type; > > ====================== > policy_module(mypol,1.0) > > gen_require(` > type svirt_lxc_net_t; > attribute entry_type; > type unconfined_exec_t; > ') > unconfined_typebounds(svirt_lxc_net_t) > typebounds unconfined_exec_t entry_type; > ======================== > > # make -f /usr/share/selinux/devel/Makefile > Compiling targeted mypol module > /usr/bin/checkmodule: loading policy configuration from tmp/mypol.tmp > mypol.te:9:ERROR 'type entry_type is not declared' at token ';' on line > 3257: > > typebounds unconfined_exec_t entry_type; > /usr/bin/checkmodule: error(s) encountered while parsing configuration > /usr/share/selinux/devel/include/Makefile:154: recipe for target > 'tmp/mypol.mod' failed > make: *** [tmp/mypol.mod] Error 1 Yes, checkpolicy presently only supports specifying an individual child type for the type bounds. That said, I don't think it would be hard to extend checkpolicy to support specifying an attribute for the child type (but not the parent - that has to be a singleton), and then just set the parent for all the types in that attribute. I guess you'd have to update CIL too. _______________________________________________ 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.
