From kragen@dnaco.net Wed Sep 30 11:08:18 1998 Date: Wed, 30 Sep 1998 11:08:17 -0400 (EDT) From: Kragen To: Chris Evans cc: "Stephen C. Tweedie" , Paul Boehm , security-audit@ferret.lmh.ox.ac.uk Subject: Re: rootd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: On Wed, 30 Sep 1998, Chris Evans wrote: > Sometime recently I finally managed to pinpoint my nagging concern over > security approaches such as this. Take a program such as "su". Under the > old scheme it is suid root, so it's a case of one cock-up in the su code > and bang your security is history. > > Under a "rootd" scheme su gets its privileges relegated to only being able > to make requests to the "rootd" program. With such a powerful program as > "su", the requests involved are unfortunately stuff like "switch my UID to > xxx please". So compromise "su" and you just send a bogus request to rootd > and you're back at stage one. Preferably 'su' would have to send a password to rootd. > I think a more effective persuit of security is damn thorough auditing, > and more interestingly, a bit of recoding of stuff so it runs with less > privileges. I think this is certainly worthwhile. I suggest that looking at better ways of doing things might also be worthwhile; the Unix approach to security is fundamentally broken. Mandatory access controls cannot be implemented; information leakage is impossible to prevent; denials of service are impossible to avoid; jailing possibly-compromised processes is essentially impossible. The approaches that offer the most toward solving these problems are basically complete replacements for the Unix security model. Mandatory access controls and jailing possibly-compromised processes (which are really the same thing) gets done by writing a system-call monitor. Fixing denials of service means changing scheduling and memory allocation to use beancounter objects. Auditing everything damn thoroughly is the plug-all-the-holes approach, also known as the "Microsoft approach to building bug-free software". It is not very effective. Rewriting things to need less privilege is definitely worthwhile. The trouble, basically, is that there are hundreds of setuid programs, a 750,000-line kernel (well, OK, most of that isn't compiled in) talking to the network and all your untrusted programs, and some small but finite number of bugs among all of these things. The interface between the untrusted world and 'root' is very large and complex. As a result, it's relatively porous. Rewriting things to need less privilege reduces this. The interface between the totally untrusted world (people who send you email, for example) and authenticated local users is even worse, and will probably stay that way. Kragen -- Kragen Sitaker A well designed system must take people into account. . . . It's hard to build a system that provides strong authentication on top of systems that can be penetrated by knowing someone's mother's maiden name. -- Schneier