[arch-general] AppArmor support
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?
On Sun, 2018-09-09 at 13:42 +0000, Gus wrote:
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
On Sun, 2018-09-09 at 15:04 +0100, Filipe Laíns via arch-general wrote:
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
Linux-hardened doesn't support hibernation and i think it's overkill to use it on desktop. On 2018-09-09 14:04, Filipe Laíns via arch-general wrote:
On Sun, 2018-09-09 at 13:42 +0000, Gus wrote:
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
On 9/9/18, Gus <qty@airmail.cc> wrote:
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.
On 9/9/18 10:26 PM, Carsten Mattner via arch-general wrote:
On 9/9/18, Gus <qty@airmail.cc> wrote:
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.
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
On 9/10/18, Levente Polyak via arch-general <arch-general@archlinux.org> wrote:
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.
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.
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.
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.
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......
On 9/10/18 1:43 PM, Carsten Mattner wrote:
On 9/10/18, Levente Polyak via arch-general <arch-general@archlinux.org> wrote:
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.
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
On 9/10/18, Levente Polyak via arch-general <arch-general@archlinux.org> wrote:
On 9/10/18 1:43 PM, Carsten Mattner wrote:
On 9/10/18, Levente Polyak via arch-general <arch-general@archlinux.org> wrote:
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.
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 :).
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.
---------------------------------------- From: Levente Polyak via arch-general <arch-general@archlinux.org> Sent: Mon Sep 10 14:09:06 CEST 2018 To: General Discussion about Arch Linux <arch-general@archlinux.org> Cc: Levente Polyak <anthraxx@archlinux.org> 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.
On 9/10/18 5:58 PM, Geo Kozey wrote:
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
---------------------------------------- From: Levente Polyak <anthraxx@archlinux.org> Sent: Mon Sep 10 18:42:14 CEST 2018 To: Geo Kozey <geokozey@mailfence.com> Cc: General Discussion about Arch Linux <arch-general@archlinux.org> 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.
On 9/10/18 7:31 PM, Geo Kozey wrote:
---------------------------------------- From: Levente Polyak <anthraxx@archlinux.org> Sent: Mon Sep 10 18:42:14 CEST 2018 To: Geo Kozey <geokozey@mailfence.com> Cc: General Discussion about Arch Linux <arch-general@archlinux.org> 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
Am 10.09.18 um 20:06 schrieb 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
On 9/10/18, Geo Kozey via arch-general <arch-general@archlinux.org> wrote:
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?
---------------------------------------- From: Carsten Mattner <carstenmattner@gmail.com> Sent: Mon Sep 10 20:07:23 CEST 2018 To: Geo Kozey <geokozey@mailfence.com>, General Discussion about Arch Linux <arch-general@archlinux.org> Cc: Levente Polyak <anthraxx@archlinux.org> Subject: Re: [arch-general] AppArmor support
On 9/10/18, Geo Kozey via arch-general <arch-general@archlinux.org> wrote:
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.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, 9 September 2018 13:42, Gus <qty@airmail.cc> wrote:
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.
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.
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.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, 9 September 2018 17:34, Gus <qty@airmail.cc> wrote:
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.
On 9/9/18 2:24 PM, Maksim Fomin via arch-general wrote:
Really? Just rejected by heftig? The issue was rejected 4 times, first by heftig than 3 times by Scimmia: 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
On Sun, Sep 09, 2018 at 02:53:04PM -0400, Eli Schwartz via arch-general wrote:
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
On September 9, 2018 10:00:03 PM GMT+02:00, Leonid Isaev via arch-general <arch-general@archlinux.org> wrote:
On Sun, Sep 09, 2018 at 02:53:04PM -0400, Eli Schwartz via arch-general wrote:
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.
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
On Sun, Sep 09, 2018 at 10:19:37PM +0200, David Runge wrote:
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
On 2018-09-09 14:46:21 (-0600), Leonid Isaev via arch-general wrote:
On Sun, Sep 09, 2018 at 10:19:37PM +0200, David Runge wrote:
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
---------------------------------------- From: David Runge <dave@sleepmap.de> Sent: Thu Sep 13 19:51:49 CEST 2018 To: General Discussion about Arch Linux <arch-general@archlinux.org> 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=packa... [1] https://gitlab.com/apparmor/apparmor/wikis/Release_Notes_2.13.1 [2] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packa... Yours sincerely G. K.
On 2018-09-13 20:52:23 (+0200), Geo Kozey wrote:
---------------------------------------- From: David Runge <dave@sleepmap.de> Sent: Thu Sep 13 19:51:49 CEST 2018 To: General Discussion about Arch Linux <arch-general@archlinux.org> 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.
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
---------------------------------------- From: David Runge <dave@sleepmap.de> Sent: Fri Sep 14 11:24:09 CEST 2018 To: Geo Kozey <geokozey@mailfence.com> Cc: General Discussion about Arch Linux <arch-general@archlinux.org> Subject: Re: [arch-general] AppArmor support
On 2018-09-13 20:52:23 (+0200), Geo Kozey wrote:
---------------------------------------- From: David Runge <dave@sleepmap.de> Sent: Thu Sep 13 19:51:49 CEST 2018 To: General Discussion about Arch Linux <arch-general@archlinux.org> 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.
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/4200932d8fb31cc3782d96dd8312511e... 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.
On 2018-09-14 12:21:26 (+0200), Geo Kozey wrote:
They called it 'binmerge' :) Hope this can be achieved for all profiles.
https://gitlab.com/apparmor/apparmor/commit/4200932d8fb31cc3782d96dd8312511e...
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 ;-)
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
---------------------------------------- From: David Runge <dave@sleepmap.de> Sent: Thu Sep 20 20:42:08 CEST 2018 To: Geo Kozey <geokozey@mailfence.com> Cc: General Discussion about Arch Linux <arch-general@archlinux.org> Subject: Re: [arch-general] AppArmor support
On 2018-09-14 12:21:26 (+0200), Geo Kozey wrote:
They called it 'binmerge' :) Hope this can be achieved for all profiles.
https://gitlab.com/apparmor/apparmor/commit/4200932d8fb31cc3782d96dd8312511e...
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 ;-)
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/4200932d8fb31cc3782d96dd8312511e... 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/d9d3cae2aaf272e2039d6f9113ab59d4... Yours sincerely G. K.
On 2018-09-20 18:42, David Runge wrote:
On 2018-09-14 12:21:26 (+0200), Geo Kozey wrote:
They called it 'binmerge' :) Hope this can be achieved for all profiles.
https://gitlab.com/apparmor/apparmor/commit/4200932d8fb31cc3782d96dd8312511e...
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 ;-)
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?
On 2018-09-21 10:53:33 (+0000), Gus wrote:
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! -- https://sleepmap.de
---------------------------------------- From: David Runge <dave@sleepmap.de> Sent: Fri Sep 21 20:41:15 CEST 2018 To: General Discussion about Arch Linux <arch-general@archlinux.org> Subject: Re: [arch-general] AppArmor support
On 2018-09-21 10:53:33 (+0000), Gus wrote:
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/app... Yours sincerely G. K.
Hi Geo, On 2018-09-22 15:13:20 (+0200), Geo Kozey wrote:
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/app... 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 -- https://sleepmap.de
---------------------------------------- From: David Runge <dave@sleepmap.de> Sent: Sat Sep 22 17:43:51 CEST 2018 To: Geo Kozey <geokozey@mailfence.com> Cc: General Discussion about Arch Linux <arch-general@archlinux.org> Subject: Re: [arch-general] AppArmor support
Hi Geo,
On 2018-09-22 15:13:20 (+0200), Geo Kozey wrote:
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/app... 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.
---------------------------------------- From: Geo Kozey via arch-general <arch-general@archlinux.org> Sent: Sat Sep 22 18:23:58 CEST 2018 To: David Runge <dave@sleepmap.de> Cc: Geo Kozey <geokozey@mailfence.com>, General Discussion about Arch Linux <arch-general@archlinux.org> Subject: Re: [arch-general] AppArmor support
---------------------------------------- From: David Runge <dave@sleepmap.de> Sent: Sat Sep 22 17:43:51 CEST 2018 To: Geo Kozey <geokozey@mailfence.com> Cc: General Discussion about Arch Linux <arch-general@archlinux.org> Subject: Re: [arch-general] AppArmor support
Hi Geo,
On 2018-09-22 15:13:20 (+0200), Geo Kozey wrote:
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/app... 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.
On 2018-09-22 18:38:14 (+0200), Geo Kozey wrote:
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!
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.
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.
Also there aren't such things like: Yeah, I figured.
/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
/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...
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 -- https://sleepmap.de
---------------------------------------- From: David Runge <dave@sleepmap.de> Sent: Sat Sep 22 21:43:20 CEST 2018 To: Geo Kozey <geokozey@mailfence.com> Cc: General Discussion about Arch Linux <arch-general@archlinux.org> Subject: Re: [arch-general] AppArmor support
On 2018-09-22 18:38:14 (+0200), Geo Kozey wrote:
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!
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.
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.
Also there aren't such things like: Yeah, I figured.
/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.
/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.
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=packa... I don't know if it can be fixed somehow. Yours sincerely G. K.
On 2018-09-23 11:56:11 (+0200), Geo Kozey wrote:
There are no other differences so in conclusion I think it's safe for us to leave logprof.conf untouched. That's good then! :)
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.
BTW: every interaction with PKGBUILD spits:
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 -- https://sleepmap.de
---------------------------------------- From: David Runge <dave@sleepmap.de> Sent: Thu Sep 27 23:49:16 CEST 2018 To: Geo Kozey <geokozey@mailfence.com> Cc: General Discussion about Arch Linux <arch-general@archlinux.org> Subject: Re: [arch-general] AppArmor support
BTW: every interaction with PKGBUILD spits:
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.
On 9/28/18 9:36 AM, Geo Kozey via arch-general wrote:
---------------------------------------- From: David Runge <dave@sleepmap.de> Sent: Thu Sep 27 23:49:16 CEST 2018 To: Geo Kozey <geokozey@mailfence.com> Cc: General Discussion about Arch Linux <arch-general@archlinux.org> Subject: Re: [arch-general] AppArmor support
BTW: every interaction with PKGBUILD spits:
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
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/app... 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* -- Eli Schwartz Bug Wrangler and Trusted User
On Thu, Sep 13, 2018 at 7:51 PM, David Runge <dave@sleepmap.de> wrote:
On 2018-09-09 14:46:21 (-0600), Leonid Isaev via arch-general wrote:
On Sun, Sep 09, 2018 at 10:19:37PM +0200, David Runge wrote:
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
---------------------------------------- From: David Runge <dave@sleepmap.de> Sent: Sun Sep 09 22:19:37 CEST 2018 To: <leonid.isaev@jila.colorado.edu>, General Discussion about Arch Linux <arch-general@archlinux.org>, Leonid Isaev via arch-general <arch-general@archlinux.org>, <arch-general@archlinux.org> 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/4200932d8fb31cc3782d96dd8312511e... Any Arch specific rules should be sent upstream. Yours sincerely G. K.
---------------------------------------- From: Leonid Isaev via arch-general <arch-general@archlinux.org> Sent: Sun Sep 09 22:00:03 CEST 2018 To: <arch-general@archlinux.org> Cc: Leonid Isaev <leonid.isaev@jila.colorado.edu> Subject: Re: [arch-general] AppArmor support
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
What do you mean by useless? It works pretty normal. Yours sincerely G. K.
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
On 9/9/18 4:00 PM, Leonid Isaev via arch-general wrote:
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?
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
On Sun, Sep 09, 2018 at 06:13:24PM -0400, Eli Schwartz via arch-general wrote:
On 9/9/18 4:00 PM, Leonid Isaev via arch-general wrote:
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?
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
On 2018-09-10 00:13, Eli Schwartz via arch-general wrote:
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).
On 9/27/18 8:28 PM, Michal Soltys wrote:
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. -- Eli Schwartz Bug Wrangler and Trusted User
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/linu... On 2018-09-09 18:24, Maksim Fomin via arch-general wrote:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, 9 September 2018 17:34, Gus <qty@airmail.cc> wrote:
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.
participants (12)
-
Carsten Mattner
-
David Runge
-
Eli Schwartz
-
Filipe Laíns
-
Geo Kozey
-
Gus
-
Leonid Isaev
-
Levente Polyak
-
Maciek Borzecki
-
Maksim Fomin
-
Michal Soltys
-
ProgAndy