Announcement

Collapse
No announcement yet.

Linux Desktop Security Could Be A Whole Lot Better

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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
    the consolekit security problem related to the lack of the revoke() syscall is still there right.

    Comment


    • #3
      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

      Comment


      • #4
        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.

        Comment


        • #5
          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

          Comment


          • #6
            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.

            Comment


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

              Comment


              • #8
                this is good news

                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.

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    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.

                    Comment

                    Working...
                    X