Hi,
[Cc'ing -dev@ and -support-private@ *once*, so that they know about
this discussion. Please drop them from the list of recipients on
replies: I'm mainly interested in the UX point-of-view for now. Also,
no need to Cc me, I do read -ux@ nowadays.]
The AppArmor policy we currently apply to Evince and Totem allows them
to read and write any file anywhere in /home/amnesia, regardless of
the extension; except that a blacklist protects a set of important
private files, such as GnuPG keyrings.
The advantage of this approach are:
* it's what the AppArmor profiles we get from $upstream do by
default, so it comes for free and is better than nothing;
* users didn't even notice that AppArmor is protecting (a little bit)
these applications, which is truly awesome (especially compared to
how Tor Browser's confinement is experienced apparently..)
However, this approach also has one major drawback: the blacklist is
already incomplete, e.g. it currently doesn't contain OTR keys; worse,
even if we bothered adding to the list of forbidden files now, we're
doomed to always forget something important => truth be told, that
list will *always* be incomplete.
So, I'd like to tighten this policy a little bit, by adding
a whitelist approach on top of that. How about letting Evince and
Totem read and write any file if, and only if, *all* the following
conditions are met:
- the file has a supported extension;
- the file lives in one of:
* at the root of ~/
* anywhere below the Desktop directory
* anywhere below ~/Persistent/
* anywhere below ~/Tor Browser/
* at the root of /tmp/
* at the root of /var/tmp/
* anywhere below /media/ (removable storage, and internal storage
manually mounted by the user)
* anywhere below /usr/
- unless the file lives in /media/ or /usr/, it must be owned by
the users who runs the application.
Thoughts? In particular:
1. Is there any other commonly used storage directory that should
be allowed?
2. What kind of UX and user support impact do you believe/guess that
such rules would have?
Note that I will block this tightening on #9337 ("notify the user when
AppArmor blocks something", tentatively scheduled for 1.5), in order
to avoid triggering too much of a UX and user support mess.
Final words: once we have found a set of rules that work for these two
applications, I bet we can cheaply generalize it for other ones.
Cheers,
--
intrigeri
