Re: Making directories non-executable?

[Jens Knoell <jens@surefoot.com>]

On Tuesday 23 March 2004 13:16, Glynn Clements wrote:
> Jens Knoell wrote:
> > In an effort to tighten security, I'm trying to find out if there is any
> > solution out there to make certain world-writable directories
> > non-executable? I'd imagine an execve() wrapper should be able to do
> > that, but I was not graced with finding any solution at all.
>
> When you refer to making a directory non-executable, presumably you
> aren't talking about clearing the execute bit on the directory itself,
> but refusing to treat files within that directory as executables,
> right?

Correct.

> In which case, what exactly are you trying to achieve? Is this meant
> to be a security measure? If so, against what type of attack?

The specific scenario is that we'll run a webserver where an outside 
webdesigner can and does upload CGI's of his own choosing. From experience I 
know that this means a few of them will allow injection attacks, sometimes 
resulting in shell access. Since the only directories our webserver can write 
to are temp directories, that's where they could conceivably download 
malicious binaries.

I believe that the restrictions are tight enough to not allow them to do much 
harm, yet I do think any additional hurdle I can throw in harms way will at 
least keep script kiddies away. That's why I don't want any files being 
executed if they are in the temp directory.

> An execve() wrapper would help to protect legitimate programs against
> inadvertantly executing malicious code, but it won't restrict what
> malicious code can execute, as malicious code can just bypass the
> execve() function.

*nods* that's the idea. The legitimate program would be the webserver, and 
presumably legitimate CGI's (which would be spawned via suexec). CGI's 
commonly won't be able to write to the CGI directory, which I intend to make 
the _only_ directory from where the webserver itself can execute binaries.

> Nor will it prevent the execution of malicious code which is stored as
> a shared library rather than an executable.

I'd think if someone manages to get a library onto the machine I have a bigger 
problem at hand. Libraries should only be writeable by root, and if someone 
has root on the machine it's too late...

Thanks
Jens