Re: RFC: Passing on initial client user in systemd-userdbd

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Fr, 25.11.22 15:19, Dominik George (nik@xxxxxxxxxxxxx) wrote:

> Hi,
>
> I would like to extend the methods of the User/Group Lookup API[1]
> with an optional argument "onBehalfOf" that carries the authenticated
> user who made the initial method call.
>
> The argument must only be set by a privileged client.
>
> When a client makes a lookup request to the multiplexer, the
> multiplexer authenticates the client using SO_PEERCRED. In each
> subsequent call to other services, it sets the authenticated user in
> the onBehalfOf argument to the method call.
>
> Services must only honour the argument if the connecting client was
> identified as a privileged client, i.e. it would receive the
> "privileged" section of the User or Group Record. In all other cases,
> they must ignore the argument and use SO_PEERCRED themselves to
> determine the client user.
>
> The concrete use case for this is to allow a service to take more
> fine-grained control of the data it returns, e.g. it strips location
> or realName from the record if an unprivileged user make a query, or
> chooses a user-bound OAuth token to make calls to a Web API in
> response to the request.
>
> What do others think of this?

Sounds superficially OK to do. I presume you intend to pass the numer
UID there?

Usually passing around numeric UIDs is a bit problematic, due to
user namespaces and so on. i.e. the two ends of an AF_UNIX stream might live in
different userns and thus have a different idea what UID 4711 means.

This hence raises the question if we can find a better way. Right now,
systemd's varlink implementation uses exclusively SO_PEERCRED to
identify the peer i.e. a UID pinned at connection time.

But there's also SCM_CREDENTIALS, which allows receiving and sending
UIDs at arbitrary times. When sending them, clients can only send
their own uids (euid or uid), or if they are privileged any. Hence, we
could just build on that: when reading messages of the varlink socket
do so with recvmsg() so that we get this info. Then when doing lookups
we'd use SCM_CREDENTIAL info when available, and SO_PEERCRED
otherwise. A client could then transmit its varlink messages with a
SCM_CREDENTIAL metadata field to execute stuff on-behalf of some other
client.

The big benefits of this approach would be: automatic translation of
UIDs by the kernel in regards to userns, and the kernel will
implicitly validate for us whether the on-behalf-of impersonation
shall be allowed or not.

Does that make sense?

Lennart

--
Lennart Poettering, Berlin