Ports documentation: document that TRUSTED_PKG_PATH is needed in doas.conf?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Ports documentation: document that TRUSTED_PKG_PATH is needed in doas.conf?

James Cook-2
Hi ports@,

Summary: I suggest the section at
https://www.openbsd.org/faq/ports/ports.html#PortsConfig
should include some additional text like the following:

  You will need to configure doas to pass the TRUSTED_PKG_PATH variable
  when running /usr/sbin/pkg_add. Adding the "nopass" option for
  certain commands can help reduce the number of times a password needs
  to be entered. For example, add the following to doas.conf(5),
  replacing "myuser" with your username:

    permit nopass myuser cmd /usr/bin/touch
    permit nopass setenv { TRUSTED_PKG_PATH TERM } myuser cmd /usr/sbin/pkg_add
    permit nopass setenv { TERM } myuser cmd /usr/sbin/pkg_delete

and also updating the section on the PORTS_PRIVSEP variable in
bsd.ports.mk(5) to replace

   If the regular user is not allowed to run privileged commands
   without entering a password, you may want these additional rules
   in doas.conf(5), to reduce the amount of times the password needs
   to be entered during ports work:

with

  You will need to configure doas to pass the TRUSTED_PKG_PATH variable
  when the regular user runs /usr/sbin/pkg_add. You can also reduce the
  number of times the password needs to be entered by permitting
  certain commands without a password. For example:

Happy to turn this into a patch if it looks good.


Reasoning:

I'm surprised this requirement isn't documented. "make install" as
non-root fails if TRUSTED_PKG_PATH isn't set. Am I missing something?
Or does every new ports user run into this problem, and quietly figure
out the solution on their own? Or do people just run everything as
root?

I just fixed the problem for myself after scratching my head for a
while and finally finding this email thread:
http://openbsd-archive.7691.n7.nabble.com/signify-error-when-installing-ports-on-current-td366895.html

To be fair, I did see the documentation for the PORTS_PRIVSEP variable,
which an example with TRUSTED_PKG_PATH. But I didn't add the suggested
lines, because the phrasing implies it's not actually needed:
"you may want these additional rules ...".

--
James

Reply | Threaded
Open this post in threaded view
|

Re: Ports documentation: document that TRUSTED_PKG_PATH is needed in doas.conf?

Stuart Henderson
On 2021/02/03 17:39, James Cook wrote:

> Hi ports@,
>
> Summary: I suggest the section at
> https://www.openbsd.org/faq/ports/ports.html#PortsConfig
> should include some additional text like the following:
>
>   You will need to configure doas to pass the TRUSTED_PKG_PATH variable
>   when running /usr/sbin/pkg_add. Adding the "nopass" option for
>   certain commands can help reduce the number of times a password needs
>   to be entered. For example, add the following to doas.conf(5),
>   replacing "myuser" with your username:
>
>     permit nopass myuser cmd /usr/bin/touch
>     permit nopass setenv { TRUSTED_PKG_PATH TERM } myuser cmd /usr/sbin/pkg_add
>     permit nopass setenv { TERM } myuser cmd /usr/sbin/pkg_delete

Let's not go down the 'try to evaluate every variable' path again,
keepenv is the way to go, we have spent much time figuring out weird
bugs from missing variables in the past when we have tried to
evaluate them.

If you are going to allow pkg_add with "nopass" you might just as well
write "permit nopass myuser". An account which can run pkg_add as root
has full control of the system.

Reply | Threaded
Open this post in threaded view
|

Re: Ports documentation: document that TRUSTED_PKG_PATH is needed in doas.conf?

James Cook-2
On Wed, Feb 03, 2021 at 07:24:08PM +0000, Stuart Henderson wrote:

> On 2021/02/03 17:39, James Cook wrote:
> > Hi ports@,
> >
> > Summary: I suggest the section at
> > https://www.openbsd.org/faq/ports/ports.html#PortsConfig
> > should include some additional text like the following:
> >
> >   You will need to configure doas to pass the TRUSTED_PKG_PATH variable
> >   when running /usr/sbin/pkg_add. Adding the "nopass" option for
> >   certain commands can help reduce the number of times a password needs
> >   to be entered. For example, add the following to doas.conf(5),
> >   replacing "myuser" with your username:
> >
> >     permit nopass myuser cmd /usr/bin/touch
> >     permit nopass setenv { TRUSTED_PKG_PATH TERM } myuser cmd /usr/sbin/pkg_add
> >     permit nopass setenv { TERM } myuser cmd /usr/sbin/pkg_delete
>
> Let's not go down the 'try to evaluate every variable' path again,
> keepenv is the way to go, we have spent much time figuring out weird
> bugs from missing variables in the past when we have tried to
> evaluate them.
>
> If you are going to allow pkg_add with "nopass" you might just as well
> write "permit nopass myuser". An account which can run pkg_add as root
> has full control of the system.

I don't have strong opinions about that. My point is just that the
current documentation left me with a setup that didn't work.

How about recommending keepenv instead, if that's better?

--
James

Reply | Threaded
Open this post in threaded view
|

Re: Ports documentation: document that TRUSTED_PKG_PATH is needed in doas.conf?

Thomas Frohwein-2
On Wed, Feb 03, 2021 at 09:23:48PM +0000, James Cook wrote:

> On Wed, Feb 03, 2021 at 07:24:08PM +0000, Stuart Henderson wrote:
> > On 2021/02/03 17:39, James Cook wrote:
> > > Hi ports@,
> > >
> > > Summary: I suggest the section at
> > > https://www.openbsd.org/faq/ports/ports.html#PortsConfig
> > > should include some additional text like the following:
> > >
> > >   You will need to configure doas to pass the TRUSTED_PKG_PATH variable
> > >   when running /usr/sbin/pkg_add. Adding the "nopass" option for
> > >   certain commands can help reduce the number of times a password needs
> > >   to be entered. For example, add the following to doas.conf(5),
> > >   replacing "myuser" with your username:
> > >
> > >     permit nopass myuser cmd /usr/bin/touch
> > >     permit nopass setenv { TRUSTED_PKG_PATH TERM } myuser cmd /usr/sbin/pkg_add
> > >     permit nopass setenv { TERM } myuser cmd /usr/sbin/pkg_delete
> >
> > Let's not go down the 'try to evaluate every variable' path again,
> > keepenv is the way to go, we have spent much time figuring out weird
> > bugs from missing variables in the past when we have tried to
> > evaluate them.
> >
> > If you are going to allow pkg_add with "nopass" you might just as well
> > write "permit nopass myuser". An account which can run pkg_add as root
> > has full control of the system.
>
> I don't have strong opinions about that. My point is just that the
> current documentation left me with a setup that didn't work.
>
> How about recommending keepenv instead, if that's better?

I think sthen@ may have been a little too subtle about what a giant
footgun your proposal is.

"permit nopass myuser" is equivalent to myuser being root and you might
as well run everything as root then and toss out all security
considerations that come from logging in as a non-root user.

This has no place in the FAQ in my opinion.
>
> --
> James
>

Reply | Threaded
Open this post in threaded view
|

Re: Ports documentation: document that TRUSTED_PKG_PATH is needed in doas.conf?

James Cook-2
On Wed, Feb 03, 2021 at 08:29:31PM -0700, Thomas Frohwein wrote:

> On Wed, Feb 03, 2021 at 09:23:48PM +0000, James Cook wrote:
> > On Wed, Feb 03, 2021 at 07:24:08PM +0000, Stuart Henderson wrote:
> > > On 2021/02/03 17:39, James Cook wrote:
> > > > Hi ports@,
> > > >
> > > > Summary: I suggest the section at
> > > > https://www.openbsd.org/faq/ports/ports.html#PortsConfig
> > > > should include some additional text like the following:
> > > >
> > > >   You will need to configure doas to pass the TRUSTED_PKG_PATH variable
> > > >   when running /usr/sbin/pkg_add. Adding the "nopass" option for
> > > >   certain commands can help reduce the number of times a password needs
> > > >   to be entered. For example, add the following to doas.conf(5),
> > > >   replacing "myuser" with your username:
> > > >
> > > >     permit nopass myuser cmd /usr/bin/touch
> > > >     permit nopass setenv { TRUSTED_PKG_PATH TERM } myuser cmd /usr/sbin/pkg_add
> > > >     permit nopass setenv { TERM } myuser cmd /usr/sbin/pkg_delete
> > >
> > > Let's not go down the 'try to evaluate every variable' path again,
> > > keepenv is the way to go, we have spent much time figuring out weird
> > > bugs from missing variables in the past when we have tried to
> > > evaluate them.
> > >
> > > If you are going to allow pkg_add with "nopass" you might just as well
> > > write "permit nopass myuser". An account which can run pkg_add as root
> > > has full control of the system.
> >
> > I don't have strong opinions about that. My point is just that the
> > current documentation left me with a setup that didn't work.
> >
> > How about recommending keepenv instead, if that's better?
>
> I think sthen@ may have been a little too subtle about what a giant
> footgun your proposal is.
>
> "permit nopass myuser" is equivalent to myuser being root and you might
> as well run everything as root then and toss out all security
> considerations that come from logging in as a non-root user.
>
> This has no place in the FAQ in my opinion.

I'll readily accept that it's a bad solution. I just thought I should
suggest something instead of just complaining that the documentation is
broken.

Maybe I should back up and explain what led me to believe the
documentation is broken. Maybe I'm mistaken, and the problem I ran into
is my own fault.

* The phrasing in this section:
  https://www.openbsd.org/faq/ports/ports.html#PortsConfig led me to
  believe I should try to configure privilege separation if I want to
  work with ports.

* As a result, I set PORTS_PRIVSEP=Yes in /etc/mk.conf.

* With that configuration, running "make install" in, say
  /usr/ports/archivers/gtar results in an error:

    falsifian angel gtar $ make install
    doas ([hidden email]) password:
    doas ([hidden email]) password:
    doas ([hidden email]) password:
    ===>  Installing gtar-1.33p0 from /usr/ports/packages/amd64/all/
    doas ([hidden email]) password:
    quirks-3.534 signed on 2021-02-03T00:42:33Z
    file:/usr/ports/packages/amd64/all/gtar-1.33p0.tgz: unsigned package
    Can't find /usr/ports/packages/amd64/all/gtar-1.33p0.tgz
    Couldn't install gtar-1.33p0
    *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2148 '/var/db/pkg/gtar-1.33p0/+CONTENTS': @/usr/bin/env -i PKG_TMPDIR=/var/tmp TE...)
    doas ([hidden email]) password:
    *** Error 2 in /usr/ports/archivers/gtar (/usr/ports/infrastructure/mk/bsd.port.mk:2591 'install': @lock=gtar-1.33p0;  export _LOCKS_HELD=" ...)

Of course, now I know how to solve the error. But I thought I'd found a
bug in the documentation, because the documentation led me to a bad
setup.

My suggested doas.conf comes (almost) directly from the existing
documentation for PORTS_PRIVSEP.

--
James

Reply | Threaded
Open this post in threaded view
|

Re: Ports documentation: document that TRUSTED_PKG_PATH is needed in doas.conf?

Thomas Frohwein-2
On Thu, Feb 04, 2021 at 05:52:09AM +0000, James Cook wrote:

[...]

> > > > If you are going to allow pkg_add with "nopass" you might just as well
> > > > write "permit nopass myuser". An account which can run pkg_add as root
> > > > has full control of the system.
> > >
> > > I don't have strong opinions about that. My point is just that the
> > > current documentation left me with a setup that didn't work.
> > >
> > > How about recommending keepenv instead, if that's better?
> >
> > I think sthen@ may have been a little too subtle about what a giant
> > footgun your proposal is.
> >
> > "permit nopass myuser" is equivalent to myuser being root and you might
> > as well run everything as root then and toss out all security
> > considerations that come from logging in as a non-root user.
> >
> > This has no place in the FAQ in my opinion.

[...]

> Of course, now I know how to solve the error. But I thought I'd found a
> bug in the documentation, because the documentation led me to a bad
> setup.
>
> My suggested doas.conf comes (almost) directly from the existing
> documentation for PORTS_PRIVSEP.

I think you did find an inconsistency in the documentation and thanks
for raising it. Just would like to point out that commit [1] happened
in response to the discussion of the issue.

[1] https://marc.info/?l=openbsd-cvs&m=161247673822783&w=2

Reply | Threaded
Open this post in threaded view
|

Re: Ports documentation: document that TRUSTED_PKG_PATH is needed in doas.conf?

Marc Espie-2
As the idiot responsible for how the framework actually works, I'm always
running with keepenv.

Building ports by hand always end up installing *whatever* as root, so
I don't see nopass as much of a security risk either. Heck, you're going to
put that shit in /usr/local/bin and run it anyway.


PORTS_PRIVSEP is a much better security measure. Preventing ports from
accidentally accessing the network or writing all over the system is good.

The main reason PORTS_PRIVSEP is not the default is that it requires some
awkward setup (fix-permissions) and that you definitely need some scripts
to handle editing files as the right guy (or put yourself in the right
group.... in any case, you have to do stuff correctly to handle ports).


Ports has a somewhat low entry barrier compared to other parts of the
system, but a secure setup still requires some basic understanding of
things.

At some point, either you put in the work, or just use the darn packages.

Reply | Threaded
Open this post in threaded view
|

Re: Ports documentation: document that TRUSTED_PKG_PATH is needed in doas.conf?

Stuart Henderson
On 2021/02/05 10:07, Marc Espie wrote:

> As the idiot responsible for how the framework actually works, I'm always
> running with keepenv.
>
> Building ports by hand always end up installing *whatever* as root, so
> I don't see nopass as much of a security risk either. Heck, you're going to
> put that shit in /usr/local/bin and run it anyway.
>
>
> PORTS_PRIVSEP is a much better security measure. Preventing ports from
> accidentally accessing the network or writing all over the system is good.

Coming back to this because I thought of something..

Note I am only thinking about the case with PORTS_PRIVSEP, I think anybody
working with ports should use that by default, it's not that hard to
work with.

The place where nopass is a problem is elevating from your normal user
account. But this is exactly the place where people are getting fed up
with entering their password many times which is exactly why they're
wanting to use nopass.

There is a possible change that could be made to make this much safer
(though doas is already above the proposed limit of 1000 lines of code ;)
It could have another mode, similar to "nopass" but which, instead of
running the elevated commands directly, prints the command line and asks
for yes/no confirmation. This would save entering passwords all the time
but would make it much harder to just sneak an elevated command past the
person in front of the keyboard.

It seems so obvious, I'm wondering why doas or sudo before doesn't
already have it..

Reply | Threaded
Open this post in threaded view
|

Re: Ports documentation: document that TRUSTED_PKG_PATH is needed in doas.conf?

Daniel Jakots-6
On Wed, 17 Feb 2021 14:48:02 +0000, Stuart Henderson
<[hidden email]> wrote:

> Note I am only thinking about the case with PORTS_PRIVSEP, I think
> anybody working with ports should use that by default, it's not that
> hard to work with.

Why isn't this the default then?

Reply | Threaded
Open this post in threaded view
|

Re: Ports documentation: document that TRUSTED_PKG_PATH is needed in doas.conf?

Marc Espie-2
In reply to this post by Stuart Henderson
On Wed, Feb 17, 2021 at 02:48:02PM +0000, Stuart Henderson wrote:

> On 2021/02/05 10:07, Marc Espie wrote:
> > As the idiot responsible for how the framework actually works, I'm always
> > running with keepenv.
> >
> > Building ports by hand always end up installing *whatever* as root, so
> > I don't see nopass as much of a security risk either. Heck, you're going to
> > put that shit in /usr/local/bin and run it anyway.
> >
> >
> > PORTS_PRIVSEP is a much better security measure. Preventing ports from
> > accidentally accessing the network or writing all over the system is good.
>
> Coming back to this because I thought of something..
>
> Note I am only thinking about the case with PORTS_PRIVSEP, I think anybody
> working with ports should use that by default, it's not that hard to
> work with.
>
> The place where nopass is a problem is elevating from your normal user
> account. But this is exactly the place where people are getting fed up
> with entering their password many times which is exactly why they're
> wanting to use nopass.
>
> There is a possible change that could be made to make this much safer
> (though doas is already above the proposed limit of 1000 lines of code ;)
> It could have another mode, similar to "nopass" but which, instead of
> running the elevated commands directly, prints the command line and asks
> for yes/no confirmation. This would save entering passwords all the time
> but would make it much harder to just sneak an elevated command past the
> person in front of the keyboard.
>
> It seems so obvious, I'm wondering why doas or sudo before doesn't
> already have it..
>
>
I'm not very sure how useful it would be for ports, considering the
actual commands we get to run as root, which aren't exactly short with all
the options...

Reply | Threaded
Open this post in threaded view
|

Re: Ports documentation: document that TRUSTED_PKG_PATH is needed in doas.conf?

Stuart Henderson
On 2021/02/17 19:42, Marc Espie wrote:

> On Wed, Feb 17, 2021 at 02:48:02PM +0000, Stuart Henderson wrote:
> > On 2021/02/05 10:07, Marc Espie wrote:
> > > As the idiot responsible for how the framework actually works, I'm always
> > > running with keepenv.
> > >
> > > Building ports by hand always end up installing *whatever* as root, so
> > > I don't see nopass as much of a security risk either. Heck, you're going to
> > > put that shit in /usr/local/bin and run it anyway.
> > >
> > >
> > > PORTS_PRIVSEP is a much better security measure. Preventing ports from
> > > accidentally accessing the network or writing all over the system is good.
> >
> > Coming back to this because I thought of something..
> >
> > Note I am only thinking about the case with PORTS_PRIVSEP, I think anybody
> > working with ports should use that by default, it's not that hard to
> > work with.
> >
> > The place where nopass is a problem is elevating from your normal user
> > account. But this is exactly the place where people are getting fed up
> > with entering their password many times which is exactly why they're
> > wanting to use nopass.
> >
> > There is a possible change that could be made to make this much safer
> > (though doas is already above the proposed limit of 1000 lines of code ;)
> > It could have another mode, similar to "nopass" but which, instead of
> > running the elevated commands directly, prints the command line and asks
> > for yes/no confirmation. This would save entering passwords all the time
> > but would make it much harder to just sneak an elevated command past the
> > person in front of the keyboard.
> >
> > It seems so obvious, I'm wondering why doas or sudo before doesn't
> > already have it..
> >
> >
> I'm not very sure how useful it would be for ports, considering the
> actual commands we get to run as root, which aren't exactly short with all
> the options...
>

I'm not thinking about stuff run from ports infrastructure here.

The connection with ports is that people use nopass to stop being asked to
type the password 3 times every time infrastructure tries to install a
dependency (doas persist "tickets" can't be transferred sideways or
downwards to other processes). So it's easy to see why they might use
nopass, but that opens themselves up to attacks from other angles.

Silly example but say you save some script from a website/email and run it
without checking carefully, or you run some software as your own user
that has a bug which is exploited, and it tries to use (sudo|doas) to
gain privs.

Current situation, either it asks for the password (with no indication
what it's trying to run and someone might type it anyway), or nopass is
set and it just goes ahead and runs it, or if it's sudo then maybe it
asks for the password or maybe it runs it anyway, depending on whether
you have a valid ticket.

PORTS_PRIVSEP obviously helps the case where something dodgy is run as
part of a port build. But it doesn't help the above.

There is prior art. With ssh-agent you can add a key with -c, then
if you run some dodgy program that tries to use your stored key to
connect to another host it checks for confirmation before allowing it to
proceed. You don't need to keep reentering the password but if you get
an ssh-agent request when you're not expecting it you'll know that
something is wrong.

Reply | Threaded
Open this post in threaded view
|

Re: Ports documentation: document that TRUSTED_PKG_PATH is needed in doas.conf?

Marc Espie-2
On Wed, Feb 17, 2021 at 08:22:27PM +0000, Stuart Henderson wrote:

> On 2021/02/17 19:42, Marc Espie wrote:
> > On Wed, Feb 17, 2021 at 02:48:02PM +0000, Stuart Henderson wrote:
> > > On 2021/02/05 10:07, Marc Espie wrote:
> > > > As the idiot responsible for how the framework actually works, I'm always
> > > > running with keepenv.
> > > >
> > > > Building ports by hand always end up installing *whatever* as root, so
> > > > I don't see nopass as much of a security risk either. Heck, you're going to
> > > > put that shit in /usr/local/bin and run it anyway.
> > > >
> > > >
> > > > PORTS_PRIVSEP is a much better security measure. Preventing ports from
> > > > accidentally accessing the network or writing all over the system is good.
> > >
> > > Coming back to this because I thought of something..
> > >
> > > Note I am only thinking about the case with PORTS_PRIVSEP, I think anybody
> > > working with ports should use that by default, it's not that hard to
> > > work with.
> > >
> > > The place where nopass is a problem is elevating from your normal user
> > > account. But this is exactly the place where people are getting fed up
> > > with entering their password many times which is exactly why they're
> > > wanting to use nopass.
> > >
> > > There is a possible change that could be made to make this much safer
> > > (though doas is already above the proposed limit of 1000 lines of code ;)
> > > It could have another mode, similar to "nopass" but which, instead of
> > > running the elevated commands directly, prints the command line and asks
> > > for yes/no confirmation. This would save entering passwords all the time
> > > but would make it much harder to just sneak an elevated command past the
> > > person in front of the keyboard.
> > >
> > > It seems so obvious, I'm wondering why doas or sudo before doesn't
> > > already have it..
> > >
> > >
> > I'm not very sure how useful it would be for ports, considering the
> > actual commands we get to run as root, which aren't exactly short with all
> > the options...
> >
>
> I'm not thinking about stuff run from ports infrastructure here.
>
> The connection with ports is that people use nopass to stop being asked to
> type the password 3 times every time infrastructure tries to install a
> dependency (doas persist "tickets" can't be transferred sideways or
> downwards to other processes). So it's easy to see why they might use
> nopass, but that opens themselves up to attacks from other angles.

Ah right, makes way more sense in that case.

Is tedu@ AWOL or still somewhat around ?

Reply | Threaded
Open this post in threaded view
|

Re: Ports documentation: document that TRUSTED_PKG_PATH is needed in doas.conf?

Marc Espie-2
In reply to this post by Daniel Jakots-6
On Wed, Feb 17, 2021 at 10:20:35AM -0500, Daniel Jakots wrote:
> On Wed, 17 Feb 2021 14:48:02 +0000, Stuart Henderson
> <[hidden email]> wrote:
>
> > Note I am only thinking about the case with PORTS_PRIVSEP, I think
> > anybody working with ports should use that by default, it's not that
> > hard to work with.
>
> Why isn't this the default then?

Because it requires significant extra setup and understanding
and it means we will get even less newcomers than we do now.