Footnote to history: I liked codepad so much when I first saw it on HN back in 2008, I tracked down the guy who made it (Steve Hazel/sah) and made him my co-founder! :-)
Re:Pastebin, compiler, and debugger supporting 40+ languages
by kranner on Friday July 30, 2010 @12:50AM
(#1560299)
Maybe they're running the untrusted user-submitted code as processes under the 'nobody' user as a security measure.
I've built something similar for my upcoming programmer-testing service at http://codeboff.in and this is one of the precautions I've taken in my own sandboxing arrangement.
Re:Pastebin, compiler, and debugger supporting 40+ languages
by limmeau on Friday July 30, 2010 @02:39PM
(#1562114)
The Python example in parent printed an /etc/passwd full of nobody-accounts. From my error message, I only know that the first line in the compilation environment is a nobody-account. In all /etc/passwds I remember having dealt with (mostly the distribution-maintained ones of Linux distributions), the first line was the root account. This is by no means a proof that the compilation environment is guarded, but a strong hint.
Re:Pastebin, compiler, and debugger supporting 40+ languages
by kranner on Friday July 30, 2010 @06:48PM
(#1562847)
OK, but I wonder if it's not easier to just block access to /etc/passwd from the compiler while it is compiling user-submitted code. AppArmor or SELinux could be used to do this.
A decoy /etc/passwd is a bit less plausible to me.
Re:Pastebin, compiler, and debugger supporting 40+ languages
by limmeau on Saturday July 31, 2010 @04:40AM
(#1563439)
As for the plausibility of the decoy, how do you interpret the output of the Python interpreter in the great-grandparent comment?
If I had to build a compile-and-run sandbox, I'd also look into SELinux or AppArmor. However, blocking reads to /etc/passwd will disable getpwent(), which innocent programs may occasionally use, and with shadow passwords, /etc/passwd should not be sensitive anyway.
Re:Pastebin, compiler, and debugger supporting 40+ languages
by kranner on Saturday July 31, 2010 @06:05AM
(#1563512)
Hmm, I have to admit a 'nobody' account with UID and GID 0 is weird. I'm not sure if it is possible for a non-superuser to have those values so you may be right here.
With AppArmor, at least, it is perfectly possible to assign different policies to the same program. Policies are applied to programs identified by pathname so all one needs to do to sandbox, for instance, /usr/bin/gcc:
1. ln /usr/bin/gcc-4.4 ~/sandbox/compilers/gcc
2. Create and enforce an apparmor policy for ~/sandbox/compilers/gcc
3. Remember to use only ~/sandbox/compilers/gcc for untrusted code.
I do this (among other things) for my platform, and given that I only require user-submitted code to solve one of a limited set of algorithmic challenges, I can get away with blocking access to /etc/passwd (and everything else but a restricted whitelist).
I'd have to learn SOAP first, but I've been meaning to do a website similar to tryruby.com for one of my projects. This looks like it could definitely help.
Re:Pastebin, compiler, and debugger supporting 40+ languages
by kuszi on Thursday July 29, 2010 @07:01PM
(#1559622)
You can always use any of online judge services allowing you to set problem/organize contests (like http://spoj.pl) but how do you know your candidate is really solving the problem by himself?
Footnote to history: I liked codepad so much when I first saw it on HN back in 2008, I tracked down the guy who made it (Steve Hazel/sah) and made him my co-founder! :-)
How does it feel to be the author of a goddamn resume requirement? :-P
http://jobsearch.monster.com/PowerSearch.aspx?q=selenium
Until then, we've got work to do!
Now there's one for the bucket list...
http://ideone.com/Xm7TK
I've built something similar for my upcoming programmer-testing service at http://codeboff.in and this is one of the precautions I've taken in my own sandboxing arrangement.
http://ideone.com/lQbpi
http://ideone.com/icJVj
In fact it looks like '/etc/passwd' is readable to the compiler after all.
A decoy /etc/passwd is a bit less plausible to me.
If I had to build a compile-and-run sandbox, I'd also look into SELinux or AppArmor. However, blocking reads to /etc/passwd will disable getpwent(), which innocent programs may occasionally use, and with shadow passwords, /etc/passwd should not be sensitive anyway.
With AppArmor, at least, it is perfectly possible to assign different policies to the same program. Policies are applied to programs identified by pathname so all one needs to do to sandbox, for instance, /usr/bin/gcc:
1. ln /usr/bin/gcc-4.4 ~/sandbox/compilers/gcc 2. Create and enforce an apparmor policy for ~/sandbox/compilers/gcc 3. Remember to use only ~/sandbox/compilers/gcc for untrusted code.
I do this (among other things) for my platform, and given that I only require user-submitted code to solve one of a limited set of algorithmic challenges, I can get away with blocking access to /etc/passwd (and everything else but a restricted whitelist).
I'd have to learn SOAP first, but I've been meaning to do a website similar to tryruby.com for one of my projects. This looks like it could definitely help.
http://i.seemikecode.com/