3 ms·

Yeah. The Downloads directory inevitably accumulates sensitive data over time, especially lacking automatic cleanup/expiration of files. For this reason alone,

Yeah. The Downloads directory inevitably accumulates sensitive data over time, especially lacking automatic cleanup/expiration of files. For this reason alone, Firefox should follow the Chromium/Edge policy. Running Firefox via snapcraft, I've come to realize that desktop Linux systems keep moving the problem around without fully solving it (though I'm quite grateful for the real security benefits of snaps). Traditional users/permissions are ineffective because all your important data is readable by your ostensibly unprivileged user. Then SELinux/AppArmor enforcement comes along, but it's of limited effectiveness because you end up with free-for-alls (for convenience's sake) like ~/Downloads.

yakubin 7y ago
I think SELinux/AppArmor is a good idea for services like web/ftp/irc/ssh servers, wayland compositors, notification daemons (like dunst), external devices managment daemons (like udiskie) etc. But it isn't a good solution for applications which a user could try to use to read or change arbitrary things in the system for no malicious reasons. But, as I understand it, the Flatpak model of having the application sandboxed and then only allowing it to access files which are selected by the user in the GTK dialog is a great solution. It's just that I haven't seen one for command line applications. E.g. how should we protect ourselves from someone exploiting a vulnerability in vim to access our private documents, which we could potentially want to edit with vim ourselves? EDIT: it seems there is some progress on making a Firefox Flatpak: https://bugzilla.mozilla.org/show_bug.cgi?id=1441922 https://bugzilla.mozilla.org/show_bug.cgi?id=1441922
- dngray 7y ago
  > Yeah. The Downloads directory inevitably accumulates sensitive data over time, especially lacking automatic cleanup/expiration of files. For this reason alone, Firefox should follow the Chromium/Edge policy. > Then SELinux/AppArmor enforcement comes along, but it's of limited effectiveness because you end up with free-for-alls (for convenience's sake) like ~/Downloads. I keep this clean when I am finished with a file I usually have a term up and will move it to somewhere in ~/ or ~/Documents I think I might use AppAmor to secure this like TAILS does https://tails.boum.org/contribute/design/application_isolation/#index1h2 https://tails.boum.org/contribute/design/application_isolati... I found these profiles which will act as a good basis https://github.com/mk-fg/apparmor-profiles/blob/master/profiles/usr.bin.firefox https://github.com/mk-fg/apparmor-profiles/blob/master/profi... it seems that Mike Kazantsev (mk-fg) has abstracted it it a bit more into other files. The ones that come with apparmor look ancient https://gitlab.com/apparmor/apparmor/blob/master/profiles/apparmor/profiles/extras/usr.lib.firefox.firefox https://gitlab.com/apparmor/apparmor/blob/master/profiles/ap... > E.g. how should we protect ourselves from someone exploiting a vulnerability in vim to access our private documents, which we could potentially want to edit with vim ourselves? I think for me it would be about starting with high risk applications. If you look at https://github.com/mk-fg/apparmor-profiles/tree/master/profiles https://github.com/mk-fg/apparmor-profiles/tree/master/profi... you notice things like steam, skype, etc.

yakubin 7y ago

I think SELinux/AppArmor is a good idea for services like web/ftp/irc/ssh servers, wayland compositors, notification daemons (like dunst), external devices managment daemons (like udiskie) etc. But it isn't a good solution for applications which a user could try to use to read or change arbitrary things in the system for no malicious reasons. But, as I understand it, the Flatpak model of having the application sandboxed and then only allowing it to access files which are selected by the user in the GTK dialog is a great solution. It's just that I haven't seen one for command line applications. E.g. how should we protect ourselves from someone exploiting a vulnerability in vim to access our private documents, which we could potentially want to edit with vim ourselves? EDIT: it seems there is some progress on making a Firefox Flatpak: https://bugzilla.mozilla.org/show_bug.cgi?id=1441922 https://bugzilla.mozilla.org/show_bug.cgi?id=1441922

dngray 7y ago
> Yeah. The Downloads directory inevitably accumulates sensitive data over time, especially lacking automatic cleanup/expiration of files. For this reason alone, Firefox should follow the Chromium/Edge policy. > Then SELinux/AppArmor enforcement comes along, but it's of limited effectiveness because you end up with free-for-alls (for convenience's sake) like ~/Downloads. I keep this clean when I am finished with a file I usually have a term up and will move it to somewhere in ~/ or ~/Documents I think I might use AppAmor to secure this like TAILS does https://tails.boum.org/contribute/design/application_isolation/#index1h2 https://tails.boum.org/contribute/design/application_isolati... I found these profiles which will act as a good basis https://github.com/mk-fg/apparmor-profiles/blob/master/profiles/usr.bin.firefox https://github.com/mk-fg/apparmor-profiles/blob/master/profi... it seems that Mike Kazantsev (mk-fg) has abstracted it it a bit more into other files. The ones that come with apparmor look ancient https://gitlab.com/apparmor/apparmor/blob/master/profiles/apparmor/profiles/extras/usr.lib.firefox.firefox https://gitlab.com/apparmor/apparmor/blob/master/profiles/ap... > E.g. how should we protect ourselves from someone exploiting a vulnerability in vim to access our private documents, which we could potentially want to edit with vim ourselves? I think for me it would be about starting with high risk applications. If you look at https://github.com/mk-fg/apparmor-profiles/tree/master/profiles https://github.com/mk-fg/apparmor-profiles/tree/master/profi... you notice things like steam, skype, etc.