On 02/06/2017 09:03 AM, Daniel J Walsh wrote:
> I know we discussed this a few months ago, but I can not seem to find
> the emails.
>
> With current container runtime policy, we are adding type-bounds checks
> for containers, so that
>
> docker --no-new-privs will work with SELInux.
>
> The problem we are now seeing is I have docker running as
> container_runtime_t and it is executing the
>
> container as container_t.
>
>
> typebounds container_runtime_t container_t;
>
>
> But sometimes a user executes a command like
>
>
> docker run --entrypoint="/wait-for-it.sh" -v
> /usr/local/wait-for-it.sh:/wait-for-it.sh:ro fedora
>
> Where /usr/local/wait-for-it.sh is labeled as usr_t, or it could be
> bin_t. I seen an AVC that says
>
>
> type=AVC msg=audit(1486244245.275:7129): avc: denied { entrypoint }
> for pid=20532 comm="exe" path="/wait-for-it.sh" dev="dm-0" ino=50618329
> scontext=system_u:system_r:container_t:s0:c116,c857
> tcontext=unconfined_u:object_r:usr_t:s0 tclass=file permissive=0
>
> Was caused by:
> Unknown - would be allowed by active policy
> Possible mismatch between this policy and the one under
> which the audit message was generated.
>
> Possible mismatch between current in-memory boolean
> settings vs. permanent ones.
>
>
> The reason this is being blocked is container_runtime_t is not allowed
> to be entered from usr_t. The typebounds call
>
> removes the entrypoint from container_t and the container fails.
>
>
> To fix this I would need to allow container_runtime_t to be entered by
> lots of new types. Since container_runtime_t is an unconfined domain by
> default I don't want to have to add all of these entrypoints. I also
> want to allow container_t to be transitioned to via unconfined_t, and
> again, I don't want these entrypoints added for unconfined_t.
>
> I feel that entrypoint should be ignored for typebounds just like target
> domains are. Since they cause you too loosen the policy of the parent
> domain.
>
>
Here is the bugzilla associated with this issue.
https://bugzilla.redhat.com/show_bug.cgi?id=1419288
_______________________________________________
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.
