[Dev] Simplifying access to a privilege manager using a virtual filesystem

Lukasz Wojciechowski l.wojciechow at partner.samsung.com
Fri Apr 25 16:11:32 GMT 2014

Keyzen seems to be a good and fast solution, but I don't know if it fits 
Tizen requirements.
Let me point some concerns:

1. multiuser
Keeping policies as files and protecting it with Smack won't solve 
multiuser problem as we cannot constraint access to same file / 
directory with Smack for different users.
There are two ways of doing it:
a) we can do it with DAC - just imagine amount of groups that need to be 
created and managed for maintain security
b) we can do it by allowing not to request directly file system, but to 
do it through process (service) that will give as the answer - and in 
this case we don't have any bonus from keeping policies in filesystem as 
the only one who can read it is some dedicated trusted process.

2. containers
One of Tizen 3.0 requirements is allowing to run applications in 
separate containers. It won't be possible to provide access to 
filesystem between host and containers. Here again some service 
providing secure IPC interface is needed.

3. types of policies
Proposed model describes policies as relations between privileges (files 
with prefix defining policy_type) for different processes: 
I don't think stretching it to uids will be easy. Both 
/tmp/keyzen/{PROCESS}/{UID}/{PRIVILEGE} and 
/tmp/keyzen/{UID}/{PROCESS}/{PRIVILEGE} may have problems with keeping 
policies defined for all users or for all applications (e.g. some user X 
is allowed to use privilege P for all applications that request it).

4. need of library
What does it mean "- there no real need of a library (all languages)". 
You describe a keyzen library with keyzen.h. It is de facto needed or we 
can check access without it? And if so how can type of policy (called 
mode on your github page) be used in such case.

5. Links to Cynara
How do You plan to link Keyzen and Cynara ? Are they going to cooperate? 
Is Keyzen a replacement for Cynara? You list two possible ways of 
linking those two models, but it is rather unification of model 
(replacing pids with uid/appid) than showing how would they work together.

Best wishes
Łukasz Wojciechowski

> Date: Thu, 24 Apr 2014 11:49:33 +0200
> From: Jos? Bollo <jobol at nonadev.net>
> To: "dev at lists.tizen.org" <dev at lists.tizen.org>
> Subject: [Dev] Simplifying access to a privilege manager using a
> 	virtual	filesystem
> Message-ID: <1398332973.4522.48.camel at intel06.vannes>
> Content-Type: text/plain; charset="UTF-8"
> Hi all,
> I finalized the proof of concept called 'keyzen' that you will find on
> github https://github.com/jobol/keyzen
> The advantages of using a filesystem to manage the privileges to access
> the API are:
> - it's fast
> - it could be linked tightly to LSM smack
> - it benefits of accesses control (DAC/MAC) and file namespace
> - there no real need of a library (all languages)
> - supports synchronous and asynchronous queries
> - no socket
> - no kernel change
> Traditionally, this type of access is done with a library using a socket
> or an IPC wich is more difficult to integrate with DAC/MAC, cannot be
> isolated with a file namespace and requires special binding for each
> langage.
> It will allow to implement the tizen privileges defined at
> https://www.tizen.org/fr/privilege/ and can be adapted to cynara's
> concepts of application-id / user-id.
> I propose to simplify the access to cynara by using that model. Each
> service, that are needing knowledge of specific privileges, will query
> the filesystem. In case of user confirmation, the filesystem will
> trigger a special request through a special file.
> The special filesystem is currently implemented using FUSE.
> For blocking request, the overhead is minimised: only the level 2
> function 'access' is needed.
> To prove that my proposition is viable, I implemented a secure launcher
> using it: https://github.com/jobol/smaunch. That launcher
> using extended security attributes set the authorized privileges and use
> it to configure Smack rules and the file namespace.
> Using Smaunch, I found that the launch time of the process (either
> native or HTML5) is about 6.6ms:
> - launch of smaunch: 2.6 ms
> - reading DB: 0.6 ms
> - finding mount points (keyzen-fs and smackfs): 0.4 ms
> - setting permission (FUSE): 1.2 ms
> - setting smack and isolating file namespace: 1.8 ms
> Your feedback is welcome
> Best regards
> Jos? Bollo

More information about the Dev mailing list