It's 3.30.2 release day, upload a tarball and fix that hidden pesky bug that you missed in .1 🦛

Commit 3a22ed5b authored by Carlos Soriano's avatar Carlos Soriano Committed by Carlos Soriano

general: Don't allow launching binaries or programs in general

For long we used to support that since the desktop was part of Nautilus.
Also, back then we didn't have a Software app where you are expected to
installs apps. Back then it was common for apps to be delivered in
a tarball, nowadays that's out of question.

Now that the desktop is long gone, launching binaries and desktop files
from within Nautilus is not as useful. Not only that, but we are moving
towards a more sandboxed system, and we should use the standard and
system wide support for launching apps based on users choices.

We also are not able to be secure enough to handle this, as we saw in
the past we allowed untrusted binaries to be launched, and therefore
we had a CVE (CVE-2017-14604) for Nautilus. We are not being audited
(afaik) and we are not in a position that we can let this issues slip.

With that altogether, this prevents launching binaries or programs from
Nautilus.

Closes: #184
parent 83483358
......@@ -11,12 +11,6 @@
<value value="1" nick="double"/>
</enum>
<enum id="org.gnome.nautilus.ActivationChoice">
<value value="0" nick="launch"/>
<value value="1" nick="display"/>
<value value="2" nick="ask"/>
</enum>
<enum id="org.gnome.nautilus.FolderView">
<value value="0" nick="icon-view"/>
<value value="1" nick="list-view"/>
......@@ -121,11 +115,6 @@
<summary>Type of click used to launch/open files</summary>
<description>Possible values are “single” to launch files on a single click, or “double” to launch them on a double click.</description>
</key>
<key name="executable-text-activation" enum="org.gnome.nautilus.ActivationChoice">
<default>'display'</default>
<summary>What to do with executable text files when activated</summary>
<description>What to do with executable text files when they are activated (single or double clicked). Possible values are “launch” to launch them as programs, “ask” to ask what to do via a dialog, and “display” to display them as text files.</description>
</key>
<key type="b" name="install-mime-activation">
<default>true</default>
<summary>Show the package installer for unknown MIME types</summary>
......
......@@ -3541,39 +3541,6 @@ file_info_start (NautilusDirectory *directory,
g_object_unref (location);
}
static gboolean
is_link_trusted (NautilusFile *file,
gboolean is_launcher)
{
GFile *location;
gboolean res;
g_autofree gchar *trusted = NULL;
if (!is_launcher)
{
return TRUE;
}
trusted = nautilus_file_get_metadata (file,
NAUTILUS_METADATA_KEY_DESKTOP_FILE_TRUSTED,
NULL);
if (nautilus_file_can_execute (file) && trusted != NULL)
{
return TRUE;
}
res = FALSE;
if (nautilus_file_is_local (file))
{
location = nautilus_file_get_location (file);
res = nautilus_is_in_system_dir (location);
g_object_unref (location);
}
return res;
}
static void
link_info_done (NautilusDirectory *directory,
NautilusFile *file,
......@@ -3582,20 +3549,9 @@ link_info_done (NautilusDirectory *directory,
GIcon *icon,
gboolean is_launcher)
{
gboolean is_trusted;
file->details->link_info_is_up_to_date = TRUE;
is_trusted = is_link_trusted (file, is_launcher);
if (is_trusted)
{
nautilus_file_set_display_name (file, name, name, TRUE);
}
else
{
nautilus_file_set_display_name (file, NULL, NULL, TRUE);
}
file->details->got_link_info = TRUE;
g_clear_object (&file->details->custom_icon);
......@@ -3607,12 +3563,11 @@ link_info_done (NautilusDirectory *directory,
file->details->got_custom_activation_uri = TRUE;
file->details->activation_uri = g_strdup (uri);
}
if (is_trusted && (icon != NULL))
if (icon != NULL)
{
file->details->custom_icon = g_object_ref (icon);
}
file->details->is_launcher = is_launcher;
file->details->is_trusted_link = is_trusted;
nautilus_directory_async_state_changed (directory);
}
......
......@@ -1198,7 +1198,6 @@ nautilus_files_view_activate_files (NautilusFilesView *view,
NautilusFilesViewPrivate *priv;
GList *files_to_extract;
GList *files_to_activate;
char *path;
if (files == NULL)
{
......@@ -1230,15 +1229,12 @@ nautilus_files_view_activate_files (NautilusFilesView *view,
extract_files_to_chosen_location (view, files_to_extract);
}
path = get_view_directory (view);
nautilus_mime_activate_files (nautilus_files_view_get_containing_window (view),
priv->slot,
files_to_activate,
path,
flags,
confirm_multiple);
g_free (path);
g_list_free (files_to_extract);
g_list_free (files_to_activate);
}
......@@ -7675,7 +7671,6 @@ update_selection_menu (NautilusFilesView *view)
GList *l;
gint selection_count;
gboolean show_app;
gboolean show_run;
gboolean show_extract;
gboolean item_opens_in_view;
gchar *item_label;
......@@ -7716,7 +7711,7 @@ update_selection_menu (NautilusFilesView *view)
g_free (item_label);
/* Open With <App> menu item */
show_extract = show_app = show_run = item_opens_in_view = selection_count != 0;
show_extract = show_app = item_opens_in_view = selection_count != 0;
for (l = selection; l != NULL; l = l->next)
{
NautilusFile *file;
......@@ -7733,17 +7728,12 @@ update_selection_menu (NautilusFilesView *view)
show_app = FALSE;
}
if (!nautilus_mime_file_launches (file))
{
show_run = FALSE;
}
if (!nautilus_file_opens_in_view (file))
{
item_opens_in_view = FALSE;
}
if (!show_extract && !show_app && !show_run && !item_opens_in_view)
if (!show_extract && !show_app && !item_opens_in_view)
{
break;
}
......@@ -7772,10 +7762,6 @@ update_selection_menu (NautilusFilesView *view)
g_free (escaped_app);
g_object_unref (app);
}
else if (show_run)
{
item_label = g_strdup (_("Run"));
}
else if (show_extract)
{
item_label = nautilus_files_view_supports_extract_here (view) ?
......@@ -8736,20 +8722,10 @@ nautilus_files_view_move_copy_items (NautilusFilesView *view,
NautilusFile *target_file;
target_file = nautilus_file_get_existing_by_uri (target_uri);
/* special-case "command:" here instead of starting a move/copy */
if (target_file != NULL && nautilus_file_is_launcher (target_file))
{
nautilus_file_unref (target_file);
nautilus_launch_desktop_file (
gtk_widget_get_screen (GTK_WIDGET (view)),
target_uri, item_uris,
nautilus_files_view_get_containing_window (view));
return;
}
else if (copy_action == GDK_ACTION_COPY &&
nautilus_is_file_roller_installed () &&
target_file != NULL &&
nautilus_file_is_archive (target_file))
if (copy_action == GDK_ACTION_COPY &&
nautilus_is_file_roller_installed () &&
target_file != NULL &&
nautilus_file_is_archive (target_file))
{
char *command, *quoted_uri, *tmp;
const GList *l;
......
This diff is collapsed.
......@@ -40,16 +40,14 @@ gboolean nautilus_mime_file_extracts (Nauti
gboolean nautilus_mime_file_opens_in_external_app (NautilusFile *file);
gboolean nautilus_mime_file_launches (NautilusFile *file);
void nautilus_mime_activate_files (GtkWindow *parent_window,
NautilusWindowSlot *slot,
GList *files,
const char *launch_directory,
NautilusWindowOpenFlags flags,
gboolean user_confirmation);
NautilusWindowSlot *slot,
GList *files,
NautilusWindowOpenFlags flags,
gboolean user_confirmation);
void nautilus_mime_activate_file (GtkWindow *parent_window,
NautilusWindowSlot *slot_info,
NautilusFile *file,
const char *launch_directory,
NautilusWindowOpenFlags flags);
NautilusWindowSlot *slot_info,
NautilusFile *file,
NautilusWindowOpenFlags flags);
gint nautilus_mime_types_get_number_of_groups (void);
const gchar* nautilus_mime_types_group_get_name (gint group_index);
GList* nautilus_mime_types_group_get_mimetypes (gint group_index);
\ No newline at end of file
GList* nautilus_mime_types_group_get_mimetypes (gint group_index);
......@@ -91,16 +91,13 @@ open_location_cb (NautilusPlacesView *view,
{
NautilusFile *file;
GtkWidget *window;
char *path;
path = "other-locations:///";
file = nautilus_file_get (location);
window = gtk_widget_get_toplevel (GTK_WIDGET (view));
nautilus_mime_activate_file (GTK_WINDOW (window),
NAUTILUS_WINDOW_SLOT (slot),
file,
path,
flags);
nautilus_file_unref (file);
}
......
  • mentioned in merge request !218 (merged)

    Toggle commit list
  • A very strange decision. Suppose I just compiled my "Hello world". Now I can not run it from Nautilus? Why? Anyway if the ultimate goal is isolate all programs from each other, why not automatically run each binary in an isolated environment?

    Edited by Mikhail Gavrilov
  • That kind of artificial scenario doesn’t help prove anything. Perhaps https://bugzilla.gnome.org/show_bug.cgi?id=737849 will shed more light.

  • Flatpak provides the ability to run applications in an isolated environment and Nautilus is not an application launcher.

  • Ok, we will come to that everyone will run applications through the terminal. And nothing will change in terms of improving isolation.

  • Applications are usually ran through the app picker, dash or search for regular usage. For development, you most probably are using an IDE or the terminal.

    In terms of isolation, indeed there are sandboxing technologies available for all, those are managed properly by Nautilus (via mime types) and they integrate with the Software center and the Shell.

  • I just wanted to remind you that the user will still find different ways to bypass this restriction. Those to achieve the final goal, you must disable the launch of applications at the kernel level by bypassing .desktop files.

    Edited by Mikhail Gavrilov
  • Not sure, I think isolated enviroments like Flatpak would make that secure enough, in terms of trade-offs. The point is to not go to one extreme or the other, but find a good enough middle ground.

  • Now I want talking about myself. I do not know how I got this habit, but past five years I've running all applications through GNOME Terminal. This is explained by the fact that I want to see any debug/error messages in console if any errors occur.

    So I've will continue launching applications incorrectly if you are not restrict launching applications by this way. And I am sure that many Linux users do the same as I do.

  • Flatpak applications can be ran through terminal with no problem. That is kinda tangential actually!

  • I get that Nautilus hiding file extensions on executable .desktop files (CVE-2017-14604) is a bad thing. No argument there (and without Desktop icons ability to execute .desktop files is kind of moot anyway). I also get that the "Launch" option on the executable text files preference has to go. But why remove to option to have the "Ask" option for executable text files for which Nautilus doesn't hide the file extension?

    So for games purchased at GOG.com, which come with a script GUI installer, users will now have to learn how to use the terminal to launch the GUI installer?

    For simple scripts users may write, using say zenity for GUI, to automate some tasks on their computer they can no longer launch these from Nautilus? The terminal has to be used to launch simple automation scripts that likely were written in the first place to not have to use the terminal?

    I don't follow the reasoning on this at all.

    What's the difference between launching a script from Nautilus, having it ask what to do, and from Terminal? Is Terminal somehow more secure? No. So why inconvenience users and let them have the "Ask" option.

  • The question is when will all applications be packed in a flatpack? I'm sitting on Fedora and as far as I know there are no such plans.

  • I get that Nautilus hiding file extensions on executable .desktop files (CVE-2017-14604) is a bad thing

    Note that both Canonical and RH security team needed more than just "showing the file extension", specifically they expected a two step way to launch something. That means, mark as executable, then ask, which is what we were doing after the CVE fix.

    Note that this is just one of the factors, not the whole thing.

    So for games purchased at GOG.com, which come with a script GUI installer, users will now have to learn how to use the terminal to launch the GUI installer?

    You needed to turn on the executable bit anyway, which is unlikely you even know what is it if you don't know what a terminal is. In any case, I contacted GOG.

    @mikhail.v.gavrilov

    The question is when will all applications be packed in a flatpack? I'm sitting on Fedora and as far as I know there are no such plans.

    It's actually in the plans for some time already: https://fedoraproject.org/wiki/Workstation/Flatpaks

  • That means, mark as executable, then ask, which is what we were doing after the CVE fix.

    Sorry if I'm misunderstanding. Am I correctly understanding it as:

    • the "then ask" part is what you've removed with this change
    • meaning simple user scripts written to automate basic tasks can no longer be launched from Nautilus
  • the "then ask" part is what you've removed with this change

    What is removed is all the work I did in the past for the CVE, that includes the "then ask" part and the actual ability to launch.

    meaning simple user scripts written to automate basic tasks can no longer be launched from Nautilus

    You mean bash scripts? Then yes, they are still like binaries.

  • Yes, I read this article, but there's no objective to replace all rpm packages with flatpack. So I don't think that flatpack would be widely adopted in Linux community in near time.

  • @mikhail.v.gavrilov it's the plan together with other initiatives. But this is quite irrelevant here though, and it only affects Fedora.

  • You mean bash scripts? Then yes, they are still like binaries.

    Thinking some more on it, any kind of script. Bash, Python, Ruby, Perl.

    I really don't get it. To be able to launch scripts for simple automation of repetitive tasks, users now have to -- what -- package them as a Flatpak?

    The alternative is to launch them from Terminal but what is the argument here? That Terminal is more secure than Nautilus with "Ask" option?

  • Thinking some more on it, any kind of script. Bash, Python, Ruby, Perl.

    Wait, except the bash ones, those were not possible to be launched before either. Did you check this...?

    That Terminal is more secure than Nautilus with "Ask" option?

    Read the other comments, commit message and previous discussions. I think it's pretty clear this is just one factor, not the whole thing...

    Edited by Carlos Soriano
  • To be able to launch scripts for simple automation of repetitive tasks, users now have to -- what -- package them as a Flatpak?

    Can you provide what scripts were you using that you launched like this?

  • Can you provide what scripts were you using that you launched like this?

    Sure. To be clear, I set execute permission on such script files through Nautilus' context menu > Properties > Permissions. Launching scripts from Nautilus then presents me with the "Run in Terminal | Display | Cancel | Run" dialog. Using Nautilus 3.28.1.

    I have a collection of Bash and Python scripts for automating repetitive tasks related to publishing documents, photos and more to websites. Few examples:

    • tying together pandoc commands to transform source document into HTML, PDF and/or ePub format and a few simple pre- and post-processing steps using other tools
    • automatic resizing of new photos, setting metadata on the files and creating or updating HTML gallery
    • several scripts related to archiving and creating signatures for archives
    • scripts to do full backups to external media of authored content

    Scripts using standard Linux commands are mostly written in Bash using zenity to present me with a simple checkbox window to tick options for what actions I want it take this run. Like optionally uploading the processed files to the website. Simple scripts tying together commands with a little bit of logic and giving me options and feedback through simple GUI with zenity. Some scripts I'm doing in Python these days if processing of files is a more complex action.

    Such scripts are useful only to me, for automating tasks in my workflow. I use Nautilus to navigate the files on which I'm working and to launch these scripts to processes the files I've worked on. It would be very welcome to continue to have the option to launch scripts from Nautilus for automating such tasks.

  • Sounds like what you want to use is the "scripts" feature of Nautilus, where you put some scripts in the scripts folder and you can run them on the context menu in any place. That is still available.

  • A python script with the execute bit set and #!/usr/bin/env python or similar at the top is executable and can be run by double-click from Nautilus prior to this change. Same for perl, ruby, etc. Bash is just the default if a script lacks the #! comment at the top saying what interpreter to use.

    Many executables in linux are implemented this way:

    $ grep '#! /usr/bin/python' /usr/bin/* | wc -l
    59
    
    $ grep '#!/usr/bin/perl' /usr/bin/* | wc -l
    236
  • Sounds like what you want to use is the "scripts" feature of Nautilus

    That would work for for generic scripts, sure. I'm working on projects for clients for several weeks or months. Different things need to be done for different clients and projects. The automation differs from one project to the next. With the way Nautilus currently works I can easily write or tailor scripts for the needs of one project and keep them with that project. Next project likely needs different automation.

    I'm not writing gems worth sharing here, I'm just getting things done by automating specific tasks to each individual project.

  • @jakedane thanks for the use case explanation. That is really informative!

    I am considering making a proposal for gnome-terminal to register as handling the MIME type of scripts like yours. This would mean that you would be able to Open With Terminal from nautilus context menu, just like you can open with a text editor. Would you find this convenient?

    Edited by António Fernandes
  • @antoniof thanks for replying. That would be a welcome option, if less convenient than just double-clicking the script file and having Nautilus ask me wether to run it in terminal (if say the script has relevant terminal output), just run it (if the script has a GUI or output on terminal is otherwise not relevant) or display it (for editing it).

    My scripts have a GUI. Be that with zenity dialogs or (very simple) PyGTK. Just presenting me with checkboxes list of options for this run and feedback on progress and such.

    I can't be the only one doing content creation that puts together unique scripts for each project to automate specific repetitive tasks on that project. This is one of the reason's I'm on Linux, because it's so easy to do automation by tying together CLI programs and standard Linux commands in a script file and even add GUI dialogs and user input with something like zenity.

    If the "Ask" dialog is removed from Nautilus, could I write my own standalone "Ask" dialog, register that for handling the MIME types of scripts, and set it as the default action for files of this MIME type in Nautilus? So that double-clicking such a file would open it with my handler, showing the old dialog?

  • @jakedane Not needed, but would you share some of those GUI applications that you use for automated tasks? If you are not comfortable sharing it publicly, could you send it to csoriano@gnome.org? (I promise I don't judge code :) )

    It would be good to get deeper and understand the flow usage of those.

    Edited by Carlos Soriano
  • What happens with things like AppImages?

    as we saw in the past we allowed untrusted binaries to be launched,

    How that actually solves security at all? "Untrusted" binaries can be also something you have on appLauncher or start via terminal?

    I'm trying to understand what is the benefit to the users. Personally, the only files I launch directly via Files is AppImages, that I should make desktop files for them anyway. So I'm not really affected from the commit, I just cant see the point either

  • How that actually solves security at all? "Untrusted" binaries can be also something you have on appLauncher or start via terminal?

    You might want to ask security experts, a simple double click is too dangerous seems. Different security teams requested different layering.

    I'm trying to understand what is the benefit to the users

    Less attack vectors for a non audited app, sandboxing friendly, portal integration, it fits with other proposals... Maybe you don't see that as "user benefit", indirectly in the grand scheme of things it is though. All it's explained in the commit message and relevant issues in GitLab and Bugzilla. Please read that, I think we are a little bit tired of saying the same over and over again.

  • @csoriano

    Please read that, I think we are a little bit tired of saying the same over and over again.

    I just made a question because I didnt understand the commit message. I didn't ask you personally, but anyone to this list that isn't tired to answer. Sorry!

  • @alex285 Well, most likely the ones that can answer are the Nautilus devs here :)

    In any case no worries, it was an honest "tired", not an annoyed one.

  • @csoriano I totally interpreted your answer wrong! Sorry!

  • @jakedane

    If the "Ask" dialog is removed from Nautilus, could I write my own standalone "Ask" dialog, register that for handling the MIME types of scripts, and set it as the default action for files of this MIME type in Nautilus? So that double-clicking such a file would open it with my handler, showing the old dialog?

    Yes, you can install a .desktop file for that and you will be able to mark it as default app for those type of files so that double click works as before. This works in your use case because you are able to write your own scripts, but it is not as convenient.

  • @csoriano don't be rude with @alex285 he is a big fan of nautilus (nice youtube channel) :)

    every time I see a feature removed think devs are trolling me, but i understand that security is the first reason.

  • It was not my intention. Apologies if that seemed like it.

  • Hi all,

    I understand this is for security and dealing with a CVE, and security teams felt this is the best way.

    I respectfully disagree.

    Basically, I think this too difficult for novice users to understand how to work around. Downloading things, finding them in file browser, unzipping archives, and double clicking the executable are the basic steps everyone learns in order to download and use software. That's pretty much exclusively how things are done on Windows; Windows is where most new Linux users come from. (macOS sort of lets you do the same thing, even though they locked things down a bit for "untrusted apps" in a way that I find also unfriendly to end users. But back to Windows which is a lot more users than macOS, statistically...)

    Crucially, these things are doable almost entirely with the mouse. It's all visual and intuitive.

    Setting up launchers, or using the terminal may as well be learning how to compile and package their own .deb (too alien and too technical, and too intimidating.)

    Most people learn these steps (download, unzip, double click) as the basic minimum computer literacy in order to run apps. Learning about repos and software configuration apps is a skill most Windows users don't have. And many people are sure they can't figure out the terminal even before they try it.

    being able to download executables and run them from the file manager lets newcomers use Linux like they use Windows. These users need an easy way to do things safer, or they won't do it, IMO. They'll just get frustrated. Some will ust give up and use only preinstalled apps, others will assume "Linux is too hard," and give up on Linux. Remember, a lot of Linux newcomers rely on Ubuntu for being a safe and easy first step into Linux, so this potentially affects some of the most beginner Linux users out there.

    Okay, essay over. Sorry for the long post.

    In short, I think something that can be done quickly, intuitively and easily with the mouse is a must, or new Linux users will be frustrated or give up. Please consider the newbies on this. Thank you.

    Edited by DeeDeeG
  • Downloading things, finding them in file browser, unzipping archives, and double clicking the executable are the basic steps everyone learns in order to download and use software

    Just to clarify, this was not possible before this change, not sure we are get something clear from here. Downloaded binaries doens't have the executable bit set, so you needed to know what is that, how to set it, set it, then run.

  • @csoriano Okay, yeah I had seen that earlier in the thread but forgot to address that.

    Even changing the executable permission can be done with the mouse. Right click, properties, allow running as executable.

    I have had to do essentially the same thing on Windows, and also (similar to this), people from Windows are used to right clicking and "Running as administrator."

    So I think setting executable permissions in and of itself is achievable for beginners and not a hard barrier to launching apps.

    As long as launching app is only a few clicks and doable with the mouse, and not too hard to find out what to do, I am fine with the changes in this commit. But I believe this kind of change should be accompanied by some intuitive way to run apps with the mouse, from Nautilus. Whether it be native to Nautilus, an extention installed by default, etc. As long as a newbie can figure it out, there's no problem.

    Edited by DeeDeeG
  • Windows are used to right clicking and "Running as administrator."

    :(

  • The behavior of new users with low computer literacy may be embarrassing or disheartening, but these are real users, and most people I meet have lower computer skills, rather than higher. Looking down on these people, or ignoring them, either is a mistake.

    There's a lot of these folks, so I'm just here to advocate for their needs. If I can get more than a facepalm and a frowney-face in reply, I think we'd get further on this. (edit: sorry for being a bit salty on this :/ I don't mean it personally against anyone here, I just care about this issue and hope this can be done in a way that is easier for users to understand.)

    There must be a way to adequately warn users when there's a fishy executable, but still letting them run it "if they must," using just the mouse. You can put up roadblocks like macOS if you need to.

    Or you could just require .desktop files to have the ".desktop" extension (and maybe trigger a warning for ".pdf.desktop", ".jpg.desktop" etc. so newbies don't get confused by a dual extension).

    There are lots of ways to protect users without reducing usability.

    Edited by DeeDeeG
  • mentioned in issue #437 (closed)

    Toggle commit list
  • I have to agree with @DeeDeeG on this one. This is security through obscurity, which is not effective long term.

    @csoriano: You needed to turn on the executable bit anyway, which is unlikely you even know what is it if you don't know what a terminal is.

    It is indeed possible to know about the executable bit without knowing about the terminal. Documentation could be made wherein users will be told to:

    1. Right click an executable
    2. Look for something labeled Properties or Permissions and click it
    3. Look for an unchecked checkbox with the word Execute or Executable beside it
    4. Check the box and press the Ok button
    5. Double-click to launch executable.

    That, in my honest opinion, seems to be a good balance between security and usability. If there are any doubts on whether an inexperienced user will have difficulty following these steps, maybe a survey should be made regarding this matter or get more community feedback before pressing on with this change.

    P.S. Could somebody please follow up with what happened to this commit linked by @ivorget above? It seems to be a better solution that doesn't obfuscate user interaction as drastically whilst providing a sufficient layer of security. Nevermind that; I found the answers on this issue.

    Edited by julius Enriquez
  • For people coming to this thread after 15 May (2018): I would say this conversation is mostly happening at that issue now, the one @win8linux just mentioned: #437 (closed)

  • @csoriano

    In any case, I contacted GOG.

    What did you tell them? What are they supposed to do now?

    What do you tell AppImage? What are we supposed to do now?

  • Downloaded binaries doens't have the executable bit set, so you needed to know what is that, how to set it, set it, then run.

    Exactly. Which is exactly how, as a user, you say that you "trust" an application.

    Which is why the whole "security" point is bogus.

    Edited by probonopd
  • Admittedly, extracting tarballs preserves the execution bit as set by the person who made the tarball, so the execute bit is not an indication that the user has explicitly trusted the file, so I don't find that argument convincing and I don't mind an additional popup confirming you want to run the file, possibly with an option to trust that file specifically from now on (and just remembered by Nautilus as long as the file exists rather than living in file permissions). There has also been talk by FileRoller devs that users could be presented with a warning upon extracting tarballs containing executables that have their execute bit set. This is a pretty good option IMHO. Also, if the .desktop functionality is removed, then executables will not as easily be able visibly impersonate other file types, reducing the chance of someone being tricked into running one.

    Edited by Chris Billington
  • @probonopd @win8linux unfortunately, the execute bit may be alredy set without user consent in at least two cases:

    1. Binaries extracted from a tarball (see explanation by Chris Billington above).
    2. Binaries on a FAT filesystem (which is common for USB sticks), as every file in that file system is treated as executable.

    So, unfortunately, the exeute bit doesn't serve as a security toggle. An additional measure is necessary.

    Edited by António Fernandes
  • How about a dialog every first run of an executable, @antoniof?

    Maybe something like this: image

    Edited by julius Enriquez
  • Well, I tried. 🤷

    I had planned to make a very rough sketch quickly of what such a proposed dialog could look like in text form. Alas, the formatting was butchered on first upload; because of that, I just took a screenshot of it in the editor and put it up. Hopefully, someone more talented can submit an improved version.

  • @win8linux Thanks for the suggestion. The "Are you sure? Yes/No" kind of dialogs has been shown not to be effective, as people quickly get used to always click Yes. It is more successful at annoying people (yet another window, yet another click!) than at preventing mistakes.

    There is possibly a role for an explanation dialog like this, but maybe with instructions instead of buttons. Such instructions should be something very simple. My point is not making things harder, but requiring awareness. But I'm not a security expert.

    Edited by António Fernandes
  • Can we make it something that could be a setting as a switch or checkbox, then put the instructions in the dialog, @antoniof? The dialog itself could just have only one Ok button.

  • @antoniof What about a dconf key? So package maintainers or administrators can decide if they want this feature enabled or disabled.

  • @antoniof thanks for your constructive moderation.

    Binaries extracted from a tarball (see explanation by Chris Billington above).

    Chris Billington offers a possible solution by having the archive extraction tool handle this.

    Binaries on a FAT filesystem (which is common for USB sticks), as every file in that file system is treated as executable.

    Most systems mount these with the noexec option. I think udisks2 does this.

    Edited by probonopd
  • mentioned in commit ce73de0c

    Toggle commit list
  • mentioned in merge request !229 (merged)

    Toggle commit list
  • mentioned in commit 70166550

    Toggle commit list
  • mentioned in commit ac886102

    Toggle commit list
  • What if instead of running the program from Files, double clicking opened a prompt to create a .desktop file for you?

  • @suckybell, that's not a bad idea and, in fact, we'd love to be able to do exactly that for AppImages. However, there is still the case where you email a script to your computer-illiterate friend and they need to be able to just run it, without any kind of "installation".

Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment