On Mon, 3 Feb 2003 14:02, Ola Lundqvist wrote:
> > I still can't see how setting noexec on /tmp helps security. You would
> > still have to type an explicit path to execute any program, so it's no
> > different from any other arbitrary path. Is it intended to protect
> > against people who put . in their path?
>
> Well I can imagine a lot of things that noexec prevents. I actually
> have caught a cracker (a successful one) this way. The cracker used
> some flaw and wrote files to /tmp. Then it tried to execute them
> but failed. The user actually had root access so he should have been able
> to do anything but he had created the suid root shell and placed it
> in /tmp. So he failed. :)
That was a script kiddie. At the very least they should have had a fall-back
plan of deleting the file under /tmp to hide their traces, a good script
would even do this.
However there's usually somewhere that root can write to and then execute...
If you had been running SE Linux then cracking a daemon running as root and
then getting it's privs would not gain you anything unless the daemon in
question was sshd, and even cracking that wouldn't give you administrative
privs.
> I would like to add such a thing to policy, yes.
There's probably a hundred more useful security things that should be added to
policy. Making the shell of dummy accounts be /bin/false is one that springs
to mind.
> If a package really need to write files and then execute them they should
> be changed to create them under /var/lib/pkgname so that only the user that
> the software runs as can write the files there. If it is an end user
> program the executables should be stored and execeuted in the home
> directory.
Storing temp files in the home directory provides no good way of cleaning them
out and therefore results in a loss of disk and backup space for multi-user
systems. Also it removes the ability to do various performance optimisations
(tmpfs, or RAID-0 for /tmp, mkfs of the /tmp device at boot time, etc).
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page