<div dir="ltr">On Tue, Aug 5, 2008 at 5:29 AM, Markku Savela <span dir="ltr"><<a href="mailto:msa@moth.iki.fi">msa@moth.iki.fi</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>...which is more targeted for a desktop and defining the access rights<br>
again based on UID's. And the checking solution involves heavy<br>
operations using setgid helper programs to access the "hidden"<br>
permission database.</blockquote><div><br>Right, PolicyKit is for defining "coarse" access control; but if you need high performance, one option might be to have a PolicyKit mechanism which hands back the path to a direct unix domain socket.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I was thinking about a solution, where "permission tokens" are<br>
preloaded into the process context at the start (by a privileged<br>
application starter, which controls the policy), and use dynamically<br>
generated group id's as permission tokens.</blockquote><div><br>I'm not sure we can control all of the ways in which applications get launched very easily. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Checking access rights of a client in the server would simply reduce<br>
to verifying that the client process context has the required<br>
permission token (group identifier). The DBUS modification comes into<br>
picture, because many services are behind a DBUS messages and I want<br>
first solution that would not require any changes into server<br>
implementations.<br>
<br>
Of course, some services can do the check themselves. [However, I<br>
surely wish that DBus daemon would pass the client PID automatically<br>
in every message -- getting it via separate DBus query causes lot of<br>
extra work per service call]<br><div class="Ih2E3d"></div></blockquote><div><br>That's possible. More generally we could pass the "credentials" along with a message, including the SELinux security context for example.<br>
<br>But again I think that the pattern of having an access-controlled method which gives you a token to access a separate high-performance channel makes sense if you really need high performance.<br><br>DBus itself is not designed with performance as the #1 goal.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
> You'd have to describe more of what the problem you're trying to<br>
> solve is for me to advise; but if your system has a targeted<br>
> profile, SELinux gives you very strong controls over the entire<br>
> system security. The policy language allows you to define which<br>
> programs can communicate over the system and session bus.<br>
<br>
</div>SELinux is an option, but the configuration is scary. Especially, if<br>
the goal is to allow an installed service daemon to specify own<br>
permisson tokens for the services. </blockquote><div><br>Part of the realization driven by SELinux is that security really *is* a whole-system concept; you can't look at individual things in isolation.<br><br></div></div>
</div>