Page MenuHomeFreeBSD

jail(3): fix common usage after mac.label support
ClosedPublic

Authored by kevans on Mon, Jan 19, 8:19 PM.
Tags
None
Referenced Files
F142485065: D54786.id170083.diff
Tue, Jan 20, 8:26 AM
F142483649: D54786.id170072.diff
Tue, Jan 20, 8:07 AM
F142468841: D54786.id.diff
Tue, Jan 20, 5:57 AM
F142444570: D54786.id170083.diff
Tue, Jan 20, 12:51 AM
F142444264: D54786.diff
Tue, Jan 20, 12:44 AM
F142443374: D54786.id.diff
Tue, Jan 20, 12:29 AM
F142433810: D54786.diff
Mon, Jan 19, 10:28 PM
F142423178: D54786.diff
Mon, Jan 19, 8:29 PM
Subscribers

Details

Summary

Nobody else's mac.conf(5) has any entries for jails, so they get a
trivial ENOENT and we fail before we can fetch any jail parameters.

Add an entry that works for everyone, and hardcode that as an ENOENT
fallback in libjail to provide a smoother transition. This is probably
not harmful to leave in long-term, since mac.conf(5) will override it.

This unearthed one additional issue, in that mac_get_prison() in the
MAC framework handled the no-label-policies bit wrong. We don't want
to break jail utilities enumerating jail parameters automatically, so
we must ingest the label in all cases -- we can still use it as a small
optimization to avoid trying to copy out any label. We will break
things if a non-optional element is specified in the copied in label,
but that's expected.

Fixes: db3b39f063d9f05 ("libjail: extend struct handlers [...]")
Fixes: bd55cbb50c58876 ("kern: add a mac.label jail parameter")

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 69999
Build 66882: arc lint + arc unit

Event Timeline

jlduran requested changes to this revision.EditedMon, Jan 19, 9:42 PM

I think this is not sufficient (just to avoid a missing mac.conf entry):
I will test it thoroughly later, but for now:

# jail -c path=/ name=D54786 persist
# jls -s
lib/libc/posix1e/mac.conf
15

The manual page lib/libc/posix1e/mac.conf.5 will need a similar update.

This revision now requires changes to proceed.Mon, Jan 19, 9:42 PM

I think this is not sufficient (just to avoid a missing mac.conf entry):
I will test it thoroughly later, but for now:

# jail -c path=/ name=D54786 persist
# jls -s

I realized that I accidentally still had my MAC policy loaded, but here there's an even bigger 'yikes':

root@multicons:~ # jail -c path=/ name=D54786 persist
root@multicons:~ # jls -s
panic: vtopde on a uva/gpa 0x23103382a000
cpuid = 3
time = 1768859160
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0068816af0
vpanic() at vpanic+0x136/frame 0xfffffe0068816c20
panic() at panic+0x43/frame 0xfffffe0068816c80
pmap_kextract() at pmap_kextract+0x1c5/frame 0xfffffe0068816ca0
free() at free+0x5d/frame 0xfffffe0068816ce0
mac_get_prison() at mac_get_prison+0x164/frame 0xfffffe0068816d40
kern_jail_get() at kern_jail_get+0xc8b/frame 0xfffffe0068816dd0
sys_jail_get() at sys_jail_get+0x3e/frame 0xfffffe0068816e00
amd64_syscall() at amd64_syscall+0x169/frame 0xfffffe0068816f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0068816f30
--- syscall (506, FreeBSD ELF64, jail_get), rip = 0x48f69bf72da, rsp = 0x48f6475f9a8, rbp = 0x48f647601a0 ---
KDB: enter: panic
[ thread pid 1453 tid 100855 ]
Stopped at      kdb_enter+0x33: movq    $0,0x11f4932(%rip)
This revision is now accepted and ready to land.Tue, Jan 20, 1:07 AM

In the interest of not leaving main broken, I'm going to push this since it's functional both with a jail policy and without- noting that I fully expect to perhaps need another round to cleanup some remaining issue(s) pertaining to the expedited timeline.