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>