[Dev] enforcing priviliges of web apps (was: Re: New Tizen Bluetooth Framwork (NTB) wiki page)

Kis, Zoltan zoltan.kis at intel.com
Wed May 14 07:33:02 GMT 2014


On Wed, May 14, 2014 at 9:53 AM, Patrick Ohly <patrick.ohly at intel.com> wrote:
> On Wed, 2014-05-14 at 00:51 +0300, Kis, Zoltan wrote:
>> In this model, native apps could also access the platform DBUS
>> interfaces, and security needs to be enforced e.g. in the DBUS daemon
>> (by assumed Cynara extensions to the dbus daemon).
>
> When you say "the dbus daemon", do you mean the /usr/bin/dbus-daemon or
> the D-Bus service providing a certain interface?

/usr/bin/dbus-daemon

>
> In the current Cynara model, the dbus-daemon was meant to be unchanged,
> ie. would not call Cynara. There are the Smack-aware access controls,
> but as far as I understand those controls, they are too static and/or
> hard to manage once apps with different Smack rules and manifests get
> installed.
>
> Cynara augments static Smack rules with runtime checks in user space.
> For this to work, each individual D-Bus service has to call Cynara.

Or, the dbus-daemon (and all other security enforcement points) has to
run the run-time checks.

>
> We cannot count on all D-Bus services doing this properly, so the system
> default for unmodified upstream D-Bus services has to be "User resp.
> System domain can access them, apps can't". But even in such a system,
> the session D-Bus must be accessible by all apps, because the
> Cynara-aware services there will have to be accessible to apps.

Yes, once/if we have a secure mechanism to access DBUS (by apps
fulfilling the conditions of policy), it is a generic/widely available
mechanism.

>
>> The main drawback here is the need to map every single platform
>> functionality to a new API, and then which API? The C API? OSP/C++?
>> ASD IDL->C++? An intermediate 'mother of all' API to which all
>> previous are mapped? Looks very idealistic/irrealistic to me, given
>> the limited time and resources we have. Also, the optimal process
>> model of the service proxy is not clear.
>
> I share these concerns.
>
> The way I see it, we need three options and the ability to choose on a
> case-by-case basis:
>      1. Proxy daemon where the API is clear.
>      2. D-Bus rule-based filtering (with the current Smack support).
>      3. Cynara called by D-Bus services.
>
> Perhaps there's a forth option:
>
>  4. Cynara called by dbus-daemon, based on service configuration.
>
> The advantage of option 4 over 3 is that we don't need to touch the many
> entry points into upstream services. However, it depends on Cynara
> behaving well inside the dbus-daemon event loop - blocking synchronous
> calls definitely will be a showstopper there. It also won't work well
> with kdbus.

In my view (may be wrong and I expect security people to correct me)
we may be able to solve that.
What we need is to have the runtime checks in one or more security
enforcement points.
One of those is the dbus-daemon, but there may be others, e.g.
crosswalk extensions (in one of the models), a security proxy daemon
for platform libraries, etc.

Now I see there may be a problem if those runtime checks are run in
the same process memory as the app, since a malicious app could use
tricks to access/modify that code. Therefore the generic solution
cannot really be a library doing the runtime security checks from the
same virtual memory space in which the app is running, and therefore
has to be separated by process boundary enforced by the kernel.

However, in the case of crosswalk extensions, the platform facing
functionality runs in a different process than the app itself.
dbus-daemon obviously is also a process. The security proxy too. So
for all the security enforcement points so far we could actually use a
library doing the security checks.

Then, the rules based on which the checks are done, could be local to
the enforcement points, and updated by Cynara when there is a change.
In that way, the enforcement points could make local decisions, and
the synchronous calls would also work.

Since I am no security expert, all the above is IMHO, needing
check/confirmation.

Best regards,
Zoltan

>
> Also note that we need 2 for 3 to be secure. Apps must be able to send
> method call messages and receive their replies and signals, but they
> must not be allowed to see anything going via the bus which they don't
> have access to. This needs to be controlled by dbus-daemon; it's outside
> of the control of Cynara-aware services.
>
> Can some security expert please take the AR to investigate how option 2
> with a secure default (apps cannot talk to services and will not receive
> any signals) and exceptions (for Cynara-aware services) can be
> implemented?
>
> If this is not possible, then the only remaining alternative is to
> prevent apps from accessing any D-Bus session (user or system) and
> implement the proxy approach for certain APIs. This is probably not good
> enough for IVI.
>
> --
> Best Regards, Patrick Ohly
>
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
>
>
>


More information about the Dev mailing list