lix-project/lix

Fork 58

Lookup supplementary groups during peer credential lookup #968

New issue

Open

opened 2025-08-19 18:00:29 +00:00 by raito · 3 comments

raito commented

2025-08-19 18:00:29 +00:00

Owner

When running "highly" hardened workloads with DynamicUser=true from systemd, primary UID/GID are not stable.

Therefore, bestowing allowed user or trusted user privileges to these workloads is non-trivial.

To avoid this, a simple trick would be to use a supplementary group and thread it via systemd and making Lix accept connections from that supplementary group.

Unfortunately, Lix does not perform any lookup of supplementary groups and only know about primary UID/GIDs.

Describe the solution you'd like

PAM lookup at peer credential lookup time to obtain richer information about the pending connection.

Describe alternatives you've considered

Static allocations which is the classical workaround.

Additional context

This came up while setting up Renovate for lix-project/nixos-module in a safe way.

cc @delroth

## Is your feature request related to a problem? Please describe. When running "highly" hardened workloads with `DynamicUser=true` from systemd, primary UID/GID are not stable. Therefore, bestowing allowed user or trusted user privileges to these workloads is non-trivial. To avoid this, a simple trick would be to use a supplementary group and thread it via systemd and making Lix accept connections from that supplementary group. Unfortunately, Lix does not perform any lookup of supplementary groups and only know about primary UID/GIDs. ## Describe the solution you'd like PAM lookup at peer credential lookup time to obtain richer information about the pending connection. ## Describe alternatives you've considered Static allocations which is the classical workaround. ## Additional context This came up while setting up Renovate for lix-project/nixos-module in a safe way. cc @delroth

raito added the

E/easy

E/help wanted

Area/protocol

labels

2025-08-19 18:01:44 +00:00

raito added the

release-blocker

label

2025-11-17 22:51:08 +00:00

lix-bot commented

2025-11-25 11:41:57 +00:00

Member

This issue was mentioned on Gerrit on the following CLs:

commit message in cl/4646 ("nix/daemon: refactor peer authentication")

This issue was mentioned on Gerrit on the following CLs: * commit message in [cl/4646](https://gerrit.lix.systems/c/lix/+/4646) ("nix/daemon: refactor peer authentication")

pennae commented

2025-11-26 17:06:20 +00:00

Owner

considering the raciness of retrieving supplementary groups of a process outside of the specific DynamicUse case we cannot consider this a safe thing to add. freebsd can provide supplementary groups with is LOCAL_PEERCRED sockopt, until linux can do this we cannot safely implement this. at least the worst that can happen is that we incorrectly reject a connection if supplementary groups are dropped, but that's still a bad experience.

we should probably use ACLs on the socket for allowing connections at all instead, with a second socket for trusted connection proofs (or just a plain trusted socket that is always tried first)

considering the raciness of retrieving supplementary groups of a process *outside* of the specific DynamicUse case we cannot consider this a safe thing to add. freebsd can provide supplementary groups with is LOCAL_PEERCRED sockopt, until linux can do this we cannot safely implement this. at least the worst that can happen is that we incorrectly *reject* a connection if supplementary groups are dropped, but that's still a bad experience. we should probably use ACLs on the socket for allowing connections at all instead, with a second socket for trusted connection proofs (or just a plain trusted socket that is always tried first)

pennae commented

2025-11-26 17:22:12 +00:00

Owner

actually, no. due to supp-group enumeration requiring pid-referred proc access on linux and pid reuse being a thing you could swindle yourself into a trusted connection by forking after opening the connection and waiting for a bit if the system has a trusted group configured. this completely defeats the point of hardening the daemon to begin with.

this is a dangerous feature unless we rely on the OS to do the permission checks for us!

actually, no. due to supp-group enumeration requiring pid-referred proc access on linux and pid reuse being a thing you could swindle yourself into a *trusted* connection by forking after opening the connection and waiting for a bit if the system has a trusted group configured. this completely defeats the point of hardening the daemon to begin with. *this is a dangerous feature* unless we rely on the OS to do the permission checks for us!

raito added

E/hard

and removed

E/easy

labels

2025-11-26 21:11:18 +00:00