FreeBSD - a lesson in poor defaults

[drhowarddrfine]

if you want FreeBSD to become more like OpenBSD

Which is a reason why "Why isn't FreeBSD more like..." questions aren't allowed here.

 

[eternal_noob]

Rather, "Why isn't FreeBSD more secure?". And this question should be allowed.

 

[drhowarddrfine]

eternal_noob Yes but it's a misleading question prone to argument. A better question would be, "How can I make my installation more secure?"

 

[zirias@]

Rather, "Why isn't FreeBSD more secure?". And this question should be allowed.

That's a gross over-simplification, and a sign the narrative of that "article" got through.

Security is never an absolute thing. It depends on specific threats, risk analysis, etc.

Let's just pick two examples:

In this very thread, someone agreed that "swap should always be encrypted". Really? What's the threat here? Clearly, it's hardware falling into the wrong hands. When that happens, encrypted swap helps keeping private things secret. But what if that isn't even a realistic scenario for you? A bad thing that can happen with encrypted swap on FreeBSD is a resource deadlock (as GELI sometimes needs to dynamically allocate memory) in situations of heavy memory pressure. Although unlikely, I experienced that during a massive poudriere bulk run. And of course, it always costs a tiny bit of computing power. So, it's a trade-off.

Other example, this article states that intel's hyperthreading must be disabled by default (btw, it is on OpenBSD). Looking at the threat again: side-channel attacks. Especially relevant when running virtual machines operated by potentially untrusted parties. Potentially relevant on any "shared" system. But nowhere near the immediate threat of e.g. some remote vulnerability. Whether you must disable it very much depends on your scenario. In this case, disabling it will cost you almost half of your processing power.

FreeBSD is not OpenBSD. OpenBSD will always pick defaults, so they are secure in any scenario you could think of (and still, even OpenBSD can't magically protect you from any vulnerability found in some software). FreeBSD prefers for example not to impair performance for everyone by default, not to break things without warning, etc.

If you think picking defaults "the OpenBSD way" is the only correct way, then, well, just use OpenBSD.

 

[getopt]

Other example, this article states that intel's hyperthreading must be disabled by default

But in the article can be read:

Intel's hyperthreading technology (also known as SMT, Simultaneous MultiThreading) has proven itself to be insecure, so it should be disabled here.

From RFC 2119:

MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.

SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

 

[zirias@]

Ah, well. As already stated in a private message concerning this, "should" wouldn't really describe what the author of this article means.

To understand it, you probably have to read the whole article. Then, you will understand (e.g. through "stylistic" elements like sarcasm) that this author truly believes their views are the only correct ones. They don't use words like "must" a lot, and they use "should" and similar quite often, but that can't hide the intentions. (It is OTOH a nice stragety to enable "Wortklauberei" like this later)

I didn't cite the article. I reproduced part of its contents in my own words. Reproducing the word "should" there would only make it less accurate.

edit: BTW, citing some definitions obviously taken from formal specifications (if I'm not mistaken they might come from IETF) here is very off-topic. We're really not talking about formal language here, to the contrary.

 

[hardworkingnewbie]

In this very thread, someone agreed that "swap should always be encrypted". Really? What's the threat here? Clearly, it's hardware falling into the wrong hands. When that happens, encrypted swap helps keeping private things secret. But what if that isn't even a realistic scenario for you? A bad thing that can happen with encrypted swap on FreeBSD is a resource deadlock (as GELI sometimes needs to dynamically allocate memory) in situations of heavy memory pressure. Although unlikely, I experienced that during a massive poudriere bulk run. And of course, it always costs a tiny bit of computing power. So, it's a trade-off.

Obviously the threat model with unencrypted swap is that cryptographic keys could be stored in it unencrypted, and if somebody switches power off could peel them out of the swap space. Encrypted swap space might help against this.

Then again, it's known since two decades by now that modern RAM hardware does not lose data after power loss immediately, but over time. And if you cool it down, then you can peel that data out of the RAMs instead. So encrypted swap obviously cannot protect against this sort of attack.

Cold boot attack - Wikipedia

en.wikipedia.org

 

[zirias@]

Obviously the threat model with unencrypted swap is that cryptographic keys could be stored in it unencrypted

That's just one specific example of something that should stay secret (of course, an important one!). But to make it a threat, someone unauthorized must gain access to the hardware.

 

[mer]

Security is never an absolute thing. It depends on specific threats, risk analysis, etc.

Yes. This. Upvote a million times as all the cool kids nowdays say (I think. I'm old, so I don't know).

CVEs: It's always good practice to read them and try and understand them, simply because it makes one aware of potential threats. As a sysadmin you then determine if they apply to the systems you are responsible for. Part of that is determining "criticality" of the CVE or "how soon do I need to patch or mitigate on my systems".

There are some that sound scary, but when you read it and they say "must have physical access to the system in order to reboot it and hit this key combination 12 times during the loader" well, that can be lower on the critical list or deferred.
Remote execution gain root through web server frameworks? Immediate action IF the system is actually serving web stuff.

Sendmail: home of the original remote exploit (Thank you Robert Morris for a worm). Yes, lots of CVEs over the years, but in the default configuration after a new install is it really a concern? Long time since I've done an install but I thought it defaulted to local host only delivery out of the box, which as an exploitable footprint is pretty small.

Discussions about security are never a bad thing as long as "religious" positions are not taken. IPFW vs pf lots of good discussions can be had but have to start from the same point: what are the requirements for THIS system.

A lot goes back to my earlier comment about how information is presented. Even the most contentious, presented properly will lead to fruitful discussions. Present it wrong (typically "my way or the highway" or "you are just to stupid to understand what I'm saying") and things come across as trollish.

As for the article itself, there are some good points in it, some that I disagree with because they don't fit my needs/systems, some that are in the middle that are up for discussion.

 

[zirias@]

As for the article itself, there are some good points in it

Just out of curiosity (and, maybe, there is something to discuss), which are these? Are these points that weren't already adressed (like, e.g., being able to build ports as non-root, that works...)?

 

[eternal_noob]

That's a gross over-simplification, and a sign the narrative of that "article" got through.

That's a sign for nothing, i tend to over-simplify things, but this is me. I didn't even read that article.

 

[zirias@]

i tend to over-simplify things, but this is me.

Looking at your avatar, this comes a little unexpected ?. Well, then I misinterpreted your reaction, that's great .

 

[eternal_noob]

Looking at your avatar, this comes a little unexpected

I thought that logic WAS simple. ?

 

[mer]

Just out of curiosity (and, maybe, there is something to discuss), which are these? Are these points that weren't already adressed (like, e.g., being able to build ports as non-root, that works...)?

For me personally, some of the sysctl settings I thought were interesting (to me) like some of the network settings for security, the pkg stuff, well even Ubuntu you have to at least sudo if you actually want to install or upgrade.
SSL/TLS stuff: interesting (to me) but at work we run into issues where having fielded systems not yet upgraded you need the deprecated values sometimes if you want to talk to them and actually upgrade. If something is browser based and your browser deprecates some stuff (Chrome and Firefox have both done this) you wind up not being able to talk to a fielded system so you can upgrade it.
Compile time options, well they only matter if you are actually compiling.

So for me, changes in sysctl were the ones personally interesting, mostly because I routinely set some of them on my systems and have for a while, so should they be defaulted? I don't know, my bias is "no", but perhaps better documentation around them would help.

 

[Deleted member 65380]

But to make it a threat, someone unauthorized must gain access to the hardware.

Not only the hardware, that just makes things easier. Access to the operating system (with a current or future method to elevate to root, however that may be achieved).

 

[edthesmokebeard]

Like these forums, Reddit are also a censorious bunch.

Here's an idea. Why don't you take that article, turn it into a wiki page (a reponse to xyz) and update and correct whatever needs correction. Just don't hide what you don't like... this aspect is something you "party faithful" certainly won't want to entertain.

This is the answer. But its far easier to drag out 20 year old sendmail vulnerabiltiies.

 

[edthesmokebeard]

Yes,there are many bad opinions to FreeBSD but the encrypted swap was right,is important to encrypt it
I check it with his example

I see no basis for this. If someone has your physical machine, all bets are off. There might be no reason NOT to encrypt it, but it's hardly universal that 'its important to encrypt it".

 

[edthesmokebeard]

Ah, well. As already stated in a private message concerning this, "should" wouldn't really describe what the author of this article means.

To understand it, you probably have to read the whole article. Then, you will understand (e.g. through "stylistic" elements like sarcasm) that this author truly believes their views are the only correct ones. They don't use words like "must" a lot, and they use "should" and similar quite often, but that can't hide the intentions. (It is OTOH a nice stragety to enable "Wortklauberei" like this later)

I didn't cite the article. I reproduced part of its contents in my own words. Reproducing the word "should" there would only make it less accurate.

edit: BTW, citing some definitions obviously taken from formal specifications (if I'm not mistaken they might come from IETF) here is very off-topic. We're really not talking about formal language here, to the contrary.

Then that's the fault of the author. If he wants to be taken seriously, he needs to write seriously.

 

[mer]

I see no basis for this. If someone has your physical machine, all bets are off. There might be no reason NOT to encrypt it, but it's hardly universal that 'its important to encrypt it".

Disk encryption in general, in my opinion, can be overused. One thing people forget or gloss over is that encryption only protects cold disks or unmounted partitions. Machine up, devices/partitions mounted, the data is vulnerable. I also question "why do people encrypt the entire disk?" Is there really anything in /etc that needs to be encrypted? That's my opinion and I'm going to tell anyone they're wrong for doing it their way.

 

[zirias@]

mer disk encryption is useful. Once again, it depends on your threat model. You're completely right, it does nothing for you on a running machine. I think that's the main problem with both the article discussed here, and how people discuss it. It's a fundamental misunderstanding that any single "security measure" could ever be something "everyone needs". It's OpenBSD's "mission statement" to deliver a system that's as secure as possible out of the box for any scenario (and if that scenario doesn't apply to you, you have to change settings e.g. in order to get better performance). FreeBSD defaults focus on a more "generic" view. Still, you can change what you don't like.

Not only the hardware, that just makes things easier. Access to the operating system (with a current or future method to elevate to root, however that may be achieved).

Encrypted swap won't help with this. On a running machine, there will be a "mapped" device allowing access to the unencrypted data.

 

[Deleted member 43773]

Disk encryption in general, in my opinion, can be overused.

depends on:
- the machine you use
- the concerned data
- your personal attidude between careless and paranoid

In german we have a saying:
"Opportunity makes thiefs"
Even the worst lock is better than none.

On my desktop pc the disks are not encrypted.
I keep sensitive data in several encrypted files, containers, archives.
For the rest anybody gets physical access to the machine (and knows FreeBSD) can get to anything.
But he/she needs to break in my home first.

On my laptop the entire disk is encrypted.
Cause it can be stolen or get lost.
And it's just less effort to enter the password once at booting, than handle with encryption/decryption all the time.

What are you doing, if you find a lost USB flash drive on the street?
You'll take a peek what's on it, of course ?
If the stick would be encrypted - even with something light every noob-hacker would laugh about -
you'd consider: is it worth the effort or do I just format it? ?

 

[mer]

depends on:
- the machine you use
- the concerned data
- your personal attidude between careless and paranoid

Yep, that's why I said "My opinion" and "in general". Too many people (corporations) simply say must encrypt everything all the time without thought on "who, what why" that is the part I've always disagreed with. Encrypt separate devices/partitions hold financial data? Absolutely a good idea. The CFO laptop that he takes with him on the train, to meetings? Yep likely candidate for whole disk encryption. The shared family PC? Not the right choice (my opinion) but mom & dad should have a separate data disk encrypted having the family finances on it.

I don't think I was clear enough: I don't disagree with disk encryption, but blindly doing whole disk encryption without thinking is what I disagree with.

On my laptop the entire disk is encrypted.
Cause it can be stolen or get lost.
And it's just less effort to enter the password once at booting, than handle with encryption/decryption all the time.

And that is pretty much the exception to my opinion: laptops that travel or could be easily stolen.

What are you doing, if you find a lost USB flash drive on the street?

Me personally? Look to see if there is any identifying info on it so I can return it, otherwise toss it in the trash. Easy way to get someone to start loading malicious stuff on your computer.

 

[Crivens]

Is there really anything in /etc that needs to be encrypted?

Maybe not. But in /bin or /sbin for sure. Encryption ensures that no one tamperes with f.e. login while your system is down to slip you a souped up one.

 

[hardworkingnewbie]

Then that's the fault of the author. If he wants to be taken seriously, he needs to write seriously.

If that author really would have wanted to be taken seriously, he would have stated his name in the file like it is good common practice for various reasons. He didn't.

With a little bit of research it's no secret who created that file: somebody going by the pseudonym of TJ or blakkheim, a former producer of the BSDnow podcast.

But still - not in the file nor homepage, which speaks volumes by itself.

 

[mer]

Maybe not. But in /bin or /sbin for sure. Encryption ensures that no one tamperes with f.e. login while your system is down to slip you a souped up one.

That would be a bit easier than read only media for the system files, or doing mtree stuff during boot or "TPM" type of stuff.

Writing under a pseudonym is a long standing tradition, probably started as soon as there were cave drawings.

I don't necessarily think it's a bad thing, but my opinion (again, mine, agree, disagree, all good to me) is if one is going to write an article/book/paragraph criticizing something, you should own up to it. It's like restaurant or product reviews: very easy to leave a negative one without ever having eaten there or used the product. Let's face it, we are all human (I know I'm assuming a lot about myself and others here) and we have biases and preferences. Just because something doesn't work the way "I" want it to out of the box doesn't mean it's garbage, heck pick your favorite desktop environment or window manager. 50% love it, 50% hate it, the other 27% are undecided. So a critical review of anything should be owned up to, simply for readers to be aware of potential bias. The bias itself isn't wrong, it is simply a fact that indicates why the author may say what they do.

If everyone agreed on everything why bother getting out of bed?