>>>> An idea: thread/hierarchical-domain assignment
>>>> ----------------------------------------------
>>>> If possible, Apache should change the security context of web backend
>>>> during it executes a request come from users.
>>>> However, Apache can execute it on a worker thread. It conflicts a wired
>>>> constraint of SELinux which does not allow a multi-threaded process dynamic
>>>> domain transition.
>>>>
>>>> It is a reasonable constraint, if the source and destination domains are
>>>> completely independent. Because it shares a local memory, mixed security
>>>> context within a process can make a violation in domain separation.
>>>>
>>>> However, a characteristic relationship between hierarchical domains can
>>>> help the situation. It restricts a child domain (like "httpd_t.staff")
>>>> cannot over the boundary of its parent ("httpd_t"). It also means
>>>> a multi-threaded process cannot over the (parent) domain boundary,
>>>> even if a part of threads has different security context.
>>>>
>>>> My suggestion is the hard-wired constraint should be modified.
>>>> It allows to assign threads an indivisual domain, if the new domain
>>>> is a child one of the current domain.
>>>>
>>>> For example:
>>>> httpd_t -> httpd_t.staff = allowed
>>>> httpd_t -> staff_t = disallowed
>>>> httpd_t.staff -> httpd_t.staff.php = allowed
>>>>
>>>> In other words, this idea requires to change our viewpoint for child domain.
>>>> Previously, these are mutually independent domain, but a child domain will
>>>> mean a state with restricted operations compared to its parent domain.
>>> I tend to agree that we should support such changes in the kernel
>>> mechanism and let the use of it be determined by the policy.
>>>
>>> In terms of hierarchy though, the plan was to replace the current
>>> name-based hierarchy with an explicitly declared hierarchy.
>> It needs a new policy statement like:
>>
>> TYPE <child domain> DOMBY <parent domain>;
>> or
>> TYPEDOMINANCE <parent domain> <child domain> [,<child domain>] ;
>>
>> I guess these relationships are represented as a ebitmap structure
>> in the kernel, and used to mask permissions during AVC entry creation.
>
> You don't necessarily have to represent the hierarchy in the kernel; it
> can be done entirely in the policy toolchain like the current type
> hierarchy.
I think it is necessary to check whether required dynamic type transition
should be allowed, or not.
This idea allows a thread to translate its domain, only if the destinated
domain is a child one. Thus kernel has to check the relationship between
both domains based on the hierarchy information.
In other expression:
ssid := current domain
tsid := new domain
if (is_multi_threaded(current)) {
+ if (!is_dominated_domain(ssid, tsid)) <-- requires hierarchy info
return -EPERM;
}
avc_has_perm(ssid, tsid, SECCLASS_PROCESS,
PROCESS__DYNTRANSITION, NULL);
>>>> Issues: Domain Reverting
>>>> ------------------------
>>>> There is a related issue. To change security context during user request
>>>> execution also means that we have to revert its domain after executions,
>>>> because Apache repeatedly uses worker thread/process for some reasons.
>>>>
>>>> I don't have any good idea for this issue yet.
>>>> A one time cookie like AppArmor is an approach, but it is basically weak
>>>> separation compared from execve() transition.
>>> Perhaps it could pre-populate different pools of threads for different
>>> client security contexts, and then just draw from the correct pool for
>>> each client. Then the thread context doesn't have to be reverted at all
>>> and we can make the transition unidirectional.
>> I think this approach requires two precondition.
>>
>> (1) The number of client security context should be enough small.
>> If we want to assign one of MCS categories, it requires 1024 of thread
>> pool in maximum.
>
> The main server thread could lazily create the thread pools as needed to
> avoid unnecessary pools. And we could possibly use a hybrid scheme
> (e.g. one pool per sensitivity or per equivalence class of categories,
> reuse within that pool).
I guess it requires massive reworks for Apache itself. :(
If so, it may be better to implement a SELinux specific multi processing
module (MPM) which creates a child process with restricted domain per
request?
(No need to say, we will get some performance degradation.)
>> (2) We have to know what client security context should be assigned
>> before the communication between client and backend thread.
>> In the case when we use HTTP authentication to decide client security
>> context, the authentication process has to be done in the backend
>> process after the communication started.
>> It may also require major works in application updates.
>
> True, but not an issue when using labeled networking as the basis for
> determining the client security context.
In web based services, we have to assume a case when client system
is running on windows with no labeled networking support.
I think it can be also possible to associate a user and a security
context of his substitution on authentication, as operating system
doing.
>> In my impression, AA's approach is not perfect, but second best one...
>
> I'd have to hear an argument that there is a real security benefit from
> it. Do you just mean reverting domain transitions or do you
> specifically mean the cookie-based approach?
The cookie-based approach means a process/thread dynamically translated
into child domain is allowed to revert its domain into original one, only
if the submitted cookie is matched.
It can protect from script flaws as long as the cookie cannot be accessed
from script program. But it depends on the correctness of script language
processor, because the cookie has to be placed within the translated domain.
If PHP language processor itself has a bug to expose a discretional value,
a malicious one can revert its domain to "httpd_t" from "httpd_t.staff"
using the cookie illegally obtained.
So, we can find its benefit at preventing harms from buggy scripts.
However, this idea is the best one in I could flash on unfortunatelly.
Is there any other elegant design?
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.
