On Wed, 2015-04-01 at 10:34 +0200, Pavel Odvody wrote:
> 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.
>
>
I created a fresh branch which uses `SO_PEERCRED`, the road was bumpy
as none of the structs actually expose the file descriptor of the
connection or the connection object itself (reflection to the rescue!).
Example output:
# docker version
vars: {"rgid":"0","rpid":"21855","ruid":"0","version":"1.19"}
# sudo -u nginx docker version
vars: {"rgid":"986","rpid":"21881","ruid":"990","version":"1.19"}
https://github.com/shaded-enmity/docker/compare/trusteddocker
--
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