fix the setusercontext(3) workaround

[Duncaen]

Seeing this being used on even more system like Illumos with this ugly
and security critical bug open makes me cringe every time I check if it
was finally fixed.

I reported it directly to the maintainer in 2017. I reported it to
pkgsrc-security@netbsd.org without a response.

[slicer69]

Thanks for submitting the patch. Would you care to explain what it is you are trying to fix and why you feel it is a security issue? How is this an improvement over existing behaviour?

[Duncaen]

doas uses setusercontext(3) with the LOGIN_SETUSER flag which does setresuid(3) and the LOGIN_SETGROUP flag which does initgroups(3) and setresgid(2).
The codepath that is used when HAVE_LOGIN_CAP_H is not set, only does setuid(2) which only sets the uid, the LOGIN_SETGROUP path is completely left out.

This means your doas port does not drop the groups of the executing user.

1. This is a big problem if you use doas to run a command with less privileges, which is very security critical, this is not the intended behavior as it is on openbsd, this drastically changes what doas actually does in those cases. (Last time I used a crontab entry to switch from root to a different user as example for such a use case.)
2. If you run a script or program which creates files or directory user and group editable, it will use the executing users group id, which could lead to unintended user writable files.
3. When you have a umask set that would make it group writable, its not as expected root:root, its root:user.

The whole point I make is that this is wrong. Both openbsd doas and sudo change the group ids and making this port differ from this behavior without documenting and warning users is very very bad.

[slicer69]

I have a point of contention with the overall view. One being that I'm not sure this qualifies as a security concern. Having the group of the calling user is arguably expected, or at least certainly useful. However, I can see why, in some cases it would also be dangerous. I'm going to commit this patch and test it. Thank you for putting it together.

On a side note, I'd like to point out that my testing shows this issue, keeping the group of the original user, appears to only affect Linux. On FreeBSD group permissions were already dropped, as they were on OpenBSD, and (I think) NetBSD. Linux was the odd one out for keeping the calling user's groups. And I think this patch is worthwhile to bring Linux into the fold so it is no longer an exception.