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. > - 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. Additionally, if you are enforcing hierarchy on types in constrain statements you should also do this for roles and users, for consistency. -- 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.
