Re: Linux hardening

On Tuesday 30 August 2005 02:51, Kir wrote:
> > What do you mean? Curl prints to STDOUT. If someone manages to exec a
> > shell, couldn't he just redirect the curl output to /tmp as he desires?
> >
> > Anyway, it seems to me it'd be more effective to make sure he cannot
> > execute whatever it is he downloaded; the noexec flag and GRSec's TPE
> > would probably both be useful for that.
> >
> > Or did I misunderstand you?
>
> You  misunderstood.  Method  above was meant to be used with
> wget,  that  dumps  received  file  into  file. But it`s not
> impossible  to  modify  curl`s  source to behave in the same
> way:  force  it to redirect received data into file and then
> apply the same hack.
>
> Am I wrong?

Excuse for being blunt, but I believe this approach is useless. There are many 
ways an intruder could grab a remote file, from wget/curl, perl/python 
one-liners, and even from bash scripting (yes, I've seen it done through 
careful filehandle and socket mangling). So, unless you disable all downloads 
from your machine, them you are just restricting the options an intruder 
would have, but not eliminating the possibility of downloading externals 
files.

Many people have mentioned grsec/PaX, mounting /tmp with noexec and many other 
variations. These are, IMHO, much better approaches because they are system 
configuration parameters, not based on application patching. If you choose to 
patch your applications then you'll have to keep track of all updates to 
these applications (i.e., through apt-get, yum, emerge or whatever is the 
package manager of your choice -- after all one must update server software 
at some time, especially when it comes to security updates) which could 
override your modifications, and backport your modifications into every new 
version that comes out. And even then you would not have the same level of 
security provided by a containment solution such as grsrc/PaX.

Then again, these are just my $0.02...

Kind regards
Ulisses Montenegro