Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 Jul 2014 14:13:19 -0600 (MDT)
From:      Warren Block <wblock@wonkity.com>
To:        Alexander Leidinger <Alexander@Leidinger.net>
Cc:        freebsd-jail@FreeBSD.org
Subject:   Re: Additional devfs rulesets
Message-ID:  <alpine.BSF.2.11.1407261346110.24514@wonkity.com>
In-Reply-To: <20140726194437.00000ee4@Leidinger.net>
References:  <alpine.BSF.2.11.1407240945210.65901@wonkity.com> <20140726194437.00000ee4@Leidinger.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 26 Jul 2014, Alexander Leidinger wrote:

> On Thu, 24 Jul 2014 10:07:52 -0600 (MDT)
> Warren Block <wblock@wonkity.com> wrote:
>
>> devfsrules_jail is defined in /etc/defaults/devfs.rules, but a new
>> ruleset is needed to unhide bpf devices for using check_dhcp in a
>> jail.
>>
>> It seems clunky to define the new ruleset in /etc/devfs.rules on the
>> host.  Is there a more elegant way to define it with the jail
>> (ezjail) settings in /usr/local/etc?
>>
>> Although it would help with keeping devfs rules with the other jail
>> settings, is the need for running services like dhcpd in a jail
>> enough to justify adding a new ruleset for it
>> to /etc/defaults/devfs.rules?
>>
>> [devfsrules_jail_dhcp=5]
>> add include $devfsrules_jail
>> add path 'bpf*' unhide
>
> A while ago I tried to include a ruleset which includes other rulesets
> in another ruleset. It failed. Seems the include is not "multi-level"
> capable (or I did something very wrong back then). So if this doesn't
> work try to unroll the nested includes.

I wondered about that too, but it did work.  The devfsrules_jail ruleset 
(#4) itself includes earlier-defined sets.  However, the rule could not 
be specified by name in the ezjail config file:

   # did not work
   export jail_jailname_devfs_ruleset="devfsrules_jail"
   # does work
   export jail_jailname_devfs_ruleset="5"

> I'm not aware of another way than /etc/devfs.rules.

If devfs accepted an optional file parameter, additional rulesets could 
be defined with for each jail.  There might be security implications 
with that.

> With bpf available in a jail I would assume you can sniff the entire
> network from the jail, so if you add something in the defaults file you
> should make sure it makes it clear that this "opens" the jail towards
> the network from a security point of view much more than what is
> possible without it.

That's a good point, and another way adding rulesets from other files 
could be useful.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.11.1407261346110.24514>