Date: Wed, 24 Jun 1998 15:37:28 -0700 (PDT) From: Sean Eric Fagan <sef@kithrup.com> To: security@FreeBSD.ORG Subject: Re: bsd securelevel patch question Message-ID: <199806242237.PAA19784@kithrup.com> In-Reply-To: <E0yow23-00039B-00.kithrup.freebsd.security@oak67.doc.ic.ac.uk> References: David Greenman <dg@root.com> "Re: bsd securelevel patch question" (Jun 24, 11:47am)
next in thread | previous in thread | raw e-mail | index | archive | help
In article <E0yow23-00039B-00.kithrup.freebsd.security@oak67.doc.ic.ac.uk> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806242237.PAA19784>