From: aranea@aixah.de (Luis Ressel) Date: Sun, 27 Nov 2016 23:50:12 +0100 Subject: [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap In-Reply-To: <1480285881.620.14.camel@trentalancia.net> References: <20161127164146.3773-1-aranea@aixah.de> <20161127164146.3773-2-aranea@aixah.de> <1480278785.620.4.camel@trentalancia.net> <20161127222218.1ae86825@gentp.lnet> <1480285881.620.14.camel@trentalancia.net> Message-ID: <20161127235012.78adccd6@gentp.lnet> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Sun, 27 Nov 2016 23:31:21 +0100 Guido Trentalancia via refpolicy wrote: > If it is specific to Gentoo, you should enclose the new permissions > within an ifdef block. If this is really grsec's fault, it's a bit of a gray area. Not all refpolicy users use grsec, but it isn't Gentoo-specific, either. We've added grsec-specific permissions to the refpolicy before, though (for example "getty_t self:capability cap_sys_admin" earlier this year). But as I mentioned in my previous mail, I've inspected the grsec patch, and it doesn't appear to add CAP_SYS_ADMIN checks in any relevant code paths, so I'm not convinced this error is really caused by grsec. > Also, do you have an official bug report in Gentoo ? No(t yet). I've been hoping to get this resolved quickly, so I've just send the patch to both refpolicy and Gentoo's SELinux project. > From the error message that you quoted, it sounds like a call to > fs/libfs.c:simple_pin_fs() fails in drivers/gpu/drm/drm_drv.c. Yes, exactly. I've followed the call chain a few levels down, but haven't been able to determine the source of the EPERM at first glance. -- aranea