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.
