Control: user pkg-apparmor-t...@lists.alioth.debian.org Control: usertags -1 help-needed Control: tag -1 + moreinfo
Hi, Anthony DeRobertis: > I rebooted after enabling Apparmor, and cachefilesd wouldn't start: > Sep 24 13:53:17 Zia cachefilesd[1105]: About to bind cache > Sep 24 13:53:17 Zia kernel: CacheFiles: Security denies permission to > nominate security context: error -2 > Sep 24 13:53:17 Zia cachefilesd[1105]: CacheFiles bind failed: errno 2 (No > such file or directory) > Sep 24 13:53:17 Zia cachefilesd[1052]: Starting FilesCache daemon : > cachefilesd failed! > Sep 24 13:53:17 Zia systemd[1]: cachefilesd.service: Control process exited, > code=exited status=1 > Sep 24 13:53:17 Zia systemd[1]: cachefilesd.service: Failed with result > 'exit-code'. > Sep 24 13:53:17 Zia systemd[1]: Failed to start LSB: CacheFiles daemon. > Rebooting with apparmor=0 on the kernel command line makes it work > again. Wow, interesting! cachefilesd does not come with an AppArmor profile and at first glance I had no idea how enabling AppArmor could possibly affect cachefilesd. Still, I acknowledge that your test results demonstrate that it does so I took a closer look. The failing code is: https://sources.debian.org/src/cachefilesd/0.10.10-0.1/cachefilesd.c/#L557 In this context, cachefd is a FD for /dev/cachefiles. And indeed, the error message comes from the cachefiles kernel module: https://sources.debian.org/src/linux/4.18.10-2/fs/cachefiles/security.c/?hl=37#L37 Note that cachefilesd.conf(5) reads: "Furthermore, this will tell the kernel module the security context it should use when accessing the cache (SELinux is assumed to be the LSM in this example)" and /etc/cachefilesd.conf has a secctx directive whose parameter is clearly SELinux-specific and has no chance to work when AppArmor is the active LSM. So my current hypothesis is that the default configuration assumes that there is either no active LSM (fine on Stretch or when disabling AppArmor on testing/sid) or SELinux is the active LSM (which is a rare configuration on Debian). This assumption is flawed in a Debian context. Can you please retry with AppArmor enabled, after commenting out the "secctx" directive in /etc/cachefilesd.conf? If this works, then my hypothesis will be confirmed and my recommendation will be: - The default /etc/cachefilesd.conf shipped by the package should *not* enable that directive. - Ideally, README.Debian or a comment in cachefilesd.conf would suggest SELinux users to enable that directive. - On the long term, once AppArmor supports labeling, then plausibly secctx can be re-enabled, with a value that works with AppArmor (probably not "system_u:system_r:cachefiles_kernel_t:s0"). Cheers, -- intrigeri
