doas(1) adjustable timeout length

[b***@safe-mail.net]

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

[Theo de Raadt]

I'll ask the question: Why are you sure you need that?

Post by b***@safe-mail.net
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.
# 90-second persistence
permit persist=90 :wheel
permit nopass keepenv root
# 5-minute persistence
permit persist :captain
# 90-seconds; timeout must be specified.
permit persist 90 :wheel

[b***@safe-mail.net]

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&m=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

Post by Theo de Raadt
I'll ask the question: Why are you sure you need that?

Post by b***@safe-mail.net
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.
# 90-second persistence
permit persist=90 :wheel
permit nopass keepenv root
# 5-minute persistence
permit persist :captain
# 90-seconds; timeout must be specified.
permit persist 90 :wheel

[Ted Unangst]

Post by b***@safe-mail.net
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.

[b***@safe-mail.net]

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

Post by Ted Unangst
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.

[Ted Unangst]

Post by b***@safe-mail.net
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.

[b***@safe-mail.net]

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

Post by Ted Unangst

Post by b***@safe-mail.net
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.