All of lore.kernel.org
 help / color / mirror / Atom feed
* bounds domain
@ 2009-10-17  8:11 michel m
  2009-10-19  5:25 ` KaiGai Kohei
  0 siblings, 1 reply; 6+ messages in thread
From: michel m @ 2009-10-17  8:11 UTC (permalink / raw)
  To: selinux

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.

is there any documentation on this topic?

Best Regards.

--
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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: bounds domain
  2009-10-17  8:11 bounds domain michel m
@ 2009-10-19  5:25 ` KaiGai Kohei
  2009-10-19  9:51   ` michel m
  0 siblings, 1 reply; 6+ messages in thread
From: KaiGai Kohei @ 2009-10-19  5:25 UTC (permalink / raw)
  To: michel m; +Cc: selinux

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: bounds domain
  2009-10-19  5:25 ` KaiGai Kohei
@ 2009-10-19  9:51   ` michel m
  2009-10-19 13:57     ` Stephen Smalley
  0 siblings, 1 reply; 6+ messages in thread
From: michel m @ 2009-10-19  9:51 UTC (permalink / raw)
  To: KaiGai Kohei; +Cc: selinux

[-- Attachment #1: Type: text/plain, Size: 2760 bytes --]

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>
>

[-- Attachment #2: Type: text/html, Size: 3393 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: bounds domain
  2009-10-19  9:51   ` michel m
@ 2009-10-19 13:57     ` Stephen Smalley
  2009-10-20 16:25       ` michel m
  0 siblings, 1 reply; 6+ messages in thread
From: Stephen Smalley @ 2009-10-19 13:57 UTC (permalink / raw)
  To: michel m; +Cc: KaiGai Kohei, selinux

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: bounds domain
  2009-10-19 13:57     ` Stephen Smalley
@ 2009-10-20 16:25       ` michel m
  2009-10-20 16:56         ` Stephen Smalley
  0 siblings, 1 reply; 6+ messages in thread
From: michel m @ 2009-10-20 16:25 UTC (permalink / raw)
  To: Stephen Smalley; +Cc: KaiGai Kohei, selinux

thanks for your guidance,
if we turn our attention into Java virtual machine(JVM), I want to
have an access control on conceptual java threads that are
encapsulated inside jvm, so I need to know which kernel managed
process, these threads are mapped to. Is there such a mapping at all?
if yes, how is it?

I am going to manage java objects and java threads access to these
objects. If I want to use setcon() API by JNI, I don`t know what will
be labeled? Does a kernel thread get labeled or jvm process will be
labeled?

Best regards

On 10/19/09, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: bounds domain
  2009-10-20 16:25       ` michel m
@ 2009-10-20 16:56         ` Stephen Smalley
  0 siblings, 0 replies; 6+ messages in thread
From: Stephen Smalley @ 2009-10-20 16:56 UTC (permalink / raw)
  To: michel m; +Cc: KaiGai Kohei, selinux

On Tue, 2009-10-20 at 19:55 +0330, michel m wrote:
> thanks for your guidance,
> if we turn our attention into Java virtual machine(JVM), I want to
> have an access control on conceptual java threads that are
> encapsulated inside jvm, so I need to know which kernel managed
> process, these threads are mapped to. Is there such a mapping at all?
> if yes, how is it?
> 
> I am going to manage java objects and java threads access to these
> objects. If I want to use setcon() API by JNI, I don`t know what will
> be labeled? Does a kernel thread get labeled or jvm process will be
> labeled?

Doesn't really make sense to do that in Java without Isolates (JSR 121).

setcon(3) acts on the current kernel thread only.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2009-10-20 16:56 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-17  8:11 bounds domain michel m
2009-10-19  5:25 ` KaiGai Kohei
2009-10-19  9:51   ` michel m
2009-10-19 13:57     ` Stephen Smalley
2009-10-20 16:25       ` michel m
2009-10-20 16:56         ` Stephen Smalley

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.