Allow getty the sys_admin capability

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(-)

policy/modules/system/getty.te +1 -6

index f6743ea..80fec66 100644
@@ -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)

Quoted 3 lines · 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.)

I'm reluctant to add this because it is a significant permission and grsecurity is not commonly used with SELinux, to my knowledge.

Quoted 19 lines

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

(quoted diff) +0 -0

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) ')

Quoted 5 lines

-ifdef(distro_redhat', - # getty requires sys_admin #209426 -
allow getty_t self:capability sys_admin; -') -
ifdef(distro_ubuntu', optional_policy(`
unconfined_domain(getty_t)

Quoted 4 lines · Christopher J. PeBenito

Quoted 3 lines · 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.)

Quoted 2 lines

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)

Quoted 6 lines · Dominick Grift

Quoted 4 lines · Christopher J. PeBenito

Quoted 3 lines · 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.)

Quoted 8 lines

Quoted 2 lines

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?

Quoted 12 lines · Dominick Grift

Quoted 9 lines · Christopher J. PeBenito

Quoted 4 lines · 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.)

I'm reluctant to add this because it is a significant permission and grsecurity is not commonly used with SELinux, to my knowledge.

Quoted 4 lines

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-

refpolicy mailing list refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

Quoted 11 lines · Dominick Grift

Quoted 8 lines · Christopher J. PeBenito

Quoted 3 lines · 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.)

I'm reluctant to add this because it is a significant permission and grsecurity is not commonly used with SELinux, to my knowledge.

Quoted 4 lines

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?

Quoted 26 lines · On Sat, 5 Mar 2016 13:18:07 +0100 Nicolas Iooss <[email protected]> wrote:

Quoted 11 lines · Dominick Grift

Quoted 8 lines · Christopher J. PeBenito

Quoted 3 lines · 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.)

I'm reluctant to add this because it is a significant permission and grsecurity is not commonly used with SELinux, to my knowledge.

Quoted 4 lines

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.

Quoted 9 lines

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.

Quoted 3 lines · 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.)

I'm reluctant to add this because it is a significant permission and grsecurity is not commonly used with SELinux, to my knowledge.

Quoted 8 lines · On Fri, 4 Mar 2016 08:11:04 -0500 "Christopher J. PeBenito"…

Quoted 3 lines · 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.)

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?

Quoted 9 lines · On Sun, 6 Mar 2016 00:15:37 +0800 Jason Zaman <[email protected]> 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).

Quoted 4 lines

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