Re: [PATCH] Restrict access to TIOCLINUX

On Sunday, April 2nd, 2023 at 7:44 PM, Greg KH <[email protected]> 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 [email protected] 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%[email protected]/raw