Bypass doas password check with chroot

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Bypass doas password check with chroot

chohag
This isn't a bug per se, more of an incongruity in how security-centric tools work wrt root, specifically doas and chroot/su/other:

  joe@drogo$ doas -s
  drogo# doas -u chohag -s
  doas (root@drogo) password:
  doas: Authorization failed
  drogo# chroot -u chohag /
  drogo$ ^D
  drogo# su -l chohag
  drogo$ ^D

Obviously a little one-liner or tiny C app could achieve the same result too.

I assume this is more or less known, since each tool is working to its designed spec, so is the above ultimately the desired behaviour? Should doas ask even for root's password while myriad other ways of obtaining any user ID do and probably always will exist?

On some servers root doesn't have a password.

Matthew

Reply | Threaded
Open this post in threaded view
|

Re: Bypass doas password check with chroot

Ingo Schwarze
Hi Matthew,

[hidden email] wrote on Tue, Jul 02, 2019 at 11:43:13AM +0300:

> This isn't a bug per se,

Indeed not a bug.

> more of an incongruity in how security-centric tools work wrt root,

Sure.  Different tools are different.  In particular, in addition
to major differences in behaviour that were the reason for having
different tools in the first place, minor differences may also
exists.

> specifically doas and chroot/su/other:
>
>   joe@drogo$ doas -s
>   drogo# doas -u chohag -s
>   doas (root@drogo) password:
>   doas: Authorization failed
>   drogo# chroot -u chohag /
>   drogo$ ^D
>   drogo# su -l chohag
>   drogo$ ^D
>
> Obviously a little one-liner or tiny C app could achieve the same result too.
>
> I assume this is more or less known, since each tool is working to its
> designed spec, so is the above ultimately the desired behaviour?
> Should doas ask even for root's password while myriad other ways of
> obtaining any user ID do and probably always will exist?

I see nothing wrong with it.  It is easier to describe in the manual
page: since authorization is always checked, nothing needs to be said
about it, in particular no special case for root needs to be explained.
Then again, given that root is all-powerful in the first place (as
you noted), it doesn't matter either way, really.

The bikeshed has already been painted, and no matter whether you are
justified in calling the colour that tedu@ chose "pink", i wouldn't
see an obvious benefit in re-painting it now.

> On some servers root doesn't have a password.

Sure, and nothing is wrong with that.

If the default behaviour is not what you want on a particular machine,
feel free to add a line similar to

  permit nopass [keepenv] root [as root]

to doas.conf(5).

Yours,
  Ingo


P.S.
Please do not cross-post between different OpenBSD lists.
Always choose the one most appropriate for the posting,
or none if the content of your posting is off-topic on every one
of them (which several of your postings were lately).

This one would have been on-topic on misc@; but given that you
posted to bugs@, i'm answering there such that developers
can more easily see which reports have been taken care of.

Reply | Threaded
Open this post in threaded view
|

Re: Bypass doas password check with chroot

chohag
Ingo Schwarze writes:
> I see nothing wrong with it.  It is easier to describe in the manual

Indeed I was not suggesting that there was something wrong; being asked for a password when doing something which root could implicitly do simply confused me for a moment which prompted figuring out what the situation was.

> The bikeshed has already been painted, and no matter whether you are
> justified in calling the colour that tedu@ chose "pink", i wouldn't
> see an obvious benefit in re-painting it now.

I have no desire to change this behaviour or engage in bike-shedding. Please no. Perhaps instead 5 free lines?

--- doas.1.~1.19.~      Sun Sep  4 18:20:37 2016
+++ doas.1      Thu Jul  4 01:26:21 2019
@@ -85,6 +85,12 @@
 Execute the command as
 .Ar user .
 The default is root.
+.Sh NOTE
+Although the kernel imposes no restrictions on the root user's ability
+to pose as any other user,
+.Nm
+will always require a password as per its configuration in order to
+keep unnecessary complications out of a critical security utility.
 .El
 .Sh EXIT STATUS
 .Ex -std doas

Not necessary of course but would have been nice for my peace of mind the other day when it happened (ie. to know that the situation has been duly considered). btw. I've never done anything with mdoc before so I expect there's a better macro to use to head this than .Sh but that's really not the point.

> Please do not cross-post between different OpenBSD lists.

Apologies and understood.

Matthew

Reply | Threaded
Open this post in threaded view
|

Re: Bypass doas password check with chroot

Theo de Raadt-2
I don't see the point.

If you get asked the question, and you know the answer, you answer it.
Why is that not the end of the story?


[hidden email] wrote:

> Ingo Schwarze writes:
> > I see nothing wrong with it.  It is easier to describe in the manual
>
> Indeed I was not suggesting that there was something wrong; being asked for a password when doing something which root could implicitly do simply confused me for a moment which prompted figuring out what the situation was.
>
> > The bikeshed has already been painted, and no matter whether you are
> > justified in calling the colour that tedu@ chose "pink", i wouldn't
> > see an obvious benefit in re-painting it now.
>
> I have no desire to change this behaviour or engage in bike-shedding. Please no. Perhaps instead 5 free lines?
>
> --- doas.1.~1.19.~      Sun Sep  4 18:20:37 2016
> +++ doas.1      Thu Jul  4 01:26:21 2019
> @@ -85,6 +85,12 @@
>  Execute the command as
>  .Ar user .
>  The default is root.
> +.Sh NOTE
> +Although the kernel imposes no restrictions on the root user's ability
> +to pose as any other user,
> +.Nm
> +will always require a password as per its configuration in order to
> +keep unnecessary complications out of a critical security utility.
>  .El
>  .Sh EXIT STATUS
>  .Ex -std doas
>
> Not necessary of course but would have been nice for my peace of mind the other day when it happened (ie. to know that the situation has been duly considered). btw. I've never done anything with mdoc before so I expect there's a better macro to use to head this than .Sh but that's really not the point.
>
> > Please do not cross-post between different OpenBSD lists.
>
> Apologies and understood.
>
> Matthew
>

Reply | Threaded
Open this post in threaded view
|

Re: Bypass doas password check with chroot

chohag
Theo de Raadt writes:
> I don't see the point.
>
> If you get asked the question, and you know the answer, you answer it.
> Why is that not the end of the story?

When I used doas the other day to gain the rights of a user it asked me for a password which I didn't expect, as I was root. Confirming that there was no additional restriction somehow (I didn't think there would be but it doesn't hurt) made me wonder why doas was different. I couldn't find any acknowledgement of this state nor at a look through related documentation any indication of whether it was intentional or accidental.

In short, words to the effect of what I wrote would have made it clear immediately that it's understood and for good reason, ie. not complicating a simple tool, and I've have moved on to the next thing happy.

Frankly I thought no more of the issue after Ingo's response the other day but on the way home the wording I sent earlier (more or less) popped into my head and I thought I'd share.

'twould have been nice to see. Nothing more.

Matthew

Reply | Threaded
Open this post in threaded view
|

Re: Bypass doas password check with chroot

Ingo Schwarze
In reply to this post by chohag
Hi,

chohag wrote:
> deraadt@ wrote:
>> [hidden email] wrote on Thu, Jul 04, 2019 at 01:35:36AM +0300:

>>> --- doas.1.~1.19.~      Sun Sep  4 18:20:37 2016
>>> +++ doas.1      Thu Jul  4 01:26:21 2019
>>> @@ -85,6 +85,12 @@
>>>  Execute the command as
>>>  .Ar user .
>>>  The default is root.
>>> +.Sh NOTE

Absolutely not.

That's a non-standard section, and we use non-standard sections
only when there are are strong reasons, in particular very large
amounts of text in the DESCRIPTION that need additional internal
structure and subdivision.

Note that the Linux man pages project - in sharp contrast to more
widespread standards - endorses ".Sh NOTES" (note the plural) in
its man-pages(7) manual page:

  https://man.openbsd.org/Linux-5.01/man-pages.7  # look for "NOTES"

But that manual page is at odds with traditional and proven ways
of writing Unix manual pages in lots of respects and not considered
authoritative round here.

NOTES sections are quite inacceptable.  They usually arise when
people fail to make up their minds how the content ought to be
organized and instead jump around from one sub-topic to another
and back again, and then put random afterthoughts into yet another
section, NOTES.

>>> +Although the kernel imposes no restrictions on the root user's ability
>>> +to pose as any other user,
>>> +.Nm
>>> +will always require a password as per its configuration in order to
>>> +keep unnecessary complications out of a critical security utility.

No, there is no need to say that.

As a general rule in Unix manual pages, if something isn't mentioned
as a special case, then it isn't a special case.  So from the the
fact that nothing is said about root passwords, you can already
conclude that doas(1) treats them the same as any other passwords.

>> I don't see the point.
>>
>> If you get asked the question, and you know the answer, you answer it.
>> Why is that not the end of the story?

> When I used doas the other day to gain the rights of a user it asked
> me for a password which I didn't expect, as I was root. Confirming
> that there was no additional restriction somehow (I didn't think
> there would be but it doesn't hurt) made me wonder why doas was
> different. I couldn't find any acknowledgement of this state nor
> at a look through related documentation any indication of whether
> it was intentional or accidental.

You are right that users may wonder about many different questions.
But there are at least two kinds of questions that can in principle
come in a infinite numbers:

 1) Quirks and exceptions that could maybe be implemented but aren't.
 2) Reasons for minor implementation choices.

Explaining these two classes of points would be an open-ended
task and would conflict with the goal of conciseness.

So as a rule, we only describe what is implemented (but not what
isn't), and also not why, unless that would matter for the user to
use the tool correctly.


It is obvious that in general, doas(1) needs authentication.
The description of the -a option,

  https://man.openbsd.org/doas.1#a

implicitely makes that clear, too, and

  https://man.openbsd.org/doas.conf.5#nopass

already explains how to switch it off.  So i think all the information
is already there, at the places where it belongs.

Yours,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: Bypass doas password check with chroot

Ted Unangst-6
In reply to this post by chohag
[hidden email] wrote:

> Ingo Schwarze writes:
> > I see nothing wrong with it.  It is easier to describe in the manual
>
> Indeed I was not suggesting that there was something wrong; being asked for a password when doing something which root could implicitly do simply confused me for a moment which prompted figuring out what the situation was.
>
> > The bikeshed has already been painted, and no matter whether you are
> > justified in calling the colour that tedu@ chose "pink", i wouldn't
> > see an obvious benefit in re-painting it now.
>
> I have no desire to change this behaviour or engage in bike-shedding. Please no. Perhaps instead 5 free lines?

I think this is not the right note, but after some review I just realized we
don't ever say that a password is required. It's merely hinted at in various
options. I'll make a note of that.

>
> --- doas.1.~1.19.~      Sun Sep  4 18:20:37 2016
> +++ doas.1      Thu Jul  4 01:26:21 2019
> @@ -85,6 +85,12 @@
>  Execute the command as
>  .Ar user .
>  The default is root.
> +.Sh NOTE
> +Although the kernel imposes no restrictions on the root user's ability
> +to pose as any other user,
> +.Nm
> +will always require a password as per its configuration in order to
> +keep unnecessary complications out of a critical security utility.
>  .El
>  .Sh EXIT STATUS
>  .Ex -std doas
>
> Not necessary of course but would have been nice for my peace of mind the other day when it happened (ie. to know that the situation has been duly considered). btw. I've never done anything with mdoc before so I expect there's a better macro to use to head this than .Sh but that's really not the point.
>
> > Please do not cross-post between different OpenBSD lists.
>
> Apologies and understood.
>
> Matthew
>

Reply | Threaded
Open this post in threaded view
|

Re: Bypass doas password check with chroot

Ted Unangst-6
Ted Unangst wrote:
> I think this is not the right note, but after some review I just realized we
> don't ever say that a password is required. It's merely hinted at in various
> options. I'll make a note of that.

Just a simple sentence, but I think it makes explicit the behavior.


Index: doas.1
===================================================================
RCS file: /home/cvs/src/usr.bin/doas/doas.1,v
retrieving revision 1.22
diff -u -p -r1.22 doas.1
--- doas.1 21 Jun 2019 17:02:27 -0000 1.22
+++ doas.1 4 Jul 2019 15:29:00 -0000
@@ -40,6 +40,9 @@ or
 .Fl s
 is specified.
 .Pp
+The user will be required to authenticate by entering their password,
+unless configured otherwise.
+.Pp
 By default, a new environment is created.
 The variables
 .Ev HOME ,

Reply | Threaded
Open this post in threaded view
|

Re: Bypass doas password check with chroot

chohag
Ted Unangst writes:
> Ted Unangst wrote:
> > I think this is not the right note, but after some review I just realized we
> > don't ever say that a password is required. It's merely hinted at in various
> > options. I'll make a note of that.
>
> Just a simple sentence, but I think it makes explicit the behavior.

Looks much better than my ham-fisted attempt.

Matthew