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. - 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. The policy format version 24 has a field to represent boundary relationship between users/roles, but it is only used to ship existing hierarhies. [1/3] thread-context-kernel.1.patch It allows a multithreaded process to assign an individual "more bounded" security context, and it also enables to handle binary policy format version 24 in kernel space. [2/3] thread-context-checkpolicy.2.patch It enables to support TYPEBOUNDS statement and to expand existing hierarchies implicitly. [3/3] thread-context-libsepol.2.patch It enables to support binary policy format version 24. The series of patches does not contains facilities to support lazy NEVERALLOW support, due to enlarged policy size, as I noted before. 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.
