Date: Fri, 19 Jun 1998 22:38:09 -0500 (CDT) From: tqbf@pobox.com To: easmith@beatrice.rutgers.edu (Allen Smith) Cc: dg@root.com, 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: <19980620033809.4255.qmail@joshua.enteract.com> In-Reply-To: <9806192307.ZM29126@beatrice.rutgers.edu> from Allen Smith at "Jun 19, 98 11:07:42 pm"
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. One idea is to allow GID "icmp" access to ICMP raw socket functionality, and then have only one process on the system run with these credentials (the "icmpd"). Users could make requests of the icmpd via local IPC, and the daemon could validate these requests against login.conf. 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. Since I have entire systems built up and deployed with hacks like these, I am very interested in hearing how other people are approaching this issue. More importantly, I am very interested in talking to people about moving forward with some sort of coherent model for providing enhanced system- level security. Thanks for writing. ----------------------------------------------------------------------------- Thomas H. Ptacek The Company Formerly Known As Secure Networks, Inc. ----------------------------------------------------------------------------- http://www.pobox.com/~tqbf "If you're so special, why aren't you dead?" 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?19980620033809.4255.qmail>