Page 1 of 5 123 ... LastLast
Results 1 to 10 of 41

Thread: Linux Desktop Security Could Be A Whole Lot Better

  1. #1
    Join Date
    Jan 2007
    Posts
    14,808

    Default Linux Desktop Security Could Be A Whole Lot Better

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

    http://www.phoronix.com/vr.php?view=MTM3ODA

  2. #2
    Join Date
    Nov 2011
    Posts
    353

    Default

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

  3. #3
    Join Date
    May 2010
    Posts
    684

    Default

    Quote Originally Posted by garegin View Post
    the consolekit security problem related to the lack of the revoke() syscall is still there right.
    consolekit has been unmaintained for a while anyway, doesn't suprise me that it has security holes. Distros should switch to systemd/logind

  4. #4
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,891

    Default

    Quote Originally Posted by garegin View Post
    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.

  5. #5
    Join Date
    Nov 2011
    Posts
    353

    Default

    so for all intents and purposes, modern distros don't have that problem i'm talking about? how was it fixed without having the revoke() call?
    this is the video where the problem is described

    http://www.youtube.com/watch?v=ZTdUm...layer_embedded

  6. #6
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,891

    Default

    Quote Originally Posted by garegin View Post
    so for all intents and purposes, modern distros don't have that problem i'm talking about? how was it fixed without having the revoke() call?
    this is the video where the problem is described

    http://www.youtube.com/watch?v=ZTdUm...layer_embedded
    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.

  7. #7
    Join Date
    Jan 2010
    Location
    Ghent
    Posts
    208

    Default

    Quote Originally Posted by BO$$ View Post
    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.

  8. #8
    Join Date
    Sep 2012
    Posts
    15

    Default this is good news

    Quote Originally Posted by staalmannen View Post
    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.

  9. #9
    Join Date
    Nov 2011
    Posts
    276

    Default

    Use dietlibc?
    And you're talking about "security"?
    http://permalink.gmane.org/gmane.linux.busybox/1843
    http://mailman.egr.msu.edu/mailman/p...er/014531.html
    https://lists.ubuntu.com/archives/ub...er/028612.html :
    Code:
    mksh (39.1-2) unstable; urgency=low
    
      * debian/rules: build mksh-small without floating point support
        also, because it’s ⓐ huge and ⓑ buggy in dietlibc
    And from the dietlibc source, /CAVEAT:
    Code:
    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.

  10. #10

    Default uclibc for desktop

    If you are interested in using uclibc for the desktop, and have some Linux experience, with check out Alpine Linux. It has at least XFCE.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •