[ale] why I love windows

[mike at trausch.us]

On 01/31/2012 10:09 AM, Brian Mathis wrote:
> 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.

That said, without SELinux, it is possible to do the same thing by
separating an application into components of privilege and
non-privilege.  Note that we’re not even necessarily talking about
“system administration”; the “privileged” component can be anything that
the user is not allowed to do directly.  This enables applications to be
written in a manner that removes the ability to take advantage of many
different types of exploits.

For example, imagine a network application used to manage time clocks.
Such an application can communicate over the network to a system that is
append-only (or, in terms of SQL, only allowing INSERTs as opposed to
also allowing UPDATEs).  Now imagine that an employee has entered the
wrong time, and somehow they have put 10 hours on a day that they did
not work at all.  An application administrator would be able to take
care of that by properly correcting the record with an audit trail.

One way to ensure that this is the case is to separate the code base.
Place the privileged operation (modifying records) behind a PolicyKit
policy which calls a privileged component that ensures that an audit
record is created, ensures that a reason for the modification is
present, and then performs the modification itself.  Therefore, the main
application server can now use a user ID to connect to the database such
that it is only allowed to INSERT and SELECT records, and the privileged
component would use a separate user ID to connect to the database and be
allowed to UPDATE records.

The privileged component would be much smaller than the application
server itself, so it is easier to audit for correctness.

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

I am certainly not saying that.  Heck, most current situations can be
addressed by application-level or kernel-level privilege constraints
already, using relatively standard models.  What PolicyKit is there for
is to ensure that it is possible to do relatively complex things without
placing a significant burden on the system administrators to be able to
ensure that those rules are being followed.

Software in today’s world is complex.  We have no way to trust every
single line of code that is executed on our systems.  But if we run most
code with the minimum level of required privilege (e.g., give users no
permissions from the kernel’s point of view) and only write small chunks
of code that do the things they are intended to do, this enables
administrators to say “I trust this system” with greater confidence than
is otherwise possible.

	--- 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/2d0b3f04/attachment.bin