Problem with AppImages #408
Comments
|
Hi @mariomadproductions , Thank you for reporting this behaviour. There's a way to filter connections from this appimage (I have no idea if it'd apply to all appimages):
I've tested it and it works, but I don't know if the random part of the path could contain more characters like _ or - (in such case you should just have to include them between the [ ]). |
|
Ah, reading an old issue I was under the impression that regex didn't work. Just tried that - works fine. It looks to me that it just uses letters and numbers for the randomised bit. |
|
I'll add this information to the wiki, thank you! |
|
I think this should be automatic, as it would be too confusing for most people. Correct me if I am wrong, but the example in the Wiki is not correct
"/tmp/.mount_Archiv" is only relevant for this example. So removing it makes it work with all apps.
Maybe a new "AppImage" dropdown option could be added, which automatically adds the executable this way. |
|
@nitschis |
I agree @nitschis . There's a feature request to add rules templates. We could add as you suggest a dropdown: AppImages, System Apps (ntpd, xbrlapi, dirmngr, /lib/systemd-*), etc |
+1 |
|
couldn't this be faked though? any application could make an executable under an appimage directory that they assume the host has, and now that new executable inherits the rules of the actual application |
|
Yes @Jabster28 . Given that the appimages are uncompressed to /tmp, anyone could brute force the temporary dirs that they create. One way of mitigating this problem would be by creating restrictive rules. For example, instead of allowing only the cmdline, allow cmdline + UID + dst port + dst ip/host. |
|
I think a simple solution to this problem would be to save the checksum of the executable. This would be a security addition in general, but I think it should be optional to only use it with appimages. |
|
I agree, we've long discussed about this feature here #413 |
If the path of the process starts with /tmp/.mount, it typically indicates that the application is an AppImage. These apps create a random directory under /tmp, with the pattern /tmp/.mount_<appId>XXXXXX, where the AppImage is mounted (it's not always the case, but it usually is). https://github.com/AppImage/AppImageKit/blob/a0373541c1005153199aaaaceb6c17803805e648/runtime.c#L202 The problem is that if you allow the path to the executable, the next time you launch the AppImage, the path won't match the rule, and you'll be prompted again to allow the outbound connection. So as a helper for the users, if we find the path of the process starts with /tmp/.mount_, we add an option to the combo box to select the path, which creates a regular expression to match the AppImage. Requested here: #1066, #543, #408
If the path of the process starts with /tmp/.mount, it typically indicates that the application is an AppImage. These apps create a random directory under /tmp, with the pattern /tmp/.mount_<appId>XXXXXX, where the AppImage is mounted (it's not always the case, but it usually is). https://github.com/AppImage/AppImageKit/blob/a0373541c1005153199aaaaceb6c17803805e648/runtime.c#L202 The problem is that if you allow the path to the executable, the next time you launch the AppImage, the path won't match the rule, and you'll be prompted again to allow the outbound connection. So as a helper for the users, if we find the path of the process starts with /tmp/.mount_, we add an option to the combo box to select the path, which creates a regular expression to match the AppImage. Requested here: #1066, #543, #408 (cherry picked from commit 56775cd)
Hi. When using this app with an AppImage (ArchiveWeb.page, I noticed that there doesn't seem to be a way to create an exception that works for different instances of the process - because app images seem to have a randomised process path (e.g.
/tmp/.mount_archivSJ24T4/archiveweb.page). Maybe there is some way to change the AppImage behaviour (but I don't know if that's a good idea), or maybe there is something that could be changed on OpenSnitch's side?OS (please complete the following information):
The text was updated successfully, but these errors were encountered: