[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kernel-hardening
Subject:    Re: [PATCH] Restrict access to TIOCLINUX
From:       Jordan Glover <Golden_Miller83 () protonmail ! ch>
Date:       2023-04-04 21:54:50
Message-ID: FOFeJXer4RVQAe5RPxTFP5O4QbHgzTJ-HjZSftfcdO9dK5OMKEfaD2iJ8BiOWxtzfbpGl_t0hcsPrQToQ72Dc3D3seQ5joggnqEmuKOLBcg= () protonmail ! ch
[Download RAW message or body]

On Sunday, April 2nd, 2023 at 7:44 PM, Greg KH <gregkh@linuxfoundation.org> 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@linuxfoundation.org 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@kroah.com/raw


[prev in list] [next in list] [prev in thread] [next in thread]