8 ms·

FreeBSD – a lesson in poor defaults

208 points by ran290 11y ago

vbit 11y ago
Some discussion here:https://www.reddit.com/r/freebsd/comments/4azhmm/freebsd_a_lesson_in_poor_defaults/ https://www.reddit.com/r/freebsd/comments/4azhmm/freebsd_a_l...
- Gracana 11y ago
  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.
ComputerGuru 11y ago
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 11y ago
  I find that thumper's rule is very useful when dealing with zealous members of the OpenBSD community.
  - smcl 11y ago
    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 11y ago
      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 11y ago
        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. ;)
loeg 11y ago
This reads as unnecessarily nasty and mean-spirited. Sure, I am biased, I am a FreeBSD developer.
- ta0967 11y ago
  i'm a FreeBSD user since 4.3 or 4.4, and to me it reads quite fine. sure, the frustration shines throught, but he's got a bunch of valid points there.
- jaxb 11y ago
  The OP certainly wasn't trying to be neutral (wikipedia-style), but most of it reads as 'it is 2016, do you know what your operating system is (not) doing to protect you?'
- Someone 11y ago
  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?
- chriscappuccio 11y ago
  Lower your defenses, consider the issues, address them.
egwynn 11y ago
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.
- xenophonf 11y ago
  I think it's more of a defensive thing, where pkg should drop privileges unless it's performing an operation that absolutely requires root access. Technically, `pkg audit` doesn't need to run as root, since it only downloads a package catalog and compares it to the list of installed packages.
- geofft 11y ago
  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 11y ago
    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 11y ago
      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.
woodman 11y ago
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 11y ago
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 11y ago
  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
  - cm3 11y ago
    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.
    - armitron 11y ago
      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.
      - ceratopisan 11y ago
        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?
        armitron 11y ago
        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.
dwarman 11y ago
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.
deleted 11y ago
[deleted]
eclipsed 11y ago
Best default ever: https://shiro.apache.org/static/1.2.2/apidocs/src-html/org/apache/shiro/mgt/AbstractRememberMeManager.html https://shiro.apache.org/static/1.2.2/apidocs/src-html/org/a... See DEFAULT_CIPHER_KEY_BYTES Because no major companies forgot to change it when they used it?
kev009 11y ago
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 11y ago
  I believe there's work underway to replace it with Dragonfly's dma.
  - swills 11y ago
    dma is already in base, just not default
aduitsis 11y ago
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 11y ago
  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 11y ago
    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.
  - aduitsis 11y ago
    As floatboth said, there's really no reason to build every minor package by hand. Only those that you want to change the config or their dependencies.
  - Sanddancer 11y ago
    You can mix and match. The only problem comes if you have flags in a dependency that don't match the flags in the package pkg wants to install. A bit bothersome, but it allows you the best of both worlds.
- floatboth 11y ago
alwaysdownvoted 11y ago
"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?
drdaeman 11y ago
> (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.
dschiptsov 11y ago
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
xenophonf 11y ago
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 11y ago
  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)

208 points by ran290 11y ago

vbit 11y ago

Some discussion here:https://www.reddit.com/r/freebsd/comments/4azhmm/freebsd_a_lesson_in_poor_defaults/ https://www.reddit.com/r/freebsd/comments/4azhmm/freebsd_a_l...

Gracana 11y ago
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.

ComputerGuru 11y ago

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 11y ago
I find that thumper's rule is very useful when dealing with zealous members of the OpenBSD community.
- smcl 11y ago
  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 11y ago
    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 11y ago
      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. ;)

loeg 11y ago

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

ta0967 11y ago
i'm a FreeBSD user since 4.3 or 4.4, and to me it reads quite fine. sure, the frustration shines throught, but he's got a bunch of valid points there.
jaxb 11y ago
The OP certainly wasn't trying to be neutral (wikipedia-style), but most of it reads as 'it is 2016, do you know what your operating system is (not) doing to protect you?'
Someone 11y ago
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?
chriscappuccio 11y ago
Lower your defenses, consider the issues, address them.

egwynn 11y ago

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.

xenophonf 11y ago
I think it's more of a defensive thing, where pkg should drop privileges unless it's performing an operation that absolutely requires root access. Technically, `pkg audit` doesn't need to run as root, since it only downloads a package catalog and compares it to the list of installed packages.
geofft 11y ago
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 11y ago
  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 11y ago
    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.

woodman 11y ago

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 11y ago

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 11y ago
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
- cm3 11y ago
  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.
  - armitron 11y ago
    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.
    - ceratopisan 11y ago
      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?
      - armitron 11y ago
        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.

dwarman 11y ago

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.

deleted 11y ago

[deleted]

eclipsed 11y ago

Best default ever: https://shiro.apache.org/static/1.2.2/apidocs/src-html/org/apache/shiro/mgt/AbstractRememberMeManager.html https://shiro.apache.org/static/1.2.2/apidocs/src-html/org/a... See DEFAULT_CIPHER_KEY_BYTES Because no major companies forgot to change it when they used it?

kev009 11y ago

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 11y ago
I believe there's work underway to replace it with Dragonfly's dma.
- swills 11y ago
  dma is already in base, just not default

aduitsis 11y ago

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 11y ago
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 11y ago
  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.
- aduitsis 11y ago
  As floatboth said, there's really no reason to build every minor package by hand. Only those that you want to change the config or their dependencies.
- Sanddancer 11y ago
  You can mix and match. The only problem comes if you have flags in a dependency that don't match the flags in the package pkg wants to install. A bit bothersome, but it allows you the best of both worlds.
floatboth 11y ago

alwaysdownvoted 11y ago

"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?

drdaeman 11y ago

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

dschiptsov 11y ago

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

xenophonf 11y ago

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 11y ago
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)