Re: Effective rule sets in a jail?

2016-07-07 Thread Grzegorz Junka 


On 07/07/2016 13:31, Martin "eto" Misuth wrote:

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
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"


That's great! Thanks for the comprehensive explanation, I wish it was in 
the man already so I wouldn't need to enquiry additionally here. It 
makes sense, as I mentioned in my previous email, I got confused and 
messed jail inheritance with the inheritance of devfs rule sets, they 
are orthogonal as you stated. I amended my rules to include the basic 
ones from rule 4 to the more specific one for one particular jail and it 
works. Thanks again!

Grzegorz

___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"

Re: Effective rule sets in a jail?

2016-07-07 Thread Martin "eto" Misuth 
On Thu, 7 Jul 2016 11:17:41 +
Grzegorz Junka  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
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"

Re: Effective rule sets in a jail?

2016-07-07 Thread Grzegorz Junka 


On 07/07/2016 10:06, Miroslav Lachman wrote:

Grzegorz Junka wrote on 07/07/2016 11:42:


OK, I am just an user, not very familiar with the terminology. For me
(as a programmer) inheriting means overriding, so merging the more
specific to the less specific declarations.

Does it mean that the "inheriting" works in nested declarations but
doesn't take into account the default value? In other words, the default
is just default unless it re-defined in a jail declaration. If that's
the case then wouldn't be more clear to name the "outside" default
declaration as default, e.g. "default_devfs_ruleset"? Then it would be
more difficult to confuse the default with the one that can be 
inherited.


I think it is simple in current form. (And I am not sys developer, I 
was web application programmer before I became sysadmin)
I started with jails long time before jail2 with jail.conf. Current 
jail.conf is s simpler in comparision with rc.conf style variables.


Naming each default variable with different name will be harder to 
code, harder to write in jail.conf, harder to document in manpages.


Almost all programming languages works the same in this context - 
later variable definition wins.


So you can easily define all variables needed to run jails and then 
set just those specific to one jail - IPs and hostname:


## Typical static defaults:
## Use the rc scripts to start and stop jails.  Mount jail's /dev.
exec.start = "/bin/sh /etc/rc";
exec.stop  = "/bin/sh /etc/rc.shutdown";
exec.clean;
exec.system_user   = "root";
exec.jail_user = "root";
mount.devfs;
devfs_ruleset  = 4;
enforce_statfs = 1;
#allow.set_hostname = false;
#allow.mount;
allow.set_hostname = 0;
allow.sysvipc  = 0;
allow.raw_sockets  = 0;

## Dynamic wildcard parameter:
path= "/vol1/jail/$name";
exec.consolelog = "/var/log/jail/$name.console";
mount.fstab = "/etc/fstab.$name";

## Jail myjail0
myjail0 {
host.hostname = "myjail0.example.conf";
ip4.addr  = 10.20.30.40;
}

## Jail myjail1
myjail1 {
host.hostname = "myjail1.example.conf";
ip4.addr  = 10.20.30.41;
}


devfs_ruleset is the same as the other variables - you can't (and I 
hope nobody expect) to merge global default value of e.g. 
exec.system_user or allow.sysvipc with variables defined in specific 
jail context. Those variables can have only one value (bool, or 
string, or number; not an array). It is the same for devfs_rules. 
Can't have more than one numeric value, can't combine two together.


I think you will be familiar with this very soon.

Miroslav Lachman


OK, so my confusion steams from the fact that the devfs rules are 
defined somewhere else and the jail.conf is simply taking into account 
the rule number, not its content. In that context it indeed makes sense.


It could be simply a matter of adding a clarification that each jail can 
have only one devfs ruleset assigned to it (which then would be 
calculated according to the standard rules defined in jail.conf), for 
example:


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?

Grzegorz
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"

Re: Effective rule sets in a jail?

2016-07-07 Thread Miroslav Lachman 

Grzegorz Junka wrote on 07/07/2016 11:42:


OK, I am just an user, not very familiar with the terminology. For me
(as a programmer) inheriting means overriding, so merging the more
specific to the less specific declarations.

Does it mean that the "inheriting" works in nested declarations but
doesn't take into account the default value? In other words, the default
is just default unless it re-defined in a jail declaration. If that's
the case then wouldn't be more clear to name the "outside" default
declaration as default, e.g. "default_devfs_ruleset"? Then it would be
more difficult to confuse the default with the one that can be inherited.


I think it is simple in current form. (And I am not sys developer, I was 
web application programmer before I became sysadmin)
I started with jails long time before jail2 with jail.conf. Current 
jail.conf is s simpler in comparision with rc.conf style variables.


Naming each default variable with different name will be harder to code, 
harder to write in jail.conf, harder to document in manpages.


Almost all programming languages works the same in this context - later 
variable definition wins.


So you can easily define all variables needed to run jails and then set 
just those specific to one jail - IPs and hostname:


## Typical static defaults:
## Use the rc scripts to start and stop jails.  Mount jail's /dev.
exec.start = "/bin/sh /etc/rc";
exec.stop  = "/bin/sh /etc/rc.shutdown";
exec.clean;
exec.system_user   = "root";
exec.jail_user = "root";
mount.devfs;
devfs_ruleset  = 4;
enforce_statfs = 1;
#allow.set_hostname = false;
#allow.mount;
allow.set_hostname = 0;
allow.sysvipc  = 0;
allow.raw_sockets  = 0;

## Dynamic wildcard parameter:
path= "/vol1/jail/$name";
exec.consolelog = "/var/log/jail/$name.console";
mount.fstab = "/etc/fstab.$name";

## Jail myjail0
myjail0 {
host.hostname = "myjail0.example.conf";
ip4.addr  = 10.20.30.40;
}

## Jail myjail1
myjail1 {
host.hostname = "myjail1.example.conf";
ip4.addr  = 10.20.30.41;
}


devfs_ruleset is the same as the other variables - you can't (and I hope 
nobody expect) to merge global default value of e.g. exec.system_user or 
allow.sysvipc with variables defined in specific jail context. Those 
variables can have only one value (bool, or string, or number; not an 
array). It is the same for devfs_rules. Can't have more than one numeric 
value, can't combine two together.


I think you will be familiar with this very soon.

Miroslav Lachman
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"

Re: Effective rule sets in a jail?

2016-07-07 Thread Grzegorz Junka 


On 07/07/2016 09:03, Miroslav Lachman wrote:

Grzegorz Junka wrote on 07/07/2016 10:41:



I was referring to this clause in the man document:

Descendant jails inherit the parent jail's devfs ruleset enforcement.


This is true for hierarchical "nested" jails = jail inside jail.
And inheriting doesn't mean merging.
You can't allow devices in descendant jail which are not allowed on 
parent.



I thought that the outside rule is combined with the inside rule in the
jail definition. But thanks for the hint about jls -s, it does shows the
(single) active rule set (however without referring to the specific
rules defined in devfs.rules or a combination of it).


You are mixing nested jails context with jail.conf context where 
"outside" definitions are the defaults for all jails which are not 
overriding those values with own values.


Miroslav Lachman


OK, I am just an user, not very familiar with the terminology. For me 
(as a programmer) inheriting means overriding, so merging the more 
specific to the less specific declarations.


Does it mean that the "inheriting" works in nested declarations but 
doesn't take into account the default value? In other words, the default 
is just default unless it re-defined in a jail declaration. If that's 
the case then wouldn't be more clear to name the "outside" default 
declaration as default, e.g. "default_devfs_ruleset"? Then it would be 
more difficult to confuse the default with the one that can be inherited.


Grzegorz
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"

Re: Effective rule sets in a jail?

2016-07-07 Thread Miroslav Lachman 

Grzegorz Junka wrote on 07/07/2016 10:41:



I was referring to this clause in the man document:

Descendant jails inherit the parent jail's devfs ruleset enforcement.


This is true for hierarchical "nested" jails = jail inside jail.
And inheriting doesn't mean merging.
You can't allow devices in descendant jail which are not allowed on parent.


I thought that the outside rule is combined with the inside rule in the
jail definition. But thanks for the hint about jls -s, it does shows the
(single) active rule set (however without referring to the specific
rules defined in devfs.rules or a combination of it).


You are mixing nested jails context with jail.conf context where 
"outside" definitions are the defaults for all jails which are not 
overriding those values with own values.


Miroslav Lachman
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"

Re: Effective rule sets in a jail?

2016-07-07 Thread Grzegorz Junka 


On 07/07/2016 07:53, Miroslav Lachman wrote:

Ultima wrote on 07/07/2016 06:04:
Not so. The top variable, devfs_ruleset = 4 is being set as the 
default for

all jails. The devfs_ruleset = 5 inside the brackets is changing the
default value.

How to check what ruleset is mounted? That is a great question. I'm not
sure of an easy way to check other than verifying the /dev directory 
inside

the jail.


There is no way to set more than one devfs rule to jail AFAIK.
You can see the rule number in output of jls -s or jls -n.

Miroslav Lachman



I was referring to this clause in the man document:

Descendant jails inherit the parent jail's devfs ruleset enforcement.

I thought that the outside rule is combined with the inside rule in the 
jail definition. But thanks for the hint about jls -s, it does shows the 
(single) active rule set (however without referring to the specific 
rules defined in devfs.rules or a combination of it).


Grzegorz
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"

Re: Effective rule sets in a jail?

2016-07-07 Thread Miroslav Lachman 

Ultima wrote on 07/07/2016 06:04:

Not so. The top variable, devfs_ruleset = 4 is being set as the default for
all jails. The devfs_ruleset = 5 inside the brackets is changing the
default value.

How to check what ruleset is mounted? That is a great question. I'm not
sure of an easy way to check other than verifying the /dev directory inside
the jail.


There is no way to set more than one devfs rule to jail AFAIK.
You can see the rule number in output of jls -s or jls -n.

Miroslav Lachman

___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"