[arch-dev-public] providing grsecurity in [community]
There has been a recent surge of interest in securing Arch by paying closer attention to CVEs and addressing many security issues in our packages. I also started some initial work/documenting on securing the services shipped in various packages: https://wiki.archlinux.org/index.php/DeveloperWiki:Service_isolation To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system. This would be the first case of an alternative kernel in the repositories, so I'm open to discussion about whether it's appropriate to do this. There are also some issues relevant to other packages in the repositories. The grsecurity project has been around since 2001 and has fundamentally different goals than the mainline Linux project. Much like OpenBSD, it makes changes with a measurable performance or compatibility impact that are unlikely to ever be included in the upstream kernel. Many of these changes involve hardening the kernel against userspace exploitation, which is not something tackled by any of the Linux Security Modules. Users, groups, ACLs, chroots and namespaces already provide a solid foundation for access control, so hardening the kernel itself is the single biggest security improvement involved. It has various odds and ends exposed via sysctl switches, and these tend to trickle upstream in one form or another (symlink/hardlink protection, dmesg restriction, /proc restrictions). It also includes the PaX project to provide a much stronger implementation of ASLR along with significant memory protections for userspace. These features do break many packages, and require setting flags on binaries when exceptions are necessary. I don't want to place a burden on other packagers, so I plan on leaving the parts requiring integration with other packages disabled at first. If there turns out to be more interest than just my own in maintaining this, flipping on the PaX protections by default and setting the required flags in various packages could be considered. I don't want to approach this by filing bugs, so there would need to be a developer interested in doing some work on packages in [core] and [extra] for these kinds of features to be enabled. SELinux requires many packages to be built with support for it, along with a significant number of patches. The policies are very complex and spread out through the entire file system. In my opinion, it's pretty much the antithesis of Arch's goals of simplicity and transparent configuration. AppArmor/TOMOYO are much simpler, with centralized policy files that are much easier to review or ship in packages. The grsecurity RBAC system is similar to these and has a nice automatic learning mode. However, it's quite a bit more powerful and grsecurity is useful even without providing RBAC policies since this is only one component. All in all, I think grsecurity would be a great way of improving the level of security we offer. It's also one of the least intrusive ways of doing it, since it can provide significant benefits without everyone buying into it and adding profiles to their packages. There will be no impact on the regular/default kernel, so it's far friendlier to users who don't care about this than SELinux/AppArmor/Audit.
On 16/04/14 14:09, Daniel Micay wrote:
There has been a recent surge of interest in securing Arch by paying closer attention to CVEs and addressing many security issues in our packages. I also started some initial work/documenting on securing the services shipped in various packages:
https://wiki.archlinux.org/index.php/DeveloperWiki:Service_isolation
To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system. This would be the first case of an alternative kernel in the repositories,
It would not be the first case... We specifically got rid of others years ago.
so I'm open to discussion about whether it's appropriate to do this. There are also some issues relevant to other packages in the repositories.
Which packages? We need the details. Allan
On 16/04/14 02:46 AM, Allan McRae wrote:
Which packages? We need the details.
For just the basics (most of PaX disabled), there's no external work required. It would be useful with just the kernel and userland tools in [community] and no extra work done on other packages. Enabling the PaX features requires marking a fairly long list of binaries with exceptions to the rules via the PaX extended attributes in the install scripts. For example, web browsers require memory that's both executable + writable (requiring an mprotect exception) and many programs are broken by stuff like the ASLR improvements due to depending on all kinds of undefined behaviour. The `paxctl` command for this is a 0.06MiB package with a single binary and man page, so the drawback would be the work required rather than any form of dependency bloat. It wouldn't be reasonable to report every case via the issue tracker, someone would actually have to be interested in systematically adding to to [core] and [extra] packages. If you want a nearly full list of the packages, you can look in the linux-pax-flags AUR package, which is a total hack adding the PaX xattrs when the user runs a command. Doing it that way means any upgrades are going to break everything until the user runs the script, so I'm just planning on leaving the features disabled at first. Pacman hooks would be a nicer solution than editing all the install scripts, but we don't have those :).
On 16/04/14 03:15 AM, Daniel Micay wrote:
Pacman hooks would be a nicer solution than editing all the install scripts, but we don't have those :).
It also wouldn't be nearly as bad if packages could store extended attributes, since the ugly install scripts could be avoided and paxctl would only be a make dependency. Packages like iputils already run into this issue due to using capabilities as a replacement for setuid.
On 16/04/14 17:25, Daniel Micay wrote:
On 16/04/14 03:15 AM, Daniel Micay wrote:
Pacman hooks would be a nicer solution than editing all the install scripts, but we don't have those :).
It also wouldn't be nearly as bad if packages could store extended attributes, since the ugly install scripts could be avoided and paxctl would only be a make dependency. Packages like iputils already run into this issue due to using capabilities as a replacement for setuid.
Just submitted a patch to pacman that will allow setting capabilites in the package() function. Allan
Am 16.04.2014 11:52, schrieb Allan McRae:
On 16/04/14 17:25, Daniel Micay wrote:
On 16/04/14 03:15 AM, Daniel Micay wrote:
Pacman hooks would be a nicer solution than editing all the install scripts, but we don't have those :).
It also wouldn't be nearly as bad if packages could store extended attributes, since the ugly install scripts could be avoided and paxctl would only be a make dependency. Packages like iputils already run into this issue due to using capabilities as a replacement for setuid.
Just submitted a patch to pacman that will allow setting capabilites in the package() function.
Since we want PAX support to remain optional, we'd still need hooks so that after each upgrade, a script can adjust the flags appropriately.
On 16/04/14 20:00, Thomas Bächler wrote:
Am 16.04.2014 11:52, schrieb Allan McRae:
On 16/04/14 17:25, Daniel Micay wrote:
On 16/04/14 03:15 AM, Daniel Micay wrote:
Pacman hooks would be a nicer solution than editing all the install scripts, but we don't have those :).
It also wouldn't be nearly as bad if packages could store extended attributes, since the ugly install scripts could be avoided and paxctl would only be a make dependency. Packages like iputils already run into this issue due to using capabilities as a replacement for setuid.
Just submitted a patch to pacman that will allow setting capabilites in the package() function.
Since we want PAX support to remain optional, we'd still need hooks so that after each upgrade, a script can adjust the flags appropriately.
Sure... I really don't care about PAX (and think it should just be packaged in a separate repo...). I just wanted pacman to support setting capabilities during packaging. A
Am 16.04.2014 12:21, schrieb Allan McRae:
Just submitted a patch to pacman that will allow setting capabilites in the package() function.
Since we want PAX support to remain optional, we'd still need hooks so that after each upgrade, a script can adjust the flags appropriately.
Sure... I really don't care about PAX (and think it should just be packaged in a separate repo...). I just wanted pacman to support setting capabilities during packaging.
I am not sure that your patch will work at all due to limitations of fakeroot. I just tested this shortly, and fakeroot supports setting file capabilities using setcap, but not setting ACLs using setfacl. So, support for extended attributes in fakeroot is incomplete at best. A further look indicates that this may simply be stupidity on the side of fakeroot: it explicitly hardcodes ENOTSUP for acl_{s,g}et_f{ile,d}, while the now implemented f{s,g}etxattr support should be sufficient in order to support ACLs entirely. I guess these acl overrides are remnants of the days when xattr support was missing. Anyway, we need to fix fakeroot before this makepkg feature can be useful.
On 16/04/14 21:36, Thomas Bächler wrote:
Am 16.04.2014 12:21, schrieb Allan McRae:
Just submitted a patch to pacman that will allow setting capabilites in the package() function.
Since we want PAX support to remain optional, we'd still need hooks so that after each upgrade, a script can adjust the flags appropriately.
Sure... I really don't care about PAX (and think it should just be packaged in a separate repo...). I just wanted pacman to support setting capabilities during packaging.
I am not sure that your patch will work at all due to limitations of fakeroot. I just tested this shortly, and fakeroot supports setting file capabilities using setcap, but not setting ACLs using setfacl.
So, support for extended attributes in fakeroot is incomplete at best.
A further look indicates that this may simply be stupidity on the side of fakeroot: it explicitly hardcodes ENOTSUP for acl_{s,g}et_f{ile,d}, while the now implemented f{s,g}etxattr support should be sufficient in order to support ACLs entirely. I guess these acl overrides are remnants of the days when xattr support was missing.
Anyway, we need to fix fakeroot before this makepkg feature can be useful.
Getting off-topic... but only one package in our repos uses setfacl (systemd on the journal directory) in its install script, and seven use setcap. Getting the majority case fixed is still worth including this in my opinion. We can deal with get/setfacl when fakeroot does properly. Any chance you can take that upstream? Also, I really thought setcap would be used in more install scripts! A
Am 16.04.2014 14:16, schrieb Allan McRae:
Getting off-topic...
Indeed.
but only one package in our repos uses setfacl (systemd on the journal directory) in its install script, and seven use setcap. Getting the majority case fixed is still worth including this in my opinion. We can deal with get/setfacl when fakeroot does properly. Any chance you can take that upstream?
I don't really have the time now, maybe some time on the weekend. From what I saw quickly, the solution is merely to remove all the function overrides for the acl_* functions from libfakeroot.c. Unless you beat me to it, I'll test this on the weekend.
Also, I really thought setcap would be used in more install scripts!
It becomes really bad when upstream uses it in the Makefile (like systemd does) and the maintainer does not add this it to the .install manually. But indeed, many more setuid binaries should make use of file capabilities instead.
Okay, so I "fixed" the fakeroot to work with ACLs by simply removing all special ACL handling: Index: PKGBUILD =================================================================== --- PKGBUILD (Revision 210798) +++ PKGBUILD (Arbeitskopie) @@ -4,7 +4,7 @@ pkgname=fakeroot pkgver=1.20 -pkgrel=1 +pkgrel=2 pkgdesc="Gives a fake root environment, useful for building packages as a non-privileged user" arch=('i686' 'x86_64') license=('GPL') @@ -15,6 +15,11 @@ source=(http://ftp.debian.org/debian/pool/main/f/${pkgname}/${pkgname}_${pkgver}.orig.tar.bz2) md5sums=('9777a81d4d1878422447a1d0030c1f9f') +prepare() { + cd "${srcdir}/${pkgname}-${pkgver}" + sed 's|^#ifdef HAVE_ACL_T$|#if 0|' -i libfakeroot.c wrapfunc.inp +} + build() { cd "${srcdir}/${pkgname}-${pkgver}" ./configure --prefix=/usr --libdir=/usr/lib/libfakeroot \ With this, fakeroot does everything as expected: # getfattr -d -m - foo # setcap cap_net_admin=p foo # getfattr -d -m - foo # file: foo security.capability=0sAAAAAgAQAAAAAAAAAAAAAAAAAAA= # getcap foo foo = cap_net_admin+p # # getfattr -d -m - bar # setfacl -m u:thomas:rw bar # getfattr -d -m - bar # file: bar system.posix_acl_access=0sAgAAAAEABgD/////AgAGAOgDAAAEAAQA/////xAABgD/////IAAEAP////8= # getfacl bar # file: bar # owner: thomas # group: users user::rw- user:thomas:rw- group::r-- mask::rw- other::r-- Should I push this to testing?
On 16/04/14 06:00 AM, Thomas Bächler wrote:
Am 16.04.2014 11:52, schrieb Allan McRae:
On 16/04/14 17:25, Daniel Micay wrote:
On 16/04/14 03:15 AM, Daniel Micay wrote:
Pacman hooks would be a nicer solution than editing all the install scripts, but we don't have those :).
It also wouldn't be nearly as bad if packages could store extended attributes, since the ugly install scripts could be avoided and paxctl would only be a make dependency. Packages like iputils already run into this issue due to using capabilities as a replacement for setuid.
Just submitted a patch to pacman that will allow setting capabilites in the package() function.
Since we want PAX support to remain optional, we'd still need hooks so that after each upgrade, a script can adjust the flags appropriately.
It would have no impact on people not using it, since it would just be a very short string set in the `user.pax.flags` xattr key. For example, `setfattr -n user.pax.flags -v "mr" "$pkgdir/usr/bin/foo"` to disable MPROTECT and RANDMMAP features (on chromium, firefox, etc.). Of course, I'm imagining a future utopia where a critical mass of developers / trusted users are interested in maintaining this kind of thing. For the near future, users would just keep using the scary linux-pax-flags package if they wanted to enable PaX via sysctl.
In data giovedì 17 aprile 2014 02:44:37, Daniel Micay ha scritto:
Of course, I'm imagining a future utopia where a critical mass of developers / trusted users are interested in maintaining this kind of thing. For the near future, users would just keep using the scary linux-pax-flags package if they wanted to enable PaX via sysctl.
FWIW I'm very interested in linux-grsec and would gladly maintaing PAX flags on my packages if I had to. I'm still mourning over the abrupt drop of audit support from the kernel with lame reasons. -- Massimiliano "mtorromeo" Torromeo Arch Linux TU GPG: 0xDA2EE423
On 16/04/2014 06:09, Daniel Micay wrote:
To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system.
How do you/we will handle off stream kernel modules rebuild? Each modules maintainer will have to create a new version for this kernel and update it when you push a new version, right? -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
On 18/04/14 04:09 AM, Sébastien Luttringer wrote:
On 16/04/2014 06:09, Daniel Micay wrote:
To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system.
How do you/we will handle off stream kernel modules rebuild? Each modules maintainer will have to create a new version for this kernel and update it when you push a new version, right?
I could build these myself when I push a new version, because there aren't many of them. I don't think it makes sense to bother with the nvidia module because it would be a bit silly to mix it with grsecurity. grsecurity almost always follows the point releases of the previous kernel version longer than Arch keeps them around, so any real work to migrate to the new kernel version would already be done and easily copied over.
On 18/04/14 04:09 AM, Sébastien Luttringer wrote:
On 16/04/2014 06:09, Daniel Micay wrote: I could build these myself when I push a new version, because there aren't many of them. When I will push a new version of Virtualbox, which currently provides modules for linux and linux-lts. I will have to build a third external
On 18/04/2014 10:44, Daniel Micay wrote: package for linux-grsec, like every modules maintainer.
I don't think it makes sense to bother with the nvidia module because it would be a bit silly to mix it with grsecurity.
Why user with nvidia cards should be deprived of grsec security enhancement? -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
In data venerdì 18 aprile 2014 11:34:14, Sébastien Luttringer ha scritto:
On 18/04/2014 10:44, Daniel Micay wrote:
On 18/04/14 04:09 AM, Sébastien Luttringer wrote:
On 16/04/2014 06:09, Daniel Micay wrote: I could build these myself when I push a new version, because there aren't many of them.
When I will push a new version of Virtualbox, which currently provides modules for linux and linux-lts. I will have to build a third external package for linux-grsec, like every modules maintainer.
How about only using dkms for third-party modules for kernels outside of [core]? -- Massimiliano "mtorromeo" Torromeo Arch Linux TU GPG: 0xDA2EE423
On 18/04/2014 11:40, Massimiliano Torromeo wrote:
In data venerdì 18 aprile 2014 11:34:14, Sébastien Luttringer ha scritto:
On 18/04/2014 10:44, Daniel Micay wrote:
On 18/04/14 04:09 AM, Sébastien Luttringer wrote:
On 16/04/2014 06:09, Daniel Micay wrote: I could build these myself when I push a new version, because there aren't many of them.
When I will push a new version of Virtualbox, which currently provides modules for linux and linux-lts. I will have to build a third external package for linux-grsec, like every modules maintainer.
How about only using dkms for third-party modules for kernels outside of [core]?
I love this idea :) -- Sébastien "Seblu" Luttringer https://seblu.net GPG: 0x2072D77A
On 18/04/14 05:34 AM, Sébastien Luttringer wrote:
On 18/04/14 04:09 AM, Sébastien Luttringer wrote:
On 16/04/2014 06:09, Daniel Micay wrote: I could build these myself when I push a new version, because there aren't many of them. When I will push a new version of Virtualbox, which currently provides modules for linux and linux-lts. I will have to build a third external
On 18/04/2014 10:44, Daniel Micay wrote: package for linux-grsec, like every modules maintainer.
There's no problem with simply not building a VirtualBox module for the linux-grsec kernel. You're not building one now, so there would be nothing gained or lost. Supporting out-of-tree modules wasn't something I planned on considering at all right away. Other modules without userspace components wouldn't present the same problems as VirtualBox, since they would be an entirely separate package.
I don't think it makes sense to bother with the nvidia module because it would be a bit silly to mix it with grsecurity.
Why user with nvidia cards should be deprived of grsec security enhancement?
It will work fine with Nouveau. The nvidia driver is a larger pile of code than the Linux kernel itself and no hardening can be applied to it. The grsecurity kernel randomization features are rendered useless since it has info leaks all over. It might have an impact on the RBAC policies, which would otherwise be able to assume that X will be running as non-root post 1.16. If someone is interested in building an nvidia module for a grsecurity kernel and fixing any RBAC issues then I won't object, but I'm not going to do it myself.
On 18/04/2014 13:07, Daniel Micay wrote:
On 18/04/2014 10:44, Daniel Micay wrote:
On 18/04/14 04:09 AM, Sébastien Luttringer wrote:
On 16/04/2014 06:09, Daniel Micay wrote: There's no problem with simply not building a VirtualBox module for the
On 18/04/14 05:34 AM, Sébastien Luttringer wrote: linux-grsec kernel. Being not consistent is a problem to me. But nothing which I can overcome.
You're not building one now, so there would be nothing gained or lost. I build 2 modules for each release[1]. Could be 3 tomorrow. I miss your point.
Supporting out-of-tree modules wasn't something I planned on considering at all right away. Suggestion of Massimiliano is fine to me. If we all agree to get ride of compiled modules, there is no burden to me to grsec kernel addition. This even open the door to talk about versioned kernel :)
-- Sébastien "Seblu" Luttringer https://seblu.net GPG: 0x2072D77A
On 18/04/14 08:02 AM, Sébastien Luttringer wrote:
On 18/04/2014 13:07, Daniel Micay wrote:
On 18/04/2014 10:44, Daniel Micay wrote:
On 18/04/14 04:09 AM, Sébastien Luttringer wrote:
On 16/04/2014 06:09, Daniel Micay wrote: There's no problem with simply not building a VirtualBox module for the
On 18/04/14 05:34 AM, Sébastien Luttringer wrote: linux-grsec kernel. Being not consistent is a problem to me. But nothing which I can overcome.
You're not building one now, so there would be nothing gained or lost. I build 2 modules for each release[1]. Could be 3 tomorrow. I miss your point.
I mean that users are currently compiling these modules on their own for grsec, so if there were no packaged out-of-tree modules for it at all then it wouldn't be a step backwards. The most painful part for users is compiling the kernel, especially when most of the AUR kernel packages are based on older versions of the [core] package rather than following the current configuration.
Supporting out-of-tree modules wasn't something I planned on considering at all right away. Suggestion of Massimiliano is fine to me. If we all agree to get ride of compiled modules, there is no burden to me to grsec kernel addition. This even open the door to talk about versioned kernel :)
I agree that DKMS is the best way of dealing with this.
[2014-04-16 00:09:55 -0400] Daniel Micay:
To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system.
It sounds fairly intrusive to me to introduce and support a new kernel in our repositories. And I feel quite uneasy about this set of patches not having been accepted upstream. Is there a particular reason why the current state (packages in the AUR, built on-demand by those users that are interested) is dissatisfying? In your view, should we also package other patchsets, such as Con Kolivas' (by far the most popular linux-* package on the AUR)? -- Gaetan
On 18/04/14 05:09 AM, Gaetan Bisson wrote:
[2014-04-16 00:09:55 -0400] Daniel Micay:
To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system.
It sounds fairly intrusive to me to introduce and support a new kernel in our repositories.
I don't expect anyone but myself to put any work into supporting it. A few other developers and trusted users may be interested in helping, but I can certainly take care of it myself if there isn't interest. It's far less invasive than asking for features like SELinux to be enabled in all of our packages. I think most people who would be asking for the [core] kernel to support TOMOYO/AppArmor/SELinux/Smack/Audit will be more than happy to use grsecurity instead.
And I feel quite uneasy about this set of patches not having been accepted upstream.
It makes changes like adding (mostly) redundant checks to reference counting and bounds checks on copies to/from userspace with a measurable performance cost. These changes prevent many of the discovered kernel vulnerabilities from working on a grsecurity kernel. These features don't prevent bugs, but rather stop them from becoming exploitable vulnerabilities. Linus doesn't see security issues as meriting special treatment over other bugs, and trying to sell a 1-5% performance loss upstream is just not going to happen. ASLR was invented by the PaX team, along with other mitigation techniques that are now upstream. Many of the non-PaX grsecurity features have also made their way into the Linux kernel (ptrace_scope, hidepid, fs.protected_symlinks, fs.protected_hardlinks, dmesg_restrict, kptr_restrict, etc.) and other operating systems. The mainline kernel still hasn't caught up to where it was ten years ago, and there has been a significant amount of new research and feature development since then.
Is there a particular reason why the current state (packages in the AUR, built on-demand by those users that are interested) is dissatisfying?
You might as well ask why I want to maintain any packages at all. :P I think I can offer a good out-of-the-box experience with this package in the repositories. The userspace support is relevant whether someone uses a grsecurity package from the repositories or builds their own.
In your view, should we also package other patchsets, such as Con Kolivas' (by far the most popular linux-* package on the AUR)?
I'm fine with other people packaging any FOSS under the sun if it has an active upstream and isn't going to put a burden on other developers / trusted users. I don't think we should bring more dead projects or proprietary software into the repositories but this is neither. I'm not familiar with what the CK patches do, so I can't really voice an opinion on whether they are worth including in the repositories. I don't think votes are a good measure of interest in a package, since it's tied to age and automatic voting by some AUR helpers. For all we know, someone used a script to create a bunch of accounts to vote for it. If someone writes an explanation of what it is and why it would be valuable to include in the repositories then I can give an answer.
On Wed, Apr 16, 2014 at 6:09 AM, Daniel Micay <danielmicay@gmail.com> wrote:
There has been a recent surge of interest in securing Arch by paying closer attention to CVEs and addressing many security issues in our packages. I also started some initial work/documenting on securing the services shipped in various packages:
https://wiki.archlinux.org/index.php/DeveloperWiki:Service_isolation
I'm very happy that more people are now looking at security related things in Arch. Nice work!
To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system. This would be the first case of an alternative kernel in the repositories, so I'm open to discussion about whether it's appropriate to do this. There are also some issues relevant to other packages in the repositories.
Hmm, grsec seems like a dead-end to me. It will never land upstream, and hence will never be in our standard kernel and our default packages will therefore never be integrated with it. So whatever work you do will have to live independently in perpetuity. At worst it would split our (very limited) development and QA resources. Would it not make more sense to focus on some other security features that are actually upstream and which can then at least potentially be merged into our default packages eventually? Maybe another option, if you really think grsec is the way to go, would be to simply create a new unofficial repository and put the packages there instead? Cheers, Tom
The grsecurity project has been around since 2001 and has fundamentally different goals than the mainline Linux project. Much like OpenBSD, it makes changes with a measurable performance or compatibility impact that are unlikely to ever be included in the upstream kernel. Many of these changes involve hardening the kernel against userspace exploitation, which is not something tackled by any of the Linux Security Modules. Users, groups, ACLs, chroots and namespaces already provide a solid foundation for access control, so hardening the kernel itself is the single biggest security improvement involved.
It has various odds and ends exposed via sysctl switches, and these tend to trickle upstream in one form or another (symlink/hardlink protection, dmesg restriction, /proc restrictions).
It also includes the PaX project to provide a much stronger implementation of ASLR along with significant memory protections for userspace. These features do break many packages, and require setting flags on binaries when exceptions are necessary. I don't want to place a burden on other packagers, so I plan on leaving the parts requiring integration with other packages disabled at first.
If there turns out to be more interest than just my own in maintaining this, flipping on the PaX protections by default and setting the required flags in various packages could be considered. I don't want to approach this by filing bugs, so there would need to be a developer interested in doing some work on packages in [core] and [extra] for these kinds of features to be enabled.
SELinux requires many packages to be built with support for it, along with a significant number of patches. The policies are very complex and spread out through the entire file system. In my opinion, it's pretty much the antithesis of Arch's goals of simplicity and transparent configuration.
AppArmor/TOMOYO are much simpler, with centralized policy files that are much easier to review or ship in packages. The grsecurity RBAC system is similar to these and has a nice automatic learning mode. However, it's quite a bit more powerful and grsecurity is useful even without providing RBAC policies since this is only one component.
All in all, I think grsecurity would be a great way of improving the level of security we offer. It's also one of the least intrusive ways of doing it, since it can provide significant benefits without everyone buying into it and adding profiles to their packages. There will be no impact on the regular/default kernel, so it's far friendlier to users who don't care about this than SELinux/AppArmor/Audit.
On 18/04/14 05:11 PM, Tom Gundersen wrote:
On Wed, Apr 16, 2014 at 6:09 AM, Daniel Micay <danielmicay@gmail.com> wrote:
There has been a recent surge of interest in securing Arch by paying closer attention to CVEs and addressing many security issues in our packages. I also started some initial work/documenting on securing the services shipped in various packages:
https://wiki.archlinux.org/index.php/DeveloperWiki:Service_isolation
I'm very happy that more people are now looking at security related things in Arch. Nice work!
To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system. This would be the first case of an alternative kernel in the repositories, so I'm open to discussion about whether it's appropriate to do this. There are also some issues relevant to other packages in the repositories.
Hmm, grsec seems like a dead-end to me. It will never land upstream, and hence will never be in our standard kernel and our default packages will therefore never be integrated with it. So whatever work you do will have to live independently in perpetuity. At worst it would split our (very limited) development and QA resources.
There's nothing else hardening the kernel itself against exploitation, so containers (namespaces, seccomp-bpf) aren't going to benefit from any other work. I don't see much point in spending my time integrating an LSM when they're just layering on more complexity without fixing the lowest hanging fruit. The work that's done in grsecurity trickles into the kernel years later, so it's not really a dead end. I understand if touching any other packages is viewed as unacceptable and can work around that issue. The RBAC policies will be entirely centralized in the gradm package, and I can try to take the quirky approach of doing all of the PaX exceptions there. No other packages will be aware of anything going on, unless people feel like taking the completely optional step of making DKMS versions of modules. The only time spent on this is going to be my own. I've already spent far more time writing these mailing list responses than any amount of work I've put into improving security-related issues... speaking of development resources.
Would it not make more sense to focus on some other security features that are actually upstream and which can then at least potentially be merged into our default packages eventually?
We do have ptrace_scope, protected_symlinks and protected_hardlinks enabled, which are bits of grsecurity that made it into the kernel after many years. The upstream kernel only has ASLR at all because PaX invented it in the early 2000s. We could enable dmesg_restrict / kptr_restrict but there's not much value until KASLR can be turned on. Even then, there's little value in KASLR (or ASLR) when many upstream maintainers simply don't care about breaking it by leaking addresses. Flipping on PIE for some executables would be an improvement, but it's a lot more valuable with the improved PaX ASLR.
Maybe another option, if you really think grsec is the way to go, would be to simply create a new unofficial repository and put the packages there instead?
I do really think it's the way to go. If it has to be walled off outside of the repositories, there's a lot less value in it. I'm unlikely to waste any more time trying to improve this aspect of the distribution if it's just shot down. To be perfectly honest, I didn't feel I had to ask for permission to maintain a 13 year old open-source project with 43 votes in [community] and had no idea there would be such a negative response. We have plenty of forks like graphicsmagick and even two entire desktop environments forked from GNOME (Mate and Cinnamon). There's at least one proprietary driver that's never going to be open-source let alone integrated upstream, and plenty of *truly* dead-end projects with no upstream (metacity!).
On 19/04/14 07:11, Tom Gundersen wrote:
On Wed, Apr 16, 2014 at 6:09 AM, Daniel Micay <danielmicay@gmail.com> wrote:
There has been a recent surge of interest in securing Arch by paying closer attention to CVEs and addressing many security issues in our packages. I also started some initial work/documenting on securing the services shipped in various packages:
https://wiki.archlinux.org/index.php/DeveloperWiki:Service_isolation
I'm very happy that more people are now looking at security related things in Arch. Nice work!
To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system. This would be the first case of an alternative kernel in the repositories, so I'm open to discussion about whether it's appropriate to do this. There are also some issues relevant to other packages in the repositories.
Hmm, grsec seems like a dead-end to me. It will never land upstream, and hence will never be in our standard kernel and our default packages will therefore never be integrated with it. So whatever work you do will have to live independently in perpetuity. At worst it would split our (very limited) development and QA resources.
Would it not make more sense to focus on some other security features that are actually upstream and which can then at least potentially be merged into our default packages eventually?
Maybe another option, if you really think grsec is the way to go, would be to simply create a new unofficial repository and put the packages there instead?
I'd say an unofficial repo is the way to go for the time being. linux-grsec in the AUR only has 44 votes, so it is not screaming out for inclusion in the repos. Allan
On 18/04/14 08:15 PM, Allan McRae wrote:
On 19/04/14 07:11, Tom Gundersen wrote:
On Wed, Apr 16, 2014 at 6:09 AM, Daniel Micay <danielmicay@gmail.com> wrote:
There has been a recent surge of interest in securing Arch by paying closer attention to CVEs and addressing many security issues in our packages. I also started some initial work/documenting on securing the services shipped in various packages:
https://wiki.archlinux.org/index.php/DeveloperWiki:Service_isolation
I'm very happy that more people are now looking at security related things in Arch. Nice work!
To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system. This would be the first case of an alternative kernel in the repositories, so I'm open to discussion about whether it's appropriate to do this. There are also some issues relevant to other packages in the repositories.
Hmm, grsec seems like a dead-end to me. It will never land upstream, and hence will never be in our standard kernel and our default packages will therefore never be integrated with it. So whatever work you do will have to live independently in perpetuity. At worst it would split our (very limited) development and QA resources.
Would it not make more sense to focus on some other security features that are actually upstream and which can then at least potentially be merged into our default packages eventually?
Maybe another option, if you really think grsec is the way to go, would be to simply create a new unofficial repository and put the packages there instead?
I'd say an unofficial repo is the way to go for the time being. linux-grsec in the AUR only has 44 votes, so it is not screaming out for inclusion in the repos.
Allan
Users have been asking for MAC to be provided in the repositories for a long time. At the moment, two bugs are open about it: https://bugs.archlinux.org/task/37578 https://bugs.archlinux.org/task/39852 Any of these reported bugs could simply be closed with the response that the grsecurity RBAC is provided in the repositories and there's no one interested in maintaining another. I think that's a response most people would be satisfied with, but users aren't going to be very happy with an a WONTFIX simply saying Arch has no official support for any of this.
On Sat, Apr 19, 2014 at 9:59 PM, Daniel Micay <danielmicay@gmail.com> wrote:
Users have been asking for MAC to be provided in the repositories for a long time. At the moment, two bugs are open about it:
https://bugs.archlinux.org/task/37578 https://bugs.archlinux.org/task/39852
Any of these reported bugs could simply be closed with the response that the grsecurity RBAC is provided in the repositories and there's no one interested in maintaining another. I think that's a response most people would be satisfied with, but users aren't going to be very happy with an a WONTFIX simply saying Arch has no official support for any of this.
I would see this the other way around (which is one of the reasons I don't think adding forks of the kernel is such a great idea). It would be very nice if we could manage to support some more security features in the main kernel, but asking people to use an alternative kernel if they want security features seems wrong. Especially if it is used as an excuse not to get things that are already upstream working with the main kernel we provide. If you were providing an alternative kernel temporarily as a testing-ground for things that would eventually get integrated in our main kernel, I'd be all for it. But the way I see it, everyone agrees that grsec is never going upstream and that this is not something we could ever integrate in the main kernel, so I think we should be very careful about splitting efforts which could have otherwise benefited the whole distro (such as support for AppArmor, TOMOYO, SELinux, whatever). In short, work on grsec if you want, but please let's not use that as an excuse to discourage people from working on similar features for the main kernel. Cheers, Tom
On 19/04/14 05:25 PM, Tom Gundersen wrote:
On Sat, Apr 19, 2014 at 9:59 PM, Daniel Micay <danielmicay@gmail.com> wrote:
Users have been asking for MAC to be provided in the repositories for a long time. At the moment, two bugs are open about it:
https://bugs.archlinux.org/task/37578 https://bugs.archlinux.org/task/39852
Any of these reported bugs could simply be closed with the response that the grsecurity RBAC is provided in the repositories and there's no one interested in maintaining another. I think that's a response most people would be satisfied with, but users aren't going to be very happy with an a WONTFIX simply saying Arch has no official support for any of this.
I would see this the other way around (which is one of the reasons I don't think adding forks of the kernel is such a great idea). It would be very nice if we could manage to support some more security features in the main kernel, but asking people to use an alternative kernel if they want security features seems wrong. Especially if it is used as an excuse not to get things that are already upstream working with the main kernel we provide.
These features aren't in the regular kernel though. There's no way to have anything but the weak ASLR implementation with missing pieces. It has no configuration option to flip on similar hardening options. All of the MAC implementations in the kernel are limited to what's offered by the LSM framework, so even writing an equivalent to the RBAC implementation isn't possible without going through the political work of convincing many maintainers to add many more hooks, etc. The LSM support (beyond ptrace_scope from Yama) was disabled in core/linux seeing as it wasn't receiving any userspace report in the repositories and many people don't like the auditing.
If you were providing an alternative kernel temporarily as a testing-ground for things that would eventually get integrated in our main kernel, I'd be all for it. But the way I see it, everyone agrees that grsec is never going upstream and that this is not something we could ever integrate in the main kernel, so I think we should be very careful about splitting efforts which could have otherwise benefited the whole distro (such as support for AppArmor, TOMOYO, SELinux, whatever).
In short, work on grsec if you want, but please let's not use that as an excuse to discourage people from working on similar features for the main kernel.
I have no problem with someone else working on it, but as far as I know there are no other developers or trusted users interested in doing this kind of work. Anyway, there is simply no similar support upstream. It has taken over a decade for a few sysctl flags to enable some of the miscellaneous features from grsecurity. You'll encounter a *lot* of resistance trying to upstream work as Kees Cook has been doing. Yama exists because the kernel developers refused to support ptrace_scope in the core kernel... and it's a tiny feature.
It has taken over a decade for a few sysctl flags to enable some of the miscellaneous features from grsecurity.
(as in this stuff gets rejected time and time again until it was finally accepted in a reversal of the previous decisions, so by now few people other than Kees Cook are interested in even submitting these security features in the first place)
On Sat, Apr 19, 2014 at 11:47 PM, Daniel Micay <danielmicay@gmail.com> wrote:
On 19/04/14 05:25 PM, Tom Gundersen wrote:
On Sat, Apr 19, 2014 at 9:59 PM, Daniel Micay <danielmicay@gmail.com> wrote:
Users have been asking for MAC to be provided in the repositories for a long time. At the moment, two bugs are open about it:
https://bugs.archlinux.org/task/37578 https://bugs.archlinux.org/task/39852
Any of these reported bugs could simply be closed with the response that the grsecurity RBAC is provided in the repositories and there's no one interested in maintaining another. I think that's a response most people would be satisfied with, but users aren't going to be very happy with an a WONTFIX simply saying Arch has no official support for any of this.
I would see this the other way around (which is one of the reasons I don't think adding forks of the kernel is such a great idea). It would be very nice if we could manage to support some more security features in the main kernel, but asking people to use an alternative kernel if they want security features seems wrong. Especially if it is used as an excuse not to get things that are already upstream working with the main kernel we provide.
These features aren't in the regular kernel though.
I was referring to SELinux and TOMOYO. Cheers, Tom
On 19/04/14 05:25 PM, Tom Gundersen wrote:
In short, work on grsec if you want, but please let's not use that as an excuse to discourage people from working on similar features for the main kernel.
For example, if someone opens a bug asking to enable CONFIG_AUDIT again, will it really be accepted? The workaround for containers landed in systemd. http://cgit.freedesktop.org/systemd/systemd/commit/?id=24fb111
On Sat, Apr 19, 2014 at 11:58 PM, Daniel Micay <danielmicay@gmail.com> wrote:
On 19/04/14 05:25 PM, Tom Gundersen wrote:
In short, work on grsec if you want, but please let's not use that as an excuse to discourage people from working on similar features for the main kernel.
For example, if someone opens a bug asking to enable CONFIG_AUDIT again, will it really be accepted? The workaround for containers landed in systemd.
http://cgit.freedesktop.org/systemd/systemd/commit/?id=24fb111
That is clearly not an acceptable long-term solution. As far as I know audit is being fixed upstream to make this temporary work-around unnecessary. -t
On 19/04/14 06:23 PM, Tom Gundersen wrote:
On Sat, Apr 19, 2014 at 11:58 PM, Daniel Micay <danielmicay@gmail.com> wrote:
On 19/04/14 05:25 PM, Tom Gundersen wrote:
In short, work on grsec if you want, but please let's not use that as an excuse to discourage people from working on similar features for the main kernel.
For example, if someone opens a bug asking to enable CONFIG_AUDIT again, will it really be accepted? The workaround for containers landed in systemd.
http://cgit.freedesktop.org/systemd/systemd/commit/?id=24fb111
That is clearly not an acceptable long-term solution. As far as I know audit is being fixed upstream to make this temporary work-around unnecessary.
-t
It's enough for CONFIG_AUDIT to be enabled in our kernel without breaking containers. It's not enough to have it work in containers, but it's already not working in containers today because it was disabled.
On 19.04.2014 23:58, Daniel Micay wrote:
For example, if someone opens a bug asking to enable CONFIG_AUDIT again, will it really be accepted? The workaround for containers landed in systemd.
Going slightly off topic here, but you only seem to connect audit with the systemd bug so might be valuable: I don't care about audit so I don't use it. Sadly that doesn't work because it defaults to being enabled which means I get tons of audit spam in dmesg. As long as that's the case I'm against enabling it and the same thing applies to all other features that change the kernel behaviour even if I don't use them.
On 20/04/14 04:32 AM, Florian Pritz wrote:
On 19.04.2014 23:58, Daniel Micay wrote:
For example, if someone opens a bug asking to enable CONFIG_AUDIT again, will it really be accepted? The workaround for containers landed in systemd.
Going slightly off topic here, but you only seem to connect audit with the systemd bug so might be valuable:
I don't care about audit so I don't use it. Sadly that doesn't work because it defaults to being enabled which means I get tons of audit spam in dmesg.
As long as that's the case I'm against enabling it and the same thing applies to all other features that change the kernel behaviour even if I don't use them.
Sure, that's why I raised this point. Enabling any security feature in the core/linux kernel breaking something by default or even printing a few lines to the kernel log is a hard sell here. As far as I know we only have the nice `ptrace_scope=1` feature enabled because it managed to sneak in at some point.[1] I fought hard against a bug report asking for it to be disabled by default, but I expect more complaints about it because it stops `gdb -p $PID`, `strace -p $PID`, `perf trace $PID` and `reptyr $PID` from working as an unprivileged user. Security-related features are just as hard to sell upstream, even when they're completely optional. For example, PaX has a very low cost sanity check on kernel reference counting. It barely shows up in any profiling and is an optional configuration feature (PAX_REFCOUNT). It prevents a steady stream of bugs from being exploitable, such as this one from a few days ago: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2851 In order to have KASLR in core/linux (once it stops breaking hibernate?), we're going to need to enable dmesg_restrict and kptr_restrict. This means the kernel logs won't be readable as non-root and some things like perf with privileges will be broken. That's hard enough to sell here, but KASLR isn't actually useful until the kernel stops leaking addresses everywhere. It's already shown to be worthless in the current state via simple bypasses. [1] https://bugs.archlinux.org/task/36846
On Wed, 16 Apr 2014 00:09:55 -0400 Daniel Micay <danielmicay@gmail.com> wrote:
There has been a recent surge of interest in securing Arch by paying closer attention to CVEs and addressing many security issues in our packages. I also started some initial work/documenting on securing the services shipped in various packages:
https://wiki.archlinux.org/index.php/DeveloperWiki:Service_isolation
To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system. This would be the first case of an alternative kernel in the repositories, so I'm open to discussion about whether it's appropriate to do this. There are also some issues relevant to other packages in the repositories.
The grsecurity project has been around since 2001 and has fundamentally different goals than the mainline Linux project. Much like OpenBSD, it makes changes with a measurable performance or compatibility impact that are unlikely to ever be included in the upstream kernel. Many of these changes involve hardening the kernel against userspace exploitation, which is not something tackled by any of the Linux Security Modules. Users, groups, ACLs, chroots and namespaces already provide a solid foundation for access control, so hardening the kernel itself is the single biggest security improvement involved.
It has various odds and ends exposed via sysctl switches, and these tend to trickle upstream in one form or another (symlink/hardlink protection, dmesg restriction, /proc restrictions).
It also includes the PaX project to provide a much stronger implementation of ASLR along with significant memory protections for userspace. These features do break many packages, and require setting flags on binaries when exceptions are necessary. I don't want to place a burden on other packagers, so I plan on leaving the parts requiring integration with other packages disabled at first.
If there turns out to be more interest than just my own in maintaining this, flipping on the PaX protections by default and setting the required flags in various packages could be considered. I don't want to approach this by filing bugs, so there would need to be a developer interested in doing some work on packages in [core] and [extra] for these kinds of features to be enabled.
SELinux requires many packages to be built with support for it, along with a significant number of patches. The policies are very complex and spread out through the entire file system. In my opinion, it's pretty much the antithesis of Arch's goals of simplicity and transparent configuration.
AppArmor/TOMOYO are much simpler, with centralized policy files that are much easier to review or ship in packages. The grsecurity RBAC system is similar to these and has a nice automatic learning mode. However, it's quite a bit more powerful and grsecurity is useful even without providing RBAC policies since this is only one component.
All in all, I think grsecurity would be a great way of improving the level of security we offer. It's also one of the least intrusive ways of doing it, since it can provide significant benefits without everyone buying into it and adding profiles to their packages. There will be no impact on the regular/default kernel, so it's far friendlier to users who don't care about this than SELinux/AppArmor/Audit.
I'd really like to see it in our repositories, as long as it doesn't require any additional actions from other maintainers. I used to maintain my own PKGBUILD for quite a long time, but compiling whole kernel for only one machine was a bit toilsome. Could we add it to [community] at least experimentally and in case of further concerns just remove it? -- Bartłomiej Piotrowski http://bpiotrowski.pl/
On 19/04/14 03:28 AM, Bartłomiej Piotrowski wrote:
On Wed, 16 Apr 2014 00:09:55 -0400 Daniel Micay <danielmicay@gmail.com> wrote:
There has been a recent surge of interest in securing Arch by paying closer attention to CVEs and addressing many security issues in our packages. I also started some initial work/documenting on securing the services shipped in various packages:
https://wiki.archlinux.org/index.php/DeveloperWiki:Service_isolation
To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system. This would be the first case of an alternative kernel in the repositories, so I'm open to discussion about whether it's appropriate to do this. There are also some issues relevant to other packages in the repositories.
The grsecurity project has been around since 2001 and has fundamentally different goals than the mainline Linux project. Much like OpenBSD, it makes changes with a measurable performance or compatibility impact that are unlikely to ever be included in the upstream kernel. Many of these changes involve hardening the kernel against userspace exploitation, which is not something tackled by any of the Linux Security Modules. Users, groups, ACLs, chroots and namespaces already provide a solid foundation for access control, so hardening the kernel itself is the single biggest security improvement involved.
It has various odds and ends exposed via sysctl switches, and these tend to trickle upstream in one form or another (symlink/hardlink protection, dmesg restriction, /proc restrictions).
It also includes the PaX project to provide a much stronger implementation of ASLR along with significant memory protections for userspace. These features do break many packages, and require setting flags on binaries when exceptions are necessary. I don't want to place a burden on other packagers, so I plan on leaving the parts requiring integration with other packages disabled at first.
If there turns out to be more interest than just my own in maintaining this, flipping on the PaX protections by default and setting the required flags in various packages could be considered. I don't want to approach this by filing bugs, so there would need to be a developer interested in doing some work on packages in [core] and [extra] for these kinds of features to be enabled.
SELinux requires many packages to be built with support for it, along with a significant number of patches. The policies are very complex and spread out through the entire file system. In my opinion, it's pretty much the antithesis of Arch's goals of simplicity and transparent configuration.
AppArmor/TOMOYO are much simpler, with centralized policy files that are much easier to review or ship in packages. The grsecurity RBAC system is similar to these and has a nice automatic learning mode. However, it's quite a bit more powerful and grsecurity is useful even without providing RBAC policies since this is only one component.
All in all, I think grsecurity would be a great way of improving the level of security we offer. It's also one of the least intrusive ways of doing it, since it can provide significant benefits without everyone buying into it and adding profiles to their packages. There will be no impact on the regular/default kernel, so it's far friendlier to users who don't care about this than SELinux/AppArmor/Audit.
I'd really like to see it in our repositories, as long as it doesn't require any additional actions from other maintainers. I used to maintain my own PKGBUILD for quite a long time, but compiling whole kernel for only one machine was a bit toilsome.
Could we add it to [community] at least experimentally and in case of further concerns just remove it?
I don't really see any problem with moving a FOSS package with 52 votes to [community]. Whether or not people like the project isn't really relevant. The very real out-of-tree module issue has been tackled by deciding on the use of DKMS. I regret talking about PaX exceptions at all because I've realized it can just be handled entirely within the package. I think mentioning that threw off the whole conversation from the start, although I guess it was worth it if Pacman learns about extended attributes :P. If the package really does throw someone's cat in a blender, they're free to remove it. It seems the only way to demonstrate it won't give anyone any extra work to do is to just do it...
[2014-04-20 20:22:59 -0400] Daniel Micay:
I don't really see any problem with moving a FOSS package with 52 votes to [community]. Whether or not people like the project isn't really relevant.
So you initially inquired about this on arch-dev-public because you knew it was a controversial issue, but when it turns out most answers are not what you hoped for you go ahead against them? Is that the logic here? What part of "do it in a separate repo for the time being" didn't you understand and/or like? That solution seemed to make everyone happy... By the way, "Packager: Unknown Packager" looks bad. -- Gaetan
On 21/04/14 12:40 AM, Gaetan Bisson wrote:
[2014-04-20 20:22:59 -0400] Daniel Micay:
I don't really see any problem with moving a FOSS package with 52 votes to [community]. Whether or not people like the project isn't really relevant.
So you initially inquired about this on arch-dev-public because you knew it was a controversial issue, but when it turns out most answers are not what you hoped for you go ahead against them? Is that the logic here?
I brought it up on arch-dev-public because there were issues involving other packages. I wasn't looking for approval to move a package for FOSS software with 40 votes (>50 when it was moved) that I have significant interest in. I certainly adjusted what I planned to do based on the feedback here. I thought there might be interest in setting the PaX exceptions so it could be enabled out-of-the-box but there was not. There were very valid concerns about modules, which I think have been resolved by the decision to only use DKMS. I've backed down from the idea of ever incorporating the PaX exceptions into other packages and will try to handle it entirely within linux-grsec via RBAC. Other trusted users and developers will never have to put one bit of work into supporting this, and that was the only other concern raised. There are people who have a personal dislike of the software, as with anything else, and I don't really care. Beyond the issues above, I don't think anyone has raised a reason to keep this out of [community]. I don't there's there's any "slippery slope" here considering that using DKMS makes this kind of thing self-contained. It could even be written down as a policy somewhere that out-of-tree modules for non-[core] kernel packages are only supported via DKMS. There's not currently anything written down about this that I know of. I certainly don't get the impression that "most answers" are against it being in [community] at all. There was a strong consensus that PaX exceptions do not belong in other packages, and I can respect that. I currently have PaX enforcement disabled and will implement a less ideal solution internal to the package. The mailing list wasn't the only place where I've discussed this. It has been a topic of conversation on various IRC channels, where numerous trusted users and developers voiced support for it. I don't think a vocal minority on the mailing list represents a consensus against it.
What part of "do it in a separate repo for the time being" didn't you understand and/or like? That solution seemed to make everyone happy...
It didn't make me happy, nor did it seem to be a satisfactory answer to Connor, Barthalion or various others on IRC. A certain developer (I'll let them speak for themselves if they want to) suggested I just put it in [community] instead of being so cautious about it.
By the way, "Packager: Unknown Packager" looks bad.
I moved this from the unofficial repository on pkgbuild.com where I was previously building and hosting it, if you're curious why that's messed up. It will be fixed as soon as there's a new release or I start work on the PaX issue which won't be long.
Hi again, As you might have noticed, I do not care too much about grsecurity, however I do care very much about doing things the right way. That's why I'll only respond to this: [2014-04-21 01:21:16 -0400] Daniel Micay:
The mailing list wasn't the only place where I've discussed this. It has been a topic of conversation on various IRC channels, where numerous trusted users and developers voiced support for it. I don't think a vocal minority on the mailing list represents a consensus against it.
The arch-dev-public mailing list is *the* medium of discussion between developers and trusted users. That's why all of us have access to it, and that's why all of us are expected to read it. And it really is the *only* one: not all of us have access to #archlinux-dev or #archlinux-tu and not all of us follow arch-general or aur-general. And when I say "medium of discussion", the "discussion" bit is extremely important! It's not just a poll you or someone else conducts by asking people privately on different channels, it really is: a discussion where everyone is free to raise arguments for or against, then if a consensus emerges we follow it, otherwise we vote. I believe we are all reasonable people, and just as my opinion might have evolved after reading the arguments of that mysterious developer you mention, the opposite may also happen. That's why discussing is so critical. Now I'm sorry to say this but it seems to me you have handled this issue in the worst possible way: ignoring community feedback as you saw fit. -- Gaetan
On 21/04/14 01:54 AM, Gaetan Bisson wrote:
Hi again,
As you might have noticed, I do not care too much about grsecurity, however I do care very much about doing things the right way. That's why I'll only respond to this:
[2014-04-21 01:21:16 -0400] Daniel Micay:
The mailing list wasn't the only place where I've discussed this. It has been a topic of conversation on various IRC channels, where numerous trusted users and developers voiced support for it. I don't think a vocal minority on the mailing list represents a consensus against it.
The arch-dev-public mailing list is *the* medium of discussion between developers and trusted users. That's why all of us have access to it, and that's why all of us are expected to read it. And it really is the *only* one: not all of us have access to #archlinux-dev or #archlinux-tu and not all of us follow arch-general or aur-general.
And when I say "medium of discussion", the "discussion" bit is extremely important! It's not just a poll you or someone else conducts by asking people privately on different channels, it really is: a discussion where everyone is free to raise arguments for or against, then if a consensus emerges we follow it, otherwise we vote.
I think I addressed the issues that were raised. I don't feel any need to take into account trashing of the project. If there is a remaining concern about how it could create extra work for other packagers, then I'm open to seeing if it can be addressed and dropping the package if it can't be fixed.
Now I'm sorry to say this but it seems to me you have handled this issue in the worst possible way: ignoring community feedback as you saw fit.
I responded to constructive feedback such as the issues raised about modules, PaX exceptions and the possibility of work being created for others in general. The package already meets every criteria for being included in [community], and that wasn't why I brought it up. I sent a mail here because I needed to figure out if I was going to be stepping on people's toes by adding PaX exceptions to packages - the answer is a resounding *yes*, so I will not propose it again or add the flags to my packages. As far as I'm aware, there's nothing making this package any more exceptional than something like vttest or whowatch with the adjusted plans (DKMS and no PaX flags).
In data domenica 20 aprile 2014 18:40:15, Gaetan Bisson ha scritto:
What part of "do it in a separate repo for the time being" didn't you understand and/or like? That solution seemed to make everyone happy...
Actually it only made happy the developers/tu that didn't care one bit about grsecurity. I surely am not happy about that solution and others have expressed concerns about this (Bartłomiej Piotrowski and Connor Behan come to mind) so I am not sure who is here that is ignoring feedback... -- Massimiliano "mtorromeo" Torromeo Arch Linux TU GPG: 0xDA2EE423
[2014-04-22 09:30:34 +0200] Massimiliano Torromeo:
I surely am not happy about that solution and others have expressed concerns about this (Bartłomiej Piotrowski and Connor Behan come to mind) so I am not sure who is here that is ignoring feedback...
Here on earth, Bartłomiej (who said nothing against separate repos) and the guy who breaks every thread he replies to are just two people out of ten in this discussion. And why didn't you chime in and gave us your arguments against separate repos? How relevant is it whether you are happy or not if you said nothing of it in the discussion?!? You can pull all the excuses you want, but no consensus was reached. Pressing ahead with something so controversial while the discussion is still going on is a plain and simple lack of respect for the opinion and advice of fellow developers and TUs. -- Gaetan
In data lunedì 21 aprile 2014 22:24:26, Gaetan Bisson ha scritto:
Here on earth, Bartłomiej (who said nothing against separate repos) and the guy who breaks every thread he replies to are just two people out of ten in this discussion. And why didn't you chime in and gave us your arguments against separate repos? How relevant is it whether you are happy or not if you said nothing of it in the discussion?!?
Because I simply agreed with points already expressed by others and I didn't think "+1s" would help the discussion. In data sabato 19 aprile 2014 11:11:18, Connor Behan ha scritto:
Hah. I would just like to add that unofficial repositories are usually a dead end.
1. Maintainer adds kernel to his own repository and tries to advertise it in the forums. 2. Only 10 people install it. 3. Maintainer decides it's not worth the work and takes down the repo.
With [community] there is a much higher probability that packages will be popular and maintained for awhile.
This is the quote I remembered agreeing with. And looking back at the discussion I have to admit that Bartłomiej didn't really argument against separate repo but expressed his desire for grsec in [community] instead.
You can pull all the excuses you want, but no consensus was reached. Pressing ahead with something so controversial while the discussion is still going on is a plain and simple lack of respect for the opinion and advice of fellow developers and TUs.
I am not saying that consensus was reached because it definetely was not, but at the same time I also don't feel like there is any need for consensus here as it seems to me that this is a package just like any other. Feedback was requested and taken into consideration, concerns were addressed and, as explained, this ended up being a self-contained package. If this results in problems that have not been considered it can be easily removed. -- Massimiliano "mtorromeo" Torromeo Arch Linux TU GPG: 0xDA2EE423
On Tue, Apr 22, 2014 at 10:44 AM, Massimiliano Torromeo <massimiliano.torromeo@gmail.com> wrote:
In data lunedì 21 aprile 2014 22:24:26, Gaetan Bisson ha scritto:
Here on earth, Bartłomiej (who said nothing against separate repos) and the guy who breaks every thread he replies to are just two people out of ten in this discussion. And why didn't you chime in and gave us your arguments against separate repos? How relevant is it whether you are happy or not if you said nothing of it in the discussion?!?
Because I simply agreed with points already expressed by others and I didn't think "+1s" would help the discussion.
If that helps I'm giving my +1 for having it community as long as there's no need for additional work from other maintainers. grsecurity is a nice and useful patchset and having it in community reduces the cost of deploying it. What is also important is that it would make it more visible to the users. Nobody ever uses binary repositories apart from the officially supported ones and possibly arch-haskell, which is quite specific in that it is not very useful for an ordinary user, but which is great for devs already using haskell. Lukas
Lets not draw this out too much further. I don't want to have to unsubscribe from another mailing list... But I am still going to have my say! 1) This was different than every other package in [community]. I know this because packages get added to [community] all the time without an email here. And saying discussion about adding PaX extensions was makes it different is naive as anyone who has been around here a short time could tell you that was never going to happen. 2) A few years back we specifically reduced the number of kernels in our repos to one. Then the LTS kernel appeared. Now this. The problem with adding a non-vanilla kernel to the repos is now for kernel bug reports we have to verify which kernel is running. If it is linux-grsec, we then need to figure out if the issue a generic linux one, or with the other patchset. This is a burden to all our the kernel maintainers and not just the packager and is part of the reason the variety of kernels was reduced. 3) Now this is in [community] there will be an expectation of providing all the extras that are supposed to come with this. As decided, this will not be happening, but it will be expected and the question will need to be answered repeatedly. 4) A separate repo would have given actual number for interest in this. We all know the number of votes in the AUR is a crap metric and could have accumulated a long time ago. It would also have allowed us to see how important the above issues are. Despite assertions, many binary repos are well used by the Arch community. 5) There were objections to it being included in our binary repos. This does not happen often, but we usually discuss further and come to a consensus about inclusion. Ignoring those objections is not how our team works. Given the relatively few people who responded to the thread, we have no real idea what the support was (and I can provide unsupported anecdotes for support against or for inclusion of the package as well as the next person can...) In conclusion, this should have waited before being put in the repo. It might have ended up there anyway, it might not have. And I can not be bothered figuring it out as it will not affect me in any way. Allan
In data martedì 22 aprile 2014 20:03:38, Allan McRae ha scritto:
Lets not draw this out too much further. I don't want to have to unsubscribe from another mailing list... But I am still going to have my say!
Several valid points worth discussion have been raised in this thread, even with the rough last bits I think it was worth evaluating. It's your choice if you want to unsubscribe from here of course...
1) This was different than every other package in [community]. I know this because packages get added to [community] all the time without an email here. And saying discussion about adding PaX extensions was makes it different is naive as anyone who has been around here a short time could tell you that was never going to happen.
2) A few years back we specifically reduced the number of kernels in our repos to one. Then the LTS kernel appeared. Now this. The problem with adding a non-vanilla kernel to the repos is now for kernel bug reports we have to verify which kernel is running. If it is linux-grsec, we then need to figure out if the issue a generic linux one, or with the other patchset. This is a burden to all our the kernel maintainers and not just the packager and is part of the reason the variety of kernels was reduced.
This is a very valid concern. Nobody raised it before though and in defence of Daniel I think the discussion was stagnating without such valid arguments having being pointed out.
3) Now this is in [community] there will be an expectation of providing all the extras that are supposed to come with this. As decided, this will not be happening, but it will be expected and the question will need to be answered repeatedly.
This is mostly true of every package. I packaged the user-space audit daemon and I was forced to remove it from [community] when audit support was removed from the [core] kernel. The point that support was expected for audit was as much valid as it would be for a different kernel.
4) A separate repo would have given actual number for interest in this. We all know the number of votes in the AUR is a crap metric and could have accumulated a long time ago. It would also have allowed us to see how important the above issues are. Despite assertions, many binary repos are well used by the Arch community.
That does not contradict the assertion that by being in [community] the userbase would probably be much larger (debatable of course...) but most importantly having a separate repo does not solve the issue you pointed out. The used kernel will still need to be specified in bug reports. It is also true for kernels compiled from AUR. What changes is the user expectation and on this I agree with you but most of the time that would translate in a simple matter of reassigning bugs to the kernel maintainer. Maybe this is really not so simple and additional kernel will not be accepted in official binary repos but I think it would be a valuable "feature" for arch to have if we can make it work. -- Massimiliano "mtorromeo" Torromeo Arch Linux TU GPG: 0xDA2EE423
On 22/04/14 06:03 AM, Allan McRae wrote:
Lets not draw this out too much further. I don't want to have to unsubscribe from another mailing list... But I am still going to have my say!
1) This was different than every other package in [community]. I know this because packages get added to [community] all the time without an email here. And saying discussion about adding PaX extensions was makes it different is naive as anyone who has been around here a short time could tell you that was never going to happen.
I didn't expect much from that proposal but it was worth trying. It's now clear to me that it's never going to happen. It was less of a pipe dream than enabling SELinux support in many packages + shipping complex policies via labels on files/directories :).
2) A few years back we specifically reduced the number of kernels in our repos to one. Then the LTS kernel appeared. Now this. The problem with adding a non-vanilla kernel to the repos is now for kernel bug reports we have to verify which kernel is running. If it is linux-grsec, we then need to figure out if the issue a generic linux one, or with the other patchset. This is a burden to all our the kernel maintainers and not just the packager and is part of the reason the variety of kernels was reduced.
Output from `uname -a` or `dmesg` is a pretty basic requirement for a kernel issue, especially since problems like /boot not being mounted and new upgrades installed to the wrong place often happen. I don't mind being the one who asks for this on any [linux] issues missing it. I'll have to dig up the old discussion because I wasn't around for it.
3) Now this is in [community] there will be an expectation of providing all the extras that are supposed to come with this. As decided, this will not be happening, but it will be expected and the question will need to be answered repeatedly.
Whether or not the kernel is in the repositories, I'm going to be maintaining the userspace components in [community] so there is going to an expectation of support (from me). Rather than providing the PaX exceptions via file attributes, it can be done via an RBAC policy. If I didn't think I could provide all of the extras, I wouldn't be taking on the responsibility. https://bugs.archlinux.org/task/39983 The downside of this solution from a user perspective is that it won't work for the PaX subset alone (linux-pax, which I have no interest in) so the hacks in the AUR will stay around. It also means extra pain for me since it's not yet written, but no one else has to worry about that.
4) A separate repo would have given actual number for interest in this. We all know the number of votes in the AUR is a crap metric and could have accumulated a long time ago. It would also have allowed us to see how important the above issues are. Despite assertions, many binary repos are well used by the Arch community.
If what ends up happening is that it sees little use and/or causes work for other people, it can be dropped again. I don't think we're ever going to find that out from an unofficial repository. At the very least moving it to [community] is going to make a bunch of people angry about it and we can get to a resolution faster.
5) There were objections to it being included in our binary repos. This does not happen often, but we usually discuss further and come to a consensus about inclusion. Ignoring those objections is not how our team works. Given the relatively few people who responded to the thread, we have no real idea what the support was (and I can provide unsupported anecdotes for support against or for inclusion of the package as well as the next person can...)
I know there were objections, but as you said few people felt like voicing their opinion here. A real vote would make sense but I don't see value in arguing in circles with the same few people. I'm not ignoring real issues that are raised, like the added work of distinguishing between which kernel users are using. I'm willing to put in whatever time is required to prevent this from increasing the workload of people who aren't interested in it. If that means stepping up and beginning to help with [linux] bug triage, I can do that.
In conclusion, this should have waited before being put in the repo. It might have ended up there anyway, it might not have. And I can not be bothered figuring it out as it will not affect me in any way.
If the end result is that it ends up back in the AUR, that's fine. I moved it because I didn't feel this was a productive discussion anymore. Arguing about this on the mailing list for weeks is going to cause much more pain than it simply being in [community].
participants (10)
-
Allan McRae
-
Bartłomiej Piotrowski
-
Daniel Micay
-
Florian Pritz
-
Gaetan Bisson
-
Lukas Jirkovsky
-
Massimiliano Torromeo
-
Sébastien Luttringer
-
Thomas Bächler
-
Tom Gundersen