|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: What could have been done differently?
On Tue, Jan 28, 2003 at 08:14:17PM +0100, [email protected] said: [snip] > restrictive measures that operate with sufficient granularity. In Unix, > traditionally this is done per-user. Regular users can do a few things, > but the super-user can do everything. If a user must do something that > regular users can't do, the user must obtain super-user priviliges and > then refrain from using these absolute priviliges for anything else > than the intended purpose. This doesn't work. If I want to run a web > server, I should be able to give a specific piece of web serving > software access to port 80, and not also to every last bit of memory or > disk space. Jeremiah Gowdy gave an excellent presentation at ToorCon 2001 on this very topic - "Fundamental Flaws in Network Operating System Design", I think it was called. I'm looking around to see if I can find a copy of the lecture, but so far I'm having little luck. His main thesis was basically that every OS in common use today, from Windows to UNIX variants, has a fundamental flaw in the way privileges and permissions are handled - the concept of superuser/administrator. He argued instead that OSes should be redesigned to implement the principle of least privilege from the ground up, down to the architecture they run on. OpenSSH's PrivSep (now making its way into other daemons in the OpenBSD tree) is a step in the right direction. I'm still looking for a copy of the presentation, but I was able to find a slightly older rant he wrote that contains many of the same points: http://www.bsdatwork.com/reviews.php?op=showcontent&id=2 Good reading, even if it's not very much practical help at this moment. :) > Another thing that could help is have software ask permission from some > central authority before it gets to do dangerous things such as run > services on UDP port 1434. The central authority can then keep track of > what's going on and revoke permissions when it turns out the server > software is insecure. Essentially, we should firewall on software > versions as well as on traditional TCP/IP variables. The problem there is the same as with windowsupdate - if one can spoof the central authority, one instantly gains unrestricted access to not one, but myriad computers. Now, if it were possible to implement this central authority concept on a limited basis in a specific network area, I'd say that deserved further consideration. So far, the closest thing I've seen to this concept is the ssh administrative host model: adminhost:~root/.ssh/id_dsa.pub is copied to every targethost:~root/.ssh/authorized_keys2, such that commands can be performed network-wide from a single station. While I have used this model with some success, it does face scalability issues in large environments, and if your admin box is ever compromised ... > And it seems parsing protocols is a very difficult thing to do right > with today's tools. The SNMP fiasco of not long ago shows as much, as > does the new worm. It would proably a good thing if the IETF could > build a good protocol parsing library so implementors don't have to do > this "by hand" and skip over all that pesky bounds checking. Generating > and parsing headers for a new protocol would then no longer require new > code, but could be done by defining a template of some sort. The [snip] It's the trust issue, again - trust is required at some point in most security models. Defining who you can trust, and to what degree, and how/why, and knowing when to revoke that trust, is a problem that has been stumping folks for quite a while now. I certainly don't claim to have an answer to that question. :) -- -= Scott Francis || darkuncle (at) darkuncle (dot) net =- GPG key CB33CCA7 has been revoked; I am now 5537F527 illum oportet crescere me autem minui Attachment:
pgp00029.pgp
|