Hi Baptiste, I agreed that installer should be UI independent. And silent install should be work in auto test. In other cases, the install must wait for the result of user’s choice before really installing the application. So there is a sync relationship between installer and notification service.
Below is the user case to show permissions UI for your reference: 1. The installer retrieve permissions from the config.xml in the application 2. The installer pass the information: application name, permission list to notification service and wait the response from user. 3. The notification service call some graphical toolkit to show the UI which including the specific information on the application 4. End user select “Agree” or “Deny” in the dialog 5. The notification service return the result to application installer. 6. The installer goes on handling other checks if user agree application use declared permissions. Otherwise the installer should exit the installation. Best Regards Zhang Xu From: Baptiste Durand [mailto:[email protected]] Sent: Tuesday, November 25, 2014 6:02 PM To: Zhang, Xu U Cc: Pawel Sikorski; You, Yongkang; [email protected] Subject: Re: [Dev] App Installer WorkShop Status Hi Xu, The install should be UI independent, it can only use notification service to show pop up for permission. I don't want to see any deps to specific graphical toolkit in installer. we will support silent install in particular case (ie preinstallation / image creation). BR Baptiste 2014-11-25 10:39 GMT+01:00 Zhang, Xu U <[email protected]<mailto:[email protected]>>: Hi all, Is there a feature that the installer will handle UI? As you know, there should be a prompt dialog to user whether to allow the application use some permissions. If there is such feature, do you consider to support silent install? Thanks Zhang Xu From: Dev [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Baptiste Durand Sent: Tuesday, November 25, 2014 5:34 PM To: Pawel Sikorski Cc: [email protected]<mailto:[email protected]> Subject: Re: [Dev] App Installer WorkShop Status Hi Pawel , I prefers that the installer code will be as possible independent of the Launcher and Renderer (here crosswalk). I agree to reuse code yes, but I prefers to import them without especially deps to Google stack. Indeed signature check are also need for Native apps so having a feature that depends of a WRT software to do it sounds strange. -> About Encryption feature : -> The AES key in crosswallk are not managed yet by the key-manager correct? -> I'm wondering if can reuse the code of wrt-installer part instead? To be reasonable, I thinks we need to proceed in two steps: In a first step, to go faster, as Chromium has a feature already integrated for this we can have a binary developed in the crosswalk source code that encrypt the app file for the installer, that permits to have the feature encryption. We need to be sure AES Key used by crosswalk will be managed by key-manager. And this permits to let time to develop 2nd step : i.e have a definitive solution without Google stack. Pawel, do you agree with this plan for the encryption feature? Thanks for your answer/ BR Baptiste 2014-11-25 10:01 GMT+01:00 Pawel Sikorski <[email protected]<mailto:[email protected]>>: Hi Jose, All, Thanks for the answer and points. Yes, I understand your points and agree with them. Having common installer will simplify the architecture here. Keeping the privilege level extraction/verification will be also easier to prepare. We already have some code in crosswalk, that can be used here. It is thanks to Zhang, Xu U [[email protected]<mailto:[email protected]>] :)! >>Hi Baptiste, >> >>I have implemented some features on Crosswalk installer, I think they may be >>useful for your reference. >>1. https://github.com/crosswalk-project/crosswalk/pull/2518. >>For this pull request, it implement the features below: >>* Parser Tizen privileges from config.xml of wgt >>* Register application’s permission to Cynara policy >>* Call security manager to set smack label for files in the widget >>I think you can use some code directly and send pull request in Tizen gerrit >> >>2. https://github.com/crosswalk-project/crosswalk/pull/2169 >>https://github.com/crosswalk-project/crosswalk/pull/2291 >>https://github.com/crosswalk-project/crosswalk/pull/2422 >>For these pull requests, they implemented features Tizen widget signature >>checking >> >>Best Regards >>Zhang Xu >> Thank you Zhang Xu for the info. >>HERE IS THE QUESTION: Is the computation of the privilege level based on >>the signature chain used only in installers? I do not know any other places, but I cannot be sure, that there none. Sorry. Best Regards, Pawel Sikorski -----Original Message----- From: José Bollo [mailto:[email protected]<mailto:[email protected]>] Sent: Monday, November 24, 2014 5:25 PM To: Pawel Sikorski; Bumjin Im; Schaufler, Casey Cc: 'Baptiste Durand'; [email protected]<mailto:[email protected]> Subject: Re: [Dev] App Installer WorkShop Status Hi all, hi Pawel, Le samedi 22 novembre 2014 à 13:54 +0100, Pawel Sikorski a écrit : <snip> > platform/core/security/key-manager <snip> > As for the extraction of signature levels (platform, public, partner), > originally, wrt-installer used a package used cert-svc repository, > module vcore. > > I will discuss this item more with Security Team and let you know the > output. <snip> Thank you for your investigation. I had no time to check today but will try tomorrow... maybe. However, I want to point out the fact that computing the privilege level is a very sensitive operation: it has to be fully trusted. IIRC, the security manager that currently is in charge of recording the privileges in Cynara's database is not checking the level of privileges. Then, any program with the correct privilege for using the security-manager features will be allowed to install an application with any privilege of any level. It is showing how setting a common code for installer is beneficial: all of its derived installer will gain a trusted common piece of code for computing the privilege level. This model is very simple and only needs that installers are trusted. It also requires that API's of security manager are filtered on specific privileges of high level. An other model would be to have a specific service to manage the privilege levels. But this way looks very impractical and should be considered only if the privilege level have to be checked in other places than installers. HERE IS THE QUESTION: Is the computation of the privilege level based on the signature chain used only in installers? I would like to insist on the importance of this aspect of the security. Best regards José Bollo -- Baptiste DURAND Eurogiciel Vannes/FR -- Baptiste DURAND Eurogiciel Vannes/FR
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
