From owner-freebsd-security Thu Oct 21 15:40:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 442C714FF2; Thu, 21 Oct 1999 15:40:33 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id SAA50217; Thu, 21 Oct 1999 18:40:24 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 21 Oct 1999 18:40:24 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Poul-Henning Kamp Cc: Dag-Erling Smorgrav , hackers@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: Finer-grained securelevel: proof of concept In-Reply-To: <6076.940543265@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 22 Oct 1999, Poul-Henning Kamp wrote: > In message , 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