See https://code.google.com/p/sepgsql/wiki/Apache_SELinux_plus. 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). 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]. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
