Discussion:
AppArmor support
Add Reply
Gus
2018-09-09 13:42:08 UTC
Reply
Permalink
Raw Message
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
2018-09-09 14:04:48 UTC
Reply
Permalink
Raw 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?
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
2018-09-09 14:37:09 UTC
Reply
Permalink
Raw Message
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
2018-09-09 17:31:59 UTC
Reply
Permalink
Raw Message
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
2018-09-09 20:26:19 UTC
Reply
Permalink
Raw Message
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
2018-09-10 10:35:07 UTC
Reply
Permalink
Raw Message
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
2018-09-10 11:43:12 UTC
Reply
Permalink
Raw Message
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
2018-09-10 12:09:06 UTC
Reply
Permalink
Raw Message
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
2018-09-10 12:19:36 UTC
Reply
Permalink
Raw Message
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
2018-09-10 15:58:49 UTC
Reply
Permalink
Raw Message
----------------------------------------
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
2018-09-10 16:42:14 UTC
Reply
Permalink
Raw Message
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
2018-09-10 17:31:36 UTC
Reply
Permalink
Raw Message
----------------------------------------
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
2018-09-10 18:06:33 UTC
Reply
Permalink
Raw Message
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
2018-09-10 18:20:51 UTC
Reply
Permalink
Raw Message
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
2018-09-10 18:07:23 UTC
Reply
Permalink
Raw Message
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
2018-09-10 18:26:35 UTC
Reply
Permalink
Raw Message
----------------------------------------
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
2018-09-09 14:23:09 UTC
Reply
Permalink
Raw Message
‐‐‐‐‐‐‐ 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
2018-09-09 17:34:20 UTC
Reply
Permalink
Raw Message
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
2018-09-09 18:24:58 UTC
Reply
Permalink
Raw Message
‐‐‐‐‐‐‐ 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
2018-09-09 18:53:04 UTC
Reply
Permalink
Raw Message
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. :)
--
Eli Schwartz
Bug Wrangler and Trusted User
Leonid Isaev via arch-general
2018-09-09 20:00:03 UTC
Reply
Permalink
Raw Message
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.
--
Leonid Isaev
David Runge
2018-09-09 20:19:37 UTC
Reply
Permalink
Raw Message
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
--
https://sleepmap.de
Leonid Isaev via arch-general
2018-09-09 20:46:21 UTC
Reply
Permalink
Raw Message
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.
--
Leonid Isaev
David Runge
2018-09-13 17:51:49 UTC
Reply
Permalink
Raw Message
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
--
https://sleepmap.de
Geo Kozey via arch-general
2018-09-13 18:52:23 UTC
Reply
Permalink
Raw Message
----------------------------------------
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
2018-09-14 09:24:09 UTC
Reply
Permalink
Raw Message
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
--
https://sleepmap.de
Geo Kozey via arch-general
2018-09-14 10:21:26 UTC
Reply
Permalink
Raw Message
----------------------------------------
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
2018-09-20 18:42:08 UTC
Reply
Permalink
Raw Message
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
--
https://sleepmap.de
Geo Kozey via arch-general
2018-09-20 18:59:28 UTC
Reply
Permalink
Raw Message
----------------------------------------
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.

Maciek Borzecki via arch-general
2018-09-14 06:42:07 UTC
Reply
Permalink
Raw Message
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,
--
Maciek Borzecki
Geo Kozey via arch-general
2018-09-09 22:13:27 UTC
Reply
Permalink
Raw Message
----------------------------------------
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
2018-09-09 22:02:37 UTC
Reply
Permalink
Raw Message
----------------------------------------
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
2018-09-09 22:08:09 UTC
Reply
Permalink
Raw Message
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
2018-09-09 22:13:24 UTC
Reply
Permalink
Raw Message
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.
--
Eli Schwartz
Bug Wrangler and Trusted User
Leonid Isaev via arch-general
2018-09-09 22:45:34 UTC
Reply
Permalink
Raw Message
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.
--
Leonid Isaev
Gus
2018-09-09 19:01:21 UTC
Reply
Permalink
Raw Message
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.
Loading...