[ale] why I love windows

[Brian Mathis]

On Tue, Jan 31, 2012 at 9:02 AM, mike at trausch.us <mike at trausch.us> wrote:
> 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


I don't think most people like SElinux, which is why most people
usually disable it, but SElinux and PolicyKit target completely
different things.  The point of SElinux is to enforce protection from
the kernel, outside of the application, because developers cannot
write bug-free code, and many simply cannot seem to understand most
security concepts.

If a developer uses a framework like PolicyKit, that's great, but
there are millions of apps already written that don't use anything
like that, and it would be naive to say that you shouldn't use those
apps until they are rewritten.


❧ Brian Mathis