Possible SE-Linux issue related to execheap (?)

[fwelland]

Describe the bug Last 2 release of t4l. 1.7.3 and 1.7.4 -- but certainly 1.7.4 generates a SE-Linux alert on startup, and then t4l shuts down. If persistent, I can muscle through a few times and t4l will just start working, while ignoreing the SE-Linux alerts.

No I have not applied remedies suggested by SE-Linux alert browser; I wanted to keep the condition and submit an issue or question to see if this is a problem or not.

To Reproduce Steps to reproduce the behavior:

1. Start t4l
2. observe SE-Alerts

Expected behavior NO SEAlerts and t4l starts the first time.

Desktop (please complete the following information):

• OS: fedora 40 (6.9.5-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC)
• DNF/RPM based installed.
• current version: teams-for-linux-1.7.4-1.x86_64 (but the previous version, seemed to do it also; version before that, didn't seem to this.)

Additional context Here is details from SE-Linux/SETroubleshooting tool:

SELinux is preventing teams-for-linux from using the execheap access on a process.

***** Plugin allow_execheap (53.1 confidence) suggests ********************

If you do not think teams-for-linux should need to map heap memory that is both writable and executable. Then you need to report a bug. This is a potentially dangerous access. Do contact your security administrator and report this issue.

***** Plugin catchall_boolean (42.6 confidence) suggests ******************

If you want to allow selinuxuser to execheap Then you must tell SELinux about this by enabling the 'selinuxuser_execheap' boolean.

Do setsebool -P selinuxuser_execheap 1

***** Plugin catchall (5.76 confidence) suggests **************************

If you believe that teams-for-linux should be allowed execheap access on processes labeled unconfined_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing:

ausearch -c 'teams-for-linux' --raw | audit2allow -M my-teamsforlinux

semodule -X 300 -i my-teamsforlinux.pp

Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Target Context unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Target Objects Unknown [ process ] Source teams-for-linux Source Path teams-for-linux Port <Unknown> Host wellandf3 Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-40.23-1.fc40.noarch Local Policy RPM selinux-policy-targeted-40.23-1.fc40.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name wellandf3 Platform Linux wellandf3 6.9.5-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Jun 16 15:47:09 UTC 2024 x86_64 Alert Count 369 First Seen 2024-06-26 06:39:05 EDT Last Seen 2024-06-26 06:40:53 EDT Local ID 5a0cac7b-9d47-4953-9379-fadf8ef99c1a

Raw Audit Messages type=AVC msg=audit(1719398453.942:756): avc: denied { execheap } for pid=13241 comm="teams-for-linux" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0

Hash: teams-for-linux,unconfined_t,unconfined_t,process,execheap

[IsmaelMartinez]

Would you be able to test with 1.6.x and 1.7.x to see from what version this alert generated? I suspect is just a bug that would have been introduced in the refactoring from 1.7.x, but it could be other things like library updates.

Is it possible to get more detailed logs? I assume no but asking just in case. I am not familiar with se-linux alerts

On Wed, 26 Jun 2024, 12:07 Fred Welland, @.***> wrote:

Describe the bug Last 2 release of t4l. 1.7.3 and 1.7.4 -- but certainly 1.7.4 generates a SE-Linux alert on startup, and then t4l shuts down. If persistent, I can muscle through a few times and t4l will just start working, while ignoreing the SE-Linux alerts.

No I have not applied remedies suggested by SE-Linux alert browser; I wanted to keep the condition and submit an issue or question to see if this is a problem or not.

To Reproduce Steps to reproduce the behavior:

1. Start t4l
2. observe SE-Alerts

Expected behavior NO SEAlerts and t4l starts the first time.

Desktop (please complete the following information):

• OS: fedora 40 (6.9.5-200.fc40.x86_64 #1 https://github.com/IsmaelMartinez/teams-for-linux/pull/1 SMP PREEMPT_DYNAMIC)
• DNF/RPM based installed.
• current version: teams-for-linux-1.7.4-1.x86_64 (but the previous version, seemed to do it also; version before that, didn't seem to this.)

Additional context Here is details from SE-Linux/SETroubleshooting tool:

SELinux is preventing teams-for-linux from using the execheap access on a process.

***** Plugin allow_execheap (53.1 confidence) suggests ********************

If you do not think teams-for-linux should need to map heap memory that is both writable and executable. Then you need to report a bug. This is a potentially dangerous access. Do contact your security administrator and report this issue.

***** Plugin catchall_boolean (42.6 confidence) suggests ******************

If you want to allow selinuxuser to execheap Then you must tell SELinux about this by enabling the 'selinuxuser_execheap' boolean.

Do setsebool -P selinuxuser_execheap 1

***** Plugin catchall (5.76 confidence) suggests **************************

If you believe that teams-for-linux should be allowed execheap access on processes labeled unconfined_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: ausearch -c 'teams-for-linux' --raw | audit2allow -M my-teamsforlinux semodule -X 300 -i my-teamsforlinux.pp

Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Target Context unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Target Objects Unknown [ process ] Source teams-for-linux Source Path teams-for-linux Port Host wellandf3 Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-40.23-1.fc40.noarch Local Policy RPM selinux-policy-targeted-40.23-1.fc40.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name wellandf3 Platform Linux wellandf3 6.9.5-200.fc40.x86_64 #1 https://github.com/IsmaelMartinez/teams-for-linux/pull/1 SMP PREEMPT_DYNAMIC Sun Jun 16 15:47:09 UTC 2024 x86_64 Alert Count 369 First Seen 2024-06-26 06:39:05 EDT Last Seen 2024-06-26 06:40:53 EDT Local ID 5a0cac7b-9d47-4953-9379-fadf8ef99c1a

Raw Audit Messages type=AVC msg=audit(1719398453.942:756): avc: denied { execheap } for pid=13241 comm="teams-for-linux" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0

Hash: teams-for-linux,unconfined_t,unconfined_t,process,execheap

— Reply to this email directly, view it on GitHub https://github.com/IsmaelMartinez/teams-for-linux/issues/1319, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADJHEE7F7HR63YZDI5WS43ZJKOIHAVCNFSM6AAAAABJ5U3WVSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM3TKMBUGIYTSMY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[fwelland]

teams-for-linux-1.6.1-1.x86_64 didn't generate a SE-Alert.....

but teams-for-linux-1.7.0-1.x86_64 Did. I gather 1.7+ will do so... I know teams-for-linux-1.7.4-1.x86_64 did too.

In post #1 was the SELinux trouble shooting report. SELinux generates an alert when it detects something 'anomalous'. The trouble shooter suggests to investigate but provides hints to suppress if legit thing a processing is doing.

I can get more logs, if that is helpful. But what logs? Stuff from t4l? Like the debug stuff mentioned in the issue template?

NOTE: there is 'noise' on WWW that electron maybe has some inherit issues or reasons that can cause SELinux alerts. I didn't follow the release notes for t4l too closely, but maybe bump from 1.6x to 1.7x brought in new stuff from Electron...

HTH

[IsmaelMartinez]

The only change of libraries from 1.6.1 to 1.7.0 is this package https://github.com/sindresorhus/globals

We are still in electron 29.3, but hope to up to 30.x soon(ish).

In 1.7.2 we also added an option to disable local shortcuts, that "maybe" raises that alert, but that is only from 1.7.2. .

Also added eslint but that is for build time, not runtime.

See the changes in here... there is a lot of code-refactoring removing lines etc. https://github.com/IsmaelMartinez/teams-for-linux/compare/v1.6.1...v1.7.4

[IsmaelMartinez]

Can you check if 1.8.0 still has this error? I just updated electron to 30.

Also put the logs you for teams-for-linux. I don't think is going to be related to the web part, but there might be some info in there.

Thanks!

[fwelland]

Will do! May be a few days -- navigating out of office work. Also I applied a policy to ignore the SELinux alert I was getting from teams 1.7x. I need to figure out how to un-do that to get a proper test if 1.8x changes this or not.

[inittux111]

I'm running Silverblue and getting this as well, however Teams for Linux still works. So even though you may see something in the selinux audit.log about something being blocked it's not an issue unless the application breaks and even then there are selinux booleans you can use for such circumstances. I'm assuming this could also be caused by an application like Signal or Discord?

[IsmaelMartinez]

I will close this, If you got more info no why it is complaining then we can re-open.