7 ms·

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

22 points by pkrumins 14y ago

zx2c4 14y 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.
- pkrumins 14y ago
  Sorry about that. I updated the article and removed that statement.
aiiane 14y ago
su -c
sp332 14y 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?
- 4ad 14y 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.
  - StavrosK 14y 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)?
    - 4ad 14y ago
      > 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 14y ago
        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 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 14y ago
why is su in the chroot?
- deleted 14y ago
  [deleted]
agwa 14y 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.
- pkrumins 14y ago
  Good point about the security. I removed that sentence and just replaced it how this is a beautiful way to combine commands!
- simcop2387 14y 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 http://wiki.debian.org/Debootstrap [2] https://wiki.ubuntu.com/DebootstrapChroot https://wiki.ubuntu.com/DebootstrapChroot
4ad 14y 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.
- StavrosK 14y ago
  What's the difference between a login shell and a plain one?
  - 4ad 14y ago
    I believe the following links explain it pretty well: http://unix.stackexchange.com/questions/38175/difference-between-login-shell-and-non-login-shell http://unix.stackexchange.com/questions/38175/difference-bet... http://serverfault.com/questions/8882/what-is-the-difference-between-a-login-and-an-interactive-bash-shell http://serverfault.com/questions/8882/what-is-the-difference...
    - StavrosK 14y ago
geofft 14y 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.)
- pkrumins 14y 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 14y 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".

22 points by pkrumins 14y ago

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

pkrumins 14y ago
Sorry about that. I updated the article and removed that statement.

aiiane 14y ago

su -c

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

4ad 14y 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.
- StavrosK 14y 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)?
  - 4ad 14y ago
    > 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 14y ago
      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 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 14y ago

why is su in the chroot?

deleted 14y ago
[deleted]

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

pkrumins 14y ago
Good point about the security. I removed that sentence and just replaced it how this is a beautiful way to combine commands!
simcop2387 14y 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 http://wiki.debian.org/Debootstrap [2] https://wiki.ubuntu.com/DebootstrapChroot https://wiki.ubuntu.com/DebootstrapChroot

4ad 14y 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.

StavrosK 14y ago
What's the difference between a login shell and a plain one?
- 4ad 14y ago
  I believe the following links explain it pretty well: http://unix.stackexchange.com/questions/38175/difference-between-login-shell-and-non-login-shell http://unix.stackexchange.com/questions/38175/difference-bet... http://serverfault.com/questions/8882/what-is-the-difference-between-a-login-and-an-interactive-bash-shell http://serverfault.com/questions/8882/what-is-the-difference...
  - StavrosK 14y ago

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

pkrumins 14y 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 14y 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".