Skip site navigation (1)Skip section navigation (2)
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>