FreeBSD – a lesson in poor defaults

https://vez.mrsk.me/freebsd-defaults.txt?hn

by Basile • 10 years ago

94 52 10 years ago

vez.mrsk.me

stonogo• 10 years ago

This person means well, but suffers from the same myopia a lot of security-first people do: making these changes to default settings is a huge violation of expectations, and the changes need to be widely publicized once they are decided upon. Suddenly dropping support mid-cycle for tons of things will result in pitchforks and torches from people who, despite the constant insinuations of this document, do in fact know what they are doing.

This document, in short, makes a great to-do list but completely ignores the roadbuilding that needs to happen to get people ready and on board.

fleitz• 10 years ago

Exactly. I don't see these so much as poor choices as not security focused choices. Perhaps OpenBSD might be a better fit for this users needs.

api2• 10 years ago

This is what's wrong with infosec. The majority of security people seem to have no concern for any other issue, resulting in them giving a lot of ham fisted advice that gets ignored. In the end security is worse as a result.

I worked in infosec for a while and saw it at the org level:

1. Security recommends something with no concern for how it inconveniences (or worse) the users.

2. Users ignore or even actively work around security.

3. Users get pwned and blame security.

4. Security gets mad, calls users stupid, goes back to making ham fisted recommendations that everyone ignores because they have to get their work done.

5. Goto 1.

In the end I concluded that we (security) were at fault. In many cases there were user sensitive options and I would make an effort to find them, but most of security actively had contempt for anyone outside security and didn't care.

X86BSD2• 10 years ago

That is just common in IT not specifically the security nerds. Every group has their little fiefdom. DBAs, data architects, Unix admins, etc.

jms703• 10 years ago

This isn't about myopic security recommendations. These are just plain bad defaults and a failure to manage tech debt. No one that "knows what they are doing" wants to accept these risks and addressing them doesn't hurt users. Fixing these problems is totally realistic.

acidbaseextract• 10 years ago

The contempt for people outside security, and their perspectives, is a huge problem. Another great article, "Infosec's Jerk Problem" (2013):

http://adversari.es/blog/2013/06/19/cant-we-all-just-get-alo...

byuu11• 10 years ago

I have to agree.

I'm reminded of OpenBSD's move in 6.0 to enforce W^X on binaries. This breaks the use of my cooperative threading library: in order to avoid requiring specific compilers/assemblers (for the portion that's impossible to write in pure C), I use ~50 bytes of pre-compiled code so that it'll compile anywhere. To do that, I have to mark the block R|X. But I can't know with 100% certainty that the codepage doesn't overlap with something that was writable (since there is no mgetprotect), so I have no choice but to set R|W|X.

So probably what I'll have to end up doing is allocate at least three codepages at run-time, set to R|W, copy the code there, then set R|X, and take a performance penalty for needing a pointer to the code block.

What I would like to see FreeBSD do to help with migrating to stronger security is something like "freebsd-harden" that you run once after a new installation or version upgrade, and it will walk you through a series of yes/no prompts, and advise, "if you aren't sure, say no."

deaddodo• 10 years ago

HardenedBSD[1] is FreeBSD pre-hardened. This is one of the few times I agree with a parallel sister project over multi-paradigm design, since they make pretty significant changes to the Kernel+World[2] that aren't necessarily beneficial to home users.

1 - https://hardenedbsd.org/

2 - https://hardenedbsd.org/content/freebsd-and-hardenedbsd-feat...

microtonal• 10 years ago

Actually, they now have such a post-install script:

https://reviews.freebsd.org/D6826 https://wiki.freebsd.org/WhatsNew/FreeBSD11#Security

JoshTriplett4• 10 years ago

(Note: I agree with your main point that changing defaults can cause problems, and security needs to balance with usability or people won't use it.)

For that 50-byte block of code, on most platforms, you could tell the compiler or linker to put it in the text section directly along with the rest of the code, rather than in the data section. A linker script or a section attribute can do that. Then you can just call it using the appropriate symbol.

I just tested this, with a manually assembled array of bytes, using both of those methods, and both of them work.

Here's the linker script approach:

    /tmp$ cat main.c
    unsigned long long add(unsigned long long, unsigned long long);

    int main(void)
    {
        return add(23, 45);
    }
    /tmp$ cat add.c
    unsigned char add[] = {
        0x48, 0x89, 0xf8, /* mov %rdi,%rax */
        0x48, 0x01, 0xf0, /* add %rsi,%rax */
        0xc3,             /* retq */
    };
    /tmp$ cat demo.ld
    SECTIONS {
        .text : {
            main.o(.text);
            add.o(.data);
        }
    }
    /tmp$ gcc -c main.c -o main.o
    /tmp$ gcc -c add.c -o add.o
    /tmp$ gcc demo.ld -o demo
    /tmp$ ./demo ; echo $?
    68

While this won't work on every possible platform, in practice it'll work for almost any platform you might care about.

restalis• 10 years ago

"in order to avoid requiring specific compilers/assemblers, I use ~50 bytes of pre-compiled code so that it'll compile anywhere"

That is a rather odd conclusion. The pre-compiled code is supposed to be a worse solution than having assembler bits.

bonzini2• 10 years ago

I use ~50 bytes of pre-compiled code so that it'll compile anywhere. To do that, I have to mark the block R|X.

Memory is cheap; mmap 4K of R|W RAM, copy the code, and mprotect it to R|X.

vacri• 10 years ago

Previous discussion: https://news.ycombinator.com/item?id=11318508

X86BSD2• 10 years ago

Not to mention he doesn't understand what flipping these defaults actually will do.

They sound great but without understanding exactly what happens when some of these switches are flipped you're going to wind up breaking other things because you simply do not have the knowledge to understand these features in depth.

His heart may be in the right place but he needs more experience and wisdom on how things work on a more fundamental level.

karma_vaccum123• 10 years ago

My least favorite FreeBSD default: permissions for CD/DVD burning.

I get the high-minded position FreeBSD takes here, but it is also a total PITA and it seems pretty clear that if you are putting a CD/DVD in a host's tray, you have console access.

byuu11• 10 years ago

Yeah, it's pretty nuts having to study the output of camcontrol and /dev, creating a devfs ruleset, adding that to /etc/rc.conf, adding your CD drive into /etc/fstab, and then tweaking a sysctl, just to burn a CD.

I am hard-pressed to think of the security risks involved in a user being able to burn a CD. Short of some kind of highly-confidential server with no internet access, where you'd probably want the whole machine inside a locked cage anyway.

toast03• 10 years ago

There's a cd in the tray, but we don't know who put it there. Maybe if you're logged in on a specific terminal?

I could contrive some scenarios where it would be undesirable though: Maybe if there's a rewritable (or not finalized write once) disc also in the system for something important? Let's say, a diskless system without pxe support, so it boots from a cd drive, but doesn't mount it. An unauthorized user with access to the burner could disrupt the next boot.

loeg2• 10 years ago

Minor nit: HPN has been dropped from openssh since this was written.

unethical_ban• 10 years ago

Why would high performance networking be dropped from the default? I learned of its existence a few weeks ago and was wondering when it would make it in.

loeg2• 10 years ago

No one was available to benchmark HPN vs no-HPN to illustrate it still made a difference.

sverige• 10 years ago

It sounds like he needs an OS built on "default deny" principles. The best one for that is OpenBSD, and he recommends porting over three or four packages from OpenBSD. Really, he'd be happier running that, I think. I know I was when I first started exploring the BSDs. I tried FreeBSD, PC-BSD, and DragonflyBSD before settling on OpenBSD.

Default deny makes the most sense if you are interested in security. Sure, it can be a PITA to set up .conf files at first and get the packages you need, but once past the learning curve, it's the simplest thing to maintain.

FreeBSD reminds me a lot of various flavors of Linux I've tried in the (distant) past. All kinds of stuff running by default, old packages for compatibility, etc.

Security may not be important for many people till it's too late, but it's one of those things that pays dividends in what doesn't happen. Hard to sell if you've never been pwned.

jlgaddis2• 10 years ago

Don't quote me on it, but I'm pretty sure TJ is an OpenBSD developer.

micro_softy• 10 years ago

You never tried NetBSD?

If you are suggesting NetBSD has more things enabled by default than OpenBSD I would bet that is incorrect. I have tried a lot of different projects and NetBSD is the best I have seen for not enabling anything. It forces you to figure things out.

Whenever I read OpenBSD mailing lists or blogs, they often seem more aggressive in trying to make their users adhere to the default system provided. That's fine, but NetBSD generally does not do this. Users are not assumed to be idiots and are not discouraged from experimentation.

The BSD projects share more similarities than differences. None of them require anyone to use the entire base system or the defaults. Users can compile their own kernels, write their own configs e.g., based on examples provided, and cherry pick utilities.[1] In my opinion this is made just a tad easier than with Linux.

1. But if you do this with OpenBSD and advertise it, I think you may draw some criticism. Frankensystem, etc. They are not encouraging experimentation, they are encouraging conformity.

fowl2• 10 years ago

So, uh, why doesn't he just use OpenBSD? They take security seriously. (not being snarky, really!)

jlgaddis2• 10 years ago

I'm pretty sure he does. I think he's an OpenBSD developer.

gonzo• 10 years ago

TJ isn't a dev, but he's a fan of OpenBSD.

tachion• 10 years ago

A lot of these points have been addressed in one way or another - 11.0-RELEASE has a new installer dialog[0] with multiple hardening options available. These are OFF by default in 11.0-RELEASE due to POLA principle, but they are to be enabled to ON by default in future releases (hopefully in 11.1).

[0] https://secure.freshbsd.org/commit/freebsd/r302897

cpach• 10 years ago

Dupe: https://hn.algolia.com/?query=FreeBSD:%20a%20lesson%20in%20p...

FreeBSD – a lesson in poor defaults

Related Stories