>which is arguably better than anything Linux has built-in.
No it isn't. There's a reason why government and military servers run hardened Linux with SELinux, and not any of the BSDs.
No it isn't. There's a reason why government and military servers run hardened Linux with SELinux, and not any of the BSDs.
Security is hard to define, let alone prove. Everyone has a very different definition of security. So first one has to ask, secure from what?
I imagine most of the reason around BSD not on the official list(s) is because it's not as popular. I mean GenodeOS[0] is arguably one of the most secure OS's around these days, but I doubt you can find any public Govt support(by any govt) for running it in production today.
Going back to my original comment, security is complicated, and there is no "secure", but hopefully for a given set of security threats, there is a "secure enough".
The same exists in physical security. Our home door locks are notoriously not secure, but they are generally secure enough for most home needs. But your average home door lock would obviously be idiotic as protection for Fort Knox's gold deposit door.
Comparing BSD to Linux security is complicated, but for most high value targets, the answer probably is, run more than one OS. Root DNS servers and other highly critical internet infrastructure all do this as a matter of common practice. If you are mono-culture Linux only, I worry for your security, as you are effectively a single zero-day away from being owned. Linux, BSD, Windows, etc will all have RCE's and zero-days as a normal part of existing.
0: formal proof secure(sel4), for some definitions of provable even: https://genode.org/
I did not miss that part, you're just mistaken.
>SELinux is not built-in(though it is for certain distributions of Linux).
Wrong. SELinux is 100% "built-in" to Linux. That's like saying btrfs or Wireguard are not "built-in" to Linux because certain distros may or may not have them compiled in. Nonetheless, SELinux is part of the kernel [0].
The rest of your dribble is a painful Gish gallop because you were decisively proven wrong. Mature up a bit and take the L. Fomenting about being proven wrong is against the Guidelines here.
I'm happy to accept that SELinux is now built-in to Linux, the kernel parts do indeed seem to be built in now, news to me, thanks for that. I don't follow Linux kernel stuff much anymore, I haven't contributed to Linux in over a decade.
You seem to assume SELinux is the end-all be all of Linux security. It isn't. I recognize, based on your other comment, that you are fairly new to the field(a whole decade, go you!). Please open your mind and accept differing perspectives, it will do wonders for your ability to reason about security properly.
HardenedBSD[0] essentially implements grsecurity for FreeBSD, plus FreeBSD has built-in capabilities with Capsicum[1], which is true capability based security, which is much different than SELinux's MAC stuff. If you don't believe me, go read the capsicum paper[1] and come to your own conclusions, it might prove enlightening.
Also, see CheriBSD. :)
0: https://hardenedbsd.org/content/easy-feature-comparison 1: https://papers.freebsd.org/2010/rwatson-capsicum/
If you just want to continue hating on me, no reason to respond, we can go our separate ways. If you want to have a reasoned discussion about security, then I'm happy to continue.
Never said or implied anything of the sort.
>I recognize, based on your other comment, that you are fairly new to the field(a whole decade, go you!).
I've been implementing secure, hardened UNIX and Linux probably longer than you've been alive. I just specifically worked on DoD TS+ systems for a decade.
The rest of your Gish gallop is nonsense. Linux also has capability based security ON TOP of all the other aspects of security, SELinux included.
>If you want to have a reasoned discussion about security
That's not possible with you. You instantly showed how little you know about security in general when you flouted your lack of SELinux knowledge, then you proceeded to Gish gallop and sealion because you've been called out.
Stop it.
IMAX-levle projection. The only one here you should feel sorry for is yourself.
> Grow up and interact with humanity better.
"no u". Grow up and take the L with grace.
It really depends on what you mean by "SELinux". The core kernel bits of SELinux, are of course, part of kernel by definition. However, SELinux is not really useful unless it comes with the SELinux policy definition which defines what applications do "normally". This work needs to be done by the Linux distribution, because without it, it's much like relationship between software and hardware. "Without the software, it's just a paperweight."
Not it doesn't. Just like it doesn't "really depend" on what you mean by "btrfs".
> However, SELinux is not really useful unless it comes with the SELinux policy definition which defines what applications do "normally".
"However, btrts is not really useful unless it comes with the userland utilities to actually make and manipulate file systems"
See how pedantic this is? Not only are you being pedantic, you're still wrong, fractally so.
That is exactly operating system does, which is the topic of discussion. Linux OSs such as RHEL as an example.
> This work needs to be done by the Linux distribution
Which are defined as operating systems by CIS and STIG.
This is a poor attempt at "DO YOU MEAN GNU/LINUX?".
Stop it.
Good luck trying to use SELinux without having the policy installed; it's guaranteed to be non-functional. And given that the SELinux policy is distro-speicific, it's not like you can take a random Linux distribution, and enable SELinux and expect it to work. You enable SELinux on the boot command-line, but without the policy installed, it will be dead in the water. And configuring the SELinux policy is extremely non-trivial. It's several orders of magnitude more challenging than running, say, "mkfs.btrfs".
>That is exactly operating system does, which is the topic of discussion. Linux >OSs such as RHEL as an example.
If that's your definition of an OS, then there are plenty of Linux distributions --- aka, an "OS" by your definition --- that do *NOT* have SELinux built in, because they don't have an SELinux policy defined that will work with that distribution's system daemons.
Therefore, by your definition SELinux is not "built in" to all versions of Linux (specifically, "distributions"). Q.E.D.
Wrong again! You can actually have Linux systems that do not support booting from btrfs, but have btrfs-progs installed. Or systems that have neither.
>Good luck trying to use SELinux without having the policy installed
They are installed and included in the Linux operating systems used by the US government, as I stated above. This is a non-point.
> And given that the SELinux policy is distro-speicific, it's not like you can take a random Linux distribution, and enable SELinux and expect it to work.
Wow, it's almost like it be nice if there were standards used by the government and other organizations looking to secure their operating systems. Maybe they can form an agency, I'll call it the Defense Information Systems Agency. They can make standards that secure and lockdown systems, and make sure SELinux is configured properly... We'll call these Security Technical Implementation Guides, STIGs for shor... Oh wait...
> And configuring the SELinux policy is extremely non-trivial. It's several orders of magnitude more challenging than running, say, "mkfs.btrfs".
Immaterial to the matter at hand.
>If that's your definition of an OS
A distribution is an operating system by definition. It's not my definition, it's the definition[0].
>that do NOT have SELinux built in, because they don't have an SELinux policy defined that will work with that distribution's system daemons.
Still "built-in" to Linux. Whether or not it's enabled or complied in is an implementation detail, but it's still "built-in" to Linux operating systems, most definitely those used by the government for secure systems, which was the original point. Thanks for proving my point, Q.E.D.
>Therefore, by your definition SELinux is not "built in" to all versions of Linux
Using your illogic, there are BSDs that send your password through plaintext over the wire because they only have rlogin. They don't have SSH "built-in".
SELinux is absolutely "built-in" to the Linux kernel and operating systems. Whether or not specific implementations of Linux have it compiled and enabled is besides the fact that it is built-in, not third-party.
You're fractally wrong again. Take the L and stop while you're this far behind.
They're probably more secure than BSD.
>SELinux looks nice on paper - another box to check - but it’s just another mitigation later, not something that can be considered “trusted”.
This is fractally wrong.
What would I know, only designed and implemented TS+ systems for a decade!
Microsoft Server systems for government use have been audited and have strict controls for implementation, hardening, securing, etc.
They're probably more secure than BSD.
Not sure what you mean, but the custom Windows Server that the US government uses is likely more secure than BSD.
>Yet I see BSD on the STIG list as well.
No you don't. DISA does not provide STIGs for any of the BSDs. The US government does not use the BSDs for secure systems (TS+ etc.).
As said, they do have STIGs and CIS documents for JunOS but I guess they don't run any Juniper in the US secure networking despite of having certifications.
Now you're strawmaning on top of shifting goal posts again.
>As said, they do have STIGs and CIS documents for JunOS
No they don't. The CIS documents specifically outline the operating systems they support, and there are ZERO BSDs listed (click on Operating Systems)[0].
Similarly, there are zero STIGs for Junos OS. There are STIGs and CIS benchmarks for Juniper network devices, but not for Junos OS. The actual devices could be running on FreeDOS for all we care, but FreeDOS in and of itself would not be allowed to run on any servers. Hilariously, even Juniper is moving away from BSD. Junos OS Evolved is Linux based.
You're fractally wrong.