[ale] why I love windows

mike at trausch.us mike at trausch.us
Tue Jan 31 09:02:53 EST 2012


On 01/30/2012 10:12 PM, Jim Kinney wrote:
> The capability you seek is in selinux not a hodgepodge of userland 
> config libraries.

I don’t like SELinux.

No, that’s actually incorrect.  I *HATE* SELinux.  It is backwards from
the way things should be controlled, though it is necessary when you
have to control legacy applications with the kinds of access controls
that SELinux provides.

There are better ways to skin the cat, though.

For example, with SELinux, you run unmodified software and you
essentially tell it, “these are the files you’re allowed to touch, and
that’s it”.  You have to craft these rules for every process (or every
user ID) on the system.  The result is more rules than a single
administrator can remember on a network of three nodes, and forget about
300 nodes.

Here is the intro to PolicyKit, from its Web site at freedesktop.org:

> PolicyKit is an application-level toolkit for defining and handling
> the policy that allows unprivileged processes to speak to privileged
> processes: It is a framework for centralizing the decision making
> process with respect to granting access to privileged operations for
> unprivileged applications. PolicyKit is specifically targeting
> applications in rich desktop environments on multi-user UNIX-like
> operating systems. It does not imply or rely on any exotic kernel
> features.

Now, the interesting part is that it is portable (runs on multiple
kernels).  It needs nothing unusual to get its work done, it is simply
an intermediary between the privileged and the unprivileged.

Furthermore, instead of the user having to possess a root password or
whatever, they can authenticate to PolicyKit in whatever way the
administrator sees fit.  Often this means that the user needs to enter
their own password, as if they were using the sudo program.  However,
the user never actually spawns the privileged process, and the user
doesn’t actually directly interact with the spawned privileged process,
either, as I understand it.

Why is this better than, say, SELinux’s way of doing things?  Because
the application must be broken into components: the user interface, and
a trusted, privileged component that can be easily audited and is not
tied to the rest of the application.  For example, the user has a
workstation and is allowed to installed packages, but only if those
packages are signed by an authority that the system considers to be
trusted (e.g., the system administrator).

Guess what?  You can’t do that with SELinux.

But you can with PolicyKit.  Because you write a small program which
PolicyKit can invoke over D-Bus.  That program can authenticate the
package before then calling the system’s package manager to install the
package.  This is a different type of access control altogether from the
SELinux model.

The SELinux model is concerned with MAC on files and devices coupled
with copious amounts of auditing, in order to be able to fry anyone who
didn’t have the administrative authority to do something but for
whatever reason had the technical authority to do it.

The PolicyKit model is concerned with very granular bits of, well,
policy.  Not, “Can Jim Kinney format /dev/sda1?” but instead “When is
Jim Kinney allowed to format /dev/sda1?”.  The answer to that is
probably something along the lines of “When /dev/sda1 is not mounted,
and /dev/sda1 is not listed as a system mount, and when /dev/sda1 is not
otherwise in use.”

They can probably even play together, if necessary in an environment.

That said, I can see PolicyKit becoming something that I use regularly
in my programming.  It increases the auditability of code and it
increases the confidence that I have that there are no coupling
interdependencies, and it ensures that privileged code is separated by
process and hardware protection boundaries.  Plus it makes the
privileged component simpler and easier to understand, and easier to
make “obviously correct”.  Seems to me that it is a good idea all the
way around.  Besides, who would rally against more clear design for
programs?

PolicyKit has been around for a little while now, but I only really got
to be familiar with it about maybe six months ago.  I have been wanting
some system like it in Linux systems for ages.  Really, the idea
simplifies things and makes them more secure by default---which is the
way to be, if you ask me.

	--- Mike

-- 
A man who reasons deliberately, manages it better after studying Logic
than he could before, if he is sincere about it and has common sense.
                                   --- Carveth Read, “Logic”

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 729 bytes
Desc: OpenPGP digital signature
Url : http://mail.ale.org/pipermail/ale/attachments/20120131/10656cc4/attachment.bin 


More information about the Ale mailing list