Why doesn't FreeBSD merge security features from HardenedBSD?

Yeah. For servers, openbsd seems to be the most appropriate. I initially wanted to learn freebsd by using it as a desktop system, but there are some cases which make even that a bad choice for me. I'll keep using gentoo.

Security is nice to have but a lot of the points of focus here are really inconsequential, for instance this
I can't disagree more with their statement that ASLR makes exploiting something "much" harder, it is simply one more small hurdle that doesn't add that much complexity, and exploiting it is already pretty well understood, honestly the only time I hear about ASLR is when it is defeated, which is often.

But forget all of this anyway, a lot of these things require a certain level of access already, if someone can poke your system enough that they can start running their own binaries or they have the ability to write to memory arbitrarily, you're already boned, each of these security focused patches adds small hurdles that won't actually prevent anything.

The point being that these patches certainly solve _A_ problem, but they are all stop-gap solutions for biding time. There are underlying issues that remain unresolved that need to be tackled and once those are, these patches could be considered irrelevant or on a "paranoid" tier (I don't mean this as a jab).

It's like when people say "if someone has physical access to your machine, you've lost", extend that to "if someone untrusted has shell access, you've lost". A padlock might waste 5 minutes, a kernel security feature may waste a day for a cracker, but eventually, they get what they want anyway, none of these things solve problems as much as they do just add delays, and not for free either, a lot of these things have performance implications or influence debugging practices.

All in all I think it's better to try and solve the underlying issues than use band-aids. As you can see in the linked article, the problem was in GIMP and resolved in GIMP, the underlying problem should have been caught in review of the project, developers of third party software should not rely on environments to handle their logical mistakes for them, and people who really need this level of security should be auditing third party software. Relying on platform specific security features to seems bad for everyone when we should be fixing things at the source, not hoping there is a platform specific safety blanket. Moreover a saftey blanket that itself is easily cut down anyway.

I guess the summation of my post is, don't patch an entire OS when someone writes faulty userland code.
Another thing I should say is that you need to decide on an extreme when deploying, we already have systems that focus on certain aspects like security, portability, minimal resource usage, etc. if you need some sandboxed environment, those already exist and you should use those, you can't just roll in every paradigm into the same system without compromising some other aspect, in relation to security features, it's almost always incurs a performance impact and ultimately will be pointless to have the majority of the time since a majority of what you're running is trusted and what isn't trusted should have been audited.

None of this is exclusive to FreeBSD either, I'm speaking generally.

Good pointers, thanks for the input, user.

This. To add my $.02 the sec menu in bsdinstall now makes many of these the sec tweaks easy and opens the door to more being offered.

Most of the problems outlined in that article are as bad if not worse in Linux. It's because BSD has a historically greater preoccupation with correctness and security that it is even discussed at all.

...

That's a lie.
Especially the "Ports and Packages" section has no parallel in Linux. The magnitude of fail FreeBSD reached there is just staggering.
1. brain-damaged design that interferes with security
2. incompetent maintainers
3. publicly known vulnerability left unfixed for SEVERAL MONTHS since disclosure

Where is this "correctness and security" that you're trying to shill?

Depends on if he was talking about Linux the kernel or Linux os as a whole. If the second is the case then you would have to examine all of the various distributions and calculate if on average they have better security then freebsd. I would tend to agree with the other user that security on Linux is often just as bad.

openbsd.org

Obviously, that question was in context of FreeBSD - which is kind of the point of this thread.
I respect the dedication to security and good design OpenBSD devs have (and it seems to be paying off).

The security maintainer for FreeBSD is a maths prodigy and security expert in cryptography.
Whenever someone asks him why really basic shit gets through he simply states that FreeBSD has made backwards compatibility more important than security.

Sometimes I wonder why he bothers, he is clearly overqualified if he can't be allowed to fix the problems.

ASLR is useless on its own you will need some other mitigations to make it shine.
There isn't one mitigation to rule them all hence why you will need multiple mitigations to be effective.

What you are saying is 90s security thinking ( just fix all bugs and write secure code )
Well spoiler alert nobody writes secure and correct code even in kernel land and fixing all the bugs is impossible so you basically need exploit mitigations.

Exploit mitigations are all about making it harder and more expensive to write exploits and compromise systems.

Auditing third party code is close to impossible and humans or fuzzers won't find everything besides that it's expensive.

Seems like many people still have the 90s security mindset.

Also you don't need shell access for remote exploitation, FreeBSD is mostly used for server OS running network facing daemons this is a real problem without any userland exploit mitigations it's fairly easy to write stable exploits.

Also everyone saying OpenBSD is better in terms of security is straight up lying unless you only use base and no third party applications plus W^X enabled then you can say it's better.

OpenBSD is fundamentally different from FreeBSD, you stupid gnutard. A different kernel, different packages, different fucking userland, you fucking idiot.

Nice reading comprehension you've got here, lad.

Backwards compatibility with no EOL schedule is a fucking prison guaranteed to kill software, all for some legacy users that for some reason need to keep things the way they were a decade ago but continue to upgrade to new versions? That makes me rethink using FreeBSD.

What are your security recommendations for a *BSD user then?

The absolute state of FreeBSD in 2017.

I was running a mailserver like that for years, with only Dovecot from packages.

Can someone explain to me why (Free|Dragonfly)BSD don't include something like synth/poudriere in base? Building ports one by one is retarded when you want to go fully source-based.

Because updating something in ports is a lot easier than a base update.

Think about what you're saying. None of the ports I installed run as UID 0, but part of the base system does, and the kernel itself has an even higher priviledge. They don't have to be equal in terms of safety, because they don't pose the same risks. And besides (as someone else pointed out) you can run an entire Unix server, firewall, or bridge/router without any ports.

Or not using a separate tool I don't care. Like portage, their port or pkg binary should allow full system upgrade using only ports.

Because the BSDs have shit project management that do not intend for the OS to be used as-is, but only to serve as a part of proprietary software that controls the user. They serve proprietary ISVs, not you you fucking retards.

You clearly haven't used any BSD ever before.
Why not go and get a clue?
You might actually like it.

Kill yourself.

Stop derailing useful threads with license shit. You don't see me going into every Linux thread to talk shit about RMS.

Yeah I think he's clearly trolling.
Or dumb as a brick, could be both.

OP here, so far there haven't been any conclusive reasons mentioned for FreeBSD to completely skip Exploitation Mitigation.

IIRC, there was a FreeBSD patch circulating that added some form of ASLR, but I don't know what happened to it.
(This particular patch was not authored by lattera, his work formed HardenedBSD)

ASLR was described as a "small hurdle", but isn't it true that every hurdle counts for something.
Consensus amongst security professionals seems to be generally in favor of exploit mitigations.

What transpired is that perhaps FreeBSD doesn't see itself as a security-focused OS, rather embracing their status as a simple worker that is good at one particular job (e.g. Netflix) where security is handled elsewhere.
Could that be the sole reason?

To be fair you can remove the compat modules if you don't need them. Using your own kernel build is extremely easy and boils down to 2 make commands once you have your config file made and sources synced.
freebsd.org/doc/handbook/kernelconfig-building.html

Specifically to remove compat you'd just copy the GENERIC conf file to whatever name you want, comment out the compat_freebsdX kernel options, then build and install it.

I don't even know anything popular that relies on them outside of some proprietary drivers, which is why they bundle it with the GENERIC branch.

This modular approach to compat is one of the biggest draws to the OS for me, there if you need it, not if you don't.

Maybe they should rename themselves to Opensolaris and FreeBSD devs would implement their patches.

I want to reiterate some things I mentioned here but a little more loosely

Security isn't always free and the cost isn't always worth it to some people. The argument could be made, "where is the sense in running X% slower 100% of the time when you trust your environment already", not to mention some of these patches are not bulletproof, they're hurdles not walls.

2 related topics to think about that people typically argue about more, look at how people fight over languages like C vs something "safe" and managed, a big knock is always the performance.

Which is more important to you, performance or security, is obviously subjective and usually case dependent, for instance you probably don't have to worry about security on some isolated machine you use at home, but it's different in other scenarios.

Intel's latest fiasco is a good thing to bring up here, with people speculating a 30% speed decrease in certain operations. I've seen some home users saying their going to use outdated Linux kernels because they don't think the impact is worth it for their use case.

I also want to point this out
it's not like you can't use these things in your own build if you want/need them, obviously they're out there, but does every FreeBSD user need them by default? Probably not, so incurring some kind of penalty on them may not be desirable. Imagine the percentage of security focused users vs those that are not under constant threat and the cost associated.

I don't doubt it but it's probably not the sole reason. The fact that a fork exists and other security oriented projects also exist, may be related. Different goals and the ease of integration if you do desire these things alleviates any pressure, they can easily just point and say "use patchset X or project Y if you want feature Z".

I think another thing worth mentioning is security people argue over what is and isn't a solution, I know the OpenBSD people don't like the idea of jails so much where FreeBSD people think it's fine. User requirements and their level of comfort with mitigation strategies vary widely.

For me personally I'd be okay with someone exploiting one of my jails because it's isolated, if they manage to get into that isolated system, I don't care, I don't need ASLR for this sandbox, they can have root in it for all I care, I'm nuking it anyway, its only purpose is to run this service and it can't do anything else.

OpenBSD people take a different approach making sure these kinds of things don't happen in the first place. Which in my opinion is noble and the right answer but not practical. No matter what the claims are I'd rather never trust a system and just isolate it than expect it to be bulletproof because some people audited something and found no obvious problems at the time.

To put that simply, it's all a bunch different paradigms, no 1 things is the answer, including just mixing all the standard practices together.

Therefore no one would. I also hate their dump file policy. I wonder what did they do against row hammer though it should be fixed by intel.

Probably just don't worth the effort. While OpenBSD can freely experiment, FreeBSD is still used in data centers and they must think about 3rd party support too.

Sure, and 3rd parties usually pull/implement this stuff, I know Sony at least uses ASLR and some other isolation tactics on their version of FreeBSD for the PS3, PSV, and their PS4 products so I'm sure other companies using it have their own security featureset that they use.

I think that's a big part and appeal of the system, it's documented well and modular enough that you can morph it to fit the paradigm you want, some people strip it down for things like embedded systems, others add more to it for security, redundancy, special hardware, etc. FreeBSD specifically is used in a lot of places probably because it's so malleable, that's my guess at least, obviously everyone has their own reason for using it.

It's similar to NetBSD in a sense of being ubiquitous in a lot of ways despite working on so many platforms. For FreeBSD it's more of the same but just for the core project, a lot of things overlap even if you modify it to work for you. Like you can still find use in the handbook, or the ports tree, etc. but have your special kernel or even userland features, re-using the good bits from the base project.

FreeBSD should be rewritten in Rust.

wew boy

I didn't fall for it the first time, what makes you think I'm going to fall for it a second time?