[MLUG] Re: Security: Libsafe

Mark Donnelly gimli at offcenter.org
Fri Apr 21 12:25:25 EDT 2000


Quoting Robert L Krawitz <rlk at alum.mit.edu>:

> Well, then the program will continue on with garbage
> data (of a different kind).  Is that really desirable?
[snip!]
>
> One obvious use for this is for the system
> administrator to put it in /etc/ld.so.preload as part
> of an overall hardening procedure.  Having it be
> defeatable gets around the whole purpose of doing
> that.

Well, you're right.  I would like to put it 
in /etc/ld.so.preload for general use.  The thought of 
network services without the possibility of buffer 
overruns really appeals to me.

*However*, the though occurs to me that some script 
kiddie can be scanning the net around the clock.  What 
happens if I get hit at 12:20 in the morning?  I might 
have just gone to bed, and my services die because of 
this buffer overrun.  This means that I have to 
remember to check that my services are available *every 
morning*, and before I go to work, due to my firewall 
that won't let connections out either.  I can't always 
do that.

So, what if I miss it for a few mornings in a row?  
What if I'm on a vacation and unable to check these 
services?  Just taking mail, things start to bounce.  
All of our lists start detesting us because we've 
returned a bum email address.  You get the idea.

SO, the behaviour that I'd rather have would be to 
silently truncate the string operation to the limits of 
legal memory, in this case.  This is based off the 
assumption that the buffer overruns that we're likely 
to encounter these days are not through common use, but 
rather through malicious intent.  With that assumption, 
I would rather have the service stay in operation and 
simply deny the malicious intent.

Mind you, I'd be all for killing everything that is 
automatically respawned.  Things like ftpd or getty 
would be fine.  However, the fear of losing my services 
like SMTP and HTTP brings me to avoid installing this 
library.  (which is too bad, because I *love* the 
idea!)  If I could control which behaviour happens to 
which programs, I'd leave the default to kill and make 
a couple of exceptions for my "must-be-up" services.  

Just my two bits,
--Mark Donnelly

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).



More information about the Discuss mailing list