Date: Thu, 14 Jun 2001 10:30:41 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Dag-Erling Smorgrav <des@ofug.org> Cc: David Malone <dwmalone@maths.tcd.ie>, freebsd-audit@freebsd.org Subject: Re: Allowing ident in a jail. Message-ID: <Pine.NEB.3.96L.1010614102606.26099A-100000@fledge.watson.org> In-Reply-To: <xzphexjdukl.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14 Jun 2001, Dag-Erling Smorgrav wrote: > David Malone <dwmalone@maths.tcd.ie> writes: > > This seems pretty safe and doesn't really leak any info from jail > > to jail. > > - actually, this solution *does* have the potential of leaking > information about non-jailed processes into the jail, *but* > > - to get into a scenario where a socket belonging to a non-jailed > process is visible from within the jail, you have to jump through > hoops and willingly do things that more or less cancel out the > benefits of using a jail in the first place. > > So while David's patch isn't really a 100% correct fix for the problem > described in the PR, it's a good enough compromise, and a much better > solution than any I expected to find. > > (David already knows this; this is for the benefit of those who haven't > read the private discussion he and I had on this subject) Well, it does leak information, but only if jails leak sockets. That is to say, the socket credential is determined at socket creation time, and if the socket migrates elsewhere over its lifetime (via fd transfer by virtue of unix domain socket ancillary data), then it will leak information. However, this relies on having at least two parties colluding: an entity in the first jail to create the socket, and an entity in the host environment willing to help transfer the socket (by creating some IPC vehicle for it, etc). The jail model is not intended to protect jails from the host environment, just from other jails, and only when namespaces have been appropriately configured. If you want the full gamut of protection, you need a full confidentiality/integrity MAC policy. I've largely implemented this (at least twice) as part of the TrustedBSD work, but it's nowhere near ready for production use, and I'll probably reimplement it at least once more before I'll be satisfied with it. Jail is intended to be lightweight and easy to use, providing decent protection, which it does. There are a number of architectural vulnerabilities to it, not least of which is that there are a number of ways a trusting host environment could be exploited by a malicious jail. 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-audit" 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.1010614102606.26099A-100000>