@chipaca There’s no bug yet because I haven’t created one. My description above is all that currently exists. I’ll add a bug tomorrow, if you’d like.
I pushed a fix to https://github.com/snapcore/core/pull/64 - I don’t think we need a LP bug for this, this forum topic seems sufficient. Once this is reviewed it will be in the edge core snap for further testing.
@jdstrand Any thoughts on my results above wrt to the apparmor behavior and the errors @jenny.murphy reported? Wondering also if we should go ahead and make the change you suggested and allow access to @{PROC}/1/environ in one of the time* interfaces?
As mentioned from time to time, systemd and its utilities aren’t designed for application isolation and we’ll see issues like this from time to time.
The ‘capability net_admin’ denial is caused because timedatectl is setting ‘SO_RCVBUFFORCE’ and ‘SO_SNDBUFFORCE’ with setsockopt on the systemd socket: /var/run/dbus/system_bus_socket. Reading src/core/socket.c (and confirmed with strace), the EPERM denials are non-fatal because it will then try SO_RCVBUF and SO_SNDBUF which don’t require net_admin.
Reading /proc/1/environ is restricted by the upstream kernel and it manifests iself via the LSMs as a ptrace policy denial. The rules to make these all go away are:
capability net_admin,
@{PROC}/1/environ r,
ptrace (trace) peer=unconfined,
The first net_admin denial is unfortunate, the /proc/1/environ would likely be ‘ok’ for this interface but the ptrace rule is completely unacceptable, since it would all the snap to ptrace any unconfined process on the system. You cannot access @{PROC}/1/environ without the ptrace rule.
Reading src/basic/virt.c from systemd, /proc/1/environ is being read to detect if the process is running in a container (in this specific case, an nspawn’d container). The denials are non-fatal since systemd will assume it isn’t running in a container if it can’t read it (later versions of systemd continue to read /proc/1/sched to determine if running in a container). Snaps are not started via an nspawn container so systemd assuming it isn’t running in a container is just fine. Furthermore, there is nothing in /proc/1/environ that is interesting to the snap, which is why everything works in the face of these denials.
The question then becomes what to do about the denials. I think the best we could do would be to have an explicit deny rule in the timeserver-control and timezone-control interfaces:
deny @{PROC}/1/environ r,
Since we don’t allow reading @{PROC}/*/environ anywhere, I think this is ok. I do not think we should add a deny rule for net_admin though since these interfaces could then not be used with interfaces that grant the capability (deny rules take precedence over allow rules).
I plan to update snappy-debug to discuss these denials within the context of systemd to help alleviate developer confusion.
Bottom line: there is nothing that @jenny.murphy’s snap needs to do. The denials are benign.