Skip site navigation (1)Skip section navigation (2)
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>