Trusted path negation qvm-file-trust

[Jean-Philippe Ouellet]

From the WIP qvm-file-trust man page [1]:

A file is considered trusted unless:

1. It sits under an untrusted folder's path
2. It has a 'user.qubes.untrusted' extended file attribute
3. It sits in a file path that has the phrase 'untrusted' in it.
This phrase can be configured in /etc/qubes/always-open-in-dispvm.phrase

A '-' character can be placed in front of a path in the local list
to override a path listed in the local list.

I think the 2nd "local" is meant to be "global", but regardless... I
interpreted this as meaning the following cfg:
~/papers/
-~/papers/ITL/
would result in ~/papers/ieee-foo.pdf being *un*trusted and
papers/ITL/qubes-bar.pdf being *trusted*.

In the current implementation this is not the case, but rather
`-~/foo` only negates `~/foo` iff exactly foo had been previously
specified.

This means
~/Documents/crap
-~/Documents
would render all ~/Documents untrusted, rather than the current
~/Documents/crap remaining trusted because the exact path had not been
negated.

This may well be what was intended all along, but it is not what I
understood was the goal from the initial design discussions.

I believe the original description of negation in trusted paths config was [2].

Thoughts?

[1]: https://github.com/anoadragon453/qubes-mime-types/blob/9a2bd289e9924e2d7902acac1693d33dab0cfae6/doc/qvm-file-trust.rst#L20-L30
[2]: https://groups.google.com/d/msg/qubes-devel/HNdUjs35-qA/e9Z0k6uABAAJ

[Andrew Morgan]

On 08/25/2017 02:42 PM, Jean-Philippe Ouellet wrote:
> From the WIP qvm-file-trust man page [1]:
>
> A file is considered trusted unless:
>
> 1. It sits under an untrusted folder's path
> 2. It has a 'user.qubes.untrusted' extended file attribute
> 3. It sits in a file path that has the phrase 'untrusted' in it.
> This phrase can be configured in /etc/qubes/always-open-in-dispvm.phrase
>
> A '-' character can be placed in front of a path in the local list
> to override a path listed in the local list.
>
> I think the 2nd "local" is meant to be "global"

Yep, typo. Thank you!

> I interpreted this as meaning the following cfg:
> ~/papers/
> -~/papers/ITL/
> would result in ~/papers/ieee-foo.pdf being *un*trusted and
> papers/ITL/qubes-bar.pdf being *trusted*.
>
> In the current implementation this is not the case, but rather
> `-~/foo` only negates `~/foo` iff exactly foo had been previously
> specified.

Yes, that's how it has been implemented (remove from list of untrusted
folders if there's a '-' in front). I agree that this may be confusing
to the user if they believe that putting an '-' in front automatically
makes a folder trusted, however the sole purpose (at least during
discussion) of the '-' feature is to negate existing rules in the global
list, so that you could have one template with very strict trust rules,
while you could pick and choose which ones to keep in the AppVM based
upon it.

A folder is only trusted if it is not mentioned or is not a child of a
mentioned path in one of the two lists. That being said, there is thus
no possible way to have a trusted folder inside of an untrusted folder.
I don't believe we support this use case and doing so may make things
even more confusing if we tell users that _some_ files will open locally
inside of untrusted folders and some will not.

> A '-' character can be placed in front of a path in the local list to
override a path listed in the local list.

I feel like this line explains the feature pretty well, but I agree that
adding something like:

'Note: This will NOT explicitly mark a folder as trusted.'

to the documentation may clear things up a bit.

>
> This means
> ~/Documents/crap
> -~/Documents
> would render all ~/Documents untrusted, rather than the current
> ~/Documents/crap remaining trusted because the exact path had not been
> negated.
>
> This may well be what was intended all along, but it is not what I
> understood was the goal from the initial design discussions.
>
> I believe the original description of negation in trusted paths config was [2].

> The '-' in the second file should override and negate the rule in the
first file.

Yeah, it's just for negating rules, not overlaying additional ones on
top of them :)

Andrew Morgan

[Andrew Morgan]

Hey Jean-Philippe,

I'm working on getting the test suite working again. At this point it's
just a few failing tests that need to be updated.

I'm having one issue after the change to a python package. I can't seem
to grab and test the stdout of qvm-file-trust.

Here's an example:
https://github.com/anoadragon453/qubes-mime-types/blob/master/qubesfiletrust/tests/trust.py#L302

Even if I change the script to not care about the OUTPUT_QUIET var, I'm
still unable to grab any printout, so it seems to be an issue with how
I'm grabbing it (note that code did work previously).

Thanks,
Andrew Morgan