Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 5 Feb 2006 14:19:43 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        =?ISO-8859-15?Q?Bj=F6rn_K=F6nig?= <bkoenig@cs.tu-berlin.de>
Cc:        current@freebsd.org
Subject:   Re: unprivileged users are able to kill certain jailed processes
Message-ID:  <20060205141626.N76666@fledge.watson.org>
In-Reply-To: <43E60708.9000902@cs.tu-berlin.de>
References:  <43E60708.9000902@cs.tu-berlin.de>

next in thread | previous in thread | raw e-mail | index | archive | help
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-1735510087-1139149183=:76666
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Sun, 5 Feb 2006, [ISO-8859-15] Bj=F6rn K=F6nig wrote:

> unprivileged users of the host environment can see jailed processes with =
the=20
> same user ID. Furthermore they are able to send signals to these processe=
s.=20
> I think since users are not allowed to imprison processes there is no rea=
son=20
> why they should see them or even kill them.
>
> Someone pointed me to this issue and I want to know what you think about=
=20
> this.

I recognize the concern, but the current behavior is consistent with the=20
overall behavior of jail.  In attempt to enforce stronger isolation between=
=20
the host and the jail, you will run into other, more significant problems.=
=20
For example, jail relies on chroot to segment the file system name space.=
=20
Since the host environment is typically rooted at the "real" root, and gues=
t=20
environments are typically chrooted to specific subtrees, containment is=20
enforced (subject to due care).  However, file system access control isn't=
=20
aware of jails, so a uid in the host environment still "owns" files that=20
appear in the chrooted name spaces.  I.e., uid 1000 can edit=20
/home/rwatson/foo, but also /jail1/home/rwatson/foo if the uid matches.=20
Changing this will be quite difficult, probably to the point of being=20
undesirable.

So I guess the question is: if we can't close the file system method of=20
processes in the host influencing processes in the jail, does it make sense=
=20
to, say, control the delivery of signals?

Robert N M Watson

>
> These are some steps to reproduce:
>
>  root@host # jail -Uuserxy / localhost 127.0.0.1 /bin/sleep 12345&
>
>  root@host # ps a | grep sleep=20
>
>   2255  p2  IJ     0:00,01 /bin/sleep 12345
>
>  login as 'userxy'
>
>  userxy@host $ ps a | grep sleep
>   2255  p2  IJ     0:00,01 /bin/sleep 12345
>
>  userxy@host $ ps a | grep sleep
>   [nothing]
>
> This is a suggestion to eliminate this behaviour. I appreciate further=20
> testing because I hadn't much time to do it.
>
> =3D=3D=3D patch starts here =3D=3D=3D
> --- src/sys/kern/kern_jail.c.orig    Wed Sep 28 02:30:56 2005
> +++ src/sys/kern/kern_jail.c Sun Feb  5 14:42:00 2006
> @@ -405,6 +405,9 @@
> =09=09=09return (ESRCH);
> =09=09if (cred2->cr_prison !=3D cred1->cr_prison)
> =09=09=09return (ESRCH);
> +=09} else {
> +=09=09if (jailed(cred2) && suser_cred(cred1, 0))
> +=09=09=09return (ESRCH);
> =09}
>
> =09return (0);
> =3D=3D=3D patch ends here =3D=3D=3D
>
>
> Regards
> Bj=F6rn
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org=
"
>
--0-1735510087-1139149183=:76666--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060205141626.N76666>