Control: retitle -1 firejail AppArmor profile blocks Chromium's usage of ptrace => large amounts of denial logged
Hi, Reiner Herrmann: > On Fri, Nov 02, 2018 at 09:54:35AM +0100, Salvo Tomaselli wrote: >> 1424:salvo::/usr/bin/firejail /usr/bin/telegram-desktop -- >> 2205:salvo::/usr/bin/firejail /usr/bin/chromium >> 5684:salvo::/usr/bin/firejail /usr/games/steam -tcp >> >> I am however questioning the design decision of having those audit >> logs in the kernel logs, since they push out the interesting logs, and >> every failure seems to be logged. If they are so important, why log >> them in a place where having so many of them will delete the older >> ones? > I'm not sure if it's possible to stop them from landing in the kernel > log. Perhaps when using auditd? > The kernel log buffer is also not meant to keep an infinite history of log > messages. It's better to use a logging daemon if you don't want to miss > anything (which could also filter duplicates etc). Indeed. We're trying hard to only ship AppArmor policy that does not cause such trouble in Debian; AFAICT we're doing pretty good at it. Now, a profile meant to apply to basically *any* program, such as firejail-default, is by design a huge challenge: as long as it does not allow *everything* (which would make it entirely moot), it's unavoidable that such a profile will occasionally block some of the operations attempted by the programs it confines; I'm not surprised this can sometimes result in functionality breakage or huge amounts of denial logs. So I think it's good that Firejail enables AppArmor confinement by default: users can try it out if they wish, and if it causes trouble, either stop using it for the problematic app, or adjust the firejail-default profile (in this case: enable the commented out "ptrace," rule; and possibly make it a bit stricter to only allow ptrace'ing peer=firejail-default). > But regarding your problem, I find it strange anyway that (one of) those > three programs want to use ptrace, IIRC Chromium uses some operation guarded by ptrace to set up its sandboxing or for communication between its components. Recent Firefox does the same. It's quite common that a sandboxing technology requires elevated privileges and here we're stacking 3 different ones (Chromium's, Firejail, and AppArmor) so I'm not surprised that one of them is broken by one of the 2 others. If this problem affects too many Firejail users who opt-in for --apparmor, I would recommend documenting this rule in the default profile: ptrace (read,readby) peer=firejail-default, I'll let the maintainer judge whether this should be enabled by default. Other than this, it would be good if the "Usually this is needed only for debugging" documentation string was updated a little bit to reflect common current use cases of ptrace. Cheers, -- intrigeri
