Grant sudo to the first user by default, still a good idea?

? The default user is the admin user, of course they enter their own password? If you want unprivileged users, you can create them without issues.

Um, no. What you call “the admin user” is just a normal user account for doing everyday work, but this user account has special privileges. So if sudo is set up to use only the user’s own password ─ or worse: no password at all ─ and that user account gets compromised, then the attacker will have an easy way to obtain root privileges on the system, because they only need to know the user’s own password.

There are only two ways to securely set up sudo, and it’s an “either this or that but not both” condition, namely…:

  1. Allow the user to use their own password (or no password at all) for only a limited subset of root-level privileges ─ e.g. shutdown and reboot, or enabling/disabling the network. In other words, restrict what the user can do via sudo.

  2. Allow the user to have full root privileges by way of sudo, but set up sudo to require either the root user’s password, or more generally, the target user’s password.

The practice of setting up sudo to give the user full root privileges by only having to supply their own password is insecure, and was implemented by Ubuntu, because they thought it was safer to disable root logins ─ which also breaks su for obtaining root privileges.

And after Ubuntu’s example, other distributions ─ starting with Mint and Debian, but it didn’t end there ─ began setting up sudo in the same way. But it’s an insecure setup, very much akin to “the Windows way” of doing things.

It is actually very ironic that many of the currently active developers in the GNU/Linux ecosystem look unto Microsoft Windows ─ which is probably (and most notoriously) the least secure operating system design still in use today ─ for their inspiration. But I guess it’s called “user-friendliness”. And user-friendliness always comes at the cost of security. :man_shrugging:

Um, yes. The default user is part of the wheel group. That is the definition of the administrator user. That is the group that the sudo privileges are provisioned to. Regular user cannot escalate to root privileges with sudo on their own credentials, administrator user can.

In gnome settings, you have the option to create a regular user or administrator user. The latter creates user like the one created by calamares and manjaro-architect. I’m using the gnome terminology here. In my mind it’s root user -> admin user -> regular user.

If you want a secure setup, you setup a regular user account after installation for users that are not supposed to have root access.

1 Like

The point is that we’re still talking of a user account that is being used for everyday work, and that thus ─ at least in theory, or when used by an Incompetent Person™ :stuck_out_tongue: ─ can get compromised, as opposed to the root account, which must never be used for anything other than system maintenance and administration tasks.

Therefore, if this account gets compromised, then the attacker will also have root access by simply using the compromised account’s own password. By contrast, if sudo is set up to require the target account’s password ─ and thus in the case that the root account is the target (which is the default if no other options are passed to sudo) ─ then the attacker would still need to guess that account’s password, and thus in most cases, the root password.

I splitted the topic, because the original one was about mount options.

I think it is a bad culture and bad habits, but can we change this without creating too many complaints?

I also remember that on Oracle Linux as a regular user I wasn’t (cap)able connect to WiFi. Obviously regular user are considered not capable enough to set up a secure WiFi connection. I think it is a balancing act to disable some features because of security.

For example to enable SSHD to be able to connect to a machine without asking the local user to do anything. Very insecure and not done by any distro I know.

2 Likes

Good idea to split.

But anyway, i think @Aragorn has a point: with our current setup, calamares sets up root account and administrator account, but there is no option to setup a regular user account, and this is in no way apparent to an inexperienced (or even experienced) user. In fact the dialog makes it look like this is just a regular user account.

1 Like

That is going to be difficult, because many of our newbies come from the world of Ubuntu and Mint, where having sudo require the user’s own password is the default. And once people are used to something, they don’t like changing their habits. :thinking:


Yep. :100: :slight_smile:

Don’t get me wrong, I think that having the first created user account be in the wheel group is a good idea. It’s just that in order to set up sudo safely, it should require the target user’s password, not the invoking user’s password.

In a GUI environment, it doesn’t pose a whole lot of problems if the user only has to supply their own password ─ pkexec already does that in KDE Plasma ─ but attack vectors are usually aiming for a command-line-style exploitation, and sudo is a command-line tool.

However with Calamares which has become probably the most popular installer there is a long leverage.
Should we change the topic category to Development / Calamares?

2 Likes

Sudo should require your own password, if you are an admin. I think the problem is that our current setup makes everyone run as admin by default.

1 Like

It affects both installers. Maybe the feature request category could work?

1 Like

How about the users that set no password and check the Use same password for administrator account aka ROOT ? How you will “fix” that ? :stuck_out_tongue:

1 Like

What about the way Debian does it?

If during installation user enables login for root, then the first user account is not in the sudoers. However if he chooses not to have a root login, then add him to sudoers.

Edit: Maybe event not wheel-ing him too,

No, that’s not the problem. There is no need for anyone to first log into an admin account in order to do root-level things, because then they could just as easily log in as root and save themselves the trouble.

The problem is that sudo as a command-line tool for privilege escalation becomes unsafe if it only requires the user’s own password.

You have to think of sudo as something along the lines of role-based access control. If you set it up so that it only requires the user’s own password, then it should also be set up to only allow a subset of the root user’s privileges to that particular use, and not all of the root account’s privileges.

3 posts were split to a new topic: Calamares not safe for mentally ustable admins and can cause premature death :wink:

Just as a historical note, the wheel group owes its name to the fact that back in the days of minicomputers, the administrator of the system always had to log into what was called “the local console”, i.e. a terminal connected to a physically privileged port on the computer’s chassis, and this was compared to the driver of a car being the person sitting at the wheel.

Staying in line with this, the wheel group is normally by default also allowed to use the command su, but su is by default set up to require the target user’s password. The reason why Ubuntu chose to set up sudo to require only the user’s own password is that they disable the root account, and as such, you cannot even use su to become root anymore ─ or that is to say, not without sudo.

But if you run sudo as normal user, it asks you the administrator password instead of your own. That’s the setup that produces your desired state. That is why I think this is a problem in the user setup. Wheel group is supposed to be for administrators.

I think this one good way of doing it. But would require patching calamares.

1 Like

No, I’m afraid you misunderstand. There is no such thing as a separate administrator password. Passwords are tied to the user accounts themselves, not to the privilege levels.

Okay, let’s go over the different possibilities for altered privileges…

  1. su ─ which stands for “substitute user” ─ is the traditional way of doing things under a user ID that’s different from the one that you are logged in as. And su does by default require the password of the target account that you want to switch to.

  2. pkexec is the GUI way of doing things with altered or elevated privileges, but its settings are determined by policykit.

In both scenarios here-above, the account who tries to elevate their privileges must be in the wheel group.

But sudo is different. Sure, you can grant sudo privileges to everyone who is in the wheel group ─ in Ubuntu and Mint, they use a group called admin instead ─ but sudo comes set up by default to only ask for the password of the user who invokes it, and given that sudo is a command-line tool only, this opens up the door for exploitation via a malicious script or a remote break-in by way of ssh. After all, many users use very weak and easy-to-guess passwords, and that’s how most break-ins via ssh happen.

No, I think root password should not be known to all admin users on a multiuser system. It should be possible to give a user temporary admin privileges and to be able to take them again.

1 Like

It might be. You are also misunderstanding what I mean.
In my experience, this is what happens:
I have my user, matti, which is created by calamares. It is part of the wheel group. It is listed as admin on the user settings of gnome settings. I create a new user “testuser” that is not in the wheel group. When I log in with this user and run something with sudo, sudo asks for the password of user “matti”, not for the password of user “testuser”.

This how it should work imho, and how it has worked for me thusfar.