:: Re: [DNG] Linux 4.4 and KMS
Forside
Slet denne besked
Besvar denne besked
Skribent: Rainer Weikusat
Dato:  
Til: dng
Emne: Re: [DNG] Linux 4.4 and KMS
Edward Bartolo <edbarx@???> writes:

[Running X as root]

> Eh, root is dangerous... Users should never ever use root: there are
> other safer alternatives to that, like many modern Operating Systems
> ,like for example, Windows, Android, OSX. They all think for
> themselves,


[...]

While I understand the point, I was up to something different: Assuming
there's an exploitable bug in the X server, this might enable an
untrusted, local user with good C programming skills to gain root
access.

But do you have such user on your system? Or do you run publically
accessible, unprivileged servers on it which might enable someone one
the net to become a de-facto untrusted local user? For most people, the
answer will be 2x "No", hence, that's not a problem they'd have to worry
about.

Assuming 'untrusted local users with considerable C programming skills'
do exist, is the fact that "X runs as root" in itself problematic? The
answer to that is "it isn't". If X has exploitable bugs and it runs as
root, someone exploiting such a bug could elevate his privileges. The
sensible cause of action to prevent that is not to "de-privilege" the X
server (or some other, random program) but to audit the code for
possibly exploitable errors and fix them. "But that's such a HUGE body
of code and it's SOO old and neither we nor you no much (if anything)
ofc it, aren't you terribly afraid because of that?" is - at worst - FUD
and at best, an attempt to create a false sense of security by
hand-waiving: systemd is also a huge body of code, as opposed to X, it
hasn't been used in hostile circumstances for a few decades, it does run
with privileges and there's no special magic in this code which would
make it error proof. And then, there's the kernel, and even larger and
even more privileged body of code and it even talks to the network. And
again, no 'special magic' makes it bulletproof.

There's obviously a double-standard applied here where "nice programs"
are supposed to be maintained by finding and fixing bugs in them while
"not-so-nice programs" are to be crucified "just in case they deserver
that".