Re: [arch-general] AppArmor support
On 9/28/18 9:36 AM, Geo Kozey via arch-general wrote:
>>
>> From: David Runge
>> Sent: Thu Sep 27 23:49:16 CEST 2018
>> To: Geo Kozey
>> Cc: General Discussion about Arch Linux
>> 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/apparmor=0cc1589dcb541f3a4b5f45e860dbf04109f3d65e
will always be true.
A workaround for this is to delay evaluation by using:
mapfile -td '' -O "${#backup[@]}" backup < <(find ... -print0)
since the internal extract_function_variable() makepkg function does not
detect this (it only handles direct foo=var or foo+=var assignments).
Alternatively, one could play with find "${startpoint}" -path
"${startpoint}/etc/apparmor.d/*" -printf '%P\n' which will successfully
run during lint_pkgbuild and --printsrcinfo, but will still print errors
if startpoint is unreadable (if that's pkgdir, it probably will be?),
doesn't properly handle paths with spaces or newlines in them, and also
spends a lot of time searching the whole directory tree instead of only
searching the given subpath.
I favor option one. :)
Also, PKGBUILDs with complex metadata assignments are annoying to do
correctly, which is probably a reminder that we should all strive to
avoid them!
*glares at https://bugs.archlinux.org/task/58776 and sighs*
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] AppArmor support
> > From: David Runge > Sent: Thu Sep 27 23:49:16 CEST 2018 > To: Geo Kozey > Cc: General Discussion about Arch Linux > 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.
Re: [arch-general] AppArmor support
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 signature.asc Description: OpenPGP digital signature
Re: [arch-general] AppArmor support
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).
Re: [arch-general] AppArmor support
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 signature.asc Description: PGP signature
Re: [arch-general] AppArmor support
>
> From: David Runge
> Sent: Sat Sep 22 21:43:20 CEST 2018
> To: Geo Kozey
> Cc: General Discussion about Arch Linux
> 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=packages/apparmor#n104
I don't know if it can be fixed somehow.
Yours sincerely
G. K.
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
> /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
signature.asc
Description: PGP signature
Re: [arch-general] AppArmor support
> > From: Geo Kozey via arch-general > Sent: Sat Sep 22 18:23:58 CEST 2018 > To: David Runge > Cc: Geo Kozey , General Discussion about Arch Linux > > Subject: Re: [arch-general] AppArmor support > > > > > > From: David Runge > > Sent: Sat Sep 22 17:43:51 CEST 2018 > > To: Geo Kozey > > Cc: General Discussion about Arch Linux > > 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/apparmor=4dc153bf8e26239a55409ac5d1994f6575e057c5 > > Thanks for the info! > > That was indeed a problem, but not because of the profile modifications. > > I did way too broad replacements in logprof.conf, that led to the > > duplicate entries you are experiencing (as there are entries for /bin > > and /usr/bin for most binaries). > > > > I have now fixed this in 2.13.0-6 (by carefully only replacing the use > > of sbin where needed). Please let me know, if this works as intended for > > you! > > > > Best, > > David > > > > -- > > It's almost there ;) > > '/usr/bin/subdomain_parser' under [qualifiers] is still duplicated. > > I'm not sure if 'apparmor_parser' and 'subdomain_parser' under [settings] > have to be modified. IMO they should work as symlinks too. > > BTW: users transition from AUR may be complicated as now apparmor > package will contain files available in apparmor-* split packages before. > Maybe you have to add 'replaces=' for split packages. > > Yours sincerely > > G. K. Also there aren't such things like: /usr/bin/subdomain_parser /usr/bin/logprof /usr/bin/genprof in Arch anyway so creating them isn't necessary. Perhaps if there is anything left to change in [qualifiers] section, it can be upstreamed as well. Yours sincerely G. K.
Re: [arch-general] AppArmor support
> > From: David Runge > Sent: Sat Sep 22 17:43:51 CEST 2018 > To: Geo Kozey > Cc: General Discussion about Arch Linux > 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/apparmor=4dc153bf8e26239a55409ac5d1994f6575e057c5 > Thanks for the info! > That was indeed a problem, but not because of the profile modifications. > I did way too broad replacements in logprof.conf, that led to the > duplicate entries you are experiencing (as there are entries for /bin > and /usr/bin for most binaries). > > I have now fixed this in 2.13.0-6 (by carefully only replacing the use > of sbin where needed). Please let me know, if this works as intended for > you! > > Best, > David > > -- It's almost there ;) '/usr/bin/subdomain_parser' under [qualifiers] is still duplicated. I'm not sure if 'apparmor_parser' and 'subdomain_parser' under [settings] have to be modified. IMO they should work as symlinks too. BTW: users transition from AUR may be complicated as now apparmor package will contain files available in apparmor-* split packages before. Maybe you have to add 'replaces=' for split packages. Yours sincerely G. K.
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/apparmor=4dc153bf8e26239a55409ac5d1994f6575e057c5 Thanks for the info! That was indeed a problem, but not because of the profile modifications. I did way too broad replacements in logprof.conf, that led to the duplicate entries you are experiencing (as there are entries for /bin and /usr/bin for most binaries). I have now fixed this in 2.13.0-6 (by carefully only replacing the use of sbin where needed). Please let me know, if this works as intended for you! Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-general] AppArmor support
> > From: David Runge > Sent: Fri Sep 21 20:41:15 CEST 2018 > To: General Discussion about Arch Linux > Subject: Re: [arch-general] AppArmor support > > > On 2018-09-21 10:53:33 (+), 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/apparmor=4dc153bf8e26239a55409ac5d1994f6575e057c5 Yours sincerely G. K.
Re: [arch-general] AppArmor support
On 2018-09-21 10:53:33 (+), 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 signature.asc Description: PGP signature
Re: [arch-general] AppArmor support
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/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 ;-) 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?
Re: [arch-general] AppArmor support
> > From: David Runge > Sent: Thu Sep 20 20:42:08 CEST 2018 > To: Geo Kozey > Cc: General Discussion about Arch Linux > 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/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 ;-) > > > 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.
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/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 ;-) > 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 signature.asc Description: PGP signature
Re: [arch-general] AppArmor support
> > From: David Runge > Sent: Fri Sep 14 11:24:09 CEST 2018 > To: Geo Kozey > Cc: General Discussion about Arch Linux > Subject: Re: [arch-general] AppArmor support > > > On 2018-09-13 20:52:23 (+0200), Geo Kozey wrote: > > > > > > From: David Runge > > > Sent: Thu Sep 13 19:51:49 CEST 2018 > > > To: General Discussion about Arch Linux > > > 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/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.
Re: [arch-general] AppArmor support
On 2018-09-13 20:52:23 (+0200), Geo Kozey wrote: > > > > From: David Runge > > Sent: Thu Sep 13 19:51:49 CEST 2018 > > To: General Discussion about Arch Linux > > 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 signature.asc Description: PGP signature
Re: [arch-general] AppArmor support
On Thu, Sep 13, 2018 at 7:51 PM, David Runge 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
Re: [arch-general] AppArmor support
> > From: David Runge > Sent: Thu Sep 13 19:51:49 CEST 2018 > To: General Discussion about Arch Linux > 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.
Re: [arch-general] AppArmor support
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 signature.asc Description: PGP signature
Re: [arch-general] AppArmor support
> > From: Carsten Mattner > Sent: Mon Sep 10 20:07:23 CEST 2018 > To: Geo Kozey , General Discussion about Arch Linux > > Cc: Levente Polyak > Subject: Re: [arch-general] AppArmor support > > > On 9/10/18, Geo Kozey via arch-general 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.
Re: [arch-general] AppArmor support
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
Re: [arch-general] AppArmor support
On 9/10/18, Geo Kozey via arch-general 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?
Re: [arch-general] AppArmor support
On 9/10/18 7:31 PM, Geo Kozey wrote: >> >> From: Levente Polyak >> Sent: Mon Sep 10 18:42:14 CEST 2018 >> To: Geo Kozey >> Cc: General Discussion about Arch Linux >> 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 signature.asc Description: OpenPGP digital signature
Re: [arch-general] AppArmor support
> > From: Levente Polyak > Sent: Mon Sep 10 18:42:14 CEST 2018 > To: Geo Kozey > Cc: General Discussion about Arch Linux > 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.
Re: [arch-general] AppArmor support
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 signature.asc Description: OpenPGP digital signature
Re: [arch-general] AppArmor support
> > From: Levente Polyak via arch-general > Sent: Mon Sep 10 14:09:06 CEST 2018 > To: General Discussion about Arch Linux > Cc: Levente Polyak > 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.
Re: [arch-general] AppArmor support
On 9/10/18 1:43 PM, Carsten Mattner wrote: > On 9/10/18, Levente Polyak via arch-general > 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 signature.asc Description: OpenPGP digital signature
Re: [arch-general] AppArmor support
On 9/10/18, Levente Polyak via arch-general 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..
Re: [arch-general] AppArmor support
On 9/9/18 10:26 PM, Carsten Mattner via arch-general wrote: > On 9/9/18, Gus 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 Description: OpenPGP digital signature
Re: [arch-general] AppArmor support
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
Re: [arch-general] AppArmor support
> > From: David Runge > Sent: Sun Sep 09 22:19:37 CEST 2018 > To: , General Discussion about Arch Linux > , Leonid Isaev via arch-general > , > 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.
Re: [arch-general] AppArmor support
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 Description: OpenPGP digital signature
Re: [arch-general] AppArmor support
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
Re: [arch-general] AppArmor support
> > From: Leonid Isaev via arch-general > Sent: Sun Sep 09 22:00:03 CEST 2018 > To: > Cc: Leonid Isaev > 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.
Re: [arch-general] AppArmor support
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
Re: [arch-general] AppArmor support
On 9/9/18, Gus 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.
Re: [arch-general] AppArmor support
On September 9, 2018 10:00:03 PM GMT+02:00, Leonid Isaev via arch-general 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
Re: [arch-general] AppArmor support
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
Re: [arch-general] AppArmor support
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=c75a915313f72924fa0a3ed45356f9e0ea488f3b On 2018-09-09 18:24, Maksim Fomin via arch-general wrote: ‐‐‐ Original Message ‐‐‐ On Sunday, 9 September 2018 17:34, Gus 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.
Re: [arch-general] AppArmor support
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 Description: OpenPGP digital signature
[arch-general] AppArmor support
‐‐‐ Original Message ‐‐‐ On Sunday, 9 September 2018 17:34, Gus 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.
Re: [arch-general] AppArmor support
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.
Re: [arch-general] AppArmor support
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 +, 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
[arch-general] AppArmor support
‐‐‐ Original Message ‐‐‐ On Sunday, 9 September 2018 13:42, 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? 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.
Re: [arch-general] AppArmor support
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 Description: This is a digitally signed message part
Re: [arch-general] AppArmor support
On Sun, 2018-09-09 at 13:42 +, 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 Description: This is a digitally signed message part
[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?
