Re: [hackers] [slock] [PATCH] Properly drop privileges

From: FRIGN <>
Date: Fri, 9 Sep 2016 08:32:05 +0200

On Thu, 8 Sep 2016 23:46:46 +0200
Markus Teich <> wrote:

Good morning,

> I think its not much of a complexity to specify the group as well and
> also is more explicit than implicitly using the users default group
> (which might have some surprises).
> > Again I'm not really against that, just asking for some opinions.
> > I've got yours!
> I don't have a clear opinion on the nogroup vs. nobody matter, but
> since it is just a default and can easily be changed I just merged
> the patch for now (I hope I got the correct version). If somebody[0]
> gives a good argument, we'll just change the default.

it is always recommended to read the motivation for doas and why sudo
was invented in the first place. I wrote this patch under two
        - in most cases, the slock post-lock-cmd wouldn't need
        - if it needs permissions, we can't just not drop privileges.
          Instead, it should be simple to just create a group "slock"
          or something and specify there what it is allowed to do.

As an example, let's say I want to run a privileged command "rootsjob"
after locking.
The first thing I do is create a group "slock" and enter it in
config.h. We cannot have a -u or -g flag for slock to set the dropuser
because that would allow impersonation of anybody. We are protected by
having it a compiled-in option because suid-applications cannot be
modified without losing the suid-bit.

        user = "nobody"
        group = "slock"

Now I edit my sudoers/doas.conf file and do the permission control
there. Especially doas is really simple to set up and can allow
fine-grained permission control. For doas.conf it would be

        permit nopass :slock cmd rootsjob

and it can be extended from there on. slock can now be executed with

        slock doas rootsjob

and we fixed the permission problem. The reason why doas/sudo exists is
really because the duality root/non-root is too strict in many cases.
The midway cannot be solved by us, but we need to put trust into the
facilities provided by the system and allow the users to be flexible
(for instance, one could also create a slock user, so it would be bad
to implicitly set the groups from the user and vice versa).

> Thanks for the contribution, FRIGN.

I was happy to do it!



Received on Fri Sep 09 2016 - 08:32:05 CEST

This archive was generated by hypermail 2.3.0 : Fri Sep 09 2016 - 08:36:15 CEST