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 via email to