[ale] why I love windows

[mike at trausch.us]

On 01/31/2012 10:21 AM, Jim Kinney wrote:
> Note: I don't use PolicyKit.
> 
> 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.

PolicyKit has the same sort of philosophy, but it is not restricted to
the notion of users and files.  It can take into account anything it
desires; for example, time-of-day and need-to-access based on any sort
of criteria that can be implemented in code.

> 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.
>
> PolicyKit works at the application layer and appears to provide a
> mechanism of customizable wrappers to allow non-admins to do admin tasks.

Applications that use PolicyKit leverage the kernel’s protections (and
as a side effect, the protections that hardware offers) as well.  The
difference being that the role of the kernel is then confined to keeping
users in their own (lack of) privilege space.

> 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.

No, Fred the receptionist has no need for that.

Frank the support desk intern could use it, though, and the system could
automatically take protective actions against a naïve intern by making
it possible for a full administrator later to un-do what the intern did,
for example.

> 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.

Programmer’s workstations are one good example; large organizations such
as IBM where complex systems have been designed to allow
non-administrators to install software would be another good use case.
ISSI (I think that’s the name, if I recall) is a good example of
something that could stand to benefit from having something like
PolicyKit.  Instead, what ISSI did was to essentially implement
something like PolicyKit, by having Windows services that can do things
on behalf of the user if the user is allowed to do the thing by ISSI
(but of course, the OS is configured to disallow the user to perform the
action directly).

> 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.

I am quite sure that SELinux has bugs, too.  ;-)

That said, privilege escalation bugs are among the quickest-closed bugs
in the kernel.  The last one I actually paid attention to closely was
closed within an hour of its discovery, and a new kernel release was
rolled within a few hours after that.  It’s not like we’re running
Windows NT here... :^)

> 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.

And, at least if my experience is any indication, the system
administrator has to wear a programmer’s hat every now and again in
order to fix things that break violently when constrained.  The model of
PolicyKit is such that it is (a) opt-in and (b) enables full separation
between components, because they are not even linked together.  Users
play in their own sandboxes, and that’s that.

I imagine that if PolicyKit and SELinux were configured to work together
(e.g., SELinux were configured to say “Thou shalt not touch any unowned
resource” and “Thou shalt be allowed to use PolicyKit” to the users,
then you could [essentially] have a hardened kernel worry about exploits
as you described above, and let PolicyKit handle the administrative
tasks on behalf of whoever is allowed to invoke them.)

In other words, “administrators” are defined organizationally, and that
organizational template can be applied to PolicyKit to grant very
fine-grained administrative rights to the people who are allowed to
exercise them.  For that matter, if (and yes, I know that this is
unrealistic now and possibly for always) everything were re-written to
do things with PolicyKit, it could enable far more flexible technical
support infrastructures than we have today.  Instead of saying “Foo can
collect a dump of memory from a process using sudo”, one can say “Foo
can collect a dump of memory from these particular types of processes
and only when they are running in the context of certain particular
users”; because it is in userspace, it can implement literally any
policy it wants.

> 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.

I would be very interested in seeing this.  The last time you spoke on
SELinux I was very confused.  :-)

And no, I am not saying that SELinux is bad.  I just dislike it and I
don't use it.  For that matter, I do not use AppArmor either, for much
the same reason; it gets in the way, particularly on an average workstation.

Ultimately, I would like a system that enables me to do certain things
without having to elevate my own privileges.  There is (to my knowledge)
absolutely nothing to stop a program lurking in my userspace from
starting up in the window system and watching for me to gain root access
in a terminal window to do nasty things before I can stop it.

But if I were allowed to “aptitude update && aptitude safe-upgrade” or
“emerge --sync && emerge -DNua world” without invoking root privilege,
by having helpers go and request that backends kick in and do their
jobs, then I never have to run “sudo” or become root.  I can just type
the commands and if I have the permission to run them, the backend will
start up for me; if I do not have the permission to run them, the
backend will return a permission denied error.  And all the while,
nothing can lurk in my window system and try to take advantage of a root
shell while it’s in a terminal window.

	--- 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/5e433216/attachment-0001.bin