jails Allow jailed system to access USB device

[kpetri]

Good evening!
I am having trouble understanding what to add to my /etc/devfs.rules in order to allow a jail to access USB devices. It is about a Raspberry Pi 3B+ running FreeBSD 13.0p4 RELEASE, I would like to set up a jail that runs comms/dump1090, which takes input data from a SDR-RTL USB stick.
On the host system, it works flawlessly as intended.
I added the following custom rule to /etc/devfs.rules:

# Local jail config
[devfsrules_allow_usb=8]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add include $devfsrules_jail
add path 'usbctl' unhide
add path 'usb/*' unhide
add path 'usb/*' mode 0666

And edited /etc/jail.conf accordingly:

ads-b	{
	jid = "2";
	allow.mount;
	mount.devfs;
	enforce_statfs	= 0;
	devfs_ruleset	= "8";

	ip4		=  inherit;
}

Even tough I can see the USB device from within the jail, I cannot make use of it:

root@ads-b:/ # ls /dev/usb
1.1.0	1.1.1	1.2.0	1.2.1	1.3.0	1.3.1	1.4.0	1.4.1	1.4.2	1.4.3	1.5.0	1.5.1
root@ads-b:/ # dump1090 
No supported RTLSDR devices found.
root@ads-b:/ # usbconfig 
No device match or lack of permissions.

I guess it's the 1.5, as giving usbconfig from the host outputs:

ugen1.5: <Realtek RTL2838UHIDIR> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)

So I am wondering what is my /etc/devfs.rules file missing, as if I add a new permissive rule such as:

# Insecure permissive rule, for test only
[devfsrules_allow_all=9]
add path '*' unhide

And apply the new rule to the jail, I can run the program normally as I would do from the host. What is missing in my ruleset? How can I find out what I need to "unhide" in the future if I am to attempt something similar with another device?
Thanks

 

[kFuQ]

I am doing the same thing and I was getting my ass kicked too.

I finally figured it out.

/etc/defaults/devfs.rules

# Devices usually found in a jail.
[devfsrules_jail=4]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add path fuse unhide
add path usb* mode 0666 unhide
add path 'usb/*' mode 0666 unhide
add path 'usbctl' mode 660 unhide
add path ugen* mode 0666 unhide

sysctl security.jail.mount_fdescfs_allowed=1
sysctl security.jail.mount_procfs_allowed=1
sysctl security.jail.mount_devfs_allowed=1
sysctl security.jail.param.allow.mount.devfs=1
sysctl security.jail.param.allow.mount.tmpfs=1
sysctl security.jail.param.allow.mount.fdescfs=1
sysctl security.jail.param.allow.mount.procfs=1

root@websdr:~ # usbconfig 
ugen0.1: <0x1106 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
ugen0.2: <vendor 0x2109 USB2.0 Hub> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA)
ugen0.3: <Realtek RTL2838UHIDIR> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)

RPI4 - 4GB

FreeBSD 13.0-RELEASE-p6 #0: Mon Jan 10 06:33:27 UTC 2022     [email]root@arm64-builder.daemonology.net[/email]:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64

 

[SirDice]

sysctl security.jail.mount_fdescfs_allowed=1
sysctl security.jail.mount_procfs_allowed=1
sysctl security.jail.mount_devfs_allowed=1
sysctl security.jail.param.allow.mount.devfs=1
sysctl security.jail.param.allow.mount.tmpfs=1
sysctl security.jail.param.allow.mount.fdescfs=1
sysctl security.jail.param.allow.mount.procfs=1

These are all deprecated in favor of a per jail configuration, see jail(8).

dice@molly:~ % sysctl -d security.jail.mount_fdescfs_allowed
security.jail.mount_fdescfs_allowed: Jail may mount the fdescfs file system (deprecated)

Note the (deprecated)

 

[kFuQ]

These are all deprecated in favor of a per jail configuration, see jail(8).

dice@molly:~ % sysctl -d security.jail.mount_fdescfs_allowed
security.jail.mount_fdescfs_allowed: Jail may mount the fdescfs file system (deprecated)

Note the (deprecated)

That's from the ezjail toolset.. It's been spitting that message out for years now.

 

[SirDice]

That's from the ezjail toolset..

No, those are because of the jail_* variables it uses, those are deprecated too. But that has nothing to do with the deprecation of these sysctls. In all seriousness, it's time to move away from EZJail. It hasn't been updated in years and has started to show some cracks in its foundation.

 

[kFuQ]

true..