Accounts with sudo

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.

  1. Have I gone mad?
  2. 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?

1 Like

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” …

The technique of using the same account for everyday use and administrative tasks is a security no-no. The installer is a good place to add a first administrative user with sudo access but it also allows adding additional users without sudo. Or add nonadministrative users after installation. Just do not use an account with sudo privileges for nonadministrative tasks.

This security 101 concept is well documented by organizations like SANS, SEI, NIST etc. many years ago. Having heightened security awareness in the fedora community would be helpful and just make fedora that much better.

Yes, and this is a problem.

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.

Some groups are missing still

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.

I am not using an atomic variant just dnf installing packages and flatpak.

If an administrative account with sudo access is made at install time and a regular user account made afterwords everything should still be fine. Just login with the administrative user account when performing administrative tasks is a quite workable option.

But when, as a nonadministrative user, running something like

flatpak install --system zoom

I get a popup asking for administrator credentials. It is hard to tell from the prompt which user’s credentials are being requested though. I just cancel the operations and switch to the administrative user login and perform the privileged operation. Then logout of the administrative user account.

1 Like

It all depends on your threat model.

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 :wink:

1 Like

Explicit sudo is not enough ever even in a light threat model.

When root is needed it is better to use sudo instead. Some work would be needed but it is possible to configure sudo for a user without granting full root. But most with sudo access are trusted to use sudo rather than switching to root for the most part. In those cases though it is a different login account the admin/devops user uses from their regular user account.

At least that has been my experience in multiple organizations. Being a basic security tennant I expeted it was universal in any linux community.

usermod -aG flatpak $USER

or use the user repo, obviously. Fedora has no docs on that for some reason, opensuse does.

flatpak remote-rm --force flathub &&\
flatpak remote-add --user flathub

This allows completely privilege-less flatpak

I do not think being in the flatpak group does that. You are adding the remote --user.

With fedora polkit gives users in the wheel group passwordless sudo to the flatpak command to perform --system operations.

In any case using a seperate admin account with sudo access allows for administering flatpak --system without adding any user to the flatpak group (which is not good security wise). Restricting flatpak --system operations to administrative users only and requiring authentication would be preferable. It is crazy all the destruction a bad actor could accomplish with the ability to flatpak --system. Be jealous on how you protect your admin accounts that do have sudo privileges!

The systems I build do not have any users in the wheel group. Accounts with sudo privileges have their own configuration in files in /etc/sudoers.d and passwords are locked. They can only authenticate with strong authentication. Jealous I know.

It depends on you if you want to install or uninstall flatpak apps from the nonwheel user.

If you add a user to the flatpak group, they can do that without being wheel.

Yes if you are cautious either use the --user repo or --system without that group.

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)

1 Like

I am not a security researcher so finding a better explanation from one of them would build a better picture but at some level the problem is numbers related.

If you have 1 account with root access (root) there is only one account on the system that if compromised is really bad at a system level. Every account that has wheel group membership basically counts as a root access account resulting in 2 or more accounts that if compromised is really bad.

Additionally performing every task on a system as root being really bad is well known and it is expected that nobody does that anymore. All the tasks a regular user does still exposes the system to risk and if compromized limiting the ease with which damage can occur is good. It is easier to do bad things using an account with sudo privileges (e.g. if the password was obtained for an account with sudo so has full root access).

1 Like

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

Can you link to that specifically? Most of what I have seen is related to using a privileged account to perform unprivedged tasks.

However, calling an account that has the rights to escalate via sudo “privileged” is a gray area.

I have been through many security audits and this was never flagged as a risk by any auditing organization.

There was a discussion with one auditor where we discussed the pros and cons of this approach but that was it.

Ultimately, it comes down to your use case and threat model if it makes sense or not.

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.

There are lots of resources and it is a hugely broad set of issues. Many resources seem they couldn’t care less about an individual’s single desktop and much of the topic is considered only applicable to big business and governments. I would think linux communities even for desktop use would want similar best practices to be in use as an event on an individual desktop is hugely devastating to the individual.

I’ll have to look into what chromos does and consider what would allow the flexibility of fedora yet provide increased safety/security.

blocking su would also be needed, good point

Interesting that the jump to blocking is made. I am all for technical solutions but for the most part much of this can be accomplished by user education and disipline.

1 Like

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.