On 2014-05-15 11:59, Kis, Zoltan wrote: > > Here we have options. > > A. Security (service) proxy is the only enforcement point. Dominig's proposal. > In this case the EP is totally transparent and inherits the app identity. > We need to solve how the browser process will know to pop up a user > dialog for permissions. > Also, all API's that are accessed by the web runtime need to be > exposed by the service proxy, which is a huge work with huge delay. > > B. There may be multiple enforcement points (EP, dbus-daemon, > service-proxy). This allows direct DBUS access from apps, and in the > rest works like in A. Sub-options: > 1.) EP is also enforcement point, and part of the system. Then, EP > checks if access is allowed, either by > a) asking Cynara, or > b) EP caches policy data from Cynara (with an update/sync mechanism > for that data) and makes a local decision, which is much faster than > a). > 2.) EP is not an enforcement point (only dbus-daemon and service-proxy > are). Then it works like in A, but EP would have direct access to DBUS > API's, making the transition much easier, and the work much lighter > than in A. > > In either case, you can reuse the upper part of your design. > Currently only A. is a proposal, although B. is forming up to be a > proposal, too. > The issue is still debated in the architecture forum, but IMO it would > be enough if security experts would analyze both, publish it here, and > select one of them (A, B1a, B1b, or B2). So far the analysis part is > not clear (except for A). Personally, I would be fine with either B1b > or B2.
If EP is going to be an actual process making the access to protected resources and services then I don't think it's a good point for enforcement. If I understood correctly, there will be one EP per application and it will run with user's UID and application's Smack label. In such case I would vote for option B2. Option B1 doesn't protect against applications hijacking their EPs and running malicious code in it, bypassing the enforcement.
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
