(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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1327791
Title:
Security warning about just created Xubuntu desktop shortcut
To manage notifications about this bug go to:
https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
