Date: Fri, 3 Jul 1998 08:12:54 -0400 From: "Allen Smith" <easmith@beatrice.rutgers.edu> To: dg@root.com Cc: rotel@indigo.ie, security@FreeBSD.ORG, njs3@doc.ic.ac.uk, dima@best.net, abc@ralph.ml.org, tqbf@secnet.com Subject: Re: bsd securelevel patch question Message-ID: <9807030812.ZM10157@beatrice.rutgers.edu> In-Reply-To: David Greenman <dg@root.com> "Re: bsd securelevel patch question" (Jul 3, 3:28am) References: <199807031028.DAA06648@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 3, 3:28am, David Greenman (possibly) wrote: > Okay, so you are saying that the PRIV_* port privileges would be > honored only for the first privileged port number that is > bind()'ed [sic]? Hmmm...sounds interesting. I like that a lot > better than assigning 1024 gids to TCP, another 1024 gids to UDP, > etc. Actually, I'd just had in mind this as a means of speeding up (via caching) the port allowability determination (yes, I've listened to what you've commented regarding the speed of scanning the potentially large group set), but the further notion that you bring up has some definite possibilities. From my look-over of kern_fork.c, the ucred structure (which is where I'd have in mind placing this) is essentially copied from parent to child, so that'll insure that a child process can't choose a new port to bind to. The addition of syscalls to check and set the ports in question would be an additional security measure for doing stuff via login.conf, as you had suggested earlier (i.e., while either login.conf or (as I'd prefer) groups could be used for setting the basic privileges, login.conf could be used for setting which port a given PRIV_TCP or PRIV_UDP uid-derived process could bind to). While this combination isn't as secure for setuid binaries as the gid-to-port mapping I'd mentioned earlier, it does have the advantage that you point out of not occupying large slices of the gid space. OTOH, I certainly am not a security expert, so there could be something I'm missing. Hmm... I just looked over (further) the libutil source code, and it doesn't look that difficult to add this functionality into (namely into functions called by setusercontext). How would LOGIN_SETPRIV be as the applicable flag? I'm thinking that this would be definitely appropriate for having available to a class (via setclasscontext), since it'd be overridable by individual user entries anyway. Incidentally, how much differences are there between -stable and -current on stuff concerned with this? The main system I have to work with is running -stable, and that's not likely to change, for reliability reasons. I may be able to get a spare computer running -current, but that really can't take priority - it's not what I'm paid for, whereas getting the firewall computer (which is -stable) running (indirectly) is. I do have around a copy of /usr/src/sys -current that's updated whenever the main system is, which I can use for at least making sure the patches go in properly and that the kernel will compile. -Allen -- Allen Smith easmith@beatrice.rutgers.edu 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?9807030812.ZM10157>