Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow unprivileged access to "read-only" protocol messages #431

Open
q66 opened this issue Jan 16, 2025 · 1 comment
Open

allow unprivileged access to "read-only" protocol messages #431

q66 opened this issue Jan 16, 2025 · 1 comment

Comments

@q66
Copy link
Contributor

q66 commented Jan 16, 2025

It would be nice if protocol messages like querying service status were available unprivileged so that you could e.g. dinitctl --system list as a user.

The way I'm thinking it could be done is:

  1. add a parameter to dinit specifying the requested permissions for the socket; default to 666 on supported platforms, and 600 elsewhere for system dinit (the parameter would let people e.g. force it to 600 always if they don't want unprivileged users to access that), user dinit would have 600 always by default (doesn't really make sense to allow random users to access other random users' control socket)
  2. add code to check the uid of the connection via SO_PEERCRED; block access to "write" protocol messages, as well as probably specific other messages such as GETALLENV, by issuing a protocol error - we could also issue a specific return message like some kind of "permissions denied" and make it recoverable

The code would be behind a feature flag, therefore supported only on OSes that have socket peer credentials (Linux/BSDs/Darwin all support those for TCP sockets though with slightly different API)

I could implement this but I want to hear your thoughts on it first...

@davmac314
Copy link
Owner

Sorry for being slow to respond, I'm travelling at the moment and busy.

Basically I think this is reasonable if (as you suggested) it's behind a feature flag and can be disabled. In terms of implementation it needs to be done very carefully - it introduces a change in the security model since up until now Dinit does not need to concern itself with walling itself off from unprivileged processes (the idea has been that access to the control socket requires privilege). It would be good to keep very clear in the code the privileged vs unprivileged operations - possibly even moving them into separate source files, and/or big comment markers to delimit them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants