Re: Unexpected behavior in su/doas

[Tinker]

On 2016-10-02 18:14, Chris Bennett wrote:

On Sun, Oct 02, 2016 at 01:03:28AM -0700, Philip Guenther wrote:

On Sun, Oct 2, 2016 at 12:35 AM, Otto Moerbeek  wrote:
> On Sat, Oct 01, 2016 at 05:15:31PM -0500, Chris Bennett wrote:
>
>> On Sat, Oct 01, 2016 at 03:54:40PM -0600, Theo de Raadt wrote:
>> > Use of su, doas, or sudo -- means you EXPLICITLY want the tty to
>> > remain the same.
>> >
>> > De-escalation using these "sudo" or "doas" like tools on a tty is
>> > somewhat unsafe - it has always been unsafe - because tty's have
>> > capabilities.
>> >
>> > If you wish to be safer, do these operations without retaining access
>> > to a tty.
>> >
>> > Escalation on the other hand (user -> root) is different, because then
>> > it is clear you want to do more / everything.  But de-escalation is a
>> > joke.
>> >
>> > This is just one mechanism on tty, there are others.  On other
>> > descriptors there are other abilities.
>> >
>>
>> Would you mind explaining this a little bit. I don't really mean the
>> sudo/doas part.
>>
>> How to do operations without retaining access to a tty?
>>
>> What other descriptors?
>
> Well, a lot of things are possible using descriptors. Descriptors can
> refer to files, devices, sockets to name a few. So if you have an open
> descriptor to any of them...

...and it's not just actual file descriptors that provide privileged
access: even if a process closes all fds for its controlling tty, it
remains the process's controlling tty and can still be reopened via
/dev/tty.  Similarly, simply being in the same session gives a process
additional rights that it wouldn't have otherwise, such as being able
to use tcsetpgrp() and see your login name via getlogin()...



So fork, as used in daemon does mitigate this, as long as used 
correctly?

Or does the same/other problems continue?

Chris Bennett


Doing "su" or "chroot" (symmetric with respect to this risk) is 
sometimes very convenient, as it can be done without external 
configuration as would be needed for ssh.


Would it be possible to cut the risk (file descriptors) while still 
outputting to the same terminal, ssh without ssh?

Re: Unexpected behavior in su/doas

[Chris Bennett]

On Sun, Oct 02, 2016 at 01:03:28AM -0700, Philip Guenther wrote:
> On Sun, Oct 2, 2016 at 12:35 AM, Otto Moerbeek  wrote:
> > On Sat, Oct 01, 2016 at 05:15:31PM -0500, Chris Bennett wrote:
> >
> >> On Sat, Oct 01, 2016 at 03:54:40PM -0600, Theo de Raadt wrote:
> >> > Use of su, doas, or sudo -- means you EXPLICITLY want the tty to
> >> > remain the same.
> >> >
> >> > De-escalation using these "sudo" or "doas" like tools on a tty is
> >> > somewhat unsafe - it has always been unsafe - because tty's have
> >> > capabilities.
> >> >
> >> > If you wish to be safer, do these operations without retaining access
> >> > to a tty.
> >> >
> >> > Escalation on the other hand (user -> root) is different, because then
> >> > it is clear you want to do more / everything.  But de-escalation is a
> >> > joke.
> >> >
> >> > This is just one mechanism on tty, there are others.  On other
> >> > descriptors there are other abilities.
> >> >
> >>
> >> Would you mind explaining this a little bit. I don't really mean the
> >> sudo/doas part.
> >>
> >> How to do operations without retaining access to a tty?
> >>
> >> What other descriptors?
> >
> > Well, a lot of things are possible using descriptors. Descriptors can
> > refer to files, devices, sockets to name a few. So if you have an open
> > descriptor to any of them...
> 
> ...and it's not just actual file descriptors that provide privileged
> access: even if a process closes all fds for its controlling tty, it
> remains the process's controlling tty and can still be reopened via
> /dev/tty.  Similarly, simply being in the same session gives a process
> additional rights that it wouldn't have otherwise, such as being able
> to use tcsetpgrp() and see your login name via getlogin()...
> 

So fork, as used in daemon does mitigate this, as long as used correctly?
Or does the same/other problems continue?

Chris Bennett

Re: Unexpected behavior in su/doas

[Lampshade]

> > This is just one mechanism on tty, there are others.  On other
> > descriptors there are other abilities.
> > 
> 
> Would you mind explaining this a little bit. I don't really mean the
> sudo/doas part.
> 
> How to do operations without retaining access to a tty?
>
> What other descriptors?

Example:
If you have file descriptor to directory outside chroot
and you are root user you can escape chroot.

https://filippo.io/escaping-a-chroot-jail-slash-1/

Re: Unexpected behavior in su/doas

[Philip Guenther]

On Sun, Oct 2, 2016 at 12:35 AM, Otto Moerbeek  wrote:
> On Sat, Oct 01, 2016 at 05:15:31PM -0500, Chris Bennett wrote:
>
>> On Sat, Oct 01, 2016 at 03:54:40PM -0600, Theo de Raadt wrote:
>> > Use of su, doas, or sudo -- means you EXPLICITLY want the tty to
>> > remain the same.
>> >
>> > De-escalation using these "sudo" or "doas" like tools on a tty is
>> > somewhat unsafe - it has always been unsafe - because tty's have
>> > capabilities.
>> >
>> > If you wish to be safer, do these operations without retaining access
>> > to a tty.
>> >
>> > Escalation on the other hand (user -> root) is different, because then
>> > it is clear you want to do more / everything.  But de-escalation is a
>> > joke.
>> >
>> > This is just one mechanism on tty, there are others.  On other
>> > descriptors there are other abilities.
>> >
>>
>> Would you mind explaining this a little bit. I don't really mean the
>> sudo/doas part.
>>
>> How to do operations without retaining access to a tty?
>>
>> What other descriptors?
>
> Well, a lot of things are possible using descriptors. Descriptors can
> refer to files, devices, sockets to name a few. So if you have an open
> descriptor to any of them...

...and it's not just actual file descriptors that provide privileged
access: even if a process closes all fds for its controlling tty, it
remains the process's controlling tty and can still be reopened via
/dev/tty.  Similarly, simply being in the same session gives a process
additional rights that it wouldn't have otherwise, such as being able
to use tcsetpgrp() and see your login name via getlogin()...


Philip Guenther

Re: Unexpected behavior in su/doas

[Otto Moerbeek]

On Sat, Oct 01, 2016 at 05:15:31PM -0500, Chris Bennett wrote:

> On Sat, Oct 01, 2016 at 03:54:40PM -0600, Theo de Raadt wrote:
> > Use of su, doas, or sudo -- means you EXPLICITLY want the tty to
> > remain the same.
> > 
> > De-escalation using these "sudo" or "doas" like tools on a tty is
> > somewhat unsafe - it has always been unsafe - because tty's have
> > capabilities.
> > 
> > If you wish to be safer, do these operations without retaining access
> > to a tty.
> > 
> > Escalation on the other hand (user -> root) is different, because then
> > it is clear you want to do more / everything.  But de-escalation is a
> > joke.
> > 
> > This is just one mechanism on tty, there are others.  On other
> > descriptors there are other abilities.
> > 
> 
> Would you mind explaining this a little bit. I don't really mean the
> sudo/doas part.
> 
> How to do operations without retaining access to a tty?
>
> What other descriptors?

Well, a lot of things are possible using descriptors. Descriptors can
refer to files, devices, sockets to name a few. So if you have an open
descriptor to any of them...

> 
> And, I would especially appreciate any areas in src that could more
> fully give me an understanding of this. Studying code has to be
> essential to get this.

e.g. login(1), cron(8), daemon(3) and setsid(2) and friends.

-Otto

Re: Unexpected behavior in su/doas

[Otto Moerbeek]

On Sun, Oct 02, 2016 at 07:10:12AM +0200, Sebastien Marie wrote:

> On Sat, Oct 01, 2016 at 05:15:31PM -0500, Chris Bennett wrote:
> > On Sat, Oct 01, 2016 at 03:54:40PM -0600, Theo de Raadt wrote:
> > > Use of su, doas, or sudo -- means you EXPLICITLY want the tty to
> > > remain the same.
> > > 
> > > De-escalation using these "sudo" or "doas" like tools on a tty is
> > > somewhat unsafe - it has always been unsafe - because tty's have
> > > capabilities.
> > > 
> > > If you wish to be safer, do these operations without retaining access
> > > to a tty.
> > > 
> > > Escalation on the other hand (user -> root) is different, because then
> > > it is clear you want to do more / everything.  But de-escalation is a
> > > joke.
> > > 
> > > This is just one mechanism on tty, there are others.  On other
> > > descriptors there are other abilities.
> > > 
> > 
> > Would you mind explaining this a little bit. I don't really mean the
> > sudo/doas part.
> > 
> > How to do operations without retaining access to a tty?
> > What other descriptors?
> > 
> > And, I would especially appreciate any areas in src that could more
> > fully give me an understanding of this. Studying code has to be
> > essential to get this.
> > 
> 
> there is a recent thread on oss-security about the specific problem of
> sharing tty:
> http://openwall.com/lists/oss-security/2016/09/25/1
> 
> or a more ancien stuff (same problem): 
> http://www.openwall.com/lists/oss-security/2011/12/20/2
> 
> when using doas/sudo you share a tty.
> 
> # tty
> /dev/ttypa
> # doas -u user -s
> $ tty
> /dev/ttypa
> 
> so at a moment, user has access to the tty device that root will use
> later.
> 
> for example, user is able to push chars in tty buffer, logout, and let
> the root process eats the controlled input.
> 
> alternative way (and more secure in this context) is to use ssh(1). But
> note it needs additionnal configuration. ssh(1) will allocate a new
> pty(4) device for the user.
> 
> # tty
> /dev/ttypa
> # ssh user@localhost
> Last login: ...
> OpenBSD 6.0-current ...
> ...
> 
> $ tty
> /dev/ttypb
> 
> Regards.
> -- 
> Sebastien Marie

Alternatively, you can run a command as a specific use without tty
using batch(1) or at(1).

# echo su otto -c "id; tty" | batch

The command will be executed without controlling tty. OUtput will be
reported by mail.

-Otto

Re: Unexpected behavior in su/doas

[Sebastien Marie]

On Sat, Oct 01, 2016 at 05:15:31PM -0500, Chris Bennett wrote:
> On Sat, Oct 01, 2016 at 03:54:40PM -0600, Theo de Raadt wrote:
> > Use of su, doas, or sudo -- means you EXPLICITLY want the tty to
> > remain the same.
> > 
> > De-escalation using these "sudo" or "doas" like tools on a tty is
> > somewhat unsafe - it has always been unsafe - because tty's have
> > capabilities.
> > 
> > If you wish to be safer, do these operations without retaining access
> > to a tty.
> > 
> > Escalation on the other hand (user -> root) is different, because then
> > it is clear you want to do more / everything.  But de-escalation is a
> > joke.
> > 
> > This is just one mechanism on tty, there are others.  On other
> > descriptors there are other abilities.
> > 
> 
> Would you mind explaining this a little bit. I don't really mean the
> sudo/doas part.
> 
> How to do operations without retaining access to a tty?
> What other descriptors?
> 
> And, I would especially appreciate any areas in src that could more
> fully give me an understanding of this. Studying code has to be
> essential to get this.
> 

there is a recent thread on oss-security about the specific problem of
sharing tty:
http://openwall.com/lists/oss-security/2016/09/25/1

or a more ancien stuff (same problem): 
http://www.openwall.com/lists/oss-security/2011/12/20/2

when using doas/sudo you share a tty.

# tty
/dev/ttypa
# doas -u user -s
$ tty
/dev/ttypa

so at a moment, user has access to the tty device that root will use
later.

for example, user is able to push chars in tty buffer, logout, and let
the root process eats the controlled input.

alternative way (and more secure in this context) is to use ssh(1). But
note it needs additionnal configuration. ssh(1) will allocate a new
pty(4) device for the user.

# tty
/dev/ttypa
# ssh user@localhost
Last login: ...
OpenBSD 6.0-current ...
...

$ tty
/dev/ttypb

Regards.
-- 
Sebastien Marie

Re: Unexpected behavior in su/doas

[Chris Bennett]

On Sat, Oct 01, 2016 at 03:54:40PM -0600, Theo de Raadt wrote:
> Use of su, doas, or sudo -- means you EXPLICITLY want the tty to
> remain the same.
> 
> De-escalation using these "sudo" or "doas" like tools on a tty is
> somewhat unsafe - it has always been unsafe - because tty's have
> capabilities.
> 
> If you wish to be safer, do these operations without retaining access
> to a tty.
> 
> Escalation on the other hand (user -> root) is different, because then
> it is clear you want to do more / everything.  But de-escalation is a
> joke.
> 
> This is just one mechanism on tty, there are others.  On other
> descriptors there are other abilities.
> 

Would you mind explaining this a little bit. I don't really mean the
sudo/doas part.

How to do operations without retaining access to a tty?
What other descriptors?

And, I would especially appreciate any areas in src that could more
fully give me an understanding of this. Studying code has to be
essential to get this.

Thank you very much,
Chris Bennett