Linux libsentry.so requires Execution Permissions on Stack

[Luminiferous348]

Hello,

little issue I noticed, after Updating to 1.3.0, TriOS doesn't start any more on my System (openSUSE Tumbleweed - Linux) with this error:

./TriOS: error while loading shared libraries: libsentry.so: cannot enable executable stack as shared object requires: Permission denied

Turns out, the Stack for libsentry.so requires exec Permissions for this latest release (as seen with readelf). I've marked the line in this screenshot:

As you can see, the Permission bits for the Stack are set to RWE.

After using execstack -c on the lib to clear the exec Permission, the Execute Bit is gone:

And TriOS launches without any Issues.

Background: Execution permissions on the Stack is a Security issue, which is why modern Linux distributions don't allow you to run Executables or Libraries with this bit set.

The same issue also applies to the crashpad_handler, but since this apparently isn't a required import, TriOS launches without it:

So it might probably be a good idea to ship Libraries without the exec Permission on the Stack. I checked all other Executables and Libraries for TriOS, and only libsentry and crashpad_handler have this issue.

[wispborne]

Thank you. I just confirmed the RWE bit on Ubuntu 24.04, but I was able to run TriOS 1.3.0 there without any issues. Perhaps Ubuntu is more forgiving and unwilling to jeopardize compatibility.

I've posed the question to the Sentry Discord and maybe someone there can clear it up (though it's relatively niche so we'll see...)

[Luminiferous348]

Okay, I digged a little more, and turns out, the component which actually prevents the Library from Running is SELinux. I can also confirm that at least on SUSE its setup to prevent stack execution. According to this: https://access.redhat.com/solutions/43215 RHELs SELinux is also setup like SUSEs. With that its probably also this way for any Distro based on RHEL or SUSE (so openSUSE, SLES, SLED for SUSE and for example Fedora, Rocky Linux, Ultramarine, etc. for RHEL).

I don't know how Debian or Arch based Systems, (like Ubuntu or SteamOS) have their SELinux setup. (I normally use SUSE based systems for everything, and RHEL based systems for things, where SUSE isn't supported.. looking at you, HCL Sametime; I kinda just assumed that this applies to all modern distros.. so yeah, sorry about that)

Assuming that Sentry doesn't need stack execution, they should probably remove that flag. If its needed, I (or you or someone else) can probably build a selinux policy, which would allow this library to use stack execution, so that you can put that in a script which comes with TriOS, or in a README or a Docu or whatever. Or I guess you can strip the bit manually before Releasing the Package, if you don't make use the functionality, which needs stack execution.

[wispborne]

Message link: https://discord.com/channels/621778831602221064/1460055916060606595
As text:

This looks very similar to what came up here getsentry/sentry-native#1442 (comment)
which was (in part) addressed here getsentry/crashpad@19d9d8a & which got pulled into sentry-native at release 0.12.2; If I can see correctly, sentry-flutter is still on sentry-native 0.10.0 ? Maybe time to bump and see if this resolves it

[wispborne]

This should be fixed when 1.3.3-preview01 is finished building.
https://github.com/wispborne/TriOS/releases