developer documentation: cannoncial way to detect Qubes

[adrelanos]

(The TorBirdy developer wants to know...) (rephrased)

What is the canonical way for a program to detect it is being run inside Qubes?

I am inclined to make the following timely answer:

If command {{{qubesdb-read}}} is available on the system ({{{command -v qubesdb-read}}}), then it should be running in Qubes.

(This is also interesting for me during Whonix development. This is what I have been using in Whonix.)

Does that sound alright? @marmarek

Something worth adding to developer documentation. Where? @andrewdavidwong

[andrewdavidwong]

AFAIK, qubesdb-read itself isn't documented (yet). So, the appropriate place for this will probably be wherever that gets documented.

[andrewdavidwong]

AFAIK, qubesdb-read itself isn't documented (yet). So, the appropriate place for this will probably be wherever that gets documented.

[andrewdavidwong]

@adrelanos, is a goal for whonix-ws VMs not to be able to tell that they're running inside Qubes? That would be desirable for privacy, but not sure about feasibility.

[andrewdavidwong]

@adrelanos, is a goal for whonix-ws VMs not to be able to tell that they're running inside Qubes? That would be desirable for privacy, but not sure about feasibility.

[andrewdavidwong]

The original problem mentioned in that ticket should already be resolved by #1024, though.

[andrewdavidwong]

The original problem mentioned in that ticket should already be resolved by #1024, though.

[adrelanos]

Andrew David Wong:

@adrelanos, is a goal for whonix-ws VMs not to be able to tell that they're running inside Qubes? That would be desirable for privacy, but not sure about feasibility.

For fingerprinting from remote, very much yes.

For local compromise (untrustworthy applications, malware) it would be
interesting to avoid them finding that out as well, but I don't think it
will be feasible.

[adrelanos]

Andrew David Wong:

@adrelanos, is a goal for whonix-ws VMs not to be able to tell that they're running inside Qubes? That would be desirable for privacy, but not sure about feasibility.

For fingerprinting from remote, very much yes.

For local compromise (untrustworthy applications, malware) it would be
interesting to avoid them finding that out as well, but I don't think it
will be feasible.

[marmarek]

As for detecting Qubes - the current version have qubesdb-read, but I wouldn't use it as ultimate solution - Qubes R2 didn't have it and some (far) future version may have it changed. If just checking for some command existence, better check qvm-run or qvm-open-in-dvm. But maybe better, instead of just checking tools existence, check some VM property? I don't see any universal (for any Qubes version) method for that, but for the current one qubesdb-read /name should be enough.

[marmarek]

As for detecting Qubes - the current version have qubesdb-read, but I wouldn't use it as ultimate solution - Qubes R2 didn't have it and some (far) future version may have it changed. If just checking for some command existence, better check qvm-run or qvm-open-in-dvm. But maybe better, instead of just checking tools existence, check some VM property? I don't see any universal (for any Qubes version) method for that, but for the current one qubesdb-read /name should be enough.

[adrelanos]

We could also look for the existence of a file or folder. Perhaps folder /usr/lib/qubes? But then we would hope for all future that no package that was once adding a file to /usr/lib/qubes gets upstreamed and used in other distributions.

To solve that in Whonix, there is:

• /usr/share/whonix/marker
• /usr/share/anon-dist/marker
• /usr/share/anon-gw-base-files/gateway
• /usr/share/anon-ws-base-files/workstation

Perhaps something similar should be introduced in Qubes?

I would not worry about older versions. And be fine sorting that out in future versions. Because old versions get deprecated at some point and don't let the perfect be the enemy of the good.

[adrelanos]

We could also look for the existence of a file or folder. Perhaps folder /usr/lib/qubes? But then we would hope for all future that no package that was once adding a file to /usr/lib/qubes gets upstreamed and used in other distributions.

To solve that in Whonix, there is:

• /usr/share/whonix/marker
• /usr/share/anon-dist/marker
• /usr/share/anon-gw-base-files/gateway
• /usr/share/anon-ws-base-files/workstation

Perhaps something similar should be introduced in Qubes?

I would not worry about older versions. And be fine sorting that out in future versions. Because old versions get deprecated at some point and don't let the perfect be the enemy of the good.

[woju]

On Thu, May 05, 2016 at 09:57:07AM -0700, Patrick Schleizer wrote:

What is the canonical way for a program to detect it is being run inside Qubes?

FWIW, cat /etc/os-release. It is documented somewhere on
freedesktop.org, but I don't remeber where.

pozdrawiam / best regards .-.
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers, | '-.-' |
I fear lack of them. '-._ : ,-'
-- Isaac Asimov `^-^-_>

[woju]

On Thu, May 05, 2016 at 09:57:07AM -0700, Patrick Schleizer wrote:

What is the canonical way for a program to detect it is being run inside Qubes?

FWIW, cat /etc/os-release. It is documented somewhere on
freedesktop.org, but I don't remeber where.

pozdrawiam / best regards .-.
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers, | '-.-' |
I fear lack of them. '-._ : ,-'
-- Isaac Asimov `^-^-_>

[adrelanos]

Wojtek Porczyk:

On Thu, May 05, 2016 at 09:57:07AM -0700, Patrick Schleizer wrote:

What is the canonical way for a program to detect it is being run inside Qubes?

FWIW, cat /etc/os-release. It is documented somewhere on
freedesktop.org, but I don't remeber where.

We currently do not modify that file. Maybe we should. Maybe not.
Depending on if that would lead to any issues.

There is also /etc/dpkg/origins/ folder. Whonix was asked to modify it.
Which has lead to a minor issue:

https://www.whonix.org/wiki/Known_Issues#.22apt-get_source_package.22_will_show_.22dpkg-source:_warning:_failed_to_verify_signature.22

[adrelanos]

Wojtek Porczyk:

On Thu, May 05, 2016 at 09:57:07AM -0700, Patrick Schleizer wrote:

What is the canonical way for a program to detect it is being run inside Qubes?

FWIW, cat /etc/os-release. It is documented somewhere on
freedesktop.org, but I don't remeber where.

We currently do not modify that file. Maybe we should. Maybe not.
Depending on if that would lead to any issues.

There is also /etc/dpkg/origins/ folder. Whonix was asked to modify it.
Which has lead to a minor issue:

https://www.whonix.org/wiki/Known_Issues#.22apt-get_source_package.22_will_show_.22dpkg-source:_warning:_failed_to_verify_signature.22

[marmarek]

I don't think we should touch /etc/os-release in VMs. Probably it will
break distribution detection for standard upstream tools.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

I don't think we should touch /etc/os-release in VMs. Probably it will
break distribution detection for standard upstream tools.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?