Joshua Brindle wrote:
KaiGai Kohei wrote:
The series of patches enables to assign a thread an
indivisual "more bounded" domain, even if the process is
multithreaded.
We can apply this feature to set up a server application
which handles user's request withing more restricted domain,
to protect potential harms come from application bugs.
It also adds a new binary policy format (version 24).
This version allows each definitions of user/role/type to
have its bounds. The bounds restrict capabilities of bounded
one with similar rules compared to existing name based
hierarchy support.
The following rules are enhanced from existing hierarchy stuff.
- A bounded type cannot have any attribute which does not assigned
to the upper type.
I don't think this is necessary. The original hierarchy implementation
only cared about the net effect of the rules, not how they were granted.
For example, if I have 2 attributes, one that is given more privilege
and one that is given a subset of the first why should I have to assign
both to the 'parent' type? I don't agree with this constraint.
The major purpose of attribute bounds was a restriction for CONSTRAIN
or MLSCONSTRAINT rules. However, I reconsidered it can be implemented
by sanity checks at policy load time, without any attribute bounds.
I agree what you pointed out.
In the next patch, I'll remove the code to check attribute bounds.
- CONSTRAIN/MLSCONSTRAIN rules are enhanced to pay attention the
boundary relationships.
I adds a new statement of TYPEBOUNDS as follows:
TYPEBOUNDS <parent type> <child type 1> [, <child type 2> ...] ;
It defines boundary relationships between two types, and
these are loaded to the kernelspace via policy version 24.
(*) The existing hierarchy is implicitly expanded to bounds.
I don't provide a statement to define boundary relationships
between roles/users, although existing hierarchy supports
them, because its purpose/worth is unclear now.
Its purpose was the same as the original purpose for the hierarchy. The
hierarchy was developed for policy access control using the policy
management server. One would 'label' policy objects using the hierarchy
and could constrain the permissions (or roles or types) using the
hierarchical constraints. I request that you not remove this support in
your version.
Sorry, my explanation might be misleadable. :(
The new facilities can have a data structure to represent boundary
relationships between two types/roles/users. However, I didn't add
a new syntax in policy language statement, like USERBOUNDS/ROLEBOUNDS.
If the checkmodule founds existing name based hierarhies, implicit
boundary relationships are assigned to them, and these are shipped
into kernelspace later.
For example, a definition of "staff_u.kaigai" does not define a SElinux
user only, but a boundary relationship between "staff_u" and
"staff_u.kaigai" is also defined automatically.
I consider this behavior can follows existing name based hierarchies.
Additionally, if you are enforcing hierarchy on types in constrain
statements you should also do this for roles and users, for consistency.
The latest kernel patch enables to check (MLS)CONSTRAINT statement for
users, roles and types. Please show constraint_bounds_sanity_check()
which is invoked at policy load time.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@xxxxxxxxxxxxx>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
