[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#179125: maintainer scripts tries to exec script in /tmp



Hi

On Mon, Feb 03, 2003 at 02:41:18PM +0100, Russell Coker wrote:
> 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.

Yes it was a script kiddie. And I was not good enough to protect myself
back in 1997.

> However there's usually somewhere that root can write to and then execute...

Yes usually. :)

> 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.

Yes you are right. It should not be added to policy. It is common
sense.

> > 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).

You are probably right.

I simply do not really like the solution of creating scripts and then
execute them... But that is maybe another thing. :)

Regards,

// Ola

> -- 
> 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
> 

-- 
 --------------------- Ola Lundqvist ---------------------------
/  opal@debian.org                     Annebergsslingan 37      \
|  opal@lysator.liu.se                 654 65 KARLSTAD          |
|  +46 (0)54-10 14 30                  +46 (0)70-332 1551       |
|  http://www.opal.dhs.org             UIN/icq: 4912500         |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---------------------------------------------------------------



Reply to: