Jail Security - /dev/adaX disks are readable/writeable from inside a jail

[Kam]

I'm not sure if this is bug or works as designed, so before logging a bug asking here.

When you create new jail, as a jail "root" you have full access to physical disks /dev/adaX, on which are all zfs pools build.
That means, that from inside a jail you can read ALL raw data on ZFS disks.
And moreover, you will probably be able to rewrite all data on that disks, destroying whole system.

Steps to reproduce:

1. create new empty jail using gui:
Jails -> Add Jail -> Jail Name: test -> OK

2. login to jail:
[root@freenas] ~# jexec test csh

3. try read /dev/adaX disks:
root@test:/ # strings /dev/ada0|head
This is a NAS data disk and can not boot system. System halted.
EFI PART
- q+
- q+_mx
AWdO-
...
-> physical disks are readable from a jail.

I haven't tried to rewrite disks, as obviously I do not want to destroy my system, but jail root has write access too:
root@test:/ # ls -la /dev/ada0
crw-r----- 1 root operator 0x80 Mar 22 13:12 /dev/ada0

I'm running latest 9.3 version:

[root@freenas] ~# uname -a
FreeBSD freenas.local 9.3-RELEASE-p31 FreeBSD 9.3-RELEASE-p31 #0 r288272+33bb475: Wed Feb 3 02:19:35 PST 2016 root@build3.ixsystems.com:/tank/home/stable-builds/FN/objs/os-base/amd64/tank/home/stable-builds/FN/FreeBSD/src/sys/FREENAS.amd64 amd64

I'm not sure if this is bug or works as designed, but I tkink jails were created to protect rest of the system. If somebody gets jail root access by using some security hole in product installed in jail, then can destroy not only jail, but whole data on freenas system. It is also impossible to delegate jail root to others (after enabling sshd in jail), as access from jail is not well protected.

Thanks.

 

[Kam]

It reproduces also on fresh 9.10 install
[root@freenas] ~# uname -a
FreeBSD freenas.local 10.3-RELEASE FreeBSD 10.3-RELEASE #0 52dd777(freebsd10): Fri Mar 25 14:48:36 PDT 2016 root@build.ixsystems.com:/tank/home/nightlies/build-freenas9/_BE/objs/tank/home/nightlies/build-freenas9/_BE/trueos/sys/FreeNAS.amd64 amd64

 

[Kam]

problem is probably not only from custom jail, but also from plugins, which uses jails.
it seems that it was previously investigated in old freenas version under:
https://bugs.pcbsd.org/issues/5058
and published in security advisory
https://www.freebsd.org/security/advisories/FreeBSD-SA-14:07.devfs.asc

but it looks like this bug is back here in 9.3 and on fresh installed 9.10 version.
devfs -m ${devfs_mountpoint} rule -s 4 applyset
as suggested in old bug is not executed for jails.

i think this should be treated seriously, as from jail or plugins can be easily destroyed whole system.

 

[Ericloewe]

I recommend you open a bug ticket so this can be looked at.

 

[theirman]

Found out the same thing more than half a year ago: https://forums.freenas.org/index.php?threads/lock-down-devfs-in-a-jail-devfsrules.36974/
No solution

 

[Kam]

I found some workaround.
For EACH jail you wish to hide devfs devices, add devfs call to their jail-post-start command.
Here is an example for jail naimed "websrv":

cat /mnt/zpool/jails/.websrv.meta/jail-post-start
#!/bin/sh

. /etc/rc.freenas

jail_post_start "${JAILNAME}"

devfs -m /mnt/zpool/jails/websrv/dev rule -s 4 applyset

This works after freenas boot and also after each restart of the jail.
But I'm not sure if it is safe to put lines on jail-post-start script, freenas usually rewrites files when are changed settings from gui.

And it should be automatic for all new jails, because if you forget it for each new jail or are not aware of this security issue, you are at big risc.
I was looking for a way how to log a bug for this issue, but don't have account on bug system.

 

[Kam]

It seems that there is version of warden which can set devfs rulesets per jail with devfs-ruleset:

https://github.com/pcbsd/pcbsd/blob/master/src-sh/warden/bin/warden

Lets you set options for your jail
Available options:
...
devfs-ruleset: Set the devfs ruleset for this jail
...

warden in freenas does not have this option.
Can be warder updated to enable this and included possibility to set it in freenas?

 

[danb35]

I was looking for a way how to log a bug for this issue, but don't have account on bug system.

Is something preventing you from registering for an account?

 

[JavaScriptDude]

@Kam, I came across similar workaround for another problem where I had to add a tweak in the jails /mnt/<zpool>/jails/<jail_id>.meta/jail-post-start. My change has stuck for months in Production with no issues. As I could not find any documentation on these hook scripts, I dug into the warden code and it looks like these hook scripts are created when the jail is created and are not overwritten.

It appears that the changes to these hooks are written once on create and will even survive and export and import.

See FreeNAS warden createjail.sh source on GitHub.

Hopefully, this is just a case of documentation in need of improvement. I'm going to dig further to see if I can get to the bottom of these hooks as I'm not super comfortable hacking undocumented scripts.

 

[Kam]

From virtualbox with snapshot turned on I tried to rewrite disk with dd, but at leas that gets operation not permitted error. From jail, but also from host OS root.
Anyway, even read access is huge security issue, so I logged it under new bug:

https://bugs.freenas.org/issues/14432