Date: Thu, 24 Jan 2008 11:06:20 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: =?utf-8?b?QW5kcsOp?= Olsson <andre.olsson@c2solutions.se> Cc: freebsd-jail@freebsd.org Subject: Re: Citrix client within jail Message-ID: <20080124110620.2i25fd93ww0kwogk@webmail.leidinger.net> In-Reply-To: <003701c85e65$3b7832a0$b26897e0$@olsson@c2solutions.se> References: <003701c85e65$3b7832a0$b26897e0$@olsson@c2solutions.se>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Andr=C3=A9 Olsson <andre.olsson@c2solutions.se> (from Thu, 24 Jan =
=20
2008 09:43:44 +0100):
> Hi
>
>
>
> Could you please give an example of your modifications in your custom kern=
el
> to be able to run a X-server in a jail, furthermore your custom ruleset fo=
r
> devfs.
Copy & paste, whitespace may be wrong...:
---snip---
RCS file: /import/FreeBSD-CVS/src/sys/kern/kern_jail.c,v
retrieving revision 1.74
diff -u -p -u -r1.74 kern_jail.c
--- sys/kern/kern_jail.c 13 Jan 2008 14:44:08 -0000 1.74
+++ sys/kern/kern_jail.c 17 Jan 2008 14:50:22 -0000
@@ -78,6 +78,11 @@ SYSCTL_INT(_security_jail, OID_AUTO, mou
&jail_mount_allowed, 0,
"Processes in jail can mount/unmount jail-friendly file systems");
+int jail_dev_io_access_allowed =3D 0;
+SYSCTL_INT(_security_jail, OID_AUTO, dev_io_access_allowed, CTLFLAG_RW,
+ &jail_dev_io_access_allowed, 0,
+ "Process in jail has access permission to /dev/io if available");
+
/* allprison, lastprid, and prisoncount are protected by allprison_lock. *=
/
struct prisonlist allprison;
struct sx allprison_lock;
@@ -736,6 +741,17 @@ prison_priv_check(struct ucred *cred, in
case PRIV_NETINET_GETCRED:
return (0);
+ /*
+ * Allow access to /dev/io in a jail if the non-jailed admin
+ * requests this and if /dev/io exists in the jail. This
+ * allows Xorg to probe a card.
+ */
+ case PRIV_IO:
+ if (jail_dev_io_access_allowed)
+ return (0);
+ else
+ return (EPERM);
+
default:
/*
* In all remaining cases, deny the privilege request. Thi=
s
---snip---
The above only applies to 7.0 and 8. In 6.x this is not centralized =20
like above.
My /etc/devfs.rules:
---snip---
[devfsrules_unhide_audio=3D5]
add path 'audio*' unhide
add path 'dsp*' unhide
add path midistat unhide
add path 'mixer*' unhide
add path 'music*' unhide
add path 'sequencer*' unhide
add path sndstat unhide
add path speaker unhide
[devfsrules_unhide_printers=3D6]
add path 'lpt*' unhide
add path 'ulpt*' unhide
add path 'unlpt*' unhide
[devfsrules_unhide_input=3D7]
add path 'atkbd*' unhide
add path 'kbd*' unhide
add path 'joy*' unhide
add path 'psm*' unhide
add path sysmouse unhide
add path 'ukbd*' unhide
add path 'ums*' unhide
[devfsrules_unhide_xorg=3D8]
add path agpgart unhide
#add path console unhide
add path dri unhide
add path 'dri*' unhide
add path io unhide
add path mem unhide
#add path pci unhide
add path tty unhide
add path ttyv0 unhide
add path ttyv1 unhide
add path ttyv8 unhide
[devfsrules_unhide_cam=3D9]
add path 'da*' unhide
add path 'cd*' unhide
[devfsrules_unhide_kmem=3D10]
add path kmem unhide
#
# This allows to run a desktop system in a jail. Think about what you want =
to
# achieve before you use this, it opens up the entire machine to access from
# this jail to any sophisticated program.
#
[devfsrules_jail_desktop=3D11]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add include $devfsrules_unhide_audio
add include $devfsrules_unhide_input
add include $devfsrules_unhide_xorg
add include $devfsrules_unhide_cam
add include $devfsrules_unhide_kmem
---snip---
> Hopefully we can restrict access to /dev/mem for X with some help from one
> of our partners using virtual framebuffers.
It's not only /dev/mem, it's also /dev/io. Any technique to limit the =20
Xserver from accessing the whole system is highly welcome!
> Thanks for your suggestion on starting X-server on the host, our problem i=
s
> that due to security restrictions we can=C2=92t have a X-server on the hos=
t that
> each jail connects to. The X-servers need to be isolated inside respective=
ly
> jail.
Funny... you will have less security by one Xserver in each jail =20
instead of one Xserver on the host, as 2 Xservers on one machine will =20
open up a sidechannel (a big one) from one jail to the other via the =20
memory.
> We are currently checking out the possibilities to use Xnest inside the
> jail.
Maybe you want to add a second box with only the Xserver, and then =20
connect to the machine with the jails. This only makes sense if you =20
have more than 2 jails in total...
Bye,
Alexander.
--=20
Bingo, gas station, hamburger with a side order of airplane noise,
and you'll be Gary, Indiana.
=09=09-- Jessie, "Greaser's Palace"
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080124110620.2i25fd93ww0kwogk>