Citrix client within jail

Alexander Leidinger Alexander at Leidinger.net
Thu Jan 24 02:10:18 PST 2008


Quoting André Olsson <andre.olsson at c2solutions.se> (from Thu, 24 Jan  
2008 09:43:44 +0100):

> Hi
>
>
>
> Could you please give an example of your modifications in your custom kernel
> to be able to run a X-server in a jail, furthermore your custom ruleset for
> 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 = 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.  This
---snip---

The above only applies to 7.0 and 8. In 6.x this is not centralized  
like above.

My /etc/devfs.rules:
---snip---
[devfsrules_unhide_audio=5]
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=6]
add path 'lpt*' unhide
add path 'ulpt*' unhide
add path 'unlpt*' unhide

[devfsrules_unhide_input=7]
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=8]
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=9]
add path 'da*' unhide
add path 'cd*' unhide

[devfsrules_unhide_kmem=10]
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=11]
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  
Xserver from accessing the whole system is highly welcome!

> Thanks for your suggestion on starting X-server on the host, our problem is
> that due to security restrictions we can’t have a X-server on the host that
> each jail connects to. The X-servers need to be isolated inside respectively
> jail.

Funny... you will have less security by one Xserver in each jail  
instead of one Xserver on the host, as 2 Xservers on one machine will  
open up a sidechannel (a big one) from one jail to the other via the  
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  
connect to the machine with the jails. This only makes sense if you  
have more than 2 jails in total...

Bye,
Alexander.

-- 
Bingo, gas station, hamburger with a side order of airplane noise,
and you'll be Gary, Indiana.
		-- Jessie, "Greaser's Palace"

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137


More information about the freebsd-jail mailing list