‘ Fundamentally, sudo adds significant attack surface because it is a powerful tool with many features like support for security policies defined in LDAP, so the system is likely more secure without it. ’
This is uncontexualized hype clearly written by someone with no real world experience, hoping to gaslight users into thinking their current system is insecure. Then I scroll up and noticed the article is written by a company who sell presumably consulting services in unix. Go figure.
Failing that, there’s limited reasons to use BSD systems instead of Linux unless you have highly specialised requirements. Under many cases I’d imagine it would be more expensive in terms of effort required to hire/train skilled staff.
Yeah, so I went down the Freebsd rabbit hole last year for my personal hosting and I have some mixed feelings about it. It's a much nicer/less changing environment than Linux, and it's really good for the things it does well. But the moment you step off the happy path then you will find yourself lost in the woods.
Basically I ended up using the Freebsd box as a fileserver (ZFS and Minio), and still running an Alpine Linux box with zfs for most other things.
I did briefly run a Minecraft server on the Freebsd box which worked really well.
Could you expand on "But the moment you step off the happy path then you will find yourself lost in the woods."? Because from my experience FreeBSD is very predictable, and knowing how things are laid out you can figure things out for other things that one is not familiar with. If anything, I see Linux as a bit of a mess that in many places is inconsistent.
Setting up NFSv4, I spent two evenings on that before abandoning it.
Virtual network for a bunch of jails with nat.
I wanted exposed ports on the host machine mapped to a reverse proxy jail that did tls termination before forwarding to other jails on a virtual network (while allowing the jails on the virtual net outgoing internet access).
Several applications that were apparently built for Linux, so they did not compile on Freebsd (and no alternatives available).
Getting newer versions of software.
Often the version available in pkg is several major versions out of date.
Documentation for how to do things in general.
Yeah when there are docs/tutorials they can often be of high quality, but frequently there is just nothing or the available docs does not cover the edge case you are trying to solve.
> Virtual network for a bunch of jails with nat. I wanted exposed ports on the host machine mapped to a reverse proxy jail that did tls termination before forwarding to other jails on a virtual network (while allowing the jails on the virtual net outgoing internet access).
Jails are old, and there's a wealth of outdated documentation around which makes it confusing when trying to understand how things works.
In case someone else is reading this, it's not different from what Docker does automatically for you.
I typically use vnet (which gives the jail an entire virtualized network stack, something like macvlan?) and either use NAT or bridges for connectivity. NAT for machines with only one public IP (like VPSes) and bridges for homelab setup where I want a more visible setup.
When setting up NAT I just use PF as my firewall, and assign static addresses to each jail.
Virtualized network stacks in Linux are network namespaces with a difference of not being tied to a specific "prison". So every Docker network regardless of type creates one.
Ah, understandable. I remember being slightly confused when starting to use jails again, after being used to the near magical setup of Docker/etc on Linux. Like manually setting up bridges and VLANs to make it work like I wanted? WTH.
Now I dislike using Docker for similar tasks, as I find it to be more work than just doing the same setup with VNET, bridges and VLANs. I'm a fossil and I want to run different services on different VLANs, which in Docker lingo is considered "legacy application setup" (looking at the macvlan documentation).
>Documentation for how to do things in general. Yeah when there are docs/tutorials they can often be of high quality, but frequently there is just nothing or the available docs does not cover the edge case you are trying to solve.
Can you give some examples so one could do something against it? NFSv4 with kerb and ldap is one..i know ;)
With jails, I could really use a tutorial that goes through a standard proxy/app/db setup (nginx, wordpress and mariadb maybe?) that does require multiple ip addresses on the physical network. So request comes in to the host on port 80/443 -> proxy -> app -> db. All jails can do outgoing connections for things like sending email, downloading updates, etc. The db and app are on a network with the proxy and only the proxy can be reached from the outside. So what would be a pretty normal setup with Docker.
And yes, firewall config should be part of that rather large tutorial, but it I really feel like a complete tutorial is missing. The ones I have seen only cover a part of it and it's left as an exercise for the reader to figure out how to glue them together.
Some of the other issues I had with incompatible dependencies would be solved if I know how to use jails correctly.
How to get a Linux jail up and running (Alpine Linux).
ZFS + NFSv4 + Kerb + ldap would be great. I ended up solving that particular problem by using minio instead, because it was so much easier to setup, but I would like to know how to get nfs working for future things.
I was wondering if there's a builder at some point, it may improve the compatibility for the whole ecosystem. There's definitely a lot of fixes going upstream from darwin build failures.
Nix is cool tech, but really suffers from a lack of good docs. I tried to use it for dev environments, but it's a struggle and asdf just has the user experience nailed, so I abandoned nix and went with asdf instead.
> Getting newer versions of software. Often the version available in pkg is several major versions out of date.
The default settings for pkg use the quarterly branch. Remove the comment from the line for using the latest branch in /usr/local/etc/pkg/repos/FreeBSD.conf.
> hoping to gaslight users into thinking their current system is insecure.
I mean, https://nvd.nist.gov/vuln/detail/CVE-2022-43995 is lest than a week old, so probably yes. (That is, a lot of systems haven't been updated and have a nice open CVE that wouldn't be there if they weren't using sudo.)
If you compare the risk of having sudo vs the risk of granting users less constrained access to root or similar, you’ll have less cves, but be more likely to be breached due to weakened rbac.
Furthermore, there would be no vulnerabilities if you just unplug your computer and walk away, at some point you need to make usability and risk compromises.
I can think of very few instances where you should be giving people shell access, let alone need to worry about RBAC.
Furthermore, the UNIX user model and file system hierarchy already provides you with RBAC. Combine that with ACLs and SetUID (et al) bits and you’ve already got sudo baked into the core system.
Your point about it being a convenience tool is bang on: it makes it easier to administer all of the above but that convenience, like nearly all convenience tools in computing, comes with a slight security trade off.
To be clear, I don’t agree with the author’s recommendation to ditch sudo. But they are absolutely correct in the technical sense. Just as you are. In fact you are both basically arguing the same point but from different perspectives: “sudo adds a vector of attack”. It’s then up to your threat modelling to decide if that is appropriate or not.
But to come back to my original point: just don’t give people shell access. There’s no need in 99% of cases of servers these days and if we are talking about local user machines, then RBAC is less of an issue since it would be a machine per user.
Even (or perhaps especially) with a machine per user, it's critical to keep that user from accidentally shooting themselves in the foot. Typing sudo does help remind a user they're doing something different. I don't want to always have the right to force delete root!
Your comment seems to suggest the alternative of not installing `sudo` is to run your desktop as root. Which clearly isn't the case at all. There are plenty of "sudo" alternatives: `su -c`, `doas`, `login`, etc
Also since we're talking about running as root: ironically I've found a lot of people seem to put the following line in their sudoers file:
ALL=(ALL) NOPASSWD:ALL
which is definitely better than logging in as root....but not by a lot.
You misunderstand it, if you don't need sudo you probably better uninstall it, what's your "real-world"-problem with that? If you work with images you might want to "deinstall" root as well....
No kidding, I am still waiting for Linux distros and other BSDs to switch to doas(1) as their default. Similar to how openssh took over from the proprietary version of ssh years ago.
In addition to what you've said, nobody is forcing anybody to use sudo. Most of my systems don't have it at all — it's simply not necessary. Some of the others use the lightweight doas ported from OpenBSD:
Some folks kind of are; for instance, last time I looked Arch Linux has sudo as part of base so it's hard to remove.
Edit: Sorry, apparently Arch does let you remove sudo (now?). If you substitute in RHEL et al. the general point stands (and I actually checked this time and Rocky 8 makes unhappy noises if you ask it to remove sudo), but my initial example was wrong.
Don't remember it ever being a problem tbh. Haven't had it installed for quite some time (since I discovered doas). I just installed it and then removed to re-check:
$ yay -Rsn sudo
checking dependencies...
:: libisoburn optionally requires sudo: for use with xorriso-dd-target
:: pacman-contrib optionally requires sudo: privilege elevation for several scripts
:: refind optionally requires sudo: for privilege elevation in refind-install and refind-mkdefault
:: wireguard-tools optionally requires sudo: elevate privileges
:: yay optionally requires sudo: privilege elevation
Package (1) Old Version Net Change
sudo 1.9.12.p1-1 -7.10 MiB
Total Removed Size: 7.10 MiB
:: Do you want to remove these packages? [Y/n]
:: Processing package changes...
(1/1) removing sudo [###############################################] 100%
:: Running post-transaction hooks...
(1/2) Reloading system manager configuration...
(2/2) Arming ConditionNeedsUpdate...
libisoburn, refind, wg, yay can be elevated by doas or su.
pacman-contrib is a bunch of package development scripts. Your typical user won't have them. Also the previous point applies.
Strange; now I've tried it and it does indeed work. I'm fairly sure I tried that before and it wouldn't let me remove sudo, which was irritating because I switched to using doas and didn't like having sudo around. Assuming my memory isn't failing me, that must have been fixed fairly recently.
Looks like nothing else in core depends on sudo, most packages from extra/community that need it have it as an optional dependency, looks like one can remove sudo on Arch
It's not like you need to use sudo on Linux. And sudo has been maintained by an OpenBSD developer since the early 90s.
Aside from what the problems and benefits of sudo may or may not be, bringing up sudo in a "BSD vs. Linux" debate is a red herring: it's just completely unrelated.
> Failing that, there’s limited reasons to use BSD systems instead of Linux unless you have highly specialised requirements. Under many cases I’d imagine it would be more expensive in terms of effort required to hire/train skilled staff.
I'd expect you'd need more training for Linux, since it changes more often.
Linux systems hasn't changed a lot in the last 4 years or os. We mostly run Ubuntu LTS at my work and the 18.04 -> 20.04 -> 22.04 deltas have been really low on the server side, and not that significant on the desktop side either
During this time frame we've also migrated our last FreeBSD servers to Ubuntu
We deferred to switching to the new installer until 22.04 and kept using the legacy net boot image for as long as possible. The switchover wasn't as bad as I was afraid it would and took only a few days to make new internal app to drive our installations. The worst part of the new installer is it requires a minimum of 2GiB of RAM to run, so all of our new VMs have to start with at least that much and be scaled down later
My goodness. How can you possibly say that Ubuntu hasn't changed much from 18 -> 22? There are whole how-tos that are completely useless from those changes. All sorts of things are different. That's ridiculous.
The other comment pointed out the installer, which I did forget about. But other then that what significant has changed?
Ubuntu's documentation, and lots of third party documentation targeting ubuntu, is like 10 years out of date for lots of things anyways, and even when it _works_ often gives bad advice that either was never true or hasn't been true for years.
Netplan happened on 20.04 AFAIR. Doesn't matter much for your cloud vps you never change networking on, but still.
From my perspective, it's not changed much too - I was using apt-get install nginx - I keep using it. Was using systemctl - keep using it. Cannot say I've adjusted my habits during that moves.
> Linux systems hasn't changed a lot in the last 4 years or os. We mostly run Ubuntu LTS at my work and the 18.04 -> 20.04 -> 22.04 deltas have been really low on the server side, and not that significant on the desktop side either
You know, I actually set this comment aside because I was curious about how HN would engage with it. So far, it seems like folks are pointing out that there indeed have been changes in certain aspects of the OS, as well as probably the introduction of the whole snap mechanism.
Regardless, to me Ubuntu LTS seems like one of the better OS distros out there, both for desktop and server use. It's not ideal, but it's good enough in most respects, to the point where it's hard to recommend anything else.
Previously I recall many looking in the direction of CentOS as something to install on servers and have it serve them for a long time with security updates and pretty good stability, but I guess now one would have to count on Rocky Linux and Alma Linux for that. Additionally, I have to admit that some of the choices that RPM distros make can be a bit odd and the software support isn't where I'd like it to be, things like Docker were admittedly broken (DNS resolution, firewall masquerades and other oddness with SELinux) for a while. It feels like they have their own enterprise-focused way of doing everything, OpenShift being an example of this.
On the other hand, there's Debian and Ubuntu. Personally, I might even like Debian better, but Ubuntu's LTS lifecycle is far more worry free. You might not get 10 years of support, but setting up something and running it for 5 years (with security and other updates) is pretty freeing, especially when you're primarily interested in just keeping things running in a stable manner and don't always need the latest packages. There are changes, of course, there are packages that change names, that break or are deprecated, sometimes you get other growing pains that all of the OSes out there need to deal with.
But Ubuntu LTS to me feels like it's good enough for both server use in both development/testing/prod, as well as personal use, as a daily driver.
And nowadays I'm considering migrating my Debian servers after the EOL to Ubuntu, my new ones already running it.
I will say that every distro has its place and in certain domains there are better options than Ubuntu, of course, and OSes like the *BSDs have consistency and engineering that Linux cannot quite match (due to the "engineered vs grown" approach to building them), but sometimes you just want something that is simple to run, has ample tutorials and resources, and won't make you chase down odd issues.
That wasn’t their point. But to be honest I do think FreeBSD is.
Linux wins in terms of market share which makes it appear easier (eg more software support, bore install guides, etc). But if you look at the base OS itself, FreeBSD is a lot more consistent to manage.
I think it’s a great pity FreeBSD doesn’t get more traction to be honest with you. I have no major qualms with Linux on the whole but FreeBSD is a really nice platform to work on too.
I can't speak for the person you're asking, but BSD is worlds easier than using Linux.
A how-to for FreeBSD can be used with NetBSD with minimal changes. Why? Because the BSDs don't expend effort to deliberately try to differentiate themselves from each other. They're consistent and don't change gratuitously.
Try writing a how-to that has even the slightest consistency between the common Linux distros - Red Hat, Ubuntu, Debian, Arch. Heck - many how-tos written for Ubuntu 18 can't be used with newer Ubuntu! It's a mess.
No, they're suggesting that BSD changes less. If you learn FreeBSD, and you learn, let's say Ubuntu, and then you keep using them for a decade, the stated position is that FreeBSD would require you to learn fewer new things than ex. Ubuntu over the same timespan.
I've been using Linux for 27 years, and it hasn't changed all that much in that time. Packaging has got better, systemd is a bit of a pain in the tits but necessary if you want to support the kind of things we expect to do with "real" computers instead of servers sitting in a dark room untouched for years.
I've been using NetBSD for about the same amount of time, and it hasn't changed all that much either.
> I've been using Linux for 27 years, and it hasn't changed all that much in that time.
First there's networking configuration. On Debian and Ubuntu the interfaces(5) used to be nice and simple, but dog knows what to use on any particular system nowadays since there are like three ways to do things: interface, netplan, system-networkd, other?
Plus there's resolv.conf(5) being fiddled with a myriad of ways and you have to figure out which system to use there as well.
ifconfig kind of works and kind of doesn't for some things.
How may firewall system changes have there been in the last 27 years? Are we supposed to be using iptables or nftables in 2022?
In roughly the same amount of time I've owned about ten or fifteen cars.
Every single one of them had the dashboard controls in slightly different places, with slightly different options. Some had four-speed gearboxes, some five-speed, some automatic with three-, four-, five-, or in one case 18-speed gearboxes.
Every single one of them was basically just a car, and drove me to the same places in the same way.
I have not tried recently to use BSD as a desktop, which is likely to have problems when using many recent GPUs, due to the lack of device drivers (but NVIDIA provides FreeBSD drivers, not only Linux, so I have used FreeBSD on a signage appliance with a fanless NVIDIA GPU).
However, when using a system without a GUI, e.g. for a networking or storage server, in most cases FreeBSD is definitely much easier to use than Linux.
There are a huge number of small details that matter. Even for something as simple as seeing the status of the network interfaces. If I type "ifconfig" without arguments on FreeBSD, it shows everything that I want to know, about all network interfaces. To obtain the same information on a Linux system, I have to type a large number of "ip" commands, each with many arguments that I fail to remember even after decades of using "ip", so I may need to consult the "man" page for "ip". (The legacy ifconfig of Linux does not provide the functionality of FreeBSD ifconfig)
In general, for any network-related task, using ifconfig and ipfw on FreeBSD is much easier than using ip and iptables on Linux.
There also many more niche applications where there are big differences. For example the "mt" command for magnetic tape control sucks badly on Linux, but it is very convenient on FreeBSD. Also for SCSI devices FreeBSD has more flexible commands.
While audio seems to be improving on Linux with things like pipewire, for a long time audio was in many cases easier to configure on FreeBSD than on Linux with the dreaded ALSA or pulseaudio, if the audio hardware was supported. Also, when I had to configure once some USB surveillance cameras, that was easier on FreeBSD with webcamd, than on Linux, but like for audio, FreeBSD has a shorter list of supported devices.
Some of the differences in the user interface between FreeBSD and Linux are caused by FreeBSD being more conservative, while in Linux some older tools have been replaced with newer tools, but the newer tools have been made with worse user interfaces, like in the replacement of ifconfig with ip, or in the introduction of ALSA and pulseaudio, which both have an extremely poor user interface, especially for computers with multiple audio devices.
Yes, much easier, Linux is a mess, the firewall disgusting, LVM...buah. The only problem BSD have, are drivers. But you obviously never worked with BSD...unbloated systems ARE easier to use.
Firewalls are the one thing I don't really like on FreeBSD. It gives you 3 options but the handbook doesn't provide much guidance on the pros and cons of each.
I'd prefer it if there was one favored one that all the effort went into to make it really good, just like with everything else FreeBSD. This is not arch where you have to handpick each component :)
Of the 3 FreeBSD firewalls, ipfw is the native firewall, like iptables is for Linux.
The pf firewall is a fork of the OpenBSD firewall. It is the normal choice for someone already familiar with using OpenBSD firewalls. Otherwise, a new user should choose between ipfw and pf the one whose configuration seems easier to understand.
I happen to prefer ipfw, because writing a configuration file for ipfw is exactly like writing a program in a programming language (a language very much like BASIC), which examines the incoming or outgoing packets, by executing instructions sequentially. Others find the syntax used by pf more pleasant, but I find it more difficult to reason about which is the matching rule that will be selected by pf for execution for a certain packet.
The third firewall, ipfilter, is also provided mainly for the former users of it on other operating systems. I am not aware of any particular advantage for it.
Exactly, I found out the same with some googling, but the handbook specifically mentions it will describe the differences and then neglects to do it :)
I was first considering pf because I used it on Mac before, but the problem is the freebsd version was forked quite a long time ago and has different features than the openbsd version as a result.
I went for ipfw mainly because it seems to see the most active development.
But really, I wish FreeBSD would just pick one as standard and keep the others around for compatibility reasons if needed. One of the reasons I like FreeBSD is that you don't have to make such choices. Things have well chosen defaults.
Contrast this with arch which I mentioned, that even lets you decide which mechanism to use for network management (e.g. net manager, connman, systemd-networkd, netctl). It describes this choice really well in its excellent wiki, but when I tried arch it meant I had to do this kind of decision for pretty much every part of the OS :) What I like for FreeBSD is that they keep things simple.
I think Arch and FreeBSD have a lot in common, they're both intended for users that don't expect to click through everything and just dump you on a command prompt where you can set up stuff the way you want, instead focusing on excellent documentation.
I use FreeBSD on my daily driver PC now as I thought Arch was too much work with all the choices, and on the other hand the one thing I did want to change (systemd) it didn't allow.
>>CRUX is a lightweight Linux distribution for the x86-64 architecture targeted at experienced Linux users. The primary focus of this distribution is keep it simple, which is reflected in a straightforward tar.gz-based package system, BSD-style initscripts, and a relatively small collection of trimmed packages.
>>Inspired by CRUX, another minimalist distribution, Judd Vinet started the Arch Linux project in March 2002. The name was chosen because Vinet liked the word's meaning of "the principal," as in "arch-enemy"
BTW Crux is still a great distro, limited packages yes, but absolutely simple and rocksolid.
I like FreeBSB too...well it's my main system since years >8 probably. But if it need's to be linux then Alpine Arch Crux....or the RHEL's Debian's...if i really have to use them.
It is. I honestly struggle to see how anyone would pick Linux over Windows but then pick Linux over BSD. It feels like the worst of both worlds - with Linux you don't get the hardware support and keep-going-at-all-costs of Windows, but you don't get the consistency and comprehensibility of BSD either.
Any commercial OS, like Windows, Mac OS or Android, will be easier to use than any free operating system, for those users who never attempt to do any action that is not on the restricted list of actions for which the commercial OS was designed.
Nevertheless, there are many people like myself, who always discover, when using a computer, that they want to do an action not anticipated by the designers of the commercial OS, either due to lack of awareness about the needs of some people, or because they do not bother to support those that are only a small percentage of their users, or because they have an interest in preventing the owners of the computers to use their property in certain ways.
Whenever it happens that I want to do such an action, I discover that it is much more difficult to do it on Windows than on Linux or on any *BSD, and sometimes even impossible. That is the reason why I have abandoned the use of MS Windows or Mac OS, many years ago, except for various occasions when I am forced to use them temporarily for professional reasons.
Being a BSD user myself, i just said that Windows is easier (overall). I especially talk about Active Directory and Group Policies, on Windows a matter of Hour's on Linux/BSD (a comparable system)...Weeks?
But yes *nix is much more flexible..but that comes with a cost, sometimes a massive one.
Good one. Care to elaborate on your thoughts though? I work in security, I see problems caused by people trying to be edgy in architecture design all the time. You don’t need k8s, or bsd, or rust if you’re a pizza shop website.
> This is uncontexualized hype clearly written by someone with no real world experience, hoping to gaslight users into thinking their current system is insecure.
So typical for BSD fans, find a single flaw then try overblow it and show how their flavour of *BSD is better. It's frankly tiring at this point.
This is uncontexualized hype clearly written by someone with no real world experience, hoping to gaslight users into thinking their current system is insecure. Then I scroll up and noticed the article is written by a company who sell presumably consulting services in unix. Go figure.
Failing that, there’s limited reasons to use BSD systems instead of Linux unless you have highly specialised requirements. Under many cases I’d imagine it would be more expensive in terms of effort required to hire/train skilled staff.