| Main Archive Page > Month Archives > selinux archives |
hi,
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@ak.jp.nec.com>
> michel m wrote:
> > 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.
>
> I seems to me you are confusing about different two concepts.
> 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.
>
> > I should consult AVC before any
> > action taken by my threads if that action is legal.
>
> It goes against to the assumption of SELinux.
> 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.
>
> > is there any documentation on this topic?
>
> You can set a new domain on the thread using setcon(3) API.
> 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@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.