Date: Wed, 24 Jun 1998 11:47:52 -0700 From: David Greenman <dg@root.com> To: tqbf@pobox.com Cc: easmith@beatrice.rutgers.edu (Allen Smith), njs3@doc.ic.ac.uk, dima@best.net, security@FreeBSD.ORG, abc@ralph.ml.org, tqbf@secnet.com Subject: Re: bsd securelevel patch question Message-ID: <199806241847.LAA01163@implode.root.com> In-Reply-To: Your message of "Fri, 19 Jun 1998 22:38:09 CDT." <19980620033809.4255.qmail@joshua.enteract.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> Why are you wanting to do it via login.conf, instead of via multiple >> groups? I'm asking because I'm looking at doing this for ICMP sockets > >I don't see how you'd use login.conf to handle restricted system >capabilities (such as network access); these are privileges extended to >users by the kernel, not by other processes on the system who can use a >login.conf API to access information in that file. login/login.conf would be extended so that it did a 'setpriv()' as part of the login procedure. The privilege set would be associated with the process and its children. I'm not happy with login.conf for this either, but the only alternative would be to either extend the exiting passwd files to hold privilege info, or create an entirely new file to contain it. >This solution has very real security benefits, but I find administrating >them from login.conf to be clumsy. In terms of transitioning away from >binary "superuser" privilege, I think normal Unix filesystem security >semantics (owner, group, and SET[UG]ID) are expressive enough. I don't think this scales very well. Assigning specific gids as privileges is also rather messy inside the kernel and makes probably wrong assumptions about a machine's external /etc/group layout. One could mitigate this a bit by exporting the assignment of these via individual sysctl() variables. I also think the issue of handling setuid/setgid binaries is independant of a fine grained privilege mechanism. Even in your scheme, if I understand it completely, you'd only be able to have one capability enabled via setgid, so you'd be out of luck if you needed two since you can't specify a list of groups. I agree that setuid root has always been an inadequate sledgehammer for granting access to privileged resources and capabilities. I think the best way to handle this, however, is with a file ACL mechanism that allows for the specification of privileges as and extension of the access control information. On the other hand, in VMS, special privileges can be granted to a binary only if it is "installed" first - i.e. made known to the system as a special executable, usually at system startup time. This has the advantage of specifying all binaries that have elevated privilege(s) in one place and keeping privileged binaries open (making media changes difficult or impossible), but has the disadvantage of violating POLA. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806241847.LAA01163>