device cgroup enforcement is partially ineffective for snap services
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd |
Confirmed
|
Medium
|
Unassigned |
Bug Description
During a debugging session last Friday we realised that the way snapd is using the device cgroup to control access to character and block devices is not working correctly for snap services. Snap services are assigned to a device cgroup by systemd, moving them from "snap.$
The layered approach, using both device cgroup and AppArmor constraints effect of this bug to applications using specific interfaces, such as joystick or serial port, where instead of being scoped to a specific device, the bug allows access to all devices of that class.
Work on fixing this is already in progress and consists of:
1) Reviewing all interfaces for mismatches between the device cgroup (via udev tagging) and apparmor for discrepancies. Those need to be addressed first so that eventual fix for the security bug does not break existing legitimate applications.
2) Writing proper regression test and improving existing tests that exercise this code path for non-deamon applications where systemd is not involved.
3) Changing snap-confine's behaviour when dealing with services, so that it cooperates with systemd. This results in cascading changes to snap-confine's udev interaction as well as the implementation of the snap-device-helper program.
4) Coordination with distributors using enforcing apparmor confinement for proper responsible release of the fixed version.
This bug will be updated with additional information as we progress.
Changed in snapd: | |
importance: | Critical → Medium |
Changed in snapd: | |
assignee: | nobody → Zygmunt Krynicki (zyga) |
From IRC:
Day changed to 03 Aug 2019
00:23 < jdstrand> zyga and ondra (cc amurray, joe, niemeyer): I had some time to verify your assessment of the systemd/cgroup issue. I was thinking it shouldn't matter that systemd put the application in a cgroup cause snap-confine puts it in the right place and that is after systemd did its thing. I created a snap and sure enough, that is what happened and I could not reproduce. daemons were in the correct
00:23 < jdstrand> cgroup and it was all mediated
00:24 < jdstrand> zyga and ondras: I'm not saying that there isn't a bug, but it doesn't seem to be like what was described to me (it works afaict)
00:25 < jdstrand> zyga: before you do any fixing, we need to understand what is happening better, with a clear reproducer. once we have that, I'll look and we can meet
00:26 < jdstrand> zyga: fyi, I snap start/stop, systemctl start/stop/restart, udevadm trigger/control --reload-rules and all good. I only did it on bionic classic
00:45 < jdstrand> zyga:: ondras mentioned something about the client lingering. I don't know what this application is doing, but if it opened the file and then the interface as disconnected, the device cgroup would not revalidate. same if there was an fd pass then interface disconnect