PolicyKit versus SELinux and PAM

Stachu 'Dozzie' K. wrote:
> On 14.11.2007, Wayne <nospam.DeleteThis@all4me.invalid> wrote:
>> It isn't clear how PolicyKit will be "better" than SELinux
>> or PAM.
>
> Stop here. Now go and read about SELinux, PAM and PolicyKit. First of
> all, what it is and what is it designed for. Otherwise you will say
> nonsenses like "PAM is better/worse than SELinux" or "SELinux is
> better/worse than PK". They are uncomparable as they do essentially
> different things.
>
> [...]
>> What am I missing?
>
> The main ideas behind all three systems.
>

I may be missing the point, but I have read about these before posting.
PolicyKit claims to solve problems with sudo, groups, PAM. Here's
the link:

http://hal.freedesktop.org/docs/PolicyKit/intro-define-problem.html

But after reading most of the PolicyKit reference, it seems like
PolicyKit is just adding another policy DB, this one pretty much
designed so KDE/Gnome developers can set policy for applications
that run in those environments, but that the GUI developers don't
control.

The closest I can see is that PolicyKit is intended as a replacement
for sudo, but will work "better" in some sense, e.g., less privilege
needed, more authentication options. However the designers claim
PAM and these other security subsystem are flawed in some way. That
leads me to think the PolicyKit developers see it as a possible
replacement for some of what is currently done in these other ways.

And you are right that SELinux and PAM are fundamentally different
systems for different things. But the PK docs mention SELinux
and PAM, so I was wondering how PolicyKit compares with each:

While all three security subsystems have different focuses, there
is some overlap. For example: "dd if=/dev/fd0 ..." could have
permission blocked or permitted independently by SELinux rules,
PAM (pam_console), group membership (Debian), and apparently by
PolicyKit too. And while there is no conflit with SELinux rules
(which can always deny access even if permitted by the other
security mechanisms and subsystems), PAM, plugdev group, or
sudo could be configured to allow access while the PolicyKit
rules deny it. So a PAMified app may work while a PK-ified one
may not. That's what I mean by overlap and conflict.

So I think my question is valid. How does PolicyKit make system
administration any easier by adding yet another policy DB?
How does it make application authoring easier, which will
apparently use the PolicyKit API as a replacement for the PAM API
in many applications? About the only folks who benefit are
the (GUI) framework developers. And of course the end user may
have faster / easier privilege escalation than by waiting for
some admin to update a DB, or by having to launch apps with sudo.

-Wayne

PolicyKit is not something that could replace neither LinuxPAM nor
SELinux. Let's say, its complimentary application-level access control
system... Not more. By the way it's pretty raw and still not normally
supported in KDE. When I faced problem of hardening my LFS I decided
that it would be more rational to configure LinuxPAM properly. By the
way I'm not sure polkit could work without PAM.