Stephen Smalley wrote: > On Tue, 2008-07-29 at 15:51 +0900, KaiGai Kohei wrote: >> Stephen Smalley wrote: >>> On Sat, 2008-07-26 at 14:14 -0400, Joshua Brindle wrote: >>>> Stephen Smalley wrote: >>>>> On Sat, 2008-07-26 at 16:55 +0900, KaiGai Kohei wrote: >>>>>> Stephen Smalley wrote: >>>>>>> On Fri, 2008-07-25 at 22:03 +0900, KaiGai Kohei wrote: >>>>>>>> [1/3] thread-context-kernel.1.patch >>>>>>>> This patch enables to assign a thread a "weaker" hierarchical domain, >>>>>>>> only if the destinated domain is a child of the current domain. >>>>>>>> Hierachy relationships are defined in the policy version 24. >>>>>>>> This patch also enables to read the new version of policy. >>>>>>> If you are going to take type hierarchy support into the kernel, then it >>>>>>> seems like it should be completely taken into the kernel, i.e. the >>>>>>> hierarchy checking should be applied by the kernel rather than by the >>>>>>> toolchain. That is what the Flask security server did for its >>>>>>> extensible policy mechanism. >>>>>> When the checks are applied in the kernel? >>>>>> One candidate is policy loading time, and the other is AVC entry creation >>>>>> time. I prefers the later one, because checks in policy loading time will >>>>>> require the expensive checks in kernel space. >>>>>> >>>>>> In my idea, violated permission bits on AVC entries are masked by ones of >>>>>> its parent types, with/without printing logs. >>>>>> Now hierarchy/neverallow constraint makes abort whole of policy loading. >>>>>> It can be a significant difference. >>>>> Yes, it makes sense to apply the hierarchy restrictions at computation >>>>> time. Neverallows are a bit different though - we want those to flag >>>>> bugs in policy. Thus, we likely should leave neverallow checking in the >>>>> userland toolchain. >>>>> >>>> So you want to deny at runtime based on the hierarchy? Won't that >>>> create another confusing way SELinux can deny something without any >>>> clue why (aside from running the denial through audit2why)? Further, >>>> this is something we can understand and reject ahead of time, I don't >>>> know why it makes sense to wait until later when we can tell now that >>>> something is wrong with the policy. >>> True. On the other hand, if we are going to make the hierarchy visible >>> to the kernel so that it can directly leverage information from it, then >>> it makes sense to let the kernel directly enforce the relationships, >>> whether that happens at policy load time or at compute_av time. >>> >>> If we can make the checking happen entirely at policy load time in a >>> manner that isn't too expensive, then that is cleaner, I agree. If not, >>> then lazy dynamic checking by the kernel and optional full static >>> checking by the toolchain may be a compromise. >> I guess we can reduce cost to check hierarchy constraint, because all >> we have to do is to scan/check avtabs of related types and ebitmaps >> of type_attr_maps. >> However, I don't have a good idea to boost neverallow constraint so >> much due to its flexibility. :( >> >> I have measured a performance to check hierarchy/neverallow constraint >> with patched libsepol as a trial. Unfortunatelly, about 80% of CPU time >> is consumed by check_assertions() for neverallows. >> >> [root@saba ~]# time -p semodule -r kaigai >> hierarchy_check_constraints: 37.32 [s] >> check_assertions: 139.05 [s] >> real 205.32 >> user 198.06 >> sys 3.75 >> >> These checks at policy load time gives us negative effect in system >> bootup time, unless remarkable improvements. So, I prefer lazy dynamic >> checking approach. >> >> (*) System bootup time is one of the major topics for embedded Linux folks. > > Ok. I'd be interested in seeing that libsepol patch nonetheless, and we > may want to retain full checking there as an option for validation at > policy build time (via make validate) while introducing lazy dynamic > checking in the kernel. > This sounds reasonable. > BTW, we may need to revisit the policydb data structures in order to > fully address concerns about policy load time. Do you have ideas here? -- 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.
