"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."
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.
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.
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.
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.
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.
> 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.
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.
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.
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!
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.
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.
> 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.
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.
- 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.
[+] [-] stuzenz|5 years ago|reply
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?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."
[+] [-] totony|5 years ago|reply
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_Pr...
[+] [-] gizmo686|5 years ago|reply
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.
[+] [-] sbrass|5 years ago|reply
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.
[+] [-] rossvor|5 years ago|reply
[+] [-] inshadows|5 years ago|reply
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.
[+] [-] commandlinefan|5 years ago|reply
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.
[+] [-] LinuxBender|5 years ago|reply
Here is an example:
Read the test.txt file first of course.[+] [-] Mic92|5 years ago|reply
[+] [-] greatgib|5 years ago|reply
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!
[+] [-] thayne|5 years ago|reply
[+] [-] tptacek|5 years ago|reply
[+] [-] DmitryOlshansky|5 years ago|reply
I too sadly realize the dire need to post such disclaimers. Boy, these people are boring sometimes...
[+] [-] abjKT26nO8|5 years ago|reply
[1]: https://github.com/Aishou/wayland-keylogger
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] commandlinefan|5 years ago|reply
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|5 years ago|reply
[+] [-] justaj|5 years ago|reply
0: https://www.grsecurity.net/
1: https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...
[+] [-] tptacek|5 years ago|reply
[+] [-] blackrock|5 years ago|reply
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|5 years ago|reply