On Fri, 25 Sep 2015 02:09:40 +0900 Joel Rees <[email protected]> wrote: > At any rate, I have convinced myself that doas follows the manual page > in preserving the calling user's key environment variables, including > HOME and USER. > > I had not grasped that this was considered desired behavior, so did > not initially read it that way. I still think the man page is a little > confusing, but do not at the moment have any suggestions for > clarifying things. (Now I'm not sure what doas is for, other than for > running build scripts more safely, which I think it will be much more > reliable at than sudo.) > > For the purpose below (allowing running firefox as a non-login user), > I've installed sudo, and note that sudo -s now passes quoted strings > as if the string itself were the command, such that scripts that were > > sudo -H -u user2 -s "cd; command" > > must now explicitly say sh -c, as > > sudo -H -u user2 sh -c "cd; command" > > For the larger purpose, providing a reliable sandbox, I'm going to see > whether chroot would allow me to use a non-login user as proxy user > for the stupid (pardon my French) bloated web browsers.
i had a thread 'isolating untrusted programs in ssh chroot jails' (https://marc.info/?l=openbsd-misc&m=142676615612510&w=2) that covers this in detail. David Coppa reported that it was possible to do for firefox. you need a user with a shell for this to work however, but you can disable password authentication. from passwd(5): Similarly, login accounts not allowing password authentication but allowing other authentication methods, for example public key authentication, conventionally have 13 asterisks in the password field. so you can ensure that a local key is necessary to log in. and you can ensure that it only runs firefox with the ForceCommand directive (it's all in that thread, and more in the linked threads). > > On Wed, Sep 23, 2015 at 8:29 AM, Joel Rees <[email protected]> wrote: > > Thank you, Dan, Ben, and Frank. I see that I have left out some > > important information: > > > > user2 is specified as a non-login class of user in /etc/login.conf, > > auth=reject: shell=/sbin/nologin, and has a default shell of > > /sbin/nologin in /etc/passwd . > > > > On Tue, Sep 22, 2015 at 5:41 PM, Joel Rees <[email protected]> wrote: > >> I have this rule in doas.conf: > >> > >> permit nopass user1 as user2 > >> > >> As user1, I try this at the command line: > >> > >> doas -u user2 whoami > >> > >> and it tells me I am user2, as I expect. And > >> > >> doas -u user2 ls > >> > >> tells me I don't have permission. I kind of expect this. > >> > >> I'm looking for a way to do the equivalent of > >> > >> sudo -u user2 -s "cd; ls" > >> > >> I don't see a way to do this with doas, at least not without a short > >> intermediary script, which script is not going to be able to do cd ~/. > >> > >> Should I assume that doas is not intended to do this sort of thing? > > > > With this intermediary script: > > > > #! /bin/sh > > export USER=user2 > > . /etc/ksh.kshrc > > printenv > > ls > > > > I get > > > > MAIL=/var/mail/user1 > > LOGNAME=user1 > > HOME=/home/classU/user1 > > > > PATH=/home/classU/user1/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:. > > DISPLAY=:0.0 > > TERM=xterm > > USER=user2 > > ls: .: Permission denied > > > > Which, I guess, does surprise me. > > > >> (And therefore [I should] do things "right" by setting up ssh with > >> public-key > >> authentication to do the user switch?) > > > > Which would also require enabling login for user2. (I tried this > > without thinking yesterday.) > > > >> (Or go all out and set up chroot to run an instance of X11 and firefox? ;-/ > >> ) > > > > Would this also require enabling login? > > > > -- > > Joel Rees > > > > Be careful when you look at conspiracy. > > Arm yourself with knowledge of yourself, as well: > > http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html > > > > -- > Joel Rees > > Be careful when you look at conspiracy. > Arm yourself with knowledge of yourself, as well: > http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html
