you have noted that:
>As long as your application does not manage shared objects in userspace,
you don't need to consult userspace AVC before actions.
this is exactly what I am going to do. that is, I have userspace some shared objects that I need to control my threads access to these objects. but I don`t know if I should consult AVC myself in userspace per access (because as we both agree that my userspace threads` context is bounded by my OS process)or SELinus does this for me itself.
I think it seems logical that since kernel doesnot know any thing about my threads(e.g. pthreads) I should have some hooks that consult SELinux when needed.how do you think? but here comes another question, if my thread were kernel level, would I need hooks for controling my threads access to userspace shared objects?
as the last question, I want to know, in a multithreaded process, which uses M:1 model, if access requests from threads to OS , are delivered by that single process or if not, how is it done?
Best regards
2009/10/19 KaiGai Kohei <kaigai@xxxxxxxxxxxxx>
michel m wrote:I seems to me you are confusing about different two concepts.
> hi,
>
> as I was studying on how to assign different security context on
> threads defined in a process, I found that there is a concept named
> BOUNDS DOMAIN which does this for me.
> now I would like to know for implementing a userspace object manager
> that uses this mechanism for its threads, how requests for OS
> resources are protected. that is, if my single OS process changes its
> security context per thread request or I should consult AVC before any
> action taken by my threads if that action is legal.
The one is bounds-domain, the other is userspace object manager.
Once a thread changes its domain to the bounded one, its privileges
are more restrictive than the original domain. Then, SELinux checks
the given actions based on the restricted privileges.
It goes against to the assumption of SELinux.
> I should consult AVC before any
> action taken by my threads if that action is legal.
How do you make sure the checks are well comprehensive?
Since it is near to impossible to check and eliminate any bugs in
userspace, so we check violated accesses in kernel space.
As long as your application does not manage shared objects in userspace,
you don't need to consult userspace AVC before actions.
You can set a new domain on the thread using setcon(3) API.
> is there any documentation on this topic?
The only difference from dynamic domain transition is that
the newer domain has to be bounded by the older domain.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@xxxxxxxxxxxxx>
