Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

[One Thousand Gnomes]

On Tue, 25 Apr 2017 15:56:32 +0200
Jann Horn  wrote:

> On Tue, Apr 25, 2017 at 3:47 PM, Alan Cox  wrote:
> >> There could be a few user programs that would be effected by this
> >> change.
> >> See: 
> >> notable programs are: agetty, csh, xemacs and tcsh
> >>
> >> However, I still believe that this change is worth it given that the
> >> Kconfig defaults to n. This will be a feature that is turned on for the
> >> same reason that people activate it when using grsecurity. Users of this
> >> opt-in feature will realize that they are choosing security over some OS
> >> features  
> >
> > Only in this case they are not.
> >
> > If I am at the point I have the ability to send you TIOCSTI you already
> > lost because I can just open /dev/tty to get access to my controlling tty
> > and use write().  
> 
> In terms of PTYs, this patch does not try to prevent writes to a slave
> device (which afaik is what /dev/tty will give you). It tries to prevent the
> equivalent of writes to the master device. As far as I know, there is no
> way to go from a slave to the corresponding master without having
> access to the master in some other way already.

Ok so the point I was trying to make about write and read is I can
already trash your channel when you su. Probably less irritatingly.

In the pty case yes I can go from the tty to pty trivially and then open
it, however the owner of the pty side would normally have exclusivity so
while it's a potential hole it isn't a trivial one.

If I want to do the equvalent of the TIOCSTI attack then I fork a process
and exit the parent. The child can now use ptrace to reprogram your shell
to do whatever interesting things it likes (eg running child processes
called "su" via a second pty/tty pair). Not exactly rocket science.

The tty layer does not try to manage this because it can't and two
processes with the same uid are not protected from one another in the
traditional Unix model. As with anything else when you try and glue
namespaces on top of a model not designed for it you get a pile of holes.

There is no safe way to fix it if you can't trust the environment you are
communicating through. Secure practice is either to make another
connection or if local to switch console and use SAK then login.

In the namespaces case it certainly makes sense to forbid a process in
one namespace from typing characters into another namespace but to me
that implies that tty sessions/job control are namespaced, and that makes
transitioning namespace or even just typing stuff into a docker container
shell rather more tricky to get right if you have to be in the right tty
session _and_ namespace to use the tty.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

[One Thousand Gnomes]

> Really? By "pty", are you referring to the master? If so, as far as I know,
> to go from the slave to the master, you need one of:
> 
>  - ptrace access to a process that already has an FD to the master, via
>ptrace() or so (/proc/$pid/fd/$fd won't work)
>  - for a BSD PTY (which AFAIK isn't used much anymore), access to
>/dev/ptyXX

fstat() and then open *assuming* I have permissions.

> 
> Am I overlooking something?
> 
> > If I want to do the equvalent of the TIOCSTI attack then I fork a process
> > and exit the parent. The child can now use ptrace to reprogram your shell
> > to do whatever interesting things it likes (eg running child processes
> > called "su" via a second pty/tty pair). Not exactly rocket science.  
> 
> Why would the child be able to ptrace the shell? AFAICS, in the most
> relevant scenarios, the child can't ptrace the shell because the
> shell has a different UID (in the case of e.g. su or sudo). In other

If I am the attacker wanting to type something into your su when you go
and su from my account, or where the user account is trojanned I do the
following

fork
exit parent
child ptraces the shell (same uid as it's not setuid)

You type "su" return
The modified shell opens a new pty/tty pair and runs su over it
My ptrace hooks watch the pty/tty traffic until you go to the loo
My ptrace hooks switch the console 
My ptrace hooks type lots of stuff and hack your machine while eating the
output

and you come back, do stuff and then exit

And if you are in X it's even easier and I don't even need to care about
sessions or anything. X has no mechanism to sanely fix the problem, but
Wayland does.

Fortunately in any sane container case we don't give X11 handles to the
container contents. In insane cases (flatpak for example) you lose.

> scenarios, Yama, if enabled, should still stop you from doing that.
> And even with containers that have the same UID as the calling user,
> which I think is not exactly a good approach from a security perspective,
> the PID namespace should stop you from ptracing things outside the
> container.

For the case where the goal is to stop something leaking out of a
container then I agree entirely - namespaces can be used to play
whackamole with that particular one or you could use a pty/tty pair which
is how "sudo" solves the same problem space.

Disabling TIOCSTI via some magic Kconfig is silly, but making it
namespace hard is not.

If you really care about container security you could just a lightweight
vm instead but that's a different discussion ;-)

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

[One Thousand Gnomes]

> open() what? As far as I know, for System-V PTYs, there is no path you can
> open() that will give you the PTY master. Am I missing something?

Sorry brain fade - no.
> 
> >> > If I want to do the equvalent of the TIOCSTI attack then I fork a process
> >> > and exit the parent. The child can now use ptrace to reprogram your shell
> >> > to do whatever interesting things it likes (eg running child processes
> >> > called "su" via a second pty/tty pair). Not exactly rocket science.  
> >>
> >> Why would the child be able to ptrace the shell? AFAICS, in the most
> >> relevant scenarios, the child can't ptrace the shell because the
> >> shell has a different UID (in the case of e.g. su or sudo). In other  
> >
> > If I am the attacker wanting to type something into your su when you go
> > and su from my account, or where the user account is trojanned I do the
> > following
> >
> > fork
> > exit parent
> > child ptraces the shell (same uid as it's not setuid)
> >
> > You type "su" return
> > The modified shell opens a new pty/tty pair and runs su over it
> > My ptrace hooks watch the pty/tty traffic until you go to the loo
> > My ptrace hooks switch the console
> > My ptrace hooks type lots of stuff and hack your machine while eating the
> > output
> >
> > and you come back, do stuff and then exit
> >
> > And if you are in X it's even easier and I don't even need to care about
> > sessions or anything. X has no mechanism to sanely fix the problem, but
> > Wayland does.  
> 
> I think the "When using a program like su or sudo" in the patch description
> refers to the usecase where you go from a more privileged context (e.g. a
> root shell) to a less privileged one (e.g. a shell as a service-specific
> account used to run a daemon), not the other way around.

Which is the sudo case and why sudo uses a separate pty/tty pair as it's
not just TIOCSTI that's an issue but there are a load of ioctls that do
things like cause signals to the process or are just annoying -
vhangup(), changing the speed etc

(And for console changing the keymap - which is a nasty one)

> [However, I do think that it's a nice side effect of this patch that it will
> prevent a malicious program from directly injecting something like an
> SSH command into my shell in a sufficiently hardened environment
> (with LSM restrictions that prevent the malicious program from opening
> SSH keyfiles or executing another program that can do that). Although
> you could argue that in such a case, the LSM should be taking care of
> blocking TIOCSTI.]

I would submit that creating a new pty/tty pair is the proper answer for
that case however. Making the tty calls respect namespaces is however
still a no-brainer IMHO.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

[One Thousand Gnomes]

> > Which is the sudo case and why sudo uses a separate pty/tty pair as it's
> > not just TIOCSTI that's an issue but there are a load of ioctls that do
> > things like cause signals to the process or are just annoying -
> > vhangup(), changing the speed etc
> >
> > (And for console changing the keymap - which is a nasty one)
> >  
> 
> Are any of these annoyances potential security issues? I would be happy
> to add patches or modify this one to include extra hardening measures.

Or you could just use pty/tty pairs properly the way sudo and other
applications do perfectly well.

Lots of them are potential security issues - if I sent your console to
1x1 char, change the font and keymap you'd proably be peeved 8-)

It's not about hardening against all these (which would break lots of
legitimate use cases), it's about having the affected applications do the
right thing.

It makes sense that TIOCSTI honours namespaces. However it and everything
else are correctly handled by creating the lower security level process
with its own pty/tty pair.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[One Thousand Gnomes]

> DocBook is a means to an end; nobody really wants DocBook itself as far
> as I can tell. 

We only have docbook because it was the tool of choice rather a lot of
years ago to then get useful output formats. It was just inherited when
borrowed the original scripts from Gnome/Gtk. It's still the most
effective way IMHO of building big structured documents out of the kernel.

The Gtk people long ago rewrote the original document script into a real
tool so they have some different and maintained tools that are close to
equivalent and already have some markdown support. Before we go off and
re-invent the wheel it might be worth just borrowing their wheel and
tweaking it as needed ? In particular they can generate help indexes so
that the entire output becomes nicely browsable with an HTML based help
browser.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] Intel Secure Guard Extensions

[One Thousand Gnomes]

> Replay Protected Memory Block.  It's a device that allows someone to
> write to it and confirm that the write happened and the old contents
> is no longer available.  You could use it to implement an enclave that
> checks a password for your disk but only allows you to try a certain
> number of times.

rpmb is found in a load of hardware today notably MMC/SD cards. Android
phones often use it to store sensitive system data.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] Intel Secure Guard Extensions

[One Thousand Gnomes]

> > Storing your ssh private key encrypted such that even someone who
> > completely compromises your system can't get the actual private key  
> 
> Well, if someone gets root on my system, he can get my ssh private
> key right?

Potentially not. If you are using a TPM or other TEE (such as SGX) they
can't because the authentication is done from within the TEE. They may be
able to hack your box and use the TEE to login somewhere but not to get
the key out.

Stopping the latter requires a TEE with its own secure input keypad (like
some of the USB dongles)

Other uses might be things like keeping a copy of the rpm database so you
can ask the TEE if the database you have right now happens to match the
one you signed as authentic. I suspect there are lots of interesting
things that can be done with dm_crypt and also IMA in this area too.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] Intel Secure Guard Extensions

[One Thousand Gnomes]

> But... that will mean that my ssh will need to be SGX-aware, and that
> I will not be able to switch to AMD machine in future. ... or to other
> Intel machine for that matter, right?

I'm not privy to AMD's CPU design plans.

However I think for the ssl/ssh case you'd use the same interfaces
currently available for plugging in TPMs and dongles. It's a solved
problem in the crypto libraries.

> What new syscalls would be needed for ssh to get all this support?

I don't see why you'd need new syscalls.

> Ookay... I guess I can get a fake Replay Protected Memory block, which
> will confirm that write happened and not do anything from China, but

It's not quite that simple because there are keys and a counter involved
but I am sure doable.

> And, again, it means that quite complex new kernel-user interface will
> be needed, right?

Why ? For user space we have perfectly good existing system calls, for
kernel space we have existing interfaces to the crypto and key layers for
modules to use.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[One Thousand Gnomes]

> I took a closer look at the dosemu code. It appears that it does not

That doesn't tell you want DOS itself will try and do...

> purposely utilize SGDT to obtain the descriptor table while in vm86. It
> does use SGDT (in protected mode) to emulate certain functionality such
> as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
> However, this code seems to be disabled [1]. dosemu includes an i386
> emulator that in some cases uses the actual instructions of the host
> system. In such cases, UMIP might be needed to be disabled.

Is anyone actually still using DOSemu these days or are people all
using DOSbox ?

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html