Hi Baptiste, Yes, it should be independent. It is the intention here. I just meant to reuse part of the code, and just clean dependent parts.
As for the Encryption, what I understood, firstly we are focusing on steps mentioned in https://bugs.tizen.org/jira/browse/TC-2061 (sub tasks). But yes, it is a good plan, to start to separate “encryption” feature. I will ask someone to take care about that. We will let you know the status of this. Best Regards, Pawel Sikorski From: Baptiste Durand [mailto:[email protected]] Sent: Tuesday, November 25, 2014 10:34 AM To: Pawel Sikorski Cc: José Bollo; Bumjin Im; Schaufler, Casey; Bartlomiej Grzelewski; Tomasz Swierczek; [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]>: 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]] :)! >>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]] Sent: Monday, November 24, 2014 5:25 PM To: Pawel Sikorski; Bumjin Im; Schaufler, Casey Cc: 'Baptiste Durand'; [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
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
