Group owner of Multipass socket on core{18}

Hello,

We are working on making Multipass a strict snap with one goal being that it can run on Ubuntu Core[18].

In Multipass, the daemon creates a Unix domain socket which is owned by root.sudo with 660 permissions. As such, the user must be part of the sudo group. In testing the Multipass snap on Ubuntu Core{18}, the default user is not part of the sudo group, nor is there an apparent way to add the user to the sudo group since the group in defined in the read-only /etc/groups space. We use the sudo group as a measure to ensure the user at least has sudo privileges when issuing multipass commands.

Does anyone have any ideas on how best we can work around this issue? Thanks!

1 Like

Some references:

There doesn’t seem anything “automatic” that will help us, should we simply be creating a multipass group in this case (or across the board)?

Prior art:

  • LXD creates the lxd group on startup - the disadvantage being that no users get access to the socket “by default”

on core snapd creates /etc/sudoers.d/create-user-$USERNAME when the create-user feature is used (which is what console-conf calls if you configure the system interactively) …
so groups are shallow anyway (users are added via /var/lib/extrausers and group mgmt
of system groups isnt really a strength of that setup) but you can at least assume that the initial user created has sudo privileges anyway so not setting the group (and perhaps adding a uid check at startup) should be fine.

Well, yes, but sudo privileges, and sudo group are not the same… We would like to avoid requiring sudo multipass … everywhere.

indeed i didnt mean everywhere, just on core :slight_smile:

Note, on core, multipass won’t be classic and the security policy won’t allow chowning the socket to root:sudo even if you could add a user to the group.

I suspect the pattern is the same as for other snaps of this type where you desire:

$ snap install multipass
... multipass creates the socket with root:multipass 0660 permissions
$ sudo addgroup <user> multipass  # addgroup used for simplicity
$ sg multipass ; multipass ...

It is technically possible to use the account-control interface to modify /var/lib/extrausers/group directly, but this has not been allowed in the store for some time.

In short, today, this is not possible. @pedronis, this is a similar scenario (‘system users and groups’) to what we discussed for microk8s recently. In this case, multipass only wants a group to regulate access (I believe this also holds true for the docker and lxd snaps). With microk8s, they want both a user and group.

What would be possible is for multipass to leave the socket as 0666 and do the check itself by looking at the peer cred for the uid, then doing a getgrent() to check for group membership. You could make this group membership configurable via ‘snap set’ for multipass. The only thing left would be how to make it easy for the admin user to add the specified group to the system if it didn’t exist and to add users to the specified group.

OK thanks all, we’ll go with sudo multipass … on Core for now, and will work on relaxing the socket permissions by improving our authentication story beyond the socket.

it is similar though do I understand correctly that the purpose here is to have a well-known user/group, not to run as or to chown file as, but to use basically for access as values for SocketUser/SocketGroup in the service systemd.socket file?

AIUI, yes. In short, multipass, docker and lxd is one class that wants a group to regulate access to a named socket. microk8s is another class that wants a user and group for file access.

Implementation-wise, IME we want to use the same internal mechanisms for this that we developed for snap_daemon and create both the user and group for either class on the justification that we should allow in the security policy for both classes to chown/setuid/setgid/etc to the user and group since applications may choose to privilege drop before creating a resource or they may choose to chown; having snapd dictate one over the others feels arbitrary and offering user, group or user and group seems needlessly complicated. This does not mean we shouldn’t also add systemd directives for these sockets, but that is orthogonal to this discussion (though obviously, the user and/or group in said directive must exist).

To be clear, while SocketUser and SocketGroup might be a great option, IMHO we shouldn’t necessarily dictate that this is the only mechanism they can use. I feel it should be an option: either they create the socket/etc themselves with the right permissions or the application is adjusted to be passed the fd for the socket that systemd creates for it using those directives.