Note: I don't use PolicyKit.<br><br>SELinux was devised to solve a different set of problems than PolicyKit apparently was. The default model in selinux is NO! Then judicious tears in the fabric of NO! are made to allow very specific functionality.<br>
<br>As selinux is a kernel level security layer, it provides system security model that is incredibly robust. As soon as the kernel is loaded, selinux is started and _then_ the device drivers are loaded and other services begin after that. So a compromised driver or service startup will not break fundamental system security.<br>
<br>PolicyKit works at the application layer and appears to provide a mechanism of customizable wrappers to allow non-admins to do admin tasks. <br><br>I'm an admin. I have the responsibility to make Linux systems do my bidding. Thanks to the design of *NIX (Thanks to Dennis Ritchie!!), there is very good separation between users and administrators. As a professional, I _really_ want that to not change much. I don't see a good outcome for Fred the receptionist formatting a disk or changing any password but his own. I certainly don't see any good reason for non-admins to add software to a system. They can add software to their own user-space already. SELinux will block them, by default, from using their space applications to further access system controls they are not authorized to have. PolicyKit will not stop a user compiled binary from accessing areas they should not have if they exploit a privilege-escalation hole. SELinux does.<br>
<br>Because of what SELinux does, it's hard. Very damn hard to wrap the head around. An admin doesn't need to know 300+ rules to be good with selinux. But the admin does need to know what tools to use and how to use them when issues arise. <br>
<br>I may have to do a training class in selinux policy manipulation for an ale meeting for all of this to make some sense. That will take several months for me to prepare so it can't happen soon.<br><br><div class="gmail_quote">
On Tue, Jan 31, 2012 at 9:02 AM, <a href="mailto:mike@trausch.us">mike@trausch.us</a> <span dir="ltr"><<a href="mailto:mike@trausch.us">mike@trausch.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">On 01/30/2012 10:12 PM, Jim Kinney wrote:<br>
> The capability you seek is in selinux not a hodgepodge of userland<br>
> config libraries.<br>
<br>
</div>I don’t like SELinux.<br>
<br>
No, that’s actually incorrect. I *HATE* SELinux. It is backwards from<br>
the way things should be controlled, though it is necessary when you<br>
have to control legacy applications with the kinds of access controls<br>
that SELinux provides.<br>
<br>
There are better ways to skin the cat, though.<br>
<br>
For example, with SELinux, you run unmodified software and you<br>
essentially tell it, “these are the files you’re allowed to touch, and<br>
that’s it”. You have to craft these rules for every process (or every<br>
user ID) on the system. The result is more rules than a single<br>
administrator can remember on a network of three nodes, and forget about<br>
300 nodes.<br>
<br>
Here is the intro to PolicyKit, from its Web site at <a href="http://freedesktop.org" target="_blank">freedesktop.org</a>:<br>
<br>
> PolicyKit is an application-level toolkit for defining and handling<br>
> the policy that allows unprivileged processes to speak to privileged<br>
> processes: It is a framework for centralizing the decision making<br>
> process with respect to granting access to privileged operations for<br>
> unprivileged applications. PolicyKit is specifically targeting<br>
> applications in rich desktop environments on multi-user UNIX-like<br>
> operating systems. It does not imply or rely on any exotic kernel<br>
> features.<br>
<br>
Now, the interesting part is that it is portable (runs on multiple<br>
kernels). It needs nothing unusual to get its work done, it is simply<br>
an intermediary between the privileged and the unprivileged.<br>
<br>
Furthermore, instead of the user having to possess a root password or<br>
whatever, they can authenticate to PolicyKit in whatever way the<br>
administrator sees fit. Often this means that the user needs to enter<br>
their own password, as if they were using the sudo program. However,<br>
the user never actually spawns the privileged process, and the user<br>
doesn’t actually directly interact with the spawned privileged process,<br>
either, as I understand it.<br>
<br>
Why is this better than, say, SELinux’s way of doing things? Because<br>
the application must be broken into components: the user interface, and<br>
a trusted, privileged component that can be easily audited and is not<br>
tied to the rest of the application. For example, the user has a<br>
workstation and is allowed to installed packages, but only if those<br>
packages are signed by an authority that the system considers to be<br>
trusted (e.g., the system administrator).<br>
<br>
Guess what? You can’t do that with SELinux.<br>
<br>
But you can with PolicyKit. Because you write a small program which<br>
PolicyKit can invoke over D-Bus. That program can authenticate the<br>
package before then calling the system’s package manager to install the<br>
package. This is a different type of access control altogether from the<br>
SELinux model.<br>
<br>
The SELinux model is concerned with MAC on files and devices coupled<br>
with copious amounts of auditing, in order to be able to fry anyone who<br>
didn’t have the administrative authority to do something but for<br>
whatever reason had the technical authority to do it.<br>
<br>
The PolicyKit model is concerned with very granular bits of, well,<br>
policy. Not, “Can Jim Kinney format /dev/sda1?” but instead “When is<br>
Jim Kinney allowed to format /dev/sda1?”. The answer to that is<br>
probably something along the lines of “When /dev/sda1 is not mounted,<br>
and /dev/sda1 is not listed as a system mount, and when /dev/sda1 is not<br>
otherwise in use.”<br>
<br>
They can probably even play together, if necessary in an environment.<br>
<br>
That said, I can see PolicyKit becoming something that I use regularly<br>
in my programming. It increases the auditability of code and it<br>
increases the confidence that I have that there are no coupling<br>
interdependencies, and it ensures that privileged code is separated by<br>
process and hardware protection boundaries. Plus it makes the<br>
privileged component simpler and easier to understand, and easier to<br>
make “obviously correct”. Seems to me that it is a good idea all the<br>
way around. Besides, who would rally against more clear design for<br>
programs?<br>
<br>
PolicyKit has been around for a little while now, but I only really got<br>
to be familiar with it about maybe six months ago. I have been wanting<br>
some system like it in Linux systems for ages. Really, the idea<br>
simplifies things and makes them more secure by default---which is the<br>
way to be, if you ask me.<br>
<div class="HOEnZb"><div class="h5"><br>
--- Mike<br>
<br>
--<br>
A man who reasons deliberately, manages it better after studying Logic<br>
than he could before, if he is sincere about it and has common sense.<br>
--- Carveth Read, “Logic”<br>
<br>
</div></div><br>_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>-- <br>James P. Kinney III<br><br>As long as the general population is passive, apathetic, diverted to
consumerism or hatred of the vulnerable, then the powerful can do as
they please, and those who survive will be left to contemplate the
outcome.<br>- <i><i><i><i>2011 Noam Chomsky<br><br><a href="http://heretothereideas.blogspot.com/" target="_blank">http://heretothereideas.blogspot.com/</a><br></i></i></i></i><br>