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

Support a single qrexec service argument, available to qrexec policy #1876

Closed
marmarek opened this issue Mar 27, 2016 · 0 comments
Closed

Support a single qrexec service argument, available to qrexec policy #1876

marmarek opened this issue Mar 27, 2016 · 0 comments
Labels
C: core P: major Priority: major. Between "default" and "critical" in severity. release notes This issue should be mentioned in the release notes. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.
Milestone

Comments

@marmarek
Copy link
Member

The idea is to have control over qrexec policy not only based on service, but also based on some argument. This will allow to implement something like "allow service X, but only with argument Y". In most cases better idea is to have separate services or domains for that (for example multiple gpg backend domains), but there are use cases where it still can be a good idea. For example PV USB (#531) (USBIP variant) - "allow attaching this particular USB device" (creating separate services for that doesn't scale...).

As for implementation details, that argument will be encoded into service name, after + sign. This way it doesn't require major protocol change. Changes include:

  • allow + in service name
  • fallback to bare service name (with anything after + stripped) if full name isn't found - for both qrexec policy (/etc/qubes-rpc/policy/*) and qrexec target script (/etc/qubes-rpc/*).
  • provide service argument to the target script in most convenient and compatible way

This means that target script may be named /etc/qubes-rpc/some.service, and it will be called for both some.service and some.service+argument (unless /etc/qubes-rpc/some.service+argument exists). Policy can be set for different arguments in appropriate /etc/qubes-rpc/policy/some.service+argument, then default policy in /etc/qubes-rpc/policy/some.service (most likely plain deny - empty file will do).

Target script will receive service argument as... its argument. Additionally there may be environment variable with it available, but it hasn't been decided whether it will be part of stable API.

@marmarek marmarek added T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. C: core P: major Priority: major. Between "default" and "critical" in severity. release notes This issue should be mentioned in the release notes. labels Mar 27, 2016
@marmarek marmarek added this to the Release 3.2 milestone Mar 27, 2016
marmarek added a commit to marmarek/old-qubes-core-agent-linux that referenced this issue Mar 27, 2016
@marmarek marmarek mentioned this issue Mar 27, 2016
marmarek added a commit to marmarek/old-qubes-core-admin that referenced this issue Mar 29, 2016
marmarek added a commit to marmarek/qubes-core-admin-linux that referenced this issue May 20, 2016
Fixes QubesOS/qubes-issues#1876

Signed-off-by: Marek Marczykowski-Górecki <[email protected]>
marmarek added a commit to marmarek/qubes-core-admin-linux that referenced this issue May 25, 2016
Fixes QubesOS/qubes-issues#1876

Signed-off-by: Marek Marczykowski-Górecki <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: core P: major Priority: major. Between "default" and "critical" in severity. release notes This issue should be mentioned in the release notes. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.
Projects
None yet
Development

No branches or pull requests

1 participant