Hello,
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 your help!
Regards,
Luis Ressel
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.
--
Chris PeBenito
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 <[email protected]> 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.