Process privileges and owners in snaps

[James Page]

Hi All

Happy New Year!

Over the last few months we've been working towards having a core set of
snaps for OpenStack running under strict mode.

For the major of the control plane components, this was fairly trivial, and
the latest snapd release (introducing network namespace management) has
allowed us to *almost* run the hypervisor snap in strict mode.

The (hopefully) final hurdle is related to processes trying to drop
privileges on startup - for example, dnsmasq by default will always drop to
the nobody user/group on startup, and a few other neutron managed processes
do much the same thing.

This made me reflect a little on the fact that everything in a snap also
runs as root by default - which despite the sandboxing of the processes
using apparmor and seccomp still makes me feel a little uncomfortable.

I think there are two features here that might be nice to have:

1) creation and use of unprivileged users in snaps

For example, the glance snap would declare a 'glance' user/group, and the
snap could then use that in the apps section for daemons to run as:

users:
   - glance

groups:
   - glance

apps:
  api:
    command: snap-openstack glance-api
    daemon: simple
    user: glance
    group: glance
    plugs:
      - network
      - network-bind

We might want to propagate that information to the command as well using
SNAP_USER SNAP_GROUP (or suchlike).

2) interface support for allowing processes to switch uid/gid

I see support in some existing specific interfaces for
setgroups/setgid/setuid etc.. but maybe that's something we could
encapsulate in a standalone generalised interface as well.

Most of that is related with dropping privs for processes - most bits of
OpenStack assume the use of sudo for escalation of privs, which for now
I've worked through by providing a fake 'sudo' shim as the calling process
is already running as root (relying instead on the process sandboxing to
control whats permitted), but that sniffs like another interface
requirement to support use of sudo within the constraints of snap
confinement rather than re-writing the world to work with snaps.

Thoughts?

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20170104/0757da09/attachment.html>