Flatpak stops working normally when apparmor.d is installed about apparmor.d HOT 14 CLOSED

Turns out the shell is not executed by the sandbox, but by flatpak-session-helper (which make sense). It does changes a few things. You don't need the additional rule (@{bin}/@{shells} rUx,) anymore, and terminal should work fine now.

Have a look at the commit comment in 7963a65

I suppose that fish is not registered in @{shells}?

It is, currently we have @{shells} = sh zsh bash dash fish rbash ksh tcsh csh

Which baffles me if there is no denied action

This is because of this:

ALLOWED flatpak-session-helper//null-@{bin}/fish//null-@{bin}/flatpak link owner @{run}/user/@{uid}/.flatpak/4048581798-private/#411 info="Failed name lookup - deleted entry" comm=flatpak requested_mask=l denied_mask=l error=-2

Failed name lookup will crash your app in most case.

from apparmor.d.

Thanks for these logs. I am going to investigate this issue. Usually Flatpak apps works fine (but they need a bit more testing).

Can you try to get more logs with:

1. aa-log -R -s that should provide all apparmor log since boot time (if journalctl collect them)
2. aa-log -R -f <nb> where <nb> is 1, 2, 3 and 4 (the rotated audit log file)

I am using systemd-homed managed users to operate my system. I have not tried if this comes out in the case of normal users.

That should not be a problem.

from apparmor.d.

I have fixed a few issues with Firefox & Brave. All classic GUI app should work as expected.

However, there are some limitations: Terminal & IDE

Both IDE and terminal need (indirect) full access to the system. For example, for terminal, it means, having @{bin}/@{shells} rUx,. It allows to start an unconfined shell from the profile so that you can run any command from your daily terminal, including a system update, a rm -rf /... There is a way to restrict this further, however, it includes more advanced configuration and security posture (ie: not something you expect when you are just installing some default profiles as in apt install apparmor.d)

The problem with flatpak is that the apparmor profile used is the same (flatpak-app) regardless of the application. So adding @{bin}/@{shells} rUx, in it would allow every flatpak app to escape the profile... making it useless.

Possible solutions are:

• To not run your terminal under flatpak
• To not confine flatpak app (or to use an unconfined profile).

from apparmor.d.

Hi, Alex thanks for the fast reply. I was not around my PC, so I could not answer.

Can you try to get more logs with:
aa-log -R -s that should provide all apparmor log since boot time (if journalctl collect them)
aa-log -R -f where is 1, 2, 3 and 4 (the rotated audit log file)

Do you still need these aforementioned logs?

Both IDE and terminal need (indirect) full access to the system. For example, for terminal, it means, having @{bin}/@{shells} rUx,. It allows to start an unconfined shell from the profile so that you can run any command from your daily terminal, including a system update, a rm -rf /...

So if I understand correctly, all Flatpak terminal emulators without a profile applied to Flatpaks where this is restricted, can launch a shell which has unrestricted access? Is this shell subject to restrictions set by bwrap to the emulator?

What I do not get is that according to the output of aa-status I have uploaded all Flatpak related profiles were in complain mode only. So why did it cause the linkat: not found problems?

Possible solutions are:

To not run your terminal under flatpak
To not confine flatpak app (or to use an unconfined profile).

As I do wish to maintain a more stable base system, if possible I would like to use the Flatpak version of my terminal emulator. Is there some way I can apply the currently set Flatpak profile to it and apply the needed permissions to it so the shell launched in it can have all the access it needs to operate normally?

from apparmor.d.

Do you still need these aforementioned logs?

Yes, please, it could give some hint regarding linkat.

So if I understand correctly, all Flatpak terminal emulators without a profile applied to Flatpaks where this is restricted, can launch a shell which has unrestricted access? Is this shell subject to restrictions set by bwrap to the emulator?

Yes, it is just that flatpak configures bwrap restriction according to the app developer setting (see for BlackBox). Meaning, there is no restriction for it. Please note that due to the nature of the sandboxed software, this is totally normal. Otherwise it would prevent you to do anything with your terminal...

So why did it cause the linkat: not found problems?

In short, even in complain mode, apparmor can enforce some rules. See https://apparmor.pujol.io/issues/

so the shell launched in it can have all the access it needs to operate normally?

Yes, apparmor.d is quite easy to personalise from a system admin side. Create the file /etc/apparmor.d/local/flatpak-app with the following content, then restart apparmor and it should work:

  # The shell is not confined on purpose.
  @{bin}/@{shells} rUx,

from apparmor.d.

Yes, apparmor.d is quite easy to personalise from a system admin side. Create the file /etc/apparmor.d/local/flatpak-app with the following content, then restart apparmor and it should work

Sorry for asking, but I am not that knowledgeable about creating Apparmor profiles: how do I identify the exact Flatpak application I want to create the profile for? Let's say BlackBox is installed as a system-wide Flatpak. Do I have to specify it in the apparmor profile is some way?

The best I could find on this topic was this recommendation:

/etc/apparmor.d/profile-name

#include <tunables/global>

/profile/path/to/bwrap ix,
/profile/path/to/bwrap (argv) "/usr/bin/bwrap --args-for-your-app" cx

from apparmor.d.

There is only one unique profile (flatpak-app) that is the same regardless of the flatpak application. You can extend it as I mentioned, however, it will apply these changes to all flatpak applications.

Due to how flatpak works, it is not possible to create a different profile for a specific flatpak application.

The best I could find on this topic was this recommendation:

I do not know where you find this, but this is not a valid profile at all.

from apparmor.d.

I do not know where you find this, but this is not a valid profile at all.

As proven again, LLMs are very creative regarding generating bogus 😄

There is only one unique profile (flatpak-app) that is the same regardless of the flatpak application. You can extend it as I mentioned, however, it will apply these changes to all flatpak applications.

So if I want my Flatpak terminal emulator to access a shell unrestricted, all Flatpaks would be allowed as well, if I add:

  # The shell is not confined on purpose.
  @{bin}/@{shells} rUx,

At this point I wonder if I should make a feature request for this for the upstream project, I think it would make sense to be able to specify per sandboxed applications, I mean Snap can do it, right?

from apparmor.d.

Flatpak will not add this feature, because the security of flatpak sandbox does not come from apparmor/selinux but from bwrap. This is a (perfectly correct) technical choice they made long time ago, they won't change this. Snap supports it because some part of the sandbox security depends on apparmor (again, technical choice they made long time ago).

Outside of defense in depth (that could work in some condition), the real reason why I added a flatpak profile is because the purpose of this project is to ensure no program run unconfined.

Therefore, as the security of flatpak app is handled by flatpak, you can safely add @{bin}/@{shells} rUx, in it.

from apparmor.d.

I see, thank you for enlightening me I am not nearly as well-versed as you are in this topic 😃 !
I will reinstall apparmor.d and get back to you with additional logs (also checking if they work fine otherwise).
Btw. would subsequent updates fail or overwrite my modified flatpak profile? I assume both the AUR package and the file I modify will write the same profile?

from apparmor.d.

@roddhjav I have installed apparmor.d-git from the AUR, created the following profile:
/etc/apparmor.d/local/flatpak-app:

@{bin}/@{shells} rUx,

However when running flatpak run <your.flatpak.here>, it still fails with the linkat error.
Did I create the profile incorrectly?

BTW, there is no log for the flatpak-app profile.
Here are the logs: audit.log

Again, no DENIED action at all 😒

from apparmor.d.

@roddhjav I have installed apparmor.d-git from the AUR, created the following profile: /etc/apparmor.d/local/flatpak-app:

@{bin}/@{shells} rUx,

However when running flatpak run <your.flatpak.here>, it still fails with the linkat error. Did I create the profile incorrectly?

BTW, there is no log for the flatpak-app profile. Here are the logs: audit.log

Again, no DENIED action at all 😒

Ah, so a bit of experimentation revelead when this problem occurs:

My default shell is bash for the user, however for BlackBox the custom startup command was set to be fish. I did this because I like fish better than bash, but I want to keep my configuration set in .bashrc.

It seems like if I delete this startup command, no such problem occurs. However if I launch fish specifically (launching bash in terminal doesn't act like it) manually or as a startup option, the problem persists.

I suppose that fish is not registered in @{shells}?

from apparmor.d.

I suppose that fish is not registered in @{shells}?

Ok a bit more update: it looks like this custom rule is ignored completely: commenting out the rule still produces the same behavior: from bash flatpaks work, from bash spawned fish shells, linkat is missing.

I guess, the problem is not with the flatpak-app profile... Which baffles me if there is no denied action. At the very least I would expect to see a denied action. (Or possibly the path to linkat is implicitly not available?)

from apparmor.d.