FreeBSD – a lesson in poor defaults • Hacker News Board

Re: FreeBSD – a lesson in poor defaults

#61

Post by xenophonf » Sun, Mar 20, 2016, 10:26 AM UTC

A lot of good points, but several ignorant ones, too (what's wrong with tcp_wrappers or PAM? also OpenNTPD is _not_ a drop-in replacement for ntpd). And if the author is someone coming from OpenBSD, they ought to know at least something of the history behind IPFilter, as it is the raison d'etre for OpenBSD's pf.

Speaking as an infosec guy myself, I'd dearly love to see the TrustedBSD MAC Framework or the Audit Implementation (OpenBSM) being used by default. I'm surprised the author didn't mention it.

Re: FreeBSD – a lesson in poor defaults

#62

Post by cm3 » Sun, Mar 20, 2016, 2:15 PM UTC

armitron wrote: post #41

ceratopisan wrote: post #40

Earlier quoted context omitted.

I've never seen or expected to see "limit yourself to one processor for better security" as actual advice. Maybe this is sarcasm that I'm misreading?

Not at all, SMP opens a huge can of worms both for userland and kernel security. Suddenly you have all sorts of weird race conditions to deal with and in some kernels ( cough XNU) logic bugs that stem directly from how kernel subsystems interact with threads. I don't blame OpenBSD for not going down that route.

Which is why DragonflyBSD was forked during the disagreement on FreeBSD's SMPng. Matt implemented more of a message passing system instead and Sepherosa Ziehau made all kinds of improvements to share as little as possible between cores and thus enable higher scalability in particular for networking.

Re: FreeBSD – a lesson in poor defaults

#63

Post by cm3 » Sun, Mar 20, 2016, 2:17 PM UTC

_delirium wrote: post #45

ceratopisan wrote: post #40

Earlier quoted context omitted.

I've never seen or expected to see "limit yourself to one processor for better security" as actual advice. Maybe this is sarcasm that I'm misreading?

OpenBSD supports multiple cores fine as far as userland goes. If you have 8 cores and start 20 userland processes, they'll be scheduled on all 8 cores. But yes, the kernel itself is not as fine-grain multithreaded as some others. Whether that matters depends on whether waiting on the kernel turns out to be a bottleneck for your workload.

It might be ok for compute-only tasks that spread calculations over threads or processes in userland, but anything involving input/outpout (e.g. networking) will block.

Re: FreeBSD – a lesson in poor defaults

#64

Post by cm3 » Sun, Mar 20, 2016, 2:20 PM UTC

armitron wrote: post #38

cm3 wrote: post #14

Earlier quoted context omitted.

And let's not forget that OpenBSD doesn't make use of modern hardware as well as Linux and FreeBSD or DragonflyBSD. SMP incompleteness is one of the issues.

Given the focus on security, don't expect to see SMP anytime soon if ever. It's a huge source of potential security bugs and attacks on the kernel.

As with all things in computer science, there haven been successful implementations of anything that we see as unsolvable in a Unix-derivative. It's sad that so little of even non-research results has been incorporated into mainstream operating systems. I'm sure nickpsecurity can expand on this in detail, but let's just say Burroughs, VMS, Eros, L4 are all things that come to minds as ancient production quality software which solved issues fundamentally. For a newer strain have a look at Barrelfish.

Re: FreeBSD – a lesson in poor defaults

#65

Post by inopinatus » Sun, Mar 20, 2016, 4:58 PM UTC

xenophonf wrote: post #61

A lot of good points, but several ignorant ones, too (what's wrong with tcp_wrappers or PAM? also OpenNTPD is _not_ a drop-in replacement for ntpd). And if the author is someone coming from OpenBSD, they ought to know at least something of the history behind IPFilter, as it is the raison d'etre for OpenBSD's pf. Speaking as an infosec guy myself, I'd dearly love to see the TrustedBSD MAC Framework or the Audit Implem…

Has the MAC framework reached sufficient maturity that root need no longer be especially privileged, but instead just-privileged-enough?

(this would attenuate many of the OP's complaints)

Re: FreeBSD – a lesson in poor defaults

#66

Post by DominikD » Sun, Mar 20, 2016, 8:48 PM UTC

cperciva wrote: post #58

smcl wrote: post #57

Earlier quoted context omitted.

So the guy is talking utter nonsense and you'd rather not "feed the trolls" so to speak? Genuine q, security isn't my speciality

It's not all utter nonsense. Some things fall into the category of "we can't change this overnight because we have users, but it will be changing in the future".

Sure, he even acknowledges that by writing that in FreeBSD world back compat is more important than security. There's obviously nothing wrong with that as long as you're OK with this trade-off. He isn't, sucks for him then. :D And calling him OpenBSD zealot that is trolling is, well, trolling. ;)

Re: FreeBSD – a lesson in poor defaults

#67

Post by DominikD » Sun, Mar 20, 2016, 8:53 PM UTC

craftkiller wrote: post #13

daenney wrote: post #10

It seems that a lot f the issues the author has they can fix by moving over to OpenBSD. I'd be curious to hear what makes them stick with FreeBSD instead considering the complaint.

I'm not the OP but OpenBSD is missing some pretty key features. My reasons to use FreeBSD over OpenBSD are: - Virtualization (jails, bhyve) - Filesystems (ZFS) - beadm (which requires ZFS) - Linuxulator Which really is a shame because philosophically I think I'd prefer the OpenBSD camp

Jails are a mechanism, not the mechanism. OpenBSD has chroot for most of the same use cases. Virtualization is long overdue but it's coming. ZFS is not my kink but I get it why people want it. Having worked on CoW file system for three years I came to the conclusion that its perceived appeal is what sells it, but use cases are very few (if any) without system-wide control service. :)

I have not used beadm though - what's the kicker?