What commands spawn sub-shells?

My company uses a 3rd party utility to control access to root level functions that operates much like sudo. Simply prefix the command you want to run with their command, and if you have access to it, you can run the command as root. The problem is, many of my colleagues and myself have found several commands that can easily spawn a sub-shell from them (like vi) that essentially gives you an un-monitored root shell. (Great system, eh). Anyway, as luck would have it, my local ISSA chapter is hosting a spokesman from the company that produces this program at their next meeting. I'd like to grill this guy to make sure his company has addressed (whether or not my company has implemented the program properly) all the potential holes that exist as standard in most Unix distributions. Can anyone help me think of standard Unix commands that allow you to spawn a subshell, or perhaps simply allow a shell command (like /bin/bash :D)? Here's the list I've compiled so far:

more (as in !sh when viewing a file)
vi (as in :sh in command mode)
find (as in find . -exec sh)
exec (as in simply exec sh -- this command lets the current shell exit normally, and spawns a new one)
nice (as in nice -0 sh)
screen (as in screen will spawn a detatchable shell)

<edit additions>
emacs (I know you can, somehow...I hate emacs. :D)
perl (as in perl -e 'system("/bin/sh");')
awk (as in awk 'system("/bin/sh");')
python (as in python -c "import os; os.execv('/bin/sh')", or something like this...I'm not a python scripter)
</edit additions>

<edit more additions>
cat (as in cat `/bin/sh`)
echo (as in echo `/bin/sh`)
</edit more additions>

I realize there are probably several more of these things and I haven't spent very long on this list, but I was hoping that many hands would make light work. Can anyone think of others?

I dont understand the point of this. Allowing people to use sudo is dangerous and so is this. If you allow someone to execute a binary as root without prompting for a PW then you may as well give them root anyway. Even if you remove access to all those files all one needs to do is upload/write a shellcode and execute it as root. I doubt seriously your problems can be solved by listing binaries which provide shell access.

-Maestr0

Point well taken, Maestr0, but remember that this is not sudo. This company is attempting to overcome many of the security flaws in Unix with their line of tools and utilities. For example, to defeat the ability to spawn a sub-shell in vi, they have actually modified the binary of vi to disallow this feature. The idea is that a full implementation of their software would mean substituting system commands that allow shells or shell commands with their "cleaned" and "trusted" counter-parts.

Regarding your suggestion that someone could simply compile a new binary of the code and run it as root using this utility, that is not allowed. The point of this software is to grant you access to the commands you need while denying you access to the commands you don't. The ability to compile and install in the same location of an existing binary is something that cannot be done with this software. I'd love to give everyone some more details about the software company and their tools, but out of courtesy to them, I'll keep that information hidden.

Although I think I understand a little better now, I still dont think a psuedo-sudo (I made a funny :)) sounds like a security solution to me. Not without more information anyway. I've never found that more is less with access, and I dont trust users OR their binaries. :) I'm sure you'll find no end to the trickery and shenanigans you can play on this system as in your examples :

Quote:

---

Originally posted here by roswell1329

perl (as in perl -e 'system("/bin/sh");')
awk (as in awk 'system("/bin/sh");')
python (as in python -c "import os; os.execv('/bin/sh')", or something like this...I'm not a python scripter)

---

What about using your psudo to copy over orginal binaries, or chown ,chmod,ar, or ELF replacing? traces??If theres an ACL can I overwrite it with a psudo? symlinks? The possibilities to abuse this are endless to anyone with the time and will. If I can gain control of 1 root process, I can gain root, simple. (Geez, now I kinda want to see this thing and play with it, sounds kinda fun!) And you said that adding or compiling is not allowed- so? Who cares if its allowed, trick a root process into doing it for you. I'm unclear as to whether a user cant re-compile existing binaries or cant compile anything? If I've misunderstood you please explain.

-Maestr0

As I'm entering some more additions of these commands, I should tell you that all these methods for spawning a root shell work with sudo as well. (So if you wanted to experiment with this program, Maestr0, sudo would work just fine). If you have sudo access to any of these commands, you basically have root on the box. Even if you only have sudo access to 1 of these commands. And here I had the belief that sudo was actually a pretty good method of sharing control. Bummer.

As for this psudo program, I don't know all the details for it, so I am sure I'm not giving it enough credit. I know, for example, that you can flag certain vital files or even whole directories that the psudo cannot act upon with any command. As for copying a newly compiled binary into the correct path and running it, if the permissions on the directory are set correctly, you would need root to do that. If the psudo configuration included that directory, you wouldn't be able to do anything anyway. So you can basically see how with the correct configuration this system could work. There are just so many holes, and I'd like to see how tight this guy believes his product has sewn them up.

For one, with sudo you can execute a command with a another user id using the -u option, not neccesarily just root, also sudo will only allow users in /etc/sudoers to use it as well as prompt for a password (this can be controlled by a timestamped file in /var/run/sudo) I dont think allowing sudo access to root is a good idea either and is probably only used by a system processes running under a low privilege uid (and this in itself can be exploited if su'ed) needing escalated privileges to perform a specific task at specific time which STILL probably should not be run as root.


-Maestr0

EDIT:

Try this one:

psudo sed /^root/s/.*:root:/root::0:0:root:/ /mnt/etc/passwd