AppArmor support

classic Classic list List threaded Threaded
49 messages Options
123
Gus
Reply | Threaded
Open this post in threaded view
|

AppArmor support

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

Re: AppArmor support

arch general mailing list-2
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

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

AppArmor support

arch general mailing list-2
In reply to this post by Gus

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, 9 September 2018 13:42, Gus <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: AppArmor support

arch general mailing list-2
In reply to this post by arch general mailing list-2
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

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

Re: AppArmor support

Gus
In reply to this post by arch general mailing list-2
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
Gus
Reply | Threaded
Open this post in threaded view
|

Re: AppArmor support

Gus
In reply to this post by arch general mailing list-2
> 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.
Reply | Threaded
Open this post in threaded view
|

AppArmor support

arch general mailing list-2
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, 9 September 2018 17:34, Gus <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: AppArmor support

arch general mailing list-2
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


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

Re: AppArmor support

Gus
In reply to this post by arch general mailing list-2
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

On 2018-09-09 18:24, Maksim Fomin via arch-general wrote:

> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, 9 September 2018 17:34, Gus <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: AppArmor support

arch general mailing list-2
In reply to this post by arch general mailing list-2
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
Reply | Threaded
Open this post in threaded view
|

Re: AppArmor support

David Runge
On September 9, 2018 10:00:03 PM GMT+02:00, Leonid Isaev via arch-general <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: AppArmor support

arch general mailing list-2
In reply to this post by Gus
On 9/9/18, Gus <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: AppArmor support

arch general mailing list-2
In reply to this post by David Runge
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
Reply | Threaded
Open this post in threaded view
|

Re: AppArmor support

arch general mailing list-2
In reply to this post by arch general mailing list-2
> ----------------------------------------
> From: Leonid Isaev via arch-general <[hidden email]>
> Sent: Sun Sep 09 22:00:03 CEST 2018
> To: <[hidden email]>
> Cc: Leonid Isaev <[hidden email]>
> 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.
Gus
Reply | Threaded
Open this post in threaded view
|

Re: AppArmor support

Gus
In reply to this post by arch general mailing list-2
> 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
Reply | Threaded
Open this post in threaded view
|

Re: AppArmor support

arch general mailing list-2
In reply to this post by arch general mailing list-2
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


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

Re: AppArmor support

arch general mailing list-2
In reply to this post by David Runge
> ----------------------------------------
> From: David Runge <[hidden email]>
> Sent: Sun Sep 09 22:19:37 CEST 2018
> To: <[hidden email]>, General Discussion about Arch Linux <[hidden email]>, Leonid Isaev via arch-general <[hidden email]>, <[hidden email]>
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: AppArmor support

arch general mailing list-2
In reply to this post by arch general mailing list-2
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
Reply | Threaded
Open this post in threaded view
|

Re: AppArmor support

arch general mailing list-2
In reply to this post by arch general mailing list-2
On 9/9/18 10:26 PM, Carsten Mattner via arch-general wrote:

> On 9/9/18, Gus <[hidden email]> 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


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

Re: AppArmor support

arch general mailing list-2
On 9/10/18, Levente Polyak via arch-general <[hidden email]> 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......
123