From: pebenito@ieee.org (Chris PeBenito)
Date: Wed, 28 Dec 2016 13:18:32 -0500
Subject: [refpolicy] kmod_t CAP_SYS_ADMIN follow-up
In-Reply-To: <20161227193648.0b11c457@gentp.lnet>
References: <20161227193648.0b11c457@gentp.lnet>
Message-ID: <5264c466-b012-dc9f-1943-df40f46f6236@ieee.org>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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