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.
