On Sunday, April 2nd, 2023 at 7:44 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Sun, Apr 02, 2023 at 07:33:10PM +0200, Hanno Böck wrote: > > > On Sun, 2 Apr 2023 19:23:44 +0200 > > Greg KH gregkh@xxxxxxxxxxxxxxxxxxx wrote: > > > > > > Do you have other proposals how to fix this issue? One could > > > > introduce an option like for TIOCSTI that allows disabling > > > > selection features by default. > > > > > > What exact issue are you trying to fix here? > > > > The fact that the selection features of TIOCLINUX can be used for > > privilege escalation. > > > Only if you had root permissions already, and then go to try to run > something using su or sudo as someone with less permission, right? > > And as you already had permissions before, it's not really an > excalation, or am I missing something? > > > I already mentioned this in the original patch description, but I think > > the minitty.c example here illustrates this well: > > https://www.openwall.com/lists/oss-security/2023/03/14/3 > > > > Compile it, do > > sudo -u [anynonprivilegeduser] ./minitty > > > > It'll execute shell code with root permission. > > > That doesn't work if you run it from a user without root permissions to > start with, right? > > thanks, > > greg k-h The problem in the example is that sudo executed unpriv process which then re-gained the privs of sudo itself. It doesn't need to be sudo or even root - the same problem affects all containers/sandboxes (privileged or not) in linux - the (supposedly) contained process can use TIOCSTI/TIOCLINUX to break out of the container/sandbox (unless they're blocked as well). BTW: you seem in favor of restricting TIOCSTI [1] which landed in kernel so why suddenly question same problem here? [1] https://lore.kernel.org/all/Y0pIRKpPwqk2Igu%2F@xxxxxxxxx/raw
