Date: Wed, 10 Oct 2001 22:33:54 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Mikhail Teterin <mi@corbulon.video-collage.com> Cc: Matt Dillon <dillon@earth.backplane.com>, Dag-Erling Smorgrav <des@ofug.org>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_proc.c kern_prot.c uipc_socket.c uipc_usrreq.c src/sys/netinet raw_ip.c tcp_subr.c udp_usrreq.c Message-ID: <Pine.NEB.3.96L.1011010222607.3545A-100000@fledge.watson.org> In-Reply-To: <200110102353.f9ANrDp39720@corbulon.video-collage.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 10 Oct 2001, Mikhail Teterin wrote: > > I would argue that there are several levels of visibility here > > that could be governed by sysctl's. For example, if we take > > 'fstat' and 'ps' I would say that a user in the wheel group should > > have full access to both, while a user outside of wheel perhaps > > should only have access to 'ps'. That's just an example. > > When I hear about different access right to different information I > think about file systems. Perhaps, this information should be made > available through something like /proc (or something else based on > pseudofs -- /sysctl anyone -- it already hierarchical). Then the admins > could tune the permissions to their hearts' content. It sounds like what is being asked for is a mandatory access control policy -- one defined by the system administrator, as opposed to a discretionary one ("permissions"). NAI Labs has funding to work on this type of thing (more details to come on this front), so it may be the best thing to do is make sure this gets included on the set of requirements being taken into account for that work. One thing that I think is worth avoiding is adding a lot of inflexible and yet complex security policies to the system in a very ad hoc way: the results are often inconsistent, non-portable, and confusing. The "other users" alternative policy is quite simple, and fairly least-common-denominator, and the primitives to support it were already in place (by virtue of cleanly abstracting p_cansee and cr_cansee). BTW, speaking of additional file systems, Boris Popov has actually written a sysctlfs already, that you might be interested in. He also had a devfs variant at one point. I also played with a synthetic file system that represented TCP and UDP ports, and ACL operations on the ports determined the rights to connect/bind/... those ports. Unfortunately, my experience suggested that wasn't a very scalable way to do the work, and the file system paradigm represented multi-dimmensional policies very poorly (the namespace didn't reflect wildcard-esque policies). It was an interesting experiment, but probably not the right answer in the general case. If we do want to start representing the protection policies for kernel objects via a mechanism like this, it might be appropriate the add a new sysctl type for ACLs. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1011010222607.3545A-100000>