Re: [PATCH 1/3] Thread/Child-Domain Assignment

[KaiGai Kohei <kaigai@ak.jp.nec.com>]

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.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.