FreeBSD – a lesson in poor defaults • Hacker News Board

Re: FreeBSD – a lesson in poor defaults

#21

Post by washadjeffmad » Sat, Mar 19, 2016, 7:06 PM UTC

geofft wrote: post #9

egwynn wrote: post #6

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…

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.

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?

Re: FreeBSD – a lesson in poor defaults

#22

Post by msbarnett » Sat, Mar 19, 2016, 7:11 PM UTC

washadjeffmad wrote: post #21

geofft wrote: post #9

Earlier quoted context omitted.

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.

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?

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.

Re: FreeBSD – a lesson in poor defaults

#23

Post by werid » Sat, Mar 19, 2016, 7:26 PM UTC

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.

Author is an OpenBSD user/dev.

Re: FreeBSD – a lesson in poor defaults

#24

Post by jaxb » Sat, Mar 19, 2016, 7:36 PM UTC

loeg wrote: post #5

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

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

Re: FreeBSD – a lesson in poor defaults

#25

Post by marios » Sat, Mar 19, 2016, 7:59 PM UTC

teamhappy wrote: post #19

craftkiller wrote: post #13

Earlier quoted context omitted.

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

Also: - LLVM - Arm support - The handbook I do envy OpenBSD's pledge() and arc4random() though.

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.

Re: FreeBSD – a lesson in poor defaults

#26

Post by kev009 » Sat, Mar 19, 2016, 8:01 PM UTC

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.

Re: FreeBSD – a lesson in poor defaults

#27

Post by aduitsis » Sat, Mar 19, 2016, 8:07 PM UTC

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.

Re: FreeBSD – a lesson in poor defaults

#28

Post by teamhappy » Sat, Mar 19, 2016, 8:14 PM UTC

marios wrote: post #25

teamhappy wrote: post #19

Earlier quoted context omitted.

Also: - LLVM - Arm support - The handbook I do envy OpenBSD's pledge() and arc4random() though.

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 framewor…

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

Re: FreeBSD – a lesson in poor defaults

#29

Post by justinclift » Sat, Mar 19, 2016, 8:25 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

OpenBSD doesn't appear to have Infiniband support either. :(

Re: FreeBSD – a lesson in poor defaults

#30

Post by cm3 » Sat, Mar 19, 2016, 8:45 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

It's unfortunate that Shawn and Oliver decided, after failing to upstream their ASLR patches, to make HardenedBSD a full fork. I wish they would reconsider, because Konstantin Belusov has begun an upstream from scratch implementation of ASLR. But HardenedBSD is so much more than just ASLR and for a network facing OS it's crucial to have as many layers of mitigation as possible. Jails with Capsicum and ZFS are so promising already.