On Tue, 2015-03-31 at 17:02 -0400, Colin Walters wrote: > On Tue, Mar 31, 2015, at 04:35 AM, Pavel Odvody wrote: > > > It's supposed to work in the following way: > > - docker daemon is started with the --trusted flag, this labels the > > process as SELinux type 'docker_daemon_t', daemon also labels the > > created Unix socket as 'docker_socket_t'. Define a policy that allows > > only docker_daemon_t to talk to docker_socket_t. This ensures that the > > daemon communicates only with compatible binary; other methods of > > communication with the daemon have to be disabled (TCP). > > But what domains can transition to docker_daemon_t ? Is e.g. unconfined_t -> docker_daemon_t a valid transition? If so, we aren't gaining anything AFAICS. If it's not, what domains can? > The docker binary is originally labeled as docker_client_t, which is also capable of talking to docker_socket_t. > On Tue, Mar 31, 2015, at 04:35 AM, Pavel Odvody wrote: > > > > - each request that is sent from Docker Cli to the daemon is decorated > > with 2 additional HTTP headers, UID/EUID of the user. > > You really want instead to have docker use `getsockopt` with `SO_PEERCRED` when the socket connection is first set up. Anything else is subject to forgery. > That's nice! Didn't know about that one, sounds much better than pushing HTTP headers around :) Btw. the headers could not be forged, due to the policy constraints put on the socket, but this one should also work with docker-py and similar tools talking to the socket directly out of the box. -- Pavel Odvody <podvody redhat com> Software Engineer - EMEA ENG Developer Experience 5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno
Attachment:
signature.asc
Description: This is a digitally signed message part