Mechanism to create system groups

[Stéphane Graber]

LXD's main security mechanism for local users is done through group membership.

The LXD snap assumes the existence of a "lxd" group and makes the lxd unix socket owned by that group. That way only members of that group (or root) may access LXD.

snapd interfaces work great to prevent other snaps from talking to LXD, but do not help restricting access from other applications (on classic).

For the time being, the LXD snap simply assumes that the "lxd" group exists. If it doesn't the daemon will fail to start.

This bug is to track both a temporary workaround (as suggested by Mark in comments below) to just have snapd always create the "lxd" system group if it doesn't exist.

And to discuss what the right mechanism to manage groups would be moving forward.

[Stéphane Graber (stgraber)]

So after further discussion it sounds like what we want is actually the ability to get a group created on the system.

We'd then have a "lxd" group appear when the lxd snap is installed, our unix socket would be owned by root:lxd 0660 just like it is right now with the deb version.

Snaps that connect to lxd and run as root (most of them) will be able to talk to it, anything else will need to be added to the lxd group by an admin first.

This fixes the security concern in a way which requires explicit user interaction when granting unprivileged users access to LXD.

[Mark Shuttleworth (sabdfl)]

Good idea to add a group-creation mechanism, but to do it properly will
take a bit of time. Can I suggest that we find a quick path which
assumes that snapd will autocreate that lxd group on install / update on
the host system, for now? In other words, just add that group on all
systems where it is not added, so when the snap arrives it can just use
that user? A full group-creation interface will need:

 * the snap can specify what groups it wants
 * the store sends snaps for review which ask for groups that are not
yet approved
 * the store can tell snapd which groups are approved via an assertion
 * snapd can create the group and if needed pick a different name to
avoid collisions
 * the snap when installed can discover the actual group name when it is
executed

That's a lot of wiggles to code and debug :)

A fast path would be:

 * snapd deb / rpm / pkg scripts create that group everywhere
 * lxd snap just assumes it for now

Mark

[Stéphane Graber (stgraber)]

Fine with me, I'll just assume the group exists for now.

I'll still need the systemd socket activation bits I mentioned on the list so I can make use of said group and have the socket created and properly configured for use with LXD.

[Oliver Grawert (ogra)]

one bigger issue i see here is that we have two different systems with two different group files (actually 3 since the core snap needs to use a merge of a readonly and a readwrite db), i assume lxd running in context of the core snap will only be able to use the database of the core snap by default so we need to make sure to:

- get matching GIDs between host and core snap
  (on a debian system the snapd deb will just grab the last free GID below 1000 but snapd
   wont know if that GID is freely available in the readonly /etc/group of the
   core snap before the core snap is installed, so it is hard to block on this)

- make sure inside the core snap everything integrates fine with the libnss-extrausers setup
  (we only use it for users currently, the system groups usecase will need some testing)

[Jamie Strandboge (jdstrand)]

@Mark et al, IMHO adding the 'lxd' user via packaging seems reasonable for the immediate-term solution. That is what we did in 15.04.

As an intermediate step towards the final solution, I wonder if snapd could add a new backend for interfaces to create gids (and uids) and then the lxd interface itself says "create the 'lxd' gid if it doesn't exist". In this manner, other slot-implementations that need their own interface (eg, docker) could do the same thing. This is needed for what you've layed out as the long term solution (we need a way to create these anyway) but means we don't have to keep telling packagers to update the list of users and groups and the interfaces that need it now aren't blocked on the the assertions/store work.

[Oliver Grawert (ogra)]

that sounds very sensible and goes even beyond docker and lxd ...after all we might have interfaces that might provide shared directories with write access between the host and the core snap where file permissions and ownership must match ...

[Mark Shuttleworth (sabdfl)]

Yes, the hard part of that will be if we want to deal with conflicts
(e.g. an existing user with a desired name).

Mark

[Stéphane Graber (stgraber)]

So I'm recycling this bug report for what we discussed the most in comments, how to get the "lxd" group on our users' system.

The current recommendation I believe is to have snapd always create it (needs to be a system group!) and then figure out a clean way to address such needs moving forward.

All the other bits that were raised in this bug have been split into separate bugs (look for the lxd tag).

[Greg Lutostanski (lutostag)]

This is preventing me from installing the lxd snap on core-16, as there is no way to
```
sudo groupadd --system lxd
sudo usermod -G lxd -a <username>
```
as suggested by https://www.stgraber.org/2016/10/17/lxd-snap-available/, because /etc/groups is on the read-only filesystem of core-16.

I would really like to be able to run lxd on my rpi2 with core-16.

[Oliver Grawert (ogra)]

to add a group on core you need to use the --extrausers arg for addgroup and adduser, like:

sudo addgroup --extrausers --system lxd

sadly there seems to be some patch missing for the next step though:

ogra@pi3:~$ sudo adduser --extrausers ogra lxd
adduser: The group `lxd' does not exist.

as well as:

ogra@pi3:~$ sudo usermod -G lxd -a ogra
usermod: group 'lxd' does not exist

the second one is no surprise but the adduser behaviour is since all tools it uses internally are supposed to know about extrausers...

i have filed Bug #1647333 for this specific issue. as a quick workaround to get the group working anyway you can edit /var/lib/extrausers/group and /var/lib/extrausers/group- and add the username to the end of the lxd line.

[Till Kamppeter (till-kamppeter)]

I also would need some system users/groups in Ubuntu Core:

User "avahi" and group "avahi" for an avahi-daemon snap (needed for CUPS and cups-browsed)

Group "lpadmin" for CUPS snap (Group "lp" and user "lp" are already there)

[Zygmunt Krynicki (zyga)]

I think we could add a security backend or some other code that
manages users and groups but we need to have some idea what it should
do:

- is this an interface or something that is tied to a snap declaration?
- should we remove those users/groups when the snap goes away?

ZK

On Thu, Feb 2, 2017 at 3:02 PM, Till Kamppeter
<email address hidden> wrote:
> I also would need some system users/groups in Ubuntu Core:
>
> User "avahi" and group "avahi" for an avahi-daemon snap (needed for CUPS
> and cups-browsed)
>
> Group "lpadmin" for CUPS snap (Group "lp" and user "lp" are already
> there)
>
> --
> You received this bug notification because you are a member of Snappy
> Developers, which is subscribed to Snappy.
> Matching subscriptions: xxx-bugs-on-snapd
> https://bugs.launchpad.net/bugs/1606510
>
> Title:
> Mechanism to create system groups
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snappy/+bug/1606510/+subscriptions

[Mark Shuttleworth (sabdfl)]

On 02/02/17 14:40, Zygmunt Krynicki wrote:
> - is this an interface or something that is tied to a snap declaration?
> - should we remove those users/groups when the snap goes away?

I think this is an assertion function (i.e. assertions control that
particular system users exist if a particular snap is installed).

The users should persist at least as long as data persists.

Mark

[Jamie Strandboge (jdstrand)]

Note the related bug #1646144 and bug #1619888.

IMHO, we should consider all the user/group use cases when fixing this bug. Eg, three related bugs/use cases:

1. adding so-called system users/groups via snap declaration (eg, lxd wants to add 'lxd' group for its socket. aka, this bug)
2. per-snap opt-in users to support privilege separation within snaps (LP: #1619888)
3. supporting device access via ACLs (and possibly snap.* groups) - see comments in LP: #1646144

I agree with Zygmunt that security backends should be used to implement this.

For '1', if snapd has extrausers and ACL backend, then we could use the extrausers backend for the lxd interface to add the 'lxd' group (or lpadmin or avahi. Naming constraints TBD based on snapcraft@ thread (eg, _lxd, reserved user names, etc).

For '2', snapd could use the extrausers backend also for opt-in users. Strawman for discussion (needs design):

```
name: foo
apps:
  bar:
    user: true
    group: true
```

This creates `snap.foo.bar` user and group in 'extrausers' and seccomp arg filtering allows chown, setuid, etc to it (eg, launcher looks these up for the snap and allows it)

For '3', the interface uses the extrausers backend to create the `snap-interface.<interface>` group (or something else appropriately namespaced) and use that group with udev uaccess rules. UX for user access might be (needs design):
- sudo adduser --extrausers foo snap-interface.serial-port
- sudo snap connect <snap>:serial-port --user=<user>
- something else?

This could work on either classic or all-snaps if extrausers is used for all three cases. I believe there is extra work to make some of the standard tools to work with extrausers (Foundations has more information iirc).

[Zygmunt Krynicki (zyga)]

On Thu, Feb 2, 2017 at 6:26 PM, Jamie Strandboge <email address hidden> wrote:
> Note the related bug #1646144 and bug #1619888.
>
> IMHO, we should consider all the user/group use cases when fixing this
> bug. Eg, three related bugs/use cases:
>
> 1. adding so-called system users/groups via snap declaration (eg, lxd wants to add 'lxd' group for its socket. aka, this bug)
> 2. per-snap opt-in users to support privilege separation within snaps (LP: #1619888)
> 3. supporting device access via ACLs (and possibly snap.* groups) - see comments in LP: #1646144
>
> I agree with Zygmunt that security backends should be used to implement
> this.
>
> For '1', if snapd has extrausers and ACL backend, then we could use the
> extrausers backend for the lxd interface to add the 'lxd' group (or
> lpadmin or avahi. Naming constraints TBD based on snapcraft@ thread (eg,
> _lxd, reserved user names, etc).
>
> For '2', snapd could use the extrausers backend also for opt-in users.
> Strawman for discussion (needs design):
>
> ```
> name: foo
> apps:
> bar:
> user: true
> group: true
> ```
>
> This creates `snap.foo.bar` user and group in 'extrausers' and seccomp

I'm not 100% sure but AFAIR there is some badness in using dots in
usernames. Perhaps we'd have to map that to snap_foo_bar

> arg filtering allows chown, setuid, etc to it (eg, launcher looks these
> up for the snap and allows it)
>
> For '3', the interface uses the extrausers backend to create the `snap-interface.<interface>` group (or something else appropriately namespaced) and use that group with udev uaccess rules. UX for user access might be (needs design):
> - sudo adduser --extrausers foo snap-interface.serial-port
> - sudo snap connect <snap>:serial-port --user=<user>
> - something else?
>
> This could work on either classic or all-snaps if extrausers is used for
> all three cases. I believe there is extra work to make some of the
> standard tools to work with extrausers (Foundations has more information
> iirc).
>
> --
> You received this bug notification because you are a member of Snappy
> Developers, which is subscribed to Snappy.
> Matching subscriptions: xxx-bugs-on-snapd
> https://bugs.launchpad.net/bugs/1606510
>
> Title:
> Mechanism to create system groups
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snappy/+bug/1606510/+subscriptions

[Jamie Strandboge (jdstrand)]

@Zygmunt, useradd is fine with them, but adduser (a Debianism) requires the use of --force-badname. That is curious because man adduser.conf says:

"
VALID NAMES
  adduser and addgroup enforce conformity to IEEE Std 1003.1-2001,
  which allows only the following characters to appear in group and
  user names: letters, digits, underscores, periods, at signs (@) and
  dashes. The name may no start with a dash. The "$" sign is allowed
  at the end of usernames (to conform to samba).
"

So based on that, it should allow '.', but it doesn't. NAME_REGEX in /etc/adduser.conf doesn't include '.' though, so it seems there is a bug in the manpage.

I googled this and it appears there are some ancient bugs about some libraries only understanding alphanumerics and underscores. I verified underscores are fine with both adduser and useradd. We use underscores instead of dots in one other location (udev tagging). I might also note that '_apt' is now a default system user, which further supports using '_'.

[Jamie Strandboge (jdstrand)]

Discussion of this topic has moved to the forum: https://forum.snapcraft.io/t/snappy-and-users-and-groups/331