Date: Thu, 25 Jun 1998 21:35:11 +1000 (EST) From: Darren Reed <avalon@coombs.anu.edu.au> To: njs3@doc.ic.ac.uk (Niall Smart) Cc: dg@root.com, tqbf@pobox.com, easmith@beatrice.rutgers.edu, 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: <199806251136.EAA19553@hub.freebsd.org> In-Reply-To: <E0yow23-00039B-00@oak67.doc.ic.ac.uk> from "Niall Smart" at Jun 24, 98 09:20:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Niall Smart, sie said: > > > for granting access to privileged resources and capabilities. 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. On the other hand, in VMS, special privileges can be granted to > > 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. This gets somewhat messy for the > above example since it is difficult to administer things like ranges > (eg ports 0 to 1024) using a single device file for each element in that > range, and any other approach (e.g. /dev/socket/inet/0-1024) seems to > lose the cleanliness offered by the "single file for everything" approach. sockets can easily be done with portals, for which it is easy to do the above (been there, done that for a small trial). 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?199806251136.EAA19553>