Process privileges and owners in snaps

[Jamie Strandboge]

On Wed, 2017-01-04 at 11:10 +0000, James Page wrote:
> Hi All
> 
> Happy New Year!
> 
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).
> 
FYI, this is:
https://bugs.launchpad.net/snappy/+bug/1617314
https://bugs.launchpad.net/snappy/+bug/1606510

> 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.
> 
It could be in a separate interface, but IMHO if we do something like what you
describe in point '1' (ie, enumerate the users and groups and say what is going
to use each group) then we don't need a separate interface. On install snapd
creates these users and groups and then snap-confine can allow setuid(<uid of
glance>). snap-confine should also be modified to add an implicit rule to
setuid/setgid/etc back to the uid/gid to allow regaining permissions after
temporarily dropping them.

I think the implementation should probably be a new interface backend for
managing extrausers. Upon install, this backend looks at the snap yaml and
generates the declared users and groups in /var/lib/extrausers. The seccomp
default template is then updated to look at the snap yaml and if there are
declared users and groups, it adds the arg filtered setuid/setgid/etc rules for
these users and groups by default. 

If you are planning on implementing this, please get the snap yaml changes
approved and then discuss the implementation with the snappy interfaces virtual
team (ie, Gustavo, Zygmunt and me). There are open questions as to namespacing
these users and groups that need to be discussed with an architect (eg,
Gustavo)-- eg, we need to handle system user/group collisions gracefully and
securely and avoid snap user/group collisions in a way that doesn't require snap
declaration changes for everyone using this mechanism (ie, perhaps allow 'user:
SNAP_NAME' and 'user: SNAP_NAME.*' always but (perhaps?) allow use of 'user:
NOT_SNAP_NAME' with a corresponding snap declaration).

> 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.
> 
This is https://bugs.launchpad.net/snappy/+bug/1607763. Technically, this is
probably a 'sudo' interface for declaring the policy and a 'sudo' interface
backend that creates sudoers policy in /etc/sudoers.d/snap.SNAP_NAME based on
sudo interface declaration in the the snap yaml. This would of course be a very
sensitive interface with base declaration constraints and would need architect,
interface virtual team and security team input on the design and implementation.

-- 
Jamie Strandboge             | http://www.canonical.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20170104/bf62c3d6/attachment.sig>