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. -- 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.
