Re: doas(1) adjustable timeout length

2019-12-24 Thread Ingo Schwarze
Hi,

Hiltjo Posthuma wrote on Fri, Dec 20, 2019 at 12:40:14AM +0100:
> On Thu, Dec 19, 2019 at 02:03:19PM -0700, andrej wrote:

>> On the note of accurate documentation; how about adding the actually
>> defined timeout for persist rather than the "some time"?

> Sometimes there is a reason implementation details are not specificly
> documented,

Correct.

> but I don't know if thats the case here.

If i understand correctly, it is.

This option is only provided for convenience in interactive use.
It shouldn't matter for the user what the exact timeout is.
The user will simply enter the password once more when asked.

On the other hand, Ted might decide at some time in the future
that a slightly different timeout yields a better balance of
convenience and security.  When there is no public promise how
long exactly the timeout is, changing it is less disruptive.

So, i'm not convinced we want the patch quoted below.

Yours,
  Ingo


> diff --git usr.bin/doas/doas.conf.5 usr.bin/doas/doas.conf.5
> index b5cacde22cd..b541aef966c 100644
> --- usr.bin/doas/doas.conf.5
> +++ usr.bin/doas/doas.conf.5
> @@ -47,7 +47,7 @@ Options are:
>  The user is not required to enter a password.
>  .It Ic persist
>  After the user successfully authenticates, do not ask for a password
> -again for some time.
> +again for 5 minutes for the session.
>  .It Ic keepenv
>  Environment variables other than those listed in
>  .Xr doas 1



Re: doas(1) adjustable timeout length

2019-12-19 Thread Hiltjo Posthuma
On Thu, Dec 19, 2019 at 02:03:19PM -0700, andrej wrote:
> Hi Ted,
> 
> On the note of accurate documentation; how about adding the actually defined
> timeout for persist rather than the "some time"?
> 
> 
> Cheers,
> Andrej
> 
> 
> 
> --
> Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
> 

Hi Andrej,

Sometimes there is a reason implementation details are not specificly
documented, but I don't know if thats the case here.


Patch:


diff --git usr.bin/doas/doas.conf.5 usr.bin/doas/doas.conf.5
index b5cacde22cd..b541aef966c 100644
--- usr.bin/doas/doas.conf.5
+++ usr.bin/doas/doas.conf.5
@@ -47,7 +47,7 @@ Options are:
 The user is not required to enter a password.
 .It Ic persist
 After the user successfully authenticates, do not ask for a password
-again for some time.
+again for 5 minutes for the session.
 .It Ic keepenv
 Environment variables other than those listed in
 .Xr doas 1

-- 
Kind regards,
Hiltjo



Re: doas(1) adjustable timeout length

2019-12-19 Thread andrej
Hi Ted,

On the note of accurate documentation; how about adding the actually defined
timeout for persist rather than the "some time"?


Cheers,
Andrej



--
Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html



Re: doas(1) adjustable timeout length

2017-03-14 Thread bytevolcano
Understood (though in this case it looks unfinished when 99% of the
implementation is already present).

In any case you have answered my original question. Thanks, Ted.

On Tue, 14 Mar 2017 18:29:25 -0400
"Ted Unangst"  wrote:

> bytevolc...@safe-mail.net wrote:
> > I'm not saying "you must do everything my way or else", but rather I
> > am trying to understand the reasoning behind making this hardcoded
> > and fixed, as opposed to being admin-settable; maybe something is
> > planned here I am unaware of?  
> 
> We're trying to keep the options to a minimum, which keeps the
> implementation simple, but more importantly keeps the documentation
> short and reduces the number of decisions that need to be made.



Re: doas(1) adjustable timeout length

2017-03-14 Thread Ted Unangst
bytevolc...@safe-mail.net wrote:
> I'm not saying "you must do everything my way or else", but rather I
> am trying to understand the reasoning behind making this hardcoded and
> fixed, as opposed to being admin-settable; maybe something is planned
> here I am unaware of?

We're trying to keep the options to a minimum, which keeps the implementation
simple, but more importantly keeps the documentation short and reduces the
number of decisions that need to be made.



Re: doas(1) adjustable timeout length

2017-03-13 Thread bytevolcano
>From what I have read, it appears to be 15 minutes on some systems and
30 minutes on others, and this can be adjusted by the admin without
having to recompile the code.

I'm not saying "you must do everything my way or else", but rather I
am trying to understand the reasoning behind making this hardcoded and
fixed, as opposed to being admin-settable; maybe something is planned
here I am unaware of?
Not saying we need all the bells and whistles of the sudo implementation
(eg. "sudo -v" adding 5 minutes to the timeout) but I can't see any
reason this shouldn't be admin-configurable.

I would like to work on a patch for this, but I want to ensure I don't
duplicate efforts if you have something planned which conflicts with my
patch. That's why I posted in misc@, because I don't have a patch yet.

On Mon, 13 Mar 2017 01:06:51 -0400
"Ted Unangst"  wrote:

> The timeout was originally 10 minutes, but changed to 5 after I
> discovered that was the sudo default. I think increasing to 10 is
> reasonable, since it seems likely other people also land in the 5-10
> minute window, and it's not dangerously long.



Re: doas(1) adjustable timeout length

2017-03-12 Thread Ted Unangst
bytevolc...@safe-mail.net wrote:
> On one box I test configuration edits and backups, I find myself using
> doas around once every 7-9 minutes, exceeding the 5 minute limit.
> Another box is basically a gateway, so I don't exceed 2 minutes between
> doas runs.

The timeout was originally 10 minutes, but changed to 5 after I discovered that
was the sudo default. I think increasing to 10 is reasonable, since it seems
likely other people also land in the 5-10 minute window, and it's not
dangerously long.



Re: doas(1) adjustable timeout length

2017-03-12 Thread bytevolcano
On one box I test configuration edits and backups, I find myself using
doas around once every 7-9 minutes, exceeding the 5 minute limit.
Another box is basically a gateway, so I don't exceed 2 minutes between
doas runs.

It would be nice to have the option of deviating from the default, and
the "persist" feature seems incomplete without the ability to adjust
the timeout from a fixed 5 minutes.
I didn't say anything until now, because I was under the
impression there was something else planned for the "persist" feature,
but there has I haven't seen anything about this in the mailing lists
since this: https://marc.info/?l=openbsd-tech=147314077009745

Since the first release with this feature will be 6.1, it seems logical
to make any syntax changes now rather than later. No kernel changes
needed here, since the timeout can be set with TIOCSETVERAUTH, so I
don't see any harm in giving admins the option of setting the timeout
with doas.conf instead of it being hard-coded into doas itself.

On Sun, 12 Mar 2017 10:20:46 -0600
"Theo de Raadt"  wrote:

> I'll ask the question: Why are you sure you need that?
> 
> > Are there plans (or perhaps code already being worked on) to allow
> > doas(1) 'persist' to have a different time other than 5 minutes? I
> > am thinking of writing a patch for this, but I do not want to
> > duplicate effort if the devs have other/similar plans ahead.
> > 
> > I would like to configure the timeout to be 1 minute on one of my
> > boxes, and 5-10 minutes on another box.
> > 
> > For instance, something like:
> > 
> > # 90-second persistence
> > permit persist=90 :wheel
> > permit nopass keepenv root
> > 
> > # 5-minute persistence
> > permit persist :captain
> > 
> > Or even:
> > 
> > # 90-seconds; timeout must be specified.
> > permit persist 90 :wheel  



Re: doas(1) adjustable timeout length

2017-03-12 Thread Theo de Raadt
I'll ask the question: Why are you sure you need that?

> Are there plans (or perhaps code already being worked on) to allow
> doas(1) 'persist' to have a different time other than 5 minutes? I am
> thinking of writing a patch for this, but I do not want to duplicate
> effort if the devs have other/similar plans ahead.
> 
> I would like to configure the timeout to be 1 minute on one of my
> boxes, and 5-10 minutes on another box.
> 
> For instance, something like:
> 
>   # 90-second persistence
>   permit persist=90 :wheel
>   permit nopass keepenv root
> 
>   # 5-minute persistence
>   permit persist :captain
> 
> Or even:
> 
>   # 90-seconds; timeout must be specified.
>   permit persist 90 :wheel



doas(1) adjustable timeout length

2017-03-12 Thread bytevolcano
Hi,

Are there plans (or perhaps code already being worked on) to allow
doas(1) 'persist' to have a different time other than 5 minutes? I am
thinking of writing a patch for this, but I do not want to duplicate
effort if the devs have other/similar plans ahead.

I would like to configure the timeout to be 1 minute on one of my
boxes, and 5-10 minutes on another box.

For instance, something like:

# 90-second persistence
permit persist=90 :wheel
permit nopass keepenv root

# 5-minute persistence
permit persist :captain

Or even:

# 90-seconds; timeout must be specified.
permit persist 90 :wheel