FreeBSD - a lesson in poor defaults

Maxnix said:
Really, really thank you jrm! :) It was very interesting and useful. I'm happy that I now know these aspects about FreeBSD and security in general! :)
Click to expand...
blakkheim obviously put a lot of time and thought into it, and it was reviewed by people who care about FreeBSD. Some of the points are subjective, but it's good to discuss them in a logical way so things move closer to the optimum.
 
jrm said:
blakkheim obviously put a lot of time and thought into it, and it was reviewed by people who care about FreeBSD.
Click to expand...
Surely, a big thank to him and to all the people that put their efforts in it. :)
jrm said:
Some of the points are subjective, but it's good to discuss them in a logical way so things move closer to the optimum.
Click to expand...
Right! :)
 
I've seen an article similar to this elsewhere a while back. I don't see anything new or anything we don't already know about. I also don't, necessarily, see problems or "poor" defaults. Defaults are used to get a system generally running, not run as you prefer it to be. And systems like FreeBSD don't become rock, stable by changing fundamentals on a whim without regard to what everyone is used to.

My example, he doesn't like sendmail in the base system but, then, where do error messages get sent? Store them somewhere? Then where? Now you have a new default everyone has to adapt to.

And on and on ...
 
Some of what he says does raise some questions. I'm no SSH expert but why are FreeBSD re-enabling deprecated ciphers that OpenSSH are removing? And do people use tcp_wrappers? I always saw it as a poor mans firewall.

The paragraph about NONE ciphers is interesting. I don't know whether it's possible for users with NONE enabled to end up creating insecure connections by accident, but several prominent BSD users have given me the impression that it can really speed up stuff like zfs streaming.

Not sure about the enabling firewall by default. The problem is how do you enable a firewall and make it actually useful without also causing problems for a lot of users. Personally I'm perfectly happy with having the choice of firewall there and enabling it if I want it. I tend to find them all a PITA, probably because I rarely use them. The majority of my servers have completely basic network config, and just live behind proper hardware firewalls. (Well I say hardware, they probably run some customised version of BSD/Linux, but they're a hell of a lot easier to manage than pf/ipfw)

I'm also on side with getting rid of Sendmail. I exclusively used Sendmail for years and always got on fine with it, but it is a bit archaic and monolithic. I've moved to Postfix in recent years and been much happier with it. To me this is a very similar situation to bind. We had a big, kitchen-sink DNS server built into FreeBSD for years when all it really needed was a simple resolver. In FreeBSD 10, if you want bind, you can install it from ports/packages, and as an extra plus it can be kept up to date without having to wait for OS updates. The only downside is I constantly keep typing dig on my 10.x machines, and drill on my 9.x machines...

It's the same with Sendmail, we only really need something easy to configure that is capable of submitting mail to an SMTP server, and delivering to the local delivery agent. If it supported TLS and simple LOGIN/PLAIN auth out of the box as well that would be outstanding. If users want Sendmail, installing the port is easy enough.

Having a restricted account to stage packages is a really interesting point. The staging process just builds the port and effectively installs it to $PORTDIR/stage. There's probably edge cases, but for the majority of ports why does that need to run as root? It makes sense to drop to a special port building account to do that.

Periodic is also another good point. I've seen dozens of posts on here from ZFS users who've had servers crash at 3am because periodic has thrashed their pool updating locate databases, or looking for left-over temporary files. On most of my FreeBSD VMs there are 4 or 5 periodic scripts I disable just because I don't really need them and it just causes unnecessary IO on my storage systems.

P.S. Referring to the rc.conf settings in the link, you should be able to disable sendmail with sendmail_enable="NONE" rather than adding 4 separate options. I can see why they made it continue to run the local daemon if you specify sendmail_enable="NO", as you do really need local mail delivery at a minimum, but personally I would of preferred NO to actually mean off like it does for every other daemon. When I first tried to fully disable Sendmail, it did cause a bit of confusion why NO didn't actually switch it off.

They could of used something like sendmail_enable="LOCAL" for local only, and possibly even made that the default. That way, you get local delivery by default. If you actually want sendmail fully running and accepting remote connections you set it to YES, and if you want it completely off because you're using something else, you set it to NO.
 
usdmatt said:
They could of used something like sendmail_enable="LOCAL" for local only, and possibly even made that the default. That way, you get local delivery by default. If you actually want sendmail fully running and accepting remote connections you set it to YES, and if you want it completely off because you're using something else, you set it to NO.
Click to expand...

In cases where people install FreeBSD in a non server or home situation this can actually be a bug. At least I seem to recall from my earlier installations that without a FQDN you will get errors. A "LOCAL" default makes sense.
 
Anyone who is really up to date with what's been happening on UNIX/UNIX -like systems in the last ten years is not going to use tcp_wrappers, they don't work basically. The staging issue is already being worked on but there's a lot of broken software (not ports!) that insist on being built as root by using chown(1)/chmod(1) where it's not really needed and those may not work under unprivileged user.
 
Some of these complaints should be moot soon with the (hopeful) arrival of base packages in 11. It sounds like there will be easy, fine-grained control for swapping out things like sendmail and openssl.
 
It would have been more helpful if he would have included links to discussions had in regards to his points. There may be valid reasons for some of them not mentioned.
 
I do have to agree with some of these points. Namely, that the defaults for periodic are at best weird, and that sendmail should be replaced with something simpler. Regular status reports are a great feature of FreeBSD, but they should warn when something isn't right, not generate 1500 words that amount to "Everything is fine." And I'd bet most of us only need a mailer in base to send those regular reports and tell us when cron jobs fail. And yes, I turned of the daily pkg security check. Not for system security reasons, but because not a week goes by without me being warned that some package has a security issue that doesn't impact me. A weekly check would make more sense in my opinion.

I don't know enough about SSL or NTP to say what the correct course of action is there, but it does seem I update my system to resolve problems with those two things more than anything else.
 
I'm going to beg to disagree with some of the suggestions made here. I've been building up a FreeBSD server to replace a Solaris 10 server, and thus far, it has pretty much been a piece of cake.

Having sendmail installed as the SMTP default is a big plus for me. I've used sendmail ever since there was a sendmail. My access file is huge, built over a good 15 years. And the other configuration stuff I have in Solaris just moves right over to FreeBSD.

Tcpwrappers may be bleeding edge of the 1990's, but all of my boxes get it anyway, just to be sure that anything that leaks through my firewalling gets caught. I'm glad to see it as a default on initial install. Using the various NIC-level firewalling programs is in addition, and yes, I know that moving firewalling out to the entry point slows down the script kiddies when tcpwrappers doesn't. I would just as soon have tcpwrappers in place and build NIC firewalling than having someone else try to guess what my firewalling policies need to be in a bunch of preinstalled tables.

I was disappointed to see that bind is not the default named. No big deal to built from /usr/ports, I suppose. I don't know what unbound does to performance, but Solaris has a similar caching setup that is slower than a caching bind.

One reason for choosing FreeBSD (aside from having run a much older version years ago for a while) was that it's Unix---the real deal, not just another Windows/Mac replacement. To me, the less Linux stuff, the better.
 
I hope the new release system, with fewer parallel releases to support, will make it less necessary to support all kind of old stuff, that need patching away from secure software, recommended setting. Scarry to read what OP post about secure OpenSSH, and how it made less secure with, FreeeBSD security team supporting that negative development.

I gain respect for OpenBSD philosophy of clean and simple, might FreeBSD have a little to learn from them? And now more understand what they mean with it (Dont do like FreeBSD and get fat with patches, and weird old stuff, that decrease security, and makes it hard to keep up to date for the devs.)
I look forward to FreeBSD11
 
jrm said:
I'm told Oko's spirited style pushed a moderator too far.
Click to expand...

I liked him. He spoke loud and true.

So long Oko, so long... :/...:(


Oldrancher said:
One reason for choosing FreeBSD (aside from having run a much older version years ago for a while) was that it's Unix---the real deal, not just another Windows/Mac replacement. To me, the less Linux stuff, the better.
Click to expand...

That's what got me. Since the day I first tried it almost a decade ago, it felt right and I kept coming back to it, it wasn't until I decided to try it on the bare metal that I found out how good it really was. Never looked back.
 
I don't really get the arguments against removing Sendmail, just like I didn't get them against Bind. If you want Sendmail, you type pkg install sendmail, and 10 seconds later it's installed. That is the only downside to removing it and within seconds it's back in the system again, everything else is a positive:
  • The core devs no longer have to mess about importing fixes into HEAD, then into the various stable branches, then creating patch releases so you can get them.
  • If you install Sendmail you get the latest port, rather than whatever happens to be in your FreeBSD version
  • You can update by just using port/pkg update tools.
  • If you need to rebuild (fairly common for people wanting SASL support), you can just use the options in the port when you install rather than having to get the entire FreeBSD sources and mess about adding compile options.
  • The majority of users who don't want a mail server and just need to be able to submit mail to another system can just use whatever the modern lightweight replacement is. (Of course this is the only thing holding up removing Sendmail. I have no experience with OpenSMTPD so I don't know how well that would fit. With bind, unbound came along which is much easier to use, and only really tries to be a high performance resolver. I've not personally done any testing but I would hope it compares well to bind as a caching resolver)
For me I have about 6 mail servers. Some handle mail coming in to users, others are just SMTP relays. Most run Sendmail although I've migrated a few to Postfix recently and seeing how well that's running, I would actually like to change the rest as well. Everything else, the vast majority of my servers, don't need to do anything other than push mail to one of the relays, and I would be perfectly happy if Sendmail was gone from all those systems and I just had a simple submission daemon instead.
 
Thanks for the link, interesting stuff to read.
I'm glad I was not the only one who was bothered by the default permissions of configuration files such as firewall rules, default home users permissions and mainly, /root permissions. This does bother me a lot.

And as make installworld overwrites it each and every time I had to create a script that runs every day to check it - as I always forgot about it after upgrade.
 
Oldrancher said:
I'm going to beg to disagree with some of the suggestions made here.
Click to expand...

No offense to you, but I can't help but notice that you're fine with the defaults simply because they don't require you to learn new software and change old habits.

usdmatt said:
The majority of users who don't want a mail server and just need to be able to submit mail to another system can just use whatever the modern lightweight replacement is. (Of course this is the only thing holding up removing Sendmail. I have no experience with OpenSMTPD so I don't know how well that would fit.
Click to expand...

mail/dma was the replacement I saw promoted for a bit. It was even briefly committed to -CURRENT, then removed. Since I only need a mailer to get periodic and cron reports for my laptop and home server, I decided to remove sendmail entirely and try out dma for a while. That was some time ago, and it's done the only thing I need it to every day in that time.

It's certainly no solution for anyone that wants to run a fully functional mail server, and is only designed for LAN use, but the only rationale for the presence of sendmail in base that someone might eventually need a mail server, so just stick it there. And frankly, all I ever seem to hear about sendmail is that it's a very reliable and complete e-mail solution, once you've sunk a month of your life into actually getting it to work and sworn eternal allegiance and the blood of your first-born to Khorn, Lord of Chaos.
 
usdmatt said:
I don't really get the arguments against removing Sendmail
Click to expand...
A similar discussion I read, years ago, (or was it in a book?) that gives the reason for all this. I don't recall much of it but, essentially, it had to do with the fact that there are thousands and thousands of users around the world who rely on all these things being there and it's part of what makes FreeBSD steady and reliable. Jumping on any new thing needs lots of proof of its reliability as well as lots of notice of a change which also requires lots of testing first.

You don't want to become another Linux.
 
You must log in or register to reply here.
Back
Top