[arch-general] AppArmor support

[Gus]

I know such request was rejected here
https://bugs.archlinux.org/task/59733
recently, but still AppArmor doesn't need linking with libraries and
doesn't
require as much userland support as SELinux, so it will not hurt to have
one
option enabled in kernel, right?

[Filipe Laíns via arch-general]

Post by Gus
I know such request was rejected here
https://bugs.archlinux.org/task/59733
recently, but still AppArmor doesn't need linking with libraries and
doesn't
require as much userland support as SELinux, so it will not hurt to have
one
option enabled in kernel, right?

Hey Gus,

I'm sorry but I'm not the maintainer :/. You'll need to talk to them
again. If you think the closure of the bug was wrong I suggest to send
a mail to the mailing list explaining this.

Why don't you use linux-hardened instead? It's up-to-date and has both
options enabled (AppArmor and SELinux).

I feel that it's the biggest issue. We already have a kernel with both
options enabled so there's no point on also adding them in the main
one, given that those option require a lot of userspace support. Do you
have relevant reason why you don't want to use linux-hardened? If so,
that would probably change some things.

Thanks,
Filipe Laíns
3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2

[Filipe Laíns via arch-general]

Post by Filipe Laíns via arch-general
Hey Gus,
I'm sorry but I'm not the maintainer :/. You'll need to talk to them
again. If you think the closure of the bug was wrong I suggest to send
a mail to the mailing list explaining this.
Why don't you use linux-hardened instead? It's up-to-date and has both
options enabled (AppArmor and SELinux).
I feel that it's the biggest issue. We already have a kernel with both
options enabled so there's no point on also adding them in the main
one, given that those option require a lot of userspace support. Do you
have relevant reason why you don't want to use linux-hardened? If so,
that would probably change some things.
Thanks,
Filipe Laíns
3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2

Hey,

Nevermind my reply. The email somehow didn't get moved to my mailing
list folder so I thought it was sent to my address directly. Sorry for
the confusion.

Thanks,
Filipe Laíns
3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2

[Gus]

Linux-hardened doesn't support hibernation and i think it's overkill to
use it on desktop.

Post by Filipe Laíns via arch-general

Post by Gus
I know such request was rejected here
https://bugs.archlinux.org/task/59733
recently, but still AppArmor doesn't need linking with libraries and
doesn't
require as much userland support as SELinux, so it will not hurt to have
one
option enabled in kernel, right?

Hey Gus,
I'm sorry but I'm not the maintainer :/. You'll need to talk to them
again. If you think the closure of the bug was wrong I suggest to send
a mail to the mailing list explaining this.
Why don't you use linux-hardened instead? It's up-to-date and has both
options enabled (AppArmor and SELinux).
I feel that it's the biggest issue. We already have a kernel with both
options enabled so there's no point on also adding them in the main
one, given that those option require a lot of userspace support. Do you
have relevant reason why you don't want to use linux-hardened? If so,
that would probably change some things.
Thanks,
Filipe Laíns
3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2

[Carsten Mattner via arch-general]

Post by Gus
Linux-hardened doesn't support hibernation and i think it's overkill to
use it on desktop.

Not arguing in anyway for or against AppArmor, just another
data point regarding linux-hardened 4.17 and 4.18:

I tried linux-hardened on two Intel machines, and it was less stable
than "linux". Some of the changes are probably invasive/destabilising,
which makes sense seeing how slowly and carefully the mitigations are
traveling via Kees Cook into Linus' tree. I didn't have stability
issues with the old linux-grsec packages, though to be fair those
were also way older major releases which may matter.

[Levente Polyak via arch-general]

Post by Carsten Mattner via arch-general

Post by Gus
Linux-hardened doesn't support hibernation and i think it's overkill to
use it on desktop.

Not arguing in anyway for or against AppArmor, just another
I tried linux-hardened on two Intel machines, and it was less stable
than "linux". Some of the changes are probably invasive/destabilising,
which makes sense seeing how slowly and carefully the mitigations are
traveling via Kees Cook into Linus' tree. I didn't have stability
issues with the old linux-grsec packages, though to be fair those
were also way older major releases which may matter.

It is quite definitively equally stable as vanilla linux is, there is no
crazy overly invasive stuff in hardened that would justify claiming
otherwise.

What you most likely encountered, like literally all other "instability"
issues so far, is that with your setup you triggered a stock vanilla
linux bug with the difference that hardened immediately shuts itself
down for security reasons. These bugs are corruption and integrity
related and shutting down follows "better safe then sorry" for the
hardened variant.
There are various kernel configs doing so, to name some:
CONFIG_BUG_ON_DATA_CORRUPTION, CONFIG_DEBUG_LIST, CONFIG_DEBUG_SG and
lots more including slab sanitizing/verifying specifically in
combination with CONFIG_PANIC_ON_OOPS.

Just a crazy idea but how about contributing back instead of just
complaining? People on the bug tracker always help guiding how to report
upstream or finding relevant commits. Yeah, i know it takes a while to
compile, but it's not that complicated:
- take a look at the panic in hardened
- peek the code around it to find out which of the protective config
values may have triggered it (if not already obvious from the panic)
- reproduce on stock/vanilla kernel by building it including the
responsible configs
- report upstream using the gathered information of the vanilla kernel
- bonus points for git bisecting the commit that broke it

This would not only contribute to make hardened run on your or similar
setups, all vanilla linux users would benefit by helping to fix a bug
that can or does result in a corruption.

cheers,
Levente

[Carsten Mattner via arch-general]

Post by Levente Polyak via arch-general
It is quite definitively equally stable as vanilla linux is, there is no
crazy overly invasive stuff in hardened that would justify claiming
otherwise.

That hasn't been my experience, and I'm happy to hear I might be an
outlier. I am grateful for the work you put in and hope to see hardened
features be completely included in Linus' tree some day.

Post by Levente Polyak via arch-general
What you most likely encountered, like literally all other "instability"
issues so far, is that with your setup you triggered a stock vanilla
linux bug with the difference that hardened immediately shuts itself
down for security reasons. These bugs are corruption and integrity
related and shutting down follows "better safe then sorry" for the
hardened variant.
CONFIG_BUG_ON_DATA_CORRUPTION, CONFIG_DEBUG_LIST, CONFIG_DEBUG_SG and
lots more including slab sanitizing/verifying specifically in
combination with CONFIG_PANIC_ON_OOPS.

That's a possible explanation, and I wasn't complaining, but what I
wrote seems to signal that. I'm sorry it sounded like a complain.
The message I was trying to convey is that proposing linux-hardened
to make use of a feature that's been stable in Linus' tree isn't
a good idea due to stability and reluctant support likelihood when
you run into a problem.

If I have a problem with Fedora, I first ask in Fedora's forums
because they patch their kernel a lot. With Arch, I don't have
to because "linux" only carries a couple backports of fixes,
and all I need to show is config.gz.

With all that being said, I'm genuinely glad to hear that linux-hardened
generally works and I have just been unlucky to hit the right code paths.

Post by Levente Polyak via arch-general
Just a crazy idea but how about contributing back instead of just
complaining? People on the bug tracker always help guiding how to report
upstream or finding relevant commits. Yeah, i know it takes a while to
- take a look at the panic in hardened
- peek the code around it to find out which of the protective config
values may have triggered it (if not already obvious from the panic)
- reproduce on stock/vanilla kernel by building it including the
responsible configs
- report upstream using the gathered information of the vanilla kernel
- bonus points for git bisecting the commit that broke it
This would not only contribute to make hardened run on your or similar
setups, all vanilla linux users would benefit by helping to fix a bug
that can or does result in a corruption.

I did and do. I have open bugs in freedesktop and kernel bugzilla which
are not resolved and in NEW state for months and years. These are usually
regressions in drivers due to the Linux driver packaging model and
insufficient testing on supported hardware configurations. What happens
is that a driver that works flawlessly on hardware rev-1.8 suddenly starts
misbehaving with a newer kernel that has seen improvements, refactorings,
and support for newer hardware. It's most prominent in the graphics stack,
which is complex, hard to test, and easy to break. I don't blame the
developers for having a hard time, I'm discouraged stable drivers for
old hardware get regressions and stop being tested as well as hardware
of years -2/+2 years.

Therefore, I hope you don't mind if my frustration level with the issues
I'm tracking right now is high enough that I'm not in the mood to debug
and track issues I can avoid by using a different stable kernel branch.

Greg, rightfully for the most part, always encourages people to upgrade
to the latest stable branch, but he never talks about preventable
regressions that happen due to speed and unnecessary modifications in
stable drivers for older hardware. What's telling is that it's primarily
hardware drivers, while the general kernel code isn't regressing. If
Linux had a driver ABI......

[Levente Polyak via arch-general]

Post by Carsten Mattner via arch-general

Post by Levente Polyak via arch-general
Just a crazy idea but how about contributing back instead of just
complaining? People on the bug tracker always help guiding how to report
upstream or finding relevant commits. Yeah, i know it takes a while to
- take a look at the panic in hardened
- peek the code around it to find out which of the protective config
values may have triggered it (if not already obvious from the panic)
- reproduce on stock/vanilla kernel by building it including the
responsible configs
- report upstream using the gathered information of the vanilla kernel
- bonus points for git bisecting the commit that broke it
This would not only contribute to make hardened run on your or similar
setups, all vanilla linux users would benefit by helping to fix a bug
that can or does result in a corruption.

I did and do. I have open bugs in freedesktop and kernel bugzilla which
are not resolved and in NEW state for months and years. These are usually
regressions in drivers due to the Linux driver packaging model and
insufficient testing on supported hardware configurations. What happens
is that a driver that works flawlessly on hardware rev-1.8 suddenly starts
misbehaving with a newer kernel that has seen improvements, refactorings,
and support for newer hardware. It's most prominent in the graphics stack,
which is complex, hard to test, and easy to break. I don't blame the
developers for having a hard time, I'm discouraged stable drivers for
old hardware get regressions and stop being tested as well as hardware
of years -2/+2 years.
Therefore, I hope you don't mind if my frustration level with the issues
I'm tracking right now is high enough that I'm not in the mood to debug
and track issues I can avoid by using a different stable kernel branch.

Nice to hear that you do or at least did, bear with me for
overgeneralizing in in your case.

However, the point of my whole response was that you are most
definitively triggering/encountering the very same bug on the stock
kernel, stock variant just tries to go ahead instead of panic, which
means it may result in corruption and possibly killing kittens. Whatever
is encountered there is at least a "regular regression" and possibly
could provide surface for exploitation.

If you are not using linux-lts you are pretty much using the very same
stable branch/tag in linux-hardened that vanilla linux uses so there is
no "different stable kernel branch". If former is the case you can
pretty much blame vanilla linux package to an equal amount as the
hardened variant for being buggy.

cheers,
Levente

[Carsten Mattner via arch-general]

Post by Levente Polyak via arch-general

Post by Carsten Mattner via arch-general

Post by Levente Polyak via arch-general
Just a crazy idea but how about contributing back instead of just
complaining? People on the bug tracker always help guiding how to report
upstream or finding relevant commits. Yeah, i know it takes a while to
- take a look at the panic in hardened
- peek the code around it to find out which of the protective config
values may have triggered it (if not already obvious from the panic)
- reproduce on stock/vanilla kernel by building it including the
responsible configs
- report upstream using the gathered information of the vanilla kernel
- bonus points for git bisecting the commit that broke it
This would not only contribute to make hardened run on your or similar
setups, all vanilla linux users would benefit by helping to fix a bug
that can or does result in a corruption.

I did and do. I have open bugs in freedesktop and kernel bugzilla which
are not resolved and in NEW state for months and years. These are usually
regressions in drivers due to the Linux driver packaging model and
insufficient testing on supported hardware configurations. What happens
is that a driver that works flawlessly on hardware rev-1.8 suddenly starts
misbehaving with a newer kernel that has seen improvements, refactorings,
and support for newer hardware. It's most prominent in the graphics stack,
which is complex, hard to test, and easy to break. I don't blame the
developers for having a hard time, I'm discouraged stable drivers for
old hardware get regressions and stop being tested as well as hardware
of years -2/+2 years.
Therefore, I hope you don't mind if my frustration level with the issues
I'm tracking right now is high enough that I'm not in the mood to debug
and track issues I can avoid by using a different stable kernel branch.

Nice to hear that you do or at least did, bear with me for
overgeneralizing in in your case.

I'm glad my response didn't result in an unfriendly counter, I was
a little anxious what your reply will be :).

Post by Levente Polyak via arch-general
However, the point of my whole response was that you are most
definitively triggering/encountering the very same bug on the stock
kernel, stock variant just tries to go ahead instead of panic, which
means it may result in corruption and possibly killing kittens. Whatever
is encountered there is at least a "regular regression" and possibly
could provide surface for exploitation.
If you are not using linux-lts you are pretty much using the very same
stable branch/tag in linux-hardened that vanilla linux uses so there is
no "different stable kernel branch". If former is the case you can
pretty much blame vanilla linux package to an equal amount as the
hardened variant for being buggy.

Maybe someday I can use 4.19, after switching to AMD or AMD+nVidia....

On my primary machine I use LTS 4.4. It also has the graphics regressions
introduced with 4.2 and later for Intel GPUs, but it's not as bad as
later LTS branches. If I need to stress the GPU, I need to sidestep to
LTS 3.16 because there's no other LTS release after LTS 4.1 was EOL'd.
GPU hangs and ring timeouts are most frequent issues, in addition to
other bugs.

Somewhere in the last 3 or 4 years, something happened in Intel's GPU
team, and they introduced enough regressions that I started wondering
how I never thought about Intel GPU drivers before 4.2, when stuff
just worked if the GPU was documented to be supported.

I don't want to bore you with GPU driver complaints, it's not your
responsibility. Planning to use newer Ryan APUs for iGPU case and
dedicated GPU, ignoring Intel completely, in desktop machines,
when I upgrade hardware.

[Geo Kozey via arch-general]

----------------------------------------
Sent: Mon Sep 10 14:09:06 CEST 2018
Subject: Re: [arch-general] AppArmor support
Nice to hear that you do or at least did, bear with me for
overgeneralizing in in your case.
However, the point of my whole response was that you are most
definitively triggering/encountering the very same bug on the stock
kernel, stock variant just tries to go ahead instead of panic, which
means it may result in corruption and possibly killing kittens. Whatever
is encountered there is at least a "regular regression" and possibly
could provide surface for exploitation.
If you are not using linux-lts you are pretty much using the very same
stable branch/tag in linux-hardened that vanilla linux uses so there is
no "different stable kernel branch". If former is the case you can
pretty much blame vanilla linux package to an equal amount as the
hardened variant for being buggy.
cheers,
Levente

I think you may consider disabling CONFIG_PANIC_ON_OOPS in linux-hardened
default config. Preventing users from being able to debug and report their
issues upstream or even discouraging them from using linux-hardend at all is
quite a big cost of it. Asking users to recompile their kernels every time they want
to investigate their issues is also a little too much.

There is "oops=panic" cmdline which everyone can use and which is much more
flexible to switch between debug/non-debug mode than recompiling. I don't think
adding something to cmdline is beyond capabilities of Arch users, especially if
they're interested in security.

Yours sincerely

G. K.

[Levente Polyak via arch-general]

Post by Geo Kozey via arch-general
I think you may consider disabling CONFIG_PANIC_ON_OOPS in linux-hardened
default config. Preventing users from being able to debug and report their
issues upstream or even discouraging them from using linux-hardend at all is
quite a big cost of it. Asking users to recompile their kernels every time they want
to investigate their issues is also a little too much.
There is "oops=panic" cmdline which everyone can use and which is much more
flexible to switch between debug/non-debug mode than recompiling. I don't think
adding something to cmdline is beyond capabilities of Arch users, especially if
they're interested in security.
Yours sincerely
G. K.

I think you are totally missing the point, everyone can happily debug,
bisect and get proper crash information. The problem is reporting
upstream, which won't be accepted if you use anything but a vanilla
kernel (which hardened isn't as it provides custom patches).

If you want to approach upstream then reproducing the same thing on the
vanilla kernel is the only option you have, otherwise it will be rejected.

cheers,
Levente

[Geo Kozey via arch-general]

----------------------------------------
Sent: Mon Sep 10 18:42:14 CEST 2018
Subject: Re: [arch-general] AppArmor support
I think you are totally missing the point, everyone can happily debug,
bisect and get proper crash information. The problem is reporting
upstream, which won't be accepted if you use anything but a vanilla
kernel (which hardened isn't as it provides custom patches).
If you want to approach upstream then reproducing the same thing on the
vanilla kernel is the only option you have, otherwise it will be rejected.
cheers,
Levente

Nope. Not everyone can happily debug and bisect if every bug causes panic
and forced reboot of their machine.

As a person who reported dozen of bugs (mostly upstream specific but some
of them can be found only with linux-hardened - all of them fixed) and who
tests every rc kernel with linux-hardened patch and several others patches on
top of it, I can tell you that none valid report will be rejected. Of course I don't
report issues with linux-hardened patch itself upstream.

I have to admit that if I haven't disabled myself CONFIG_PANIC_ON_OOPS I
would give up long time ago.

Yours sincerely

G. K.

[Levente Polyak via arch-general]

Post by Geo Kozey via arch-general

----------------------------------------
Sent: Mon Sep 10 18:42:14 CEST 2018
Subject: Re: [arch-general] AppArmor support
I think you are totally missing the point, everyone can happily debug,
bisect and get proper crash information. The problem is reporting
upstream, which won't be accepted if you use anything but a vanilla
kernel (which hardened isn't as it provides custom patches).
If you want to approach upstream then reproducing the same thing on the
vanilla kernel is the only option you have, otherwise it will be rejected.
cheers,
Levente

Nope. Not everyone can happily debug and bisect if every bug causes panic
and forced reboot of their machine.
As a person who reported dozen of bugs (mostly upstream specific but some
of them can be found only with linux-hardened - all of them fixed) and who
tests every rc kernel with linux-hardened patch and several others patches on
top of it, I can tell you that none valid report will be rejected. Of course I don't
report issues with linux-hardened patch itself upstream.
I have to admit that if I haven't disabled myself CONFIG_PANIC_ON_OOPS I
would give up long time ago.

Sure, and thanks for doing so! Fair enough, at least if you are
bisecting/debugging... but then you are recompiling multiple times
anyway and nobody wants to and nothing stops you from keeping
CONFIG_PANIC_ON_OOPS off while doing so.

However, that's not the average use case and that doesn't mean it must
be off for everyone, it will remain "better safe then sorry" by default
for the reasons i pointed out.

cheers,
Levente

[ProgAndy]

Post by Levente Polyak via arch-general
Sure, and thanks for doing so! Fair enough, at least if you are
bisecting/debugging... but then you are recompiling multiple times
anyway and nobody wants to and nothing stops you from keeping
CONFIG_PANIC_ON_OOPS off while doing so.
However, that's not the average use case and that doesn't mean it must
be off for everyone, it will remain "better safe then sorry" by default
for the reasons i pointed out.
cheers,
Levente

If the kernel boots, isn't it possible to use the sysctl
"kernel.panic_on_oops" to disable the panic if it is really necessary?

https://www.kernel.org/doc/Documentation/sysctl/kernel.txt


---
Andy

[Carsten Mattner via arch-general]

Of course I don't report issues with linux-hardened patch itself upstream.

Correct me if I'm wrong, but does that mean you first try to repro with
vanilla and fall back to reporting to -hardened if it's not present in
Linus' tree?

[Geo Kozey via arch-general]

----------------------------------------
Sent: Mon Sep 10 20:07:23 CEST 2018
Subject: Re: [arch-general] AppArmor support

Of course I don't report issues with linux-hardened patch itself upstream.

Correct me if I'm wrong, but does that mean you first try to repro with
vanilla and fall back to reporting to -hardened if it's not present in
Linus' tree?

No, I meant build warnings, build failures or merge conflicts which can be directly
attributed to linux-hardened patch. Honestly I don't remember real kernel bugs
caused by linux-hardened patchset perhaps because it's rather tiny (100 times
smaller than last grsecurity patch was) and not that invasive.

CONFIG_FORTIFY_SOURCE_STRICT_STRING can find bugs which aren't visible in
vanillia but there are still upstream bugs not linux-hardened and can be reported
upstream.

Yours sincerely

G. K.

[Maksim Fomin via arch-general]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Post by Gus
I know such request was rejected here
https://bugs.archlinux.org/task/59733
recently, but still AppArmor doesn't need linking with libraries and
doesn't
require as much userland support as SELinux, so it will not hurt to have
one
option enabled in kernel, right?

You have been rejected by heftig and tpowa. It is unclear why and what you are asking here.
Suppose AppArmour does not require linking. So what?

Btw, you hided the information - this issue was reopened and closed again, so it was reconsidered and was closed twice.

[Gus]

Post by Maksim Fomin via arch-general
You have been rejected by heftig and tpowa. It is unclear why and what you are asking here.

It was accepted first and then rejected by heftig.

Post by Maksim Fomin via arch-general
Suppose AppArmour does not require linking. So what?

As heftig wrote, that was main reason for rejecting SELinux and AppArmor
support, but since it doesn't apply to AppArmor i see no reason to
reject it.

[Maksim Fomin via arch-general]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Post by Gus

Post by Maksim Fomin via arch-general
You have been rejected by heftig and tpowa. It is unclear why and what
you are asking here.

It was accepted first and then rejected by heftig.

Really? Just rejected by heftig? The issue was rejected 4 times, first by heftig than 3 times by Scimmia:

2018-09-03
"A Project Manager has denied the request pending for the following task: FS#59733 - [linux] enable AppArmor & SELinux User who did this - Doug Newgard (Scimmia) Reason for denial:

2018-09-05
"FS#59733 - [linux] enable AppArmor & SELinux User who did this - Doug Newgard (Scimmia) Reason for denial: No new information"

"FS#59733 - [linux] enable AppArmor & SELinux User who did this - Doug Newgard (Scimmia) Reason for denial: I'm not going to reopen a ticket for people to make the same argument over and over"

"Reason for denial: Stop having a catfight with the bugwranglers because you think, somehow, that people will be less likely to open duplicate bugs just because we provide dialog. There are better mediums to have this discussion."

So far, this issue was closed by heftig and then 3 times by bug wrangler. This fact was hidden in the first post to this thread.

[Eli Schwartz via arch-general]

Please do not try to defend me and Scimmia when in fact we told people
to take it to "more appropriate mediums"... like the mailing list, which
they did in fact do *as I personally requested*, and which you are now
reprimanding them for.

Let's be perfectly clear here: There is *nothing* wrong with Gus'
attempt at dialog and discussion -- the fact that it was closed more
than once has no relevance to this discussion, as Gus tried to explain,
and moreover the fact that it was initially accepted *once* then
rejected *once* for the reasons clearly referenced in the initial post,
is hardly hidden information.

I am, however, troubled by your attacks, and consider something to be
wrong with that.

Heftig retracted his initial willingness to enable apparmor because he
did not think it useful enough without the userland tools. It wasn't
rejected because we hate the idea or consider it not Arch-like... it was
rejected because on its own, it could be considered not-important-enough
to warrant enabling.

People now want to discuss on the mailing list why it might be worth it
nevertheless. There are valid technical arguments to be made here, and
so far, the initial poster has been pretty polite about it. Moreover, I
agree. Even though I'm not heftig.

Thank you for respecting other peoples' right to ask questions. :)

[Leonid Isaev via arch-general]

Post by Eli Schwartz via arch-general
Heftig retracted his initial willingness to enable apparmor because he
did not think it useful enough without the userland tools. It wasn't
rejected because we hate the idea or consider it not Arch-like... it was
rejected because on its own, it could be considered not-important-enough
to warrant enabling.

FWIW, I actually agree with #59733: CONFIG_AUDIT=n was blocking AppArmor
adoption... Perhaps relevant:
https://lists.debian.org/debian-devel/2017/08/msg00090.html .

But I have a question: why was AUDIT enabled in the first place? I thought it
was cosidered useless?

Cheers,
L.

[David Runge]

Post by Eli Schwartz via arch-general

Post by Eli Schwartz via arch-general
Heftig retracted his initial willingness to enable apparmor because

he

Post by Eli Schwartz via arch-general
did not think it useful enough without the userland tools. It wasn't
rejected because we hate the idea or consider it not Arch-like... it

was

Post by Eli Schwartz via arch-general
rejected because on its own, it could be considered

not-important-enough

Post by Eli Schwartz via arch-general
to warrant enabling.

FWIW, I actually agree with #59733: CONFIG_AUDIT=n was blocking
AppArmor
https://lists.debian.org/debian-devel/2017/08/msg00090.html .
But I have a question: why was AUDIT enabled in the first place? I thought it
was cosidered useless?
Cheers,
L.

FYI,
I'm currently working on bringing the user space tools to [community], but the rule sets will require testing and possibly we'll even have to have our own set shipped with the package.

I'll let you know asap.

As a side note: As Eli already pointed out there is no need for personal attacks because of a discussion on this topic. We'll try to make this ship sail, but it needs time (and testing).

Best,
David

[Leonid Isaev via arch-general]

Post by David Runge
FYI,
I'm currently working on bringing the user space tools to [community], but
the rule sets will require testing and possibly we'll even have to have our
own set shipped with the package.
I'll let you know asap.

Thanks and pls take your time. I have a VM that runs linux-hardened and is used
to study malicious pdf files. I can test rulesets there...

Cheers,
L.

[David Runge]

Post by Leonid Isaev via arch-general

Post by David Runge
FYI,
I'm currently working on bringing the user space tools to [community], but
the rule sets will require testing and possibly we'll even have to have our
own set shipped with the package.
I'll let you know asap.

Thanks and pls take your time. I have a VM that runs linux-hardened and is used
to study malicious pdf files. I can test rulesets there...

It is now in [community-testing]. Feel free to comment and suggest
improvements!

Best,
David

[Geo Kozey via arch-general]

----------------------------------------
Sent: Thu Sep 13 19:51:49 CEST 2018
Subject: Re: [arch-general] AppArmor support
It is now in [community-testing]. Feel free to comment and suggest
improvements!
Best,
David

The profile filenames doesn't matter (bin.ping, usr.bin.ping or ping-pong
will work the same. It only matters what's inside). You don't have to
change them[0]. Perhaps it will be better to leave them untouched for
easier comparison with upstream.

2.13.1 release will be very soon[1] with better usrmerge support which
means modifying profiles inside with sed won't be needed to.


[0] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/apparmor#n48
[1] https://gitlab.com/apparmor/apparmor/wikis/Release_Notes_2.13.1
[2] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/apparmor#n54

Yours sincerely

G. K.

[David Runge]

Post by Geo Kozey via arch-general

----------------------------------------
Sent: Thu Sep 13 19:51:49 CEST 2018
Subject: Re: [arch-general] AppArmor support
It is now in [community-testing]. Feel free to comment and suggest
improvements!
Best,
David

The profile filenames doesn't matter (bin.ping, usr.bin.ping or ping-pong
will work the same. It only matters what's inside). You don't have to
change them[0]. Perhaps it will be better to leave them untouched for
easier comparison with upstream.

The thing is: Some of them only reference /bin, /sbin or /usr/sbin,
which needs to be replaced for our use-case. That is not easily achieved
using sed, without also changing the includes of the override files in
local/.
A rename was therefore the easiest solution to this problem.

If I find some time over the coming days I might have another go at it
to see if there's another way of achieving the internal replaces without
moving files. Problematically the files are not very unified.

Post by Geo Kozey via arch-general
2.13.1 release will be very soon[1] with better usrmerge support which
means modifying profiles inside with sed won't be needed to.

Hmm, they only mention usrmerge on one file... lol.

Thanks for the input!

Best,
David

[Geo Kozey via arch-general]

----------------------------------------
Sent: Fri Sep 14 11:24:09 CEST 2018
Subject: Re: [arch-general] AppArmor support

Post by Geo Kozey via arch-general

----------------------------------------
Sent: Thu Sep 13 19:51:49 CEST 2018
Subject: Re: [arch-general] AppArmor support
It is now in [community-testing]. Feel free to comment and suggest
improvements!
Best,
David

The profile filenames doesn't matter (bin.ping, usr.bin.ping or ping-pong
will work the same. It only matters what's inside). You don't have to
change them[0]. Perhaps it will be better to leave them untouched for
easier comparison with upstream.

The thing is: Some of them only reference /bin, /sbin or /usr/sbin,
which needs to be replaced for our use-case. That is not easily achieved
using sed, without also changing the includes of the override files in
local/.
A rename was therefore the easiest solution to this problem.
If I find some time over the coming days I might have another go at it
to see if there's another way of achieving the internal replaces without
moving files. Problematically the files are not very unified.

Post by Geo Kozey via arch-general
2.13.1 release will be very soon[1] with better usrmerge support which
means modifying profiles inside with sed won't be needed to.

Hmm, they only mention usrmerge on one file... lol.
Thanks for the input!
Best,
David

They called it 'binmerge' :)

https://gitlab.com/apparmor/apparmor/commit/4200932d8fb31cc3782d96dd8312511e807fd09b

I think this should fix issues with referencing filenames that you mentioned.
If there's something else left you may try to open issue/merge request upstream.

BTW: Upstream URL should be https://gitlab.com/apparmor/apparmor as this is
where develeopment activity occurs.

Yours sincerely

G. K.

[David Runge]

Post by Geo Kozey via arch-general
They called it 'binmerge' :)

Hope this can be achieved for all profiles.

Post by Geo Kozey via arch-general
https://gitlab.com/apparmor/apparmor/commit/4200932d8fb31cc3782d96dd8312511e807fd09b
I think this should fix issues with referencing filenames that you
mentioned. If there's something else left you may try to open
issue/merge request upstream.

I'll do that. There are more problems with the package, than just the
profiles ;-)

Post by Geo Kozey via arch-general
BTW: Upstream URL should be https://gitlab.com/apparmor/apparmor as this is
where develeopment activity occurs.

Forgot to put that in (will do next time).

However, I managed to only replace the use of /sbin/, /usr/sbin/ and
/bin/ by /usr/bin/. The profile names are left unchanged now.

To all interested: Please do test, if you have the time!

Best,
David

[Geo Kozey via arch-general]

----------------------------------------
Sent: Thu Sep 20 20:42:08 CEST 2018
Subject: Re: [arch-general] AppArmor support

Post by Geo Kozey via arch-general
They called it 'binmerge' :)

Hope this can be achieved for all profiles.

Post by Geo Kozey via arch-general
https://gitlab.com/apparmor/apparmor/commit/4200932d8fb31cc3782d96dd8312511e807fd09b
I think this should fix issues with referencing filenames that you
mentioned. If there's something else left you may try to open
issue/merge request upstream.

I'll do that. There are more problems with the package, than just the
profiles ;-)

Post by Geo Kozey via arch-general
BTW: Upstream URL should be https://gitlab.com/apparmor/apparmor as this is
where develeopment activity occurs.

Forgot to put that in (will do next time).
However, I managed to only replace the use of /sbin/, /usr/sbin/ and
/bin/ by /usr/bin/. The profile names are left unchanged now.
To all interested: Please do test, if you have the time!
Best,
David

I found that 'binmerge' commit was only merged to 'master' branch which
means it won't be part of upcoming 2.13.1 release. You may consider
applying it locally or keep using sed rules.

https://gitlab.com/apparmor/apparmor/commit/4200932d8fb31cc3782d96dd8312511e807fd09b

Another thing is python abstraction which is currently broken in Arch as it
doesn't cover python 3.7. The below commit fixes it and this time it will be
part of 2.13.1 release:

https://gitlab.com/apparmor/apparmor/commit/d9d3cae2aaf272e2039d6f9113ab59d486e29b2b
Yours sincerely

G. K.

[Gus]

Post by David Runge

Post by Geo Kozey via arch-general
They called it 'binmerge' :)

Hope this can be achieved for all profiles.

Post by Geo Kozey via arch-general
https://gitlab.com/apparmor/apparmor/commit/4200932d8fb31cc3782d96dd8312511e807fd09b
I think this should fix issues with referencing filenames that you
mentioned. If there's something else left you may try to open
issue/merge request upstream.

I'll do that. There are more problems with the package, than just the
profiles ;-)

Post by Geo Kozey via arch-general
BTW: Upstream URL should be https://gitlab.com/apparmor/apparmor as this is
where develeopment activity occurs.

Forgot to put that in (will do next time).
However, I managed to only replace the use of /sbin/, /usr/sbin/ and
/bin/ by /usr/bin/. The profile names are left unchanged now.
To all interested: Please do test, if you have the time!
Best,
David

Have been running it for a few days, so far everything is alright.
Thanks.

Also, don't know if it should be done in upstream or not, but maybe
logprof.conf
should be modified a little to add, for example, /usr/bin/zsh in
[qualifiers]
section. And anyone knows what the point in [repository] section?

[David Runge]

Have been running it for a few days, so far everything is alright. Thanks.

That's good news!

Also, don't know if it should be done in upstream or not, but maybe
logprof.conf
should be modified a little to add, for example, /usr/bin/zsh in
[qualifiers]
section. And anyone knows what the point in [repository] section?

I assume upstream would be the place for this.

Thanks for testing!

[Geo Kozey via arch-general]

----------------------------------------
Sent: Fri Sep 21 20:41:15 CEST 2018
Subject: Re: [arch-general] AppArmor support

Have been running it for a few days, so far everything is alright. Thanks.

That's good news!

Also, don't know if it should be done in upstream or not, but maybe
logprof.conf
should be modified a little to add, for example, /usr/bin/zsh in
[qualifiers]
section. And anyone knows what the point in [repository] section?

I assume upstream would be the place for this.
Thanks for testing!

After [0] sed rules are applied to all apparmor config files, not just profiles
which results in unwanted errors:

configparser.DuplicateOptionError: While reading from '/etc/apparmor/logprof.conf' [line 47]: option '/usr/bin/bash' in section 'qualifiers' already exists

You should limit it to profiles only as it was before.

[0] https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/apparmor&id=4dc153bf8e26239a55409ac5d1994f6575e057c5


Yours sincerely

G. K.

[David Runge]

Hi Geo,

Post by Geo Kozey via arch-general
After [0] sed rules are applied to all apparmor config files, not just
configparser.DuplicateOptionError: While reading from
'/etc/apparmor/logprof.conf' [line 47]: option '/usr/bin/bash' in
section 'qualifiers' already exists
You should limit it to profiles only as it was before.
[0] https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/apparmor&id=4dc153bf8e26239a55409ac5d1994f6575e057c5

Thanks for the info!
That was indeed a problem, but not because of the profile modifications.
I did way too broad replacements in logprof.conf, that led to the
duplicate entries you are experiencing (as there are entries for /bin
and /usr/bin for most binaries).

I have now fixed this in 2.13.0-6 (by carefully only replacing the use
of sbin where needed). Please let me know, if this works as intended for
you!

Best,
David

[Geo Kozey via arch-general]

----------------------------------------
Sent: Sat Sep 22 17:43:51 CEST 2018
Subject: Re: [arch-general] AppArmor support
Hi Geo,

Post by Geo Kozey via arch-general
After [0] sed rules are applied to all apparmor config files, not just
configparser.DuplicateOptionError: While reading from
'/etc/apparmor/logprof.conf' [line 47]: option '/usr/bin/bash' in
section 'qualifiers' already exists
You should limit it to profiles only as it was before.
[0] https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/apparmor&id=4dc153bf8e26239a55409ac5d1994f6575e057c5

Thanks for the info!
That was indeed a problem, but not because of the profile modifications.
I did way too broad replacements in logprof.conf, that led to the
duplicate entries you are experiencing (as there are entries for /bin
and /usr/bin for most binaries).
I have now fixed this in 2.13.0-6 (by carefully only replacing the use
of sbin where needed). Please let me know, if this works as intended for
you!
Best,
David
--

It's almost there ;)

'/usr/bin/subdomain_parser' under [qualifiers] is still duplicated.

I'm not sure if 'apparmor_parser' and 'subdomain_parser' under [settings]
have to be modified. IMO they should work as symlinks too.

BTW: users transition from AUR may be complicated as now apparmor
package will contain files available in apparmor-* split packages before.
Maybe you have to add 'replaces=' for split packages.

Yours sincerely

G. K.

[Geo Kozey via arch-general]

----------------------------------------
Sent: Sat Sep 22 18:23:58 CEST 2018
Subject: Re: [arch-general] AppArmor support

----------------------------------------
Sent: Sat Sep 22 17:43:51 CEST 2018
Subject: Re: [arch-general] AppArmor support
Hi Geo,

Post by Geo Kozey via arch-general
After [0] sed rules are applied to all apparmor config files, not just
configparser.DuplicateOptionError: While reading from
'/etc/apparmor/logprof.conf' [line 47]: option '/usr/bin/bash' in
section 'qualifiers' already exists
You should limit it to profiles only as it was before.
[0] https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/apparmor&id=4dc153bf8e26239a55409ac5d1994f6575e057c5

Thanks for the info!
That was indeed a problem, but not because of the profile modifications.
I did way too broad replacements in logprof.conf, that led to the
duplicate entries you are experiencing (as there are entries for /bin
and /usr/bin for most binaries).
I have now fixed this in 2.13.0-6 (by carefully only replacing the use
of sbin where needed). Please let me know, if this works as intended for
you!
Best,
David
--

It's almost there ;)
'/usr/bin/subdomain_parser' under [qualifiers] is still duplicated.
I'm not sure if 'apparmor_parser' and 'subdomain_parser' under [settings]
have to be modified. IMO they should work as symlinks too.
BTW: users transition from AUR may be complicated as now apparmor
package will contain files available in apparmor-* split packages before.
Maybe you have to add 'replaces=' for split packages.
Yours sincerely
G. K.

Also there aren't such things like:

/usr/bin/subdomain_parser
/usr/bin/logprof
/usr/bin/genprof

in Arch anyway so creating them isn't necessary. Perhaps if there is anything
left to change in [qualifiers] section, it can be upstreamed as well.

Yours sincerely

G. K.

[David Runge]

Post by Geo Kozey via arch-general

Post by Geo Kozey via arch-general
It's almost there ;)
'/usr/bin/subdomain_parser' under [qualifiers] is still duplicated.

Ah, the match was not good enough yet. Now it should be!

Post by Geo Kozey via arch-general

Post by Geo Kozey via arch-general
I'm not sure if 'apparmor_parser' and 'subdomain_parser' under [settings]
have to be modified. IMO they should work as symlinks too.

It's easier for replacing the sbin stuff atm.

Post by Geo Kozey via arch-general

Post by Geo Kozey via arch-general
BTW: users transition from AUR may be complicated as now apparmor
package will contain files available in apparmor-* split packages before.
Maybe you have to add 'replaces=' for split packages.

This is already the case.
Yeah, I figured.

Post by Geo Kozey via arch-general
/usr/bin/subdomain_parser

This one is utterly bizarre. I have no clue where this is supposed to be
coming from, because it's not included in the sources, but mentioned in
regression and stress tests and there's a config and man page for it! oO

Post by Geo Kozey via arch-general
/usr/bin/logprof
/usr/bin/genprof

These seem to be around as /usr/bin/aa-{logprof,genprof} and are
installed this way as defined in source code.
Very... odd.
I'll change the configuration to reflect that for now...

Post by Geo Kozey via arch-general
in Arch anyway so creating them isn't necessary. Perhaps if there is anything
left to change in [qualifiers] section, it can be upstreamed as well.

Yeah, the configuration needs to be extended to also cover /usr/bin (for
our case).
I'm already compiling a list of things that need to be taken care of
upstream, to make packaging less painful.

Thanks for all the feedback!

Best,
David

[Geo Kozey via arch-general]

----------------------------------------
Sent: Sat Sep 22 21:43:20 CEST 2018
Subject: Re: [arch-general] AppArmor support

Post by Geo Kozey via arch-general

Post by Geo Kozey via arch-general
It's almost there ;)
'/usr/bin/subdomain_parser' under [qualifiers] is still duplicated.

Ah, the match was not good enough yet. Now it should be!

Post by Geo Kozey via arch-general

Post by Geo Kozey via arch-general
I'm not sure if 'apparmor_parser' and 'subdomain_parser' under [settings]
have to be modified. IMO they should work as symlinks too.

It's easier for replacing the sbin stuff atm.

Post by Geo Kozey via arch-general

Post by Geo Kozey via arch-general
BTW: users transition from AUR may be complicated as now apparmor
package will contain files available in apparmor-* split packages before.
Maybe you have to add 'replaces=' for split packages.

This is already the case.
Yeah, I figured.

Post by Geo Kozey via arch-general
/usr/bin/subdomain_parser

This one is utterly bizarre. I have no clue where this is supposed to be
coming from, because it's not included in the sources, but mentioned in
regression and stress tests and there's a config and man page for it! oO

This is legacy cruft. Perhaps it exist on some ancient distributions.
We shouldn't care of it.

Post by Geo Kozey via arch-general
/usr/bin/logprof
/usr/bin/genprof

These seem to be around as /usr/bin/aa-{logprof,genprof} and are
installed this way as defined in source code.
Very... odd.
I'll change the configuration to reflect that for now...

Same as above. As you can see no other aa-* tools are whitelisted this way.
We should ignore this.

Post by Geo Kozey via arch-general
in Arch anyway so creating them isn't necessary. Perhaps if there is anything
left to change in [qualifiers] section, it can be upstreamed as well.

Yeah, the configuration needs to be extended to also cover /usr/bin (for
our case).
I'm already compiling a list of things that need to be taken care of
upstream, to make packaging less painful.

I looked at the diff between our logprof.conf and upstream, here are
my thoughts:

/var/log/syslog.log and /var/log/syslog.log don't exist in Arch as logs
are handled by journald. There is syslog-ng package in extra but
according to its docs it uses /var/log/syslog and /var/log/messages so
we're actually breaking this instead of fixing.

As mentioned earlier /sbin/apparmor_parser should work through
symlink as well.

Also as mentioned earlier subdomain_parser, logprof, genprof are
legacy cruft and can be ignored.

cardmgr is something pcmcia related. IIRC pcmcia tools were dropped
from Arch some time ago. I think no repo or AUR package provides
cardmgr. I checked that it don't even exist in debian stable. It can be
ignored.

killall5 - again it doesn't exist in Arch.

There are no other differences so in conclusion I think it's safe for us to
leave logprof.conf untouched.

Thanks for all the feedback!
Best,
David
--

I also recommend to backport upstram 'binmerge' patch rather than using
custom sed rules as it will further reduce our diff and bring us as close to
upstream as we can get. I prepared PKGBUILD in case you're interested

BTW: every interaction with PKGBUILD spits:

find: ‘etc/apparmor.d/’: No such file or directory

which probably come from:

https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/apparmor#n104

I don't know if it can be fixed somehow.

Yours sincerely

G. K.

[David Runge]

Post by Geo Kozey via arch-general
There are no other differences so in conclusion I think it's safe for us to
leave logprof.conf untouched.

That's good then! :)

Post by Geo Kozey via arch-general
I also recommend to backport upstram 'binmerge' patch rather than using
custom sed rules as it will further reduce our diff and bring us as close to
upstream as we can get. I prepared PKGBUILD in case you're interested

Thanks for the feedback! I added many of the changes in 2.13.0-8.
Feel free to test and let me know if there's any more changes required.

Post by Geo Kozey via arch-general
find: ‘etc/apparmor.d/’: No such file or directory

Hm, not for me. Are you using devtools to build in a clean chroot
environment?

Best,
David

[Geo Kozey via arch-general]

----------------------------------------
Sent: Thu Sep 27 23:49:16 CEST 2018
Subject: Re: [arch-general] AppArmor support

Post by Geo Kozey via arch-general
find: ‘etc/apparmor.d/’: No such file or directory

Hm, not for me. Are you using devtools to build in a clean chroot
environment?
Best,
David
--

Yes, but I think it occurs before actual chrooting:

$ extra-x86_64-build -- -T -l /var/build/chroot
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
:: Starting full system upgrade...
there is nothing to do
==> Building in chroot for [extra] (x86_64)...
==> Synchronizing chroot copy [/var/lib/archbuild/extra-x86_64/root] -> [/var/build/chroot]...done
find: 'etc/apparmor.d/': No such file or directory
==> Making package: apparmor 2.13.0-8
==> Retrieving sources...
-> Found apparmor-2.13.tar.gz
-> Found apparmor-2.13.tar.gz.asc
-> Found binmerge.patch
==> Validating source files with sha512sums...


Maybe it's something specific to my system, no idea.

Other than that everything looks good to me. Great job!

Yours sincerely

G. K.

[Eli Schwartz via arch-general]

Post by Geo Kozey via arch-general

----------------------------------------
Sent: Thu Sep 27 23:49:16 CEST 2018
Subject: Re: [arch-general] AppArmor support

Post by Geo Kozey via arch-general
find: ‘etc/apparmor.d/’: No such file or directory

Hm, not for me. Are you using devtools to build in a clean chroot
environment?
Best,
David
--

$ extra-x86_64-build -- -T -l /var/build/chroot
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
:: Starting full system upgrade...
there is nothing to do
==> Building in chroot for [extra] (x86_64)...
==> Synchronizing chroot copy [/var/lib/archbuild/extra-x86_64/root] -> [/var/build/chroot]...done
find: 'etc/apparmor.d/': No such file or directory
==> Making package: apparmor 2.13.0-8
==> Retrieving sources...
-> Found apparmor-2.13.tar.gz
-> Found apparmor-2.13.tar.gz.asc
-> Found binmerge.patch
==> Validating source files with sha512sums...
Maybe it's something specific to my system, no idea.
Other than that everything looks good to me. Great job!
Yours sincerely

That happens because the PKGBUILD dynamically re-evaluates the contents
of the "backup" metadata variable, and lint_pkgbuild attempts to
recalculate this but fails because it only works *during* package.

I mentioned this on IRC, I believe...

This means the resulting output is rather confusing when running makepkg
without an existing "etc" directory next to the PKGBUILD... which due to
https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/apparmor&id=0cc1589dcb541f3a4b5f45e860dbf04109f3d65e
will always be true.

A workaround for this is to delay evaluation by using:
mapfile -td '' -O "${#backup[@]}" backup < <(find ... -print0)

since the internal extract_function_variable() makepkg function does not
detect this (it only handles direct foo=var or foo+=var assignments).

Alternatively, one could play with find "${startpoint}" -path
"${startpoint}/etc/apparmor.d/*" -printf '%P\n' which will successfully
run during lint_pkgbuild and --printsrcinfo, but will still print errors
if startpoint is unreadable (if that's pkgdir, it probably will be?),
doesn't properly handle paths with spaces or newlines in them, and also
spends a lot of time searching the whole directory tree instead of only
searching the given subpath.

I favor option one. :)

Also, PKGBUILDs with complex metadata assignments are annoying to do
correctly, which is probably a reminder that we should all strive to
avoid them!

*glares at https://bugs.archlinux.org/task/58776 and sighs*

[Maciek Borzecki via arch-general]

Post by David Runge

Post by Leonid Isaev via arch-general

Post by David Runge
FYI,
I'm currently working on bringing the user space tools to [community], but
the rule sets will require testing and possibly we'll even have to have our
own set shipped with the package.
I'll let you know asap.

Thanks and pls take your time. I have a VM that runs linux-hardened and is used
to study malicious pdf files. I can test rulesets there...

It is now in [community-testing]. Feel free to comment and suggest
improvements!

That's some great news. Big thanks to everyone involved. I'm looking
forward to making use of it in snapd.

Cheers,

[Geo Kozey via arch-general]

----------------------------------------
Sent: Sun Sep 09 22:19:37 CEST 2018
Subject: Re: [arch-general] AppArmor support
FYI,
I'm currently working on bringing the user space tools to [community], but the rule sets will require testing and possibly we'll even have to have our own set shipped with the package.
I'll let you know asap.
As a side note: As Eli already pointed out there is no need for personal attacks because of a discussion on this topic. We'll try to make this ship sail, but it needs time (and testing).
Best,
David

Do you mean AppArmor user space tools? The AUR package works well with sed rules:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=apparmor#n49

The next AppArmor userspace tools will have full usrmerge support so above won't be needed:
https://gitlab.com/apparmor/apparmor/commit/4200932d8fb31cc3782d96dd8312511e807fd09b

Any Arch specific rules should be sent upstream.

Yours sincerely

G. K.

[Geo Kozey via arch-general]

----------------------------------------
Sent: Sun Sep 09 22:00:03 CEST 2018
Subject: Re: [arch-general] AppArmor support
FWIW, I actually agree with #59733: CONFIG_AUDIT=n was blocking AppArmor
https://lists.debian.org/debian-devel/2017/08/msg00090.html .
But I have a question: why was AUDIT enabled in the first place? I thought it
was cosidered useless?
Cheers,
L.
--
Leonid Isaev

What do you mean by useless? It works pretty normal.
Yours sincerely

G. K.

[Gus]

Post by Leonid Isaev via arch-general
But I have a question: why was AUDIT enabled in the first place? I thought it
was cosidered useless?

AFAIK, it was considered slow (at least for syscalls), but after recent
changes
in kernel it doesn't matter anymore.

You can read discussion here https://bugs.archlinux.org/task/42954

[Eli Schwartz via arch-general]

Post by Leonid Isaev via arch-general
FWIW, I actually agree with #59733: CONFIG_AUDIT=n was blocking AppArmor
https://lists.debian.org/debian-devel/2017/08/msg00090.html .
But I have a question: why was AUDIT enabled in the first place? I thought it
was cosidered useless?

It is definitely not useless! It's historically been disabled because it
did not have any good way to enable support, but keep it turned off by
default. And having it turned on by default came with mandatory
slowdowns for *all* users.

Ironically, Spectre has proven to be our friend here -- due to all the
mitigations, there is now no fast path for these system calls, so your
kernel is just as slow whether AUDIT is enabled or not. Therefore, we
ended up simply enabling it.

See https://bugs.archlinux.org/task/42954 for more background.

[Leonid Isaev via arch-general]

Post by Eli Schwartz via arch-general

Post by Leonid Isaev via arch-general
FWIW, I actually agree with #59733: CONFIG_AUDIT=n was blocking AppArmor
https://lists.debian.org/debian-devel/2017/08/msg00090.html .
But I have a question: why was AUDIT enabled in the first place? I thought it
was cosidered useless?

It is definitely not useless! It's historically been disabled because it
did not have any good way to enable support, but keep it turned off by
default. And having it turned on by default came with mandatory
slowdowns for *all* users.
Ironically, Spectre has proven to be our friend here -- due to all the
mitigations, there is now no fast path for these system calls, so your
kernel is just as slow whether AUDIT is enabled or not. Therefore, we
ended up simply enabling it.

Good to know. I remember arguments like "audit is primarily necessary for
selinux that we don't have... Otherwise it just spams logs". In any case,
audit=0 is the way to go for me.

Cheers,
L.

[Michal Soltys]

Post by Eli Schwartz via arch-general
It is definitely not useless! It's historically been disabled because it
did not have any good way to enable support, but keep it turned off by
default. And having it turned on by default came with mandatory
slowdowns for *all* users.
Ironically, Spectre has proven to be our friend here -- due to all the
mitigations, there is now no fast path for these system calls, so your
kernel is just as slow whether AUDIT is enabled or not. Therefore, we
ended up simply enabling it.

That's not precisely like that - spectre & friends workarounds can be
trivially disabled (e.g.: pti, spectre_v2, spec_store_bypass_disable,
l1tf) - bringing "old" nominal performance back (whether good/bad idea,
that of course depends on what/how you run your linux on for what
purpose). Not mentioning cpus that will eventually come not needing
those workarounds.

So in this context audit=0 is a very viable thing - if one (and that's
probalby crushing majority of users) doesn't need this feature (directly
or indirectly).

[Eli Schwartz via arch-general]

Post by Michal Soltys
That's not precisely like that - spectre & friends workarounds can be
trivially disabled (e.g.: pti, spectre_v2, spec_store_bypass_disable,
l1tf) - bringing "old" nominal performance back (whether good/bad idea,
that of course depends on what/how you run your linux on for what
purpose). Not mentioning cpus that will eventually come not needing
those workarounds.
So in this context audit=0 is a very viable thing - if one (and that's
probalby crushing majority of users) doesn't need this feature (directly
or indirectly).

Even if you disable the mitigations, the fast path we're talking about
here was simply deleted from linux.git -- it doesn't exist anymore,
zero, zilch, squat, nada.

[Gus]

It was accepted first [1], and then rejected for reasons that doesn't
apply
fully to AppArmor, and i doesn't hid anything, so stop playing
detective.
Like Scimmia said "There are better mediums to have this discussion."
and
for such discussions we have this mailing list, doesn't we?

[1]
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=c75a915313f72924fa0a3ed45356f9e0ea488f3b

Post by Maksim Fomin via arch-general
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Post by Gus

Post by Maksim Fomin via arch-general
You have been rejected by heftig and tpowa. It is unclear why and what
you are asking here.

It was accepted first and then rejected by heftig.

Really? Just rejected by heftig? The issue was rejected 4 times, first
2018-09-03
"A Project Manager has denied the request pending for the following
task: FS#59733 - [linux] enable AppArmor & SELinux User who did this -
2018-09-05
"FS#59733 - [linux] enable AppArmor & SELinux User who did this - Doug
Newgard (Scimmia) Reason for denial: No new information"
"FS#59733 - [linux] enable AppArmor & SELinux User who did this - Doug
Newgard (Scimmia) Reason for denial: I'm not going to reopen a ticket
for people to make the same argument over and over"
"Reason for denial: Stop having a catfight with the bugwranglers
because you think, somehow, that people will be less likely to open
duplicate bugs just because we provide dialog. There are better
mediums to have this discussion."
So far, this issue was closed by heftig and then 3 times by bug
wrangler. This fact was hidden in the first post to this thread.