> Rpm wanted this, did it ever happen? The basic set of hooks in order to support rpm plugins (that in turn can for example parse and apply per-application policy) were merged to rpm a while back. Some minor hooks were omitted at that point since we either didn't see a strong use case for them or were not exactly sure about the right way to do it. But if you are interested you can check the available rpm plugin hooks:
http://rpm.org/gitweb?p=rpm.git;a=blob;f=lib/rpmplugins.h;h=ecfa68b4a5eb40771cb07ddd9d5eb2d1443f79ce;hb=4c621e97776a47c2b4e7f17c1cd2a7961453babf > I think Tizen is taking a app bundled with policy approach. There is a possibility to do it in Tizen, because we actually have a rpm security plugin to do per application manifest parsing even for native apps. I guess Casey can comment more on the future of this mechanism. I have been away from Tizen for a while now. I also remember a while back that we had a similar dilemma with Smack security context labels and threads. Casey what was the outcome? I remember that we also didn't agree on any proper solution and used some workaround to address certain use cases, but was anything changed in Smack because of this? On Thu, Dec 4, 2014 at 3:52 AM, William Roberts <[email protected]> wrote: > > 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]. >
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
