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

Schaufler, Casey casey.schaufler at intel.com
Mon Apr 28 15:11:08 GMT 2014


> -----Original Message-----
> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Lukasz
> Stelmach
> Sent: Monday, April 28, 2014 1:31 AM
> To: Lukasz Wojciechowski
> Cc: dev at lists.tizen.org
> Subject: Re: [Dev] Simplifying access to a privilege manager using a virtual
> filesystem
> 
> 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.

Fuse has locking issues with both Smack and SELinux as well. Don't use fuse.
 
> >> - it could be linked tightly to LSM smack

What do you mean by this?


> If done in kernel which.
> 
> >> - it benefits of accesses control (DAC/MAC) and file namespace
> 
> I am afraid that the concept of privileges poorly maps to DAC/MAC models.
> 
> >> 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?
> 
> --
> Łukasz Stelmach
> Samsung R&D Institute Poland
> Samsung Electronics


More information about the Dev mailing list