From: aranea@aixah.de (Luis Ressel)
Date: Mon, 28 Nov 2016 23:03:20 +0100
Subject: [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the
 sys_admin cap
In-Reply-To: <1480352576.14631.5.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>
	<20161127235012.78adccd6@gentp.lnet>
	<1480352576.14631.5.camel@trentalancia.net>
Message-ID: <20161128230320.158d4202@gentp.lnet>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Mon, 28 Nov 2016 18:02:56 +0100
Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> wrote:

> > We've
> > added grsec-specific permissions to the refpolicy before, though
> > (for example "getty_t self:capability cap_sys_admin" earlier this
> > year).  
> 
> Thanks for pointing that out ! I have now removed the sys_admin
> capability locally from the getty module.
> 
> It is not needed. And, there must be something wrong if the patch you
> mention forces permissions that are normally unneeded... It seems like
> it is forcing the users to weaken the policy, which is not what we
> want.

I do of course agree that unconditionally adding grsec-specific
permissions to the refpolicy isn't optimal either.

What are your thoughts about adding a new kernel_grsec ifdef, similar
to our current distro_* ifdef's? It would apply to the getty_t
permission I mentioned earlier, to the kmod_t capability discussed in
this thread (as soon as we've confirmed it is indeed grsec-related),
and to any other grsec-specific permissions we've added in the past
(@Sven, Jason: Do you remember any such permissions?).

The vast majority of refpolicy+grsec users are probably gentoo folks,
so we could keep these permissions in ifdef(distro_gentoo) blocks, too;
but I think that wouldn't be ideal. After all, there may well be other
people using this particular combination; it's not gentoo-specific.

Regards,
Luis