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

http://www.catonmat.net/blog/chroot-su-sh-trick/

by pkrumins • 14 years ago

22 21 14 years ago

sp332• 14 years ago

The '-' in "su - user" runs the shell as a login shell. Is that useful? Also it means you really don't need to specify "sh" as the command to invoke, since su will run the user's default shell, right?

4ad4• 14 years ago

Yes, you probably want su rather than su -. He uses sh only to run some command but that's obviously superflous, he should just use su -c. The fact that he sources the user's profile is hilarious. The fact that this remarkably poor and trivial article made it to the HN front page is sad.

StavrosK3• 14 years ago

> The fact that he sources the user's profile is hilarious.

Why is that?

Also, if all he wants is to run a command, why not use sudo? Isn't that what sudo is supposed to do (i.e. pretty much what su -c does)?

jrussbowman• 14 years ago

why is su in the chroot?

zx2c4• 14 years ago

From TFA:

> 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.

pkrumins4• 14 years ago

Sorry about that. I updated the article and removed that statement.

aiiane• 14 years ago

su -c

agwa• 14 years ago

A couple important points which are missing from the article:

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.

pkrumins4• 14 years ago

Good point about the security. I removed that sentence and just replaced it how this is a beautiful way to combine commands!

simcop2387• 14 years ago

If you're alright with linux and can run the program on a debian derived distro, it's very easy to do these days with debootstrap. I've setup multiple jails on my computer for various software that doesn't play nicely with a rolling release distro all the time (coughskypecough).

[1] http://wiki.debian.org/Debootstrap [2] https://wiki.ubuntu.com/DebootstrapChroot

4ad4• 14 years ago

How did this extremely poor written and technically incorrect article make it to the Hacker News front page?

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.

StavrosK3• 14 years ago

What's the difference between a login shell and a plain one?

4ad4• 14 years ago

I believe the following links explain it pretty well:

http://unix.stackexchange.com/questions/38175/difference-bet...

http://serverfault.com/questions/8882/what-is-the-difference...

pkrumins4• 14 years ago

Thanks for the great comment! I just updated the article and explained that I misunderstood how "su" works. I also removed the statement about running untrusted binaries. I had simply added it to the article without thinking much to have a closing line for the article.

I found sourcing the profile trick useful in case the chrooted users need a customized environment such as custom PATHs or something else user specific.

thaumaturgy• 14 years ago

How did this rude and in poor taste comment make it to the top of the thread?

Peteris is a solid HN contributor with 216 submissions to date, many of which focus on math or programming or shell tricks, which puts him head and shoulders above those that submit the daily sewage from techcrunch.com (or those, like me and you, that don't submit at all).

Here's a quick sample of some of his top HN submissions:

1. Announcing his business, making virtual machines accessible over the web (and open-sourcing the code behind it): http://news.ycombinator.com/item?id=1534973

2. An introduction to pipe viewer: http://news.ycombinator.com/item?id=462244

3. Top Ten One-Liners from CommandLineFu Explained: http://news.ycombinator.com/item?id=1200900

4. Low-level bit hacks: http://news.ycombinator.com/item?id=1811104

5. Using Fibonacci Numbers to Convert from Miles to Kilometers and Vice Versa: http://news.ycombinator.com/item?id=1050151

6. How I went to Silicon Valley and raised $55,000 for Browserling: http://news.ycombinator.com/item?id=2808314

7. How to steal a botnet: http://news.ycombinator.com/item?id=1072225

etc.

And, his submissions often provoke even greater discussion in comment threads, even when they contain a mistake (as in http://news.ycombinator.com/item?id=3684515).

Peteris is legit (and a really nice guy besides). No matter how much you know, it's likely that he's written about something you don't know. He has earned enough respect from the HN community that he deserves to have corrections to his articles submitted gracefully and with tact, not with accusations of incompetence.

geofft• 14 years ago

First off, there are tools for this like schroot that make this easier and are intended for this type of use case.

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.)

pkrumins4• 14 years ago

I removed that sentence and just replaced it how this is a beautiful way to combine commands! :) I wrote that one earlier without much thinking, just to have something as a closing line.

pokesomesmot• 14 years ago

Why is something that can be gleaned from a man page a "trick"? Boy reads man pages. News at 11.

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".

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

Related Stories