Wait until you hear who created the internet!
Yes, it was Al Gore!
Thank goodness for selinux. Without it Linux would not be a secure OS.
And no AppArmor does not do the same thing. You need the mandatory part for mandatory access controls to work.
Also, AppArmor might not exist without SELinux.
When the NSA first implemented SELinux, they did so directly, but were not able to get that merged into mainline because there was concern that SELinux was not the correct solution.
What they ended up doing was creating the Linux Security Modules (LSM) framework, which is just a bunch of hooks in the kernel that a module can implement. SELinux was then rewritten as LSM module. This allowed other solutions like AppArmor to be implemented without any invasive work; they could just plug into the same system SELinux used.
Some time later, the ability to run multiple LSMs at once was added.
Incidentally, Linux capabilities are also implemented as an LSM.
TIL. Very cool.
you’re the first person i’ve ever heard of who liked selinux; what do you like about it?
If you are building a static system, SELinux is amazing. You need a few lines of policy per application to label things appropriately, then you can see what accesses programs made and decide if you want to allow them or not.
Taking a full Linux system and adding a locked down SELinux policy can be done in less than a week. If you are starting with an SELinux enabled system and just want to lock down your application, it can be done in less than a day.
Once you know what you are doing, there is also a pretty powerful policy analysis tool that lets you see what a given domain can do; including transitive things like “domain sandbox_t can launch a program in Domain vim_t, which can write a file in Domain sshd_config_t, which can be read by domain sshd_t” which may indicate that your sandbox has a hole allowing it to compromise your sshd configuration. Although, to be fair, doing this level of analysis is not simple, even with the tooling. And you very quickly notice issues that are inherent in how Linux works.
The problem with SELinux comes when you try applying it to general purpose systems, because you do not know ahead of time what the user will want to do. To be effective, policy needs to be written for the specific system it will be running on.
An example I like to use is Android. Android makes great use of SELinux, and is a general purpose system. But the SELinux policy itself does not protect the general purpose Android system. It protects the special purpose system that is the Android runtime. All apps run with the same policy that says things like “cannot access the filesystem at all, unless given access by the Android runtime”, then the actual security policy users see is all implemented in use space by Android. SElinux is just a means of preventing apps from bypassing the Android permission system.
Most people don’t actually like real security as much as they claim they do. SELinux and its derivatives are pretty much the only real option we have for properly robust security these days.
I like the fact that it is a solid mandatory access control system. With SELinux you are substantially more safe than without.
For example. Let’s say you are running a compromised version of OpenSSH. Threw a XZ style back door a hacker gets in as OpenSSH (which runs as root).
Without SELinux the system is fully owned. With SELinux the attacker can only access what OpenSSH needs to access even if they have root. They can’t just chmod files and folders wherever. That means your photos and application data are still secure. With the pre written SELinux policies this applies not just for OpenSSH but for every piece of software installed on your system. Everything is limited to the exact folders, ports, and system capabilities that it needs and no more. Even stuff like seperate websites being served under Nginx. You can have Nginx-subgroup-1 and Nginx-subgroup-2 where the applications can’t see each other even though they are being run as the Nginx user.
I don’t trust any Linux distro without this security layer.
It’s a little difficult to learn and master, but it’s totally worth it if you care about security.
Redhat put out a comic about it a few years ago explaining the basics. https://people.redhat.com/duffy/selinux/selinux-coloring-book_A4-Stapled.pdf
Yeah. Solaris is junk, obviously.
Solaris was great until they insisted on keeping their crappy CPU for way too long before adding x86 support and lost their market share and their company.
It was a terrible gamble and they lost hard to Linux as a result.
Solaris was beautiful. But it could have been more secure if it had Mandatory Access Controls. One compromised app running as root, or one privilege elevation exploit and without mandatory access controls you’re done.
Even with user contained exploits without MAC you expose way too much.
Edit: Turns out Solaris had a MAC enabled variant called Trusted Solaris! I could have seen myself using this if Sun was still around and OpenSolaris had panned out.
https://en.m.wikipedia.org/wiki/Trusted_Solaris
In conclusion Solaris was not junk.
A favorite of mine is Ghidra. Before they realeased+open souced it a few years back, the only option for real software reverse engineering (as in, for large and non-trivial programs, where you need more than just fancy disassembly) was IDA Pro, which is absurdly expensive if you’re not sponsored or willing to pirate. Now, some of us kinda take for granted the fact that there’s an open source world-class RE tool. And honestly, I even prefer it to IDA Pro - that’s how good it is.
Very interesting! I didn’t known about ghidra.
You could’ve just provided a link to their Github page, but no, you had to link to their official website.
- What’s the issue with their official website?
- A Github link is easier to impersonate than an official .gov address.
An official .gov website is easier to serve a js vulnerability than github
