Hello Sorry on lag in answering to list.
I've been working on Cynara's API (that is BTW already published on wiki
page http://wiki.tizen.org/wiki/Security:Cynara#API_2).
There is only synchronous API designed for libCynara for now. I agree
that there is a need for asynchronous API and we are going to publish
one later. For now our priority is to get Cynara working with currently
published API.
I'll try to answer inline for rest.
W dniu 2014-04-14 11:44, José Bollo pisze:
On ven, 2014-04-11 at 16:42 +0000, Schaufler, Casey wrote:
-----Original Message-----
From: Dev [mailto:[email protected]] On Behalf Of José Bollo
Sent: Friday, April 11, 2014 8:19 AM
To: [email protected]
Cc: Lukasz Wojciechowski
Subject: Re: [Dev] Cynara (filesystem)
(snip)
1. The service providers HAVE TO request the security system
------------------------------------------------------------
What are the service providers?
- libraries (most probably shared) running in the client process context;
No. Libraries are not security elements in a Linux system.
There is nothing you can do in a library that you can't do
directly in the client code. There is no way for Cynara to tell
if the application is lying to it. You can certainly add Cynara
calls to a library, but it is pointless because any denial can
be circumvented.
You're right. I wasn't really warned of that, Thanks.
(snip)
I agree to Casey. We cannot help in case of library accessed resources.
Our goal is to provide trusted service (Cynara), that can be used by
services (implemented as processes not libraries) to check if some pair
{application + user} is allowed to reach a resource defined by a privilege.
- 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?
Sorry, you've just hit the security composition problem.
To the best of my knowledge no one has a solution.
The basic issue is that if you trust Fred with A and Wilma
with B you can’t say anything about the safety of A and B
when Fred and Wilma are in the same room.
I have to keep it in mind. Thanks again.
- What if a service provider doesn't checks the permission it HAVE to check?
Then we have a gap in the system. Hey, I think that application level
privilege is a really *bad* idea. Alas, you kids seem to think it is the
cat's pajamas and have written it into the specifications.
ACK
If provider already has access to some resource or is providing some
service, then it can share it with anyone. Of course it can use Cynara
to ask if it should, however is completely up to provider what it does.
We assume that system services are trusted. They work in system domain.
- 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.
Cynara isn't the same as polkit and we'd not be doing anyone favors
if they start to think it is. I know it is lots of work to create and propagate
a new open source project or to maintain patches for our own little thing.
Agreed.
Yes, we can probably think about it later, after we implement and
stabilize project.
2. The filesystem accesses ARE NOT targeted by Cynara
Right. They can't be. Cynara uses a different access control
model (application/service/resource) than the filesystem
(subject/object). There is no direct mapping from one model
to the other.
That would be good to have the feedback of Lukasz about that point.
These are two separate things. Cynara is capable only to check some
privileges. It does not change SMACK labels, rules. It does not define
groups etc. It is only responsible for giving simple answer for question
"is some user running some application allowed to use some privilege?"
and that all it does. Filesystem control is MAC/DAC responsibility not
Cynara's.
(snip)
From what I understand of Cynara, it also defines/uses a launcher. Then I
think that the launcher could configure the filesystem.
The launcher only needs to know the Smack label and UID to
set on the application. The service gets this information from
the IPC mechanism and gets the privilege information from
Cynara. It’s the application installer that has to work with Cynara.
I'm not sure that the UID and the Smack label are enough. More data is
needed to know what are the privileges of an application.
Cynara needs to know policies in order to properly check privileges when
asked. Someone has to gave it some. I believe that there will be many
processes that will need to change set of Cynara policies:
* installer (it reads manifests and knowns what application wants to use
what privileges)
* privilege-manager (it certainly has to access Cynara policies to make
some user demand restrictions)
* user adding/removing/managing (every user created has a list of
applications that [s]he ca run and a set of privileges that [s]he can use)
In Cynara we have two interfaces:
* one for checking privileges - open for everybody (or almost) -
accessed by libCynara
* second for playing with Cynara policies
The 2nd one should be used only by a trusted application. I believe here
is a need for a 2nd service to take care a CynaraAdmin role.
Cynara is design to be completely generic. There are no Tizen relations
in its API. CynaraAdmin service needs to give provide API specific to
Tizen distribution taht will be used for:
* managing policies
* managing users
* application installation processes
* application launchers
It shall be an extended service version of current libprivilege-control
API. This will be Tizen specific.
It will be responsible for setting SMACK labels on directories and files
during installation, proper privileges dropping (setuid, etc) during
application launch
and among all these things it will also set proper policy rules in Cynara.
@Jose: Why do You think that SMACK label user's UID and privilege name
are not enough to check access? Maybe You can provide an example?
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
We'll certainly look more at this proposal.
Great! Let me insist here on the fact that this solution let the kernel
check all filesystem accesses with no time overhead. Besides, it allows
to make redirections depending of the possibilities of the platform for
removable media and the support of multi-users.
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?
Cynara isn't in the launcher. It's in the installer and services.
Yes, it's a whole. But without a launch step, my filesystem control
mechanism would not work.
Launching code should be used by launcher. It is out of Cynara's scope.
Best regards
José
Best regards
Lukasz
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
