The `sudo chroot /chroot su - user sh -c "cmd args"` trick

This "trick" is absolutely trivial. What's next, the trick about using grep to search through files? The author's lack of competence is evident due to the improper way of using su, the extremely weird idiom of sourcing the profile where it is not required and representing su as being useful for running untrusted binaries.

Simulating a login is usually not what you want. Sometimes it is, most often it is not. The author simulates a login but does not tell you why would you want to do it.

Su takes arguments that can be passed to the started shell. In particular -c can be passed to the original shell started bu su[1]; no need to start a second shell. This is not used here. Starting two shells instead of one is hardly a crime (I always do cat file | grep something instead of the more effective grep something file) but misrepresenting how su works is. In particular su does not work like "su - user cmd", as he claims, su works like "su [login [args]]" where args are passed to the started shell. The author does not understand su therefore he is not capable of writing an article about it.

The fact that he just simulated a full login only to run a non-interactive shell that manually sources .profile is hilarious, but the fact that he says chroots are good for running untrusted code is dangerously misleading.

[1] Interestingly GNU su takes -c by itself rather than passing it to the shell, but the effect of su user -c cmd is the same in BSD and Linux, although for different reasons.

1. This requires a pretty complete system environment to be set up in the /chroot directory: a shell, /etc/passwd, su, and all the libraries needed to make the program you're running work. In my experience this is the hard part.

2. chroot only isolates filesystem access but an untrusted executable might make use of your networking, for example. (Furthermore, if you're not careful an unprivileged user can become root inside the jail, and root can trivially escape chroot jails.)

Edit: I suppose the article is really about command composition and not chroot jails, but I think that a better example wouldn't involve a lot of prerequisite work.

> This is great way to execute unknown executables and code in a safe environment!

LOL wut? No. No it is not a great nor a safe way to "execute unknown executables and code". Chroots are so very inadequate for this.

I agree with agwa. I only use chroot for building live systems, not "security". And I use su and sh -c sometimes for overcoming braindead attempts at security on Linux distributions.

But I have always thought that if you were going to use chroot as some sort of security mechanism ("jails"), then you have to strip all the unneeded functionality out of the environment. It must all be removed from the system. If there is a program on the system that can do something you don't want the user to do, then either remove that program or edit the code to remove that functionality (e.g. a reduced functionality shell, etc.) and recompile.

Imagine the user uses SSH to login to a machine that only has a crippled shell (you have edited the code to remove undesired functionality) and a couple of other crippled programs that can't do much of anything. These might be combined into the same binary, similar to busybox. Any functionality that you don't want the user to have simply does not exist omnn the system. That would be my idea of "security".

Second, "This is great way to execute unknown executables and code in a safe environment!" is nonsense that I can't believe I'm still seeing in 2012. (No, schroot does not do this either.)