OK., my conclusions went too far. Per-user application installation changes assumptions on which Cynara policy construction was based. We had a quick brain storm with Lukasz Wojciechowski and managed to adapt to this in a way that would only affect Cynara.
On 2014-06-20 17:01, Schaufler, Casey wrote: > > *From:*Dev [mailto:[email protected]] *On Behalf Of *Rafal Krypa > *Sent:* Friday, June 20, 2014 5:47 AM > *To:* [email protected] > *Subject:* [Dev] Crosswalk multi-user implementation vs. Smack > > > > The two are not at odds. Or, should I say, the three. > > > > Hi, > > I have investigated current Crosswalk behavior with respect to multi-user and > I think that we may have some incompatibilities with platform security design. > > > > The security team and the Crosswalk team are working closely to ensure that > Crosswalk performs its role in platform security properly. > > > It seems that web applications are now installed per user. > > > > Yes, this is a multi-user requirement. Otherwise if Fred installs an > application Pebbles will always have access to it. > > > > I found application data installed into > ~/.config/xwalk-service/applications/$APP_ID and aplication information > stored in ~/.application. Using xwalkctl I was able to install the same > application for multiple users. The app was assigned the same application and > package id for user. > > > > Which is correct. It gets the same application ID because it is the same > application, and it gets the same package id because it came from the same > package. > > > This is something slightly different than I heard before and expected. > > > > It shouldn’t be. It is the only rational way to allow two users to maintain > their own distinct application environments. > > > > And I think it forces us to revisit Smack label assignment for applications. > > > > No, this is exactly what it expected and desired. > > > > With applications installed locally in user home, it is unfeasible to base > Smack label only on package id. This would lead to multiple users having > applications with the same label. > > > > Yes. This is intentional. We have a requirement for application isolation. > Not application instance isolation. Not application instance invocation > isolation. This is important. Consider two people in a car (backseat, of > course!) each running their own copy of SwordSwinger (in “fight to the death” > mode). The application expects to interact with other instances of itself > running on the device. That is how it provides a delightful user experience. > > > > Those applications could have entirely different set of permissions (e.g. > different versions of the same app or id collision for two unrelated > applications). If application management is to be done entirely per-user, a > different Smack labeling will be required. > > > > You are leaving out what differentiates users, which is the UID. The UID is a > security attribute of the process, just like the Smack label. > > > One obvious solution would be to build Smack label from package id AND user > identifier. Down side of this would be multiplication of Smack labels in the > system and proportional growth of policy size. > > > > Yes, that is one option we would consider if we didn’t have UIDs. Because > processes have a Smack label and a UID we can always differentiate between > SwordSwinger run by Fred and SwordSwinger run by Barney. If Fred wants to > allow the application to update the internet scoreboard, and Barney > doesn’t, that’s easy to do. Cynara understands both Smack labels and UIDs. > > > > There is no need to panic. It’s all under control. … I think. > > >
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
