If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Linux Desktop Security Could Be A Whole Lot Better

05-23-2013, 10:40 PM

Phoronix: Linux Desktop Security Could Be A Whole Lot Better

The security researcher that uncovered a host of X.Org security issues went beyond just evaluating the X.Org libraries and looked at other Linux desktop packages too. There's many security-related bugs outstanding within the Linux desktop ecosystem and Ilja van Sprundel believes "things could be better by several orders of magnitude."..

Comment

the consolekit security problem related to the lack of the revoke() syscall is still there right.

Consolekit was depreciated for logind, which is a part of the systemd suite.

For the record, Policykit was also abandoned, it was forked into Polkit by the same developers. It was forked because they wanted to break and couldnt do it with PolicyKit, so they just made a new project and told everyone to migrate at their convenience.

Post a message to Lennart's blog or the systemd-devel mailing list and ask them if it was worked around or if they dont hit that problem. Its very possible 1) That problem was inherit to consolekit's design, 2) a non-issue by logind's design 3) worked around in logind 4) Still ongoing.

The point we were trying to make was: Consolekit will NEVER get fixed in that regard, because its a dead project.

Comment

Again people, linux is invulnerable. That guy is probably a Microsoft paid evil monster paid to divide and conquer us! But we shall not fall for the faith is strong in us! Linux cannot be broken! Do not listen to this Judas!

I know it was meant as sarcasm, but in fact it points to a real problem. One should be thankful about people pointing out flaws, but the natural reaction is often to try to deny them or to "shoot the messenger". There is a big difference between FUD and real security warnings, but for the casual observer it can be difficult to distinguish the two.

Comment

I know it was meant as sarcasm, but in fact it points to a real problem. One should be thankful about people pointing out flaws, but the natural reaction is often to try to deny them or to "shoot the messenger". There is a big difference between FUD and real security warnings, but for the casual observer it can be difficult to distinguish the two.

Agreed. This is temporary bad news, but in the long term it is good news. It's nice to have some more expert auditing, and it should help the security of our desktops overall.

Beware! Much of this code is untested!
Someday, we will have a test suite and everything will be just fine.

Yes, they say a bit about security, and there is some validity to complaints about glibc bloat and dynamic linking (I've seen a dietlibc proponent claim that the fact that libnss is dynamic allows manipulation of the environment to have uncontrollable effects, which is accurate if you know what LD_LIBRARY_PATH and LD_PRELOAD can do...), but...for reasons best expressed in the first two links and that last quote, use anything but dietlibc.

uClibc is reasonably tested, musl is reasonably clean and well-audited, klibc is fairly bug-free (and also feature-free, unfortunately), bionic and variants have a measure of support and testing thanks to Google, newlibc has testing and support from RedHat.

I should mention that one reason for musl being developed was to provide a lightweight and correct libc with a stable ABI; the ABI is the big downfall for most alternatives.