![]() |
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 |
Derek Martin wrote: > You need a total ste security plan. > > ... port 25 is a privileged port, and > opening it requires root privileges[1]... >> ... DHCP server only needs raw access to an Ethernet device. > ...which requires root privilege[1]. > Which is why diligence is required. If you don't stay on top of it, > you almost may as well not bother. In the end, it's much less work to > have a complete site security strategy and diligently maintain > software updates Your arguments sound like those of a security consultant-for-hire who will be happy to come over and for, say, $2500 in monthly fees set up and maintain a customized "site security plan". And my argument doesn't conflict with yours at all; obviously, if you have more than $30,000 a year worth of data to protect, then by all means you should invest about that amount (or more) in site-security planning and maintenance. I have an MP3 library, a collection of old email, and the obligatory 7 years worth of financial records. If it all got lost in a house fire, then I might complain to the heavens about how unfair life is--but I wouldn't be out $30,000 or even $10,000. Life would somehow carry on. In fact most home users have even less at stake than I do. Diligence really is not a good investment for us: in the worst possible case, assuming we have that third line of defense in place (backup tapes), after a security break we simply spend a few hours or days reinstalling and putting our system back together. It takes less time to do a restore than to write up your first security plan, let alone keep it current on a month-to-month/year-to-year basis. That's why my argument is orthogonal to yours: it calls for making security breaches less common, through architectural improvements to the system. Linux vs. Microsoft has an interesting challenge in this area. Bill Gates finally woke up about a year ago to the fact that his entire legacy is threatened by a mushrooming number of security problems. So by edict, he was able to get the company focused on re-architecting the entire system to put the bulk of those problems in the past. It will be painful and it will take a long time, but as software dictator of the overall system, Gates is in a better position to force necessary change than anyone in the freeware community is. Linus Torvalds could, I suppose, attempt to shepherd Linux developers into a new security model (which would in place of "root" for a process that needs access to raw sockects or to open a single well-known port like 25 would define ACL's or some more-sophisticated method of launching programs within a narrowly-defined security definition). But Linux is suffering at this point from the 1980s Unix problem: too many rival distributors who want to define the one true way of doing things, and convince everyone else to go along. You can't implement a new security model without changing the apps, and you can't change the apps without kernel support. That's the thrust of my argument. Put another (frightening) way, I see Microsoft scoring some big wins over Linux in the next 3 years unless this security issue is addressed in a cooperative fashion by the Linux developer community. Why is it important? Well, the number of standalone Linux boxes connected to home cable-modems exceeds, probably by far, the number of corporate sites which can affort $30K+/year in security management. Those standalone boxes represent a huge threat to Internet stability unless security is fixed in a global, set/forget way for home users. The likely alternative is that cable-modem suppliers will increasingly strangle the useful connectivity of home-based computers in general. You are calling for diligence at the per-site level. I am calling, in turn, for diligence at the macroscopic, developer level. -rich
![]() |
|
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |