[GH-ISSUE #884] slack.profile does not allow opening URLs in messages

gitea-mirror commented

2026-05-05 06:15:11 -06:00

Owner

Originally created by @elvetemedve on GitHub (Oct 31, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/884

Somehow the default web browser should be white-listed in order to be able to open URLs posted in instant messages.

Originally created by @elvetemedve on GitHub (Oct 31, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/884 Somehow the default web browser should be white-listed in order to be able to open URLs posted in instant messages.

gitea-mirror

2026-05-05 06:15:11 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 06:15:18 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Nov 1, 2016):

Isn't that hard/impossible to do? On Debian, you could theoretically use x-www-browser, but that's just a symbolic link to /etc/alternatives/x-www-browser which in turn is a symbolic link to the actual browser. You have no way of apriori knowing what that is. One tack to take is just to whitelist all the common browsers, but that's kinda defeating the purpose. The other way is to create a local profile ~/.config/firejail/slack.profile, include the global one, and additionally whitelist whatever browser you use, which is probably the best way to go.

@chiraag-nataraj commented on GitHub (Nov 1, 2016): Isn't that hard/impossible to do? On Debian, you could theoretically use `x-www-browser`, but that's just a symbolic link to `/etc/alternatives/x-www-browser` which in turn is a symbolic link to the actual browser. You have no way of apriori knowing what that is. One tack to take is just to whitelist all the common browsers, but that's kinda defeating the purpose. The other way is to create a local profile `~/.config/firejail/slack.profile`, include the global one, and additionally whitelist whatever browser you use, which is probably the best way to go.

gitea-mirror commented

2026-05-05 06:15:22 -06:00

Author

Owner

@elvetemedve commented on GitHub (Nov 1, 2016):

Well, I like the idea of adding all common browsers to the whitelist. I don't think that would weaken the protection, because those browsers should be run in a sandbox as well. But current profile decrease the usability (I could mention the document viewer evince which has the same issue. I cannot open external links from documents). It's not something the application should not do, this is part of its feature set.

@elvetemedve commented on GitHub (Nov 1, 2016): Well, I like the idea of adding all common browsers to the whitelist. I don't think that would weaken the protection, because those browsers should be run in a sandbox as well. But current profile decrease the usability (I could mention the document viewer _evince_ which has the same issue. I cannot open external links from documents). It's not something the application should not do, this is part of its feature set.

gitea-mirror commented

2026-05-05 06:15:26 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Nov 1, 2016):

Well whitelisting them means also whitelisting additional files in /etc, additional binaries, and so on - basically, it forces the profile to be wider than it should be and allows access to files that slack itself may not need. So it does indeed weaken the protection. Now whether that weakening of the profile is something you want is up to you, but I don't think it should be the default for the profile.

By the way, this is additionally super bad because whitelisting Google Chrome means also disabling seccomp and capabilities filters, which are effectively necessary for any program which doesn't have its own (basically any program except for Google Chrome). You really don't want to do this unless you have to.

[Edit] I believe the additional whitelisting is only necessary if you assume you may have to start the program from within the slack sandbox. Otherwise, you may be able to get away with just whitelisting the binaries, so it may not be as bad as I first thought.

@chiraag-nataraj commented on GitHub (Nov 1, 2016): Well whitelisting them means also whitelisting additional files in `/etc`, additional binaries, and so on - basically, it forces the profile to be wider than it should be and allows access to files that slack itself may not need. So it does indeed weaken the protection. Now whether that weakening of the profile is something you want is up to you, but I don't think it should be the default for the profile. By the way, this is additionally super bad because whitelisting Google Chrome means also disabling seccomp and capabilities filters, which are effectively necessary for any program which doesn't have its own (basically any program except for Google Chrome). You _really_ don't want to do this unless you have to. [Edit] I believe the additional whitelisting is only necessary if you assume you may have to start the program from within the slack sandbox. Otherwise, you may be able to get away with just whitelisting the binaries, so it may not be as bad as I first thought.

gitea-mirror commented

2026-05-05 06:15:28 -06:00

Author

Owner

@elvetemedve commented on GitHub (Nov 1, 2016):

I played a bit with the slack.profile and removed few restrictions. As I see the opened browser will be run in the same sandbox as Slack just like you mentioned.

Reading profile /home/geza/.config/firejail/slack.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/whitelist-common.inc
Warning: user namespaces not available in the current kernel.
Parent pid 15006, child pid 15007
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted
Child process initialized
Redirecting symlink to /usr/bin/slack
Warning: cannot switch euid to root
Warning: cannot switch egid to root
Warning: cannot switch euid to root
Warning: cannot switch egid to root
Warning: an existing sandbox was detected. /usr/bin/slack will run without any additional sandboxing features
Child process initialized

(slack:8): dconf-WARNING **: Unable to open /var/lib/flatpak/exports/share/dconf/profile/user: Permission denied
Creating Slack Application
/opt/google/chrome/google-chrome: line 45: /dev/fd/62: No such file or directory
/opt/google/chrome/google-chrome: line 46: /dev/fd/62: No such file or directory
The setuid sandbox is not running as root. Common causes:

An unprivileged process using ptrace on it, like a debugger.

A parent process set prctl(PR_SET_NO_NEW_PRIVS, ...)
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted

Is there a way to tell firejail to create new processes outside the sandbox of Slack? When I click on a link like https://kernel.org/, then I would like to see firejail google-chrome-stable http://kernel.org/ executed. That way Chrome would run within its own sandbox.

@elvetemedve commented on GitHub (Nov 1, 2016): I played a bit with the slack.profile and removed few restrictions. As I see the opened browser will be run in the same sandbox as Slack just like you mentioned. > Reading profile /home/geza/.config/firejail/slack.profile > Reading profile /etc/firejail/disable-common.inc > Reading profile /etc/firejail/disable-programs.inc > Reading profile /etc/firejail/disable-devel.inc > Reading profile /etc/firejail/disable-passwdmgr.inc > Reading profile /etc/firejail/whitelist-common.inc > Warning: user namespaces not available in the current kernel. > Parent pid 15006, child pid 15007 > Warning: /sbin directory link was not blacklisted > Warning: /usr/sbin directory link was not blacklisted > Child process initialized > Redirecting symlink to /usr/bin/slack > Warning: cannot switch euid to root > Warning: cannot switch egid to root > Warning: cannot switch euid to root > Warning: cannot switch egid to root > Warning: an existing sandbox was detected. /usr/bin/slack will run without any additional sandboxing features > Child process initialized > > (slack:8): dconf-WARNING **: Unable to open /var/lib/flatpak/exports/share/dconf/profile/user: Permission denied > Creating Slack Application > /opt/google/chrome/google-chrome: line 45: /dev/fd/62: No such file or directory > /opt/google/chrome/google-chrome: line 46: /dev/fd/62: No such file or directory > The setuid sandbox is not running as root. Common causes: > - An unprivileged process using ptrace on it, like a debugger. > - A parent process set prctl(PR_SET_NO_NEW_PRIVS, ...) > Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted Is there a way to tell firejail to create new processes outside the sandbox of Slack? When I click on a link like `https://kernel.org/`, then I would like to see `firejail google-chrome-stable http://kernel.org/` executed. That way Chrome would run within its own sandbox.

gitea-mirror commented

2026-05-05 06:15:31 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Nov 2, 2016):

Try with Chrome already opened (you may have to whitelist Google Chrome's configuration directory? not sure). I think it will still require syscalls, though probably not as many...

@chiraag-nataraj commented on GitHub (Nov 2, 2016): Try with Chrome already opened (you may have to whitelist Google Chrome's configuration directory? not sure). I think it will still require syscalls, though probably not as many...

gitea-mirror commented

2026-05-05 06:15:35 -06:00

Author

Owner

@elvetemedve commented on GitHub (Nov 6, 2016):

I managed to enable opening URLs via Google Chrome. Unfortunately it's not enough strict to make it default.
I think seccomp filter has a bug, because if I restrict access to any system call like seccomp.drop swapon, it won't work anymore, but I'm sure that neither Slack nor Chrome touch the swap management.

See the modified profile here: slack.profile.txt

@elvetemedve commented on GitHub (Nov 6, 2016): I managed to enable opening URLs via Google Chrome. Unfortunately it's not enough strict to make it default. I think seccomp filter has a bug, because if I restrict access to any system call like `seccomp.drop swapon`, it won't work anymore, but I'm sure that neither Slack nor Chrome touch the swap management. See the modified profile here: [slack.profile.txt](https://github.com/netblue30/firejail/files/573983/slack.profile.txt)

gitea-mirror commented

2026-05-05 06:15:37 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Nov 6, 2016):

Yes, because the default seccomp filter (which is what seccomp.drop uses) doesn't work for Google Chrome.

@chiraag-nataraj commented on GitHub (Nov 6, 2016): Yes, because the default seccomp filter (which is what `seccomp.drop` uses) doesn't work for Google Chrome.

gitea-mirror referenced this issue

2026-05-05 10:05:53 -06:00

[PR #598] [MERGED] Committer: Paupiah Yashvi <yash@hackers.mu> #3677

Rows
Columns

[GH-ISSUE #884] slack.profile does not allow opening URLs in messages #598