Making directories non-executable?

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.

Jen
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Making directories non-executable?

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?

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?

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.

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

--
Glynn Clements
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Making directories non-executable?

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
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Making directories non-executable?

--IJpNTDwzlM2Ie8A6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Jens Knoell [Tue, Mar 23, 2004 at 11:25:12AM -0700]:
> In an effort to tighten security, I'm trying to find out if there is any=
=20
> solution out there to make certain world-writable directories non-executa=
ble?=20

chmod a=3Drw dir

or

chmod a-x dir

man chmod helps.
You may also look at ACLs.

Nico

--=20
Keep it simple & stupid, use what's available.
pgp: 8D0E E27A | Nico Schottelius
http://nerd-hosting.net | http://linux.schottelius.org

--IJpNTDwzlM2Ie8A6
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAYLxGzGnTqo0OJ6QRAqCMAJ9xfRVYC6TCu5ae3ExY1KMesL+1xgCf UuTN
HM0L9ItJJg25AigvCaX7+1c=
=J15i
-----END PGP SIGNATURE-----

--IJpNTDwzlM2Ie8A6--
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Making directories non-executable?

There is an option when mounting partitions: noexec .
It is advisable to have a separate partition for /tmp (if this is the
directory you're trying to make it a "non executable medium") and mount
it with noexec (and nosuid) option(s).



George Iosif

-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Making directories non-executable?

Jens Knoell wrote:

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

In which case, an execve() wrapper should suffice; glibc defines
execve as a weak symbol, so overriding it in an external library would
still affect glibc functions which use it.

OTOH, putting the temp directories on a separate filesystem which is
mounted with the noexec flag will also work, and may be more robust as
the restriction is implemented by the kernel rather than in user space.

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

I was referring to the situation where, rather than upload a malicious
executable, they upload a malicious shared library into the temp
directory then use e.g. "LD_PRELOAD=/tmp/malware.so /bin/true".

--
Glynn Clements
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html