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).
Seen.
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.
Agreed.
(snip)
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
José
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.
best regards
Lukasz
_______________________________________________
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev
