
FreeBSD – a lesson in poor defaults - ran290
https://vez.mrsk.me/freebsd-defaults.txt
======
ComputerGuru
I'd be interested in hearing @cpercival's take on this. He was the FreeBSD
Security Officer for a while (but stepped down some years ago) and is
definitely properly paranoid about security.

~~~
cperciva
I find that thumper's rule is very useful when dealing with zealous members of
the OpenBSD community.

~~~
smcl
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

~~~
cperciva
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".

~~~
DominikD
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. ;)

------
egwynn
The author writes:

    
    
       ###############################################################################
       daily_status_security_pkgaudit_enable="NO"
       ###############################################################################
    
       I most certainly don't want pkg (running as root, remember) going out to
       the internet every night to fetch a list of vulnerable ports.
    
       Who thought this was safe?
    

I’m confused. Why is this unsafe? Is it because the author doesn’t trust `pkg`
to do the auditing job safely as root? Remember, this isn’t automatic
updating/installing. This job just adds a section to the daily email that
tells you which packages have security updates to them.

~~~
geofft
Yes, making this change is _bad_ for security, unless you have some other
means of being informed of vulnerabilities.

If you think pkg has vulnerabilities, fix them. (For instance, running as not-
root is a great idea!) The author's argument that pkg is bad because Debian
apt has vulnerabilities is ... really stretching.

~~~
washadjeffmad
Isn't that still assuming that the information that pkg provides is generally
trustworthy?

I assume their consideration is that the list might not be trustworthy, so
knee jerk updating based on a potentially faulty list is itself a
vulnerability. Would a 24h delayed updated list of security updates be worse
than an incorrect one?

~~~
msbarnett
The fact that pkg isn't least-privileged in its operations sucks, but the idea
that this somehow makes the contents of a cryptographically signed
vulnerability list, fetched via SSL with chain-of-trust verification
"untrustworthy" is nonsensical.

~~~
MBCook
Since it runs as scripts as root what happens when through malice, mistake, or
odd configuration a script gets through standard review and trashes a system?
What if one of the official maintainers doesn't exercise due diligence?

You're protected from MITM and hacked repos, but what if the problem is in the
official repo?

Defensive programming is useful.

~~~
msbarnett
Yeah, but that's not the argument. I'm specifically responding to the parent's
assertion that you wouldn't want to run audit because the list might just lie
to you.

That's separate from the idea that the list might be maliciously crafted to
exploit an overflow and gain root privileges (which presumably could bypass
signing checks) -- if your threat model involves loss of control of FreeBSD's
signing keys, pkg running as root is irrelevant. You can't ever trust anything
outside the box, or update at all. No binary is trustable and even if you
heavily audit the source you're in trusting-trust territory.

(also the only key that matters is the Security Officer's key for vuln
disclosures -- not any random maintainer has signing authority)

------
vbit
Some discussion
here:[https://www.reddit.com/r/freebsd/comments/4azhmm/freebsd_a_l...](https://www.reddit.com/r/freebsd/comments/4azhmm/freebsd_a_lesson_in_poor_defaults/)

~~~
Gracana
Wow, that comment about OpenSMTPD. I highly recommend reading beyond the first
message. The reddit poster links it as supporting their claim, but the rest of
the picture sure doesn't.

------
woodman
I'm really torn on the issue of how tightly coupled the userland configuration
is to the release cycle. I'm not sure that I'd be running FreeBSD today if it
hadn't been that way, because having a well tested and widely deployed base
image makes adoption so much easier. The common problems that novices get
discouraged by are completely sidestepped: package conflicts, library
incompatibility, missing drivers, etc.

But after several years of use I find the methods used to implement those
thing getting in the way:

In the interest of security I want the kernel to have the smallest attack
surface possible, and this isn't just a theoretical thing. Not long ago there
was a very serious remote exploit that leveraged two default kernel compile
options - SCTP and IPV6, and had those not been made default (few can even
take advantage of SCTP) I'm sure the number of vulnerable machines would have
been tiny. So to decrease your risk for a 0 day you want to get off the
GENERIC kernel config, but now you need to constantly rebuild the kernel in
order to keep up with the latest security fixes - and you can't safely
automate the build/install process.

Building the userland is far worse. The mk scripts handle dependency through
explicitly defined, and very fragile, rules. Don't want the base version of
openssl? Well have fun figuring out how to get your build working after some
uefi bins that you don't even want fail to find the missing openssl headers -
because somebody forget to add that dependency to the mk file. I could go on
for hours, the buildworld process is a trainwreck.

But there is good news! The problem is actively being addressed, as I
understand it, a lot of that is being pushed into a sort of blessed pkg repo.
So hopefully we'll have the best of both worlds - easy initial base, and
unlimited customization that leverages the pkg dependency code. I've been
working on my own solution, using dynamically generated dependency graphs at
the compiler level, but extending the pkg system seems like the right way to
go.

------
daenney
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.

~~~
craftkiller
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

~~~
teamhappy
Also:

    
    
      - LLVM
      - Arm support
      - The handbook
    

I do envy OpenBSD's pledge() and arc4random() though.

~~~
marios
OpenBSD man pages and FAQ are really good too. LLVM is not in the base
install, but you can install clang from ports and build a program if you need
to.

I agree with pledge() and arc4random(). They are both ridiculously easy to
use. FreeBSD has Capsicum but it doesn't seem to be integrated.

Oh, and FreeBSD has DTrace. Judging from some recent commits it looks like
OpenBSD is going to get some sort of tracing framework.

~~~
teamhappy
> OpenBSD man pages and FAQ are really good too.

Absolutely! I didn't mention the man pages because all BSDs have really good
ones and they all use OpenBSD's mandoc these days.

------
kev009
A lot of these really aren't "defaults" but things necessary for ABI
compatibility in the -STABLE branches. I was expecting more on poor sysctl
tuning out of the box (and that is a real problem).

I will say that for FreeBSD 11, where we can break ABI again, it would be nice
to ditch sendmail and I don't know why it is taking so long to do it.

~~~
cm3
I believe there's work underway to replace it with Dragonfly's dma.

~~~
swills
dma is already in base, just not default

------
drdaeman
> (About SSH "none" cipher) The trade-off in performance isn't really worth it
> either, as the bottlenecks one might experience have a lot more to do with
> the MAC than the actual encryption.

Maybe that's just my experience, but I've used patched OpenSSH (scp, to be
exact) that had "none" cipher on GNU/Linux, as a no-brainer tar+netcat pipe
replacement for two PCs connected with a patch cable (so, no security was
necessary), and it had saturated the link well. Default cipher suite ate the
CPU and gave terrible performance. So I doubt the author's statement about the
worth.

------
aduitsis
Pkgng and poudriere can very neatly be used in conjunction. You can use pkg to
fetch and install all your binary packages from FreeBSD in the same way that
apt-get is used in Debian. Most people will do just that.

But, if you'd like to have some ports built by yourself with special options,
you can setup a poudriere builder and tell it to periodically make the ports
you're interested in. The ports are compiled and packaged into pkgng packages.
The final result is an additional private repo which you can totally use along
with the official FreeBSD one.

~~~
cm3
I've heard time and again that you should either build everything from ports
of install pkg binaries? I believe it's because of different use flags (in
Gentoo lingo), so maybe you mean that one would build everything privately in
a consistent poudriere repo with personal settings and only ever install
packages from there. Is that right?

~~~
floatboth
Uh… no? Unless you really customize _all the options_ I guess. There's no
reason to rebuild the exact same package you'll get from the repo.

E.g. I install all firefox's dependencies from pkg, then I build firefox from
ports with the GTK3 option. Same with packages that use openssl (I use
libressl). Never had any problems with that.

------
eclipsed
Best default ever: [https://shiro.apache.org/static/1.2.2/apidocs/src-
html/org/a...](https://shiro.apache.org/static/1.2.2/apidocs/src-
html/org/apache/shiro/mgt/AbstractRememberMeManager.html)

See DEFAULT_CIPHER_KEY_BYTES

Because no major companies forgot to change it when they used it?

------
loeg
This reads as unnecessarily nasty and mean-spirited. Sure, I am biased, I am a
FreeBSD developer.

~~~
Someone
I find it direct and nasty, but not mean-spirited. I think he does that
because he cares about this, and hasn't managed to get his message across.

And I think he has good points. In particular, ports running make as root
makes every buffer overflow in your C compiler, linker, and whatever other
tools build scripts run a potential root exploit. Yes, other security measures
such as pledge can decrease that risk, but why run the risk at all?

------
dwarman
My personal aphorism (for at least 20 years now):

Warman's Law: That which _can_ be configured _must_ be comfigured,

Corr.: Defaults Aren't.

Impl: running any program on its defaults will get you in trouble somewhere
down the line. This is no different. Configurations are there precisely to
accommodate each users' individual needs, and we are not all the same.
Typically defaults try to achieve useability by naive users, and usually do so
in a way that is wrong for the sophisticated users. As well as often not
chosen very well and really wrong for everybody. Then there is code written by
naive programmers who code the naive default and do not provide any
configuration because they are unaware of any other way to use the system. And
the other extreme of course - Windws anyone? Multiple places to configure
different aspects of a specific vehavior, and selection dialogues that "help"
by not showing sub-options not used by the current settings, making it
impossible to know the full set?

At least the /etc paradigm lets us get a canonical view of everything,
explorable with a simple text editor. This article actually shows the
advantages.

------
alwaysdownvoted
"I don't know anythng about IPFilter, nor do I know anyone who uses it, so
we'll pretend it doesn't exist."

If alternatives exist that would address the author's complaints (and they
do), but he doesn't know anything about them or anyone that uses them then
does he pretend they don't exist? What do you think?

------
xenophonf
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.

~~~
inopinatus
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)

------
dschiptsov
11/10 on arrogance and narcissism.

The defaults about swap and openssh are reasonable for high-performance
networking servers, which is what FreeBSD is for. Yes, compatibility and
performance _matters_. Ports are supposed to be installed before server is put
for production, and at that time running shit as root is not a big deal.

BTW, OpenBSD, with all respect for code quality and attention to details is
nowhere near in networking server performance and stability. Once I made an
OpenBSD/spark64 firewall, which, I think, is still in production, but apart
from packet filter and DNS server it was hardly usable for anything.

I am oldfag^W^W remember FreeBSD 2.0

