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?
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.
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.
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.
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).
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.
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.
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:
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.
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.)
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.
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 comments
[ 3.0 ms ] story [ 24.4 ms ] threadWhy 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)?
Because he just did a login:
> 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.
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.
> 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.
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.
[1] http://wiki.debian.org/Debootstrap [2] https://wiki.ubuntu.com/DebootstrapChroot
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.
http://unix.stackexchange.com/questions/38175/difference-bet...
http://serverfault.com/questions/8882/what-is-the-difference...
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.
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.
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.)
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".