github-starred/firejail

Fork 0

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

[GH-ISSUE #2326] Enable apparmor specific aplication profile use #1554

New issue

Closed

opened 2026-05-05 08:12:54 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 08:12:54 -06:00

Owner

Originally created by @lhernanz on GitHub (Jan 2, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2326

Hi,
the current (read HEAD src/firejail/sandbox.c) apparmor integration always use the firejail-defaul apparmor profile even when a more specific profile exists for an application (e.g. firefox). This has 2 problems:

Complex applications are not going to work as well as with their specific apparmor profile (e.g. firefox)
If an application needs access to any additional path beyond the base profile, you need to add that to the global firejail-default file and it will effect any other application using that profile (e.g. keepass2 wants to create a directory KeePass in /run/user/uid and this is not allowed in the current profile). This is far from ideal from a security point of view.

Both problems would go away if firejail would try to identify if an specific application profile exist instead of always using the firejail-default one.

Regards

Originally created by @lhernanz on GitHub (Jan 2, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2326 Hi, the current (read HEAD src/firejail/sandbox.c) apparmor integration always use the firejail-defaul apparmor profile even when a more specific profile exists for an application (e.g. firefox). This has 2 problems: - Complex applications are not going to work as well as with their specific apparmor profile (e.g. firefox) - If an application needs access to any additional path beyond the base profile, you need to add that to the global firejail-default file and it will effect any other application using that profile (e.g. keepass2 wants to create a directory KeePass in /run/user/uid and this is not allowed in the current profile). This is far from ideal from a security point of view. Both problems would go away if firejail would try to identify if an specific application profile exist instead of always using the firejail-default one. Regards

gitea-mirror closed this issue

2026-05-05 08:12:55 -06:00

gitea-mirror commented

2026-05-05 08:12:56 -06:00

Author

Owner

@Vincent43 commented on GitHub (Jan 2, 2019):

Yes, that's how current AppArmor integration works. In general it's not recommended using both firejail and app specific AppArmor profile as they will conflict with each other. Chose only one of them.

@Vincent43 commented on GitHub (Jan 2, 2019): Yes, that's how current AppArmor integration works. In general it's not recommended using both firejail and app specific AppArmor profile as they will conflict with each other. Chose only one of them.

gitea-mirror commented

2026-05-05 08:12:57 -06:00

Author

Owner

@lhernanz commented on GitHub (Jan 4, 2019):

After further testing, I have realized that if you have an specific apparmor profile for an application, it is applied (on top of firejail) as long as you do not use the --apparmor option. If you use it, firejail will use its own apparmor profile. I would suggest that you include this information in the documentation to provide more clarity about the real intent/meaning of that option.

The problem that I have now is that I would like to use the default apparmor profile for all the applications that do not have their own and I cannot figure out a way of doing it without manually changing all the profiles (and that would be very inconvenient from the point of view of ugprades). Do you have any suggestion about how to do this? Is it even smart to try to do it (I am not sure if the addition of the firejail-defaut profile is going to break more things that the additional protection that is going to provide)?.
Thanks

@lhernanz commented on GitHub (Jan 4, 2019): After further testing, I have realized that if you have an specific apparmor profile for an application, it is applied (on top of firejail) as long as you do not use the `--apparmor` option. If you use it, firejail will use its own apparmor profile. I would suggest that you include this information in the documentation to provide more clarity about the real intent/meaning of that option. The problem that I have now is that I would like to use the default apparmor profile for all the applications that do not have their own and I cannot figure out a way of doing it without manually changing all the profiles (and that would be very inconvenient from the point of view of ugprades). Do you have any suggestion about how to do this? Is it even smart to try to do it (I am not sure if the addition of the firejail-defaut profile is going to break more things that the additional protection that is going to provide)?. Thanks

gitea-mirror commented

2026-05-05 08:12:58 -06:00

Author

Owner

@Vincent43 commented on GitHub (Jan 4, 2019):

After further testing, I have realized that if you have an specific apparmor profile for an application, it is applied (on top of firejail) as long as you do not use the --apparmor option. If you use it, firejail will use its own apparmor profile. I would suggest that you include this information in the documentation to provide more clarity about the real intent/meaning of that option.

Yes, that's exactly the case which i recommended against (using specific apparmor profile with firejail). Firejail don't control external AppArmor profiles and don't support them.

The problem that I have now is that I would like to use the default apparmor profile for all the applications that do not have their own and I cannot figure out a way of doing it without manually changing all the profiles (and that would be very inconvenient from the point of view of ugprades). Do you have any suggestion about how to do this?

I recommend disabling firejail (removing symlink from /usr/local/bin) for every app that have enforced AppArmor profile available. Alternatively disabling their AppArmor profiles instead, depending on which one (firejail or AppArmor) you prefer.

I am not sure if the addition of the firejail-defaut profile is going to break more things that the additional protection that is going to provide?

firejail-default AppArmor profile should be treated as Appendix to userspace firejail functionality. The exact things it does are documented in firejail manpage. Not using it is not a big deal.

@Vincent43 commented on GitHub (Jan 4, 2019): > After further testing, I have realized that if you have an specific apparmor profile for an application, it is applied (on top of firejail) as long as you do not use the --apparmor option. If you use it, firejail will use its own apparmor profile. I would suggest that you include this information in the documentation to provide more clarity about the real intent/meaning of that option. Yes, that's exactly the case which i recommended against (using specific apparmor profile with firejail). Firejail don't control external AppArmor profiles and don't support them. > The problem that I have now is that I would like to use the default apparmor profile for all the applications that do not have their own and I cannot figure out a way of doing it without manually changing all the profiles (and that would be very inconvenient from the point of view of ugprades). Do you have any suggestion about how to do this? I recommend disabling firejail (removing symlink from `/usr/local/bin`) for every app that have enforced AppArmor profile available. Alternatively disabling their AppArmor profiles instead, depending on which one (firejail or AppArmor) you prefer. > I am not sure if the addition of the firejail-defaut profile is going to break more things that the additional protection that is going to provide? firejail-default AppArmor profile should be treated as Appendix to userspace firejail functionality. The exact things it does are documented in firejail manpage. Not using it is not a big deal.

gitea-mirror commented

2026-05-05 08:12:59 -06:00

Author

Owner

@ghost commented on GitHub (Jan 20, 2020):

Closing this as the OP's question is answered.

@ghost commented on GitHub (Jan 20, 2020): Closing this as the OP's question is answered.

gitea-mirror referenced this issue

2026-05-05 10:12:16 -06:00

[PR #1554] [CLOSED] harden corebird #4019

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#1554

No description provided.

Rows
Columns