
The `sudo chroot /chroot su - user sh -c "cmd args"` trick - pkrumins
http://www.catonmat.net/blog/chroot-su-sh-trick/
======
4ad
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.

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

~~~
4ad
I believe the following links explain it pretty well:

[http://unix.stackexchange.com/questions/38175/difference-
bet...](http://unix.stackexchange.com/questions/38175/difference-between-
login-shell-and-non-login-shell)

[http://serverfault.com/questions/8882/what-is-the-
difference...](http://serverfault.com/questions/8882/what-is-the-difference-
between-a-login-and-an-interactive-bash-shell)

~~~
StavrosK
They do indeed, thank you.

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

~~~
simcop2387
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 ( _cough_ skype _cough_ ).

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

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

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

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

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

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

------
sp332
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?

~~~
4ad
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.

~~~
StavrosK
> 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)?

~~~
4ad
> Why is that?

Because he just did a login:

    
    
      silver:aram$ sudo su aram -c 'echo $PATH'
      /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
      
      silver:aram$ sudo su - aram -c 'echo $PATH'
      .:/home/aram/bin:/home/aram/bin/linux:/home/aram/bin/linux/amd64:/home/aram/bin/linux/386:/home/aram/go/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/games:/usr/local/bin:/usr/local/sbin:/home/aram/plan9/bin
      
      silver:aram$ sudo su - aram -c '. ~/.profile; echo $PATH'
      .:/home/aram/bin:/home/aram/bin/linux:/home/aram/bin/linux/amd64:/home/aram/bin/linux/386:/home/aram/go/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/games:/usr/local/bin:/usr/local/sbin:/home/aram/plan9/bin
    

> why not use sudo? Isn't that what sudo is supposed to do (i.e. pretty much
> what su -c does)?

Sure, he could have used sudo.

~~~
runlevel1
Careful adding '.' to your $PATH, particularly as the first item.

It makes it awful easy to execute something you forgot/didn't know was in the
current working directory.

UPenn gives a pretty good explanation here:
<http://www.seas.upenn.edu/cets/answers/dot-path.html>

The security issue is most relevant on multi-user systems, including hosted
services (e.g. a web server with an upload feature and misconfigured umask).

I don't do it on my personal system either because I am my own worst enemy and
am frequently saved by the Unix "rule of least surprise."

It's the usual convenience/risk balance. To each his own.

------
jrussbowman
why is su in the chroot?

------
aiiane
su -c

