Snap daemons run as same user, removing some security restrictions

[Simon Davy]

Snap daemons all run as the same user*. The expectation for much software is that it will run as a dedicated user.

As an example, if a snap that has network-bind interface and binds sockets using the SO_REUSEPORT option, another snap will be also able to do so, as it is the same user, and thus steal traffic from the original snap.

There are possibly other restrictions that a shared user might overcome.

Possible solution: allow a snap to specify in needs a dedicated user? Or even do it by default for daemons? Could be randomly generated.

* the fact it is root is mitigated by snappy, the issue here is that it is shared, but it possibly wouldn't hurt to be not root?

[Jamie Strandboge (jdstrand)]

Thank you for reporting a bug. At the moment there is a known and documented gap in our network mediation that we are working to address.

From the security whitepaper[1]:

"Traditional permissions

The Linux kernel enforces Discretionary Access Controls (DAC) via traditional UNIX ‘owner’ permissions as well as Linux kernel capabilities and the Ubuntu Core base system uses these permissions extensively. For app snaps on Ubuntu Core 16, services run as root and therefore traditional permissions alone do not play as important of a role in the confinement of services. Future versions of Ubuntu Core will allow snaps to optionally request snap-specific, non-root users and groups for services."

In general DAC is not a primary mechanism for isolation in snappy at this time and we rely on other isolation mechanisms. We want to support opt-in uid/gid for snaps that need it (ie, to support privilege dropping) but note that separate uid/gids will not be required so we'll need more complete isolation for networking. From the whitepaper:

"Network interfaces

Ubuntu Core 16 does not currently support fine-grained network mediation (eg, for per-snap access to IPv4 and IPv6 TCP and UDP ports) and snaps specifying the ‘network-bind’ interface and providing network services are reachable by other snaps on the host (provided the connecting snap uses the client ‘network’ interface) and over the internet."

Adding fine-grained mediation for networking is planned (see bug #796588) and once it is implemented we will be able to assign ports to snaps.

As for SO_REUSEPORT, the man page states:

"SO_REUSEPORT (since Linux 3.9)
              Permits multiple AF_INET or AF_INET6 sockets to be bound to an
              identical socket address. This option must be set on each
              socket (including the first socket) prior to calling bind(2)
              on the socket. To prevent port hijacking, all of the
              processes binding to the same address must have the same
              effective UID. This option can be employed with both TCP and
              UDP sockets
"

As you pointed out, if a snap uses SO_REUSEPORT, then another snap could reuse the port, but there is a safeguard there in that it won't work if bind() has been called already which makes the attack racy. Of course, we don't ever want the attack to work, which is one of many reasons why we are implementing fine-grained network mediation.

Based on the above, I'm going to mark this a duplicate for bug #796588. Thank you for taking a critical look at the security of snappy and filing a bug. :)

[1]https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.