Comment 14 for bug 1327791

(In reply to Yves-Alexis Perez from comment #12)
> (In reply to Steve Dodier-Lazaro from comment #11)
> > The distinction between exec/non-exec bits is pretty irrelevant until
> > sandboxing is fully deployed, to be honest. We cannot both provide security
> > *and* a good UX for locally installed apps and .desktop files on the Desktop
> > for now, so I'm tempted to go with good UX and revisit the decision later.
>
> I disagree about “pretty irrelevant”. In a secure world you'd have complete
> W^X and thus would refuse to execute anything where the user has write
> access. But even doing that road, it looks logical (at least to me) to
> refuse to execute user stuff with no explicit execute permission.

Essentially we have two threats: malicious downloads and malicious apps. If apps are malicious then anything $HOME is unsafe, and the exec bit is totally meaningless. If only considering malicious downloads, I could create a malicious archive with files that already contain the exec-bit set, so at the end of the day we're only protecting against standalone files on systems with a default umask. The distinction isn't particularly impressive. With proper (i.e., research grade for now and years to come) sandboxing on, you could tell from which app a file was downloaded, from which domain it came and whether you have a record of security issues with its advertised publisher. We're far from there yet. :-)

What I mean is that the difference *really does not set a security boundary*. It's purely heuristics-based, to match the most common scenario. On the day someone actively tries to distribute Linux malware, this reasoning will blow apart and we'll have to serve systematic warnings.

> >
> > Some pseudo-code:
> > 1a. Make a safe-list of directories with all of PATH,
> > /usr/local/share/applications, /usr/share/applications,
> > ~/.local/share/applications/, ~/Desktop
>
> I don't think anything under $HOME should be really safe (even in $PATH).

I agree with you, again it's a heuristics-based judgement which should be revisited as soon as evidence suggests our users are threatened and a warning could help. Hopefully basic sandboxing will be deployed by then so ~/.local/{bin,share} will not be writable by user apps.

>
> > 1b. Remove XDG_DOWNLOADS_DIR from the safe-list (to keep users who download
> > to Desktop a bit safer)
>
> It seems that browsers now also set some extended attributes on downloaded
> files, so it might be interesting to support that (but I don't have any
> pointer here).

Hmm, that's a good idea. Though, I'm not sure how many P2P apps/IM apps/browsers/direct downloads cohabit on the Linux ecosystem. Detecting file downloads at scale might be painful or unreliable.

In summary, for decision makers:
If Xfce wants to commit to security now in prevision for later, it should not include any $HOME paths into the safe-list, it should replace the "ValidateExecute" path with the "Warning" path and set "script-launch-behaviour" to ask/warn by default. My recommendation would be to be a bit nicer but to be ready to release stricter defaults in the future as facilities become available or risks become tangible. Of course we should support as much OEM customisation as we reasonably can.