Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 9 Dec 2001 16:23:45 -0500 (EST)
From:      Robert Watson <rwatson@FreeBSD.ORG>
To:        "Brian F. Feldman" <green@FreeBSD.ORG>
Cc:        "Crist J . Clark" <cjc@FreeBSD.ORG>, alexus <ml@db.nexgen.com>, freebsd-security@FreeBSD.ORG
Subject:   Re: identd inside of jail 
Message-ID:  <Pine.NEB.3.96L.1011209161942.85510C-100000@fledge.watson.org>
In-Reply-To: <200112091827.fB9IRAl13742@green.bikeshed.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sun, 9 Dec 2001, Brian F. Feldman wrote:

> Robert Watson <rwatson@FreeBSD.ORG> wrote:
> > 
> > This problem is fixed in 5.0-CURRENT as it performs two checks in udp and
> > tcp getcred: first, it checks for privilege (and permits the jail to
> > succeed), and second, it checks whether the connection in question is
> > visible to the current jail.  I do not currently plan to merge these
> > changes to -STABLE, as they rely on changes merging the pcred and ucred
> > structures, which in turn depend on a lot of other changes throughout the
> > kernel in 5.0-CURRENT.  As a follow-up note, the credential management
> > code in 5.0-CURRENT is substantially rewritten, and the result is much
> > better enforcement of process and resource visibility, both from the
> > perspective of jail, and from limiting users from seeing resources created
> > by other users (such as TCP connections) when dictated by policy.
> 
> For 4.X, how about a sysctl kern.security.bsd.jail_getcred_enabled or a
> jail.getcred_allowed?  That would make at least some people happy, I
> think. 

I'm a little wary of adding features that we know we'll obsolete as soon
as 5.0 comes out :-).  However, if you called it:

  jail.almostdeprecated.global_getcred_allowed

or something, I might survive.  Part of the issue here is that we know
this isn't the right fix, it's just that the right fix is fairly involved,
and something that the details of are still in flux in the -CURRENT branch
(general handling of credentials and subject/object visibility has changed
a lot, and will change more before we're done).  Right now the fix in
-CURRENT relies on the cached subject credential in the socket: this is
actually wrong, it should probably instead rely on an object label.  In a
sense, I'd really prefer that we simply wait until 5.0 to ship with a
system that has this behavior correct in jail: 5.0 has much more mature
kernel security characteristics.

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 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.NEB.3.96L.1011209161942.85510C-100000>