Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |