<div dir="ltr"><div dir="ltr" class="gmail_msg">Hi All</div><div dir="ltr" class="gmail_msg"><br></div><div dir="ltr" class="gmail_msg">Happy New Year!<br><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Over the last few months we've been working towards having a core set of snaps for OpenStack running under strict mode.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I think there are two features here that might be nice to have:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">1) creation and use of unprivileged users in snaps</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">users:</div><div class="gmail_msg">   - glance</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">groups:</div><div class="gmail_msg">   - glance</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div class="gmail_msg">apps:</div><div class="gmail_msg">  api:</div><div class="gmail_msg">    command: snap-openstack glance-api</div><div class="gmail_msg">    daemon: simple</div><div class="gmail_msg">    user: glance</div><div class="gmail_msg">    group: glance</div><div class="gmail_msg">    plugs:</div><div class="gmail_msg">      - network</div><div class="gmail_msg">      - network-bind</div></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">We might want to propagate that information to the command as well using SNAP_USER SNAP_GROUP (or suchlike).</div><div class="gmail_msg"><br></div><div class="gmail_msg">2) interface support for allowing processes to switch uid/gid</div><div class="gmail_msg"><br></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br></div><div class="gmail_msg">Thoughts?</div><div class="gmail_msg"><br></div><div class="gmail_msg">James</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div></div></div>