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

José Bollo jose.bollo at open.eurogiciel.org
Mon Apr 28 09:10:35 GMT 2014


On lun, 2014-04-28 at 10:30 +0200, Łukasz Stelmach wrote:
> It was <2014-04-25 pią 18:11>, when Lukasz Wojciechowski wrote:
> > Date: Thu, 24 Apr 2014 11:49:33 +0200
> > From: José Bollo <jobol at nonadev.net>
> > Message-ID: <1398332973.4522.48.camel at intel06.vannes>
> >>
> >> 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
> 
> I don't expect much from FUSE performancewise.

Hi Łukasz,

I agree that the performances of FUSE aren't so good.

It has the big advantage to allow fast progress and evaluations. If
performance are really to be improved a keyzen kernel module could
replace it.

> >> - it could be linked tightly to LSM smack
> 
> If done in kernel which.

Agreed too. 

The advantage of linking it to the LSM SMACK would be that it would able
keyzen to follow forks allowing it to make inherit keys. Anyway, it is
not required by Cynara that isn't tracking processes but applications. 

> >> - it benefits of accesses control (DAC/MAC) and file namespace
> 
> I am afraid that the concept of privileges poorly maps to DAC/MAC
> models.

Yes, There is no mix between permissions and MAC/DAC in my mind. Here
DAC/MAC is only for filtering accesses to the parts of the keyzen
filesystem as in the procfs: a process can't read or exam the content of
a directory if it hasn't the right to then the idea is that it can't
read or query the permissions of some other processes (well still have
to be coded in details, not in the proof of concept).

Best regards
José

> >> 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.
> >>
> [...]
> > 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
> 
> Please remember that you do not need to "create" groups actually to use
> them. Groups are just integers and you can use all integers available
> for the system as group ids. What you refer to as "creating groups" is
> adding mappings between names and numbers in some database
> (e.g. /etc/groups). Do you need such mappings?
> 
> [...]
> 
> >
> > 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.
> 
> Why would bind-mounts not work?
> 
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev




More information about the Dev mailing list