On Dec 3, 2014 4:46 PM, "Nick Kralevich" <[email protected]> wrote: > > > > On Wed, Dec 3, 2014 at 3:53 PM, William Roberts <[email protected]> wrote: >>> >>> 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? > > > Having each service be a dedicated thread would be wasting a lot of threads. > >> >> >>> >>> >>> 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. > > > The particular use case I'm thinking of is isolated_app. https://android-review.googlesource.com/106676 removed the ability of isolated_app to access GPU devices. However, there is a use case for isolated_apps to access GPU devices. It would be nice for isolated_apps to start in the isolated_app domain, and if they don't want GPU access, to drop privileges to the "isolated_app_no_gpu" domain by calling setcon_all(). > > Longer term, it would be nice if an app could define their own SELinux domain (typebounded, of course), so that apps could choose whatever restrictions are appropriate for them. I haven't worked through the logistics of how that might work...
Rpm wanted this, did it ever happen? I think Tizen is taking a app bundled with policy approach. > >> >> >>> >>> >>> -- 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 >> > > > > -- > Nick Kralevich | Android Security | [email protected] | 650.214.4037
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
