Hi,
sajolida wrote (05 Jun 2015 16:51:34 GMT) :
> intrigeri:
>> [...]
>> 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:
>> [...]
>> 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.
Cool.
> Here are a few possible additions:
> When using `keyringer open` temporary files are stored in
> /run/shm/keyringer.amnesia.
That's a directory name, right? If it is, then: is that the *exact*
directory name that's always used, or is a random-looking suffix added
to it? If so, then that's probably a security bug (as basically any
use of a fixed or guessable or bruteforceable filename in
a world-writable directory).
In principle, I'm all for allowing access to keyringer temporary
files, if it can be done in a sane way. And most AppArmor profiles
(including Evince's and Totem's) grant access to same-owner files in
other well-known temporary directories anyway.
My only concern is that any compromised app, even if it's confined
with AppArmor, will have access to *all* files open with `keyringer
open', even those that are meant to be opened with another app.
We could avoid this if keyringer used a per-helper-app temporary
directory, but it uses xdg-open IIRC so that won't work. Another way
would be to set up temporary access rules based on the filename passed
on the command-line (like firejail does), but it would require quite
some work, and I'd rather focus my efforts in this area to GUI apps
and won't bother too much about CLI ones.
> 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?
Yes, since it's (in most? all? cases) a tmpfs, I've seen some software
prefer using /{dev,run}/shm over /tmp. However, it's quite rare
(grep'ing for shm in my /etc/apparmor.d/ only shows a few FDs like
PulseAudio's one).
Anyway: as long as we allow access to same-owner files in /tmp and
/var/tmp, also allowing the same for /{dev,run}/shm is probably no
big deal.
> 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.
ACK, good idea.
> 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).
I don't know. In my (limited) experience, I've seen /media more often
used for removable media (that one expects to be readable by non-root
users anyway), while /mnt is more often used for stuff that's on
internal drives (for which one may have different expectations).
Perhaps we can rely on DAC (the basic filesystem permissions as you
know them) to enforce this difference when it's needed. I'll need to
think about it a bit harder.
>> 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.
:)
Thanks for the feedback!
Cheers,
--
intrigeri
