Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1652406 > unrolled thread

Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI  ioctl require CAP_SYS_ADMIN Peter Dolding <oiaohm@gmail.com> - 2017-05-29 12:50 +0200
    Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make  TIOCSTI ioctl require CAP_SYS_ADMIN "Serge E. Hallyn" <serge@hallyn.com> - 2017-05-30 18:00 +0200
      Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make  TIOCSTI ioctl require CAP_SYS_ADMIN Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-05-31 00:00 +0200
        Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI  ioctl require CAP_SYS_ADMIN Peter Dolding <oiaohm@gmail.com> - 2017-05-31 13:30 +0200
          Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make  TIOCSTI ioctl require CAP_SYS_ADMIN Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-05-31 16:40 +0200
            Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make  TIOCSTI ioctl require CAP_SYS_ADMIN "Serge E. Hallyn" <serge@hallyn.com> - 2017-05-31 17:40 +0200

#1652406 — Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Sat, May 20, 2017 at 12:33 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> On Fri, May 19, 2017 at 12:48:17PM +1000, Peter Dolding wrote:
>> Using cap_sys_admin as fix is like removing car windsheld because
>> vision is being blocked by a rock hitting it.
>
> Nonsense.  If the application has cap_sys_admin then it is less contained and
> more trusted anyway.  If I went to the trouble to run an application in a
> private user namespace (where it can have cap_sys_admin, but not targeted
> at my tty) then it should be more contained.  That's the point of targeted
> capabilities.

The thing that is missed every time is how much is cap_sys_admin.

So you are saying a user namespace has to be set up to contain the defect.

Really no application should have cap_sys_admin.

The theory of capabilities is that security should be broken down into
logical blocks.

So tty stuff should under a tty capabilities.

This one here should not be shoved into cap_sys_admin because can you
show a single case of a general used application performing this
action in the exploit way that is normal behaviour.

The exploits are doing behaviours that have no general place.

Its really simple to shove everything to cap_sys_admin instead of hey
lets look at the exploits how they work and if this should be fairly
blanked banned.  The behaviour that is question is being able push
chars into input stream and have them processed after application has
terminated or after application has switched to background.   That is
not pushing data into another tty.   Pushing data into a different tty
is already restricted to cap_sys_admin.

Personally from my point of view when application terminates or
switches to background  what ever it pushed back into the input buffer
should be junked and maybe a special cap to deal with rare case of
applications that expect this behavour.

Also please remember one of the application using this behaviour of
pushing stuff back to input buffer is csh.  In other words a general
user shell.   This will not be the only application that is general
usage after the change of pushing to cap_sys_admin that would also
have to be pushed to cap_sys_admin because they use TIOCSTI in a way
that the patch will block when the program does not have
cap_sys_admin.   So now you have more applications running as
cap_sys_admin so more security problems.

Peter Dolding.

[toc] | [next] | [standalone]

#1653338 — Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

Quoting Peter Dolding (oiaohm@gmail.com):
> On Sat, May 20, 2017 at 12:33 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> > On Fri, May 19, 2017 at 12:48:17PM +1000, Peter Dolding wrote:
> >> Using cap_sys_admin as fix is like removing car windsheld because
> >> vision is being blocked by a rock hitting it.
> >
> > Nonsense.  If the application has cap_sys_admin then it is less contained and
> > more trusted anyway.  If I went to the trouble to run an application in a
> > private user namespace (where it can have cap_sys_admin, but not targeted
> > at my tty) then it should be more contained.  That's the point of targeted
> > capabilities.
> 
> The thing that is missed every time is how much is cap_sys_admin.
> 
> So you are saying a user namespace has to be set up to contain the defect.
> 
> Really no application should have cap_sys_admin.
> 
> The theory of capabilities is that security should be broken down into
> logical blocks.
> 
> So tty stuff should under a tty capabilities.

(last reply on this)

Currently capabilities.7 says

              * employ  the  TIOCSTI ioctl(2) to insert characters into the input queue of a
                terminal other than the caller's controlling terminal;

for CAP_SYS_ADMIN.

So you can create a new CAP_SYS_TIOCSSTI if you like, and offer a patch where
*both* CAP_SYS_ADMIN and CAP_SYS_ADMIN suffice.  Again, see CAP_SYSLOG for a
prior example.

What you may not do is change it so that on an older kernel you must have
CAP_SYS_ADMIN to use TIOCSTI, while on a newer one it does not suffice.

-serge

[toc] | [prev] | [next] | [standalone]

#1653633 — Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

> > So tty stuff should under a tty capabilities.  
> 
> (last reply on this)
> 
> Currently capabilities.7 says
> 
>               * employ  the  TIOCSTI ioctl(2) to insert characters into the input queue of a
>                 terminal other than the caller's controlling terminal;
> 
> for CAP_SYS_ADMIN.
> 
> So you can create a new CAP_SYS_TIOCSSTI if you like, and offer a patch where
> *both* CAP_SYS_ADMIN and CAP_SYS_ADMIN suffice.  Again, see CAP_SYSLOG for a
> prior example.

Even then it wouldn't be useful because the attacker can use every other
interface in the tty layer, many of which you can't magic away behind a
capability bit. And the applications would need changing to use the
feature - at which point any theoretical broken apps can instead be fixed
to use a pty/tty pair and actually fix the real problem.

Alan

[toc] | [prev] | [next] | [standalone]

#1654141

On Wed, May 31, 2017 at 7:52 AM, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
>> > So tty stuff should under a tty capabilities.
>>
>> (last reply on this)
>>
>> Currently capabilities.7 says
>>
>>               * employ  the  TIOCSTI ioctl(2) to insert characters into the input queue of a
>>                 terminal other than the caller's controlling terminal;
>>
>> for CAP_SYS_ADMIN.
>>
>> So you can create a new CAP_SYS_TIOCSSTI if you like, and offer a patch where
>> *both* CAP_SYS_ADMIN and CAP_SYS_ADMIN suffice.  Again, see CAP_SYSLOG for a
>> prior example.
>
> Even then it wouldn't be useful because the attacker can use every other
> interface in the tty layer, many of which you can't magic away behind a
> capability bit. And the applications would need changing to use the
> feature - at which point any theoretical broken apps can instead be fixed
> to use a pty/tty pair and actually fix the real problem.
>
Alan is right.   CAP_SYS_ADMIN allows crossing the tty barrier.

Broken applications that you can wrap in a pty/tty pair as the lxc
application does would be defeated if those applications move up to
CAP_SYS_ADMIN.  Because you have granted the high right of cross
pty/tty containment.

Pushing CAP_SYS_TIOSSTI out by itself without the feature in
CAP_SYS_ADMIN means broken applications can be allowed to run in like
a lxc container where they cannot go anywhere with the exploit because
the pty/tty they are picking is not going to get them very far at all.

Pushing TIOSSTI up to CAP_SYS_ADMIN to address this problem is wrong.
 Question is also how many applications use CAP_SYS_ADMIN feature to
push chars into other pty/tty on the system.   Pushing across pty/tty
barrier may not be a suitable feature to be generically in
CAP_SYS_ADMIN in the first place.

http://www.halfdog.net/Security/2012/TtyPushbackPrivilegeEscalation/

This here is example of TIOSSTI pushback as CAP_SYS_ADMIN being bad.
I don't know of a genuine program using push back in exploiting way
where the pushed back input is expected to be processed after the
program has terminated.

Really we need to work out how many breakage will in fact be caused by
majority restricting both pushback and write across tty barrier.
This is not like CAP_SYS_LOG these are features that can be used to
exploit system badly.   It is possible that the exploiting form of
TIOSSTI pushback is used by nothing genuine userspace in any properly
functional case.   So if that is the case unconstrained TIOSSTI
push-back would only be making application crashes worse.

The reason I want TIOSSTI pushback moved to its own CAP_SYS first is
to find out if anything is in fact using it as part of genuine usage
and allowing anyone caught out to work around it.    I am sorry this
is me most likely using X11 logic break it and see if anyone yells.
If no one complains disappear the feature completely then this closes
this form of exploit for good.

Peter Dolding

[toc] | [prev] | [next] | [standalone]

#1654312 — Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

> Alan is right.   CAP_SYS_ADMIN allows crossing the tty barrier.

I don't need CAP_ anything to mmap your frame buffer, or use selection to
cut and paste text into the terminal.

> Broken applications that you can wrap in a pty/tty pair as the lxc
> application does would be defeated if those applications move up to
> CAP_SYS_ADMIN.  Because you have granted the high right of cross
> pty/tty containment.

Yes

> I don't know of a genuine program using push back in exploiting way
> where the pushed back input is expected to be processed after the
> program has terminated.

So there are two real problems here

1. We don't know what namespace each character belongs to, so there's no
way we can construct a model where pushed symbols only appear in the
namespace they are pushed from. That would be a nice situation but it's
not at all obvious there is a sane way to implement it.

2. Focussing on TIOCSTI is just ignoring the bigger picture. TIOCSTI is
actually a lot less nasty in many situations than a framebuffer mmap and
spying attack where a container run from the console could sit and watch
you. TIOCSTI is in some ways the easiest to fix because setsid() will let
you mitigate it in certain cases whereas I'm fairly sure the selection
based console attack doesn't need controlling terminal rights.

In the case you have a less privileged subshell you need a whole new tty
context, and there's no obvious way for the kernel to magic one into
existance so that for example the container can change it's own baud rate
but not the baud rate of any app outside the container.

ioctl whitelisting will break stuff, but an SELinux/AppArmour/seccomp
whitelisting based solution is probably the only practical one you can
implement usefully, and for a lot of container users would be ok.

And yes there are genuine users of TIOCSTI although these days most
things just use their own pty/tty pair.

Alan

[toc] | [prev] | [next] | [standalone]

#1654359 — Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

Quoting Alan Cox (gnomes@lxorguk.ukuu.org.uk):
> > Alan is right.   CAP_SYS_ADMIN allows crossing the tty barrier.
> 
> I don't need CAP_ anything to mmap your frame buffer, or use selection to
> cut and paste text into the terminal.
> 
> > Broken applications that you can wrap in a pty/tty pair as the lxc
> > application does would be defeated if those applications move up to
> > CAP_SYS_ADMIN.  Because you have granted the high right of cross
> > pty/tty containment.
> 
> Yes

Right.

> > I don't know of a genuine program using push back in exploiting way
> > where the pushed back input is expected to be processed after the
> > program has terminated.
> 
> So there are two real problems here
> 
> 1. We don't know what namespace each character belongs to, so there's no
> way we can construct a model where pushed symbols only appear in the
> namespace they are pushed from. That would be a nice situation but it's
> not at all obvious there is a sane way to implement it.
> 
> 2. Focussing on TIOCSTI is just ignoring the bigger picture. TIOCSTI is
> actually a lot less nasty in many situations than a framebuffer mmap and
> spying attack where a container run from the console could sit and watch
> you. TIOCSTI is in some ways the easiest to fix because setsid() will let
> you mitigate it in certain cases whereas I'm fairly sure the selection
> based console attack doesn't need controlling terminal rights.
> 
> In the case you have a less privileged subshell you need a whole new tty
> context, and there's no obvious way for the kernel to magic one into
> existance so that for example the container can change it's own baud rate
> but not the baud rate of any app outside the container.
> 
> ioctl whitelisting will break stuff, but an SELinux/AppArmour/seccomp
> whitelisting based solution is probably the only practical one you can
> implement usefully, and for a lot of container users would be ok.

Seccomp policy could refuse TIOCSTI to any fd, but that's not ideal.  It could
be customized per-application-start to only refuse TIOCSTI to the passed-in tty
fd, but you'd have to prevent dup then right?  Selinux can label the fd so it's
in fact ideal here.  But - is there something clever a seccomp policy could do
to work only on specified fds and any that were dup'ed?

Mind you, I of course agree that creating a new pty and passing only that in
is the sane fix.  Maybe in the end this thread will serve best as a loud
reminder / teaching moment about this issue for those about to write such an
application.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web