>On Fri, 19 Apr 2013 20:22:54 +0200
>"Niels Terp" <nielst...@comhem.se> wrote:
> 
> [snip]
> 
> I know that I am poking my face into a beehive here, and I am well
> aware of the dangers by logging in as root. It is possible on my SuSE
> system, and have never given me any problems. And I ALLWAYS have a
> backup of my system. So PLEASY tell me, how can I autostart KDE, and
> still log in as root ?

Words fail to express just how bad an idea this is. Yet, I must try.

The first and main problem, obviously, is that running as root destroys
the compartmenalization of your system. This compartmenalization is
critical to normal and RELIABLE system operation.

I won't spend more words on that problem, because there is a much
bigger problem here. It specifically has to do with KDE.

One word before I begin. I have never used KDE, in the sense that I
have never written a program that uses KDE. What follows has been pieced
together by reling on documentation and the general knowledge
regarding objects and object-based programing systems. While I may be
wrong regarding KDE, I am not wrong regarding the general idea.

KDE is object based. I am sure you and everione else reading this knows
what an object is. For the sake of those who don't, let me reiterate.
An "object" is a construct consisting of code and data. It has an
internal state. The state is held in the data. The code implements
functions. Some of these functions are public - other object can call
them - and some functions are private - only the object itself can call
them. As a rule, the only way to access an objects data is to call a
function in that object and let it return data to you.

KDE has something called Kparts. I think Kparts is the main
inter-process comunication method used, but I may be wrong. If I am
wrong, that would be very good. Kparts are objects. They ferry data
from one process to another. If I know this part correctly, the
undelying method by which this is done is by using shared memory to
contain said objects. So far so good. Now, application A uses Kparts to
send information to application B. A passes an object to B. The only
way for B to gain the data is to get it from within the object and
there is only one way to do this: to call a function within the object.

Let me reiterate: when objects are used for IPC (inter-process
comunication), the only way for the receiver to gain the passed data is
for it to execute the passed object.

The question now, ofcourse, is what happens if that function that
returns data is booby-traped to take over the receiving application?
There is no way for the receiving application to know what will happen
once it passes control to the object yet it has no other choice but to
do so.

Thus, objects used for IPC enable simple and easy process takeover.
Ultimately, there vulnerabilities are unprotectable.

Regarding your idea to log in to a KDE session as root... I hope I
don't have to go on explaining why is that such a bad idea. With the
system being completely de-compartmenalized, you will have no security
both from legitimate errors and mistakes and from any and all attacks.
And without being protected from errors and mistakes, you will not have
a reliable system.

One final word. While I may be wrong regarding Kparts and KDE, KDE is
not the only thing in existance which uses object-based IPC. I hear
GNOME also uses them, but the biggest culprit.. realy, the elephant in
the room that needs to be mentioned is Windows. If I read the
documentation right, all the way since 1991. (or some such) and the
adoption of COM, MS-DOS and Windows have used object-based IPC as their
workhorse. This is the number one problem of Windows. And it has gotten
worse over the years. The most recent SURE instance of this being used
that I could find is in the newest Windowses Power shell. One of the
key selling points for the Power shell is how the pipes are implemented
using object passing. The sales pitch goes on to elaborate how previous
versions of the Windows shell would serialize object before passing
them (serialization means that the data was extracted from the object
and passed alone) but the new Power shell passes object and thus
eliminates the cost of serialization and deserialization. In my mind,
the possibilities for abuse of that are endless.


-- 
You don't need an AI for a robot uprising.
Humans will do just fine.
                     --Skynet
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to