Persistent special roles
Posted: Sun Apr 05, 2009 3:27 amAs I understand, there's no way to make special roles' restrictions to reapply automagically after gradm -R, and it makes role ex-subjects silently escape any restrictions of special role. This is not an issue when one can write a role for user or group or even domain, which usually is quite possible, but not always.
The problem arises when you want to arrange kinda jail container (like FreeBSD jail) based on Grsecurity chroot restrictions. UIDs and GIDs does not make a difference, because each jail can contain processes with any and the same UIDs and GIDs, that must be restricted according to different roles. And to have one generic special role is not enough because different jails require different ip_override rules (an so on).
You can define several special roles with different ip_override rules and start the jails within that roles. This is kinda solution. But what is important is when you should add another role for another jail on a running production system, you should gradm -R to transmit that new role to the kernel. And that's the problem: after gradm -R all jails are losing their ip_override restrictions - you must stop/gradm -R/restart jails, that is not convenient and sometimes is not even an option.
What could be a better solution?
1. Persistent special roles. They could be persistent (and marked as such by a new role flag) in one of the following ways:
- They could not be unapplied nor changed after policy reload.
- They could be refreshed if the same role name exist in reloaded policy.
- They could be refreshed if the same role name exist in reloaded policy, but stay persistent without changes if there's no such name (mistakes happen).
2. The roles of a new type (like domain, but different), based on cgroup subsystem found in 2.6.24+ kernels.
In such case, the role name is the name of the cgroup of the grsec cgroup controller. Then RBAC could make a difference based on the name of cgroup, where the subject process (and its parent) belogns to. Sure, the grsec cgroup controller must not allow the same pid to be added to several grsec-cgroups. As far as cgroups are persistent, the cgroup-based roles can be reapplied after policy reload just like in case of domain, user and group roles. (It seems overcomplicated. Is it?)
3. I should "stop whining" and "shut up and code". (c)
There are working solution - not so convenient but it does exist. I should stop/gradm -R/restart jails and write special jail roles proactively. Or I should write another hacky solutions for "kinda jails" myself.
So... Could it be 1 or 2? Or is it the obvious 3?
I just have another idea... Is it possible to implement policy merging? Then one can merge new special roles to the policy in the kernel.
The problem arises when you want to arrange kinda jail container (like FreeBSD jail) based on Grsecurity chroot restrictions. UIDs and GIDs does not make a difference, because each jail can contain processes with any and the same UIDs and GIDs, that must be restricted according to different roles. And to have one generic special role is not enough because different jails require different ip_override rules (an so on).
You can define several special roles with different ip_override rules and start the jails within that roles. This is kinda solution. But what is important is when you should add another role for another jail on a running production system, you should gradm -R to transmit that new role to the kernel. And that's the problem: after gradm -R all jails are losing their ip_override restrictions - you must stop/gradm -R/restart jails, that is not convenient and sometimes is not even an option.
What could be a better solution?
1. Persistent special roles. They could be persistent (and marked as such by a new role flag) in one of the following ways:
- They could not be unapplied nor changed after policy reload.
- They could be refreshed if the same role name exist in reloaded policy.
- They could be refreshed if the same role name exist in reloaded policy, but stay persistent without changes if there's no such name (mistakes happen).
2. The roles of a new type (like domain, but different), based on cgroup subsystem found in 2.6.24+ kernels.
In such case, the role name is the name of the cgroup of the grsec cgroup controller. Then RBAC could make a difference based on the name of cgroup, where the subject process (and its parent) belogns to. Sure, the grsec cgroup controller must not allow the same pid to be added to several grsec-cgroups. As far as cgroups are persistent, the cgroup-based roles can be reapplied after policy reload just like in case of domain, user and group roles. (It seems overcomplicated. Is it?)
3. I should "stop whining" and "shut up and code". (c)
There are working solution - not so convenient but it does exist. I should stop/gradm -R/restart jails and write special jail roles proactively. Or I should write another hacky solutions for "kinda jails" myself.
So... Could it be 1 or 2? Or is it the obvious 3?
I just have another idea... Is it possible to implement policy merging? Then one can merge new special roles to the policy in the kernel.