From owner-freebsd-security Fri Jun 19 20:38:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA01871 for freebsd-security-outgoing; Fri, 19 Jun 1998 20:38:09 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from joshua.enteract.com (joshua.enteract.com [207.229.129.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA01865 for ; Fri, 19 Jun 1998 20:38:07 -0700 (PDT) (envelope-from tqbf@pobox.com) From: tqbf@pobox.com Received: (qmail 4256 invoked by uid 1004); 20 Jun 1998 03:38:09 -0000 Message-ID: <19980620033809.4255.qmail@joshua.enteract.com> Subject: Re: bsd securelevel patch question In-Reply-To: <9806192307.ZM29126@beatrice.rutgers.edu> from Allen Smith at "Jun 19, 98 11:07:42 pm" To: easmith@beatrice.rutgers.edu (Allen Smith) Date: Fri, 19 Jun 1998 22:38:09 -0500 (CDT) Cc: dg@root.com, njs3@doc.ic.ac.uk, dima@best.net, security@FreeBSD.ORG, abc@ralph.ml.org, tqbf@secnet.com Reply-To: tqbf@pobox.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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