From: aranea@aixah.de (Luis Ressel)
Date: Tue, 27 Dec 2016 19:36:48 +0100
Subject: [refpolicy] kmod_t CAP_SYS_ADMIN follow-up
Message-ID: <20161227193648.0b11c457@gentp.lnet>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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