From owner-freebsd-security Sun Dec 9 13:24: 3 2001 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 B7AA937B416; Sun, 9 Dec 2001 13:24:00 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fB9LNji91881; Sun, 9 Dec 2001 16:23:45 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 9 Dec 2001 16:23:45 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Brian F. Feldman" Cc: "Crist J . Clark" , alexus , freebsd-security@FreeBSD.ORG Subject: Re: identd inside of jail In-Reply-To: <200112091827.fB9IRAl13742@green.bikeshed.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 9 Dec 2001, Brian F. Feldman wrote: > Robert Watson 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