From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Mon, 7 Mar 2016 10:02:05 -0500 Subject: [refpolicy] [PATCH] Allow getty the sys_admin capability In-Reply-To: <20160305153847.09ba84ee@gentp.lnet> References: <1457057118-4361-1-git-send-email-aranea@aixah.de> <56D98968.30104@tresys.com> <56D9AFA9.503@gmail.com> <56DACE7F.7090502@m4x.org> <20160305153847.09ba84ee@gentp.lnet> Message-ID: <56DD97ED.6050201@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 3/5/2016 9:38 AM, Luis Ressel wrote: > On Sat, 5 Mar 2016 13:18:07 +0100 > Nicolas Iooss wrote: > >> On 03/04/2016 04:54 PM, Dominick Grift wrote: >>> On 03/04/2016 02:11 PM, 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. >>> >>> >>> My getty requests this permission as well [1] and i am not using >>> grsecurity. Although, i am not sure if the permission is absolutely >>> needed. (then again I do not believe that it requests it for its >>> health alone) >> >> Hello, as I was wondering what was behind agetty requiring sys_admin >> capabilities and what would happen if the access is denied, I took a >> look to its source code. The TIOCSTI ioctl (the mechanism which >> allows injecting characters in a terminal input queue) seems to only >> been used in a function named wait_for_term_input [1]. This allows >> the user input to be seen as a "normal input" while >> wait_for_term_input temporarily configured the terminal with ICANON, >> ECHO... attributes disabled. >> >> If the ioctl(fd, TIOCSTI, buffer + i) call fails (for example because >> sys_admin is not granted by SELinux), this is silently ignored. As >> far as I understand the code, wait_for_term_input function is only >> used at the beginning of the login prompt (the characters are echoed >> to the terminal) and not the password prompt. Therefore the user may >> get the feeling that the first typed character has been dropped >> somewhere. Is that so? Are there other annoyances that I missed in >> my quick analysis? >> > > Yes, the first character of the username is dropped. It isn't just > missing from the terminal output, though; it doesn't reach 'login' > either, so you really have to type it in twice. I'm merging the patch because of this. If anyone takes the time to fix the code in the future, we can always remove the permission. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com