Executables in /tmp necessary?
Hello all, I am setting up a server where users will have shell access (ssh). I want to prevent anyone from uploading and running their own binaries. The idea is simply to make sure that all partitions where users have write access will be mounted with the noexec flag. My only problem is /tmp (which is also a separate partition), where the users will have write access since they have a shell. Is it safe to mount /tmp with noexec too? Or will it break any programs - if so which? The server runs lots of stuff; apache/php, samba, cvs, qmail + courier-imap + fetchmail + procmail for mail system, named, dhcp, sshd, (i may have forgotten some). Any experience and comments are welcome Thanks, Simon
Hello all,
I am setting up a server where users will have shell access (ssh). I want to prevent anyone from uploading and running their own binaries. The idea is simply to make sure that all partitions where users have write access will be mounted with the noexec flag. My only problem is /tmp (which is also a separate partition), where the users will have write access since they have a shell.
Is it safe to mount /tmp with noexec too? Or will it break any programs - if so which? The server runs lots of stuff; apache/php, samba, cvs, qmail + courier-imap + fetchmail + procmail for mail system, named, dhcp, sshd, (i may have forgotten some).
Any experience and comments are welcome
http://www.securityportal.com/lskb/articles/kben10000036.html mounting /tmp noexec will break very little (in my opinion anything that moves/copies binaries to tmp and then executes them is broken). It shouldn't be a problem. You should also look into PAM to restrict what users can do: http://www.sysadminmag.com/current/feature.shtml
Thanks,
Simon
Kurt Seifried SecurityPortal, your focal point for security on the net http://www.securityportal.com/
* Kurt Seifried wrote on Sun, Aug 13, 2000 at 14:16 -0600:
I am setting up a server where users will have shell access (ssh). I want to prevent anyone from uploading and running their own binaries. The idea is simply to make sure that all partitions where users have write access will be mounted with the noexec flag.
mounting /tmp noexec will break very little (in my opinion anything that moves/copies binaries to tmp and then executes them is broken). It shouldn't be a problem.
... but it helps a very little only.
Take a look how to run a non-exucutable file:
dx:/tmp # ls -l date
-rw-r--r-- 1 root root 25272 Aug 14 09:57 date
dx:/tmp # /lib/ld-linux.so.2 ./date
Mon Aug 14 10:01:57 MEST 2000
So the noexec option isn't helping (thanks to Jari Laurila
... but it helps a very little only. Take a look how to run a non-exucutable file:
dx:/tmp # ls -l date -rw-r--r-- 1 root root 25272 Aug 14 09:57 date
dx:/tmp # /lib/ld-linux.so.2 ./date Mon Aug 14 10:01:57 MEST 2000
So the noexec option isn't helping (thanks to Jari Laurila
for pointing that out on focus-linux).
This is true, but most scripts/etc assume /tmp can hold executables and execute them without any funkiness like /lib/ld-linux.so.2 /tmp/rewt-shell Since security is NEVER 100% absolute, and is about risk management I would say it's still worth doing since it mitigates some risk (many "default" scripts will break). If you do enough of these little fixes you can make life pretty rough on the attacker.
oki,
Steffen
-Kurt
* Kurt Seifried wrote on Wed, Aug 16, 2000 at 01:46 -0600:
* Steffen Dettmer wrote:
* Simon Lodal
wrote: [-- at this ident level --]
Take a look how to run a non-exucutable file: So the noexec option isn't helping
This is true, but most scripts/etc assume /tmp can hold executables and execute them without any funkiness like /lib/ld-linux.so.2 /tmp/rewt-shell
Correct, but the question/idea was:
I want to prevent anyone from uploading and running their own binaries. The idea is simply to make sure that all partitions where users have write access will be mounted with the noexec flag.
And "noexec" is no way to prevent anybody from executing own binaries, they can still do.
Since security is NEVER 100% absolute, and is about risk management I would say it's still worth doing since it mitigates some risk (many "default" scripts will break).
It wasn't the idea of breaking default scripts IRRC; the question was if a system with noexec mounted /tmp/ is still working without problems. default Scripts work still when invoked as parameter to the interpreter, i.e. "perl test.pl" (BTW, this is dangerous, too, since perl can make syscalls etc.), since the interpreters are still executable (but not writeable, but this doesn't matters here I think).
If you do enough of these little fixes you can make life pretty rough on the attacker.
Well, let's say you can make life bad for script-kiddies :) But I think the original poster wanted to prevent the local users from executeing binaries. You're right if you say an ordinary user wouldn't know how to work around noexec fs, normally ;) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
I want to prevent anyone from uploading and running their own binaries. The idea is simply to make sure that all partitions where users have write access will be mounted with the noexec flag.
And "noexec" is no way to prevent anybody from executing own binaries, they can still do.
Oh, you wanted an answer to _that_ question. =) Ok several ways I see of doing it: chroot. dump the user into /home/username, with a basic command shell (bash) and any utilities they need, chances are it's relatively little. Statically compile everyything so there's no /lib/, yadaya. SOmeone posted chroot patches for telnet to linux-security-audit a few weeks back. I wouldn't try this unless you're a glutton for punishment, it will be PAINFULL to setup. Don't do it, put the challupah down. A restricted shell like... http://www.whizziwig.com/drsh.shtml I haven't used this, but it looks like it might do the trick. Other solutions come to mind but they involve some voodoo magic and software that isn't really public/easily available or "compatible" with SuSE (you'd end up with a new distro basically). You prolly also want to limit what the users can do memory/cpu wise: http://www.sysadminmag.com/current/feature.shtml You may applaud at will ;)
oki,
Steffen
-Kurt
participants (3)
-
Kurt Seifried
-
Simon Lodal
-
Steffen Dettmer