intrigeri:
> [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?
I think that's a good list. It's quite permissive and shouldn't pose big
problems.
Here are a few possible additions:
When using `keyringer open` temporary files are stored in
/run/shm/keyringer.amnesia. I don't know the Debian FHS enough to be
sure, but could there be other places where applications store files
that are meant to be open by other applications?
Would it make sense to add
/live/persistence/TailsData_unlocked/Persistent/. Users are not supposed
to interact with that but we're including ~/Persistent/ anyway and we
sometimes mention this path in our doc so people might end up there.
Would it make sense to add /mnt just like we add /media? It's officially
for "temporarily mounted filesystems". I'm not sure what power users
would put in there but I sometimes mount stuff manually in there from
old habits (not in Tails usually).
> 2. What kind of UX and user support impact do you believe/guess that
> such rules would have?
I don't know but probably quite low. At least we should try and see.
> 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.
Ok.
> 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.
Yeap.
--
sajolida
