Date: Mon, 21 Feb 2000 11:29:48 +0000 From: Paul Richards <paul@originative.co.uk> To: Mark Murray <mark@grondar.za> Cc: Peter Wemm <peter@netplex.com.au>, current@freebsd.org, committers@freebsd.org Subject: Re: Crypto progress! (And a Biiiig TODO list) Message-ID: <38B121AC.B2F0E2E3@originative.co.uk> References: <20000218062947.B0DDE1CD9@overcee.netplex.com.au> <200002180743.JAA26529@gratis.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Murray wrote: > > > Mark Murray wrote: > > > > I'm very uncomfortable with requiring Yet Another Daemon to manage > > > > (and screw up) password checking. Generally speaking, if I wouldn't > > > > trust a program with root privileges, I wouldn't trust it with my > > > > password, either (for obvious reasons). > > > > > > If "all those" suid programs could be "de-suid'ed", and replaced with > > > a simple "does this username/password pair check out?" daemon/module, > > > would that make you happier? > > > > As long as there is some sort of rate limiting system so that it doesn't > > provide a trivial online brute force password cracking service... Getting > > this right would be an interesting challenge. :-) > > Easy to do of the daemon is not on by default, or if it is pretty fascist by > default, with lots of options to define the fascism. I think there are risks with this approach and I'm not sure the benefits are clear cut. My main concern is single point of failure. It's only an improvement on what we have now if we can remove suid programs. If you do that then the *only* way to authenticate is via the daemon. If you screw the daemon in some way and you don't already have a root session then your only option is to hit the power switch. At the moment, if you screw login you can su, if you screw su then you can login at the console etc etc. The daemon becomes an obvious target for DOS given how critical it is and any weakness that would cause it to fail would result in a catastrophic system failure. There aren't many (any?) system processes that are that critical. How are you going to deal with single-user boots? I can't really see how you can remove all password related suid programs, only a few of them. The other concern is that at the moment you can't get access to the encrypted password without being root. With a daemon any user can process can access that information. I accept that this might not be a losing position since any user script could run su or password repeatedly but it seems to me that there isn't a *clear* security enhancement here. The daemon approach actually has benfits that I'm keen on that aren't related to security. A single point of access to the data means that the backend can be changed so that passwords can be in a different file or a database, without having to worry about rebuilding all the binaries. You could even split users across different back end systems. It would be interesting to extend the whole idea so that there were username classes e.g. system account, web site user and so on. Then you could use the same database to hold all account information. This is of course what NT does and most people hate that because the web server then has access to the login passwords. If you're going to have a daemon though that any user process can connect to then this is the direction you're moving in so you may as well take the added functionality that comes with it and make it a generic authentication system that can be used for things like web servers. On the whole though, I'm not sure that this is a direction that has a definate win to it. How many binaries are there that have access to the master.passwd file? How many lines of code need to be audited for those binaries, compared to the number of lines of code needed to implement a secure daemon solution? Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38B121AC.B2F0E2E3>