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.

Sign up for GitHub

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

Jump to bottom

Improve handling of restricted Admin API policy #5099

Open
marmarek opened this issue Jun 14, 2019 · 1 comment
Open

Improve handling of restricted Admin API policy #5099

marmarek opened this issue Jun 14, 2019 · 1 comment
Labels
C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.

Comments

@marmarek
Copy link
Member

The problem you're addressing (if any)
Writing policy for management VM for qvm-* tools to work require multiple trade-offs. For example:

  • full list of VMs needs to be allowed
  • full list of labels and other global objects needs to be allowed

Describe the solution you'd like

  1. Limit admin.vm.List output (which when directed to dom0 - list all the VMs) to a list of VMs explicitly allowed in admin.vm.List policy, even when the call is to dom0.
  2. When information about a VM is retrieved through Admin API (for example a property referencing another VM), do not try to list that VM.

Where is the value to a user, and who might that user be?
Ease writing concise and precise Admin API policy. Basically, remove catches mentioned in https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/#simple-management-vm-demo

Related, non-duplicate issues
#3293
@marmarek marmarek added T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. labels Jun 14, 2019
@marmarek marmarek added this to the Release 4.0 updates milestone Jun 14, 2019
@marmarek marmarek self-assigned this Jun 14, 2019
marmarek added a commit to marmarek/qubes-core-admin-client that referenced this issue Jun 14, 2019
@marmarek
Do not check for object existence when got it with another Admin API …
c46b09b 
…call

When qubesd returns an name of VM or other object, as part of another
call (reading a property, listing devices etc), it's safe to assume that
object exists. Do not try to list it, which could be prevented by qrexec
policy. This means a VM object would be returned (for example in
vm.netvm property), which potentially could not be listed through
app.domains collection. This may lead to some corner cases, but
generally should ease handling of restricted policy.

This does not affect practical information the management VM have access
too, as those names are already returned. It's just client side python
wrapper that didn't allowed to access them.

QubesOS/qubes-issues#5099
marmarek added a commit to marmarek/qubes-core-admin-client that referenced this issue Dec 3, 2019
@marmarek
Do not check for object existence when got it with another Admin API …
95f58c9 
…call

When qubesd returns an name of VM or other object, as part of another
call (reading a property, listing devices etc), it's safe to assume that
object exists. Do not try to list it, which could be prevented by qrexec
policy. This means a VM object would be returned (for example in
vm.netvm property), which potentially could not be listed through
app.domains collection. This may lead to some corner cases, but
generally should ease handling of restricted policy.

This does not affect practical information the management VM have access
too, as those names are already returned. It's just client side python
wrapper that didn't allowed to access them.

QubesOS/qubes-issues#5099
@marmarek marmarek mentioned this issue Dec 7, 2019
Merged
marmarek added a commit to marmarek/qubes-core-admin-client that referenced this issue Jan 18, 2020
@marmarek
Do not check for object existence when got it with another Admin API …
2b35272 
…call

When qubesd returns an name of VM or other object, as part of another
call (reading a property, listing devices etc), it's safe to assume that
object exists. Do not try to list it, which could be prevented by qrexec
policy. This means a VM object would be returned (for example in
vm.netvm property), which potentially could not be listed through
app.domains collection. This may lead to some corner cases, but
generally should ease handling of restricted policy.

This does not affect practical information the management VM have access
too, as those names are already returned. It's just client side python
wrapper that didn't allowed to access them.

QubesOS/qubes-issues#5099
marmarek added a commit to marmarek/qubes-core-admin-client that referenced this issue Jan 28, 2020
@marmarek
Do not check for object existence when got it with another Admin API …
7ea6c00 
…call

When qubesd returns an name of VM or other object, as part of another
call (reading a property, listing devices etc), it's safe to assume that
object exists. Do not try to list it, which could be prevented by qrexec
policy. This means a VM object would be returned (for example in
vm.netvm property), which potentially could not be listed through
app.domains collection. This may lead to some corner cases, but
generally should ease handling of restricted policy.

This does not affect practical information the management VM have access
too, as those names are already returned. It's just client side python
wrapper that didn't allowed to access them.

QubesOS/qubes-issues#5099
@marmarek
Copy link
Member Author

Generally admin.Events is a more tricky than that, because it also disclose a bunch of other information - like properties values when it being set. This could be handled in similar manner (analyze policy for admin.vm.property.Get with appropriate argument for example), but this is left for future extension, not part of this issue.

marmarek added a commit to marmarek/qubes-core-admin that referenced this issue Feb 21, 2020
@marmarek
api/internal: extract get_system_info() function
49a8fb8 
This will be useful in other places too.

QubesOS/qubes-issues#5099
marmarek added a commit to marmarek/qubes-core-admin that referenced this issue Mar 9, 2020
@marmarek
api/internal: extract get_system_info() function
879ee9e 
This will be useful in other places too.

QubesOS/qubes-issues#5099
@qubesos-bot qubesos-bot mentioned this issue Apr 18, 2020
Closed
marmarek added a commit to marmarek/qubes-core-admin-client that referenced this issue Apr 20, 2020
@marmarek
Do not check for object existence when got it with another Admin API …
17c52a7 
…call

When qubesd returns an name of VM or other object, as part of another
call (reading a property, listing devices etc), it's safe to assume that
object exists. Do not try to list it, which could be prevented by qrexec
policy. This means a VM object would be returned (for example in
vm.netvm property), which potentially could not be listed through
app.domains collection. This may lead to some corner cases, but
generally should ease handling of restricted policy.

This does not affect practical information the management VM have access
too, as those names are already returned. It's just client side python
wrapper that didn't allowed to access them.

QubesOS/qubes-issues#5099
marmarek added a commit to marmarek/qubes-core-admin-client that referenced this issue May 18, 2020
@marmarek
Do not check for object existence when got it with another Admin API …
5315bbf 
…call

When qubesd returns an name of VM or other object, as part of another
call (reading a property, listing devices etc), it's safe to assume that
object exists. Do not try to list it, which could be prevented by qrexec
policy. This means a VM object would be returned (for example in
vm.netvm property), which potentially could not be listed through
app.domains collection. This may lead to some corner cases, but
generally should ease handling of restricted policy.

This does not affect practical information the management VM have access
too, as those names are already returned. It's just client side python
wrapper that didn't allowed to access them.

QubesOS/qubes-issues#5099
@qubesos-bot qubesos-bot mentioned this issue May 24, 2020
Closed
marmarek added a commit to QubesOS/qubes-core-admin-client that referenced this issue Oct 24, 2020
@marmarek
Do not check for object existence when got it with another Admin API …
eb6e887 
…call

When qubesd returns an name of VM or other object, as part of another
call (reading a property, listing devices etc), it's safe to assume that
object exists. Do not try to list it, which could be prevented by qrexec
policy. This means a VM object would be returned (for example in
vm.netvm property), which potentially could not be listed through
app.domains collection. This may lead to some corner cases, but
generally should ease handling of restricted policy.

This does not affect practical information the management VM have access
too, as those names are already returned. It's just client side python
wrapper that didn't allowed to access them.

QubesOS/qubes-issues#5099

(cherry picked from commit 5315bbf)
@qubesos-bot qubesos-bot mentioned this issue Oct 25, 2020
Closed
@qubesos-bot qubesos-bot mentioned this issue Nov 2, 2020
Closed
@andrewdavidwong andrewdavidwong modified the milestones: Release 4.0 updates, Release TBD Apr 7, 2023
@andrewdavidwong andrewdavidwong removed this from the Release TBD milestone Aug 13, 2023
@marmarek marmarek removed their assignment Mar 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@marmarek @andrewdavidwong