From owner-freebsd-security Wed Jun 24 15:37:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA18129 for freebsd-security-outgoing; Wed, 24 Jun 1998 15:37:55 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA18074 for ; Wed, 24 Jun 1998 15:37:32 -0700 (PDT) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.8) id PAA19784; Wed, 24 Jun 1998 15:37:28 -0700 (PDT) (envelope-from sef) Date: Wed, 24 Jun 1998 15:37:28 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199806242237.PAA19784@kithrup.com> To: security@FreeBSD.ORG Reply-To: security@FreeBSD.ORG Subject: Re: bsd securelevel patch question In-Reply-To: References: David Greenman "Re: bsd securelevel patch question" (Jun 24, 11:47am) Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: >> 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. >Of course, this implies that all permissions can be represented in >the filesystem. I can imagine a /dev/socket/inet/xyz mechanism which >allows a process to bind to a specific port or /dev/raw which allows >them to create a raw socket etc etc. I think David was talking about using traditional ACL's on files. He wasn't terribly clear, however; he also could have meant something like /dev/io (which, when you open it, allows you to execute in/out instructions). I have asked him what kind of priv's he's talking about in general; there are some rather obvious ones (PRIV_CHUID, PRIV_IO, etc.), but I suspect he has more in mind. I think going to capabilities is a good idea, but it is definitely far more complex, and is likely to be considerably buggier. And will probably break things, at least at first. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message