Bug#912587: apparmor makes dmesg useless

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#912587: apparmor makes dmesg useless

Salvo Tomaselli-3
Source: apparmor
Severity: important

Dear Maintainer,
when apparmor is installed, it emits an incredible amount of
logs on dmesg, causing actual important stuff from the kernel
to be missed.

By incredible amount I mean that it fills completely the ring
buffer with crap.

Should it even be logging on dmesg?

Imagine dmesg, only filled of this:
[299560.719237] audit: type=1400 audit(1541071734.314:10526): apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=13691 comm="TaskSchedulerSi" requested_mask="read" denied_mask="read" peer="firejail-default"
[299560.719241] audit: type=1400 audit(1541071734.314:10527): apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=13691 comm="TaskSchedulerSi" requested_mask="readby" denied_mask="readby" peer="firejail-default"
[299560.921678] audit: type=1400 audit(1541071734.518:10528): apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=13691 comm="TaskSchedulerSi" requested_mask="read" denied_mask="read" peer="firejail-default"

For now my solution is to remove apparmor, but it gets sometimes pulled in again by other things.

Best

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Reply | Threaded
Open this post in threaded view
|

Bug#912587: apparmor makes dmesg useless

intrigeri
Control: reassign -1 firejail

Hi Salvo!

Salvo Tomaselli:
> when apparmor is installed, it emits an incredible amount of
> logs on dmesg, causing actual important stuff from the kernel
> to be missed.

Only if some buggy profiles are enabled.

> Should it even be logging on dmesg?

AppArmor is a LSM and the kernel logs there.

> [299560.719237] audit: type=1400 audit(1541071734.314:10526): apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=13691 comm="TaskSchedulerSi" requested_mask="read" denied_mask="read" peer="firejail-default"
> [299560.719241] audit: type=1400 audit(1541071734.314:10527): apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=13691 comm="TaskSchedulerSi" requested_mask="readby" denied_mask="readby" peer="firejail-default"
> [299560.921678] audit: type=1400 audit(1541071734.518:10528): apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=13691 comm="TaskSchedulerSi" requested_mask="read" denied_mask="read" peer="firejail-default"

⇒ reassigning to firejail.

> For now my solution is to remove apparmor,

I would instead suggest:

  sudo aa-disable /etc/apparmor.d/firejail-default

… until that profile is fixed.

So that in the meantime, you keep benefiting from other AppArmor
profiles :)

@firejail maintainers: happy to help if you wish so!

Cheers,
--
intrigeri

Reply | Threaded
Open this post in threaded view
|

Bug#912587: apparmor makes dmesg useless

Reiner Herrmann
Hi Salvo and intrigeri,

On Thu, Nov 01, 2018 at 05:58:49PM +0100, intrigeri wrote:
> > [299560.719237] audit: type=1400 audit(1541071734.314:10526): apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=13691 comm="TaskSchedulerSi" requested_mask="read" denied_mask="read" peer="firejail-default"
> > [299560.719241] audit: type=1400 audit(1541071734.314:10527): apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=13691 comm="TaskSchedulerSi" requested_mask="readby" denied_mask="readby" peer="firejail-default"
> > [299560.921678] audit: type=1400 audit(1541071734.518:10528): apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=13691 comm="TaskSchedulerSi" requested_mask="read" denied_mask="read" peer="firejail-default"
>
> ⇒ reassigning to firejail.

I'm also using apparmor and firejail, but haven't seen any similar
messages in my kernel log (not even with 'firejail --apparmor').
With which programs are you using firejail at the time the logs are
appearing?
ptrace sounds like you were running a debugger or something similar
in firejail.
Are the logs also appearing when firejail is not running anything
('firejail --list' is empty)?

> > For now my solution is to remove apparmor,
>
> I would instead suggest:
>
>   sudo aa-disable /etc/apparmor.d/firejail-default

The firejail profile is only used when firejail is instructed to load
it. It shouldn't do any harm on its own.

> @firejail maintainers: happy to help if you wish so!

Do you see anything in the profile that looks wrong and could be causing
those logs when it is loaded by firejail?

Kind regards,
   Reiner

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#912587: apparmor makes dmesg useless

Reiner Herrmann
On Thu, Nov 01, 2018 at 06:13:02PM +0100, Reiner Herrmann wrote:
> Do you see anything in the profile that looks wrong and could be causing
> those logs when it is loaded by firejail?

I just saw that the firejail-default AppArmor profile contains the
following:

> ##########
> # With ptrace it is possible to inspect and hijack running programs.
> # Usually this
> # is needed only for debugging. To allow ptrace, uncomment the following
> # line.
> ##########
> #ptrace,

@Salvo, do you still see the logs, when you uncomment ptrace here and
reload it?

Regards,
  Reiner

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#912587: apparmor makes dmesg useless

Salvo Tomaselli-3
Normally, this

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?

How do i reload after changing an apparmor profile?
Il giorno gio 1 nov 2018 alle ore 18:22 Reiner Herrmann
<[hidden email]> ha scritto:

>
> On Thu, Nov 01, 2018 at 06:13:02PM +0100, Reiner Herrmann wrote:
> > Do you see anything in the profile that looks wrong and could be causing
> > those logs when it is loaded by firejail?
>
> I just saw that the firejail-default AppArmor profile contains the
> following:
>
> > ##########
> > # With ptrace it is possible to inspect and hijack running programs.
> > # Usually this
> > # is needed only for debugging. To allow ptrace, uncomment the following
> > # line.
> > ##########
> > #ptrace,
>
> @Salvo, do you still see the logs, when you uncomment ptrace here and
> reload it?
>
> Regards,
>   Reiner



--
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
                -- Galileo Galilei

http://ltworf.github.io/ltworf/

Reply | Threaded
Open this post in threaded view
|

Bug#912587: apparmor makes dmesg useless

Reiner Herrmann
On Fri, Nov 02, 2018 at 09:54:35AM +0100, Salvo Tomaselli wrote:

> Normally, this
>
> 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).

But regarding your problem, I find it strange anyway that (one of) those
three programs want to use ptrace, so it's in my opinion valid to log
it. Maybe steam is using ptrace to look into the memory of some started
games? So you either allow ptrace in the apparmor profile, or you ask
firejail not use apparmor for e.g. the steam profile.

> How do i reload after changing an apparmor profile?

Try /etc/init.d/apparmor reload.

Kind regards,
   Reiner

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#912587: apparmor makes dmesg useless

intrigeri
Reiner Herrmann:
>> How do i reload after changing an apparmor profile?

> Try /etc/init.d/apparmor reload.

This will do something closer to what you want in many cases:

  sudo apparmor_parser -r /path/to/the/profile

Cheers,
--
intrigeri

Reply | Threaded
Open this post in threaded view
|

Bug#912587: apparmor makes dmesg useless

intrigeri-4
In reply to this post by Reiner Herrmann
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

Reply | Threaded
Open this post in threaded view
|

Bug#912587: apparmor makes dmesg useless

Reiner Herrmann
Hi intrigeri,

On Sun, Dec 16, 2018 at 02:14:54PM +0100, intrigeri wrote:

> 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.
Thanks for the suggestion.
I was unfamiliar with the example rule you provided above, so I looked
it up. According to the AppArmor wiki [0] this finer-grained ptrace
control is only available in AppArmor 3.
But I can see it also being used in some profiles installed on my
system. Has this feature been backported to version 2?

Kind regards,
   Reiner

[0] https://gitlab.com/apparmor/apparmor/wikis/TechnicalDoc_Proc_and_ptrace

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#912587: apparmor makes dmesg useless

intrigeri-4
Hi,

Reiner Herrmann:
> I was unfamiliar with the example rule you provided above, so I looked
> it up. According to the AppArmor wiki [0] this finer-grained ptrace
> control is only available in AppArmor 3.
> But I can see it also being used in some profiles installed on my
> system. Has this feature been backported to version 2?

On my sid system, apparmor.d(5) documents fine-grained ptrace rules
and indeed, the parser does compile such policy just fine. I can't
recall if the Linux kernel (mainline) enforces them though.

I've patched that manpage in Debian so it reads:

   Some features are not supported on Debian yet:

    - Network Rules
    - DBus rules
    - Unix socket rules

… and I would hope I did check back then, so I *think* fine-grained
ptrace rules are enforced by Linux 4.19 mainline. Now, that's easy to
test :)

Cheers,
--
intrigeri