That it is difficult and most people have "better things to do", fine, I can agree that this can't work for like, all computer users. But if you really care ab

That it is difficult and most people have "better things to do", fine, I can agree that this can't work for like, all computer users. But if you really care about security, and if you are managing a linux OS where you have a lot of deep access to the system, I think saying "I have better things to do with my time than understand the system I'm managing; that's what vendors are for" is a lazy perspective. Consider this: https://github.com/systemd/systemd/issues/6237 https://github.com/systemd/systemd/issues/6237 Order of events here: - RedHat creates systemd to handle init and daemons--something that used to be handled mostly by shell scripting and much simpler tools. - Debian and RHEL based systems adopt systemd. That's most Linux systems. - About 6-7 years later, an issue is noticed and reported by a user. If a user creates a service to be run under a username beginning with a number, which some distros (not RHEL or Debian though), systemd validates the name (why?) by matching it against a regex. -If validation on any field fails, they categorically ignore that field and run the service. -In this case, because it is the user name, it runs the service as root instead of the user name. -Their response? "This is how the system handles all fields. We do it for consistency and compatibility. Closed." -That was 3 years ago. This was never fixed. "It's not a bug! Just don't give systemd a potentially valid user name that looks like that!" So using the daemon system promoted by RedHat (who we trust!) has created a situation where a process--possibly a server or something public facing--could be run as root without you immediately realizing it. You don't care to understand your system, but you do have to operate it. RedHat won't do that part for you. So, you could create these conditions unknowingly. It wasn't malicious, but what's important is that it isn't necessary. Look at what kinds of questions did the RedHat maintainers ask? "I wonder what tool allowed you to generate this file?" A totally useless question, given these files are frequently generated manually. "It's the tools fault! Whatever it is. Even though it might be a valid username on your system." A better question might be "Why do we have to validate/parse the username field at all?" After all, parsing bugs are well-known for creating security vulnerabilities, and if the name is invalid, then there will be no user, and the service will fail in the same way it does when the username string is syntactically valid but there is simply no user. In short, they have a product that "helps you manage your OS; and from RedHat (who we trust!)", yet we find that it increases complexity; does unnecessary work; and results in a bug that could allow a process to run root when it should not. This scenario is so similar to the flatpak sandbox issue. "It's not a bug. It's just that most people are misconfiguring it." Fine! But you chose to embrace the added complexity of a system (flatpak) that you just don't actually need. It has pros and cons. It's not a matter of trusting RedHat not to be malicious--it's trusting them to make that judgement for you. Their judgement is not perfect. There is a medium that exists between "audit every line of source in the system yourself" and "trust implicitly everything a vendor says and does". I think that RedHat is reputable and trustworthy, and they are trying to push Linux forward, but they are simultaneously reinforcing their position as industry experts through creating software that "eats linux". It's not malicious, it's just the nature of their existence. Your interests and their interests are not the same, so it makes sense to consider things for yourself.