[refpolicy] [PATCH] Allow getty the sys_admin capability

[refpolicy] [PATCH] Allow getty the sys_admin capability

[Luis Ressel]

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.)
---
 policy/modules/system/getty.te | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/policy/modules/system/getty.te b/policy/modules/system/getty.te
index f6743ea..80fec66 100644
--- a/policy/modules/system/getty.te
+++ b/policy/modules/system/getty.te
@@ -33,7 +33,7 @@ files_pid_file(getty_var_run_t)
 #
 
 # Use capabilities.
-allow getty_t self:capability { dac_override chown setgid sys_resource sys_tty_config fowner fsetid };
+allow getty_t self:capability { dac_override chown setgid sys_admin sys_resource sys_tty_config fowner fsetid };
 dontaudit getty_t self:capability sys_tty_config;
 allow getty_t self:process { getpgid setpgid getsession signal_perms };
 allow getty_t self:fifo_file rw_fifo_file_perms;
@@ -102,11 +102,6 @@ ifdef(`distro_gentoo',`
 	sysnet_dns_name_resolve(getty_t)
 ')
 
-ifdef(`distro_redhat',`
-	# getty requires sys_admin #209426
-	allow getty_t self:capability sys_admin;
-')
-
 ifdef(`distro_ubuntu',`
 	optional_policy(`
 		unconfined_domain(getty_t)
-- 
2.7.2

[refpolicy] [PATCH] Allow getty the sys_admin capability

[Christopher J. PeBenito]

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.


> ---
>  policy/modules/system/getty.te | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/policy/modules/system/getty.te b/policy/modules/system/getty.te
> index f6743ea..80fec66 100644
> --- a/policy/modules/system/getty.te
> +++ b/policy/modules/system/getty.te
> @@ -33,7 +33,7 @@ files_pid_file(getty_var_run_t)
>  #
>  
>  # Use capabilities.
> -allow getty_t self:capability { dac_override chown setgid sys_resource sys_tty_config fowner fsetid };
> +allow getty_t self:capability { dac_override chown setgid sys_admin sys_resource sys_tty_config fowner fsetid };
>  dontaudit getty_t self:capability sys_tty_config;
>  allow getty_t self:process { getpgid setpgid getsession signal_perms };
>  allow getty_t self:fifo_file rw_fifo_file_perms;
> @@ -102,11 +102,6 @@ ifdef(`distro_gentoo',`
>  	sysnet_dns_name_resolve(getty_t)
>  ')
>  
> -ifdef(`distro_redhat',`
> -	# getty requires sys_admin #209426
> -	allow getty_t self:capability sys_admin;
> -')
> -
>  ifdef(`distro_ubuntu',`
>  	optional_policy(`
>  		unconfined_domain(getty_t)
> 


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH] Allow getty the sys_admin capability

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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)

[1]
https://github.com/DefenSec/dssp-contrib/blob/master/services/getty/poli
cy.cil#L22

> 
>> --- policy/modules/system/getty.te | 7 +------ 1 file changed, 1
>> insertion(+), 6 deletions(-)
>> 
>> diff --git a/policy/modules/system/getty.te
>> b/policy/modules/system/getty.te index f6743ea..80fec66 100644 
>> --- a/policy/modules/system/getty.te +++
>> b/policy/modules/system/getty.te @@ -33,7 +33,7 @@
>> files_pid_file(getty_var_run_t) #
>> 
>> # Use capabilities. -allow getty_t self:capability { dac_override
>> chown setgid sys_resource sys_tty_config fowner fsetid }; +allow
>> getty_t self:capability { dac_override chown setgid sys_admin
>> sys_resource sys_tty_config fowner fsetid }; dontaudit getty_t
>> self:capability sys_tty_config; allow getty_t self:process {
>> getpgid setpgid getsession signal_perms }; allow getty_t
>> self:fifo_file rw_fifo_file_perms; @@ -102,11 +102,6 @@
>> ifdef(`distro_gentoo',` sysnet_dns_name_resolve(getty_t) ')
>> 
>> -ifdef(`distro_redhat',` -	# getty requires sys_admin #209426 -
>> allow getty_t self:capability sys_admin; -') - 
>> ifdef(`distro_ubuntu',` optional_policy(` 
>> unconfined_domain(getty_t)
>> 
> 
> 


- -- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJW2a+lAAoJECV0jlU3+UdpRSkL/jLOg9XKppMb2f2l90pWdtga
b9bDSyqUOvifgAEf0C57hfYH/Ji7IrfKI26QTuq7KZPbHs2XzepHDYO6RB1HEZwx
t35dEAp5FTV2lqXBdh4AMUSlI3LTO16u+JekQBivPQMEdR4dUFsHY4gcHBpwFtdG
t73dZv2IEXhi5LaHxCiwa0UELjntpojmJ6ToZys3h4CIknLINbYyy0A2rDBOBSLc
cAxWvXCX40yzNt8MEzXjZ8oL+eNYF8Z+TgGyTpBZPwXR2Y/3I1343GOt0+Lp68As
qilss1SokaeGkOaLnPi17BGZTbrrGkwBLiZCWqoGLJ5ZBf5vcZf5k6ifLcmw7BKP
z9kxU4+ZiRkMrdMUVbyoH74FcRDH7kF+V7fVBVsFKCwS3hryJLAZz5P4p7za46a8
3UJ8M4gByNOkG03KGuisp+18bF4GUMZWZ39k80IlM+h8mQMg/6CGmc9CdBbXWbF1
zCNsFsOfouin2124mebbWzzN7AqehqzyRK0Jt2NQ/g==
=n+Oa
-----END PGP SIGNATURE-----

[refpolicy] [PATCH] Allow getty the sys_admin capability

[Nicolas Iooss]

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?

Anyway, before grsecurity added a test for sys_admin when a process uses
TIOCSTI ioctl on its own tty, the capability has already been granted
when distro_redhat is enabled.  The comment which is associated to this
access, "getty requires sys_admin #209426", is not clear to me.  Where
could I find more information about this bug report?

Cheers,
Nicolas

[1]
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/term-utils/agetty.c?h=v2.27.1#n1659

[refpolicy] [PATCH] Allow getty the sys_admin capability

[Jason Zaman]

On Sat, Mar 05, 2016 at 01:18:07PM +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?
> 
> Anyway, before grsecurity added a test for sys_admin when a process uses
> TIOCSTI ioctl on its own tty, the capability has already been granted
> when distro_redhat is enabled.  The comment which is associated to this
> access, "getty requires sys_admin #209426", is not clear to me.  Where
> could I find more information about this bug report?

I assume this:
https://bugzilla.redhat.com/show_bug.cgi?id=209426

but i get:
You are not authorized to access bug #209426. To see this bug, you must
first log in to an account with the appropriate permissions.

-- Jason

[refpolicy] [PATCH] Allow getty the sys_admin capability

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/05/2016 01:18 PM, 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?
> 
> Anyway, before grsecurity added a test for sys_admin when a process
> uses TIOCSTI ioctl on its own tty, the capability has already been
> granted when distro_redhat is enabled.  The comment which is
> associated to this access, "getty requires sys_admin #209426", is
> not clear to me.  Where could I find more information about this
> bug report?
> 

Seems to be a private bug report

https://bugzilla.redhat.com/show_bug.cgi?id=209426

I personally am of the opinion that we generally should not decide
what a process can and cannot do. If it requests it, and if it is not
a bug then I think it should be allowed.

> Cheers, Nicolas
> 
> [1] 
> https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/term-
utils/agetty.c?h=v2.27.1#n1659
>
> 
_______________________________________________
> refpolicy mailing list refpolicy at oss.tresys.com 
> http://oss.tresys.com/mailman/listinfo/refpolicy
> 


- -- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJW2uA/AAoJECV0jlU3+UdpI+AMAI4FKdRYnomRI8MQMvdijRm4
G4K2/sx2iTLV+UlnB06I4J7J6Sfm5kwyjbkMrHH9+t+NoiZLWqCxlTk9q7fN/Ktx
XC0BSPQOltJ+/BN2ohWF8or4VZb2Re9gnqwl0EtOuID9ekFJuwdixFHhFcTGBPMm
4B3W6uR7sSY9cNeNJOZ0pJjciUNktNeupgBV1MDbFyeSG0wNvnAzxeYUoEnE25Sw
HnTBN+/8fk9kGeTSl3ShCxvLhBluOVqQCVmq5ZdnsUGP95uPn1/XUUgy146epXGx
+Mmy7lcEUPviBMhKq5IrUsYbZJoPMZr6Xdd/W5j2J0EUyY21W0lIbDLd4ica5Qsy
sqsd4OCL785BHJFD/eLK2LlPR696aISlCcjpp96+nUbz8M2i8zJzxhSbk/sByeQH
IizWBtfmShq9NegQKQU8HbX3uVSXJ2Eu6w+74WuUnHsCMQvhbT9llNn5bV6FRagS
LkFLjXFmWnuFw3QhcYLZ4HoljUBBupqCtpJhSlOD0w==
=5N+h
-----END PGP SIGNATURE-----

[refpolicy] [PATCH] Allow getty the sys_admin capability

[Luis Ressel]

On Sat, 5 Mar 2016 13:18:07 +0100
Nicolas Iooss <nicolas.iooss@m4x.org> 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.

-- 
Regards,
Luis Ressel

[refpolicy] [PATCH] Allow getty the sys_admin capability

[Christopher J. PeBenito]

On 3/5/2016 9:38 AM, Luis Ressel wrote:
> On Sat, 5 Mar 2016 13:18:07 +0100
> Nicolas Iooss <nicolas.iooss@m4x.org> 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

[refpolicy] [PATCH] Allow getty the sys_admin capability

[Luis Ressel]

On Fri, 4 Mar 2016 08:11:04 -0500
"Christopher J. PeBenito" <cpebenito@tresys.com> 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. :)

-- 
Regards,
Luis Ressel

[refpolicy] [PATCH] Allow getty the sys_admin capability

[Jason Zaman]

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" <cpebenito@tresys.com> 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

[refpolicy] [PATCH] Allow getty the sys_admin capability

[Luis Ressel]

On Sun, 6 Mar 2016 00:15:37 +0800
Jason Zaman <jason@perfinion.com> wrote:

> 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.
> 

Have a look at agetty.c, grep for TIOCSTI. It's not a bug, but it looks
like bad engineering. They prematurely read a single char, then insert
it back into the input stream via TIOCSTI (instead of just remembering
it in a temporary buffer).

> I have not noticed this on my machine yet, what version of kernel and
> agetty causes this?
> 

agetty since at least util-linux version 2.26, in combination with the
CONFIG_GRKERNSEC_HARDEN_TTY kernel config (which is a very new grsec
feature; it's in hardened-sources-4.4.3, perhaps also in 4.4.2, but not
in <=4.3.5).

In case you haven't noticed yet, I've opened a gentoo bug for
discussion: https://bugs.gentoo.org/show_bug.cgi?id=576522

-- 
Regards,
Luis Ressel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160305/367fb9a4/attachment-0001.bin 

[refpolicy] [PATCH] Allow getty the sys_admin capability

[Nicolas Iooss]

On 03/05/2016 05:43 PM, Luis Ressel wrote:
> On Sun, 6 Mar 2016 00:15:37 +0800
> Jason Zaman <jason@perfinion.com> wrote:
> 
>> 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.
>>
> 
> Have a look at agetty.c, grep for TIOCSTI. It's not a bug, but it looks
> like bad engineering. They prematurely read a single char, then insert
> it back into the input stream via TIOCSTI (instead of just remembering
> it in a temporary buffer).

Between the read and the ioctl calls there is "tcsetattr(fd, TCSANOW,
&orig);", which is very important: it restores the attributes of the
tty.  The characters which were read were not shown on the tty because
wait_for_term_input begins by setting the tty in "noecho" mode.

For printable characters, the use of TIOCSTI may be replaced with calls
to putc and ungetc, and special characters (like Ctrl-ed keys) would
need special care in this situation (I do not know which one: ignoring
them or showing them anyway).

In short I do not think there is an quick&easy work-around of the way it
is currently implemented.  Anyway disabling "agetty --reload" feature as
suggested in Gentoo #576522 disables this part of the code.

> 
>> I have not noticed this on my machine yet, what version of kernel and
>> agetty causes this?
>>
> 
> agetty since at least util-linux version 2.26, in combination with the
> CONFIG_GRKERNSEC_HARDEN_TTY kernel config (which is a very new grsec
> feature; it's in hardened-sources-4.4.3, perhaps also in 4.4.2, but not
> in <=4.3.5).

and also with this feature enabled if you use sysctl, with
/proc/sys/kernel/grsecurity/harden_tty (I forgot this on my machine when
I first tried to reproduce the issue).