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. :)
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)
processes binding to the same address must have the same
effective UID. This option can be employed with both TCP and
on the socket. To prevent port hijacking, all of the
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/