[Dev] Cynara (filesystem)
jose.bollo at open.eurogiciel.org
Fri Apr 11 15:18:50 GMT 2014
On mar, 2014-04-08 at 20:57 +0200, Lukasz Wojciechowski wrote:
> Services that are being used by applications need to control if the
> caller has sufficient privileges to call each API. In Tizen 2.2.X this
> level of access control was done using very detailed Smack policy on IPC
> mechanisms. Since Tizen 3.0 is introducing compact 3-domain Smack
> policy, there is a need for user-space mechanism that complements the
> solution. This is a place for new module - Cynara.
> Details can be found at wiki page:
> Page is still being constructed, but is is high time to share and
> probably start a discussion.
> I will be glad to answer any questions about it.
> I plan to publish roadmap for Cynara development and API draft this week.
Hi Lukasz, Hi Gagarin, Hi all,
I want to come back on the main topic.
The proposal Cynara is IMHO going the good way. But I have at least two
1. the service providers HAVE TO request the security system;
2. the filesystem accesses ARE NOT targeted by Cynara.
1. The service providers HAVE TO request the security system
What are the service providers?
- libraries (most probably shared) running in the client process
- Unix socket domain services;
- DBUS services.
In all this cases, the service is able to retrieve the client PID. That
is what is detailed here
That PID is used to check the permissions using some library.
For me that is good enough and we can go on with that. (That is really
better than trusting clients to check for there permissions;) But:
- What if a malicious application A having accesses to permissions P is
mediating acceses to P for a third application B? That may be the case
via filesystem or via message port when application are sharing a same
certification. It may happen, we have to know that. I don't think that
we can avoid such mechanisms. Any idea?
- What if a service provider doesn't checks the permission it HAVE to
- As wrote Patrick Ohly, checking permission is a Tizen requirement
that have to deal with upstream projects. Patrick wrote about a stub
between Cynara and Polkit. I think that there is a need to define the
process that Tizen will follow about that point.
2. The filesystem accesses ARE NOT targeted by Cynara
Here again, Patrick was the first to point it out.
That is a real important point specially for native applications (if
natives or hybrid applications are still in the scope) because libc
doesn't check that a open is allowed and it will never do that.
Smack ensures the system integrity/security and is the backbone of
security but it can't go into the details of all the permissions. It
shouldn't also pollute the file system with tons of labels, making it
difficult to admin without super powers.
Then now, the biggest problem isn't the security but the PRIVACY. To
ensure it, there is a need to restrict the accesses to the filesystem of
the applications, depending on their permissions:
- any application has access to system parts of the filesystem (here
restrictions are set using DAC and sMACk)
- some applications will only see their data
- some application will see their data and some data shared on a
- some application will have access to shared data of the user
- some application will have access to all data of the user
- some application will have access to all shared data of all users
- some application will have full access to the filesystem
>From what I understand of Cynara, it also defines/uses a launcher. Then
I think that the launcher could configure the filesystem.
I proposed a smack aware launcher that(**see post scriptum**):
- restricts the the smack accesses of the launched applications
depending on their permission
- restricts the filesystem accesses of the launched applications
depending on their permission
>From my experiments, adapting the filesystem to the need of the security
is taking only little time, less than 1ms (I didn't tried on ARM). Then
why to not add it to Cynara, its specifications, its API? Agreed?
post-scriptum: The last version of smaunch (proof of concept) now
integrate keyzen the manager of permission keys (proof of concept).
Taking smaunch and keyzen together is implementing a kind of cynara
(yes it really look like and it really works but is a proof of concept).
Details will follow. If curious, check https://github.com/jobol/keyzen
More information about the Dev