FreeBSD - a lesson in poor defaults

Status
Not open for further replies.
I think the following snippet of the authors proposed sysctl.conf is a good example:

Code:
security.bsd.hardlink_check_gid=1  # These two options will break poudriere's
security.bsd.hardlink_check_uid=1  # compiling privsep.

Is he saying that something that specifically breaks poudriere should be the default instead? Bizarre. I am going to assume his suggested "default" candidate would change if he was a pourdriere user. But that isn't what a "default" is!

Seems to be just another guy online who is not very able to reflect upon the fact that tweaks for them don't match the use-case of others. This is along the same lines as GUI installers, default text editors, etc. Since a true "default" can't be made, we just stick with what is already there to avoid breakage.
 
Here's Ed Maste from the FreeBSD Foundation:
This link gets shared around every now and then, and my response is always the same: there is some useful insight, but there’s also information that’s so outdated it provides no value, outright misinformation, and self-contradiction. Some of the technical points are fair, and should be and are being addressed. But the commentary is often laughably wrong. The document seems more focused on advancing an agenda than a good-faith effort at improving security in FreeBSD.
 
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.
 
For who might be interested my sysctl.conf,
Code:
###ENABLE SECURITY 
security.bsd.unprivileged_read_msgbuf=0  #1 
security.bsd.unprivileged_proc_debug=0   #1 
kern.randompid=1                         #0 
kern.sugid_coredump=1                    #0 changed credential programs dump core  
kern.corefile=/var/coredumps/%U/%N.core  #%N.core 
###KERN 
kern.msgbuf_show_timestamp=1             #0 show timestamp in messagebuf 
kern.shutdown.poweroff_delay=2000        #5000 : Delay before poweroff to write disk caches (msec) 
kern.shutdown.kproc_shutdown_wait=20     #60 : Max wait time (sec) to stop for each process 
kern.ipc.shm_use_phys=1                  #0  : Enable locking of shared memory pages in core 
kern.ipc.shmall=512000                   #131072 
kern.ipc.shmmax=1000000000               #536870912 
###HW 
hw.usb.no_shutdown_wait=1                #0  : No USB device waiting at system shutdown 
###VFS 
vfs.zfs.min_auto_ashift=12               #9 
vfs.usermount=1                          #0,Unprivileged users may mount and unmount file systems 
##################987654321#### 
vfs.zfs.arc_min= 1500000000              #0 
vfs.zfs.arc_max= 2500000000              #0 
#################a987654321### 
###NET################################################################## 
net.inet6.ip6.temppltime=7200            # 86400 ,  Maximum preferred lifetime for temporary addresses 
net.inet6.ip6.tempvltime=14400           # 604800 , Maximum valid lifetime for temporary addresses 
net.inet.tcp.cc.algorithm=cubic          #newreno #Congestion control newreno,CDG,CHD,CUBIC,DCTCP,HD,H-TCP,VEGAS 
# 
net.inet6.ip6.redirect=0                 #1 
net.inet6.icmp6.rediraccept=0            #1        
net.inet.ip.redirect=0                   #1 
net.inet.icmp.drop_redirect=1            #0 
# 
net.inet.ip.maxfragpackets=0             #15762 
net.inet.ip.maxfragsperpacket=0          #16 
# 
net.inet.tcp.blackhole=2                 #0 
net.inet.udp.blackhole=1                 #0 
# 
net.inet.tcp.always_keepalive=0          #1           
net.inet.tcp.nolocaltimewait=1           #0            
net.inet.tcp.icmp_may_rst=0              #1 
net.inet.ip.check_interface=1            #0                   
net.inet.ip.process_options=0            #1                   
net.inet.ip.random_id=1                  #0                           
net.inet.icmp.icmplim=50                 #200 
#aslr 
kern.elf64.aslr.enable=1                 #0 
#aslrpie 
kern.elf64.aslr.pie_enable=1             #0 
# 
net.inet6.ip6.accept_rtadv=1             #0 Default value of per-interface flag for accepting ICMPv6 RA messages 
# 
kern.metadelay=4                         #28 
kern.dirdelay=5                          #29 
kern.filedelay=7                         #30 
# 
security.bsd.unprivileged_idprio=1       #0 
kern.sched.preempt_thresh=120            #80
 
There's always gonna be somebody who doesn't like the defaults... there's several outtakes from that:
  • There's no such thing as a 'perfect' setup. FreeBSD ships with minimum needed to have a working system, but then it's up to the user to put in the effort to set the system up as they see fit.
  • The article was last updated 6/23/2022.
  • Yeah, the article is laced with commentary about how the defaults don't make sense for the author/user.
  • Once you get past the author's disdainful attitude, they do bother to make the case by pointing out technical details.
  • In post #7, drhowarddrfine dug up a very good response from FreeBSD foundation. I see that response as a sign that somebody from the Foundation actually bothered to read the whole article, and formulate a thoughtful response.
  • Most negative responses to the article seem to come from readers who just skimmed the article, caught an 'off-putting point A' about it - and off-handedly said that the whole article is crap because of that one point A. The article has more than just the unlikeable 'Point A', people!
 
  • Like
Reactions: mer
Once you get past the author's disdainful attitude, they do bother to make the case by pointing out technical details.
Oftentimes a point is better received for discussion if not presented with disdain.
Your previous point about the "defaults not making sense for the author" is a key point to me. The problem is that led into a lot of his attitude, presenting as "he knows better than any other user so noone should question his word". He did not state that, but that is what came through.
I personally think some of the items warrant discussion, but feel there was a lot of "I don't like the defaults because they don't fit the way I think they should be" (like the things about periodic.conf, rc.conf and firewalls).

I saw the date of last edit, but I wanted to know "what was updated/changed" and it was effectively "sleath edit". I think he should have kept the previous iterations, then mark updates clearly as to what has changed.
 
I promise I won't post anymore opinionated articles randomly found in the Fediverse... ?
My opinion, that is the wrong thing to take away from everything folks have said here.
The saying "a broken clock is right twice a day" applies to the link you posted.
The problem is, just like trying to discuss say politics with someone, if you start the discussion with a "you are stupid your opinion is stupid" attitude, you basically lose. You are not having a discussion, you are giving/getting a lecture.
 
I promise I won't post anymore opinionated articles randomly found in the Fediverse... ?
Most blogs/articles about technology and 'best practices' have some have some degree of narcissism to them. You gotta be able to look past that to be able to get solid technical information from such sources.

I personally think that there's nothing wrong with discussing the said articles/blogs in here, but there's kind of a format/template to how those discussions are started and conducted. I'd suggest thinking about a few things, such as: why you're starting a discussion, what you think of the article, what the outtake is... Nothing formal, but don't be lazy, put some thought into it. And the FreeBSD forums do have mods who can step in if the conversation gets out of hand.
 
I personally think that there's nothing wrong with discussing the said articles/blogs in here,
Discussions and corrections are welcome. Only the mud slinging contests are unwelcome, at least here. And I think at the original source also, or they would allow for comments? So someone posts some content, does not allow to be critizised (need to be right, save public face) and thus offloads the 'discussions' to other places.
Is it only me or is this akin to dump your trash in the woods?

So be polite and bring facts so we can have a discussion. Be rude and you get shown the door. This is not censorship, this is the rules of the house.
 
  • Like
Reactions: mer
Whatever, Crivens. You'll employ the tried and true "that was rude" to apply your censorship (which includes locking discussion, not only removing it).
 
I personally think that there's nothing wrong with discussing the said articles/blogs in here
Concerning this specific article, I don't think it's worth discussing it any more. It's been around for a very long time, and it was "discussed" a lot. Still the result is the same. Some claims are just wrong, most are just personal opinion (with sometimes complaining the default isn't the "most secure for any scenario choice" as OpenBSD would do, and some with questionable secuirty implication at all). Between all this, there are a few valid complaints (although last time I checked, some of these were already outdated in spite of the author claiming regular updates). It's a well-known strategy to mix in some well-founded points in your opinionated work, that way, readers are easily tricked into taking the whole thing seriously.
 
That article is the result if you want FreeBSD to become more like OpenBSD, a lot, while there are enough reasons around why FreeBSD will never be that way.

It's the equivalent of a BMW lover complaining about that Mercedes should be more like BMW, which will never happen for obvious reasons. And vice versa. There's a variety of BSDs and other stuff out there for good reason - different needs, different tool.
 
That article is the result if you want FreeBSD to become more like OpenBSD, a lot,
I think it's important to add this:

"out of the box"

Nothing prevented the author from applying changes to his default FreeBSD install to achieve his goal. Heck if he feels that strongly about it, perhaps he should take a look at something like HardenedBSD or try getting a port added that simply applies his desired settings.
 
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
 
  • Like
Reactions: mer
Status
Not open for further replies.
Back
Top