On Thu, Dec 4, 2014 at 1:01 PM, Stephen Smalley <[email protected]>
wrote:

> It has to be initiated explicitly by that thread calling setcon(3)
>

Ok getting closer. So the setcon has to be done prior to creating any other
threads per the man page, so what happens to
the processes domain, does it switch too?

Lets try using an example.

thread() {
  // what is tcontext here?
  tcontext = getcon()
  return
}

main() {

  // my context is: u:r:mydomain:s0
  mycontext = getcon()

  dostuff();

  //ok time to lunch thread... mydomain_thread is typebounded on mydomain
  setcon(u:r:mydomain_thread:s0)

  // what is mycontext here?
  mycontext = getcon()

  t = start_thread(thread);
  join(t);

  // what is mycontext here?
  mycontext = getcon()

  return;
}





> when it wants to perform the switch; mod_selinux calls setcon() from
> the worker thread to assume the desired context for the web app.  And
> the policy involves more than just the typebounds declaration (that
> just defines the hierarchy - it does not allow anything or cause any
> transitions).

I didn't think so, but it was unclear to me from the setcon manpage what
cause the thread context transition.


>   You have to fully specify everything you want to allow
> to the child type via explicit allow rules still.  And you cannot
> allow it anything not allowed to the parent type, so even access to
> derived types (e.g. child_tmpfs) has to be allowed to the parent in
> order to allow it to the child.
>
> On Thu, Dec 4, 2014 at 1:04 PM, William Roberts
> <[email protected]> wrote:
> >
> > On Dec 4, 2014 9:45 AM, "Stephen Smalley" <[email protected]>
> wrote:
> >>
> >> With the exception of typebounds, you can't unless it is the first
> >> thread and you set it before creating any others, which is precisely
> >> what is done in dalvik and art for setting the context of
> >> system_server and apps.
> >
> > I get that part. I think I'm not asking my question properly. What I'm
> > trying to say is that if you declare this typebounds rule what does that
> > actually get you? Is it that any thread created by the process gets
> placed
> > into the bounded domain automatically by the kernel or is this some
> > additional user space mechanism needed?
> >
> >   If using typebounds, then it will be
> >> permitted for other threads but it is up to you to ensure that you
> >> have a 1:1 user:kernel thread model and that the usage model is safe
> >> as in the mod_selinux case.
> >
> > In the mod_selinux_case what actually would cause a transition from the
> > process domain into this bounded domain? Again is this transition
> initiated
> > by some user space code like set con or is it handled automatically like
> a
> > process type transition by the kernel?
> >
> > Any other scenario, e.g. a setcon_all(),
> >> would require a kernel change to support
> >>
> >> On Thu, Dec 4, 2014 at 10:17 AM, William Roberts
> >> <[email protected]> wrote:
> >> >
> >> > On Dec 4, 2014 5:54 AM, "Stephen Smalley" <[email protected]>
> >> > wrote:
> >> >>
> >> >> See https://code.google.com/p/sepgsql/wiki/Apache_SELinux_plus.
> >> >
> >> > Yes I briefly looked at this.
> >> >
> >> >> That was the original motivation for taking awareness of the type
> >> >> hierarchy (aka typebounds) into the kernel, so that the kernel could
> >> >> leverage it to decide when it is safe to allow a thread in a
> >> >> multi-threaded process to switch contexts (i.e. when the change can
> >> >> only reduce permissions).
> >> >
> >> > OK and this is what my original question gets at. Is setcon fails in
> >> > multithreaded programs how can one set a threads context?
> >> >
> >> > The typebounds support replaced the old
> >> >> libsepol/checkpolicy-only support for the type hierarchy and was
> >> >> implemented by KaiGai Kohei as part of that project.  It presumes
> >> >> however that the kernel:user threading model is 1:1 (true in the
> >> >> NPTL), which I don't believe holds for the Android runtime.
> >> >>
> >> >> On Wed, Dec 3, 2014 at 6:53 PM, William Roberts
> >> >> <[email protected]> wrote:
> >> >> >
> >> >> >
> >> >> > On Wed, Dec 3, 2014 at 2:57 PM, Nick Kralevich <[email protected]>
> >> >> > wrote:
> >> >> >>
> >> >> >>
> >> >> >> Stephen said it best in
> >> >> >> http://www.spinics.net/lists/selinux/msg01471.html
> >> >> >> . Quoting him:
> >> >> >>
> >> >> >> setcon() presently fails with EPERM if a multi-threaded
> application
> >> >> >> tries
> >> >> >> to invoke it.
> >> >> >>
> >> >> >> You can't prevent a thread within a process (thread group) from
> >> >> >> accessing
> >> >> >> any of the memory - they share the same memory space.  Thus, you
> >> >> >> can't
> >> >> >> safely run one thread in one security context and another thread
> in
> >> >> >> another
> >> >> >> security context.
> >> >> >
> >> >> > Yeah this was why I was confused. Their some document where they
> >> >> > described
> >> >> > some apache web server dispatching threads on some other context
> and
> >> >> > it
> >> >> > seemed strange to me. Assuming perfect code, you can at least limit
> >> >> > the
> >> >> > syscall interactions.
> >> >> >>
> >> >> >>
> >> >> >> Trying to isolate system_server threads using this mechanism is
> >> >> >> bound
> >> >> >> to
> >> >> >> fail. Even if setcon() worked on threads, many services use
> execute
> >> >> >> queues
> >> >> >> to do their operations, which would make it difficult to identify
> >> >> >> which
> >> >> >> thread is responsible for which activity.
> >> >> >
> >> >> >
> >> >> > Yes that would make it hard. Is each service started with its own
> >> >> > dedicated
> >> >> > thread? Assuming some scenario where threads are bounded couldn't
> the
> >> >> > work
> >> >> > queue be smart enough to dispatch on a thread with the same type
> >> >> > label?
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> It would be nice to have a better solution but I'm not sure what
> it
> >> >> >> is.
> >> >> >
> >> >> >
> >> >> > Me either. I have never been a fan of system server from a security
> >> >> > standpoint since its one big address space of fun.
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> One thing I'd love to see is for setcon() to work on a
> thread-group
> >> >> >> basis.
> >> >> >> For example, imagine a "setcon_all()" function which set *every*
> >> >> >> thread
> >> >> >> to
> >> >> >> the provided security context atomically. This avoids the security
> >> >> >> concerns
> >> >> >> raised by Stephen.
> >> >> >>
> >> >> >> This, in conjunction with typebounds, could allow an application
> to
> >> >> >> start
> >> >> >> in a more privileged state, drop privileges using "setcon_all()",
> >> >> >> and
> >> >> >> continue executing with reduced privileges, regardless of the
> number
> >> >> >> of
> >> >> >> threads running at the time.
> >> >> >
> >> >> >
> >> >> > Yes that would be nice, is this a common scenario? Seems like many
> of
> >> >> > the
> >> >> > core services in Android are single threaded.
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> -- Nick
> >> >> >>
> >> >> >> On Mon, Dec 1, 2014 at 3:31 PM, William Roberts
> >> >> >> <[email protected]>
> >> >> >> wrote:
> >> >> >>>
> >> >> >>>
> >> >> >>> So I see that SELinux has typebounds, which can be used to
> enforce
> >> >> >>> that
> >> >> >>> some new domain, has less privelges then its parent thus building
> >> >> >>> some
> >> >> >>> type
> >> >> >>> of hierachy. It also,
> >> >> >>> says if you have some kernel version greater than 2.6.39 you can
> >> >> >>> control
> >> >> >>> thread contexts (http://selinuxproject.org/page/TypeRules).
> >> >> >>> However,
> >> >> >>> setcon
> >> >> >>> also allows the changing
> >> >> >>> of thread contexts.
> >> >> >>>
> >> >> >>> Also, setcon states that:
> >> >> >>>
> >> >> >>> A  multi-threaded  application can perform a setcon() prior to
> >> >> >>> creating
> >> >> >>>         any child threads, in which case all of the child threads
> >> >> >>> will
> >> >> >>> inherit
> >> >> >>>         the  new  context.   However, setcon() will fail if there
> >> >> >>> are
> >> >> >>> any
> >> >> >>> other
> >> >> >>>         threads running in the same process.
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> So is their some use of these types of technologies to control
> >> >> >>> threads
> >> >> >>> in
> >> >> >>> system server to help overcome its limitation of one gigantic
> >> >> >>> process?
> >> >> >>>
> >> >> >>> If no one can comment to this, can someone perhaps clarify the
> use
> >> >> >>> of
> >> >> >>> setcon in multiple threaded environment, can you use it to get
> the
> >> >> >>> main
> >> >> >>> thread, and child threads in all different domains?
> >> >> >>>
> >> >> >>> Bill
> >> >> >>>
> >> >> >>>
> >> >> >>> _______________________________________________
> >> >> >>> Seandroid-list mailing list
> >> >> >>> [email protected]
> >> >> >>> To unsubscribe, send email to [email protected]
> .
> >> >> >>> To get help, send an email containing "help" to
> >> >> >>> [email protected].
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Nick Kralevich | Android Security | [email protected] | 650.214.4037
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Respectfully,
> >> >> >
> >> >> > William C Roberts
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > Seandroid-list mailing list
> >> >> > [email protected]
> >> >> > To unsubscribe, send email to [email protected].
> >> >> > To get help, send an email containing "help" to
> >> >> > [email protected].
>



-- 
Respectfully,

William C Roberts
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to 
[email protected].

Reply via email to