github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #1456] improve exception handling / dynamic filter customization #979

New issue

Closed

opened 2026-05-05 07:15:17 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 07:15:17 -06:00

Owner

Originally created by @Boruch-Baum on GitHub (Aug 11, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1456

How about a feature that instead of firejail enigmatically denying some program some access, that it display a pop-up telling the user what is happening, and allowing the user to optionally permit the access just this once, or permanently?

The advantages include:

Letting a user know specifically what the program is trying to do. A user (or a security researcher) might decide that a program qualifies as malware based upon the specific pop-up messages from firejail.
Making it easier for users to customize profiles. This will also make it MUCH easier for people to accept and adopt firejail, because (in my experience) currently the program requires patience and frustration-tolerance.

The disadvantages might include:

well, it's more work
pop-ups maybe implemented differently by different distributions. Firejail could just decide upon one as a hard dependency. That might not always look seamless for users' desktop themes, but it would be easiest.

Originally created by @Boruch-Baum on GitHub (Aug 11, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1456 How about a feature that instead of firejail enigmatically denying some program some access, that it display a pop-up telling the user what is happening, and allowing the user to optionally permit the access just this once, or permanently? The advantages include: 1) Letting a user know specifically what the program is trying to do. A user (or a security researcher) might decide that a program qualifies as malware based upon the specific pop-up messages from firejail. 2) Making it easier for users to customize profiles. This will also make it MUCH easier for people to accept and adopt firejail, because (in my experience) currently the program requires patience and frustration-tolerance. The disadvantages might include: 1) well, it's more work 2) pop-ups maybe implemented differently by different distributions. Firejail could just decide upon one as a hard dependency. That might not always look seamless for users' desktop themes, but it would be easiest.

gitea-mirror

2026-05-05 07:15:17 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

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

Author

Owner

@netblue30 commented on GitHub (Aug 15, 2017):

firejail enigmatically denying some program some access

It is not fireajil, it is the kernel. What firejail does is to configure seccomp and namespaces in Linux kernel and after that it goes to sleep. When access to a file is denied, only the kernel knows about it.

We do have a --tracelog option that works in user space for files specifically blacklisted. It sends a message to syslog announcing the access attempt, but like anything else in user space you can get around it.

@netblue30 commented on GitHub (Aug 15, 2017): > firejail enigmatically denying some program some access It is not fireajil, it is the kernel. What firejail does is to configure seccomp and namespaces in Linux kernel and after that it goes to sleep. When access to a file is denied, only the kernel knows about it. We do have a --tracelog option that works in user space for files specifically blacklisted. It sends a message to syslog announcing the access attempt, but like anything else in user space you can get around it.

gitea-mirror commented

2026-05-05 07:15:23 -06:00

Author

Owner

@Boruch-Baum commented on GitHub (Aug 16, 2017):

Oh. That means what I was suggesting would entail a lot more work. Firejail would have to intercept somehow the kernel's complaint, and then act.

@Boruch-Baum commented on GitHub (Aug 16, 2017): Oh. That means what I was suggesting would entail a lot more work. Firejail would have to intercept somehow the kernel's complaint, and then act.

gitea-mirror commented

2026-05-05 07:15:25 -06:00

Author

Owner

@Ferroin commented on GitHub (Aug 16, 2017):

FWIW, I think if you have auditing enabled, you can use that to get info on access denials, and that can't be bypassed. Doesn't help much of course with the possibility of allowing access, but it least it could improve the logged messages regarding the denied access.

@Ferroin commented on GitHub (Aug 16, 2017): FWIW, I think if you have auditing enabled, you can use that to get info on access denials, and that can't be bypassed. Doesn't help much of course with the possibility of allowing access, but it least it could improve the logged messages regarding the denied access.

gitea-mirror referenced this issue

2026-05-05 10:08:24 -06:00

[PR #979] [MERGED] Correct skanlite.profile #3812

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#979

No description provided.

Rows
Columns