Debian Bug report logs - #605090
linux-2.6: [RFC] Add a grsec featureset to Debian kernels

version graph

Package: src:linux; Maintainer for src:linux is Debian Kernel Team <debian-kernel@lists.debian.org>;

Reported by: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>

Date: Sat, 27 Nov 2010 11:42:01 UTC

Severity: wishlist

Tags: moreinfo, patch, upstream

Found in version linux-2.6/2.6.32-28

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, kees@debian.org, corsac@debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Sat, 27 Nov 2010 11:42:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
New Bug report received and forwarded. Copy sent to kees@debian.org, corsac@debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>. (Sat, 27 Nov 2010 11:42:06 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: linux-2.6: [RFC] Add a grsec featureset to Debian kernels
Date: Sat, 27 Nov 2010 12:36:29 +0100
[Message part 1 (text/plain, inline)]
Package: linux-2.6
Severity: wishlist
Tags: patch

Hey people,

First, please excuse me, I wasn't able to attend the Paris Miniconf and
thus the kernel summit, to propose this at that time. In any case, it's
not about Squeeze so there's still a lot of time to discuss this anyway.

I'd like to propose adding a new featureset to Debian kernels for
Wheezy, using grsecurity (http://www.grsecurity.net) patchset.

== Introduction

For people not familiar with grsecurity, the website as plenty of
information, but it's basically a hardening patch for the Linux kernel,
with major features beeing:

* a role-based access control system
* chroot() hardening
* memory protection using PaX (address randomization, arbitrary code execution prevention...)
* auditing

On the long term the best would be to upstream those features mainline,
and there's actually a process to do that from Ubuntu developers
(https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening), but in
the meantime having a grsecurity enabled kernel by default in Debian
would be really nice, in my opinion.

I know some people concerned about security have the habit to rebuild a
vanilla kernel anyway, but I think some people and organization would be
very interested by having a hardened kernel available in Debian, like
virtual hosting companies etc.

Doing it using a featureset is nice because it's not too intrusive (it's
not the default, it has to be chosen explicitly by the user and it's a
separate patch in the source package) and using the existing linux-2.6
package architecture it's actually quite easy.

== Implementation

Attached is a patch (against Debian linux-2.6 svn tree, for the
2.6.32-28 kernel, targeted to Squeeze) which do that. Basically it adds
the latest grsecurity patch, defines the variants where it's used and
the default config.

So far I've only tested on i386 and amd64 so I didn't do anything on
other architectures.

The grsecurity patch itself has been edited because some of the files
touched by the patch have already been patched by backports from latest
kernel versions, for example. It's not really hard work to do, and it
shouldn't be necessary for 2.6.36 kernel. The sha256sum of the edited
patch is:

8df533f83817542277e34fed9ae766b9059a144a73fe536d003569b17ac03f1f  grsecurity-2.2.0-2.6.32.25-201011151726+debian.patch

and I've attached it to the bug so it's easier to look at it
independantly of the svn patch.

Packages based on Squeeze kernel are available on
http://molly.corsac.net/~corsac/debian/kernel-grsec (it's apt-get'able
for amd64 or the dsc is present for those who just want to look at the
source package).

== Configuration

The KConfig is the one I use, which is open to discussion (like
everything else anyway). I've tried to be fairly secure, so some
features might not work for some people.

When possible, options are configurable at runtime using sysctl.
Attached is a tentative grsec.conf file to be put in /etc/sysctl.d so
people can fine-tune their installation. I didn't find a way to ship it
cleanly in a linux-image package so if anyone has an idea please say so.

For example, I've set kernel.grsecurity.disable_priv_io=0 so Xorg with
KMS works fine (it still won't work for non-KMS people though). Without
that, Xorg will fail to start with:

xf86EnableIOPorts: failed to set IOPL for I/O (operation not permitted)

so it's still clear why this happen and it's easy to fix.

I've tried to provide a default config which could fit for most people,
but I think it should be tuned by users in the end, so besides the gids
I'm not sure there's much to discuss.

=== Chroot

chroot sysctls are all configured to 1, but for people working on
Debian stuff, especially building in chroots, it might be a good idea to
set:

kernel.grsecurity.chroot_execlog=0
kernel.grsecurity.chroot_deny_chmod=0

=== Trusted Path Execution

Trusted Path Execution (TPE) is a way to restrict code execution.
Basically, binaries execution is forbidden from paths not owned by root.
It's configured using a GID (which I chose to be 500, once again it can
and should be discussed), it and can be opt-in (users belonging to the
group are prevented to execute “untrusted” binaries) or opt-out (only
people belonging to the group can execute “untrusted” binaries). I chose
the latter, to have a “secure by default” system.

=== Socket restrictions

The same kind of restrictions exist on socket, gid-based again: when you
add users to the relevant group, you deny them the right to create
sockets. I've chosen gids 501, 502 and 503 for respectively “all”
sockets, “client” sockets and “server” sockets. Once again, this is
configurable using sysctls.

== Maintenance

While I'd like to participate in the upstreaming effort, as noted above
I still think it'd be a good idea to have a grsecurity kernel for
Wheezy. As it means more work for the kernel team, I volunteer to give
help to handle that (in fact, I've already been following the linux-2.6
svn and the grsecurity release for some time).

== Rebuild the kernel

You can rebuild the kernel easily using the .dsc or using a linux-2.6
debcheckout. In the latter case, you have to apply the attached patch,
then:

* download linux-2.6.32.tar.z2
* python debian/bin/genorig.py ../linux-2.6.32.tar.bz2
* debian/rules orig
* debian/rules debian/control
* fakeroot debian/rules source
* fakeroot make -f debian/rules.gen binary-arch_amd64_grsec_amd64 (or
  any other target)

and follow the kernel handbook which is pretty nice:
http://kernel-handbook.alioth.debian.org/

== Conclusion

So, what do you think? Does it look like a good idea, are there some
blockers, some implementation details to discuss? Any comment is
welcome.

Thanks anyway for your time.

Regards,
-- 
Yves-Alexis Perez


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-grsec-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
[grsec.conf (text/plain, attachment)]
[add-grsec-featureset.patch (text/x-diff, attachment)]
[grsecurity-2.2.0-2.6.32.25-201011151726+debian.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Sun, 28 Nov 2010 00:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ben Hutchings <ben@decadent.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Sun, 28 Nov 2010 00:00:03 GMT) Full text and rfc822 format available.

Message #10 received at 605090@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: Yves-Alexis Perez <corsac@debian.org>
Cc: 605090@bugs.debian.org
Subject: Re: Bug#605090: linux-2.6: [RFC] Add a grsec featureset to Debian kernels
Date: Sat, 27 Nov 2010 23:56:09 +0000
[Message part 1 (text/plain, inline)]
On Sat, 2010-11-27 at 23:34 +0100, Yves-Alexis Perez wrote:
[...]
> == Configuration
> 
> The KConfig is the one I use, which is open to discussion (like
> everything else anyway). I've tried to be fairly secure, so some
> features might not work for some people.
> 
> When possible, options are configurable at runtime using sysctl.
> Attached is a tentative grsec.conf file to be put in /etc/sysctl.d so
> people can fine-tune their installation. I didn't find a way to ship it
> cleanly in a linux-image package so if anyone has an idea please say so.

I suggest you put it in a separate package e.g. linux-grsec-base and
have the image packages depend on or recommend it.

[...]
> === Trusted Path Execution
> 
> Trusted Path Execution (TPE) is a way to restrict code execution.
> Basically, binaries execution is forbidden from paths not owned by root.
> It's configured using a GID (which I chose to be 500, once again it can
> and should be discussed), it and can be opt-in (users belonging to the
> group are prevented to execute “untrusted” binaries) or opt-out (only
> people belonging to the group can execute “untrusted” binaries). I chose
> the latter, to have a “secure by default” system.
> 
> === Socket restrictions
> 
> The same kind of restrictions exist on socket, gid-based again: when you
> add users to the relevant group, you deny them the right to create
> sockets. I've chosen gids 501, 502 and 503 for respectively “all”
> sockets, “client” sockets and “server” sockets. Once again, this is
> configurable using sysctls.

These gids are in the 'dynamically assigned' range and must not be
configured into the kernel; see Debian policy §9.2.

[...]
> == Conclusion
> 
> So, what do you think? Does it look like a good idea, are there some
> blockers, some implementation details to discuss? Any comment is
> welcome.

Ideally I'd like to see the worthwhile bits merged upstream in some
form, with the most paranoid stuff in an LSM.  But I'm not going to
spend time on that myself.  If you're prepared to maintain this and
accept that it might not be kept for more than one release then I have
no objection.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Sun, 28 Nov 2010 09:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Sun, 28 Nov 2010 09:51:06 GMT) Full text and rfc822 format available.

Message #15 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: 605090@bugs.debian.org, kees@ubuntu.com
Subject: Re: Bug#605090: linux-2.6: [RFC] Add a grsec featureset to Debian kernels
Date: Sun, 28 Nov 2010 10:44:38 +0100
On sam., 2010-11-27 at 23:56 +0000, Ben Hutchings wrote:
> On Sat, 2010-11-27 at 23:34 +0100, Yves-Alexis Perez wrote:
> [...]
> > == Configuration
> > 
> > The KConfig is the one I use, which is open to discussion (like
> > everything else anyway). I've tried to be fairly secure, so some
> > features might not work for some people.
> > 
> > When possible, options are configurable at runtime using sysctl.
> > Attached is a tentative grsec.conf file to be put in /etc/sysctl.d so
> > people can fine-tune their installation. I didn't find a way to ship it
> > cleanly in a linux-image package so if anyone has an idea please say so.
> 
> I suggest you put it in a separate package e.g. linux-grsec-base and
> have the image packages depend on or recommend it.

Good point, especially if there's some work to do for adding groups, it
might be better to do that in a linux-grsec-base package than in the
linux-image one.
> 
> [...]
> > === Trusted Path Execution
> > 
> > Trusted Path Execution (TPE) is a way to restrict code execution.
> > Basically, binaries execution is forbidden from paths not owned by root.
> > It's configured using a GID (which I chose to be 500, once again it can
> > and should be discussed), it and can be opt-in (users belonging to the
> > group are prevented to execute “untrusted” binaries) or opt-out (only
> > people belonging to the group can execute “untrusted” binaries). I chose
> > the latter, to have a “secure by default” system.
> > 
> > === Socket restrictions
> > 
> > The same kind of restrictions exist on socket, gid-based again: when you
> > add users to the relevant group, you deny them the right to create
> > sockets. I've chosen gids 501, 502 and 503 for respectively “all”
> > sockets, “client” sockets and “server” sockets. Once again, this is
> > configurable using sysctls.
> 
> These gids are in the 'dynamically assigned' range and must not be
> configured into the kernel; see Debian policy §9.2.

On this, I'm not sure (but will ask base-passwd maintainers for advice).
The gids are configured in KConfig, but can be changed dynamically using
sysctl (though that means before procpcs is run the gid is still the
static one). It'd be nice to have the same gids on every system, but I'm
not sure it's really indispensable.
> 
> [...]
> > == Conclusion
> > 
> > So, what do you think? Does it look like a good idea, are there some
> > blockers, some implementation details to discuss? Any comment is
> > welcome.
> 
> Ideally I'd like to see the worthwhile bits merged upstream in some
> form, with the most paranoid stuff in an LSM.  But I'm not going to
> spend time on that myself.  If you're prepared to maintain this and
> accept that it might not be kept for more than one release then I have
> no objection.

Yeah, agreed about the upstreaming part (and I'll try to give some help
there too). And yes, ideally it shouldn't be kept too long before
reaching upstream.

I'll do some tests on a linux-grsec-base package and see about the gid
stuff and report back later.

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Fri, 03 Dec 2010 17:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Fri, 03 Dec 2010 17:03:03 GMT) Full text and rfc822 format available.

Message #20 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: 605090@bugs.debian.org, kees@ubuntu.com, corsac@debian.org
Subject: Re: Bug#605090: linux-2.6: [RFC] Add a grsec featureset to Debian kernels
Date: Fri, 03 Dec 2010 18:01:47 +0100
On dim., 2010-11-28 at 10:44 +0100, Yves-Alexis Perez wrote:
> On sam., 2010-11-27 at 23:56 +0000, Ben Hutchings wrote:
> > I suggest you put it in a separate package e.g. linux-grsec-base and
> > have the image packages depend on or recommend it.
> 
> Good point, especially if there's some work to do for adding groups, it
> might be better to do that in a linux-grsec-base package than in the
> linux-image one.

I've started doing that, I've put it in collab-maint for now. At the
moment it installs the sysctl.conf file and configure the groups at
installation. At one point, adding some documentation on PaX and
grsecurity stuff will be a good idea too.
> > 
> > [...]
> > > === Trusted Path Execution
> > > 
> > > Trusted Path Execution (TPE) is a way to restrict code execution.
> > > Basically, binaries execution is forbidden from paths not owned by root.
> > > It's configured using a GID (which I chose to be 500, once again it can
> > > and should be discussed), it and can be opt-in (users belonging to the
> > > group are prevented to execute “untrusted” binaries) or opt-out (only
> > > people belonging to the group can execute “untrusted” binaries). I chose
> > > the latter, to have a “secure by default” system.
> > > 
> > > === Socket restrictions
> > > 
> > > The same kind of restrictions exist on socket, gid-based again: when you
> > > add users to the relevant group, you deny them the right to create
> > > sockets. I've chosen gids 501, 502 and 503 for respectively “all”
> > > sockets, “client” sockets and “server” sockets. Once again, this is
> > > configurable using sysctls.
> > 
> > These gids are in the 'dynamically assigned' range and must not be
> > configured into the kernel; see Debian policy §9.2.
> 
> On this, I'm not sure (but will ask base-passwd maintainers for advice).
> The gids are configured in KConfig, but can be changed dynamically using
> sysctl (though that means before procpcs is run the gid is still the
> static one). It'd be nice to have the same gids on every system, but I'm
> not sure it's really indispensable.

Ok, after talking a bit with Brad Spengler it's a bit hard to make the
-proc user runtime-configurable because it'd mean either chown()ing the
whole /proc tree after running the sysctl, or something like that. A
boot parameter could be used too, but all in all, there are no real nice
way to achieve that. So I've requested from base-passwd maintainers the
allocation of 5 gids in the 60000-64999 range, and I'm waiting for their
comment.

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Sat, 04 Dec 2010 18:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Sat, 04 Dec 2010 18:51:06 GMT) Full text and rfc822 format available.

Message #25 received at 605090@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
Cc: Ben Hutchings <ben@decadent.org.uk>, 605090@bugs.debian.org, kees@ubuntu.com, corsac@debian.org
Subject: Re: Bug#605090: linux-2.6: [RFC] Add a grsec featureset to Debian kernels
Date: Sat, 4 Dec 2010 18:48:21 +0000
On Fri, Dec 03, 2010 at 06:01:47PM +0100, Yves-Alexis Perez wrote:
> On dim., 2010-11-28 at 10:44 +0100, Yves-Alexis Perez wrote:
> > On sam., 2010-11-27 at 23:56 +0000, Ben Hutchings wrote:
> > > These gids are in the 'dynamically assigned' range and must not be
> > > configured into the kernel; see Debian policy §9.2.
> > 
> > On this, I'm not sure (but will ask base-passwd maintainers for advice).
> > The gids are configured in KConfig, but can be changed dynamically using
> > sysctl (though that means before procpcs is run the gid is still the
> > static one). It'd be nice to have the same gids on every system, but I'm
> > not sure it's really indispensable.
> 
> Ok, after talking a bit with Brad Spengler it's a bit hard to make the
> -proc user runtime-configurable because it'd mean either chown()ing the
> whole /proc tree after running the sysctl, or something like that. A
> boot parameter could be used too, but all in all, there are no real nice
> way to achieve that. So I've requested from base-passwd maintainers the
> allocation of 5 gids in the 60000-64999 range, and I'm waiting for their
> comment.

I let Yves-Alexis know by private e-mail, but, for the public record, I
allocated these gids as requested.

  http://bzr.debian.org/scm/loggerhead/users/cjwatson/base-passwd/trunk/revision/155

-- 
Colin Watson                                       [cjwatson@debian.org]




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Tue, 04 Jan 2011 11:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Tue, 04 Jan 2011 11:27:06 GMT) Full text and rfc822 format available.

Message #30 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: 605090@bugs.debian.org
Subject: Updated patch
Date: Tue, 04 Jan 2011 12:25:29 +0100
[Message part 1 (text/plain, inline)]
I've put updated patches on
http://molly.corsac.net/~corsac/debian/kernel-grsec/patches/ (kernel is
built but not uploaded to packages/ since it's quite huge, will do that
at one point. Patches are attached to that mail too. 

The first one (add-grsecurity-featureset) is against the debian kernel
svn tree and add the featureset, while the second (debian-grsecurity) is
against the grsecurity upstream patch and adapts it to the current
debian kernel sources (removes the stuff already backported by the
kernel team etc.). 
I expect it to be really smaller for 2.6.37.

Patch and build procedure is:

  mkdir kernel-grsec
  cd kernel-grsec
  svn co svn://svn.debian.org/svn/kernel/dists/sid/linux-2.6
  cd linux-2.6
  curl http://molly.corsac.net/~corsac/debian/kernel-grsec/patches/add-grsecurity-featureset.patch |patch
  cd debian/patches/features/all/grsec
  wget http://grsecurity.net/stable/grsecurity-2.2.1-2.6.32.27-201101021130.patch
  cp grsecurity-2.2.1-2.6.32.27-201101021130{,+debian}.patch
  curl http://molly.corsac.net/~corsac/debian/kernel-grsec/patches/debian-grsecurity.patch |patch grsecurity-2.2.1-2.6.32.27-201101021130+debian.patch
  cd ../../../../../..
  wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.32.tar.bz2
  cd linux-2.6
  python debian/bin/genorig.py ../linux-2.6.32.tar.bz2
  debian/rules debian/control-real
  dpkg-buildpackage -us -uc (or fakeroot make -f debian/rules.gen binary-arch_amd64_grsec_amd64 or the variant you need)
   
See the kernel handbook (http://kernel-handbook.alioth.debian.org/) for
more info, and remember to check the various stuff you download,
sha1sums for the patches are:

e0a7d38f93a7857f2caceb13cac56eebb4b79530  add-grsecurity-featureset.patch
20c7c213f36f1a99a381d5fca563d9c22236e172  debian-grsecurity.patch

Comments welcome.

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM
[add-grsecurity-featureset.patch (text/x-patch, attachment)]
[debian-grsecurity.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Tue, 18 Jan 2011 17:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Tue, 18 Jan 2011 17:36:03 GMT) Full text and rfc822 format available.

Message #35 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: 605090@bugs.debian.org
Cc: kees@debian.org
Subject: Re: Updated patch
Date: Tue, 18 Jan 2011 18:32:50 +0100
[Message part 1 (text/plain, inline)]
On mar., 2011-01-04 at 12:25 +0100, Yves-Alexis Perez wrote:
> I've put updated patches on
> http://molly.corsac.net/~corsac/debian/kernel-grsec/patches/ (kernel is
> built but not uploaded to packages/ since it's quite huge, will do that
> at one point. Patches are attached to that mail too. 
> 
> The first one (add-grsecurity-featureset) is against the debian kernel
> svn tree and add the featureset, while the second (debian-grsecurity) is
> against the grsecurity upstream patch and adapts it to the current
> debian kernel sources (removes the stuff already backported by the
> kernel team etc.). 
> I expect it to be really smaller for 2.6.37. 

I've started working on 2.6.37 since Brad Sprengler recently released
the grsecurity patch for that kernel.

Result is the attached patches. Basically the only thing needed now is
to remove the localversion since we already get it from the featureset.

Initial packaging for linux-grsec-base is at
http://git.debian.org/?p=collab-maint/linux-grsec-base.git;a=summary if
needed.

Kernel team, what do you think? Could the patches be merged against
trunk? Config might still need some reviewing but that can be done once
people start testing the packages.

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM
[add-grsecurity-featureset-2.6.37.patch (text/x-patch, attachment)]
[debian_grsecurity-2.2.1-2.6.37-201101172105.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 26 Jan 2011 07:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 26 Jan 2011 07:30:03 GMT) Full text and rfc822 format available.

Message #40 received at 605090@bugs.debian.org (full text, mbox):

From: Bastian Blank <waldi@debian.org>
To: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>, 605090@bugs.debian.org
Cc: kees@debian.org
Subject: Re: Bug#605090: Updated patch
Date: Wed, 26 Jan 2011 08:25:48 +0100
On Tue, Jan 18, 2011 at 06:32:50PM +0100, Yves-Alexis Perez wrote:
> Index: debian/config/i386/grsec/defines
> ===================================================================
> --- debian/config/i386/grsec/defines	(revision 0)
> +++ debian/config/i386/grsec/defines	(revision 0)
> @@ -0,0 +1,9 @@
> +[base]
> +flavours:
> + 686

No new non-pae image.

> + amd64

Why?

> +[grsec]
> +flavours:
> + i386
> + amd64

What is this?

> Index: debian/config/i386/defines
> ===================================================================
> --- debian/config/i386/defines	(revision 16824)
> +++ debian/config/i386/defines	(working copy)
> @@ -3,6 +3,7 @@
>   openvz
>   vserver
>   xen
> + grsec

This was a sorted list.

> Index: debian/config/featureset-grsec/config
> ===================================================================
> --- debian/config/featureset-grsec/config	(revision 0)
> +++ debian/config/featureset-grsec/config	(revision 0)
> @@ -0,0 +1,152 @@
> +# Disable XEN for UDEREF support
> +CONFIG_XEN=n

Nope. Disabling core stuff needs more information.

> Index: debian/config/featureset-grsec/defines
> ===================================================================
> --- debian/config/featureset-grsec/defines	(revision 0)
> +++ debian/config/featureset-grsec/defines	(revision 0)
> @@ -0,0 +1,8 @@
> +[description]
> +part-short-grsec: Grsecurity and PaX protection

This is already too long.

> +[image]
> +depends: linux-grsec-base,, paxctl

Why is paxctl necessary? Also syntax error.

> --- debian/config/amd64/grsec/config	(revision 0)
> +++ debian/config/amd64/grsec/config	(revision 0)
> @@ -0,0 +1,5 @@
> +#
> +# PaX
> +#
> +CONFIG_PAX_PER_CPU_PGD=y
> +CONFIG_TASK_SIZE_MAX_SHIFT=42

Remove, no real settings here.

Bastian

-- 
Mind your own business, Spock.  I'm sick of your halfbreed interference.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 26 Jan 2011 08:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 26 Jan 2011 08:06:03 GMT) Full text and rfc822 format available.

Message #45 received at 605090@bugs.debian.org (full text, mbox):

From: Bastian Blank <waldi@debian.org>
To: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>, 605090@bugs.debian.org
Cc: kees@debian.org
Subject: Re: Bug#605090: Updated patch
Date: Wed, 26 Jan 2011 09:03:08 +0100
On Tue, Jan 18, 2011 at 06:32:50PM +0100, Yves-Alexis Perez wrote:
> I've started working on 2.6.37 since Brad Sprengler recently released
> the grsecurity patch for that kernel.

Is there VCS or is this just a code drop without information about
changes? I was not even able to find older patches. Who does code
reviews without that information?

The patch includes several modifications to selinux and random other
parts. Why are they not merged? Please show that they have been
submitted at least.

> Initial packaging for linux-grsec-base is at
> http://git.debian.org/?p=collab-maint/linux-grsec-base.git;a=summary if
> needed.

Why is this not part of the patch below?

Currently the patch only includes informations for i386 and amd64.
Please state your intentions about other architectures.

> +  [ Yves-Alexis Perez ]
> +  * Add a grsecurity featureset.

*nitpick* the patch calls it "Grsecurity".

> Index: debian/config/featureset-grsec/config
> ===================================================================
> --- debian/config/featureset-grsec/config	(revision 0)
> +++ debian/config/featureset-grsec/config	(revision 0)
> @@ -0,0 +1,152 @@
> +CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y

Please show why this should not be enabled globaly.

> +CONFIG_DEBUG_RODATA=y

x86 specific and default on.

Bastian

-- 
It would be illogical to kill without reason.
		-- Spock, "Journey to Babel", stardate 3842.4




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 26 Jan 2011 12:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 26 Jan 2011 12:33:03 GMT) Full text and rfc822 format available.

Message #50 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: Bastian Blank <waldi@debian.org>
Cc: 605090@bugs.debian.org, kees@debian.org
Subject: Re: Bug#605090: Updated patch
Date: Wed, 26 Jan 2011 13:29:14 +0100
[Message part 1 (text/plain, inline)]
First, thanks for your comments. I'm replying to both mails at once.

On mer., 2011-01-26 at 08:25 +0100, Bastian Blank wrote:
> On Tue, Jan 18, 2011 at 06:32:50PM +0100, Yves-Alexis Perez wrote:
> > Index: debian/config/i386/grsec/defines
> > ===================================================================
> > --- debian/config/i386/grsec/defines	(revision 0)
> > +++ debian/config/i386/grsec/defines	(revision 0)
> > @@ -0,0 +1,9 @@
> > +[base]
> > +flavours:
> > + 686
> 
> No new non-pae image.

Ok. In fact it's a good idea anyway because having PAE on means we have
NX which makes it easier for Grsecurity.

> 
> > + amd64
> 
> Why?

Because people using 64bit kernels on i386 might still want a grsec
variant.
> 
> > +[grsec]
> > +flavours:
> > + i386
> > + amd64
> 
> What is this?

I didn't really find the syntax for the “defines” files so I looked at
the others ones and xen has that [xen] section but maybe it's only used
internall by xen feature set. Will remove and check it doesn't break
anything.
> 
> > Index: debian/config/i386/defines
> > ===================================================================
> > --- debian/config/i386/defines	(revision 16824)
> > +++ debian/config/i386/defines	(working copy)
> > @@ -3,6 +3,7 @@
> >   openvz
> >   vserver
> >   xen
> > + grsec
> 
> This was a sorted list.

Fixed.
> 
> > Index: debian/config/featureset-grsec/config
> > ===================================================================
> > --- debian/config/featureset-grsec/config	(revision 0)
> > +++ debian/config/featureset-grsec/config	(revision 0)
> > @@ -0,0 +1,152 @@
> > +# Disable XEN for UDEREF support
> > +CONFIG_XEN=n
> 
> Nope. Disabling core stuff needs more information.

As the comment says, this is because UDEREF conflicts with XEN. The help
for the Kconfig option says:

config PAX_MEMORY_UDEREF
	bool "Prevent invalid userland pointer dereference"
	depends on X86 && !UML_X86 && !XEN
	select PAX_PER_CPU_PGD if X86_64
	help
	  By saying Y here the kernel will be prevented from dereferencing
	  userland pointers in contexts where the kernel expects only kernel
	  pointers.  This is both a useful runtime debugging feature and a
	  security measure that prevents exploiting a class of kernel bugs.

	  The tradeoff is that some virtualization solutions may experience
	  a huge slowdown and therefore you should not enable this feature
	  for kernels meant to run in such environments.  Whether a given VM
	  solution is affected or not is best determined by simply trying it
	  out, the performance impact will be obvious right on boot as this
	  mechanism engages from very early on.  A good rule of thumb is that
	  VMs running on CPUs without hardware virtualization support (i.e.,
	  the majority of IA-32 CPUs) will likely experience the slowdown.


I was assuming people wanting a grsec kernel would prefer having UDEREF
than XEN, but we might as well use the more conservative approach and
keep XEN enabled (and UDEREF disabled) and wait for feedback from users.
If bugreports are reported asking for UDEREF we can still revisite that
later.

> 
> > Index: debian/config/featureset-grsec/defines
> > ===================================================================
> > --- debian/config/featureset-grsec/defines	(revision 0)
> > +++ debian/config/featureset-grsec/defines	(revision 0)
> > @@ -0,0 +1,8 @@
> > +[description]
> > +part-short-grsec: Grsecurity and PaX protection
> 
> This is already too long.

What would be a good limit? Would “Grsecurity protection” work? As I
understand it it's added to the short description of the various
packages for that featureset so the total should be kept under 80 chars.
Looking at other featureset we could go for “Grsecurity support” but I'm
not sure it makes much sense.
> 
> > +[image]
> > +depends: linux-grsec-base,, paxctl
> 
> Why is paxctl necessary? Also syntax error.

PAX security features will enforce W^X mmap() (RANDMMAP), which some
application don't like (for example browsers with JIT javascript
engines). If one wants to use those application she has to disable it on
the executable itself, which is done using paxctl (which can be used to
enable/disable other protection type at runtime).

It's not strictly a dependency so it can be demoted to Recommends (or
moved to linux-grsec-base only) if you prefer. 

Syntax error is fixed.

> 
> > --- debian/config/amd64/grsec/config	(revision 0)
> > +++ debian/config/amd64/grsec/config	(revision 0)
> > @@ -0,0 +1,5 @@
> > +#
> > +# PaX
> > +#
> > +CONFIG_PAX_PER_CPU_PGD=y
> > +CONFIG_TASK_SIZE_MAX_SHIFT=42
> 
> Remove, no real settings here.

What do you mean by “real” settings? PAX_PER_CPU_PGD is enabled by
UDEREF and TASK_SIZE_MAX_SHIFT is set to 42 on amd64 because of how it
has been implemented without segmentation.

More info can be found there:
http://grsecurity.net/pipermail/grsecurity/2010-April/001024.html

Due to the performances concerns, I've decided to keep UDEREF and
KERNEXEC disabled on amd64 for now anyway, so those will disappear
(independently of the i386 decision).


On mer., 2011-01-26 at 09:03 +0100, Bastian Blank wrote:
On Tue, Jan 18, 2011 at 06:32:50PM +0100, Yves-Alexis Perez wrote:
> > I've started working on 2.6.37 since Brad Sprengler recently
released
> > the grsecurity patch for that kernel.
> 
> Is there VCS or is this just a code drop without information about
> changes? I was not even able to find older patches. Who does code
> reviews without that information?

No there is no VCS unfortunately. PAX part can be found
http://www.grsecurity.net/~paxguy1/ and I follow the RSS for grsecurity
on http://grsecurity.net/testing_rss.php


> 
> The patch includes several modifications to selinux and random other
> parts. Why are they not merged? Please show that they have been
> submitted at least.

As I already pointed out on the first mail, Brad Sprengler has already
said he wasn't interested in upstreaming stuff. There is an upstreaming
effort for some specific bits (like the
https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Upstream
Hardening I already gave). The selinux-specific part are related to the
effort to make function pointers structures read-only (or do you have
other specific parts in mind?).

> 
> > Initial packaging for linux-grsec-base is at
> > http://git.debian.org/?p=collab-maint/linux-grsec-base.git;a=summary
if
> > needed.
> 
> Why is this not part of the patch below?

The grsec.conf was attached to the initial bug report. As there is no
easy way to ship an external file in the linux-image, I was told it'd be
a better idea to make an external package and that helps because I can
do the user creation there and add a README.
> 
> Currently the patch only includes informations for i386 and amd64.
> Please state your intentions about other architectures.

For now I only tested on those architectures. Some hardening features
are not architecture-dependent so it'd be nice to have them everywhere,
but some are (especially the memory protection stuff, dependening on if
the architecture support segmentation or not, has an NX bit etc. For
example ARM support has been added recently
(http://grsecurity.net/news.php#armdev). As it might require some config
tuning I think other architectures should be enabled after some testing
and if users are interested in the featureset. Right now I guess it
makes sense for armel, ppc, sparc. I lack data for other arches.
> 
> > +  [ Yves-Alexis Perez ]
> > +  * Add a grsecurity featureset.
> 
> *nitpick* the patch calls it "Grsecurity".

Thanks, corrected.
> 
> > Index: debian/config/featureset-grsec/config
> > ===================================================================
> > --- debian/config/featureset-grsec/config	(revision 0)
> > +++ debian/config/featureset-grsec/config	(revision 0)
> > @@ -0,0 +1,152 @@
> > +CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y
> 
> Please show why this should not be enabled globaly.

Good point, it should. I'll make a separated bug report.
> 
> > +CONFIG_DEBUG_RODATA=y
> 
> x86 specific and default on.

Fixed.

Thank you for your review.

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 26 Jan 2011 13:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 26 Jan 2011 13:57:03 GMT) Full text and rfc822 format available.

Message #55 received at 605090@bugs.debian.org (full text, mbox):

From: Bastian Blank <waldi@debian.org>
To: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
Cc: 605090@bugs.debian.org, kees@debian.org
Subject: Re: Bug#605090: Updated patch
Date: Wed, 26 Jan 2011 14:54:43 +0100
On Wed, Jan 26, 2011 at 01:29:14PM +0100, Yves-Alexis Perez wrote:
> On mer., 2011-01-26 at 08:25 +0100, Bastian Blank wrote:
> > On Tue, Jan 18, 2011 at 06:32:50PM +0100, Yves-Alexis Perez wrote:
> > > +# Disable XEN for UDEREF support
> As the comment says, this is because UDEREF conflicts with XEN. The help
> for the Kconfig option says:

And why does it conflict with XEN? The documentation does not provide
any specific pointers. From my view it is easy, it have to run on my
test environments that features heavy virtualization of different types.

> > > +part-short-grsec: Grsecurity and PaX protection
> > This is already too long.
> What would be a good limit? Would “Grsecurity protection” work?

Should be okay.

> > > +depends: linux-grsec-base,, paxctl
> > Why is paxctl necessary? Also syntax error.
> It's not strictly a dependency so it can be demoted to Recommends (or
> moved to linux-grsec-base only) if you prefer. 

Okay.

> > > +++ debian/config/amd64/grsec/config	(revision 0)
> > Remove, no real settings here.
> What do you mean by “real” settings? PAX_PER_CPU_PGD is enabled by
> UDEREF and TASK_SIZE_MAX_SHIFT is set to 42 on amd64 because of how it
> has been implemented without segmentation.

Real settings can be modified by the user, this two can't.

> On mer., 2011-01-26 at 09:03 +0100, Bastian Blank wrote:
> On Tue, Jan 18, 2011 at 06:32:50PM +0100, Yves-Alexis Perez wrote:
> > > I've started working on 2.6.37 since Brad Sprengler recently
> released
> > > the grsecurity patch for that kernel.
> > Is there VCS or is this just a code drop without information about
> > changes? I was not even able to find older patches. Who does code
> > reviews without that information?
> No there is no VCS unfortunately.

You will need a git repository in the future. So please start with it.

> > The patch includes several modifications to selinux and random other
> > parts. Why are they not merged? Please show that they have been
> > submitted at least.
> As I already pointed out on the first mail, Brad Sprengler has already
> said he wasn't interested in upstreaming stuff.

What Brad wants or don't want is irrelevant here. While the patch policy
for the main kernel is rather strict, other featuresets can incorporate
more changes. However this is no free ticket to push anything into it.

>                                                 There is an upstreaming
> effort for some specific bits (like the
> https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Upstream
> Hardening I already gave).

Please explain how this is related to Grsecurity.

>                            The selinux-specific part are related to the
> effort to make function pointers structures read-only (or do you have
> other specific parts in mind?).

Everything that is not directly related to Grsecurity or PaX. And there
is a lot.

> > > http://git.debian.org/?p=collab-maint/linux-grsec-base.git;a=summary
> if
> > > needed.
> > Why is this not part of the patch below?
> The grsec.conf was attached to the initial bug report. As there is no
> easy way to ship an external file in the linux-image, I was told it'd be
> a better idea to make an external package and that helps because I can
> do the user creation there and add a README.

External _binary_ package, not source package.

> > > +CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y
> > Please show why this should not be enabled globaly.
> Good point, it should. I'll make a separated bug report.

No need for a bug.

> > > +CONFIG_DEBUG_RODATA=y
> Fixed.

The current patch even marks it as broken.

Bastian

-- 
Beam me up, Scotty, there's no intelligent life down here!




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 26 Jan 2011 18:09:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 26 Jan 2011 18:09:05 GMT) Full text and rfc822 format available.

Message #60 received at 605090@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
Cc: Bastian Blank <waldi@debian.org>, 605090@bugs.debian.org
Subject: Re: Bug#605090: Updated patch
Date: Wed, 26 Jan 2011 10:07:15 -0800
Hi,

On Wed, Jan 26, 2011 at 01:29:14PM +0100, Yves-Alexis Perez wrote:
> Due to the performances concerns, I've decided to keep UDEREF and
> KERNEXEC disabled on amd64 for now anyway, so those will disappear
> (independently of the i386 decision).

This doesn't seem like a good idea. The bulk of heavy-duty kernel hardening
is with KERNEXEC and UDEREF. If someone is interested in speed, they can
choose i386. But if someone wants a hardened kernel and amd64, they should
have the option. I'd leave those on for both.

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 26 Jan 2011 21:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 26 Jan 2011 21:00:03 GMT) Full text and rfc822 format available.

Message #65 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: Bastian Blank <waldi@debian.org>
Cc: 605090@bugs.debian.org, kees@debian.org
Subject: Re: Bug#605090: Updated patch
Date: Wed, 26 Jan 2011 21:56:35 +0100
[Message part 1 (text/plain, inline)]
On mer., 2011-01-26 at 14:54 +0100, Bastian Blank wrote: 
> On Wed, Jan 26, 2011 at 01:29:14PM +0100, Yves-Alexis Perez wrote:
> > On mer., 2011-01-26 at 08:25 +0100, Bastian Blank wrote:
> > > On Tue, Jan 18, 2011 at 06:32:50PM +0100, Yves-Alexis Perez wrote:
> > > > +# Disable XEN for UDEREF support
> > As the comment says, this is because UDEREF conflicts with XEN. The help
> > for the Kconfig option says:
> 
> And why does it conflict with XEN? The documentation does not provide
> any specific pointers. From my view it is easy, it have to run on my
> test environments that features heavy virtualization of different types.

UDEREF and KERNEXEC makes intensive use of segmentation and tune some
low level stuff like the linker and thus breaks assumptions on which XEN
counts.

> 
> > > > +++ debian/config/amd64/grsec/config	(revision 0)
> > > Remove, no real settings here.
> > What do you mean by “real” settings? PAX_PER_CPU_PGD is enabled by
> > UDEREF and TASK_SIZE_MAX_SHIFT is set to 42 on amd64 because of how it
> > has been implemented without segmentation.
> 
> Real settings can be modified by the user, this two can't.

I still don't get it. I had the impression that
debian/config/<arch>/<featureset>/config role was to override
debian/config/featureset-<featureset>/config with arch-specific config
items.
> 
> > On mer., 2011-01-26 at 09:03 +0100, Bastian Blank wrote:
> > On Tue, Jan 18, 2011 at 06:32:50PM +0100, Yves-Alexis Perez wrote:
> > > > I've started working on 2.6.37 since Brad Sprengler recently
> > released
> > > > the grsecurity patch for that kernel.
> > > Is there VCS or is this just a code drop without information about
> > > changes? I was not even able to find older patches. Who does code
> > > reviews without that information?
> > No there is no VCS unfortunately.
> 
> You will need a git repository in the future. So please start with it.

I was kind-of waiting for the git linux-2.6 transition. I contacted Ben
Hutchings about his linux-2.6 tree on git.debian.org but he told me to
rather directly request to join the alioth project and don't wait for
the transition to happen. 
> 
> > > The patch includes several modifications to selinux and random other
> > > parts. Why are they not merged? Please show that they have been
> > > submitted at least.
> > As I already pointed out on the first mail, Brad Sprengler has already
> > said he wasn't interested in upstreaming stuff.
> 
> What Brad wants or don't want is irrelevant here. While the patch policy
> for the main kernel is rather strict, other featuresets can incorporate
> more changes. However this is no free ticket to push anything into it.
> 
> >                                                 There is an upstreaming
> > effort for some specific bits (like the
> > https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Upstream
> > Hardening I already gave).
> 
> Please explain how this is related to Grsecurity.

Well, as the page explains, this is about upstreaming a lot of kernel
and userland protections provided by Grsecurity: NX, ASLR, symbols
hiding...

> 
> >                            The selinux-specific part are related to the
> > effort to make function pointers structures read-only (or do you have
> > other specific parts in mind?).
> 
> Everything that is not directly related to Grsecurity or PaX. And there
> is a lot.

The patch is only about Grsecurity and PaX protection. But while PaX is
mostly about memory protection, Grsecurity has multiple features:

* the RBAC system
* chroot protection
* info leak reduction
* arbitrary code execution prevention (both in kernel and in userland)

and that means it const-ify function pointers, it forces struct
initialization etc.

As said in the first mail, the Grsecurity patches usually cherry-picks
security bugfixes which are not yet in a released kernel. As the kernel
teams already do it, I remove those bits from the grsecurity patch. In
2.6.37 there's no need for that yet but I do it for the 2.6.32 I'm
tracking too. 
> 
> > > > http://git.debian.org/?p=collab-maint/linux-grsec-base.git;a=summary
> > if
> > > > needed.
> > > Why is this not part of the patch below?
> > The grsec.conf was attached to the initial bug report. As there is no
> > easy way to ship an external file in the linux-image, I was told it'd be
> > a better idea to make an external package and that helps because I can
> > do the user creation there and add a README.
> 
> External _binary_ package, not source package.

I have to admit I don't know how to integrate a new binary package like
this using the existing linux-2.6 source package, but I'm not at all
opposed to include it in order to keep things at the same place. But
does the linux-2.6 architecture permits that? 
> 
> > > > +CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y
> > > Please show why this should not be enabled globaly.
> > Good point, it should. I'll make a separated bug report.
> 
> No need for a bug.

Ok. 
> 
> > > > +CONFIG_DEBUG_RODATA=y
> > Fixed.
> 
> The current patch even marks it as broken.

Yeah, right. PaX enforces itself readonly stuff (which is why it adds a
lot of const stuff) which are not really compatible with DEBUG_RODATA.

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 26 Jan 2011 23:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <max@stro.at>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 26 Jan 2011 23:33:03 GMT) Full text and rfc822 format available.

Message #70 received at 605090@bugs.debian.org (full text, mbox):

From: maximilian attems <max@stro.at>
To: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>, 605090@bugs.debian.org
Cc: kees@debian.org
Subject: Re: Bug#605090: Updated patch
Date: Thu, 27 Jan 2011 00:29:27 +0100
On Tue, 18 Jan 2011, Yves-Alexis Perez wrote:

> 
> Kernel team, what do you think? Could the patches be merged against
> trunk? Config might still need some reviewing but that can be done once
> people start testing the packages.

What follows is my personal view, in short what I miss most is an
assessement of the involved cost of this specific "feature" branch.

first of all merging a patch that deviates from mainline for an
eternety and shows zero interest of upstream merging is not a 
good candidate. You get longterm plenty of cost versus allmost
no benefit. I'm quite unsure that this patch benefits Debian.
From a distant past look it was in fact quite untastefull.

The second trouble is that I question your understanding of this patch.
(viewing the way you answered waldi's questions).

Third beside "security" theatre what is gained by it?

Fourth why not invest the time for Wheezy and have finally the mainline
and security backed SELinux ready. This seems like a much better time
investment.

Fifth the ninties are over, an upstream that still doesn't use an VSC
seems very untrustworthy.


happy hacking

-- 
maks




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Thu, 27 Jan 2011 21:45:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 27 Jan 2011 21:45:10 GMT) Full text and rfc822 format available.

Message #75 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: maximilian attems <max@stro.at>
Cc: 605090@bugs.debian.org, kees@debian.org
Subject: Re: Bug#605090: Updated patch
Date: Thu, 27 Jan 2011 22:41:44 +0100
[Message part 1 (text/plain, inline)]
On jeu., 2011-01-27 at 00:29 +0100, maximilian attems wrote:
> On Tue, 18 Jan 2011, Yves-Alexis Perez wrote:
> 
> > 
> > Kernel team, what do you think? Could the patches be merged against
> > trunk? Config might still need some reviewing but that can be done once
> > people start testing the packages.
> 
> What follows is my personal view, in short what I miss most is an
> assessement of the involved cost of this specific "feature" branch.

I follow both 2.6.32 (“stable”) and 2.6.36 then 2.6.37 (“test”) releases
since few weeks, integrating them to the linux-2.6 (sid and trunk)
source packages. There's an rss feed with a changelog which I use to see
what changed and apply the debian diff (which is about removing the
“localpart” in 2.6.37 and removing the security bugfixes in 2.6.32).
Right now I'm doing it manually (applying against a tree after
debian/rules source and fixing the rej) and intend to switch to git when
the migration is done. For 2.6.37 it's immediate, for 2.6.32 it's a bit
longer since I need to do the removal part. Then there is the testing.
Nothing really specific there.
> 
> first of all merging a patch that deviates from mainline for an
> eternety and shows zero interest of upstream merging is not a 
> good candidate. You get longterm plenty of cost versus allmost
> no benefit.

There's no interest in upstreaming from grsec/pax teams but some other
people are indeed interested in upstreaming those kind of features. In
the meantime, having a featureset is a nice way to move along.

>  I'm quite unsure that this patch benefits Debian.

A lot of Debian users build their own kernels for integrating grsecurity
patch and I really think they would be interested in having it directly
in the distribution. Though it's not exactly the same situation
(especially wrt. the config) I think Gentoo Hardened kernel is really
appreciated. Professional as well a personal people do use it daily
because it's critical in their work. If we can provide them a package I
think they'll be grateful.

> From a distant past look it was in fact quite untastefull.
> 
> The second trouble is that I question your understanding of this patch.
> (viewing the way you answered waldi's questions).

Indeed there are parts in that patch I wouldn't be able to explain
precisely, especially very low-level stuff, linker, sparc64 assembly... 
> 
> Third beside "security" theatre what is gained by it?

I think the whole point of the “Grsecurity” patchset is “security”.
> 
> Fourth why not invest the time for Wheezy and have finally the mainline
> and security backed SELinux ready. This seems like a much better time
> investment.

Trying to push some bits upstream is indeed a good time investment
(though it takes time and I really think moving forward now is a good
idea). But Grsecurity isn't a drop-in replacement for SELinux. Some
features like RBAC and auditing have some similarities, but all the
hardening and memory protection really have nothing to do with that.
> 
> Fifth the ninties are over, an upstream that still doesn't use an VSC
> seems very untrustworthy.

I didn't say anything about upstream VCS usage. Indeed it'd be nice to
have a repository available for users and I'm sure openvz and vserver
patchsets maintainers would agree.


Thank you for your comments anyway.

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Thu, 27 Jan 2011 22:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Campbell <ijc@hellion.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 27 Jan 2011 22:24:03 GMT) Full text and rfc822 format available.

Message #80 received at 605090@bugs.debian.org (full text, mbox):

From: Ian Campbell <ijc@hellion.org.uk>
To: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>, 605090@bugs.debian.org
Subject: Re: Bug#605090: Updated patch
Date: Thu, 27 Jan 2011 22:21:37 +0000
[Message part 1 (text/plain, inline)]
On Wed, 2011-01-26 at 13:29 +0100, Yves-Alexis Perez wrote: 
> 
> config PAX_MEMORY_UDEREF
>         bool "Prevent invalid userland pointer dereference"
>         depends on X86 && !UML_X86 && !XEN
>         select PAX_PER_CPU_PGD if X86_64
>         help
>           By saying Y here the kernel will be prevented from dereferencing
>           userland pointers in contexts where the kernel expects only kernel
>           pointers.  This is both a useful runtime debugging feature and a
>           security measure that prevents exploiting a class of kernel bugs.
> 
>           The tradeoff is that some virtualization solutions may experience
>           a huge slowdown and therefore you should not enable this feature
>           for kernels meant to run in such environments.  Whether a given VM
>           solution is affected or not is best determined by simply trying it
>           out, the performance impact will be obvious right on boot as this
>           mechanism engages from very early on.  A good rule of thumb is that
>           VMs running on CPUs without hardware virtualization support (i.e.,
>           the majority of IA-32 CPUs) will likely experience the slowdown.
> 
> 
> I was assuming people wanting a grsec kernel would prefer having UDEREF
> than XEN, but we might as well use the more conservative approach and
> keep XEN enabled (and UDEREF disabled) and wait for feedback from users.
> If bugreports are reported asking for UDEREF we can still revisite that
> later. 

Can you describe how it works and what makes it slow for Xen?

It sounds like strictly speaking it's not "broken" under Xen as such,
it's just not recommended since it is effectively unusable with certain
guest types. It's not clear if the comment is referring to PV guests or
HVM guests using shadow mode. i.e. It's not clear if "hardware
virtualization support" refers to HVM generally or more specifically to
HAP (hardware assisted paging). 

The problem with disabling CONFIG_XEN in this way is that it will also
disable the Xen PVHVM drivers which enhance disk and network performance
for HVM guests.

Hardware with HVM is really quite common these days and HAP has been
around for quite a while too so it's not as rare as the comment makes
out.

I think that if we are going to have this flavour then it should have
both Xen and grsec. That allows it to work for people using HVM (+/- HAP
as discussed above) guests. For people with PV guests they can either
choose dog-slow-but-secure or fast. Maybe that's not much of a
choice ;-)

Ian.

-- 
Ian Campbell

Be free and open and breezy!  Enjoy!  Things won't get any better so
get used to it.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Tue, 01 Feb 2011 15:30:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Tue, 01 Feb 2011 15:30:07 GMT) Full text and rfc822 format available.

Message #85 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: Ian Campbell <ijc@hellion.org.uk>
Cc: 605090@bugs.debian.org
Subject: Re: Bug#605090: Updated patch
Date: Tue, 01 Feb 2011 16:26:53 +0100
[Message part 1 (text/plain, inline)]
On jeu., 2011-01-27 at 22:21 +0000, Ian Campbell wrote:
> > I was assuming people wanting a grsec kernel would prefer having UDEREF
> > than XEN, but we might as well use the more conservative approach and
> > keep XEN enabled (and UDEREF disabled) and wait for feedback from users.
> > If bugreports are reported asking for UDEREF we can still revisite that
> > later. 
> 
> Can you describe how it works and what makes it slow for Xen?

UDEREF tries to prevent the kernel to dereference pointers to userland
by tuning the segmentation model, modifying the global descriptor table
and the various functions copying from/to userspace. If Xen (or another
hypervisor) has assumptions about the segment layouts, then those
assumptions will break on a grsec kernel. You can find more information
there: http://grsecurity.net/~spender/uderef.txt (and the amd64
announcement there
http://grsecurity.net/pipermail/grsecurity/2010-April/001024.html)

> 
> It sounds like strictly speaking it's not "broken" under Xen as such,
> it's just not recommended since it is effectively unusable with certain
> guest types. It's not clear if the comment is referring to PV guests or
> HVM guests using shadow mode. i.e. It's not clear if "hardware
> virtualization support" refers to HVM generally or more specifically to
> HAP (hardware assisted paging). 
> 
> The problem with disabling CONFIG_XEN in this way is that it will also
> disable the Xen PVHVM drivers which enhance disk and network performance
> for HVM guests.
> 
> Hardware with HVM is really quite common these days and HAP has been
> around for quite a while too so it's not as rare as the comment makes
> out.
> 
> I think that if we are going to have this flavour then it should have
> both Xen and grsec. That allows it to work for people using HVM (+/- HAP
> as discussed above) guests. For people with PV guests they can either
> choose dog-slow-but-secure or fast. Maybe that's not much of a
> choice ;-)
> 

I've tried to build a kernel with CONFIG_XEN and CONFIG_PAX_UDEREF.
Build succeeds and it boots fine, but I don't have a working xen setup
to try it (wether on host or on guest). I've tried to run a kvm guest
(using a standard kernel) and it's slow as hell, but it was the same
without CONFIG_XEN. It'd be worth trying on i386 though.

I can provide you that kernel if you want to try yourself (or only the
edited patch removing the conflict against CONFIG_XEN, though it's
trivial to do).

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 09 Feb 2011 17:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <max@stro.at>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 09 Feb 2011 17:54:03 GMT) Full text and rfc822 format available.

Message #90 received at 605090@bugs.debian.org (full text, mbox):

From: maximilian attems <max@stro.at>
To: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
Cc: 605090@bugs.debian.org, kees@debian.org
Subject: Re: Bug#605090: Updated patch
Date: Wed, 9 Feb 2011 18:51:02 +0100
On Thu, 27 Jan 2011, Yves-Alexis Perez wrote:

> On jeu., 2011-01-27 at 00:29 +0100, maximilian attems wrote:
> > On Tue, 18 Jan 2011, Yves-Alexis Perez wrote:
> > 
> > > 
> > > Kernel team, what do you think? Could the patches be merged against
> > > trunk? Config might still need some reviewing but that can be done once
> > > people start testing the packages.
> > 
> > What follows is my personal view, in short what I miss most is an
> > assessement of the involved cost of this specific "feature" branch.
> 
> I follow both 2.6.32 (“stable”) and 2.6.36 then 2.6.37 (“test”) releases
> since few weeks, integrating them to the linux-2.6 (sid and trunk)
> source packages. There's an rss feed with a changelog which I use to see
> what changed and apply the debian diff (which is about removing the
> “localpart” in 2.6.37 and removing the security bugfixes in 2.6.32).
> Right now I'm doing it manually (applying against a tree after
> debian/rules source and fixing the rej) and intend to switch to git when
> the migration is done. For 2.6.37 it's immediate, for 2.6.32 it's a bit
> longer since I need to do the removal part. Then there is the testing.
> Nothing really specific there.

"Removing the security bugfixes", that doesn't sound like a good roead to go.


> > first of all merging a patch that deviates from mainline for an
> > eternety and shows zero interest of upstream merging is not a 
> > good candidate. You get longterm plenty of cost versus allmost
> > no benefit.
> 
> There's no interest in upstreaming from grsec/pax teams but some other
> people are indeed interested in upstreaming those kind of features. In
> the meantime, having a featureset is a nice way to move along.

That is a wrong look at the problem, once it's upstream everybody profits.
So this looks more like a dead end road.
 
> >  I'm quite unsure that this patch benefits Debian.
> 
> A lot of Debian users build their own kernels for integrating grsecurity
> patch and I really think they would be interested in having it directly
> in the distribution. Though it's not exactly the same situation
> (especially wrt. the config) I think Gentoo Hardened kernel is really
> appreciated. Professional as well a personal people do use it daily
> because it's critical in their work. If we can provide them a package I
> think they'll be grateful.

Hmm
Openvz was once scheduled to be merged mainline and back then people
were actively workin on it. We are dropping it as mainline has a very
interesting alternative.

Considering that SELinux is inside the kernel it be much better time
investment to polish that. What makes you think that a Debian Hardened
with proper SELinux wouldn't be really appreciated!?

 
> > Third beside "security" theatre what is gained by it?
> 
> I think the whole point of the “Grsecurity” patchset is “security”.

I like the way you put it under brackets and think that
security is gained by just applying this patchset.

> > Fourth why not invest the time for Wheezy and have finally the mainline
> > and security backed SELinux ready. This seems like a much better time
> > investment.
> 
> Trying to push some bits upstream is indeed a good time investment
> (though it takes time and I really think moving forward now is a good
> idea). But Grsecurity isn't a drop-in replacement for SELinux. Some
> features like RBAC and auditing have some similarities, but all the
> hardening and memory protection really have nothing to do with that.

Be more precise in what SELinux can't do for you?
(Emulating NX for bad hardware doesn't count these days).

> > Fifth the ninties are over, an upstream that still doesn't use an VSC
> > seems very untrustworthy.
> 
> I didn't say anything about upstream VCS usage. Indeed it'd be nice to
> have a repository available for users and I'm sure openvz and vserver
> patchsets maintainers would agree.

Been there and we are leaving both.
 

Happy hacking

-- 
maks




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 09 Feb 2011 18:21:17 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 09 Feb 2011 18:21:17 GMT) Full text and rfc822 format available.

Message #95 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: maximilian attems <max@stro.at>
Cc: 605090@bugs.debian.org, kees@debian.org
Subject: Re: Bug#605090: Updated patch
Date: Wed, 09 Feb 2011 19:20:26 +0100
[Message part 1 (text/plain, inline)]
On mer., 2011-02-09 at 18:51 +0100, maximilian attems wrote:
> > I follow both 2.6.32 (“stable”) and 2.6.36 then 2.6.37 (“test”) releases
> > since few weeks, integrating them to the linux-2.6 (sid and trunk)
> > source packages. There's an rss feed with a changelog which I use to see
> > what changed and apply the debian diff (which is about removing the
> > “localpart” in 2.6.37 and removing the security bugfixes in 2.6.32).
> > Right now I'm doing it manually (applying against a tree after
> > debian/rules source and fixing the rej) and intend to switch to git when
> > the migration is done. For 2.6.37 it's immediate, for 2.6.32 it's a bit
> > longer since I need to do the removal part. Then there is the testing.
> > Nothing really specific there.
> 
> "Removing the security bugfixes", that doesn't sound like a good roead to go.

Well, I'm only removing them from the Grsecurity patch because they're
already included in the Debian packaging...
> 
> 
> > > first of all merging a patch that deviates from mainline for an
> > > eternety and shows zero interest of upstream merging is not a 
> > > good candidate. You get longterm plenty of cost versus allmost
> > > no benefit.
> > 
> > There's no interest in upstreaming from grsec/pax teams but some other
> > people are indeed interested in upstreaming those kind of features. In
> > the meantime, having a featureset is a nice way to move along.
> 
> That is a wrong look at the problem, once it's upstream everybody profits.
> So this looks more like a dead end road.

I agree that upstreaming is better but I still think it's useful to have
a featureset in the meantime (and I think people are interested in
that).

> Hmm
> Openvz was once scheduled to be merged mainline and back then people
> were actively workin on it. We are dropping it as mainline has a very
> interesting alternative.

Again, I'm all in favor of dropping it when mainline has a viable
alternative. But it's not currently the case.
> 
> Considering that SELinux is inside the kernel it be much better time
> investment to polish that. What makes you think that a Debian Hardened
> with proper SELinux wouldn't be really appreciated!?

I'm sure a Debian Hardened with SELinux would be really appreciated.

> 
> Be more precise in what SELinux can't do for you?
> (Emulating NX for bad hardware doesn't count these days).

Again, SELinux is about access control policies, in order to reduce
propagation when a process is compromised. It's not about hardening the
kernel and userland to prevent this compromission. At most you could
compare it with the RBAC part of Grsecurity, but there's also the chroot
protection one, the PaX memory protections, auditing and the various
hardening features which you can find on the website.

Thanks for your comments.
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 09 Feb 2011 18:42:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to micah anderson <micah@riseup.net>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 09 Feb 2011 18:42:12 GMT) Full text and rfc822 format available.

Message #100 received at 605090@bugs.debian.org (full text, mbox):

From: micah anderson <micah@riseup.net>
To: maximilian attems <max@stro.at>, 605090@bugs.debian.org, Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
Cc: 605090@bugs.debian.org, kees@debian.org
Subject: Re: Bug#605090: Updated patch
Date: Wed, 09 Feb 2011 13:38:25 -0500
[Message part 1 (text/plain, inline)]
On Wed, 9 Feb 2011 18:51:02 +0100, maximilian attems <max@stro.at> wrote: 
> 
> > > first of all merging a patch that deviates from mainline for an
> > > eternety and shows zero interest of upstream merging is not a 
> > > good candidate. You get longterm plenty of cost versus allmost
> > > no benefit.
> > 
> > There's no interest in upstreaming from grsec/pax teams but some other
> > people are indeed interested in upstreaming those kind of features. In
> > the meantime, having a featureset is a nice way to move along.
> 
> That is a wrong look at the problem, once it's upstream everybody profits.
> So this looks more like a dead end road.

So instead of having things that are nice, we should wait until upstream
has them?

> Considering that SELinux is inside the kernel it be much better time
> investment to polish that. What makes you think that a Debian Hardened
> with proper SELinux wouldn't be really appreciated!?

It would be. So would a proper grsecurity kernel.

> > > Third beside "security" theatre what is gained by it?
> > 
> > I think the whole point of the “Grsecurity” patchset is “security”.
> 
> I like the way you put it under brackets and think that
> security is gained by just applying this patchset.

Can you show that grsecurity does not provide any additional security?

> > > Fourth why not invest the time for Wheezy and have finally the mainline
> > > and security backed SELinux ready. This seems like a much better time
> > > investment.
> > 
> > Trying to push some bits upstream is indeed a good time investment
> > (though it takes time and I really think moving forward now is a good
> > idea). But Grsecurity isn't a drop-in replacement for SELinux. Some
> > features like RBAC and auditing have some similarities, but all the
> > hardening and memory protection really have nothing to do with that.
> 
> Be more precise in what SELinux can't do for you?
> (Emulating NX for bad hardware doesn't count these days).

For some SELinux is the right choice, for others grsecurity. Its obvious
which you prefer, but not everyone is the same as you. Yves-Alexis is
interested in doing the work on something that you do not want to do the
work on, that seems like a good thing.

micah
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 09 Feb 2011 23:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 09 Feb 2011 23:21:03 GMT) Full text and rfc822 format available.

Message #105 received at 605090@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: maximilian attems <max@stro.at>
Cc: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>, 605090@bugs.debian.org
Subject: Re: Bug#605090: Updated patch
Date: Wed, 9 Feb 2011 15:18:48 -0800
On Wed, Feb 09, 2011 at 06:51:02PM +0100, maximilian attems wrote:
> Be more precise in what SELinux can't do for you?

SELinux is only MAC. It attempts to protect userspace from userspace. From
my view, the bulk of the benefits in grsec and PaX are protecting the
kernel from userspace. Take for example the case of syscalls. There
is nothing in a MAC that can filter syscalls, so if there is a
new vulnerability in a syscall, you might get attacked, and no MAC
can stop it. PaX adds a lot of internal hardening to mitigate most
kernel exploitation attempts (for example, actually enforcing the
kernel/userspace memory segmentation so that kernel code can't be
tricked into running code from a userspace mapping, setting function
pointers and call tables read-only so that an arbitrary write isn't
instantly turned into a root-escalation, hiding the location of kernel
addresses to frustrate attacks that need to find in-kernel offsets,
actually checking the size of copy_to/from_user work to avoid overflows,
the list goes on and on).

> (Emulating NX for bad hardware doesn't count these days).

Why not? A giant amount of hardware lacks NX, and is still in active use,
especially for Debian (people are turning more to Debian as other distros
move their minimum instruction set requirements higher and higher).

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Thu, 10 Feb 2011 09:57:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 10 Feb 2011 09:57:10 GMT) Full text and rfc822 format available.

Message #110 received at 605090@bugs.debian.org (full text, mbox):

From: Bastian Blank <waldi@debian.org>
To: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>, 605090@bugs.debian.org
Subject: Re: Bug#605090: Updated patch
Date: Thu, 10 Feb 2011 10:51:46 +0100
On Wed, Jan 26, 2011 at 09:56:35PM +0100, Yves-Alexis Perez wrote:
> On mer., 2011-01-26 at 14:54 +0100, Bastian Blank wrote: 
> > On Wed, Jan 26, 2011 at 01:29:14PM +0100, Yves-Alexis Perez wrote:
> > > On mer., 2011-01-26 at 08:25 +0100, Bastian Blank wrote:
> > > > On Tue, Jan 18, 2011 at 06:32:50PM +0100, Yves-Alexis Perez wrote:
> > > > > +++ debian/config/amd64/grsec/config	(revision 0)
> > > > Remove, no real settings here.
> > > What do you mean by “real” settings? PAX_PER_CPU_PGD is enabled by
> > > UDEREF and TASK_SIZE_MAX_SHIFT is set to 42 on amd64 because of how it
> > > has been implemented without segmentation.
> > Real settings can be modified by the user, this two can't.
> I still don't get it.

Use menuconfig. Try to modify the values.

> > You will need a git repository in the future. So please start with it.
> I was kind-of waiting for the git linux-2.6 transition. I contacted Ben
> Hutchings about his linux-2.6 tree on git.debian.org but he told me to
> rather directly request to join the alioth project and don't wait for
> the transition to happen. 

Please start with it. I don't want random code drops _right_ _now_.

> > > As I already pointed out on the first mail, Brad Sprengler has already
> > > said he wasn't interested in upstreaming stuff.
> > What Brad wants or don't want is irrelevant here. While the patch policy
> > for the main kernel is rather strict, other featuresets can incorporate
> > more changes. However this is no free ticket to push anything into it.

Okay. Then I set the rules:
* The patch must be minimal. This means:
  - Arbitrary fixes must go to mainline.
  - No style changes in random code.

Bastian

-- 
Violence in reality is quite different from theory.
		-- Spock, "The Cloud Minders", stardate 5818.4




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Mon, 14 Feb 2011 10:06:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Mon, 14 Feb 2011 10:06:05 GMT) Full text and rfc822 format available.

Message #115 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: Bastian Blank <waldi@debian.org>
Cc: 605090@bugs.debian.org
Subject: Re: Bug#605090: Updated patch
Date: Mon, 14 Feb 2011 11:02:53 +0100
[Message part 1 (text/plain, inline)]
On jeu., 2011-02-10 at 10:51 +0100, Bastian Blank wrote:
> On Wed, Jan 26, 2011 at 09:56:35PM +0100, Yves-Alexis Perez wrote:
> > On mer., 2011-01-26 at 14:54 +0100, Bastian Blank wrote: 
> > > On Wed, Jan 26, 2011 at 01:29:14PM +0100, Yves-Alexis Perez wrote:
> > > > On mer., 2011-01-26 at 08:25 +0100, Bastian Blank wrote:
> > > > > On Tue, Jan 18, 2011 at 06:32:50PM +0100, Yves-Alexis Perez wrote:
> > > > > > +++ debian/config/amd64/grsec/config	(revision 0)
> > > > > Remove, no real settings here.
> > > > What do you mean by “real” settings? PAX_PER_CPU_PGD is enabled by
> > > > UDEREF and TASK_SIZE_MAX_SHIFT is set to 42 on amd64 because of how it
> > > > has been implemented without segmentation.
> > > Real settings can be modified by the user, this two can't.
> > I still don't get it.
> 
> Use menuconfig. Try to modify the values.

Understood, thanks, they're implicitely set.
> 
> > > You will need a git repository in the future. So please start with it.
> > I was kind-of waiting for the git linux-2.6 transition. I contacted Ben
> > Hutchings about his linux-2.6 tree on git.debian.org but he told me to
> > rather directly request to join the alioth project and don't wait for
> > the transition to happen. 
> 
> Please start with it. I don't want random code drops _right_ _now_.

Well, I've started to setup a git tree, but it's a bit hard to make the
kernel package git transition myself. I used the script from Ben
Hutchings to setup a git repository with Debian patches applied, but the
result isn't really intended to be maintained, as far as I see it.

> > > > As I already pointed out on the first mail, Brad Sprengler has already
> > > > said he wasn't interested in upstreaming stuff.
> > > What Brad wants or don't want is irrelevant here. While the patch policy
> > > for the main kernel is rather strict, other featuresets can incorporate
> > > more changes. However this is no free ticket to push anything into it.
> 
> Okay. Then I set the rules:
> * The patch must be minimal. This means:
>   - Arbitrary fixes must go to mainline.

“arbitrary fixes” are picked up from mainline, which is why I remove
them from the patch since they're already backported into Debian.

>   - No style changes in random code.

I guess that can be cleaned-up.

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Mon, 14 Feb 2011 12:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Mon, 14 Feb 2011 12:27:03 GMT) Full text and rfc822 format available.

Message #120 received at 605090@bugs.debian.org (full text, mbox):

From: Bastian Blank <waldi@debian.org>
To: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>, 605090@bugs.debian.org
Subject: Re: Bug#605090: Updated patch
Date: Mon, 14 Feb 2011 13:25:22 +0100
On Mon, Feb 14, 2011 at 11:02:53AM +0100, Yves-Alexis Perez wrote:
> On jeu., 2011-02-10 at 10:51 +0100, Bastian Blank wrote:
> > Please start with it. I don't want random code drops _right_ _now_.
> Well, I've started to setup a git tree, but it's a bit hard to make the
> kernel package git transition myself.

I thought about using something derived from the stable tree. You need
it to do proper patch imports anyway.

> >   - Arbitrary fixes must go to mainline.
> “arbitrary fixes” are picked up from mainline, which is why I remove
> them from the patch since they're already backported into Debian.

No. I meant the "arbitrary" fixes like the const-ness changes.

Bastian

-- 
She won' go Warp 7, Cap'n!  The batteries are dead!




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Fri, 18 Feb 2011 09:09:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Fri, 18 Feb 2011 09:09:07 GMT) Full text and rfc822 format available.

Message #125 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: Bastian Blank <waldi@debian.org>
Cc: 605090@bugs.debian.org
Subject: Re: Bug#605090: Updated patch
Date: Fri, 18 Feb 2011 10:08:18 +0100
[Message part 1 (text/plain, inline)]
On lun., 2011-02-14 at 13:25 +0100, Bastian Blank wrote:
> On Mon, Feb 14, 2011 at 11:02:53AM +0100, Yves-Alexis Perez wrote:
> > On jeu., 2011-02-10 at 10:51 +0100, Bastian Blank wrote:
> > > Please start with it. I don't want random code drops _right_ _now_.
> > Well, I've started to setup a git tree, but it's a bit hard to make the
> > kernel package git transition myself.
> 
> I thought about using something derived from the stable tree. You need
> it to do proper patch imports anyway.

I already use the (upstream) stable tree, but that doesn't give me the
Debian patches applied, which is what really matters here.
> 
> > >   - Arbitrary fixes must go to mainline.
> > “arbitrary fixes” are picked up from mainline, which is why I remove
> > them from the patch since they're already backported into Debian.
> 
> No. I meant the "arbitrary" fixes like the const-ness changes.

Those are not arbitraty fixes, the const make sense if the rodata part
is really enforced. This is the kind of thing which is upstreamable
(though DEBUG_RODATA only does part of the job KERNEXEC does) but that
doesn't mean we shouldn't have them now.

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 23 Feb 2011 12:39:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 23 Feb 2011 12:39:06 GMT) Full text and rfc822 format available.

Message #130 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: Bastian Blank <waldi@debian.org>
Cc: 605090@bugs.debian.org, kees@debian.org
Subject: Re: Bug#605090: Updated patch
Date: Wed, 23 Feb 2011 13:36:29 +0100
[Message part 1 (text/plain, inline)]
On mer., 2011-01-26 at 14:54 +0100, Bastian Blank wrote:
> > > >
> http://git.debian.org/?p=collab-maint/linux-grsec-base.git;a=summary
> > if
> > > > needed.
> > > Why is this not part of the patch below?
> > The grsec.conf was attached to the initial bug report. As there is
> no
> > easy way to ship an external file in the linux-image, I was told
> it'd be
> > a better idea to make an external package and that helps because I
> can
> > do the user creation there and add a README.
> 
> External _binary_ package, not source package.

What's the correct way to add a new binary package to linux-2.6. I've
checked the current package and there's the xen-linux-system package
which seems to be xen specific. It has some templates files in
debian/templates and some specific treatment in
debian/bin/gencontrol.py. 

Should I add some templates too and modify the gencontrol.py to create
that new binary package or should I refrain to touch it.
> 
> > > > +CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y
> > > Please show why this should not be enabled globaly.
> > Good point, it should. I'll make a separated bug report.
> 
> No need for a bug.

What's the status for this? Current 2.6.37 builds fine with that option
enabled.

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 18 May 2011 09:21:51 GMT) Full text and rfc822 format available.

Acknowledgement sent to Helge Kreutzmann <debian@helgefjell.de>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 18 May 2011 09:21:53 GMT) Full text and rfc822 format available.

Message #135 received at 605090@bugs.debian.org (full text, mbox):

From: Helge Kreutzmann <debian@helgefjell.de>
To: 605090@bugs.debian.org
Cc: 605090-submitter@bugs.debian.org
Subject: Great idea to get grsec flavored Debian kernels
Date: Wed, 18 May 2011 10:49:34 +0200
[Message part 1 (text/plain, inline)]
Hello,
it would be really great to get grsec enabled kernels. We've using them
for years (self compiled) and except for the recent "problems" with
iceweasel (cf. #623997) without any modifications / problems (except
for a root kit we caught 7 years ago, but that's on purpose).

Greetings

           Helge
-- 
      Dr. Helge Kreutzmann                     debian@helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/
[signature.asc (application/pgp-signature, inline)]

Message sent on to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Bug#605090. (Wed, 18 May 2011 09:27:28 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 31 Aug 2011 16:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 31 Aug 2011 16:09:03 GMT) Full text and rfc822 format available.

Message #143 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: 605090@bugs.debian.org
Cc: kees@debian.org
Subject: Re: Bug#605090: Updated patch
Date: Wed, 31 Aug 2011 17:58:47 +0200
[Message part 1 (text/plain, inline)]
On mer., 2011-02-23 at 13:36 +0100, Yves-Alexis Perez wrote:
> On mer., 2011-01-26 at 14:54 +0100, Bastian Blank wrote:
> > > > >
> > http://git.debian.org/?p=collab-maint/linux-grsec-base.git;a=summary
> > > if
> > > > > needed.
> > > > Why is this not part of the patch below?
> > > The grsec.conf was attached to the initial bug report. As there is
> > no
> > > easy way to ship an external file in the linux-image, I was told
> > it'd be
> > > a better idea to make an external package and that helps because I
> > can
> > > do the user creation there and add a README.
> > 
> > External _binary_ package, not source package.
> 
> What's the correct way to add a new binary package to linux-2.6. I've
> checked the current package and there's the xen-linux-system package
> which seems to be xen specific. It has some templates files in
> debian/templates and some specific treatment in
> debian/bin/gencontrol.py. 
> 
> Should I add some templates too and modify the gencontrol.py to create
> that new binary package or should I refrain to touch it.

I've tried to add templates but it still lacks the proper gencontrol.py
logic. Any indication on what exactly is needed there would help.
> > 
> > > > > +CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y
> > > > Please show why this should not be enabled globaly.
> > > Good point, it should. I'll make a separated bug report.
> > 
> > No need for a bug.
> 
> What's the status for this? Current 2.6.37 builds fine with that option
> enabled.

So there /was/ a need for a bug, since this got completely lost. This is
#639919

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 31 Aug 2011 16:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 31 Aug 2011 16:36:03 GMT) Full text and rfc822 format available.

Message #148 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: 605090@bugs.debian.org
Subject: Update on grsecurity featureset
Date: Wed, 31 Aug 2011 18:33:32 +0200
[Message part 1 (text/plain, inline)]
Ok, here's an updated patchset.

Tarball can be found at
http://molly.corsac.net/~corsac/debian/kernel-grsec/grsec-patches.tar.xz
(and already extracted in grsec-patches/ folder).

It's a folder with a quilt patche series

* 01_support-linux-3.0.patch

This is unrelated but needed to support linux3 naming scheme in
genorig.py.

* 02_force-hostcc-version.patch

This one is needed because grsecurity ships two gcc (>= 4.5) plugins.
Those need to be built with the same compiler version as the rest of the
kernel, but right now they're built with HOSTCC which is not set right
now, so defaults to 'gcc' which is gcc-4.6 at that time. So export
HOSTCC to the (non CROSS_COMPILE) version.

03_enable-strict-user-copy-check.patch

This one in not directly involved with grsecurity. Could be enabled by
itself (#639919)

04_add-linux-grsec-base-templates.patch

This one adds basic templates for a linux-grsec-base binary packages to
be built by linux-2.6 but I still didn't figured out how to patch
genorig.py to make it do it.

05_add-grsec-featureset.patch

This is the main part, adding the featureset and config.

06_grsecurity.patch

The main grsecurity patch, not really readable since the quilt patch
adds a patch :) It's basically the genuine grsecurity patch (right now
grsecurity-2.2.2-3.0.4-201108301903.patch) with two little change:

* removing the -grsec localversion
* oneliner to make it apply against debian sources

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Thu, 01 Sep 2011 04:21:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ben Hutchings <ben@decadent.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 01 Sep 2011 04:21:08 GMT) Full text and rfc822 format available.

Message #153 received at 605090@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>, 605090@bugs.debian.org
Subject: Re: Bug#605090: Update on grsecurity featureset
Date: Thu, 01 Sep 2011 05:20:30 +0100
[Message part 1 (text/plain, inline)]
On Wed, 2011-08-31 at 18:33 +0200, Yves-Alexis Perez wrote:
> Ok, here's an updated patchset.
> 
> Tarball can be found at
> http://molly.corsac.net/~corsac/debian/kernel-grsec/grsec-patches.tar.xz
> (and already extracted in grsec-patches/ folder).
> 
> It's a folder with a quilt patche series
> 
> * 01_support-linux-3.0.patch
> 
> This is unrelated but needed to support linux3 naming scheme in
> genorig.py.

Already done on trunk.

> * 02_force-hostcc-version.patch
> 
> This one is needed because grsecurity ships two gcc (>= 4.5) plugins.
> Those need to be built with the same compiler version as the rest of the
> kernel, but right now they're built with HOSTCC which is not set right
> now, so defaults to 'gcc' which is gcc-4.6 at that time. So export
> HOSTCC to the (non CROSS_COMPILE) version.

gcc plugins surely need to be built _for_ the compiler version used for
the kernel, not _by_ that version.

Also, you are changing HOSTCC for all build tools and not just these
plugins.

> 03_enable-strict-user-copy-check.patch
> 
> This one in not directly involved with grsecurity. Could be enabled by
> itself (#639919)

Without the strict check, the crap code produces a compile-time warning
and a run-time warning and *no copying*.  With the strict check, the
crap code results in FTBFS (but only on i386 and s390!).  So how is this
an improvement for us?

> 04_add-linux-grsec-base-templates.patch
> 
> This one adds basic templates for a linux-grsec-base binary packages to
> be built by linux-2.6 but I still didn't figured out how to patch
> genorig.py to make it do it.

Don't add such a package to linux-2.6.  It should be a new source
package, like linux-base is now (after I initially made that mistake).

> 05_add-grsec-featureset.patch
> 
> This is the main part, adding the featureset and config.

And linux-grsec-base, a second time!

> 06_grsecurity.patch
> 
> The main grsecurity patch, not really readable since the quilt patch
> adds a patch :) It's basically the genuine grsecurity patch (right now
> grsecurity-2.2.2-3.0.4-201108301903.patch) with two little change:
> 
> * removing the -grsec localversion
> * oneliner to make it apply against debian sources

You should provide a gen-patch script to help in regenerating the patch.

Ben.

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Thu, 01 Sep 2011 08:21:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 01 Sep 2011 08:21:07 GMT) Full text and rfc822 format available.

Message #158 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: 605090@bugs.debian.org
Subject: Re: Bug#605090: Update on grsecurity featureset
Date: Thu, 01 Sep 2011 10:20:16 +0200
[Message part 1 (text/plain, inline)]
On jeu., 2011-09-01 at 05:20 +0100, Ben Hutchings wrote:
> On Wed, 2011-08-31 at 18:33 +0200, Yves-Alexis Perez wrote:
> > Ok, here's an updated patchset.
> > 
> > Tarball can be found at
> > http://molly.corsac.net/~corsac/debian/kernel-grsec/grsec-patches.tar.xz
> > (and already extracted in grsec-patches/ folder).
> > 
> > It's a folder with a quilt patche series
> > 
> > * 01_support-linux-3.0.patch
> > 
> > This is unrelated but needed to support linux3 naming scheme in
> > genorig.py.
> 
> Already done on trunk.

Ha, fair enough, I was wondering how people did the orig for 3.x :) Can
this be committed to sid/, since it has 3.0 anyway?
> 
> > * 02_force-hostcc-version.patch
> > 
> > This one is needed because grsecurity ships two gcc (>= 4.5) plugins.
> > Those need to be built with the same compiler version as the rest of the
> > kernel, but right now they're built with HOSTCC which is not set right
> > now, so defaults to 'gcc' which is gcc-4.6 at that time. So export
> > HOSTCC to the (non CROSS_COMPILE) version.
> 
> gcc plugins surely need to be built _for_ the compiler version used for
> the kernel, not _by_ that version.

I'm not sure about what you mean here. I assumed that building a gcc
plugin with a given gcc version meant that it was built *for* this
version (and thus forcing the compiler for those plugins to the same
version used for the kernel meant the plugin would work at kernel build
time).

> 
> Also, you are changing HOSTCC for all build tools and not just these
> plugins.

Yes, as said on #debian-kernel this was because it seemed more logical
to use the same thing everywhere and because at one point I had issues
with building perf for squeeze 2.6.32 on a box where gcc was at 4.6. And
in fact, afaict, I'm forcing HOSTCC for the whole build, but I have to
admit I found that more consistent to have CC and HOSTCC at the same
version.

If you think it's a bad idea I can try to modify grsecurity patch to add
it to the plugins Makefile (that'd be debian specific the same way I
remove localversion) but kernelvariables looked like a good place.
> 
> > 03_enable-strict-user-copy-check.patch
> > 
> > This one in not directly involved with grsecurity. Could be enabled by
> > itself (#639919)
> 
> Without the strict check, the crap code produces a compile-time warning
> and a run-time warning and *no copying*.  With the strict check, the
> crap code results in FTBFS (but only on i386 and s390!).  So how is this
> an improvement for us?

I've replied to the specific bug so we can track it there, since it's
unrelated (and is not needed per se on the grsecurity featureset).
> 
> > 04_add-linux-grsec-base-templates.patch
> > 
> > This one adds basic templates for a linux-grsec-base binary packages to
> > be built by linux-2.6 but I still didn't figured out how to patch
> > genorig.py to make it do it.
> 
> Don't add such a package to linux-2.6.  It should be a new source
> package, like linux-base is now (after I initially made that mistake).

Well, that's what I did when you suggested it (packaging is at
http://anonscm.debian.org/gitweb/?p=collab-maint/linux-grsec-base.git;a=summary) but afaiui Bastian asked it not to be a new source package. Anyway, this can be dropped easily if not needed.
> 
> > 05_add-grsec-featureset.patch
> > 
> > This is the main part, adding the featureset and config.
> 
> And linux-grsec-base, a second time!

Woops, fixed :)
> 
> > 06_grsecurity.patch
> > 
> > The main grsecurity patch, not really readable since the quilt patch
> > adds a patch :) It's basically the genuine grsecurity patch (right now
> > grsecurity-2.2.2-3.0.4-201108301903.patch) with two little change:
> > 
> > * removing the -grsec localversion
> > * oneliner to make it apply against debian sources
> 
> You should provide a gen-patch script to help in regenerating the patch.

Yeah good point. At least localversion should be easy to filterdiff. And
maybe add a specific .kernelvariables and the relevant include to the
plugins Makefile. Thanks for the suggestion.

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Tue, 11 Oct 2011 15:00:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Tue, 11 Oct 2011 15:00:09 GMT) Full text and rfc822 format available.

Message #163 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: 605090@bugs.debian.org
Cc: kees@debian.org
Subject: [grsec] update on featureset
Date: Tue, 11 Oct 2011 16:52:42 +0200
[Message part 1 (text/plain, inline)]
Ok so the tarball on the website isn't really convenient so, for now,
I've put the quilt serie on a git repository on git.d.o:
http://anonscm.debian.org/gitweb/?p=users/corsac/grsec-patches.git;a=summary

The master branch for is for the "sid" branch in debian kernel svn, and
there's a squeeze branch too (though it's for now out of date).

I've updated the patches to the latest svn (sid) version and the latest
grsecurity/pax patches and I'll put updated packages on my server
tonight.

Could we move forward on this?

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Tue, 11 Oct 2011 19:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <corsac@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Tue, 11 Oct 2011 19:12:03 GMT) Full text and rfc822 format available.

Message #168 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <corsac@debian.org>
To: 605090@bugs.debian.org
Cc: kees@debian.org
Subject: Re: Bug#605090: [grsec] update on featureset
Date: Tue, 11 Oct 2011 21:10:16 +0200
[Message part 1 (text/plain, inline)]
On mar., 2011-10-11 at 16:52 +0200, Yves-Alexis Perez wrote:
> 
> I've updated the patches to the latest svn (sid) version and the latest
> grsecurity/pax patches and I'll put updated packages on my server
> tonight. 

Packages are available on:

deb http://molly.corsac.net/~corsac/debian/kernel-grsec/packages/ sid/

Regards,
-- 
Yves-Alexis
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Thu, 10 Nov 2011 14:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 10 Nov 2011 14:51:03 GMT) Full text and rfc822 format available.

Message #173 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: 605090@bugs.debian.org
Cc: kees@debian.org, Ben Hutchings <ben@decadent.org.uk>, Moritz Mühlenhoff <jmm@inutil.org>, Bastian Blank <waldi@debian.org>, maximilian attems <max@stro.at>
Subject: Re: Bug#605090: [grsec] update on featureset
Date: Thu, 10 Nov 2011 15:46:18 +0100
[Message part 1 (text/plain, inline)]
On mar., 2011-10-11 at 16:52 +0200, Yves-Alexis Perez wrote:
> Ok so the tarball on the website isn't really convenient so, for now,
> I've put the quilt serie on a git repository on git.d.o:
> http://anonscm.debian.org/gitweb/?p=users/corsac/grsec-patches.git;a=summary

Now upgraded to grsecurity 2.2.2-3.0.8-201110250925 against
linux-2.6_3.0.0-6.

Package (i386 and amd64) should be available on:

deb http://molly.corsac.net/~corsac/debian/kernel-grsec/packages/ sid/

tonight.
> 
> Could we move forward on this?

Since I got not reply at all after this mail, I'm asking again. I know
people are busy and I know this bug is not the easiest to handle, but
I'd really like to move on.

Since the RT featureset was added not that long ago, I guess the concept
of featureset is still welcome. I know the situation is different, but
still, I really think Debian users would appreciate a grsecurity
featureset, which wouldn't harm other people kernels thanks to the
alternate image.

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Thu, 10 Nov 2011 15:27:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ben Hutchings <ben@decadent.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 10 Nov 2011 15:27:10 GMT) Full text and rfc822 format available.

Message #178 received at 605090@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
Cc: 605090@bugs.debian.org, kees@debian.org, Moritz Mühlenhoff <jmm@inutil.org>, Bastian Blank <waldi@debian.org>, maximilian attems <max@stro.at>
Subject: Re: Bug#605090: [grsec] update on featureset
Date: Thu, 10 Nov 2011 15:24:32 +0000
[Message part 1 (text/plain, inline)]
On Thu, 2011-11-10 at 15:46 +0100, Yves-Alexis Perez wrote:
> On mar., 2011-10-11 at 16:52 +0200, Yves-Alexis Perez wrote:
> > Ok so the tarball on the website isn't really convenient so, for now,
> > I've put the quilt serie on a git repository on git.d.o:
> > http://anonscm.debian.org/gitweb/?p=users/corsac/grsec-patches.git;a=summary
> 
> Now upgraded to grsecurity 2.2.2-3.0.8-201110250925 against
> linux-2.6_3.0.0-6.
> 
> Package (i386 and amd64) should be available on:
> 
> deb http://molly.corsac.net/~corsac/debian/kernel-grsec/packages/ sid/
> 
> tonight.
> > 
> > Could we move forward on this?
> 
> Since I got not reply at all after this mail, I'm asking again. I know
> people are busy and I know this bug is not the easiest to handle, but
> I'd really like to move on.
> 
> Since the RT featureset was added not that long ago, I guess the concept
> of featureset is still welcome. I know the situation is different, but
> still, I really think Debian users would appreciate a grsecurity
> featureset, which wouldn't harm other people kernels thanks to the
> alternate image.

Every extra featureset that requires additional effort from the existing
team members reduces the effort that can be spent on other tasks.

Is the grsecurity patch getting bigger or smaller over time?

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Thu, 10 Nov 2011 16:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 10 Nov 2011 16:45:03 GMT) Full text and rfc822 format available.

Message #183 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: 605090@bugs.debian.org, kees@debian.org, Moritz Mühlenhoff <jmm@inutil.org>, Bastian Blank <waldi@debian.org>, maximilian attems <max@stro.at>
Subject: Re: Bug#605090: [grsec] update on featureset
Date: Thu, 10 Nov 2011 17:44:37 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/11/2011 16:24, Ben Hutchings wrote:
> Every extra featureset that requires additional effort from the existing
> team members reduces the effort that can be spent on other tasks.

Yes, I definitely understand that, and I really intend to provide enough
help to minimize the burdain on existing team members which don't care
about that featureset.
> 
> Is the grsecurity patch getting bigger or smaller over time?

It's a bit hard to tell. Putting aside the various security backports
(mainly relevant for the 2.6.32 patch), the size seems to have decreased
a little since 2.6.39 (and risen in the 3.0 serie).

Feature-wise, Brad Sprengler and the PaX team still add stuff, like the
gcc plugins or hardening features like symbols hiding, fix bugs (for
example in RBAC code), while few of them reach mainline.

Regards,
- -- 
Yves-Alexis Perez
ANSSI/ACE/LAM
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iQIcBAEBCgAGBQJOu/91AAoJENcc3UqWxbaOkVAQAK5kcuOvmrASldaP0c/CpvXm
AgQBfFLhPJjO8KxB/qDhdAcc4m9Kn7rYbmbFgHi5ujdHu99ccki1+wzZv12LFZkc
VzNs12RQT8OboxQybfNcsRRgledwRGOCIefkKM91z05YSLBOmxNalpC//mcEqx+Y
rSvoZ/+/X/ZFp7krKHULR2oeqJFohjBejnS3/6eLSQDN8HCvGi0QN/MF45X9O+aE
vVhfzkDAV3LuyYXOi82Vi9y01W/7KtLbTGf8TEi7vh2XWwrdzHagnc/Lg28adxfu
QaL/ufabLUY34fdB0R5AfSjKcpnyX4J/tpDEWeObtQTMQc/p/kb0yJXWBTAk3azI
/PlF63OUxUhOh9wFASbYR5nZC+e8ToATA3XAYJ/nGoXKvC2vxD73DIk7jspgstS0
bVYLcuSQ4ZkxG2w3CmbgqdF0/92JTZ5PQEvL/0lM2lwYDFt4cZ4kY2xDK+7uo0uD
8j5Js51T0PPROhg0wKK3Zk5wxnReUj8sOnfB96GtCc8x05N5CCxr49pi6Zfdk6BM
yO1tfvq75x9jfspzAv+mkhZDbfo47NcbKYLM+aZvJGKHavqCU0ejSOTCSNgsH8og
cY8/tEhIMd3dSY4IXmj8eHl3gSVTkzwRDpRVpGxmicf3HGlfs2tMpLAtiRY4JS8I
eOmxJ7Wbkpv5dstazq8y
=eBwV
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Thu, 10 Nov 2011 17:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Moritz Muehlenhoff <jmm@inutil.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 10 Nov 2011 17:09:03 GMT) Full text and rfc822 format available.

Message #188 received at 605090@bugs.debian.org (full text, mbox):

From: Moritz Muehlenhoff <jmm@inutil.org>
To: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
Cc: Ben Hutchings <ben@decadent.org.uk>, 605090@bugs.debian.org, kees@debian.org, Bastian Blank <waldi@debian.org>, maximilian attems <max@stro.at>
Subject: Re: Bug#605090: [grsec] update on featureset
Date: Thu, 10 Nov 2011 18:06:40 +0100
On Thu, Nov 10, 2011 at 05:44:37PM +0100, Yves-Alexis Perez wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 10/11/2011 16:24, Ben Hutchings wrote:
> > Every extra featureset that requires additional effort from the existing
> > team members reduces the effort that can be spent on other tasks.
> 
> Yes, I definitely understand that, and I really intend to provide enough
> help to minimize the burdain on existing team members which don't care
> about that featureset.
> > 
> > Is the grsecurity patch getting bigger or smaller over time?
> 
> It's a bit hard to tell. Putting aside the various security backports
> (mainly relevant for the 2.6.32 patch), the size seems to have decreased
> a little since 2.6.39 (and risen in the 3.0 serie).
> 
> Feature-wise, Brad Sprengler and the PaX team still add stuff, like the
> gcc plugins or hardening features like symbols hiding, fix bugs (for
> example in RBAC code), while few of them reach mainline.

Maybe we can ask upstream, whether the RBAC code and the rest of the
patch set can be separated? I don't think there's much interest in RBAC
for a Debian feature set, while the rest is quite interesting.

Cheers,
        Moritz




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Thu, 10 Nov 2011 17:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 10 Nov 2011 17:18:03 GMT) Full text and rfc822 format available.

Message #193 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: Moritz Muehlenhoff <jmm@inutil.org>
Cc: Ben Hutchings <ben@decadent.org.uk>, 605090@bugs.debian.org, kees@debian.org, Bastian Blank <waldi@debian.org>, maximilian attems <max@stro.at>
Subject: Re: Bug#605090: [grsec] update on featureset
Date: Thu, 10 Nov 2011 18:16:56 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/11/2011 18:06, Moritz Muehlenhoff wrote:
> Maybe we can ask upstream, whether the RBAC code and the rest of the
> patch set can be separated? I don't think there's much interest in RBAC
> for a Debian feature set, while the rest is quite interesting.
> 
Unfortunately, I already asked upstream about a nicely splitted patch,
but Brad didn't seem interested back in time. It might be worth
re-asking though.

Regards,
- -- 
Yves-Alexis Perez
ANSSI/ACE/LAM
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iQIcBAEBCgAGBQJOvAcIAAoJENcc3UqWxbaOK3cP/jUKp59eQbTfQ30JmQsAtKFB
3A2r9PRFvs0eex7O/DYXz2Ua/MFnfCxYg2Xuv79aqH+8mBX/WlmNmZfL7uHCT3Zx
AgvT6A4LFxm5HNtQV4xnqflmEaxFCWBxVgv39ITeCvNKfxXKM6tYIXmb38GEhB79
srxrL1wW7Kad62YXngQeltTWbJIkWBBgcC29zERXpY/DDoQhwAvel4jSTu+L54NB
zmc8X3YI7gcwMq0Xke+aPNqGu+IfQaUpOu8BVa3WwxN8fNhYkDddkmrJ2YdpcjeJ
sawNl08d6zgZWntDTKe/KjvJpV9goxP/jKR9vUFYgSl+S90tGKzMzpAQFddgwTh9
h422D1Pbd9swyHQ32AN2RIxVEAf6zXcyZPpGw5NSdsbwu3A+1A4/BsTDkVNOKarq
msS+0tFwSdwqe8aOvFawenuHmh1s33c6urZn6Bve6a1tWCTs1Lapydcl34VYAJrX
ii5zsBAlA/Vl3NujUh8V0rvYzHADB4qjQFIUS+TyEEOaHLVBK4/fUlcGxZnS4HcV
6lw/+Nm7nSbgwBv7lbGRJwOgoT38KRNsh/03IQyC8qNLooHn31HJvctGxMt+o7Hu
E2HqxJC2SPBQGoPXQdqRHK+Bi2z/ukS4u3dtfWsBZxkQQVi9w3Zq7Ele6dx7cXvb
YOF14DsTQbVkg+hgaptH
=j3zh
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Thu, 10 Nov 2011 17:33:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 10 Nov 2011 17:33:04 GMT) Full text and rfc822 format available.

Message #198 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <yves-alexis.perez@ssi.gouv.fr>
To: spender@grsecurity.net, 605090@bugs.debian.org
Subject: splitting grsecurity patchset
Date: Thu, 10 Nov 2011 18:33:28 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Brad,

as you may know from IRC, I'm trying to include a new grsecurity
featureset to the Debian kernels. The point is basically to add a new
binary package to the existing architecture, so people interested in
kernel hardening can chose to run a grsecurity-enabled kernel instead of
the default one.

Currently the patch is a bit large and poses some maintainance issues to
the kernel team, and something which would help us would be to have
access to some splitted version of the patchset, with few files for
large features (such as RBAC).

I'm not sure how much work does this involve for you (I'm not sure how
you're working internally), but it'd be quite appreciated (and not only
for Debian kernel people).

Regards,
- -- 
Yves-Alexis Perez
ANSSI/ACE/LAM
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iQIcBAEBCgAGBQJOvAroAAoJENcc3UqWxbaOIMgP/0CXIyGP+pZQsRcGfniYH5NX
DMviV1kHzurddtGu/VIPdygoJ+ORz9kEiISU9neeO9O99a/n7KQ4vRSIbcv9ODU3
pxAfprz0ej4TWsVk5kRQBNTWuF8Dd9Abzg0x0RdQcrkqmxgORiHAPW/PhyTelyKL
cEf7mXFNEt2aVT63urm21OziAz/CmXRbGidocwHYiX+RcBpD0RCQ9rj5OLFru9R2
8RGtVDqVewqAekOEb4ZV2SQ5g4uPiX51vrazTtxYLp1+g2rSuHDTX/+r734+0EmQ
Gw6QaLPat6gvkIvsMS3BNk0mnM8GVM3SlSNvW+Ile00GqJeR/nPzd2ECelEcgP4x
+ErBJICCUvKuhNw3uChkh8gNkD9WXqrnHi+7qgGaxs4aP+VmD2Y7gaN4V1RSRgf/
N+8o6u2SZvsaUvC5LFtp37RwppR7xIGrVswMKgojgwl9Vp1xY1EcOb0k90YqA2eu
SfQlT7rJGM10W2gkVvLdP93wY4S4R2HI56rlEElQlRqJwGbwLh0nGwPMAKtIQlHG
sWdwEpCIRiMc0wSN+6Xcd+VoFua7a1QVSCtv3TEga+tWPGNzeRJKHPThHWiQUXb6
GCeUKdKgt76NrJ/aiqeSpD79YQTTQCUpb2egK8KdGP6d4JnXpi/TXhQ+mtq9DpUb
9hEH75ILvIqr9hUuSAR/
=Bosl
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 28 Dec 2011 04:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Carlos Alberto Lopez Perez <clopez@igalia.com>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 28 Dec 2011 04:48:03 GMT) Full text and rfc822 format available.

Message #203 received at 605090@bugs.debian.org (full text, mbox):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>
To: 605090@bugs.debian.org
Cc: gcs@debian.hu
Subject: RE: [RFC] Add a grsec featureset to Debian kernels
Date: Wed, 28 Dec 2011 05:45:20 +0100
[Message part 1 (text/plain, inline)]
Hello,


What is the status of this? It has been a looong time ago since last update.


I am also interested in having a Debian kernel with the grsec+pax
featureset and I am sure that many sysadmins would appreciate this
possibility. There is a huge user base of grsec from hosting companies.


I agree that this RBAC thing may be not interesting for everybody giving
the fact that it duplicates some functionality (we already have SELinux
and TOMOYO).


So if you really feel so strong about removing this feature from the
debian-grsec-kernel it can be easily done just by setting
CONFIG_GRKERNSEC_NO_RBAC=y in the .config (there is no need to ask
upstream to split the patch).


Anyway I think RBAC is a nice feature and it don't hurts: Its far easier
to use than SElinux [1] and we already have in Debian the user-space
tools to work with it:

  CC'ing Laszlo Boszormenyi
  (maintainer of linux-patch-grsecurity2, paxctl and gradm2)



I would like to see this moving forward, so I volunteer myself to help
with the maintenance of this featureset.



Regards!


[1] http://www.cs.virginia.edu/~jcg8f/SELinux%20grsecurity%20paper.pdf


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Carlos Alberto Lopez Perez                           http://neutrino.es
Igalia - Free Software Engineering                http://www.igalia.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Mon, 09 Jan 2012 14:21:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <corsac@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Mon, 09 Jan 2012 14:21:10 GMT) Full text and rfc822 format available.

Message #208 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <corsac@debian.org>
To: Carlos Alberto Lopez Perez <clopez@igalia.com>, 605090@bugs.debian.org
Cc: gcs@debian.hu
Subject: Re: Bug#605090: [RFC] Add a grsec featureset to Debian kernels
Date: Mon, 09 Jan 2012 15:19:35 +0100
[Message part 1 (text/plain, inline)]
On mer., 2011-12-28 at 05:45 +0100, Carlos Alberto Lopez Perez wrote:
> Hello,
> 
> 
> What is the status of this? It has been a looong time ago since last update.

Sorry for the delay. As the BTS doesn't automatically CC the submitter,
please keep me on CC: when replying to this bug.

For sid, I keep updating the kernels from time to time, you can see the
grsec-patches (against the sid svn branch) at
http://anonscm.debian.org/gitweb/ and binary packages can be found at
http://molly.corsac.net/~corsac/debian/kernel-grsec/packages/sid/ (I
don't upload every built kernel there since it's a bit huge.

For squeeze, I'm a bit lagging but I should update both the relevant
branch in grsec-patches and the repository.

I don't give a status update each time I update the repositories in
order not to flood people, and I still hope some positive answer from
the kernel team (until it's obvious it's too late for Wheezy).
> 
> 
> I am also interested in having a Debian kernel with the grsec+pax
> featureset and I am sure that many sysadmins would appreciate this
> possibility. There is a huge user base of grsec from hosting companies.

Thanks for the support.
> 
> 
> I agree that this RBAC thing may be not interesting for everybody giving
> the fact that it duplicates some functionality (we already have SELinux
> and TOMOYO).
> 
> 
> So if you really feel so strong about removing this feature from the
> debian-grsec-kernel it can be easily done just by setting
> CONFIG_GRKERNSEC_NO_RBAC=y in the .config (there is no need to ask
> upstream to split the patch).

This was mostly about upstreaming things, in fact. But disabling an
option doesn't make the patch smaller.
> 
> 
> Anyway I think RBAC is a nice feature and it don't hurts: Its far easier
> to use than SElinux [1] and we already have in Debian the user-space
> tools to work with it:
> 
>   CC'ing Laszlo Boszormenyi
>   (maintainer of linux-patch-grsecurity2, paxctl and gradm2)

Note that linux-patch-grsecurity2 should really be removed now.
> 
> 
> 
> I would like to see this moving forward, so I volunteer myself to help
> with the maintenance of this featureset.
> 
Thanks for that :)
-- 
Yves-Alexis
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Sat, 21 Jan 2012 19:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Adam K <adam.ffa@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Sat, 21 Jan 2012 19:15:03 GMT) Full text and rfc822 format available.

Message #213 received at 605090@bugs.debian.org (full text, mbox):

From: Adam K <adam.ffa@gmail.com>
To: 605090@bugs.debian.org
Subject: definitely, a worth while patchset
Date: Sat, 21 Jan 2012 11:10:40 -0800
[Message part 1 (text/plain, inline)]
Hey,

 This patch-set should replace linux-patch-grsecurity2.This patch-set provides excellent default settings and capability. For example, the user and group setup helps with creating consistent access user and group ids across servers. Most of the default kernel settings match with gentoo's hardened project kernel settings. Since this patch-set integrates with debian patch-sets, servers get benefits from both patch-sets. And, admins don't have to choose between patching the vanilla sources or resolving conflicts between the debian and grsec patch-sets.

I believe a statistic needs to be done on how much of the grsec feature set is used by grsec users. For example, I use RBAC instead of SELINUX and Tomoyo almost always. There's also things like extra chroot security features that should be taken into consideration. My hypothesis for this statistic is that most grsec users use RBAC as well. For those that don't, I understand that a split between larger and smaller feature sets, PAX vs RBAC, would be helpful. For this split to happen, with grsec's history, I think a large interest needs to be shown for them to split the patch-set. So, if this is accepted, maybe the level of interest needed to get a split patch will be generated.

Currently, I like this as a patch-set more than a binary because of security conflicts with things like xen. However, if I wasn't using xen, I would use the binary.

(Note: I accidently sent this message to 605090-subscribe@bugs.debian.org first.)

- 

[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Mon, 30 Jan 2012 10:09:30 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <corsac@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Mon, 30 Jan 2012 10:09:32 GMT) Full text and rfc822 format available.

Message #218 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <corsac@debian.org>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: debian-kernel@lists.debian.org, debian-devel@lists.debian.org, debian-security@lists.debian.org, 605090@bugs.debian.org, spender@grsecurity.net
Subject: Re: Linux 3.2 in wheezy
Date: Mon, 30 Jan 2012 11:05:33 +0100
[Message part 1 (text/plain, inline)]
(adding few CC:s to keep track on the bug)

On dim., 2012-01-29 at 21:26 +0000, Ben Hutchings wrote:
> On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
> > On dim., 2012-01-29 at 18:22 +0000, Ben Hutchings wrote:
> > > Featuresets
> > > -----------
> > > 
> > > The only featureset provided will be 'rt' (realtime), currently built
> > > for amd64 only.  If there is interest in realtime support for other
> > > architectures, we may be able to add that.  However, we do need to
> > > consider the total time taken to build binary packages for each
> > > architecture.
> > > 
> > > If there are particular container features that should be enabled or
> > > backported to provide a useful replacement for OpenVZ or VServer,
> > > please let us know.  We cannot promise that these will all be enabled
> > > but we need to know what is missing. 
> > 
> > So in the end what are the reasons for not trying the grsecurity
> > featureset? #605090 lacks any reply from the kernel team since quite a
> > while, and especially after answers were provided to question asked.
> 
> You already know the main reason:
> > Feature-wise, Brad Sprengler and the PaX team still add stuff, like the
> > gcc plugins or hardening features like symbols hiding, fix bugs (for
> > example in RBAC code), while few of them reach mainline.
> 
> I realise that the mainline Linux developers have sometimes been
> unreasonably resistant to these changes and I'm not intending to assign
> blame for this.  But practically this means that we have to either carry
> the featureset indefinitely or disappoint users by removing it in a
> later release.  (See the complaints about removing OpenVZ in wheezy
> despite 4 years' advance notice of this.)

I understand this, and I still see the grsec featureset as a valuable
project. Indeed, reducing the diff wrt. upstream in Debian kernel is an
important goal (especially considering the time involvement).

Now, I still think having a hardened Debian kernel inside the
distribution is helpful and needed for some people (some of them have
said so on the bug report, some other directly told me). I can continue
providing kernels for stable and sid outside of Debian, but that means
it's painful to find them, so less people will use it. I'm sure I don't
have to remind people, but having a hardened kernel can buy you some
time when some vulnerabilities are found in the kernel, like
the /proc/pid/mem one (even when it does not prevent completely the
vulnerability, it can prevents the exploit to be successful, for
example).
> 
> It also appears that you never had any response to your question to
> upstream about minimising the patch set.

Indeed. Brad, I'm not sure if you received the initial mail, so if you
have any comment…
> 
> > Not doing anything is indeed a way to just get rid of the question, but
> > I would have at least appreciated a definitive answer on the bug rather
> > than via the dda mail.
> 
> I'm sorry about that; it completely slipped my mind as there have been
> no discussions about it for some months.

Well, the last mail from the kernel team on the bug was indeed months
ago (nov 10th afaict), but I kept adding info and replies since.

Anyway, thanks for your answer.

Regards,
-- 
Yves-Alexis
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Mon, 30 Jan 2012 13:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Brad Spengler <spender@grsecurity.net>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Mon, 30 Jan 2012 13:15:15 GMT) Full text and rfc822 format available.

Message #223 received at 605090@bugs.debian.org (full text, mbox):

From: Brad Spengler <spender@grsecurity.net>
To: Yves-Alexis Perez <corsac@debian.org>
Cc: Ben Hutchings <ben@decadent.org.uk>, debian-kernel@lists.debian.org, debian-devel@lists.debian.org, debian-security@lists.debian.org, 605090@bugs.debian.org
Subject: Re: Linux 3.2 in wheezy
Date: Mon, 30 Jan 2012 08:02:22 -0500
[Message part 1 (text/plain, inline)]
> Indeed. Brad, I'm not sure if you received the initial mail, so if you
> have any comment???

It looks like there were quite a few messages I wasn't involved in ;)  

Regarding minimizing the patchset, we do that already where we see 
opportunities to do so.  We used to carry a large constifying patch 
which has now been replaced with a gcc plugin.  Likewise with the kernel 
stack clearing feature.

As far as gutting the patch for whatever features someone not involved 
in the project thinks are the only ones necessary (I saw a few posts 
in the thread asking for that) -- I don't think it's a good idea and 
I'm not interested at all in assisting that.

If we're going to be in the business of telling other people what to do 
with their free time, might I suggest that Debian improve its userland 
hardening so that it's not in last place?  As a Debian user myself, I
can assure you that no one cares about a miniscule performance hit from
PIE on i386 in su/passwd.  There's no reason not to have these privilege
boundaries hardened -- and very disappointing for us as 
MPROTECT/ASLR/GRKERNSEC_BRUTEFORCE would have provided an effective 
deterrent against exploitation of the /proc/pid/mem vuln were it not
for distros' userland hardening being asleep on the job.  That failure
will continue to bite users.

Frankly it makes more sense for me to offer .debs myself than to deal 
with a bureaucracy and non-standard kernel in Debian.  It contains 
who-knows-what extra code, and I doubt anyone looked at any of it to see if 
it allows for some way to leak information I prevent against a vanilla 
kernel, or a way to bypass any other existing protection.  There's more 
to security (a whole-system concept) than just the ripping of individual 
features.

-Brad
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Mon, 30 Jan 2012 14:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ben Hutchings <ben@decadent.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Mon, 30 Jan 2012 14:09:08 GMT) Full text and rfc822 format available.

Message #228 received at 605090@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: Yves-Alexis Perez <corsac@debian.org>
Cc: debian-kernel@lists.debian.org, debian-devel@lists.debian.org, debian-security@lists.debian.org, 605090@bugs.debian.org, spender@grsecurity.net
Subject: Re: Linux 3.2 in wheezy
Date: Mon, 30 Jan 2012 14:08:18 +0000
[Message part 1 (text/plain, inline)]
On Mon, 2012-01-30 at 11:05 +0100, Yves-Alexis Perez wrote:
> (adding few CC:s to keep track on the bug)
> 
> On dim., 2012-01-29 at 21:26 +0000, Ben Hutchings wrote:
> > On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
> > > On dim., 2012-01-29 at 18:22 +0000, Ben Hutchings wrote:
> > > > Featuresets
> > > > -----------
> > > > 
> > > > The only featureset provided will be 'rt' (realtime), currently built
> > > > for amd64 only.  If there is interest in realtime support for other
> > > > architectures, we may be able to add that.  However, we do need to
> > > > consider the total time taken to build binary packages for each
> > > > architecture.
> > > > 
> > > > If there are particular container features that should be enabled or
> > > > backported to provide a useful replacement for OpenVZ or VServer,
> > > > please let us know.  We cannot promise that these will all be enabled
> > > > but we need to know what is missing. 
> > > 
> > > So in the end what are the reasons for not trying the grsecurity
> > > featureset? #605090 lacks any reply from the kernel team since quite a
> > > while, and especially after answers were provided to question asked.
> > 
> > You already know the main reason:
> > > Feature-wise, Brad Sprengler and the PaX team still add stuff, like the
> > > gcc plugins or hardening features like symbols hiding, fix bugs (for
> > > example in RBAC code), while few of them reach mainline.
> > 
> > I realise that the mainline Linux developers have sometimes been
> > unreasonably resistant to these changes and I'm not intending to assign
> > blame for this.  But practically this means that we have to either carry
> > the featureset indefinitely or disappoint users by removing it in a
> > later release.  (See the complaints about removing OpenVZ in wheezy
> > despite 4 years' advance notice of this.)
> 
> I understand this, and I still see the grsec featureset as a valuable
> project. Indeed, reducing the diff wrt. upstream in Debian kernel is an
> important goal (especially considering the time involvement).
> 
> Now, I still think having a hardened Debian kernel inside the
> distribution is helpful
[...]

I agree and I would like to see hardening of *all* our configurations,
where the performance cost is not too much.  That's going to protect all
our users rather than just people who seek out a special paranoid
configuration.

Ben.

-- 
Ben Hutchings
Lowery's Law:
             If it jams, force it. If it breaks, it needed replacing anyway.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Mon, 30 Jan 2012 15:45:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Peter Samuelson <peter@p12n.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Mon, 30 Jan 2012 15:45:04 GMT) Full text and rfc822 format available.

Message #233 received at 605090@bugs.debian.org (full text, mbox):

From: Peter Samuelson <peter@p12n.org>
To: Brad Spengler <spender@grsecurity.net>
Cc: debian-kernel@lists.debian.org, debian-devel@lists.debian.org, debian-security@lists.debian.org, 605090@bugs.debian.org
Subject: Re: Linux 3.2 in wheezy
Date: Mon, 30 Jan 2012 09:40:49 -0600
[Brad Spengler]
> Frankly it makes more sense for me to offer .debs myself than to deal
> with a bureaucracy and non-standard kernel in Debian.  It contains
> who-knows-what extra code, and I doubt anyone looked at any of it to
> see if it allows for some way to leak information I prevent against a
> vanilla kernel, or a way to bypass any other existing protection.

I hope you aren't complaining that the Debian kernel team doesn't
include your patch, and also complaining that Debian kernel team
includes too many patches, in the same email.

Probably that isn't what you tried to say, but that's kinda what it
sounded like.

Peter




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Mon, 30 Jan 2012 21:30:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <corsac@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Mon, 30 Jan 2012 21:30:12 GMT) Full text and rfc822 format available.

Message #238 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <corsac@debian.org>
To: 605090@bugs.debian.org
Cc: debian-kernel@lists.debian.org, debian-devel@lists.debian.org, debian-security@lists.debian.org, spender@grsecurity.net, Ben Hutchings <ben@decadent.org.uk>
Subject: Re: Bug#605090: Linux 3.2 in wheezy
Date: Mon, 30 Jan 2012 22:26:50 +0100
[Message part 1 (text/plain, inline)]
On lun., 2012-01-30 at 14:08 +0000, Ben Hutchings wrote:
> On Mon, 2012-01-30 at 11:05 +0100, Yves-Alexis Perez wrote:
> > (adding few CC:s to keep track on the bug)
> > 
> > On dim., 2012-01-29 at 21:26 +0000, Ben Hutchings wrote:
> > > On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
> > > > On dim., 2012-01-29 at 18:22 +0000, Ben Hutchings wrote:
> > > > > Featuresets
> > > > > -----------
> > > > > 
> > > > > The only featureset provided will be 'rt' (realtime), currently built
> > > > > for amd64 only.  If there is interest in realtime support for other
> > > > > architectures, we may be able to add that.  However, we do need to
> > > > > consider the total time taken to build binary packages for each
> > > > > architecture.
> > > > > 
> > > > > If there are particular container features that should be enabled or
> > > > > backported to provide a useful replacement for OpenVZ or VServer,
> > > > > please let us know.  We cannot promise that these will all be enabled
> > > > > but we need to know what is missing. 
> > > > 
> > > > So in the end what are the reasons for not trying the grsecurity
> > > > featureset? #605090 lacks any reply from the kernel team since quite a
> > > > while, and especially after answers were provided to question asked.
> > > 
> > > You already know the main reason:
> > > > Feature-wise, Brad Sprengler and the PaX team still add stuff, like the
> > > > gcc plugins or hardening features like symbols hiding, fix bugs (for
> > > > example in RBAC code), while few of them reach mainline.
> > > 
> > > I realise that the mainline Linux developers have sometimes been
> > > unreasonably resistant to these changes and I'm not intending to assign
> > > blame for this.  But practically this means that we have to either carry
> > > the featureset indefinitely or disappoint users by removing it in a
> > > later release.  (See the complaints about removing OpenVZ in wheezy
> > > despite 4 years' advance notice of this.)
> > 
> > I understand this, and I still see the grsec featureset as a valuable
> > project. Indeed, reducing the diff wrt. upstream in Debian kernel is an
> > important goal (especially considering the time involvement).
> > 
> > Now, I still think having a hardened Debian kernel inside the
> > distribution is helpful
> [...]
> 
> I agree and I would like to see hardening of *all* our configurations,
> where the performance cost is not too much.  That's going to protect all
> our users rather than just people who seek out a special paranoid
> configuration.

So I think it's perfectly clear that nor Debian nor Grsecurity are
really interested in Debian shipping a Grsecurity kernel.

I find that sad, because I do think there are users of both which would
benefit from that, and not only people who seek out a special paranoid
configuration.

Anyway, I'll keep updating the current setup for interested people, but
without any interest from either party, that definitely looks like a
dead end.

Regards,
-- 
Yves-Alexis
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Tue, 31 Jan 2012 16:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to micah anderson <micah@riseup.net>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Tue, 31 Jan 2012 16:03:04 GMT) Full text and rfc822 format available.

Message #243 received at 605090@bugs.debian.org (full text, mbox):

From: micah anderson <micah@riseup.net>
To: Yves-Alexis Perez <corsac@debian.org>, 605090@bugs.debian.org
Cc: debian-kernel@lists.debian.org, debian-devel@lists.debian.org, debian-security@lists.debian.org, spender@grsecurity.net, Ben Hutchings <ben@decadent.org.uk>
Subject: Re: Bug#605090: Linux 3.2 in wheezy
Date: Tue, 31 Jan 2012 11:01:04 -0500
[Message part 1 (text/plain, inline)]
On Mon, 30 Jan 2012 22:26:50 +0100, Yves-Alexis Perez <corsac@debian.org> wrote:
> On lun., 2012-01-30 at 14:08 +0000, Ben Hutchings wrote:
> > On Mon, 2012-01-30 at 11:05 +0100, Yves-Alexis Perez wrote:
> > > (adding few CC:s to keep track on the bug)
> > > 
> > > On dim., 2012-01-29 at 21:26 +0000, Ben Hutchings wrote:
> > > > On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
> > > > > On dim., 2012-01-29 at 18:22 +0000, Ben Hutchings wrote:
[...]
> > > Now, I still think having a hardened Debian kernel inside the
> > > distribution is helpful
> > [...]
> > 
> > I agree and I would like to see hardening of *all* our configurations,
> > where the performance cost is not too much.  That's going to protect all
> > our users rather than just people who seek out a special paranoid
> > configuration.

Would you agree that there are some small hardening things that can be
done that don't impact performance that much? In particular the
privilege boundries mentioned earlier does not seem to introduce any
particular performance cost worth worrying about.

> So I think it's perfectly clear that nor Debian nor Grsecurity are
> really interested in Debian shipping a Grsecurity kernel.

Well, I don't think its fair to say "Debian" is not interested in
shipping a Grsecurity kernel. I think its more accurate to say that the
current configuration of the Debian kernel team doesn't find the time to
deal with it... but I'm not sure that speaks for all of Debian.

> I find that sad, because I do think there are users of both which would
> benefit from that, and not only people who seek out a special paranoid
> configuration.

I agree. On some machines, I would gladly trade perfomance for a
hardened kernel where that is more important and it is unfortunate that
the attempt to appeal to all possible configurations at the same time
results in a kernel that doesn't allow for specialized configurations
that people want/need.

> Anyway, I'll keep updating the current setup for interested people, but
> without any interest from either party, that definitely looks like a
> dead end.

What is stopping you from creating another package, that provides the
kernel with grsecurity patches applied? Don't bother the kernel team
with it, and just maintain it yourself in the archive? Its free software
afterall. 

micah
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 01 Feb 2012 09:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <corsac@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 01 Feb 2012 09:27:05 GMT) Full text and rfc822 format available.

Message #248 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <corsac@debian.org>
To: micah anderson <micah@riseup.net>
Cc: 605090@bugs.debian.org, debian-kernel@lists.debian.org, debian-devel@lists.debian.org, debian-security@lists.debian.org, Ben Hutchings <ben@decadent.org.uk>
Subject: Re: Bug#605090: Linux 3.2 in wheezy
Date: Wed, 01 Feb 2012 10:24:40 +0100
[Message part 1 (text/plain, inline)]
On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
> On Mon, 30 Jan 2012 22:26:50 +0100, Yves-Alexis Perez <corsac@debian.org> wrote:
> > So I think it's perfectly clear that nor Debian nor Grsecurity are
> > really interested in Debian shipping a Grsecurity kernel.
> 
> Well, I don't think its fair to say "Debian" is not interested in
> shipping a Grsecurity kernel. I think its more accurate to say that the
> current configuration of the Debian kernel team doesn't find the time to
> deal with it... but I'm not sure that speaks for all of Debian.

Well, in this case, that's mostly the same. I'm sure there are people in
Debian which are interested (even outside of me). But here, the kernel
team has the final word (well, or the tech ctte, but I really don't see
the point of that).
> 
[…]

> 
> > Anyway, I'll keep updating the current setup for interested people, but
> > without any interest from either party, that definitely looks like a
> > dead end.
> 
> What is stopping you from creating another package, that provides the
> kernel with grsecurity patches applied? Don't bother the kernel team
> with it, and just maintain it yourself in the archive? Its free software
> afterall. 
> 

Honestly, having multiple linux source package in the archive doesn't
really sound like a good idea. I don't really think the kernel team
would appreciate, I'm pretty sure ftpmasters would disagree, and as a
member of the security team, It's definitely something I would object.

Regards,
-- 
Yves-Alexis
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 01 Feb 2012 09:54:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <corsac@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 01 Feb 2012 09:54:11 GMT) Full text and rfc822 format available.

Message #253 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <corsac@debian.org>
To: Wouter Verhelst <wouter@debian.org>
Cc: micah anderson <micah@riseup.net>, 605090@bugs.debian.org, debian-kernel@lists.debian.org, debian-devel@lists.debian.org, debian-security@lists.debian.org, Ben Hutchings <ben@decadent.org.uk>
Subject: Re: Bug#605090: Linux 3.2 in wheezy
Date: Wed, 01 Feb 2012 10:51:25 +0100
[Message part 1 (text/plain, inline)]
On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
> On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
> > On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
> > > What is stopping you from creating another package, that provides the
> > > kernel with grsecurity patches applied? Don't bother the kernel team
> > > with it, and just maintain it yourself in the archive? Its free software
> > > afterall. 
> > > 
> > 
> > Honestly, having multiple linux source package in the archive doesn't
> > really sound like a good idea. I don't really think the kernel team
> > would appreciate, I'm pretty sure ftpmasters would disagree, and as a
> > member of the security team, It's definitely something I would object.
> 
> Well, that's what we have the 'linux-source' packages for: to allow
> other packages to build-depend on them.
> 

Hmhm, that might be a good idea indeed. I need to investigate and try
that a bit.

Ben, what would kernel team think of that?

Regards,
-- 
Yves-Alexis
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 01 Feb 2012 10:21:31 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wouter Verhelst <wouter@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 01 Feb 2012 10:21:34 GMT) Full text and rfc822 format available.

Message #258 received at 605090@bugs.debian.org (full text, mbox):

From: Wouter Verhelst <wouter@debian.org>
To: Yves-Alexis Perez <corsac@debian.org>
Cc: micah anderson <micah@riseup.net>, 605090@bugs.debian.org, debian-kernel@lists.debian.org, debian-devel@lists.debian.org, debian-security@lists.debian.org, Ben Hutchings <ben@decadent.org.uk>
Subject: Re: Bug#605090: Linux 3.2 in wheezy
Date: Wed, 1 Feb 2012 10:34:28 +0100
On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
> On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
> > What is stopping you from creating another package, that provides the
> > kernel with grsecurity patches applied? Don't bother the kernel team
> > with it, and just maintain it yourself in the archive? Its free software
> > afterall. 
> > 
> 
> Honestly, having multiple linux source package in the archive doesn't
> really sound like a good idea. I don't really think the kernel team
> would appreciate, I'm pretty sure ftpmasters would disagree, and as a
> member of the security team, It's definitely something I would object.

Well, that's what we have the 'linux-source' packages for: to allow
other packages to build-depend on them.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 01 Feb 2012 14:33:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ben Hutchings <ben@decadent.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 01 Feb 2012 14:33:08 GMT) Full text and rfc822 format available.

Message #263 received at 605090@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: Yves-Alexis Perez <corsac@debian.org>
Cc: Wouter Verhelst <wouter@debian.org>, micah anderson <micah@riseup.net>, 605090@bugs.debian.org, debian-kernel@lists.debian.org, debian-devel@lists.debian.org, debian-security@lists.debian.org
Subject: Re: Bug#605090: Linux 3.2 in wheezy
Date: Wed, 01 Feb 2012 14:32:19 +0000
[Message part 1 (text/plain, inline)]
On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote:
> On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
> > On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
> > > On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
> > > > What is stopping you from creating another package, that provides the
> > > > kernel with grsecurity patches applied? Don't bother the kernel team
> > > > with it, and just maintain it yourself in the archive? Its free software
> > > > afterall. 
> > > > 
> > > 
> > > Honestly, having multiple linux source package in the archive doesn't
> > > really sound like a good idea. I don't really think the kernel team
> > > would appreciate, I'm pretty sure ftpmasters would disagree, and as a
> > > member of the security team, It's definitely something I would object.
> > 
> > Well, that's what we have the 'linux-source' packages for: to allow
> > other packages to build-depend on them.
> > 
> 
> Hmhm, that might be a good idea indeed. I need to investigate and try
> that a bit.
> 
> Ben, what would kernel team think of that?

I don't speak for the whole team, but I don't see that it solves any
problem.  You would have to Build-Depend on exact versions of
linux-source, so that you know your external patches will apply.  Then
you would have to rebase the patches every time linux-2.6 is updated,
making sure (without much help from upstream) that you don't introduce a
subtle security problem.

Ben.

-- 
Ben Hutchings
Lowery's Law:
             If it jams, force it. If it breaks, it needed replacing anyway.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 01 Feb 2012 17:45:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <corsac@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 01 Feb 2012 17:45:06 GMT) Full text and rfc822 format available.

Message #268 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <corsac@debian.org>
To: Ben Hutchings <ben@decadent.org.uk>, 605090@bugs.debian.org
Cc: Wouter Verhelst <wouter@debian.org>, micah anderson <micah@riseup.net>, debian-kernel@lists.debian.org, debian-devel@lists.debian.org, debian-security@lists.debian.org, spender@grsecurity.net
Subject: Re: Bug#605090: Linux 3.2 in wheezy
Date: Wed, 01 Feb 2012 18:41:43 +0100
[Message part 1 (text/plain, inline)]
On mer., 2012-02-01 at 14:32 +0000, Ben Hutchings wrote:
> On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote:
> > On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
> > > On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
> > > > On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
> > > > > What is stopping you from creating another package, that provides the
> > > > > kernel with grsecurity patches applied? Don't bother the kernel team
> > > > > with it, and just maintain it yourself in the archive? Its free software
> > > > > afterall. 
> > > > > 
> > > > 
> > > > Honestly, having multiple linux source package in the archive doesn't
> > > > really sound like a good idea. I don't really think the kernel team
> > > > would appreciate, I'm pretty sure ftpmasters would disagree, and as a
> > > > member of the security team, It's definitely something I would object.
> > > 
> > > Well, that's what we have the 'linux-source' packages for: to allow
> > > other packages to build-depend on them.
> > > 
> > 
> > Hmhm, that might be a good idea indeed. I need to investigate and try
> > that a bit.
> > 
> > Ben, what would kernel team think of that?
> 
> I don't speak for the whole team, but I don't see that it solves any
> problem.  You would have to Build-Depend on exact versions of
> linux-source, so that you know your external patches will apply.  Then
> you would have to rebase the patches every time linux-2.6 is updated,
> making sure (without much help from upstream) that you don't introduce a
> subtle security problem.
> 
Well, that's already what I do and intended to do (and that's clear from
the beginning of the bug report).

Wrt not introducing subtle security problems, what I mostly do is remove
the security backports from the grsec patch which are already applied to
Debian kernel, so this part is fairly straightforward.

Now indeed when doing the job for Squeeze kernel it's a bit less
straightforward because of the huge amount of driver backports, but from
my own experience, the conflicts are still mostly about changed context
lines.

Regards,
-- 
Yves-Alexis
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 01 Feb 2012 18:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ben Hutchings <ben@decadent.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 01 Feb 2012 18:33:03 GMT) Full text and rfc822 format available.

Message #273 received at 605090@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: Yves-Alexis Perez <corsac@debian.org>
Cc: 605090@bugs.debian.org, Wouter Verhelst <wouter@debian.org>, micah anderson <micah@riseup.net>, debian-kernel@lists.debian.org, debian-devel@lists.debian.org, debian-security@lists.debian.org, spender@grsecurity.net
Subject: Re: Bug#605090: Linux 3.2 in wheezy
Date: Wed, 1 Feb 2012 18:30:44 +0000
On Wed, Feb 01, 2012 at 06:41:43PM +0100, Yves-Alexis Perez wrote:
> On mer., 2012-02-01 at 14:32 +0000, Ben Hutchings wrote:
> > On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote:
> > > On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
> > > > On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
> > > > > On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
> > > > > > What is stopping you from creating another package, that provides the
> > > > > > kernel with grsecurity patches applied? Don't bother the kernel team
> > > > > > with it, and just maintain it yourself in the archive? Its free software
> > > > > > afterall. 
> > > > > > 
> > > > > 
> > > > > Honestly, having multiple linux source package in the archive doesn't
> > > > > really sound like a good idea. I don't really think the kernel team
> > > > > would appreciate, I'm pretty sure ftpmasters would disagree, and as a
> > > > > member of the security team, It's definitely something I would object.
> > > > 
> > > > Well, that's what we have the 'linux-source' packages for: to allow
> > > > other packages to build-depend on them.
> > > > 
> > > 
> > > Hmhm, that might be a good idea indeed. I need to investigate and try
> > > that a bit.
> > > 
> > > Ben, what would kernel team think of that?
> > 
> > I don't speak for the whole team, but I don't see that it solves any
> > problem.  You would have to Build-Depend on exact versions of
> > linux-source, so that you know your external patches will apply.  Then
> > you would have to rebase the patches every time linux-2.6 is updated,
> > making sure (without much help from upstream) that you don't introduce a
> > subtle security problem.
> > 
> Well, that's already what I do and intended to do (and that's clear from
> the beginning of the bug report).
> 
> Wrt not introducing subtle security problems, what I mostly do is remove
> the security backports from the grsec patch which are already applied to
> Debian kernel, so this part is fairly straightforward.
> 
> Now indeed when doing the job for Squeeze kernel it's a bit less
> straightforward because of the huge amount of driver backports, but from
> my own experience, the conflicts are still mostly about changed context
> lines.

But your upstream disagrees on that point.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Wed, 01 Feb 2012 18:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to dann frazier <dannf@dannf.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 01 Feb 2012 18:57:04 GMT) Full text and rfc822 format available.

Message #278 received at 605090@bugs.debian.org (full text, mbox):

From: dann frazier <dannf@dannf.org>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: Yves-Alexis Perez <corsac@debian.org>, Wouter Verhelst <wouter@debian.org>, micah anderson <micah@riseup.net>, 605090@bugs.debian.org, debian-kernel@lists.debian.org, debian-devel@lists.debian.org, debian-security@lists.debian.org
Subject: Re: Bug#605090: Linux 3.2 in wheezy
Date: Wed, 1 Feb 2012 11:46:55 -0700
On Wed, Feb 01, 2012 at 02:32:19PM +0000, Ben Hutchings wrote:
> On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote:
> > On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
> > > On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
> > > > On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
> > > > > What is stopping you from creating another package, that provides the
> > > > > kernel with grsecurity patches applied? Don't bother the kernel team
> > > > > with it, and just maintain it yourself in the archive? Its free software
> > > > > afterall. 
> > > > > 
> > > > 
> > > > Honestly, having multiple linux source package in the archive doesn't
> > > > really sound like a good idea. I don't really think the kernel team
> > > > would appreciate, I'm pretty sure ftpmasters would disagree, and as a
> > > > member of the security team, It's definitely something I would object.
> > > 
> > > Well, that's what we have the 'linux-source' packages for: to allow
> > > other packages to build-depend on them.
> > > 
> > 
> > Hmhm, that might be a good idea indeed. I need to investigate and try
> > that a bit.
> > 
> > Ben, what would kernel team think of that?
> 
> I don't speak for the whole team,

and nor do I..

> but I don't see that it solves any
> problem.  You would have to Build-Depend on exact versions of
> linux-source, so that you know your external patches will apply.  Then
> you would have to rebase the patches every time linux-2.6 is updated,
> making sure (without much help from upstream) that you don't introduce a
> subtle security problem.

Whilte it may help the kernel team to not have to worry about problems
in the grsec flavor when preparing uploads, preventing delays for the
non-grsec images. But, that just pushes the coordination down a ways -
for stable updates we would need to add the grsec build into the
pipeline, and there'd be delays in grsec security updates that go in
via linux-2.6. Not nak'ing the idea, but it does extend some critical
paths.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Thu, 02 Feb 2012 01:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to russell@coker.com.au:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 02 Feb 2012 01:33:03 GMT) Full text and rfc822 format available.

Message #283 received at 605090@bugs.debian.org (full text, mbox):

From: Russell Coker <russell@coker.com.au>
To: debian-devel@lists.debian.org
Cc: dann frazier <dannf@dannf.org>, Ben Hutchings <ben@decadent.org.uk>, "Yves-Alexis Perez" <corsac@debian.org>, Wouter Verhelst <wouter@debian.org>, micah anderson <micah@riseup.net>, 605090@bugs.debian.org, debian-kernel@lists.debian.org, debian-security@lists.debian.org
Subject: Re: Bug#605090: Linux 3.2 in wheezy
Date: Thu, 2 Feb 2012 12:18:01 +1100
On Thu, 2 Feb 2012, dann frazier <dannf@dannf.org> wrote:
> Whilte it may help the kernel team to not have to worry about problems
> in the grsec flavor when preparing uploads, preventing delays for the
> non-grsec images. But, that just pushes the coordination down a ways -
> for stable updates we would need to add the grsec build into the
> pipeline, and there'd be delays in grsec security updates that go in
> via linux-2.6. Not nak'ing the idea, but it does extend some critical
> paths.

The current approach of having a kernel patch package seems to work well.  It 
removes the need for involvement of the kernel and security teams (presumably 
security changes to the kernel will usually not require changes to the 
grsecurity patch) and allows the users to easily build their own kernels.

If a user has a choice between using Spender's Debian package and a kernel-
patch package to build their own kernel then I think that they should be able 
to do whatever they want.

Spender suggested that people who want GRSecurity on Debian would be better 
off using a .deb he provides and working on user-space hardening.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Thu, 02 Feb 2012 06:27:33 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees de Jong <keesdejong@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 02 Feb 2012 06:27:33 GMT) Full text and rfc822 format available.

Message #288 received at 605090@bugs.debian.org (full text, mbox):

From: Kees de Jong <keesdejong@gmail.com>
To: russell@coker.com.au
Cc: debian-devel@lists.debian.org, dann frazier <dannf@dannf.org>, Ben Hutchings <ben@decadent.org.uk>, Yves-Alexis Perez <corsac@debian.org>, Wouter Verhelst <wouter@debian.org>, micah anderson <micah@riseup.net>, 605090@bugs.debian.org, debian-kernel@lists.debian.org, debian-security@lists.debian.org
Subject: Re: Bug#605090: Linux 3.2 in wheezy
Date: Thu, 02 Feb 2012 07:18:48 +0100
[Message part 1 (text/plain, inline)]
Perhaps you should contact Julien Tinnes of http://kernelsec.cr0.org/ 
He has been too busy to work on the kernels lately but maybe he wants to
help.





On do, 2012-02-02 at 12:18 +1100, Russell Coker wrote:

> On Thu, 2 Feb 2012, dann frazier <dannf@dannf.org> wrote:
> > Whilte it may help the kernel team to not have to worry about problems
> > in the grsec flavor when preparing uploads, preventing delays for the
> > non-grsec images. But, that just pushes the coordination down a ways -
> > for stable updates we would need to add the grsec build into the
> > pipeline, and there'd be delays in grsec security updates that go in
> > via linux-2.6. Not nak'ing the idea, but it does extend some critical
> > paths.
> 
> The current approach of having a kernel patch package seems to work well.  It 
> removes the need for involvement of the kernel and security teams (presumably 
> security changes to the kernel will usually not require changes to the 
> grsecurity patch) and allows the users to easily build their own kernels.
> 
> If a user has a choice between using Spender's Debian package and a kernel-
> patch package to build their own kernel then I think that they should be able 
> to do whatever they want.
> 
> Spender suggested that people who want GRSecurity on Debian would be better 
> off using a .deb he provides and working on user-space hardening.
> 
> -- 
> My Main Blog         http://etbe.coker.com.au/
> My Documents Blog    http://doc.coker.com.au/
> 
> 


-- 
Met vriendelijke groet,
Kees de Jong



                De informatie opgenomen in dit bericht kan vertrouwelijk
                zijn en is uitsluitend bestemd voor de
                geadresseerde(n). 
                Indien u dit bericht onterecht ontvangt, wordt u
                verzocht de inhoud niet te gebruiken en de afzender
                direct te informeren door het bericht te retourneren.
                --
                The information contained in this message may be
                confidential and is intended to be exclusively for the
                addressee(s). 
                Should you receive this message unintentionally, please
                do not use the contents herein and notify the sender
                immediately by return e-mail. 
                
                
                
                
                
                
                
                
                
[Message part 2 (text/html, inline)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Thu, 02 Feb 2012 06:42:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <corsac@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 02 Feb 2012 06:42:04 GMT) Full text and rfc822 format available.

Message #293 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <corsac@debian.org>
To: Kees de Jong <keesdejong@gmail.com>
Cc: russell@coker.com.au, debian-devel@lists.debian.org, dann frazier <dannf@dannf.org>, Ben Hutchings <ben@decadent.org.uk>, Wouter Verhelst <wouter@debian.org>, micah anderson <micah@riseup.net>, 605090@bugs.debian.org, debian-kernel@lists.debian.org, debian-security@lists.debian.org, Julien Tinnes <julien.tinnes@google.com>
Subject: Re: Bug#605090: Linux 3.2 in wheezy
Date: Thu, 02 Feb 2012 07:39:05 +0100
[Message part 1 (text/plain, inline)]
> On do, 2012-02-02 at 12:18 +1100, Russell Coker wrote: 
> > On Thu, 2 Feb 2012, dann frazier <dannf@dannf.org> wrote:
> > > Whilte it may help the kernel team to not have to worry about problems
> > > in the grsec flavor when preparing uploads, preventing delays for the
> > > non-grsec images. But, that just pushes the coordination down a ways -
> > > for stable updates we would need to add the grsec build into the
> > > pipeline, and there'd be delays in grsec security updates that go in
> > > via linux-2.6. Not nak'ing the idea, but it does extend some critical
> > > paths.
> > 
> > The current approach of having a kernel patch package seems to work well.  It 
> > removes the need for involvement of the kernel and security teams (presumably 
> > security changes to the kernel will usually not require changes to the 
> > grsecurity patch) and allows the users to easily build their own kernels.
> > 
> > If a user has a choice between using Spender's Debian package and a kernel-
> > patch package to build their own kernel then I think that they should be able 
> > to do whatever they want.
> > 
> > Spender suggested that people who want GRSecurity on Debian would be better 
> > off using a .deb he provides and working on user-space hardening.
> > 

(please don't top-post)
If people on the CC: list want to be dropped, please ask :)

On jeu., 2012-02-02 at 07:18 +0100, Kees de Jong wrote:
> Perhaps you should contact Julien Tinnes of http://kernelsec.cr0.org/ 
> He has been too busy to work on the kernels lately but maybe he wants
to help.
> 
> 

Well Julien was aware of my initiative and, afaict, he didn't really
have time for that, nor was interested in the porting part.

And as I said before, I'm not interested in shipping just a patch in
Debian. If users want to patch the kernel, configure it and built it, I
think they're better off getting the latest patch from grsecurity.net
and kernel from kernel.org. The point was in shipping a binary package
with a default setup secure enough, and a way to tune the features
through sysctl.

Regards,
-- 
Yves-Alexis
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Fri, 03 Feb 2012 00:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Fri, 03 Feb 2012 00:00:31 GMT) Full text and rfc822 format available.

Message #298 received at 605090@bugs.debian.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: debian-devel@lists.debian.org
Cc: 605090@bugs.debian.org, debian-kernel@lists.debian.org, debian-security@lists.debian.org
Subject: Re: Bug#605090: Linux 3.2 in wheezy
Date: Fri, 03 Feb 2012 00:55:59 +0100
[Message part 1 (text/plain, inline)]
On Thu, 2012-02-02 at 12:18 +1100, Russell Coker wrote:
> The current approach of having a kernel patch package seems to work well.
Phew... well.... there are many people running at >stable... and for
them it does not... as the package seems more or less orphaned.

Also,.. configuring something complex like grsec is probably nothing for
the end-user who, however, should have also an easy way to benefit from
it.


> It 
> removes the need for involvement of the kernel and security teams (presumably 
> security changes to the kernel will usually not require changes to the 
> grsecurity patch) and allows the users to easily build their own kernels.
Well, even though it means [much] work for them,... wouldn't that
involvement be just the good thing? Having some real experts, looking
after everything?!


> Spender suggested that people who want GRSecurity on Debian would be better 
> off using a .deb he provides and working on user-space hardening.
Well IMHO, at best, one should never need to rund anything from outside
the Debian archives ;)


Cheers,
Chris.
[smime.p7s (application/x-pkcs7-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Fri, 03 Feb 2012 00:36:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ben Hutchings <ben@decadent.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Fri, 03 Feb 2012 00:36:06 GMT) Full text and rfc822 format available.

Message #303 received at 605090@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: Christoph Anton Mitterer <calestyo@scientia.net>
Cc: debian-devel@lists.debian.org, 605090@bugs.debian.org, debian-kernel@lists.debian.org, debian-security@lists.debian.org
Subject: Re: Bug#605090: Linux 3.2 in wheezy
Date: Fri, 3 Feb 2012 00:34:10 +0000
On Fri, Feb 03, 2012 at 12:55:59AM +0100, Christoph Anton Mitterer wrote:
> On Thu, 2012-02-02 at 12:18 +1100, Russell Coker wrote:
> > The current approach of having a kernel patch package seems to work well.
> Phew... well.... there are many people running at >stable... and for
> them it does not... as the package seems more or less orphaned.
> 
> Also,.. configuring something complex like grsec is probably nothing for
> the end-user who, however, should have also an easy way to benefit from
> it.

There is an easy way to benefit from it.  Download and build an
official release.  I assume 'make deb-pkg' works like in mainline
Linux.

> > It 
> > removes the need for involvement of the kernel and security teams (presumably 
> > security changes to the kernel will usually not require changes to the 
> > grsecurity patch) and allows the users to easily build their own kernels.
> Well, even though it means [much] work for them,... wouldn't that
> involvement be just the good thing? Having some real experts, looking
> after everything?!

You flatter us.  General experience with kernel development does not
make someone an expert that is capable of understanding all the
implications of rebasing a patch or patch set that modifies many core
kernel features.

> > Spender suggested that people who want GRSecurity on Debian would be better 
> > off using a .deb he provides and working on user-space hardening.
> Well IMHO, at best, one should never need to rund anything from outside
> the Debian archives ;)

Wishing it so doesn't make it practically possible.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Fri, 03 Feb 2012 00:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Fri, 03 Feb 2012 00:51:06 GMT) Full text and rfc822 format available.

Message #308 received at 605090@bugs.debian.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: debian-devel@lists.debian.org
Cc: 605090@bugs.debian.org, debian-kernel@lists.debian.org, debian-security@lists.debian.org
Subject: Re: Bug#605090: Linux 3.2 in wheezy
Date: Fri, 03 Feb 2012 01:47:20 +0100
[Message part 1 (text/plain, inline)]
On Fri, 2012-02-03 at 00:34 +0000, Ben Hutchings wrote:
> There is an easy way to benefit from it.
Well still the user wouldn't know how to configure it...
Actually I must admit that I haven't followed PaX/grsec now for some
time (mainly due to the deb package being always out of date in sid).

Wasn't it once the case with PaX that packages have to be compiled
specially? Or some ELF headers added or so?
And there were no execute features which are perhaps superseded to some
extent (now that AMD64 has NX bit)...
So what I mean in the end,... I'm surely not an expert with respect to
the kernel, but at least I used to have my own .config since years,..
still it would mean quite some effort for me to get PaX/grsec running in
a way that I for myself believe I've done it right.
And this does not include tracing problems (I _very_ vaguely remember
that one had to make exceptions e.g. for Java?)

And that's why I think that such "special" frameworks like PaX/grsec,
SElinux, Apparmor, Smack, etc. pp. make only sense if well supported by
the distro, at least for some (blind guess:) 80-90% of all potential
users.



> You flatter us.  General experience with kernel development does not
> make someone an expert that is capable of understanding all the
> implications of rebasing a patch or patch set that modifies many core
> kernel features.
Well come on Ben,.. you've already helped me so often with issues with
the kernel,... you guys have at least some very good overview on
everything!


> > Well IMHO, at best, one should never need to rund anything from outside
> > the Debian archives ;)
> Wishing it so doesn't make it practically possible.
Well.. so far I do :D


Cheers,
Chris.
[smime.p7s (application/x-pkcs7-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Fri, 03 Feb 2012 01:18:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to russell@coker.com.au:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Fri, 03 Feb 2012 01:18:04 GMT) Full text and rfc822 format available.

Message #313 received at 605090@bugs.debian.org (full text, mbox):

From: Russell Coker <russell@coker.com.au>
To: debian-security@lists.debian.org
Cc: Christoph Anton Mitterer <calestyo@scientia.net>, debian-devel@lists.debian.org, 605090@bugs.debian.org, debian-kernel@lists.debian.org
Subject: Re: Bug#605090: Linux 3.2 in wheezy
Date: Fri, 3 Feb 2012 12:15:27 +1100
On Fri, 3 Feb 2012, Christoph Anton Mitterer <calestyo@scientia.net> wrote:
> Wasn't it once the case with PaX that packages have to be compiled
> specially? Or some ELF headers added or so?

Some shared libraries have code which can't be run without an executable 
stack, it's a small number of libraries that are written in assembler code.  
We want to allow running them but don't want to give all programs permission 
to execute code on the stack.

From memory the GR Security option for this was to flag the rare executables 
that want an executable stack and are permitted to have it.

The solution devised by libc/gcc upstream was to have a special assembly 
section in every shared object that doesn't require an executable stack and if 
an executable only loads shared objects that don't require it then the 
executable stack is disabled.  Then we have SE Linux policy to prevent most 
programs from having an executable stack which means that if they are tricked 
into loading some of the rare libraries that need it then it doesn't do 
anything bad.

The downside to the latter approach is that lots of shared objects which have 
some assembler code needed to be patched.

The PaX approach involved less work.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Mon, 06 Feb 2012 10:27:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yves-Alexis Perez <corsac@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Mon, 06 Feb 2012 10:27:06 GMT) Full text and rfc822 format available.

Message #318 received at 605090@bugs.debian.org (full text, mbox):

From: Yves-Alexis Perez <corsac@debian.org>
To: 605090@bugs.debian.org
Subject: Grsec to follow 3.2 stable release
Date: Mon, 06 Feb 2012 11:23:02 +0100
This might be relevant for interested people:


> Linux 3.2 chosen as new stable kernel, 2.6.32 support continues (Feb 04
> 2012) 
> The PaX Team and I have decided on Linux 3.2 as the new stable
> kernel, joining with the choice made by Debian and Ubuntu. We will
> continue to support 2.6.32 until the end of this year, at least.

(http://grsecurity.net/news.php#newstable)

Regards,
-- 
Yves-Alexis





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Thu, 09 Feb 2012 09:50:40 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 09 Feb 2012 09:50:42 GMT) Full text and rfc822 format available.

Message #323 received at 605090@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Yves-Alexis Perez <corsac@debian.org>
Cc: Wouter Verhelst <wouter@debian.org>, micah anderson <micah@riseup.net>, 605090@bugs.debian.org, debian-kernel@lists.debian.org, debian-devel@lists.debian.org, debian-security@lists.debian.org, Ben Hutchings <ben@decadent.org.uk>
Subject: Re: Bug#605090: Linux 3.2 in wheezy
Date: Thu, 09 Feb 2012 10:49:39 +0100
Yves-Alexis Perez <corsac@debian.org> writes:

> On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
>> On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
>> > On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
>> > > What is stopping you from creating another package, that provides the
>> > > kernel with grsecurity patches applied? Don't bother the kernel team
>> > > with it, and just maintain it yourself in the archive? Its free software
>> > > afterall. 
>> > > 
>> > 
>> > Honestly, having multiple linux source package in the archive doesn't
>> > really sound like a good idea. I don't really think the kernel team
>> > would appreciate, I'm pretty sure ftpmasters would disagree, and as a
>> > member of the security team, It's definitely something I would object.
>> 
>> Well, that's what we have the 'linux-source' packages for: to allow
>> other packages to build-depend on them.
>> 
>
> Hmhm, that might be a good idea indeed. I need to investigate and try
> that a bit.
>
> Ben, what would kernel team think of that?
>
> Regards,
> -- 
> Yves-Alexis

Don't forget to set "Build-With:" in the resulting binary package. That
ensure DAK will keep the right linux-source package around as long as
your package is in the repository. Otherwise you will have GPL
violations.

MfG
        Goswin




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Thu, 24 May 2012 15:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees de Jong <kees.dejong@adyen.com>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>.

Your message did not contain a Subject field. They are recommended and useful because the title of a $gBug is determined using this field. Please remember to include a Subject field in your messages in future.

(Thu, 24 May 2012 15:27:06 GMT) Full text and rfc822 format available.


Message #328 received at 605090@bugs.debian.org (full text, mbox):

From: Kees de Jong <kees.dejong@adyen.com>
To: 605090@bugs.debian.org
Date: Thu, 24 May 2012 17:17:38 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Is there a status update on this work? Will Wheezy get a grsec feature
set kernel? Thanks for all the work so far!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPvlEPAAoJENRhrNqNnJdg5i4H/3kGJ8fquM9SCJksiWBikrbi
BxzjEaZHJbbFkogZ0V443lOF3DqCV7bgFCroyGY0emxV8ZCqe6SD8jUsorBcXKLA
+pKHcF1pWB4CVAZQj4Dc0P4goDkYbXV39dR9XSzA4ynaTIErKLRfECpOKami6zPs
1eUvOPk91hZ0thVJw909A6/ec1PxP1Y5NNhDVLdNGN4ptWkTwDGi7ATqNblhwURE
bTbM/Z0RWbcW9kDuAcoI2k8KfpLHDCEomwtKMYGIDULwcUM78pvyjbNCQ9RuIj3r
6e1uoQPqNpYOdIIma+a1r4PGSh2Dbw7X+OG9kfOK0KW+FWBjmaAxCA5NDCzWeX0=
=FXI2
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#605090; Package linux-2.6. (Mon, 09 Jul 2012 06:42:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to tomasz.w@gmx.de:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>.

Your message did not contain a Subject field. They are recommended and useful because the title of a $gBug is determined using this field. Please remember to include a Subject field in your messages in future.

(Mon, 09 Jul 2012 06:42:04 GMT) Full text and rfc822 format available.


Message #333 received at 605090@bugs.debian.org (full text, mbox):

From: Tomasz Wartalski <tomasz.w@gmx.de>
To: 605090@bugs.debian.org
Date: Mon, 09 Jul 2012 08:38:59 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I hope there will be some progress on this issue. There are advantages
in providing a grsec-patched kernel inside debian.

E.g: with a grsec patched vanilla kernel my radeon GPU tends to lock up
every couple of days and my computer doesn’t reliably recover from
standby. This ain’t happen with a stock debian kernel or a kernel build
out of the debian sources.

I’ve tried Yves-Alexis´s grsec-patched debian kernel and sources,
mentioned in this bugreport and they work like a charm. No more GPU
lock-ups and the standby issues are gone. I’m pretty sure there will be
other machine configurations out there, where folks just cannot run the
grsec-patched vanilla kernel using debian.

Please continue your work on this Yves-Alexis.

Cheers,

Tomasz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk/6fIMACgkQiypP+gYHZb9sOwCcDSfigVr5vnl/XhFDOoYaS+Be
EEQAoKKt89FtfJbXHzxFBKWCOiC+/DaH
=V+Zg
-----END PGP SIGNATURE-----




Bug reassigned from package 'linux-2.6' to 'src:linux'. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Sun, 25 Nov 2012 01:57:03 GMT) Full text and rfc822 format available.

Marked as found in versions linux-2.6/2.6.32-28. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Sun, 25 Nov 2012 01:57:03 GMT) Full text and rfc822 format available.

Added tag(s) upstream and moreinfo. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Sun, 25 Nov 2012 01:57:04 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 20:51:51 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.