Date: Thu, 14 Jun 2001 09:51:52 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: David Malone <dwmalone@maths.tcd.ie> Cc: freebsd-audit@freebsd.org, des@freebsd.org Subject: Re: Allowing ident in a jail. Message-ID: <Pine.NEB.3.96L.1010614094351.25293A-100000@fledge.watson.org> In-Reply-To: <200106141435.aa12577@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
David, Thanks for picking up on that PR -- I've actually known about the issue for a while, but have not had the opportunity to address it since the infrastructure was only in place recently. More comments below... On Thu, 14 Jun 2001, David Malone wrote: > PR 28107 raises the issue that identd doesn't work inside a jail. > This is because the getcred sysctl used to impliment the ident > lookup doesn't allow a jailed root. This is probably reasonably > sendible, as you don't want to leak info about other jails. > > However, I think it's possible to modify the getcred sysctls to > use u_cansee to determine if the credentials associated with a > socket and be viewed by the getcred caller. > > The way things work at the moment is that at the time a socket is > created with the socket(2) call the credentials of the creating > process are attached to that socket. Thus, if you call u_cansee on > the cerdentials of the socket and the credentials of the process > doing the getcred you should get the following semantics: This was actually part of the goal of moving the prison structure into the credential from the process: it would allow us to make access control decisions based on cached credentials. This is not possible in -STABLE because in -STABLE it's still p_prison as opposed to cr_prison. > 1) A unjailed getcred caller can get the creds for any socket. > 2) A jailed getcred caller can only get the creds for a socket > if that socket was created by a process in the same jail. > > This seems pretty safe and doesn't really leak any info from jail > to jail. This is as right as we can do for now, and is an acceptable solution (and the one I had in mind when I originally heard about this problem). It's actually not quite right, because really access control to a socket should be made on the socket as an object, not as a subject. I have a source tree with extensive local changes to introduce a notion of an "object label" that gets tagged into kernel objects, such as IP sockets, and is used for this type of access control. However, that won't be ready to commit for at least another month and a half. Your fix seems to be the best we can do for now, and given the jail model, is in practice identical in semantics. > I've included a patch below which compiles, but which I haven't had a > chance to test fully yet. I'd like to know what people think of this > patch. I'm not sure if Robert would consider this an abuse of u_cansee. I won't get a chance to test the patch for at least a couple of days due to travel; however, I do not consider this an abuse :-). After appropriate testing (in particular, verifying that information flow from other jails and from non-jails is limited), I'm comfortable with this change being committed. In the future, we'll change it to use object labeling, but this is the right answer for today. My only concern is that it will be very difficult to MFC due to its reliance on the jail code changing, and probably lots of intersection with the pcred/ucred collapse. As such, it may not be possible to MFC easily (and probably not at all: I'm not comfortable with MFC'ing the ucred/pcred collapse yet, because my regression tests aren't finished for all cases). Your patch looks good, please commit whenever you feel comfortable with it. Thanks, 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.1010614094351.25293A-100000>