Hello Lukasz, see below
On ven, 2014-04-25 at 18:11 +0200, Lukasz Wojciechowski wrote:
> Hello
> 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
Setting restriction on a user basis is really easy (go-rwx) and is
enough.
> 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.
The implication of using keyzen inside containers hasn't been studied
currently. Containers are very specials and can isolate and/or share.
Then they could also share part of filesystems or we can also remount
keyzen for the container. What is for you a problem seems to be in fact
an advantage. Remains the problem of UID, GID, PID that can be
differents. I dont think that this problem is solved by IPC being in
separate containers.
>
> 3. types of policies
> Proposed model describes policies as relations between privileges (files
> with prefix defining policy_type) for different processes:
> /tmp/keyzen/{PROCESS}/{PRIVILEGE}
> 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).
Did you intended to write /tmp/keyzen/{APPID}/{UID}/{PRIVILEGE}
or /tmp/keyzen/{UID}/{APPID}/{PRIVILEGE} ?
I have no special reason to include UID in keyzen.
But I have good reasons to mind about possible compatibility between
keyzen and Cynara. Cynara is keeping permissions based on AppId/Uid.
Then here the good solution would be to implement the
hierarchy /tmp/keyzen/{UID}/{APPID}/{PRIVILEGE} and to add
a directory /tmp/keyzen/default/{APPID} to get the default privileges of
applications. It will be obvious to create links
from/tmp/keyzen/{UID}/{APPID}/ to /tmp/keyzen/default/{APPID} if it make
sense.
>
> 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.
I mean that for most of the languages, the functions needed to query or
use keyzen are already implemented as part of the language standard
library: opening a file, reading it, removing it, getting a directory
contents are already implemented. Then adding facilities to access
keyzen subsystem is obvious and doesn't either need to implement a
protocol nor to link with a tuned library.
>
> 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.
All of these questions are open except one: keyzen isn't a replacement
for Cynara. But if it can contribute to make cynara better then I will
be happy.
Best regards
José
> Best wishes
> Łukasz Wojciechowski
>
> > Date: Thu, 24 Apr 2014 11:49:33 +0200
> > From: Jos? Bollo <jo...@nonadev.net>
> > To: "dev@lists.tizen.org" <dev@lists.tizen.org>
> > Subject: [Dev] Simplifying access to a privilege manager using a
> > virtual filesystem
> > Message-ID: <1398332973.4522.48.camel@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
>
> _______________________________________________
> Dev mailing list
> Dev@lists.tizen.org
> https://lists.tizen.org/listinfo/dev
_______________________________________________
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev
