On Mon, 2015-04-06 at 11:34 -0400, Daniel J Walsh wrote:
> On 04/02/2015 11:50 AM, Pavel Odvody wrote:
> > 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
> >
> You should be looking to get the loginuid not the UID or gid. We also
> have SO_PEERCON
>
> man getpeercon() in libselinux returns the type of the remote connection
> on the socket.
>
> But I think we want to do this in two different steps. First look at
> the communications with the docker
> socket purely from a DAC perspective. Once we have something in place
> for this, we can start looking
> at the SELinux/MAC issues.
>
>
>
>
I've pushed an update that also grabs the `loginuid` from
/proc/${pid}/loginuid and stores it in the `rlid` variable per each
request:
# docker version
{"rgid":"0","rlid":"0","rpid":"2260","ruid":"0","version":"1.19"}
# sudo -u nginx docker version
{"rgid":"986","rlid":"0","rpid":"2267","ruid":"990","version":"1.19"}
(fedora)$ sudo docker version
{"rgid":"0","rlid":"1000","rpid":"2415","ruid":"0","version":"1.19"}
(fedora)$ docker version
{"rgid":"1000","rlid":"1000","rpid":"2382","ruid":"1000","version":"1.19"}
Now figure out what to actually do with all the IDs and how to label
stuff inside docker.
Do you have a Docker branch for this project or is this the only
prototype?
--
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