On 1998.07.20, Brett Lymn <blymnat_private> wrote: > A sufficiently determined programmer can write crap code despite the > language. This is the key issue with the inherent security problems. The collolary to this statement is "better tools allow bad programs to implement bad designs faster." Using "better tools" as others seem to suggest will *not* gain us any more "security" than we already have, if we don't also change the quality of programmers. Yes, some people believe Eric Allman is a "good" programmer. And, as someone replying to this list has said, "10,000 lemmings can't be wrong." The problem is not in the implementor, nor the implementation, but elsewhere. The real problem in system security really comes from the flawed design from which software is implemented from (or worse, no real design at all). I recall someone on this list as saying, "user programs are meant to be user-friendly, secure programs are meant to be secure." This is a very clever way of indicating the necessary focus of the two classes of software. To clearly restate, "privilaged programs should be simple in design and implementation; they should do one thing, and do it well." In this particular case of imapd, the blame doesn't lie upon the programmers nor the tools they used, but more the design itself. Why in god's name should a mail system require system-wide root privilages? As a normal user, I should be able to manipulate my own mailbox. Why shouldn't the agent through which I manipulate my own mailbox run, from start to finish, with no more privilages than my own user? And, for the section that *must* have extra-privilaged execution, keep it so simple that one could easily hand-trace it's execution and guarantee some comfortable level of safety. If one can't envision a design that follows this practice, that is where the blame should lie. "Tools don't produce bad software. Bad designers produce bad designs from which bad software is implemented." In developing new "secure systems," we should spend less time *securing* already existing insecure systems, in the hopes of deluding ourselves that they have somehow become "secure" (when we know we can never prove such a thing). We should instead focus our energies on designing software systems where the threat-level is as minimal as possible. This still won't prevent lost work and other problems, but if this is a significant issue, why does a tool like "rm" exist? Yes, in the wrong hands, "rm" can be very devastating. But, without necessary privilages, the scope of the damage is much smaller. So, design tools that do not require unnecessary privilages, and focus on preventing unauthorized gain of those privilages. Don't work the other way around, letting software run with privilages and simply trying to make them behave perfectly. That's a much harder task. The traditional argument is that "with the way things currently are, it may be nearly impossible to redesign services to not require privilages." Well, then, if you want a secure system, be prepared to build one---from scratch, if need be. Perhaps even the existing notion of UNIX-based privilages is insufficient for any real security - design a better model, and implement it. Don't complain about the tools people choose to use, as changing those won't improve security, they'll just give us new types of security problems to find. -Dossy -- URL: http://www.panoptic.com/~dossy -< BORK BORK! >- E-MAIL: dossyat_private Now I'm who I want to be, where I want to be, doing what I've always said I would and yet I feel I haven't won at all... (Aug 9, 95: Goodbye, JG.) "You should change your .sig; not that the world revolves around me." -s. sadie
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:06:46 PDT