From: guido@trentalancia.net (Guido Trentalancia) Date: Wed, 28 Dec 2016 19:27:18 +0100 Subject: [refpolicy] kmod_t CAP_SYS_ADMIN follow-up In-Reply-To: <5264c466-b012-dc9f-1943-df40f46f6236@ieee.org> References: <20161227193648.0b11c457@gentp.lnet> <5264c466-b012-dc9f-1943-df40f46f6236@ieee.org> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com The same sys_admin capability recently added to the getty module is also very much likely unneeded and just dangerous. I could not reproduce it, I strongly advice to revert that commit (last March, as far as I can remember, there is another specific thread still open). Thanks, Guido On the 28th December 2016 19:18:32 CET, Chris PeBenito via refpolicy wrote: >On 12/27/16 13:36, Luis Ressel via refpolicy wrote: >> TL;DR: Kernel bug, no need for refpol changes. >> >> I've now identified the source of kmod's sudden need for the >> CAP_SYS_ADMIN permission on my systems. Since Linux 4.8, some >> filesystem-related kernel operations require the caller to pass a >> capable(CAP_SYS_ADMIN) check, except for kernel-internal mounts not >> exposed to user space. >> >> The drm subsystem used by graphics drivers uses such an internal >mount >> of the "drm_fs" pseudo fs -- but due to a kernel bug, the filesystem >> code doesn't recognize this as an internal operation and hence >requires >> CAP_SYS_ADMIN. Since the initalization routines of kernel modules run >> in the kmod_t (or udev_t, depending on the userspace program loading >> the module) domain, use of this capability is denied by SELinux and >the >> initalization fails. >> >> I also have a theory why Guido and Nicolas weren't able to reproduce >my >> issues: It seems that on many Linux systems, the loading of >> necessary kernel modules is taken care of by udev -- and refpol >grants >> udev_t access to the sys_admin capability. On my systems however, >udev >> fails to load any kernel modules (probably due to a bug; udev doesn't >> seem to like signed modules). My boot scripts attempt to load the >> required modules by calling modprobe (kmod), but that fails as >> explained above. > >Thanks for resolving this question.