# FreeBSD - a lesson in poor defaults



## jrm@ (Mar 18, 2016)

This is an opinion piece by blakkheim (aka TJ), the former producer of the BSDNow poscast.

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


----------



## gofer_touch (Mar 18, 2016)

Hmm. Oko is going to love this one!


----------



## Maxnix (Mar 18, 2016)

jrm said:


> This is an opinion piece by blakkheim (aka TJ), the former producer of the BSDNow poscast.
> 
> https://vez.mrsk.me/freebsd-defaults.txt


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!


----------



## Maxnix (Mar 18, 2016)

gofer_touch said:


> Hmm. Oko is going to love this one!


We'll wait for his toughts about the topic!


----------



## jrm@ (Mar 18, 2016)

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!


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.


----------



## Maxnix (Mar 18, 2016)

jrm said:


> blakkheim obviously put a lot of time and thought into it, and it was reviewed by people who care about FreeBSD.


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.


Right!


----------



## drhowarddrfine (Mar 18, 2016)

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


----------



## jrm@ (Mar 18, 2016)

drhowarddrfine said:


> I've seen an article similar to this elsewhere a while back.


Do you have a link?

The closest I could find was http://www.bsdguides.org/2005/hardening-freebsd/.


----------



## usdmatt (Mar 18, 2016)

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.


----------



## Deleted member 9563 (Mar 19, 2016)

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.



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.


----------



## kpa (Mar 19, 2016)

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.


----------



## jrm@ (Mar 19, 2016)

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.


----------



## protocelt (Mar 19, 2016)

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.


----------



## ANOKNUSA (Mar 19, 2016)

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.


----------



## drhowarddrfine (Mar 19, 2016)

jrm said:


> Do you have a link?


No. I read it a year or two ago. It wasn't as old as yours.


----------



## jrm@ (Mar 20, 2016)

gofer_touch said:


> Hmm. Oko is going to love this one!


I'm told Oko's spirited style pushed a moderator too far.


----------



## Oldrancher (Mar 20, 2016)

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.


----------



## Psypro (Mar 20, 2016)

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


----------



## zspider (Mar 20, 2016)

jrm said:


> I'm told Oko's spirited style pushed a moderator too far.



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.



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.


----------



## Crivens (Mar 20, 2016)

zspider said:


> I liked him. He spoke loud and true.
> 
> So long Oko, so long... :/...


I think he is quoting the T800.


----------



## zspider (Mar 20, 2016)

Crivens said:


> I think he is quoting the T800.



*hums the Terminator 1 theme...* o.0


----------



## usdmatt (Mar 20, 2016)

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.


----------



## _martin (Mar 20, 2016)

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.


----------



## ANOKNUSA (Mar 20, 2016)

Oldrancher said:


> I'm going to beg to disagree with some of the suggestions made here.



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.



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.


----------



## drhowarddrfine (Mar 20, 2016)

usdmatt said:


> I don't really get the arguments against removing Sendmail


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.


----------



## Deleted member 9563 (Mar 20, 2016)

The fact that expected behaviour does not easily change is a big plus for FreeBSD. I can't help but think that a discussion about defaults is really about the balance between stability of older systems and expected behaviour versus out-of-the-box behaviour for new users.


----------



## protocelt (Mar 21, 2016)

OJ said:


> The fact that expected behaviour does not easily change is a big plus for FreeBSD. I can't help but think that a discussion about defaults is really about the balance between stability of older systems and expected behaviour versus out-of-the-box behaviour for new users.


 Good point. I would also like add to this that no matter what the defaults are, there will always be some users that don't like some of them for whatever the reason. No matter how hard you try, it's just not possible to please everyone all of the time.


----------



## zspider (Mar 21, 2016)

protocelt said:


> Good point. I would also like add to this that no matter what the defaults are, there will always be some users that don't like some of them for whatever the reason. No matter how hard you try, it's just not possible to please everyone all of the time.



Honestly I don't mind the tweaking, since it teaches me about the OS and you learn why and where things are. Saves alot of time when you know how to adjust something without having to ask, or go searching the internet.


----------



## Oldrancher (Mar 21, 2016)

ANOKNUSA said:


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



Have to chuckle at that comment.  Yeah, I suppose I'm "new to Unix," since my first install was AT&T system 7 (as I recall) on a PDP-11 around 1979.  Yes, having a recent `sendmail` in the distribution was a plus for me, only in that it means that I don't have to download the source distribution and compile it before configuring it for use.  That is what I have been doing on Solaris, as the package in the last Solaris 10  distribution is a bit ancient.  From my perspective, if something I've built and configured for use in my Solaris boxes is available on FreeBSD, either in the basic installation or in /usr/ports, great.  If not, and if it is available as open source, I'll download it, compile it, and install it.
Such was the case with the CDE desktop, which I have up and running.  

All in all, it has been clear to me for some time that I needed to move to another O/S, because Solaris as I have used it has vanished into the maw of Oracle, and I didn't see Openindiana as a solid replacement.  The move to FreeBSD has been, for the most part, surprisingly easy, and if the installation defaults aren't what I want, it hasn't been much work to build and install what I need and want.   Right now I'm waiting for the 10.3 release to replace my crash-and-burn 10.2 test installation with a production installation on another box.


----------



## ANOKNUSA (Mar 21, 2016)

Oldrancher said:


> Have to chuckle at that comment. Yeah, I suppose I'm "new to Unix," since my first install was AT&T system 7 (as I recall) on a PDP-11 around 1979.



Nah, I just meant that your post essentially says "I like the FreeBSD defaults because they let me use my old Solaris configurations." I can totally understand why that's appealing, and familiarity is a valid reason for liking something. But the concern raised by the link in the OP was that the default configurations might present easily avoidable security/stability risks to users and add unnecessary difficulties for the FreeBSD developers and maintainers.

Again, I meant no offense, but if certain choices are arguably making many people's lives riskier and harder for no good reason then changing them would arguably be a net gain for the project and community. Not wanting to force lots of people to immediately make major changes to fundamental configuration is a good reason to avoid radical change. Not wanting to force a few people to eventually reconfigure one or two things is a terrible reason to avoid gradual (and arguably progressive) change.


----------



## Oldrancher (Mar 22, 2016)

protocelt said:


> Good point. I would also like add to this that no matter what the defaults are, there will always be some users that don't like some of them for whatever the reason. No matter how hard you try, it's just not possible to please everyone all of the time.



And therein lies the crux of the matter.  ANOKNUSA brings up the subject of security in a default install.  While I have talked about moving from a Solaris 10 Desktop/Server setup to FreeBSD 10.2, I suspect that what I run here (essentially, a pair of ISP servers) is not what the majority of new-to-FreeBSD users need to set up.  For one thing, I have full Internet backbone feeds (no filtering, including the DDoS and script kiddie stuff) with static IP's.

My upstream feed is a small local ISP, whom I've helped set up a rural wireless deployment, so I do get some "special folks" treatment from them.  One biggie on my systems is that I run a Mailman server.

My servers connect to the Internet backbone through Fortinet Fortigate firewalls with Fortiguard UTM to keep the script kiddies at bay.  Not cheap, but they sure do a job.
Properly configured, a Fortigate 60 allows me to run FreeBSD "naked" without much fear of the script kiddies getting through.  And let me assure you, running ISP services gets tons of hacking attempts---I spend as much time on security as I do on everything else. 

As I said at the outset, installing Tcpwrappers with some security as a default gives at least some protection against the script kiddies.  It's also simple for a novice to configure.

I'm not going to belabor the default install of sendmail(8) to any great extent.
As a matter of fact, I have my own way of building the .cf files, which means that my installation is already non-standard.  Yes, learning to administer sendmail(8) for a novice is probably more of an exercise than something like postfix(1), but if FreeBSD installed with postfix(1), I'd build sendmail(8) and install it.   Installing it as a default sends a clear message that "Hey, Toto, this isn't Linux."  That along with not installing an X11 server and one of the popular (Linux) window managers by default.

Virtually all of the security notices I've seen have been for ssh(1), ssl(3), bind(1), and ntp.  What are you folks going to do, eliminate ssh(1) and ssl(3) from the default install because they get security notices?  A lot of things depend on having those two.

Going back to protocelt's comment, I don't think that any out-of-the-box O/S install is going to meet the exact need of any advanced UNIX user.


----------



## Deleted member 9563 (Mar 22, 2016)

Oldrancher said:


> Going back to protocelt's comment, I don't think that any out-of-the-box O/S install is going to meet the exact need of any advanced Unix user.



FreeBSD actually shines here, because it doesn't install nearly as much stuff by default as some other OSs. Even Debian installs with a bunch of extra stuff, a significant percentage of which I have to delete after. The list of defaults considered in the featured article is actually pretty short, all things considered.


----------



## ANOKNUSA (Mar 22, 2016)

Oldrancher said:


> Going back to protocelt's comment, I don't think that any out-of-the-box O/S install is going to meet the exact need of any advanced UNIX user.



Completely agreed on that point. I'll also say that personally, I probably don't put as high a priority on security as the author of that list might. Just as most people don't need everything included in base (and so aren't affected by every security issue that might arise), most people don't need maximum security. Security is an important thing, and I think minimizing the effort the developers have to undertake to keep up with security should be be addressed, but I'm not advocating locking everything down by default or removing anything that has a half-dozen security issues in a single year or anything like that. The convenience of a user configuring a new system can be balanced with reasonably secure default settings. Just as most people don't need everything that's included in the base system, most people don't need the maximum security settings common programs might offer. Someone configuring a new install shouldn't have to worry about whether their version of OpenSSH is out-of-date, but they shouldn't have to physically carry their SSH keys to a new machine either.

I wouldn't be surprised if the developers actually intend to address some of these things once 11.0 is out and the new support scheme becomes active. It's only necessary to support as many older versions of common utilities as there are older minor releases of FreeBSD, for as long as those older minor releases of FreeBSD are supported. Both those quantities are about to be cut down, with only 10.3 and 11.0 being supported as of the end of this year. Fewer supported release and a more predictable user upgrade schedule could make it much easier to incorporate new releases of common utilities into new releases of FreeBSD.


----------



## Oldrancher (Mar 22, 2016)

ANOKNUSA said:


> I'll also say that personally, I probably don't put as high a priority on security as the author of that list might. Just as most people don't need everything included in base (and so aren't affected by every security issue that might arise), most people don't need maximum security. Security is an important thing, and I think minimizing the effort the developers have to undertake to keep up with security should be be addressed, but I'm not advocating locking everything down by default or removing anything that has a half-dozen security issues in a single year or anything like that. The convenience of a user configuring a new system can be balanced with reasonably secure default settings. Just as most people don't need everything that's included in the base system, most people don't need the maximum security settings common programs might offer. Someone configuring a new install shouldn't have to worry about whether their version of OpenSSH is out-of-date, but they shouldn't have to physically carry their SSH keys to a new machine either.



From my perspective, there is just no such thing as "too much security," even if you are not running a port 25 mail server and ports 80 and 443 web server.  Over the past year, botnet and script kiddie probes getting out to my system have risen dramatically, and I've had some conferences with my upstream feed's network people about botnet probes flooding their wireless antenna system and degrading performance.  Last summer, I configured a Solaris 10 "crash and burn" box to run without a hardware firewall/router in front of it, just to see what was coming out as far as their transmitting antennas.  WOW!  Peaks of thousands of probes per second to `fingerd, portmapper, named, SNMP, telnet, rlogin` and a few others.  That sacrificial system got hacked at least twice, requiring a full reinstall from cold to recover.  I'm not going to go into a lot of detail about what my upstream provider needed to do to block those probes from their server farm vs. what I needed to do on my server network.  Suffice it to say that both my upstream provider and I have had to become much more security-conscious than we were a year ago, particularly in regard to Unix/Linux security.


----------



## Crivens (Mar 23, 2016)

What I heard from one of the CCC network people, that when they attach their conference network and initiate the border routing (making is a new country, as far as I understood), they get about four MBit of traffic instantly. No system is there beyond the routers, but the scanning starts within seconds. So, automatic port scanning is a given, and script kiddies likewise (you are _still_ not allowed to, ahem, re-educate them. With a pice of 2x4. With nails in it). 

The default values for anything that might directly face the internet should be hard and draconic, in my opinion.


----------



## shepherdAZ (Mar 23, 2016)

Crivens said:


> The default values for anything that might directly face the internet should be hard and draconic, in my opinion.



Absolutely. Better to have to switch on the stuff that is needed, rather than remember to disable the stuff that isn't. I found the original linked article/doc very informative, and it fits nicely with some new hardening scripts I am writing for our servers. If nothing else, getting people talking about these types of issues (and generating the resulting knowledge/tips) is immensely useful.


----------



## Deleted member 9563 (Mar 23, 2016)

Crivens said:


> The default values for anything that might directly face the internet should be hard and draconic, in my opinion.



Even at points further removed things need to be tight. Several of the VPS's that I've set up had over 100 intrusion attempts per minute almost right away. This is an insignificant amount, but a threat is a threat.



shepherdAZ said:


> Absolutely. Better to have to switch on the stuff that is needed, rather than remember to disable the stuff that isn't.



This is an extremely important point. One does not "remember" to turn something off which one has not touched in the first place. One will, however, go looking for something to turn on if things aren't working.


----------



## zspider (Mar 24, 2016)

Crivens said:


> and script kiddies likewise (you are _still_ not allowed to, ahem, re-educate them. With a pice of 2x4. With nails in it).



Wouldn't we all like to do that.?



OJ said:


> This is an extremely important point. One does not "remember" to turn something off which one has not touched in the first place. One will, however, go looking for something to turn on if things aren't working.



This^


----------



## Crivens (Mar 24, 2016)

OJ said:


> This is an extremely important point. One does not "remember" to turn something off which one has not touched in the first place. One will, however, go looking for something to turn on if things aren't working.


Or even worse is when it was off by default and gets turned on behind your back because some stupid component will not work without it. And then some installation code is being "helpful" and turns on something you _know_ is meant to be off. 



zspider said:


> Wouldn't we all like to do that.?


I would be interested in a poll on this, but it might not be completely politically correct


----------



## ANOKNUSA (Mar 24, 2016)

Oldrancher said:


> My upstream feed is a small local ISP, whom I've helped set up a rural wireless deployment...





Crivens said:


> What I heard from one of the CCC network people, that when they attach their conference network and initiate the border routing (making is a new country, as far as I understood), they get about four MBit of traffic instantly.



Yeah, things are a lot less problematic for residents of urban America, sitting behind colossal ISPs with dedicated routers at multiple junctures. It's good to be reminded now again not to take that convenience for granted. Thanks.


----------



## jrm@ (Mar 25, 2016)

Check out the 2016-03-23 episode of BSDNow.  A discussion about the article starts around 11 minutes in and there are show notes on the topic.


----------



## Deleted member 9563 (Mar 25, 2016)

jrm said:


> and there are show notes on the topic.



From the notes: _"The article suggests just removing sendmail with no replacement. Not sure how they expect users to deliver mail, or the daily/weekly repo_rts"

Can someone explain why the assumption that there are users and why, when there are any, it would be a requirement for them to deliver mail? And what's wrong with logs for reports? This just sounds like some personal use case or quirky preference and comes off as outright bizarre as a choice for everybody.

I'm loathe to criticize FreeBSD but on the surface, the above seems almost as badly conceived as when Linux distros vehemently insist that you must have an office suite the size of the rest of the OS.

I can see how this default made sense 20 years ago, and is here for backward compatibility. But that was a long time ago. I'm waiting to be educated.


----------



## Maxnix (Mar 25, 2016)

OJ said:


> From the notes: _"The article suggests just removing sendmail with no replacement. Not sure how they expect users to deliver mail, or the daily/weekly repo_rts"
> 
> Can someone explain why the assumption that there are users and why, when there are any, it would be a requirement for them to deliver mail? And what's wrong with logs for reports? This just sounds like some personal use case or quirky preference and comes off as outright bizarre as a choice for everybody.
> 
> ...


Me too was wondering why someone should rely on sendmail for notifications. Nothing against `sendmail`, but I enable it only for messages from `cron` and if there is a way to have such messages in a log file instead, I would be very happy.


----------



## gofer_touch (Mar 25, 2016)

jrm said:


> Check out the 2016-03-23 episode of BSDNow.  A discussion about the article starts around 11 minutes in and there are show notes on the topic.



The hosts seemed to have had a good laugh, taking pot shots at OpenBSD and all.


----------



## pkubaj (Mar 25, 2016)

I believe they are just making up stupid excuses. I guess nobody said anything about changing default OpenSSH settings in stable/* branches, it's just that head also enables DSA. The same applies to OpenSSL. While stable/* could stay on OpenSSL, as insecure as it is, head could switch to LibreSSL, at least with experimental, non-default src.conf knob. In fact, that's what HardenedBSD with FreeBSD LibreSSL maintainer do. Take a look at https://wiki.freebsd.org/LibreSSL/Base

I'm seriously considering switching to HardenedBSD when 11.0-RELEASE is out, they at least seem to take security seriously, while providing source compatibility with FreeBSD (not sure about binaries).


----------



## drhowarddrfine (Mar 25, 2016)

OJ said:


> Can someone explain why the assumption that there are users and why, when there are any, it would be a requirement for them to deliver mail? And what's wrong with logs for reports?


I already mentioned this in an earlier post. It's good to see I'm backed up on that. 

You guys shouldn't assume that, as users, your needs are the same as corporations, ISPs, server farms, etc.


----------



## gofer_touch (Mar 25, 2016)

pkubaj said:


> I'm seriously considering switching to HardenedBSD when 11.0-RELEASE is out, they at least seem to take security seriously, while providing source compatibility with FreeBSD (not sure about binaries).



Is HBSD a drop in replacement for FreeBSD for most purposes? I've tried it a few times in a VM and it seems pretty close.


----------



## Deleted member 9563 (Mar 25, 2016)

drhowarddrfine said:


> You guys shouldn't assume that, as users, your needs are the same as corporations, ISPs, server farms, etc


I couldn't agree more. Hence my post.


----------



## ANOKNUSA (Mar 25, 2016)

drhowarddrfine, I'm mostly with you. My main problems with sendmail are its weight, complexity, and historical baggage. Tons of files, in several places, with a configuration syntax that's arcane. Simply replacing it with logging won't really fix anything, though. Recording periodic and error reports to log files means the admin then has to habitually check those logs. But that's not big deal---it can be done right after punching in each morning, right?

Well, different periodic configurations take different amounts of time to run depending on which checks are performed, and different checks take different amounts of time to perform depending on how much hardware and how many files have to be dealt with. So it's not predictable when the admin might have logs ready to be checked. And that's just for periodic---everyone has differently sized crontabs, and new cron jobs and scripts being tested would also need to be logged, and these logs would be generated whenever the system got around to executing, finishing, and logging the process.

So now the admin falls prey to that perennial bad habit of the office drone, checking every half hour to see if any new messages are available and seeing that there aren't, though there could have been, though there haven't been any the last six times they were checked, but maybe next time, so keep checking... The solution to that, of course, is to create some kind of notification mechanism that alerts the admin when new logs are available. Which means new code, and new configurations. Which then need to be added to the system. And should probably have default settings, which need to be hashed out by the people making it...

So yeah, e-mail is the way to handle this. I can't argue with that. I just think a lighter mailer with a simple config should be doing the job for most, with other alternatives available in the ports tree for those who need them.


----------



## jungleboogie (Mar 27, 2016)

matoatlantis said:


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



This bothers me too.

I know many things in /etc/ probably need to be read by all. That's just the fact of operating systems and I'm not advocating major changes with that. However, why in the world would you have a default option for jungle to be able to see all of matoatlantis's files in the home directory?? This is a very, very small change. When you adduser, you can set the home permissions however you want, so TJ is just advocating making it not read only by everyone.


----------



## sidetone (Mar 27, 2016)

Is mail/fdm good? It uses an ISC License. I've read that sendmail is not a secure MTA. OpenBSD uses mail/opensmtpd, which is available for FreeBSD, but it only uses smtp.


----------



## ANOKNUSA (Mar 27, 2016)

fdm is not an MTA. It connects to remote IMAP or POP3 servers and fetches mail, then sorts it into a local mailbox. It's used in conjunction with MUAs like Mutt, Alpine, and Thunderbird.

But if you have a use for it then yes, it is pretty good, albeit with a steep learning curve.


----------



## Oldrancher (Mar 27, 2016)

drhowarddrfine said:


> You guys shouldn't assume that, as users, your needs are the same as corporations, ISPs, server farms, etc.



I think that this is an important consideration.  FreeBSD doesn't pretend now to be a "Windows replacement" O/S.  I don't know how well PC-BSD works for that.  The guys I know who are doing Windows replacement consumer installs are current talking Mint, after having talked up Ubuntu and Mepis.  

My needs are "the same as corporations, ISPs, server farms etc." but without a large user base.  To get down to brass tacks, I think there are two questions that need to be answered:

1. Should an O/S rely on its security resources to run "bare" on an outside network, without a hardware appliance between it and the outside?  I've experimented with that, and while it's a chore, it's risky.  Problem for the SOHO user is that a really good small security appliance isn't well-supported by the consumer device market.  I use Fortinet Fortigate 60's, which are not cheap, and overkill for my needs---but they do a real job at blocking the script kiddies.  

While setting up a Fortigate to protect a Windows system is fairly quick and simple, the moment you start adding an MTA and an HTTP server, you've got to get an appropriate configuration.  Some of the needed resources require command-line programming.
Not sure about the current Cisco ASA's, but I think that they also require a lot of command-line configuration.  

2.  How much is it reasonable to expect a "systems administrator" to do in O/S configuration?   When I read the Mailman support mail lists and a few other places, I get the impression that many people employed as "systems administrators" expect to install pre-built binaries and use point-and-click GUI tools.   

For the past 15 years, since I retired, I've only worked with a few O/S's---primarily, Solaris---although I have looked at some of the Linux distributions rather cursorily.
For the 20 years before that, I worked with both BSD and System V systems at kernel level, so my "systems administration" skills add up to "as deep as you need to go" to get something to work.  

I think that so far as the current FreeBSD default `sendmail` goes, it works out of the box.  And I like getting the reports on a local mail spool, as they can be dealt with individually with a simple mail reader like `mutt`.  Boosting up the configuration to work as a incoming/outgoing MTA is, for the most part, adding 
adding about 10 command lines to the master .mc that builds sendmail.cf, primarily to handle masquerading and dnsbl spam filtering.  I don't do sendmail.cfr vi fixups.


----------



## Deleted member 9563 (Mar 28, 2016)

Oldrancher said:


> I think that so far as the current FreeBSD default  sendmail goes, it works out of the box.


As I recall, without a FQDN it will give errors on bootup. So no, it still doesn't quite work out of the box.


----------



## Oldrancher (Mar 28, 2016)

OJ said:


> As I recall, without a FQDN it will give errors on bootup. So no, it still doesn't quite work out of the box.



Entering a FQDN is part of the installation.


----------



## Deleted member 9563 (Mar 28, 2016)

Oldrancher said:


> Entering a FQDN is part of the installation.


Of course. So?


----------



## Oldrancher (Mar 28, 2016)

OJ said:


> Of course. So?



So sendmail comes up on a fresh install, if it was done by the book.


----------



## shepper (Mar 28, 2016)

Oldrancher said:


> My needs are "the same as corporations, ISPs, server farms etc." but without a large user base. To get down to brass tacks, I think there are two questions that need to be answered:
> 
> 1. Should an O/S rely on its security resources to run "bare" on an outside network, without a hardware appliance between it and the outside? I've experimented with that, and while it's a chore, it's risky. Problem for the SOHO user is that a really good small security appliance isn't well-supported by the consumer device market. I use Fortinet Fortigate 60's, which are not cheap, and overkill for my needs---but they do a real job at blocking the script kiddies.
> 
> ...



I am not sure that the questions raised were addressed.

The OpenBSD project works well as network security appliance.  An example setup is here. (The linked OpenBSD manual pages broke last week and have yet to be fixed). jggimi has been very accessible in that forum often sharing his config files and helping others trouble shoot theirs.  Oko, systemadmin in an academic settings, diagrammed his home network topology in this post.  If you are paying Fortigate a significant amount you may want to look into setting up your own firewall/NAS.  You might also want to look at opensmtpd which is now the default mail server in OpenBSD.  opensmtpd does not do everything but it does meet many peoples needs with simplicity and elegance.


----------



## drhowarddrfine (Mar 28, 2016)

Oldrancher said:


> So sendmail comes up on a fresh install, if it was done by the book.


Yep


----------



## beastDemian (Mar 28, 2016)

The BSDNow guys posted a nice rebuttal: 

http://www.bsdnow.tv/episodes/2016_03_23-marking_up_the_ports_tree

I agree that OpenSSL should be exiled from base, specially now that we have much better solutions. But things are done for a reason and some of the other points seem a lot like "Why is FreeBSD not OpenBSD?".


----------



## shepper (Mar 28, 2016)

beastDemian said:


> I agree that OpenSSL should be exiled from base, specially now that we have much better solutions


+1

I also agree that we are drifting toward a new topic and it would be a great topic.  Not a chest-thumping thread but rather one that summarizes the strengths and weakness of OpenSSL/LibreSSL, sendmail/opensmtpd, ?????/OpenSSH, ntp/opentpd, firewalls/pf ....


----------



## kpa (Mar 31, 2016)

beastDemian said:


> I agree that OpenSSL should be exiled from base, specially now that we have much better solutions. But things are done for a reason and some of the other points seem a lot like "Why is FreeBSD not OpenBSD?".



I agree but how to actually do it? There are many many utilities in base that absolutely need SSL/TLS support out of the box such as fetch(1). Ideally you would just `pkg install openssl/libressl` as the first step in a freshly installed system to get those working but as it happens pkg(8) itself relies on SSL/TLS...


----------



## usdmatt (Mar 31, 2016)

> Ideally you would just pkg install openssl/libressl as the first step in a freshly installed system to get those working but as it happens pkg(8)itself relies on SSL/TLS...



Any operating system absolutely needs an SSL/TLS library out of the box. The question is whether there's a better choice than what FreeBSD is currently using that makes it worth changing the software in base. Using LibreSSL definitely makes some sense, although at this point I don't know how many issues switching the default would cause (could be quite a lot, especially if you include packages that use ssl).

Same with Sendmail. I would never suggest having no built-in email functionality at all, but to me it makes much more sense to provide Sendmail as a package, and just have a minimal SMTP client and local delivery agent in base.


----------



## Deleted member 9563 (Mar 31, 2016)

usdmatt said:


> Same with Sendmail. I would never suggest having no built-in email functionality at all, but to me it makes much more sense to provide Sendmail as a package, and just have a minimal SMTP client and local delivery agent in base.



That would be great. Or even just fix the Sendmail dependency on a FQDN.


----------



## kpa (Mar 31, 2016)

OJ said:


> Sendmail dependency on a FQDN.



This is not true. Sendmail only depends on hostname that resolves to an address, any address. The hostname can be just joe and as long as that name resolves to an address through the resolver(3) Sendmail is happy. All MTAs have the same basic requirement, even the most minimal ones. They need to know the name of the system they are running on to properly fill in the header values in emails.


----------



## Deleted member 9563 (Mar 31, 2016)

kpa said:


> This is not true. Sendmail only depends on hostname that resolves to an address, any address. The hostname can be just joe and as long as that name resolves to an address through the resolver(3) Sendmail is happy. All MTAs have the same basic requirement, even the most minimal ones. They need to know the name of the system they are running on to properly fill in the header values in emails.


Thanks kpa. I'll defer to your better knowledge. It has been a little while since I did an install, but I could have sworn I was getting an error message at boot when I only had a single name, and that adding a full name solved that. In fact it would stop and wait for a timeout before continuing.


----------



## beastDemian (Apr 1, 2016)

kpa said:


> I agree but how to actually do it? There are many many utilities in base that absolutely need SSL/TLS support out of the box such as fetch(1).



Of course, I wasn't sugesting that we remove ALL SSL/TLS libraries from base. I was suggesting replacing OpenSSL with LibreSSL (or with Boring for that matter). While I must admit that I was, for the most part ignorant to the terrible status of OpenSSL as a codebase, now that my eyes are opened I believe something should be done about it. IMO the project should adopt as an official stance the removal of OpenSSL and its replacement with a more suitable library.  I do not trust OpenSSL code anymore and I don't want it running on my productions servers.



kpa said:


> Ideally you would just  pkg install openssl/libressl as the first step in a freshly installed system to get those working but as it happens pkg(8) itself relies on SSL/TLS...



I believe there is a way to do so. Bernard Spil was (is AFAIK) working on it . I understand the solution to this is to patch the base system to build with LibreSSL (1) and making SSL in base private(2). 1 Is more or less working. 2 is harder to do, but with packaged base coming to 11 it should not be impossible. There is a way to do it, it just needs significant momentum to acomplish.

Sendmail is an easier solution, but the person working on replacing it with DMA ran out of time IIRC (I don't really know what needed to be done, last time I checked out a -CURRENT image and tried to build the source, DMA didn't build).


----------



## getopt (Aug 22, 2022)

jrm@ said:


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


Who knows if this project is still alive and worked on?


----------



## SirDice (Aug 22, 2022)

Project is still alive. There are still a lot of kinks to iron out.


----------



## zirias@ (Aug 22, 2022)

Hm, looking at the PkgBase wiki entry, you can read about these "kinks", and the impression is that, yes, it's alive, but just a little bit .

The "src" tree can build packages now for a long time, and I don't think this will ever be removed again. But whether it will ever be officially supported? I'm not sure. I personally think it's a very nice idea, but looking at all the problems to solve, I'm a bit unsure it's really worth it. We will see.


----------



## getopt (Aug 22, 2022)

zirias@ said:


> Hm, looking at the PkgBase wiki entry, you can read about these "kinks", and the impression is that, yes, it's alive, but just a little bit .


Yes, saw this. Along with these links:









						GitHub - trueos/pkgbase-docs: Information / Documentation on TrueOS inspired base packages for FreeBSD
					

Information / Documentation on TrueOS inspired base packages for FreeBSD - GitHub - trueos/pkgbase-docs: Information / Documentation on TrueOS inspired base packages for FreeBSD




					github.com
				









						pkgbase-docs
					

Information / Documentation on TrueOS inspired base packages for FreeBSD



					trueos.github.io
				






> *After discussing with the team, we're going to go ahead and abandon this revision. While we wanted to see something usable happen in this space, it's just not cost or time effective to spend far more effort fighting politics than the actual implementation took. We will continue using a non-package solution for our products for the future.*








						⚙ D20394 Ports Tree Base Packages
					






					reviews.freebsd.org
				




The disturbing phrase there is "fighting politics".


----------



## zirias@ (Aug 22, 2022)

getopt said:


> The disturbing phrase there is "fighting politics".


This is not PkgBase, it was an attempt to "integrate" base into ports. There are good reasons not to do this (and probably other good reasons why it was attempted as well). Talking about "politics" is nothing but a code for not accepting the counter arguments.


----------

