Feature: make the local group prefix configurable for improved security

[ToonSpinTUe]

Is there an existing request for this feature?

• I have searched the existing issues and found none that matched mine

Describe the feature

In large(ish) organizations like mine, many people may have access to Entra/IAM/etc and different people may have access to Linux machines. Allowing an Entra-ID (or similar) admin to add users to the linux-sudo group, is allowing them to grant root privileges to others or themselves. I feel this is a security risk. At the time I'm writing this, this behavior is hardcoded in main.

By the way, I chose to make this a public issue because the documentation is quite open about this in fact being an intended feature.

Describe the ideal solution

Ideally I would get rid of this feature altogether, but it seems it's an intended one. So my suggestion is to at least making it configurable so it can be turned off, and I would prefer to have this behavior turned off by default.

Alternatives and current workarounds

The only thing I can think of is to proactively add groups called "linux-sudo" in whatever provider people are using, and make it so nobody can add users to them.

System information and logs

Not applicable

Relevant information

Not applicable

Double check your logs

• I have redacted any sensitive information from the logs

[adombeck]

Hi, thanks for reaching out. It is indeed intended that Entra ID admins can change the groups of users logging in via Entra ID. If you want to avoid Entra ID admins being able to access specific machines, you can already do that by configuring the allowed users. Does that solve your use case?

[ToonSpinTUe]

That looks like an allowlist of usernames to me, which I suppose is a valid use case but not one that's relevant to what I'm talking about. What I want is for an Entra ID admin not to be able to elevate someone's permissions on my Linux machine.

The use case I'm talking about is where people grant access to Linux servers by placing them in Entra groups. The thought process here is that as a Linux admin, I decide which Entra groups get sudo privileges on which machines and which groups don't. As a perfect example, let's say I don't want ANY members of Entra ID groups to have any sudo privileges. Now if an Entra admin (and because of a deliberate separation of concerns I am not one of those) can add anyone to the sudo group on all of my machines, that security model goes straight out the window. Because of this feature, I have no control whatsoever over who is allowed to do what on any of my machines, as far as I can tell, unless I happen to also be the only Entra ID admin.

By the way, having an "allowed groups" functionality would be awesome too :), but I can do that in OpenSSH already. So that's a different discussion and not one I want to have in the scope of this issue. The point I want to get across is that this has nothing to do with who can access my machines, but instead with who decides what they are allowed to do once they have said access.

[ToonSpinTUe]

Let's simplify the use case. Let's say I have a zero trust environment so I can't trust the Entra ID admins. Now I want to configure my system so john.doe@example.com is the only one to access it, but I don't want them to ever have any sudo privileges. I can't do that, currently, because if the Entra ID admins get hacked, the hackers can grant john.doe@example.com sudo privileges if they know which local groups have those.

[adombeck]

I'm not sure that authd is the right choice for that use case. You still have to trust the Entra ID admins, because, as far as I know, they can just delete your user from the tenant and create a new user with the same UPN which will then be allowed to log in.

[ToonSpinTUe]

Yes, and if I could configure the broker so they can't add the user to the local sudo group, they won't be able to become root so easily. Also they do need to know the user's local password unless I'm mistaken. Again, what I'm asking has nothing to do with access but with privileges on the local machine. You keep bringing up who can or can't log in and I feel like you're missing the point that I'm not talking about who can log in. I'm talking about what they can do once they can, about mitigating the risk that someone can become root on all of my servers.