On Mon, 2009-10-19 at 13:21 +0330, michel m wrote: > 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. If your threads are accessing kernel objects (e.g. files, sockets, etc), then you can let the kernel perform the mediation based on the thread's security context. If your application is managing some objects/abstractions of its own that do not map directly to kernel objects (e.g. windows as in Xorg, connections as in DBus, database records as in PostGres), then it needs to act as a userspace object manager. > 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? On modern Linux distributions (with the Linux 2.6 kernel and the NPTL library), the threading model is 1:1, and thus the kernel can directly enforce the per-thread restrictions. -- Stephen Smalley National Security Agency -- 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.
