Quoting Alexander Leidinger <[EMAIL PROTECTED]> (from Mon, 10 Mar 2008 12:28:29 +0100):

I've read in some web based discussions some stuff about this. I would like to clarify some things here in the official place.

You also need to setup /etc/devfs.rules (this is a copy of my one, it
contains more than is needed to run the X server, so you can trim this
if you want):
---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

Those are needed if you want to use audio in the jail. Normally they are not visible in a jail. If they are visible in a jail, you can use them (no usage restrictions). My desktop should be able to play some audio, so I add them for my desktop.

[devfsrules_unhide_printers=6]
add path 'lpt*' unhide
add path 'ulpt*' unhide
add path 'unlpt*' unhide

I also want access to my printer, the same comments as for the audio stuff.

[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

And again: the same as above.

[devfsrules_unhide_xorg=8]
add path agpgart unhide

Needed by X.

#add path console unhide
add path dri unhide
add path 'dri*' unhide

dri is needed too, but I haven't really tested it.

add path io unhide

io can be unhide in a jail, but in the kernel there's an access restriction for it and you can not access it if you are jailed. My patch adds a systctl which allows the admin to give access to either all jails (if io is made visible in the jail with devfs), or only by one jail.

add path mem unhide

mem is not visible by default. If you make it visible, a jail can access it. There are no additional access restrictions in the kernel like for io. I don't know why there's is one for io but not for mem. It's not symmetric, and I would expect either a check for both or not check at all. My patch is not supposed to make it symmetric, nor do I want to remove the priv check for io.

Yes, if you give access to this your system will be "insecure", so don't expect any big benefits. The reason I do this is:
 - it raises the bar (an attacker not only has to get root
   access in my desktop to make everything he wants, he also
   has to know how to use mem/io to get access to the entire
   machine, so the security is somewhere between a desktop
   on the bare metal, and a real jail without access to mem/io)
 - virtualisation of my desktop (I can move it to a different
   machine if I want)
 - because I can do it

#add path pci unhide
add path tty unhide
add path ttyv0 unhide
add path ttyv1 unhide
add path ttyv8 unhide

My X server is running on ttyv8 (explicitly configured in the X config). During my testing I also had to give access to other ttys, but I don't remember if it was before or after the hardcoding of the tty in the config.

[devfsrules_unhide_cam=9]
add path 'da*' unhide
add path 'cd*' unhide

I play around with access to the CD and some USB mass storage from my desktop.

[devfsrules_unhide_kmem=10]
add path kmem unhide

Needed by the X server.

#
# 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.

To all those which think this patch will open up access to the system (to someone who has root access in the jail and knows how to get out of /dev/mem, /dev/kmem and /dev/io what he wants): you are right, as explicitly told here and in the man page, so don't complain please (if you use this, you should know what you are doing).

Bye,
Alexander.

--
FORTUNE'S FUN FACTS TO KNOW AND TELL: #8

        Idaho state law makes it illegal for a man to give his sweetheart
a box of candy weighing less than fifty pounds.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to