Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Sep 2017 14:32:50 +0200
From:      Giulio Ferro <auryn@zirakzigil.org>
To:        Alexander Leidinger <Alexander@leidinger.net>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: devd in jail
Message-ID:  <415A2FDD-F02E-44BF-862F-FA928EACB454@zirakzigil.org>
In-Reply-To: <20170810225439.Horde.1s8Qi_dlNtxgEigsNKbdrer@webmail.leidinger.net>
References:  <e03a6040-1322-c82c-0e96-49c474188d5c@zirakzigil.org> <CAOtMX2g7PR9S7v%2BrUXwBeQUPDFfJy2zZwAvg7q5ze99jDF4hmA@mail.gmail.com> <20170810225439.Horde.1s8Qi_dlNtxgEigsNKbdrer@webmail.leidinger.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Alexander,

This set of patches doesn't seem to apply to 11.1 stable, am I right?


> Il giorno 10 ago 2017, alle ore 22:54, Alexander Leidinger <Alexander@leid=
inger.net> ha scritto:
>=20
>=20
> Quoting Alan Somers <asomers@freebsd.org> (from Wed, 9 Aug 2017 13:14:20 -=
0600):
>=20
>>> On Wed, Aug 9, 2017 at 12:47 PM, Giulio Ferro <auryn@zirakzigil.org> wro=
te:
>>> Hello all,
>>>=20
>>> Setup :  11.1-STABLE FreeBSD 11.1-STABLE #0 r321925M amd64
>>>=20
>>>=20
>>> I'm trying to create a fully virtualized desktop enviroment in a jail by=

>>> means of installing there
>>> a xrdp-devel server + Xorg installation (xorg + xorgrdp).
>>>=20
>>> Everything seems to work until the moment when the X server actually tri=
es
>>> to come up (after I choose session=3Dxorg, username + password)
>>> In the X logs in the jail, in fact, I have this error:
>>>=20
>>> ...
>>> [  9768.824] (EE) config/devd: fail to connect to devd
>>> [  9768.824] [config] failed to initialise devd
>>>=20
>>>=20
>>> I've checked on the host machine, and I don't have that error as everyth=
ing
>>> works fine there...
>>>=20
>>> In my jail, I've setup the devfs like this (/etc/jail.conf in the host):=

>>>=20
>>> ---
>>> exec.start=3D"/bin/sh /etc/rc";
>>> exec.stop=3D"/bin/sh /etc/rc.shutdown";
>>> exec.clean;
>>> mount.devfs;
>>> devfs_ruleset=3D1;
>>>=20
>>> path=3D"/usr/home/jail/$name";
>>>=20
>>> myjail {
>>>        host.hostname=3D"myjail.me.com";
>>>        vnet;
>>>        vnet.interface =3D epair0b, epair1b;
>>>        persist;
>>> }
>>> ---
>>>=20
>>>=20
>>> and in the /etc/devfs.conf everythink is commented out.
>>>=20
>>> In the /dev directory in the jail, I get both the devctl and devctl2
>>> devices.
>>>=20
>>> As the devd demon is not running in the jail, I've tried adding
>>> devd_enable=3D"YES"
>>>=20
>>> in the rc.conf (jail), but when I try to start it, I get:
>>>=20
>>> # /etc/rc.d/devd start
>>> Starting devd.
>>> devd: Can't open devctl device /dev/devctl: Device busy
>>> /etc/rc.d/devd: WARNING: failed to start devd
>>>=20
>>>=20
>>> Do you know if I'm doing something wrong, or there's a proper way to hav=
e
>>> devd running in the jail?
>>>=20
>>> I've thought that maybe I should use the devtcl2 device, as the devctl i=
s
>>> used by the host,
>>> but I don't know how to specify that to devd...
>>>=20
>>> Thanks in advance for your help.
>>>=20
>>> Giulio
>>=20
>> Unfortunately, you're not going to be able to run devd(8) in the jail.
>> /dev/devctl can be opened by only one reader at a time, and that
>> reader is always devd(8).  /dev/devctl2 is actually a completely
>> different device with a totally different interface.  Apologies for
>> the confusing names.  But you may not need to run a totally separate
>> instance of devd.  The X server is probably trying to open either
>> /var/run/devd.pipe or /var/run/devd.seqpacket.pipe.  ktrace would tell
>> you which.  If you can bridge those sockets into the jail, then X
>> would probably run.
>=20
> Apart from using an explicit config of devices instead of HAL / devd, if t=
his is a X server connecting to a graphics card (instead of just a remote ac=
cessible framebuffer), the X-in-a-jail patches are needed, as the X server n=
eeds access to /dev/(k)mem and /dev/io (and /dev/drm).
>=20
> ATTENTION: doing this compromises the complete security of the entire mach=
ine. The jail with the X-server can then access the entire memory of the mac=
hine, this means circumventing any kernel-level security protection / jail r=
estrictions.
>=20
> Using the PR_ALLOW_* flags from current in 11.1 is ok (sys/sys/jail.h):
> ---snip---
> /* Flags for pr_allow */
> #define PR_ALLOW_SET_HOSTNAME           0x00000001
> #define PR_ALLOW_SYSVIPC                0x00000002
> #define PR_ALLOW_RAW_SOCKETS            0x00000004
> #define PR_ALLOW_CHFLAGS                0x00000008
> #define PR_ALLOW_MOUNT                  0x00000010
> #define PR_ALLOW_QUOTAS                 0x00000020
> #define PR_ALLOW_SOCKET_AF              0x00000040
> #define PR_ALLOW_MOUNT_DEVFS            0x00000080
> #define PR_ALLOW_MOUNT_NULLFS           0x00000100
> #define PR_ALLOW_MOUNT_ZFS              0x00000200
> #define PR_ALLOW_MOUNT_PROCFS           0x00000400
> #define PR_ALLOW_MOUNT_TMPFS            0x00000800
> #define PR_ALLOW_MOUNT_FDESCFS          0x00001000
> #define PR_ALLOW_MOUNT_LINPROCFS        0x00002000
> #define PR_ALLOW_MOUNT_LINSYSFS         0x00004000
> #define PR_ALLOW_RESERVED_PORTS         0x00008000
> #define PR_ALLOW_KMEM_ACCESS            0x00010000      /* reserved, not u=
sed yet */
> #define PR_ALLOW_ALL                    0x0001ffff
> ---snip---
>=20
> Then kern_jail.c needs a little patch:
> ---snip---
> Index: sys/kern/kern_jail.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- sys/kern/kern_jail.c    (revision 321365)
> +++ sys/kern/kern_jail.c    (working copy)
> @@ -200,6 +200,7 @@
>        "allow.mount.linprocfs",
>        "allow.mount.linsysfs",
>        "allow.reserved_ports",
> +       "allow.kmem_access",
> };
> const size_t pr_allow_names_size =3D sizeof(pr_allow_names);
>=20
> @@ -220,6 +221,7 @@
>        "allow.mount.nolinprocfs",
>        "allow.mount.nolinsysfs",
>        "allow.noreserved_ports",
> +       "allow.nokmem_access",
> };
> const size_t pr_allow_nonames_size =3D sizeof(pr_allow_nonames);
>=20
> @@ -3344,6 +3346,27 @@
>                return (0);
>=20
>                /*
> +                * Allow access to /dev/io in a jail if the non-jailed adm=
in
> +                * requests this and if /dev/io exists in the jail. This
> +                * allows Xorg to probe a card.
> +                */
> +       case PRIV_IO:
> +               if (cred->cr_prison->pr_allow & PR_ALLOW_KMEM_ACCESS)
> +                       return (0);
> +               else
> +                       return (EPERM);
> +
> +               /*
> +                * Allow low level access to KMEM-like devices (e.g. to
> +                * allow Xorg to use DRI).
> +                */
> +       case PRIV_KMEM_WRITE:
> +               if (cred->cr_prison->pr_allow & PR_ALLOW_KMEM_ACCESS)
> +                       return (0);
> +               else
> +                       return (EPERM);
> +
> +               /*
>                 * Allow jailed root to set loginclass.
>                 */
>        case PRIV_PROC_SETLOGINCLASS:
> ---snip---
>=20
> For 11.1 one little change is needed to get DRM access... see https://svnw=
eb.freebsd.org/changeset/base/320827
>=20
> The jail then needs to be started with "allow.kmem_access" and appropriate=
 devfs rules (the jail needs rule 15 or 18, you may want to give more or les=
s access, depending on your needs, review with care):
> ---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
>=20
> [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
>=20
> [devfsrules_unhide_xorg=3D8]
> add path agpgart unhide
> #add path console unhide
> add path dri unhide
> add path 'dri/card*' unhide
> add path nvidiactl unhide
> add path 'nvidia*' 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
>=20
> [devfsrules_unhide_kmem=3D11]
> add path kmem unhide
>=20
> [devfsrules_unhide_zfs=3D12]
> add path zfs unhide
>=20
> #
> # This allows to run a desktop system in a jail.  Think about what you wan=
t to
> # achieve before you use this, it opens up the entire machine to access fr=
om
> # this jail to any sophisticated program.
> #
> [devfsrules_jail_desktop=3D15]
> 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_kmem
>=20
> [devfsrules_jail_desktop_withzfs=3D18]
> 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_kmem
> add include $devfsrules_unhide_zfs
> ---snip---
>=20
> Bye,
> Alexander.
>=20
> --=20
> http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?415A2FDD-F02E-44BF-862F-FA928EACB454>