Necessity to provide support for SCM_CREDENTIALS

[Simon McVittie]

On 05/11/14 13:14, Mateusz Malicki wrote:
> I am working with dbus-daemon launched in container (enabled user
> namespace).
> Client library (outside user namespace) isn't able to connect to dbus
> with EXTERNAL authentication mechanism.

The short answer is "don't do that". The slightly longer answer is
please don't do that unless you are willing to design, document and
implement what should happen, and provide security support for it in
future (assuming it's even implementable).

I would recommend treating the container as if it was a separate
machine, for instance by running whatever tool you want to run inside
the container environment, or proxying the D-Bus connection over ssh.

dbus-daemon does not currently have any concept of user namespaces: if
you connect across a user namespace boundary, the numeric uids inside
the container and the numeric uids outside the container are not going
to match, potentially resulting in incorrect
authentication/authorization decisions. This could lead to either
insecurity (a process allowed to do things it should not be able to do)
or failure (a process not allowed to do things it should be able to do).

> Dbus-daemon doesn't support for SCM_CREDENTIALS.

It does support SO_PEERCRED on Linux, and that's what we use instead.

If SO_PEERCRED doesn't work the way you want it to across user namespace
boundaries, please look into why not. If the answer is "nobody has got
round to it yet", that suggests a possible way to proceed; if the answer
is "it would be insecure", don't do that :-)

> Why it isn't implemented?

SO_PEERCRED only has one bit of code: the server reads the client's
credentials. Relatively simple.

SCM_CREDENTIALS has two parts: the client must send the credentials, and
the server must read them. Twice as many things that can go wrong :-)

If SCM_CREDENTIALS has some key advantage that SO_PEERCRED does not,
you're welcome to implement it (probably based on the SCM_CREDS code
path for FreeBSD); but it is extremely security-sensitive, so be
careful. I would want to be 100% sure that it does not introduce new
security vulnerabilities before merging.

Regards,
    S