l.wojciechow at partner.samsung.com
Mon Apr 14 14:23:29 GMT 2014
W dniu 2014-04-14 15:44, José Bollo pisze:
> On lun, 2014-04-14 at 14:59 +0200, Lukasz Wojciechowski wrote:
>> Hello Sorry on lag in answering to list.
> You are forgiven.
>> I've been working on Cynara's API (that is BTW already published on wiki
>> page http://wiki.tizen.org/wiki/Security:Cynara#API_2).
>> There is only synchronous API designed for libCynara for now. I agree
>> that there is a need for asynchronous API and we are going to publish
>> one later. For now our priority is to get Cynara working with currently
>> published API.
>> Cynara needs to know policies in order to properly check privileges when
>> asked. Someone has to gave it some. I believe that there will be many
>> processes that will need to change set of Cynara policies:
>> * installer (it reads manifests and knowns what application wants to use
>> what privileges)
>> * privilege-manager (it certainly has to access Cynara policies to make
>> some user demand restrictions)
>> * user adding/removing/managing (every user created has a list of
>> applications that [s]he ca run and a set of privileges that [s]he can use)
> Look at what you wrote just above.
Yes, there is a need for that. And this need will be satisfied with
CynaraAdmin through secure interface described below.
>> In Cynara we have two interfaces:
>> * one for checking privileges - open for everybody (or almost) -
>> accessed by libCynara
>> * second for playing with Cynara policies
>> The 2nd one should be used only by a trusted application. I believe here
>> is a need for a 2nd service to take care a CynaraAdmin role.
>> Cynara is design to be completely generic. There are no Tizen relations
>> in its API. CynaraAdmin service needs to give provide API specific to
>> Tizen distribution taht will be used for:
>> * managing policies
>> * managing users
>> * application installation processes
>> * application launchers
>> It shall be an extended service version of current libprivilege-control
>> API. This will be Tizen specific.
>> It will be responsible for setting SMACK labels on directories and files
>> during installation, proper privileges dropping (setuid, etc) during
>> application launch
>> and among all these things it will also set proper policy rules in Cynara.
>> @Jose: Why do You think that SMACK label user's UID and privilege name
>> are not enough to check access? Maybe You can provide an example?
> Above you wrote that the privilege (restrictions) are given by
> application. Then I'm understanding that the application is needed to
> determine the rights.
> But what are the privilege we are talking about? Is it those of
> https://www.tizen.org/fr/privilege/ ? Or is it something else?
> Best regards
Every application defines in manifest files, what privileges are
required to run an application. It is installer responsibility to read
manifest, probably ask user if [s]he accepts those privileges.
Next installer installs application and must run some secure related
actions like: Smack labeling installed files and directories and setting
proper policy rules in Cynara.
I believe all secure related actions should be gathered in one place -
CynaraAdmin service that will use:
1) libprivilege-control and libsmack for setting labels
2) libCynaraAdmin for setting policy rules in Cynara.
This a basic source of Cynara's rules. However there are more: user
installations, privilege-checker, etc.
Yes for privilege definition. However Cynara is very flexible tool and I
can imagine that privile list can be extended to privileges offered by
some services and even to dynamicaly created services. Cynara is a tool,
and how we use this tool is up to us.
More information about the Dev