Effective rule sets in a jail?

[Martin "eto" Misuth]

On Thu, 7 Jul 2016 11:17:41 +0000
Grzegorz Junka <list1 at gjunka.com> wrote:
> 
> Descendant jails inherit the parent jail's devfs ruleset. Devfs rules 
> enforced in the jail are defined by the single calculated ruleset.
> 
> What do you think?
> 

IMHO, regarding jails, better mental model would be like this:
 - any single jail can have one and only one devfs ruleset number assigned
   - however, different standalone jails can have different devfs ruleset
     number assigned
 - nested jails inherit ruleset number from their parent jail

Regarding rulesets "inheritance"/"merging" you are probably looking into the
wrong place. devfs ruleset system is completely orthogonal to jails, as it
is used for other things as well.

You can "merge" devfs rulesets in devfs /etc/devfs.rules. 

Look into /etc/defaults/devfs.rules how initial rulesets are built.

First everything is hidden by ruleset 1 aka "devfsrules_hide_all". This is "by
default deny" policy, which should, according to me, used whenever one can.

Then, new rulesets are created by unhiding various groups of devices. 
Like for example you have minimal sub-ruleset 2 aka "devfsrules_unhide_basic".
That one is required to get minimal working /dev. Otherwise most programs break.

Finally ruleset 4 aka "devfsrules_jail" is built, which can be used by jails.

I personally "classify" jail types into groups. Let's call such group a jail
"class" (for the purpose of classification).

Thus to get what you want, you should create custom ruleset per jail "class" and
assign it to your jails based on their "class".

[devfsrules_jail_class_no_zfs=16]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login

Class might be not good word for this, as it is quite "loaded" by now, but I am
using it that way.

Some jails might end up so special, they require completely fine tuned ruleset. 
Those cannot be completely "classified" at all like this for example:

[devfsrules_jail_proxy=333]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add include $devfsrules_unhide_jail_proxy_tuns 

"devfsrules_unhide_jail_proxy_tuns" sub-rule in this case unhides
several tun interfaces used solely by this jail only.

devfs.conf files are "parsed" by /etc/rc.d/devfs rc script which is run quite
early after boot. If you look at it you will see it is using /etc/rc.subr 
devfs_* subroutines of rc.d framework which invoke /sbin/devfs helper program.

Theoretically if /etc/rc.d/devfs and /etc/rc.subr are not enough for
you, you could write helper script to invoke /sbin/devfs to setup most
convoluted rule ids directly by hand.

  eto