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
signature.asc
Description: This is a digitally signed message part
-- Snapcraft mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
