After looking at a security related thread questions of sanity arise. Do fedora users normally operate their systems logged in using accounts that have sudo privileges?
For many years this has been forbidden in any security minded work environment I’ve participated in. Installing fedora with a locked root account (no local or remote login capability) is in line with security aware administration. During install at least one account needs to be configured that does have sudo privileges (and at most a small number). Then every user has an unprivileged account for normal use.
When administrative tasks require root privileges an administrative user logs in with their account that has sudo privileges (in more security oriented environments everything done with sudo is audited and traceable to the individual). Otherwise they only log in with their regular user account.
Have I gone mad?
Does the fedora community need to be better educated on the ramifications of having sudo privileges?
I’m hoping 2 is the actual case. Any documents on this topic already available showing the fedora slant?
By default, the first user account which is created will have sudo privileges, won’t it?
By default, we allow users to install rpms/flatpaks and apply updates even without sudo, don’t we?
I guess that is what you do when you don’t want new users to be “helpless” …
As long as PATH, bashrc etc are writable, processes can catch your sudo password.
Anaconda (the installer) doesnt seem to allow to create multiple users at the same time, so you create a wheel user and from that another one for regular use.
Rpm-ostree doesnt work for non-wheel users currently, which is pretty bad. In the process of fixing that. But I think dnf also doensnt allow updates for nonwheel users, which means you basically cant use your system ? Not sure if the GUI stores allow that using packagekit.
To install systemwide flatpaks, users have to be in the flatpak group. same for libvirt for virtual machines.
Flatpaks can be installed for the user only, using a user repo, which doesnt require that repo.
There are other problems like securing some files. You would want to have your ssh or gpg keys not readable by processes running as the user, so you need some other way than chown-ing them to root, if you remove the sudo permissions.
For most users using explicit sudo is seen as safer then being root to do admin.
If a user does not need to do admin then they do not need sudo access, and should not have it configured.
If you are in an enterprise environment on linux it is often as a developer or a devops engineer. In both cases you are likely to be allowed to do sudo as a necessary part of your job. Everyone else is on Windows to running office365
So, even if the account I’m using has sudo privileges, that doesn’t mean that everything I’m doing is being done as sudo/administrator (which would be the case if one uses the “root” account). If I want to run a privileged command, i must prefix it with sudo and then enter my password pretty much each time (and the time sudo “remembers credentials” can be tweaked). Basically, in my use case where I’m the single user for my machine, I rarely use sudo—only to run an upgrade once a week or install/uninstall packages.
Could you explain what the security issue in this usage is please? (If someone has access to my machine and is aware of my administrative password, me using a non administrative account won’t really prevent misuse)
Desktop Linux is based on the fact that users can edit their desktop and shell how they want. At the same time, even Flatpaks have access to exactly those parts
~/.bashrc (and the other shells)
/.local/bin/
~/.local/share/applications/
~/.ssh/
~/.gnupg/
This is pretty insane. Any randomly downloaded Appimage can edit those and alias your sudo command as explained in the article.
They can also copy system .desktop entries and manipulate them, the fact that this works is some fundamental Desktop Linux concept and its very bad. Editing applications, binaries and commands is a privileged process and should not be possible for random non-system applications.
The entire /home/username/ is mounted executable, which also opens up a ton of attack surface. Normally you wouldnt need that, you install programs from repos using dnf and flatpak.
This is only needed for hacky scripts and more, basically development. So this could be isolated in a VM or isolated container (not distrobox by default).
Android and ChromeOS are really good examples how a secure Linux system can look like, and its extremely restricted.
I would be really happy about the Fedora Community addressing these problems. A good ground to discuss and implement them, with the willingness to break some functionality, is Secureblue
This should go without saying but I meant “can you link to the specific guidance in question”.
In other words, what part of that whitepaper describes the specific issue we are discussing?
This talks about the general limitations of Linux security and sudo. It doesn’t talk about the benefit of using a separate account. Those risks still exist if you use su mysecureaccount instead of sudo <command>
I agree that we should be having more conversations about improving Linux security but that is a broader conversation.
Security is always a matter of trade-offs. For an individual desktop system, the convenience of having a main user account with the ability to escalate to administrative (root) privilege by re-authenticating generally outweighs the risk.
On such systems, the valuable stuff is almost always in the user’s home directory under their control anyway. The only real reason for an attacker to escalate to root is to install some persistent, hidden malware. While there are various ways to manipulate the user’s dotfiles to snoop for the password … there are probably other more common vectors to compromise.
One possible increase in security would be to require a second factor (like a TOTP # from a phone app) for root escalation, in addition to just the password. Or, for that matter, to always require that second factor (including for initial log-in). But, that kind of thing does get inconvenient… so it’s back to the question of the threat model.
For a multi-user system more separation is certainly better, as well as stronger authentication and authorization steps.
If you find things, dont hesitate to open an issue on secureblue. I see it as a more or less uncompromising project, and things experimented with there can easily be adapted into Fedora after all the bugs where fixed.
It already has 86 images and testing various versions and desktops (cinnamon is now added) will help find the various pitfalls.
So at least one account requires sudo root for administration. A developer would likely not need sudo root, but may require specific commands (like ability to install something via DNF
for example). Although someone did mention that is now allowed without sudo so that’s cool.
But anyone who is going to administer the system obviously needs root.
Personally not a huge fan of sudo for root, as although it gives good logging / auditing, by default it uses the same password that you logged in with. So if someone gets your regular non-priv password, they then have root. In a large organisation where someone could get your domain / local password any number of different ways, this is a problem.
There is an option for sudo to prompt for the actual root password , so you need to logon with your regular password and then if you sudo /bin/bash, you will be prompted for the root password. It’s not a widely known/used option from what i’ve seen, but it’s what I do and works really well. Working this way is similar to on older UNIX systems where you would “su - root” and enter the root password in order to perform sysadmin functions.
Of course, there are plus and minus for every setup. It depends on what your threat model is. And also depends how far you want to go with securing things. Often the way someone will priv esc due to misconfiguration or unpatched services etc.
