On Wed, 2008-07-30 at 10:10 -0400, Joshua Brindle wrote: > 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? I think it is mostly due to long hash chains, which costs us both in populating the new policydb during load and in tearing down the old one (measurable latency which led to cond_resched calls in the policydb_destroy code path) and of course on compute_av when walking the chains. So we either need to reduce policy size or store it more compactly or both. For example, being able to store a single avtab entry for all file classes when they have identical permissions in common might be helpful. -- Stephen Smalley National Security Agency -- 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.
