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: [EMAIL PROTECTED] ~]# 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 /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
