How to run program as another user - and permanently dropping current user privileges?

[Kenneth Burgener]

Stuart Jansen wrote:
> On Fri, 2007-02-23 at 19:26 -0700, Kenneth Burgener wrote:
>> The closest command I have found would be running something like "su
>> <user> -c <command>" which runs the command as the specified user, but
>> when the command exits, I am still user root.  I fear that it could be
>> hacked and taken advantage of.
>>
>> Is this the correct way to do this?
> 
> Well, that's think about what's happening.
> 
> 1) Your first script is running as root, normally in a forked shell
> instance just for the script.
> 2) You script reaches the su statement, fork()s then exec()s su. The su
> instance retains root privilege.
> 3) The su instance fork()s to create a child.
> 3.a) Because you are careful, you tell su to start a login shell. (su -l
> <user> -c <command>)
> 3.b) Because you are paranoid, you tell su to start a restricted shell.
> (su -l <user> -c "bash -r <command>")
> 3.c) Because you are really paranoid, you run the su command in a
> chroot. (chroot /mnt/jail su -l <user> -c "bash -r <command>")
> 4) The su child drops root privileges and exec()s the command.
> 5) The child process is going to have to use an exploit to get root
> privileges back. (Like any local user.)
> 6) The child finishes running without ever having root access.
> 7) The su instance cleans up after its child then stops running. The
> only information that came back from the child is a return code, not
> easy to exploit.
> 8) We return to the parent script which you apparently trust.
> 
> There isn't much danger of the child script getting root access. The
> real danger is information disclosure. Forgetting to scrub environmental
> variables, closing file handles, etc. Using raw setuid() doesn't solve
> any of that. Re-using tools already widely used means you can piggy back
> on someone else that hopefully got it right.
> 
> In fewer words, using su should be fine. If you're worried su isn't
> secure enough, performing a code audit shouldn't be too hard.


I got around to trying this today, but when I run my program I get an
error saying:

 [root at test ~]# su -l myuser -c "/usr/myapp/myprogram"
 "This account is currently not available."

Originally I created this user in /etc/passwd as follows:

 myuser:x:500:500::/tmp:/sbin/nologin

When I changed the shell parameter to:

 myuser:x:500:500::/tmp:/bin/bash

I was able to run the fine, and it showed up in the 'ps' list as running
as myuser:

 # ps aux
 ...
 myuser  2470 0.0 0.0 5956 372 ? Ss 16:36 0:00 /usr/myapp/myprogram

and all files created by 'myprogram' are created as the 'myuser'
program, which is what I wanted.  But I wonder if having the 'myuser'
with a default shell (and no password) would be a security hole, and
possibly allow someone to SSH to my box using this user account.  I
noticed all other daemon users have "/sbin/nologin" as their default
shell, and I assume they do this for a reason.

Should I be concerned with this?

Thanks,
Kenneth