On Mon, 1 Dec 2014 18:03:02 +0000 "Schaufler, Casey" <[email protected]> said:
> > -----Original Message----- > > From: Carsten Haitzler [mailto:[email protected]] > > Sent: Monday, December 01, 2014 4:05 AM > > To: Schaufler, Casey > > Cc: Puustinen, Ismo; [email protected] > > Subject: Re: [Dev] [RFC] AUL UI request for multi-process applications > > (ICO/Crosswalk...) > > > > On Sun, 30 Nov 2014 21:41:45 +0000 "Schaufler, Casey" > > <[email protected]> said: > > > > > > -----Original Message----- > > > > From: Puustinen, Ismo > > > > Sent: Thursday, November 27, 2014 12:42 AM > > > > To: Schaufler, Casey > > > > Cc: [email protected]; [email protected] > > > > Subject: Re: [Dev] [RFC] AUL UI request for multi-process applications > > > > (ICO/Crosswalk...) > > > > > > > > Hi Casey, > > > > > > > > In IVI domain the car manufacturers may want to place "regulations" that > > > > limit the applications that can be shown on the screen in different car > > > > use cases. For instance: > > > > > > > > * When the car is moving, applications that play video are not allowed > > > > on the screen. > > > > * When the car is in reverse gear, the application that shows reverse > > > > camera video must be shown on the screen. > > > > * When the car is not moving, all applications are allowed on the > > > > screen. > > > > > > > > You can easily think up a large number of possible use cases such as > > > > these ones. > > > > > > > > It's "easy" to enforce similar audio policies since we have a pretty > > > > good idea who is playing audio to PulseAudio. > > > > > > Having a "pretty good idea" is not secure. > > > > > > > In order to do such screen > > > > policy enforcement (even in collaborative way, when the application is > > > > announcing it's true capabilities in the manifest file) we have to > > > > somehow know which surface belongs to which application. > > > > > > Identifying the application making a request is easy, that's what we > > > have Cynara for. > > > > from what i see here... the app advertises what kind fo app it is. be it in > > manifest or on the window... does it much matter? i don't see this as a > > security thing as such... just a matter of "playing nice". > > Yes, I believe that it does. The application installer reads the > manifest and applies some policy regarding the integrity of the > application based on signatures (or lack thereof) within the manifest. > The value and worthiness of the signature mechanism is a separate > discussion. The application of that policy is done by trusted > components of the system. The installer also assigns information > that Cynara will use to identify the application. This information > can be considered reliable. > > Information provided by the application about itself cannot be > trusted. Ever. You can't count on an application to "play nice". you still have problems. a single app package can't have multiple "binaries" that can do different things. can't have different windows have different tasks. in x11 you can't do anything. it's a free for all on windows. in wayland you could inspect the fd of the client owning the surface and query kernel for info. at this stage i think this is best done in this way - app requests to be a lockscreen (though i still think this should be integrated as part of the compositor, but let's use this as an example, or adds a property that says "please show me while driving - i'm ok"). compositor/wm sees this then "does the appropriate thing" (eg hides all windows/surfaces that do NOT have this property). one extra catch - in wayland the compositor can double-check this property .. *IF* set by querying credentials fro the kernel on the fd. you would need to be able to "tag" a process... like with a special smack label. this special smack label confers a level of trust on the process. in the case of webruntime - we shall confer this trust as the wrt ships with tizen and is a system controlled component. we "trust" the wrt to correctly advertise the above properties, because it is a sandbox and its entire job *IS* to enforce such things within its runtime on behalf of the processes that run beneath it. thus the gpu process owning the window can place properties here and we can "trust" it to have correctly placed that property after it has done whatever checks it should. if you want to share a single gpuprocess across multiple apps, this is a requirement of that design. if not then scrap the design. separate gpuprocess per app. this also works with native apps as only apps with specific smack labels will be trusted when they claim certain "privileged" properties i dislike the idea of getting some app id, then tracing that appid back to a manifest, then having to parse that to get the data. this has to be done by the compositor/wm. it's more complicated and requires more work/overhead. to me the cleanest solution would be the ability to tag properties onto an app - like a smack label. but these properties are added like the smack label - by the kernel itself based on on-disk information about that process that only someone with secure (root) access should set (eg the installer). this would avoid needing a different smack label but allow a very simple way of saying "can process id X do Y or Z?". it gets tagged with Y or Z. maybe buried in xattr somewhere. so we should be able to query the fd of a socket for these attributes on he other side of the socket. let's pretend we have something like: int fd; char buf[256]; size_t size; while ((size = smack_fd_attr_query(fd, buf, sizeof(buf))) > 0) { // parse buffer - we have "attr1\0attr2\0attr3\0..." - keep it simple? } or something else? just tossing that out there. anyway - if we have "well known attributes" that we know are trusted as they come from the kernel... it's simple to implement. the other alternative - just use the smack label itself - a well known smack label would confer a higher level of trust for 1 or more properties (depending on label - maybe several labels with different mappings). > > > What is a "surface", and who manages surfaces? > > > In this discussion I see the terms "window", "surface" and "screen". > > > Are they the same? Are they related? Are they controlled by the > > > same service? Who is ultimately responsible for making the decision? > > > > window and surface are the same. screen ay show one or more surfaces ... > > maybe > > overlapping, maybe not. compositor/wm decide on how to show thse. these > > processes just see windows/surfaces. > > Then the compositor needs to enforce policy (whatever it may be). > > > > > > Ismo > > > > > > > > > > > > On Wed, 2014-11-26 at 17:00 +0000, Schaufler, Casey wrote: > > > > > Why does the package name get used to determine if a window gets > > > > > displayed? What policy do you really want to enforce? There has got to > > > > > be a less convoluted way to get what you want than this. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Dev [mailto:[email protected]] On Behalf Of Manuel > > > > > Bachmann > > > > > Sent: Wednesday, November 26, 2014 5:10 AM > > > > > To: [email protected] > > > > > Subject: [Dev] [RFC] AUL UI request for multi-process applications > > > > > (ICO/Crosswalk...) > > > > > > > > > > > > > > > > > > > > > > > > > Hi folks, > > > > > > > > > > > > > > > This RFC is about bug TC-1691, TC-159... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (The problem happens with Crosswalk today, but it could happen with > > > > > any other application) > > > > > > > > > > > > > > > AUL provide somes function calls, like "aul_app_get_pkgname_bypid > > > > > ()", which permit to get the application package name associated with > > > > > a running PID. > > > > > > > > > > > > > > > Under IVI, the ICO Homescreen (profile/ivi/ico-uxf-homescreen) uses > > > > > these calls to determine if it should show a window, by getting the > > > > > PID of its process, and then comparing it will the package name. If if > > > > > does not match, the window stays hidden. > > > > > > > > > > The problem is : > > > > > > > > > > > > > > > In Crosswalk, the process which creates the window (the GPU process) > > > > > is *not* the same that the one (the browser process) which registers > > > > > itself as a Tizen application. > > > > > > > > > > > > > > > Crosswalk has a dedicated process for UI operations, which is > > > > > different of the one that does the application logic. > > > > > So, the name is never found, and Web applications never show. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In this respect, we need a way for an application to "pass" its > > > > > application identifier to the graphical layer (in this case, ICO).Here > > > > > are 2 options : > > > > > > > > > > 1) in Crosswalk itself, have a package name passed from application > > > > > layer to the UI/GPU one (won't probably be upstream). Then, have a > > > > > Weston plugin "receive" and store the information. When requested by > > > > > the "aul_app_get_pkgname_bypid ()" call, AUL will also request the > > > > > plugin for this information and respond. > > > > > > > > > > > > > > > Requires modifications in : 3 packages (crosswalk, weston, aul-1) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) in Crosswalk itself, have a package name passed from application > > > > > layer to the UI/GPU one (won't probably be upstream). Then, store this > > > > > data in a local database or specific tmpfs. When requested by the > > > > > "aul_app_get_pkgname_bypid ()" call, AUL will also request this base > > > > > or tmpfs for this information and respond. > > > > > > > > > > > > > > > Requires modification in : 2 packages (crosswalk, aul-1) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The 2nd idea modifies less packages but may be trickier to implement. > > > > > Any opinion on this ? > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Regards, > > > > > > > > > > Manuel BACHMANN > > > > > Tizen Project > > > > > VANNES-FR > > > > > > > > > > > > > > > _______________________________________________ > > > > > Dev mailing list > > > > > [email protected] > > > > > https://lists.tizen.org/listinfo/dev > > > > > > _______________________________________________ > > > Dev mailing list > > > [email protected] > > > https://lists.tizen.org/listinfo/dev > > > > > > > > > -- > > Carsten Haitzler (The Rasterman) <[email protected]> > -- Carsten Haitzler (The Rasterman) <[email protected]> _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
