[GH-ISSUE #3043] --apparmor breaks ./configure scripts created by autotools

gitea-mirror commented

2026-05-05 08:34:30 -06:00

Owner

Originally created by @KOLANICH on GitHub (Nov 13, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3043

The distro is Ubuntu Eoan.

Originally created by @KOLANICH on GitHub (Nov 13, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/3043 The distro is Ubuntu Eoan.

gitea-mirror

2026-05-05 08:34:30 -06:00

closed this issue
added the
question_old
label

gitea-mirror commented

2026-05-05 08:34:32 -06:00

Author

Owner

@Vincent43 commented on GitHub (Nov 14, 2019):

Do you mean you can't compile software inside firejail --apparmor sandbox? You can try adding in /etc/apparmor.d/local/firejail-{local,default}:

/your/build/dir/** ix,

then systemctl restart apparmor.

@Vincent43 commented on GitHub (Nov 14, 2019): Do you mean you can't compile software inside `firejail --apparmor` sandbox? You can try adding in `/etc/apparmor.d/local/firejail-{local,default}`: `/your/build/dir/** ix,` then `systemctl restart apparmor`.

gitea-mirror commented

2026-05-05 08:34:33 -06:00

Author

Owner

@KOLANICH commented on GitHub (Nov 14, 2019):

Do you mean you can't compile software inside firejail --apparmor sandbox? You can try adding in /etc/apparmor.d/local/firejail-{local,default}:

Thanks for the info. But I guess it is inacceptable to modify permanent apparmor rules. In fact I expected firejail generating apparmor profiles on the fly based on firejail profiles and CLI flags and loading them.

@KOLANICH commented on GitHub (Nov 14, 2019): >Do you mean you can't compile software inside firejail --apparmor sandbox? You can try adding in /etc/apparmor.d/local/firejail-{local,default}: Thanks for the info. But I guess it is inacceptable to modify permanent apparmor rules. In fact I expected firejail generating apparmor profiles on the fly based on firejail profiles and CLI flags and [loading them](https://gitlab.com/apparmor/apparmor/blob/master/parser/parser_interface.c).

gitea-mirror commented

2026-05-05 08:34:34 -06:00

Author

Owner

@Vincent43 commented on GitHub (Nov 15, 2019):

But I guess it is inacceptable to modify permanent apparmor rules.

The purpose of /etc/apparmor.d/local/* is to allow users override some vendor settings as they wish.

In fact I expected firejail generating apparmor profiles on the fly based on firejail profiles and CLI flags and loading them.

No, firejail has only one global and static apparmor profile which is attached to every app when --apparmor switch was used.

@Vincent43 commented on GitHub (Nov 15, 2019): > But I guess it is inacceptable to modify permanent apparmor rules. The purpose of `/etc/apparmor.d/local/*` is to allow users override some vendor settings as they wish. > In fact I expected firejail generating apparmor profiles on the fly based on firejail profiles and CLI flags and loading them. No, firejail has only [one global and static apparmor profile](https://github.com/netblue30/firejail/blob/master/etc/firejail-default) which is attached to every app when `--apparmor` switch was used.

gitea-mirror commented

2026-05-05 08:34:35 -06:00

Author

Owner

@KOLANICH commented on GitHub (Nov 15, 2019):

Yeah, I have already figured that out from the source. How about implementing the generation? To do that we need to split apparmor_parser into a shared lib and a CLI for it first.

@KOLANICH commented on GitHub (Nov 15, 2019): Yeah, I have already figured that out from the source. How about implementing the generation? To do that we need to split apparmor_parser into a shared lib and a CLI for it first.

gitea-mirror commented

2026-05-05 08:34:35 -06:00

Author

Owner

@Vincent43 commented on GitHub (Nov 15, 2019):

I could see two problems with it:

It will duplicate existing whitelist/blacklist functionality of firejail and I think it doesn't make sense supporting them both.
Is modifying apparmor profiles suitable for unprivileged user? On today's systems loading/unloading/customizing apparmor profiles can be done only by system administrator. There is a risk if we allow firejail access for apparmor management (and every user that has access to firejail) it can be (ab)used for decreasing system security.

AppArmor profile generator for docker.

@Vincent43 commented on GitHub (Nov 15, 2019): I could see two problems with it: 1. It will duplicate existing whitelist/blacklist functionality of firejail and I think it doesn't make sense supporting them both. 2. Is modifying apparmor profiles suitable for unprivileged user? On today's systems loading/unloading/customizing apparmor profiles can be done only by system administrator. There is a risk if we allow firejail access for apparmor management (and every user that has access to firejail) it can be (ab)used for decreasing system security. [AppArmor profile generator for docker](https://github.com/genuinetools/bane).

gitea-mirror commented

2026-05-05 08:34:36 -06:00

Author

Owner

@KOLANICH commented on GitHub (Nov 15, 2019):

Is modifying apparmor profiles suitable for unprivileged user?

Isn't firejail a suid app running from a privileged user?

There is a risk if we allow firejail access for apparmor management (and every user that has access to firejail) it can be (ab)used for decreasing system security.

Maybe. I am not familiar enough to apparmor yet.

@KOLANICH commented on GitHub (Nov 15, 2019): >Is modifying apparmor profiles suitable for unprivileged user? Isn't firejail a suid app running from a privileged user? >There is a risk if we allow firejail access for apparmor management (and every user that has access to firejail) it can be (ab)used for decreasing system security. Maybe. I am not familiar enough to apparmor yet.

gitea-mirror commented

2026-05-05 08:34:36 -06:00

Author

Owner

@Vincent43 commented on GitHub (Nov 16, 2019):

Isn't firejail a suid app running from a privileged user?

Firejail is a suid app run by unprivileged users. This means non-root users can execute actions normally restricted to root user. There are concerns that firejail allows too much stuff already.

@Vincent43 commented on GitHub (Nov 16, 2019): > Isn't firejail a suid app running from a privileged user? Firejail is a suid app run by unprivileged users. This means non-root users can execute actions normally restricted to root user. There are concerns that firejail allows too much stuff already.

gitea-mirror commented

2026-05-05 08:34:37 -06:00

Author

Owner

@KOLANICH commented on GitHub (Nov 16, 2019):

There are concerns that firejail allows too much stuff already.

I guess we need a special page collecting links to all the ideas about how each subset of subsystems of firejail and linux kernel can be exploited to subvert isolation.

But as I have said, I don't know enough about apparmor yet. I have read in multiple places that apparmor tracks executables by their fs addresses, but if it were the case it would have been impossible to use apparmor for hardening a firejail because adding an apparmor profile to a sandboxed process would have meant adding it to all other processes using the same executable, including unsandboxed ones, which is a deeply undesired side effect.

@KOLANICH commented on GitHub (Nov 16, 2019): >There are concerns that firejail allows too much stuff already. I guess we need a special page collecting links to all the ideas about how each subset of subsystems of firejail and linux kernel can be exploited to subvert isolation. But as I have said, I don't know enough about apparmor yet. I have read in multiple places that apparmor tracks executables by their fs addresses, but if it were the case it would have been impossible to use apparmor for hardening a firejail because adding an apparmor profile to a sandboxed process would have meant adding it to all other processes using the same executable, including unsandboxed ones, which is a deeply undesired side effect.

gitea-mirror commented

2026-05-05 08:34:37 -06:00

Author

Owner

@rusty-snake commented on GitHub (Dec 14, 2019):

still an issue?

@rusty-snake commented on GitHub (Dec 14, 2019): still an issue?

gitea-mirror commented

2026-05-05 08:34:37 -06:00

Author

Owner

@KOLANICH commented on GitHub (Dec 14, 2019):

Have anything been fixed? Current solution is to just disable apparmor for the builds using autotools.

@KOLANICH commented on GitHub (Dec 14, 2019): Have anything been fixed? Current solution is to just disable apparmor for the builds using autotools.

gitea-mirror commented

2026-05-05 08:34:38 -06:00

Author

Owner

@rusty-snake commented on GitHub (Dec 14, 2019):

There was some changes (#3075).

@rusty-snake commented on GitHub (Dec 14, 2019): There was some changes (#3075).

gitea-mirror commented

2026-05-05 08:34:38 -06:00

Author

Owner

@KOLANICH commented on GitHub (Dec 14, 2019):

Probably no. This issue is not about firejail build scripts but about autotools-generated scripts in general run inside a firejail. I gonna sometime isolate them into a separate hw-virtualized VM, but it is not a top priority.

@KOLANICH commented on GitHub (Dec 14, 2019): Probably no. This issue is not about firejail build scripts but about autotools-generated scripts in general run inside a firejail. I gonna sometime isolate them into a separate hw-virtualized VM, but it is not a top priority.

gitea-mirror commented

2026-05-05 08:34:39 -06:00

Author

Owner

@Vincent43 commented on GitHub (Dec 15, 2019):

This is working as intended, apparmor is blocking execution in non-whitelisted dirs by default and user can add more dirs to whitelist. Nothing to do here.

@Vincent43 commented on GitHub (Dec 15, 2019): This is working as intended, apparmor is blocking execution in non-whitelisted dirs by default and user can add more dirs to whitelist. Nothing to do here.

gitea-mirror referenced this issue

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

[PR #1911] [MERGED] Enable KVM on Android Studio #4124

Rows
Columns

[GH-ISSUE #3043] --apparmor breaks ./configure scripts created by autotools #1911