tech-security archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: BSD Auth

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.

Home | Main Index | Thread Index | Old Index