Why Linux is better than Windows or macOS for security

Discussion in 'other security issues & news' started by Minimalist, Feb 7, 2018.

  1. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    https://www.itworld.com/article/325...etter-than-windows-or-macos-for-security.html
     
  2. Stefan Froberg

    Stefan Froberg Registered Member

    Joined:
    Jul 30, 2014
    Posts:
    747
    So the bottomline of that story seems to be that because Linux is open source it's more secure.
    Of course, it does not guarantee that fixes come fast but at least they do get fixed.......eventually ;)

    https://www.theguardian.com/technol...ow-linux-vulnerability-found-after-nine-years
    https://www.theregister.co.uk/2017/02/23/linux_kernel_gets_patch_against_12yearold_bug/

    Just wish that Torvalds and the grsecurity/pax team could be friends so that the mainline Linux itself
    would be super secure, without needing to search security hardened Linux distro or in my case, hunt and apply security patches myself....
     
  3. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    Oh yes. The level of work required to get a reasonably secure desktop is absurd. And there are elements where Windows is actually doing stuff - out of the box - which is superior to linux. Yes, you can probably replicate what's being done, but you have to spend too long to do it (e.g. secure boot/tpm stuff) and it's way beyond what's in the repos.
     
  4. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    Yes it's mentioned in article:
    They also mention this:
    and this:
     
  5. Joxx

    Joxx Registered Member

    Joined:
    Sep 5, 2012
    Posts:
    1,718
    Root access (or lack thereof), software repositories, Unix compartmentalization architecture...
     
  6. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    2,199
    Well, in a way I can understand Torvald's hesitation as security patches should never break things for many users - but this is exactly the problem with grsecurity/PaX.

    But anyways, via the Kernel Self Protection Project a lot of improvements (many of them stem from grsecurity/PaX although often modified) have been implemented in the kernel in recent versions. Kees Cook's blog gives as good overview of these changes. Further enhancements are already available in the linux-hardened project which will eventually land in the mainline kernel.

    That's grossly overstated. Many distros contain AppArmor or SELinux. I prefer SELinux as it protects system processes in a more comprehensive way. And many applications can be sandboxed by installing Firejail and simply executing sudo firecfg. Granted - Firejail is not standard in most distros. But installing it is hardly an "absurd" level of work. The combination of SELinux (which is interestingly also enabled in the Arch linux-hardened kernel) and Firejail provides a high degree of security, IMHO.
     
  7. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    Apart from notable exceptions, AppAmor profiles require work - the application writers don't bother.

    As for sandboxing or isolating X, forget it. And I don't see that happening for Waylands either. All of that being a big attack surface.

    If you want a desktop used by the great unwashed, then all this stuff has to be pretty invisible, which means more work.

    I'm with you as far as Firejail is concerned, that's a hugely valuable control. But, it's making up for the fact that application writers haven't done that themselves, it's making the best of a bad job.
     
  8. 142395

    142395 Guest

    I think Winodows also require absurd amount of work, but in different points with Linux. e.g. disable Powershell, change UAC setting or create SUA, etc. etc.
     
  9. reasonablePrivacy

    reasonablePrivacy Registered Member

    Joined:
    Oct 7, 2017
    Posts:
    2,002
    Location:
    Member state of European Union
    IIUC Wayland clients sees only it's own graphics buffers. It doesn't have access to others. It's probably also true for input events.
     
  10. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    2,199
    Well, confining applications like a browser with a MAC system is not easy. That's why SELinux (at least in Red Hat based distros) does not do it, either (although it can be done). It's obviously easier to achieve with the technologies (seccomp-bpf, namespaces, etc.) used by Firejail. However, SELinux does a good job with confining system processes, and it doesn't cause hardly any problems like when it was introduced years ago. (Even Mrk doesn't disable it anymore in his recent reviews.) That's why I said that this combo provides a high degree of security.

    Do you have any evidence for this claim?

    Martin Flöser (né Grässlin) who has been the maintainer of kwin for many years (and should thus know what he's talking about) wrote:
    And Wikipedia writes:
    If you have other info, please provide them.
     
  11. Stefan Froberg

    Stefan Froberg Registered Member

    Joined:
    Jul 30, 2014
    Posts:
    747
    Thanks for the links! :)

    I remember trying SELinux long long long time ago but gave up because so many things "breaked"
    (with grsecurity/pax I only had problem with java and other JIT using stuff, oh and Xorg but that was quickly fixed too).

    But if things are now more easier with SELinux then I could give it another try.
    Oh, and will definetely test Wayland too ... I did not know that Wayland brings security improvement to table.
     
  12. reasonablePrivacy

    reasonablePrivacy Registered Member

    Joined:
    Oct 7, 2017
    Posts:
    2,002
    Location:
    Member state of European Union
    AppArmor is easier to configure, yet can be restrictive enough for improving security.
     
  13. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    Oh Wayland is an improvement over X, but that's hardly a difficult thing. That requires native apps of course to realise some of that benefit. And browsers are precisely the thing you most want to sandbox/RBAC, though they are getting better at doing that for themselves (if you trust their integrity, which I don't completely).

    Wayland is not immune to KSL in isolating applications:

    https://github.com/MaartenBaert/wayland-keylogger

    because the underlying OS does not provide the same isolation - "features of the OS trivially allow bypass of Wayland security". IOW its model isn't congruent with the OS one.

    Obviously Wayland should be integrated with application sandboxing, but at last count, no-one in the Wayland list thinks this is in scope, or that Gnome will do it. Maybe Firejail will "do" something about it in the same way as firejailing with xpra for instance, but I think that's less likely while the Debian world gets into Wayland.

    http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/
    http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/

    Nor, as I understand it, has remoting really made it into Wayland. One of the things I had been interested in it for was precisely to do a Qubes on it, and effectively remote into it from another VM, hence compartmentalising functions and secrets.

    Please, don't misunderstand me- I welcome the improvements made possible by things like AppArmor, SELinux, Firejail, and have enjoyed using Fedora recently over Debian. But, doing this uses a lot of technical time and its hard to create a supportable desktop for regular users. I think the issue is that the business model which would allow me to pay someone trustworthy to create such an image is difficult.
     
  14. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    2,199
    It seems that this site doesn't exist anymore - I got a 404.

    And those articles are from 2014 - nearly 4 years old. A lot has changed in Wayland since then but I have no idea if the problems mentioned therein have been addressed. So I cannot comment on them.
     
  15. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    2,199
    Yes, but SELinux is more comprehensive and more tightly integrated into the system. And there is very rarely a need to configure it. When there are new or changed packages in Fedora - which is more or less a bleeding-edge distro - rare SELinux errors can happen which are easily fixed by applying the rules presented by seapplet (which comes with setroubleshoot or setools - I can't remember right now). In distros like CentOS these errors should occur even less often.
     
  16. whitedragon551

    whitedragon551 Registered Member

    Joined:
    Sep 30, 2008
    Posts:
    3,264
    Location:
    USA
    Enterprise systems and the quotes you quoted do not go hand in hand. Users are not given local admin or domain admin rights by default. They are standard users with UAC. With Windows 10 in an Enterprise enviornment you cant even access Windows 10 apps as a local or domain admin without intentionally modifying several GPO settings.
     
  17. reasonablePrivacy

    reasonablePrivacy Registered Member

    Joined:
    Oct 7, 2017
    Posts:
    2,002
    Location:
    Member state of European Union
    404.

    If I understand correctly Wayland is immune to keyloggers, but rest of the system does not. As page for other keylogger for Wayland notes:
     
  18. Stefan Froberg

    Stefan Froberg Registered Member

    Joined:
    Jul 30, 2014
    Posts:
    747
    from that keylogger page:
    "By the way, this inherent weakness is not at all specific to Linux. Similar techniques would also work on Windows and Mac, and essentially any platform that doesn't sandbox applications."

    And that is so true.

    All the bits are there (chroot, cgroups, namespaces, seccomp etc..etc..) in Linux but it's up to app developer to use them. And if developer does not do that then the burden of sandboxing falls to users with Docker, FireJail or any other 3rd party solution.

    I don't see any reason why Linux kernel (and also the gcc compiler) could not make all these security goodies by default on. (actually, gcc has now options to enable things like default PIE and default stack protection but the compiler must be configured and build with those switches on)

    So:
    1. There should be a way for Linux kernel to automatically use whatever security there is to support sandboxing out-of-the-box.
    Like automatically creating network namespace,PID namespace etc... when process is started and then provide some configure knobs in the usual place, /proc/<process pid>/, for tuning or turning off when not needed or when debugging that particular process.

    2. gcc compiler should by default use PIE (--enable-default-pie), stack protection (--enable-default-ssp) and most importantly, any spectre/meltdown mitigation technique there is .

    Currently it's up to distros to pass the -mindirect-branch, -mindirect-return and -mindirect-branch-register switches for userland apps when compiling them with retpoline support but I don't see any configure switch to make those things default on in gcc source code yet.
     
  19. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    Yes, it's old, but some of the information I mentioned I checked reasonably recently - and the withdrawal from efficient remoting is inexplicable.

    I'd be delighted if you can illustrate that Wayland is immune to KSL and can be sandboxed!
     
  20. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    Yep, I'd be very happy to compile with the switches I wanted - the performance hit was one of the absurd justifications for not doing Pax and the grsec protections - justified with servers, but why oh why not have some reliable compile time switches and repeatable buildso_O??
     
  21. reasonablePrivacy

    reasonablePrivacy Registered Member

    Joined:
    Oct 7, 2017
    Posts:
    2,002
    Location:
    Member state of European Union
    What does KSL stand for?
     
  22. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    Sorry, Key Stroke Logging.
     
  23. reasonablePrivacy

    reasonablePrivacy Registered Member

    Joined:
    Oct 7, 2017
    Posts:
    2,002
    Location:
    Member state of European Union
    Ok, it is probably common knowledge on this forum.

    As far as I understand Wayland compositor communicates directly with system interfaces (files) representing devices: gpu, mice, keyboard. Wayland clients don't have access to them directly. Instead input events (keyboard, mice, touchpad) are send to them by Wayland compositor. A Wayland client being a keylogger can't steal input sent to other clients.
    Maybe in future, when Wayland desktop environments are going be more feature-rich (and thus more interconnected and complex) there will be some vulnerabilities, though. Usual desktop workflow encourages interconnection of programs.

    I checked reddit thread about mentioning this keylogger you are referencing. It is not using features or vulnerabilities of Wayland protocol to steal input events sent to other clients thus is not proving Wayland is vulnerable to keyloggers.

    It operates as a malicious library loaded to victim processes by replacing/modification of environment variable - but that has nothing to do with Wayland and as author noted it can be prevented by a few SELinux rules (or any other feature isolating processes) preventing malicious/not trustworthy/vulnerable process modifying environment variable.
     
  24. reasonablePrivacy

    reasonablePrivacy Registered Member

    Joined:
    Oct 7, 2017
    Posts:
    2,002
    Location:
    Member state of European Union
    Going back to main topic: Interconnection. I think this is one reason that Windows is harder to defend against advanced malware. Windows has a lot of features for programs to interact with other programs. A lot of them can be used by malware to inject library, override memory or other method of executing malware code in in another running process context even without Administrator privileges and process is running as another user (but in the same login session).
    In Gnu/Linux there are fewer of this features and can be restricted by things like SELinux.


    Another thing is some design decisions in services. Windows has a lot of services in form of dll libraries executed by svchost. Some services are executed within the same process as other service, just different threads. This all means they share the same process memory space. This make difficult to use fine-grained access control on them and principle of least privilege.
    In Unix-like OSes different daemons (services) are different binaries and actually some spawn a few processes each to provide privilege separation within the same service, not to mention privilege are completely separated between different daemons. Unfortunately some separation is being subverted by crap named systemd in Gnu/Linux in some distros.
     
  25. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    2,199
    Well, for Fedora see here (note also the links at the bottom) and here.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.