Re: BSD Auth

["Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost>]

On 19-Aug-08, at 9:02 PM, David Holland wrote:
> A real solution will, among other things, not require getty and login
> to run as root. This solution does not currently exist.

I don't know about getty -- it only needs sufficient privileges to  
gain access to specific devices as far as I can tell, but login must  
have superuser privileges in order to delegate specific privileges to  
the shell process, i.e. in order to authorize the shell process to run  
as the user-id it has been assigned to run as given the authentication  
the user has given.  Not making either one of those programs setuid  
would be ideal though, and thus in that situation getty must run as  
root (i.e. be delegated superuser privileges by init) in order to then  
delegate authorization privileges to login.  However since login is  
setuid it has its own superuser privileges.

Perhaps in a Multics or other ring-style security model the login  
process would not have to true and full superuser privileges, but this  
is unix and we have only the unix security model to work with at the  
moment.

As I and many others have said at least BSD Auth allows for the  
separation of authentication and authorization into different process  
contexts.  With BSD Auth the login process need not be responsible for  
authentication and thus need not be given full access to all  
authentication information for every user at once.  However in the  
unix security model, at least as far as I have ever been able to  
figure out, there's not much choice but to give the equivalent of  
superuser privileges to bot the authentication process and the  
authorization process.

Perhaps with further and full development of a more fine-grained  
security model for NetBSD, perhaps using kauth or something like it,  
then this kind of issue can be revisited.  However I suspect that in  
that eventuality BSD Auth, or something very much like it in design  
and goals, will not just be helpful but will in fact be necessary to  
truly implement a robust and secure system that makes use of a finer- 
grained security model.

--
                                        Greg A. Woods; Planix, Inc.
                                        <woods%planix.ca@localhost>