Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

System cracked, a story



Knock on wood, I haven't (knowingly) been hacked since I started putting
systems online.  It looks like a compromise will inevitably occur; once a year
or so, I'll go digging through the CERT advisories and find at least a couple,
if not a half-dozen, vulnerabilities in the code I'm running.

I run the following on one or another of my home systems:

  sshd (v1)
  sendmail
  samba
  xntpd
  mysql
  apache w/php
  dhcpd
  ddclient
  bind9
  amanda

It's a long enough list that bugs are constantly found, particularly in
sendmail.  I don't think a firewall can do a whole lot to prevent an eventual
exploit:  some of these packages are inaccessible from outside, but a minor
vulnerability in one of them could be combined with a root vulnerability in
another that can be exploited behind the firewall.

My vigilance is way too low.  What I really want is a tripwire thingie that
compares my installed software with the CERT database, and sends me an email
the minute an advisory comes out instead of my having to poll it every few
days/months (an attacker could come along five minutes after the advisory, if
I were being targeted).

There is an architectural issue about Linux that I've long wondered about. 
Why hasn't the security model been DRASTICALLY enhanced so as to narrow the
scope of what each application can do?  For example, a sendmail program
doesn't really need root; it needs only to listen on socket 25 and to call
another program which writes user mail files.  Crond doesn't really need root.
 Apache *never* needs root.  The DHCP server only needs raw access to an
Ethernet device.  And so on.  But the default way most of these things are set
up is to start up as root and then setuid themselves to some other ID; no
daemon should ever have root to begin with, IMHO.

Without fixing the basic security architecture, one obvious problem with the
existing check-CERT/apply patches model is the sheer labor-intensiveness of it
all.  I dread my annual checks for security patches, because I know it'll be
at least hours, if not days before I'm done applying all the required patches
and getting my systems running normally.  The sweep that I did this April was
extraoardinarily time-consuming:  I had to download, recompile, and re-test
virtually every line of source code running on all my systems.  Yes, I have
peace of mind knowing that it'd be very challenging for a cracker to attack my
systems today.  But in a few months, that peace of mind will fade.

-rich





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org