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

On Mon, 28 Nov 2016 22:57:40 +0100
Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> wrote:

> That's really?counterproductive when combined with SELinux !
> 
> At the moment, if a malicious version of getty gets into the system,
> it is granted sys_admin capability permissions (which includes
> privileged and administrative operations).
> 
> On the other hand, a normal, tight policy (which does not grant the
> unneeded sys_admin permission) would prevent a malicious getty from
> carrying out privileged and administrative operations which can damage
> the system and/or disrupt its normal operation.

Well, a malicious binary tagged getty_t and running with root
privileges could easily wreak enough havoc that the availability or
non-availability of CAP_SYS_ADMIN access is somewhat irrelevant.

Anyway, I've just revisited the discussion about agetty's cap_sys_admin
permission we've had in March. Looks like it may be required on some
non-grsec systems, too. (Grep the ML history for the subject "Allow
getty the sys_admin capability").

Regards,
Luis