Classic confinement for 'netplan'

store
1

Netplan is the network configuration framework available on classic Ubuntu systems as a deb, as well as on Core systems (albeit embedded into the core snap).

There is no plan to change the above, however the availability of netplan as a snap may improve its adoption on other distros, or in scenarios we haven’t yet encountered.

Due to the nature of its work in generating a configuration for NetworkManager and systemd-networkd; netplan has to write files in /run, restart services and monitor them, as well as have access to directly controlling network devices such as to force them up or down, process renames, etc.

Additionally, ‘classic’ confinement has been elected as a clear way of signifying that ‘netplan’ on the core snap for Core systems is to remain the recommended way to control the network configuration.

1 Like
2

You can not install classic snaps on UbuntuCore systems (by design). Long term we should instead have a reserved “netplan” interface that allows all the above.

also, did you yet try to simply use network-setup-control ? it should allow many of the listed requirements already, perhaps the interface should just get extended ?

3

We explicitly don’t want the snap to be installed on Ubuntu Core; by design – it’s meant to stay in the core snap.

4

ah, sorry, that sentence sounded different … I probably need some english training :slight_smile:

nontheless, if netplan generate and netplan apply works through the network-setup-control interface and you can write to /etc/netplan, whats the other stuff that would need to be done ? see also:

and

https://github.com/snapcore/snapd/pull/5915

5

I think we’re still operating under a misunderstanding. ‘network-control’ and ‘network-setup-control’ aren’t sufficient here.

I don’t know that “netplan generate” works under these interfaces. If you’re running this on a Core system right now, I do think that you’re not limited by these interfaces, and only by the global apparmor policy.

Some of the important things here are that netplan needs to write to /run/NetworkManager/conf.d, /run/NetworkManager/system-connections, /run/systemd/network, and potentially directories under /run/systemd/system. I do not believe any of these should be exposed via interfaces except possibly for reading. Applications other than netplan should certainly not randomly get such write access via simply adding an interface: these are system configuration locations that should be limited to the operating system, to services such as netplan that create configuration for the operating system, but that probably best be tightly controlled given their high likelihood of conflicting with other applications.

Even reading these is a potential security issue: the configuration may contain wireless or 802.1x passwords (though that is also true of /etc/netplan files)

Right now, the state of netplan if under confinement: strict is still to fail due to denied access to the /run subdirectories for unlinking and re-creating files:

Nov 22 14:17:23 demeter kernel: [18760.393613] audit: type=1400 audit(1542914243.182:126): apparmor="DENIED" operation="open" profile="snap.cyphermox-netplan.netplan" name="/run/systemd/" pid=3515 comm="netplan" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Nov 22 14:17:23 demeter kernel: [18760.589069] audit: type=1400 audit(1542914243.378:127): apparmor="DENIED" operation="open" profile="snap.cyphermox-netplan.netplan" name="/etc/netplan/" pid=3515 comm="netplan" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Nov 22 14:17:23 demeter kernel: [18760.594916] audit: type=1400 audit(1542914243.382:128): apparmor="DENIED" operation="open" profile="snap.cyphermox-netplan.netplan" name="/etc/netplan/" pid=3530 comm="generate" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Nov 22 14:17:23 demeter kernel: [18760.594926] audit: type=1400 audit(1542914243.382:129): apparmor="DENIED" operation="unlink" profile="snap.cyphermox-netplan.netplan" name="/run/NetworkManager/conf.d/10-globally-managed-devices.conf" pid=3530 comm="generate" requested_mask="d" denied_mask="d" fsuid=0 ouid=0
Nov 22 14:17:23 demeter kernel: [18760.595268] audit: type=1326 audit(1542914243.382:130): auid=1000 uid=0 gid=0 ses=2 subj==snap.cyphermox-netplan.netplan (enforce) pid=3515 comm="netplan" exe="/usr/bin/python3.5" sig=0 arch=c000003e syscall=41 compat=0 ip=0x7f86328f85a7 code=0x50000
Nov 22 14:17:23 demeter kernel: [18760.595448] audit: type=1326 audit(1542914243.382:131): auid=1000 uid=0 gid=0 ses=2 subj==snap.cyphermox-netplan.netplan (enforce) pid=3515 comm="netplan" exe="/usr/bin/python3.5" sig=0 arch=c000003e syscall=41 compat=0 ip=0x7f86328f85a7 code=0x50000
6

did you check the first link i posted ? the discussion defines exactly whats missing in the network-setup-control interface to make netplan work, the list includes all dirs you listed and more …

there is definitely no reason why netplan should be classic since it never writes to unpredictable places, so an interface can properly permit/guard it to do that … classic should always be the last resort for any snap and only be used if there is no way at all to make it work with the current set of interfaces (it forces you to add extra switches to the snap command to install it (and will throw warnings and errors if you dont) it works around any security of snaps and thus there should be a serious reason for it to be granted)… in the case of netplan there has been research done already and bits only need to be added to the profile to make it work (perhaps the list isnt complete, this is why i pasted the link above for you to review)

this is indeed completely unrelated to using netplan on Ubuntu Core where we surely want to keep it as is … but where also several customers asked about using netplan from a configuration snap for which these interface changes are needed anyway eventually, you’ll get strict support for netplan for free if this lands and can just make it use the network-setup-control interface from its app entry in snapcraft.yaml.

7

That’s all fine and nice, but what’s the timeline for landing these?

It certainly doesn’t fix the problem /right now/, which is why I’m asking for classic confinement. We can always move it to strict later.

8

The requirements are understood but the interface is connected yet. Perhaps @ogra or someone else can pick up https://github.com/snapcore/snapd/pull/5915 and respond to the open questions.

I’ve vetted the publisher. Granting classic. This is now live.