[arch-dev-public] providing grsecurity in [community]

[Daniel Micay]

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.

[Allan McRae]

Post by Daniel Micay
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
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.

Post by Daniel Micay
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

[Daniel Micay]

Post by Allan McRae
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 :).

[Daniel Micay]

Post by Daniel Micay
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.

[Allan McRae]

Post by Daniel Micay

Post by Daniel Micay
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

[Thomas Bächler]

Post by Allan McRae

Post by Daniel Micay

Post by Daniel Micay
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.

[Allan McRae]

Post by Thomas Bächler

Post by Allan McRae

Post by Daniel Micay

Post by Daniel Micay
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

[Thomas Bächler]

Post by Allan McRae

Post by Thomas Bächler

Post by 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.

[Allan McRae]

Post by Thomas Bächler

Post by Allan McRae

Post by Thomas Bächler

Post by 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

[Thomas Bächler]

Post by Allan McRae
Getting off-topic...

Indeed.

Post by Allan McRae
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.

Post by Allan McRae
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.

[Thomas Bächler]

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?

[Daniel Micay]

Post by Thomas Bächler

Post by Allan McRae

Post by Daniel Micay

Post by Daniel Micay
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.

[Massimiliano Torromeo]

Post by Daniel Micay
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.

[Sébastien Luttringer]

Post by 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.

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?

[Daniel Micay]

Post by Sébastien Luttringer

Post by 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.

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.

[Sébastien Luttringer]

Post by Daniel Micay
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.

Post by Daniel Micay
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?

[Massimiliano Torromeo]

Post by Sébastien Luttringer

Post by Daniel Micay
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]?

[Sébastien Luttringer]

Post by Massimiliano Torromeo

Post by Sébastien Luttringer

Post by Daniel Micay
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 :)

[Daniel Micay]

Post by Sébastien Luttringer

Post by Daniel Micay
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.

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.

Post by Sébastien Luttringer

Post by Daniel Micay
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.

[Sébastien Luttringer]

Post by Daniel Micay
There's no problem with simply not building a VirtualBox module for the
linux-grsec kernel.

Being not consistent is a problem to me. But nothing which I can overcome.

Post by Daniel Micay
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.

Post by Daniel Micay
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 :)

[Daniel Micay]

Post by Sébastien Luttringer

Post by Daniel Micay
There's no problem with simply not building a VirtualBox module for the
linux-grsec kernel.

Being not consistent is a problem to me. But nothing which I can overcome.

Post by Daniel Micay
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.

Post by Sébastien Luttringer

Post by Daniel Micay
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.

[Gaetan Bisson]

Post by 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)?

[Daniel Micay]

Post by Gaetan Bisson

Post by 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.

Post by Gaetan Bisson
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.

Post by Gaetan Bisson
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.

Post by Gaetan Bisson
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.

[Daniel Micay]

Hey,
I'm replying to a thread on arch-dev-public with the same subject, here.
I'm maintaining the linux-grsec PKGBUILD in the AUR [0], wrote an
utility to set PaX flags [1] and host a repository for binary
grsecurity packages [2]. Although I like the idea of further
integrating grsecurity into Arch Linux, I have some points to
criticize on the planning proposals of Daniel Micay.

Post by Daniel Micay
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.

1. The very core of the grsecurity project is PaX. Without it, you
miss out on the most effective security features. Some contributing
linux-grsec users and me collected numerous binaries, which do not
work well with PaX and the according PaX features, which have to be
disabled in order to get them running. These are currently collected
in the linux-pax-flags utility [1]. For a clean grsecurity
integration, any flags on [core], [extra] and [community] should be
set before releasing linux-grsec in [community].

By leaving it disabled, I mean enabling the soft mode compilation option
and having it disabled out-of-the-box. The PaX features will still be
compiled in to the kernel. A user will still be able to install the
linux-pax-flags package from the AUR and disable soft mode via the
sysctl flag. As far as I can tell, it's also possible to deal with PaX
exceptions entirely via an RBAC profile, so shipping a default-enabled
RBAC profile would be an alternative.

Even with PaX in soft mode, grsecurity comes with a significant amount
of kernel hardening, miscellaneous features (like auditing), and of
course the RBAC implementation which fills the gap left by the removal
of AppArmor/TOMOYO support from the [core] kernel.

In my opinion, the RBAC support is the most significant feature in the
context of Arch Linux, where no other MAC solution has caught on. I
don't think SELinux is a good fit due to the complexity, opaque
configuration and necessary patches. The path-based policy files used in
AppArmor/TOMOYO are great, but RBAC provides more flexibility and
resolving the paths to inodes before enforcement prevents the link-based
issues.

Post by Daniel Micay
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.).

2. I think, manually setting the flags with a setfattr call in the
PKGBUILDs is a bad solution, because it is error-prone. The Gentoo
(hardened) folks integrated a new function for marking binaries with
PaX flags into the ebuild environment. I would prefer a solution like
this for Arch, too.
A new PKGBUILD variable for PaX flags to be set after install() would
also be a good solution (like PAX_FLAGS=(usr/bin/firefox:mr).
(There is also a utility which supports xattr flags by the Gentoo
hardened folks named paxctl-ng.)

I don't think there's an advantage to using install scripts rather than
the PKGBUILD itself. Pacman can learn to preserve extended attributes,
and it's much cleaner for this to be a tracked attribute of the package
rather than an ad-hoc hack.

Realistically, grsecurity is going to need a significant userbase (via
pkgstats) before a convincing argument can be made that this is
something Arch's packages should support. I don't think an AUR package
with 43 votes is anywhere close to enough proof that this is actually
going to see widespread usage.

Moving it to the repositories and providing a good out-of-the-box
experience is what needs to happen for this to gain the critical mass of
users (including other developers / trusted users) required to really
integrate it with the distribution.

I think the linux-pax-flags package can fill the gap until there's
either enough interest to maintain the flags across many packages, or
another solution like using RBAC is put in place.

3. I do not know, what the policy is, here, but I would prefer to
maintain the PKGBUILD myself, if it gets included in [community]. At
least, I would have expected to be integrated in the discussion a
little more. I did the work on it since beginning of 2012 and run it
on several machines since then. I think, a message like "I will adopt your
package in [community]" is a little rude. The gradm package was
already deleted from the AUR. On the linux-pax-flags AUR package,
Daniel commented that I would have to change it to work according to
his plans.

I'm aware that you've spent a long time maintaining the package, and I'm
thankful for the hard work you've put into it. However, I have a
different view on how the packaging should be done. I want switching
from the linux package to linux-grsec to be a painless experience
without any breakage. After booting into a working grsecurity
environment, users can tighten up the sysctl knobs to their liking and
begin setting grsec_lock=1 if they desire.

At the moment, booting into the grsecurity kernel starts off users in an
environment where many things like containers, profiling (perf), network
bandwidth displays, etc. no longer work. I realize that starting from
everything forbidden and building a whitelist is a nice ideal, but
booting into an install where the web browser can't be started and many
of your services fail to start is enough to drive most users away from
exploring further.

I want to mention another step, that would be necessary for a decent
integration of grsecurity and full ASLR: The activation of PIE/PIC.
This has been discussed a little on the Arch Linux BBS [3]. Allan
stated that "If there is a good way to add it for x86_64, it will be
considered." Maybe it is possible to come up with a good way.

There are a important few packages already using PIE like Chromium and
OpenSSH, although this is likely because the projects are
security-focused and set this in their build system.

Best regards,
henning
[0] https://aur.archlinux.org/packages/linux-grsec
[1] https://github.com/nning/linux-pax-flags
[2] https://arsch.orgizm.net
[3] https://bbs.archlinux.org/viewtopic.php?id=172955

[Tom Gundersen]

Post by Daniel Micay
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
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!

Post by 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. 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

Post by Daniel Micay
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.

[Daniel Micay]

Post by Tom Gundersen

Post by Daniel Micay
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
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!

Post by 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. 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.

Post by Tom Gundersen
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.

Post by Tom Gundersen
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!).

[Allan McRae]

Post by Tom Gundersen

Post by Daniel Micay
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
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!

Post by 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. 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

[Daniel Micay]

Post by Allan McRae

Post by Tom Gundersen

Post by Daniel Micay
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
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!

Post by 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. 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.

[Tom Gundersen]

Post by Daniel Micay
Users have been asking for MAC to be provided in the repositories for a
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

[Daniel Micay]

Post by Tom Gundersen

Post by Daniel Micay
Users have been asking for MAC to be provided in the repositories for a
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.

Post by Tom Gundersen
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.

[Daniel Micay]

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)

[Tom Gundersen]

Post by Daniel Micay

Post by Tom Gundersen

Post by Daniel Micay
Users have been asking for MAC to be provided in the repositories for a
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

[Daniel Micay]

Post by Tom Gundersen
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

[Tom Gundersen]

Post by Daniel Micay

Post by Tom Gundersen
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

[Daniel Micay]

Post by Tom Gundersen

Post by Daniel Micay

Post by Tom Gundersen
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.

[Florian Pritz]

Post by Daniel Micay
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.

[Daniel Micay]

Post by Florian Pritz

Post by Daniel Micay
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
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

[Connor Behan]

Post by Sébastien Luttringer

Post by Daniel Micay
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?

Because the use of closed-source kernel modules is inherently insecure
anyway.

[Sébastien Luttringer]

Post by Connor Behan

Post by Sébastien Luttringer

Post by Daniel Micay
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?

Because the use of closed-source kernel modules is inherently insecure
anyway.

We use closed-source components on our computer everyday (BIOS,
firmwares) because we trust hardware provider like Nvidia.
I wouldn't says that people who have Nvidia cards and run Nvidia drivers
are in an "inherently insecure" situation.

There are features in grsec which can be useful even with an Nvidia
module (hide others users process, restricted ipc, etc).

[Daniel Micay]

Post by Sébastien Luttringer

Post by Connor Behan

Post by Sébastien Luttringer

Post by Daniel Micay
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?

Because the use of closed-source kernel modules is inherently insecure
anyway.

We use closed-source components on our computer everyday (BIOS,
firmwares) because we trust hardware provider like Nvidia.
I wouldn't says that people who have Nvidia cards and run Nvidia drivers
are in an "inherently insecure" situation.

That's true, I'm just not interested in maintaining it myself because I
think it's a bit silly regardless :). I have no problem at all with
someone maintaining a DKMS nvidia package or grsec-specific package to
have it work. It doesn't harm me in any way to have the choice available.

Post by Sébastien Luttringer
(hide others users process)

This is actually one of the few grsecurity features that tricked
upstream. It's available as the `hidepid=2` mount option for /proc.
Sadly it breaks systemd to some extent due to the cgroup filesystem in
the kernel being inadequate (no namespacing support).

[Jan de Groot]

Post by Sébastien Luttringer
We use closed-source components on our computer everyday (BIOS,
firmwares) because we trust hardware provider like Nvidia.
I wouldn't says that people who have Nvidia cards and run Nvidia drivers
are in an "inherently insecure" situation.
There are features in grsec which can be useful even with an Nvidia
module (hide others users process, restricted ipc, etc).

The problem with Nvidia and grsecurity is that Nvidia doesn't test their
drivers on grsecurity kernels. With grsecurity you alter the way the
kernel works. If this alters the kernel in any way that the Nvidia
binary driver doesn't expect, you'll end up with something that makes
your system unstable.

Supporting Nvidia on vanilla kernels is a challenge now and then because
of the incompatible changes done in each version, but maintaining it for
a grsecurity patched kernel is even harder.

[Bartłomiej Piotrowski]

On Wed, 16 Apr 2014 00:09:55 -0400

Post by Daniel Micay
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
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?

[Daniel Micay]

Post by Bartłomiej Piotrowski
On Wed, 16 Apr 2014 00:09:55 -0400

Post by Daniel Micay
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
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...

[Gaetan Bisson]

Post by 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.

[Daniel Micay]

Post by Gaetan Bisson

Post by 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.

Post by Gaetan Bisson
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.

Post by Gaetan Bisson
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.

[Gaetan Bisson]

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

Post by 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.

[Daniel Micay]

Post by Gaetan Bisson
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

Post by 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.

Post by Gaetan Bisson
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).

[Massimiliano Torromeo]

Post by Gaetan Bisson
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...

[Gaetan Bisson]

Post by 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.

[Massimiliano Torromeo]

Post by Gaetan Bisson
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.

Post by Gaetan Bisson
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.

Post by Gaetan Bisson
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.

[Lukas Jirkovsky]

On Tue, Apr 22, 2014 at 10:44 AM, Massimiliano Torromeo

Post by Massimiliano Torromeo

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

[Allan McRae]

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

[Massimiliano Torromeo]

Post by Allan McRae
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...

Post by Allan McRae
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.

Post by Allan McRae
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.

Post by Allan McRae
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.

[Daniel Micay]

Post by Allan McRae
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 :).

Post by Allan McRae
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.

Post by Allan McRae
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.

Post by Allan McRae
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.

Post by Allan McRae
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.

Post by Allan McRae
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].

[Connor Behan]

Post by Daniel Micay
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.

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.

[Daniel Micay]

Post by Connor Behan

Post by Daniel Micay
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.

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.

I'm already maintaining the userspace components (gradm, paxtest,
checksec) that weren't already there (pax-utils) in [community] since
there's no political issue attached to them.

They're only just barely useful without the kernel though, and it's not
going be obvious where to get the corresponding kernel, unless I step
out of the usual conventions and have the wiki page talk about an
unofficial repository.

You can check that an RBAC profile is valid, but not load it. You can
verify that the Linux kernel's ASLR implementation is still too weak to
pass the `paxtest` tests from the early 2000s, but can't enable
something better. Checking for RELRO / PIE / stack canaries is a bit
more useful at least...

[Connor Behan]

[Including In-reply-to header so as not to break threading]

Post by Daniel Micay

Post by Allan McRae
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.

It's not just a matter of asking "what kernel are you using". You'll
probably have to ask the bug submitter to install linux from [core],
wait a day, and start comparing two sets of output.

But since you're prepared to do all the work, I don't think there's a
reason to drop linux-grsec. That should happen if / when another
packager has to work around it.

[Florian Pritz]

Post by Connor Behan
[Including In-reply-to header so as not to break threading]

Thanks for trying, but thunderbird still has issues here. Either it's
because there are 2 In-Reply-To headers or it's because the message id
in the one you added isn't surrounded by <>.

If adding the brackets doesn't help, try using mailman's archive and
clicking the links there (email addr link at the top of each post), that
should work just fine.

[Daniel Micay]

Post by Connor Behan
It's not just a matter of asking "what kernel are you using". You'll
probably have to ask the bug submitter to install linux from [core],
wait a day, and start comparing two sets of output.

Yeah, that's fine. If I'm already looking at them I might as well just
be helping with bug triage in general. It's usually as easy as asking a
few questions, pointing upstream or finding an existing bugzilla issue
to follow upstream progress.

The package could include a reminder in the install script to report
issues to the [community] issue tracker but I'm not sure it would be any
use.