[lxc-users] dbus and uidmap

[overlay fs]

> Quoting serge.hallyn at ubuntu.com
> Quoting overlay fs (overlayfs at gmail.com):
> > I would like to connect the host's session-bus to an unprivileged container.
> >
> > The connection succeeds when I use a trivial uidmap,
> >
> >             uidmap: container -> host:   1000 -> 1000
> >
> > With a non-trivial uidmap, dbus authorization fails because the uidmap
> > interferes with the scm_credentials.
> >
> > Is it possible to use a non-trivial uidmap?
> >
> > It seems that cgproxy has solved the uidmap problem for dbus, but
> > AFAIK it only applies to cgroups, not the session bus.
>
> What exactly are you trying to connect to?  Indeed your app is
> sending the uid it thinks it is (1000) over dbus as an integer,
> and the other end grabs the uid from the socket owner (which
> is the shifted uid).  So those need to match, which is why you
> need uid 1000->1000.
>
> -serge

Some explanation/motivation:

On the host (ubuntu 14.04 with gnome-session-flashback),
unity-settings-daemon captures events such as keypresses of media-keys
and other special keys; it then broadcasts those events over the
user's session-bus.  Those keypresses are only transmitted to apps
listening to the session bus; apps which cannot access the host's
session-bus, such as apps in a container, do not work properly.

I've made the following changes on the host to allow uid 101000 to
listen to the session bus for uid 1000:
   (i)   set the session-bus to use a path-based socket rather than
the default abstract socket.
   (ii)  granted uid's 100000 and 101000 rw permission for the socket.
   (iii) added uid 101000 to /etc/passwd  (using the 'adduser'
command.  necessary because dbus relies on /etc/passwd).
   (iv) added <allow user="101000"/>  to /etc/dbus-1/session-local.conf
   (v)  temporarily disabled apparmor, so that it doesn't mediate the
container's access to the session-bus.
   (vi) bind-mounted the socket into the container, and set
DBUS_SESSION_BUS_ADDRESS inside the container.

On the host, uid 101000 can now access the session bus for uid 1000;
eg the following works,

                    sudo -E -u \#101000 -g \#101000 -- dbus-monitor --session

In a container with a non-trivial uidmap, running 'dbus-monitor' fails
due to the aforementioned problem with scm_credentials. Here's the
trace:

$ sudo strace -f -q -p 2118 -p 2135   # strace of 'dbus-daemon
--session' and upstart-dbus-bridge on the host
[pid  2118] getsockname(73, {sa_family=AF_LOCAL,
sun_path="/tmp/dbus/session-bus/dbus-wBT44RZluY"}, [40]) = 0
[pid  2118] getsockopt(73, SOL_SOCKET, SO_PEERSEC,
"lxc-container-default-with-dbus-"..., [58]) = 0
[pid  2118] recvmsg(73, {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}],
msg_controllen=0, msg_flags=0}, 0) = 1
[pid  2118] getsockopt(73, SOL_SOCKET, SO_PEERCRED, {pid=21850,
uid=101000, gid=101000}, [12]) = 0
[pid  2118] read(73, "AUTH EXTERNAL 31303030\r\n", 2048) = 24
[pid  2118] sendto(73, "REJECTED EXTERNAL DBUS_COOKIE_SH"..., 46,
MSG_NOSIGNAL, NULL, 0) = 46

While dbus works fine with a trivial uidmap, I wonder whether this is
optimal from an isolation/security POV?