-
-
Notifications
You must be signed in to change notification settings - Fork 12
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
Implement essential policy #79
Comments
Just to clarify, by "not supporting", I mean we don't restrict based on interface and member etc. IOW, if someone is allowed access to a service, they're allowed complete access to that service. |
I don't know if this is a good idea security wise. It's entirely possible for a service to allow access to an interface, but now allow generalized access to all methods (but only those that are protected by Polkit) I'm not saying I have an API like this in mind, I'm just saying that an API like this is feasible. Hell, IIRC at one point I implemented an API like this in homed. Maybe logind actually relies on this, with some methods only callable by the PAM plugin (that runs as root)? Anyways, my point is this sounds like a setup for a very juicy privilege escalation vulnerability. |
Hmm.. perhaps we should still allow interface and path ACL so if services do a good job of splitting their API in different paths and interfaces, they can achieve this. 🤔 Also, if really needed, it be much easier to add support for fine-grained policies w/o breakage than to remove supported configuration later. So we should start simple in any case. |
busd will have to implement a policy. However, I don't think we need to go as far as existing implementations. Most of the policies are not super useful. More specifically, we'll want service-level policy but not method-level. Admins can specify which names can be owned by which users and who can make calls to them. In the D-Bus configuration XML language, this would mean enable configurations like:
and not supporting
send_interface
orsend_member
:We should not error out on encountering unsupported configuration nodes though, but rather just warn about them.
Prerequisites: #78.
The text was updated successfully, but these errors were encountered: