From: jason@perfinion.com (Jason Zaman) Date: Sun, 6 Mar 2016 00:15:37 +0800 Subject: [refpolicy] [PATCH] Allow getty the sys_admin capability In-Reply-To: <20160305165557.1935e8b9@gentp.lnet> References: <1457057118-4361-1-git-send-email-aranea@aixah.de> <56D98968.30104@tresys.com> <20160305165557.1935e8b9@gentp.lnet> Message-ID: <20160305161537.GA30514@meriadoc.perfinion.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Sat, Mar 05, 2016 at 04:55:57PM +0100, Luis Ressel wrote: > On Fri, 4 Mar 2016 08:11:04 -0500 > "Christopher J. PeBenito" wrote: > > > On 3/3/2016 9:05 PM, Luis Ressel wrote: > > > It's required for agetty on kernels with a recent grsecurity > > > patchset. (The denial itself has been showing up for quite some > > > time, but it hasn't had any obvious ill effects until recently.) > > > > I'm reluctant to add this because it is a significant permission and > > grsecurity is not commonly used with SELinux, to my knowledge. > > > > The ML seems to have eaten this mail, so I'm resending it. Apologies if > it arrives twice. > > agetty already has enough access permissions so that someone who's > hacked it has compromised the system anyway, so CAP_SYS_ADMIN doesn't > really matter in this context. > > But I agree that CAP_SYS_ADMIN is a "monster" permission that shouldn't > be handed out unless really neccessary, so I'm fine if we don't add it > to refpolicy. > > I'll fix it on the gentoo side, then; either with a distro_gentoo block > in the policy or with an agetty patch. > > By the way, most -- if not all -- gentoo users of SELinux use it in > conjunction with grsecurity. That probably doesn't qualify as "common > usage", though. :) We're all agreed that this perm sucks, but if it really is required on grsec that is justification enough for me to take the patch in gentoo even if it does not make it into refpolicy. If at all possible, I would obviously prefer to have agetty fixed. If only the first character is eaten that is rather strange so perhaps there is a real bug. If a fix is not possible then we just fall back to a distro_gentoo() block. I have not noticed this on my machine yet, what version of kernel and agetty causes this? -- Jason