Date: Thu, 21 Oct 1999 18:40:24 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Dag-Erling Smorgrav <des@flood.ping.uio.no>, hackers@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: Finer-grained securelevel: proof of concept Message-ID: <Pine.BSF.3.96.991021183303.50165A-100000@fledge.watson.org> In-Reply-To: <6076.940543265@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 22 Oct 1999, Poul-Henning Kamp wrote: > In message <Pine.BSF.3.96.991021083426.46884A-100000@fledge.watson.org>, Robert > Watson writes: > >On 21 Oct 1999, Dag-Erling Smorgrav wrote: > > > >> Patches are available from http://www.freebsd.org/~des/. This is > >> strictly proof-of-concept; the patches demonstrate that fine-grained > >> security knobs can be implemented with minimal code impact. No > >> documentation is provided, RTFS. > > > >Very clean, pretty, etc -- only one object: > > I have been talking to a lot of people over here, and one common > thing seems to be that they want to be able to set these things > differently on a "per jail" basis. > > I actually think we should not get into the jail thing, but rather > make them inheritable like other credentials, so the structure > containing the stuff should hang of the proc structure, and hey > wait, we already have this "struct ucred" hanging there. At one point I submitted patches for a p->p_authext void pointer for kernel modules that want to maintain their own security contexts -- unfortunately, it never went in, and now that I've given it some though, perhaps a registration system makes more sense -- i.e., modules register a unique magic number and can access it via a hash/etc when they need it. One can imagine, actually, a chain of authorizers being queried for security-sensitive operations, each of which stores some of its own credentials... This might fit into my kernel tokens architecture, but that might also be a bit heavy-weight (it does have the inheritence properties you mention, however). The other approach for jails is the virtual machine approach--don't treat it so much as security, as much as accessible resources accessed as though by fd's -- interfaces or virtual interfaces are mapped to logical interfaces within virtual machines -- it's not so much as they are not permitted to access the resource, as much as they are unable to access it. One could imagine during the jail creation procedure-- j = jail_new(); jail_add_if(j, "ed0.inet.128.2.35.50", "eth0"); jail_add_if(j, "xl0", "eth1"); jail_enter(j); Etc. Doesn't fit well into the current jail model, which might fit the authorization token approach -- a token or capability represented as a token authorizing binding. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.991021183303.50165A-100000>