linux-kernel - Re: [PATCH] tty: change the privilege required for tty operarions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2fed8f4.8c4.18d0c8c1269.Coremail.mengjingzi@iie.ac.cn>
Date: Mon, 15 Jan 2024 17:55:22 +0800 (GMT+08:00)
From: 孟敬姿 <mengjingzi@....ac.cn>
To: "Greg KH" <gregkh@...uxfoundation.org>
Cc: jirislaby@...nel.org, linux-kernel@...r.kernel.org, 
	linux-serial@...r.kernel.org
Subject: Re: [PATCH] tty: change the privilege required for tty operarions

&gt; Tested how?  

First of all, this change is not about functionality, only about permissions. 
I wrote 3 testcases which calls ioctl() with TIOCSTI, TIOCCONS, TIOCVHANGUP 
respectively. Then execute them on the origin kernel and patched kernel. 
Running it on both sets of kernels gives the same result. However, through
the system error message, and the kernel log output I added, I confirmed 
that the relevant functionality under the origin kernel requires sys_admin, 
and under the patched kernel requires sys_tty_config.

Indeed, it doesn't have much to do with the distro either, I just tested it 
on Debian, and similar tests can be done on other distros.

&gt; Why did you just change these 3 usages, and not all of them?  Why are
&gt; these "safe" but the others not?

There are 5 capability checks in this file, all using sys_admin. The first 
one is in the tiocsti function, in commit 690c8b804ad2 ("TIOCSTI: always 
enable for CAP_SYS_ADMIN"), sys_admin was introduced for a special 
application BRLTTY, so I hesitated to change it. In fact, BRLTTY has both 
sys_admin and sys_tty_config, so modify the kernel's permission check, will 
not affect BRLTTY's function. The other permission check is located in a 
different function, not triggered by ioctl, so it's not written together.

&gt; And most importantly of all, why make this change at all?  Who is using
&gt; capabilities these days in a fine-grained way to warrent this type of
&gt; modification?

I guess you are right, there's not a lot of people using capabilities. 
But the idea of a least privilege design is still tempting from a 
security point of view. The scarce use of capabilities is related to 
its problematic implementation, and we hope to promote its use by 
improving its implementation. sys_admin is a relatively large privilege, 
which may pose a risk to the system （check the cve list:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CAP_SYS_ADMIN ), and by 
reducing the unnecessary use of sys_admin, we can avoid some of the risks. 
In particular, the linux capability has been designed with sys_tty_config, 
so it should take over the privileges originally managed by sys_admin 
related to TTY.

Best regards,
Jingzi