Le 02/12/2014 00:36, Carsten Haitzler (The Rasterman) a écrit :
On Mon, 1 Dec 2014 18:03:02 +0000 "Schaufler, Casey"
<[email protected]> said:
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.
The installer read the privileges for a package but store them by AppID.
So the multiple Binaries coming from a single package are still
controlled as individual App.
We get that side covered.
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).
Yes that is one of the requirement. Our challenge is induced by the
architecture of Crosswalk where the surface are requested by a process
which common to all the Apps for a given user.
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.
Yes in Tizen the WRT is part of the paltform and is trusted for some
services.
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.
One model would be to enable WRT to report for which AppID, the surface
is requested letting then the compositor report in a unified manner from
Native and HTML5 Apps.
to me the cleanest solution would be the ability to tag properties onto an app
- like a smack label.
that what we do. Each App runs which a smack label which is its own AppID.
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).
Techically, the security manager tags each App on a request from 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).
It seems that you are in sync with the proposition from the Security group.
Using the Smack label provides us only one reference token, so only one
label model can be use.
Dominig ar Foll
Senior Software Architect
Open Source Technology Centre
Intel SSG
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
