On 07/27/2016 07:02 PM, Stephen Smalley wrote: > 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. > > If we want to support this for systemd, then we might as well not beat around the bush and make systemd unconfined, and make all daemon processes systemd process bounded subjects, and all daemon executable files systemd executable file bounded executable files. > _______________________________________________ > 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. > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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.
