Re: Bug#605090: Linux 3.2 in wheezy
Yves-Alexis Perez 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 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkcss5e4.fsf@frosties.localnet
Re: Bug#605090: Linux 3.2 in wheezy
On Wed, Feb 01, 2012 at 10:50:07PM +0100, Yves-Alexis Perez wrote: > On mer., 2012-02-01 at 19:14 +0100, Bastian Blank wrote: > > Since 3.1 or so it is not longer possible to use this package as source > > in terms of the GPL like the udebs have done for several releases. > Could you be a bit more specific? Up until 3.1, linux-source and linux-patch were able to recreate all versions of the source of this particular upstream version. This is not longer the case, so it needs exactly the version it was built against. Bastian -- Hailing frequencies open, Captain. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120203102825.ga15...@wavehammer.waldi.eu.org
Re: Bug#605090: Linux 3.2 in wheezy
On Fri, 3 Feb 2012, Christoph Anton Mitterer 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 Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201202031215.27866.russ...@coker.com.au
Re: Bug#605090: Linux 3.2 in wheezy
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 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120203003410.gx12...@decadent.org.uk
Re: Bug#605090: Linux 3.2 in wheezy
On Fri, 2012-02-03 at 00:34 +, 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 Description: S/MIME cryptographic signature
Re: Bug#605090: Linux 3.2 in wheezy
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 Description: S/MIME cryptographic signature
Re: Bug#605090: Linux 3.2 in wheezy
> On do, 2012-02-02 at 12:18 +1100, Russell Coker wrote: > > On Thu, 2 Feb 2012, dann frazier 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 Description: This is a digitally signed message part
Re: Bug#605090: Linux 3.2 in wheezy
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 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 Bloghttp://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. signature.asc Description: This is a digitally signed message part
Re: Bug#605090: Linux 3.2 in wheezy
On Thu, 2 Feb 2012, dann frazier 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 Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201202021218.02158.russ...@coker.com.au
Re: Bug#605090: Linux 3.2 in wheezy
On mer., 2012-02-01 at 19:14 +0100, Bastian Blank wrote: > On Wed, Feb 01, 2012 at 10:34:28AM +0100, Wouter Verhelst wrote: > > Well, that's what we have the 'linux-source' packages for: to allow > > other packages to build-depend on them. > > Since 3.1 or so it is not longer possible to use this package as source > in terms of the GPL like the udebs have done for several releases. > Could you be a bit more specific? -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Build-depending on the linux-source package (Re: Bug#605090: Linux 3.2 in wheezy)
Bastian Blank wrote: > Since 3.1 or so it is not longer possible to use this package as source > in terms of the GPL like the udebs have done for several releases. The Built-Using field[1] can take care of that, at least for debs. (I don't know about udebs.) [1] http://bugs.debian.org/641153 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120201190556.GA28314@burratino
Re: Bug#605090: Linux 3.2 in wheezy
On Wed, Feb 01, 2012 at 02:32:19PM +, 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. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120201184655.gb2...@dannf.org
Re: Bug#605090: Linux 3.2 in wheezy
On Wed, Feb 01, 2012 at 06:41:43PM +0100, Yves-Alexis Perez wrote: > On mer., 2012-02-01 at 14:32 +, 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 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120201183043.gv12...@decadent.org.uk
Re: Bug#605090: Linux 3.2 in wheezy
On Wed, Feb 01, 2012 at 10:34:28AM +0100, Wouter Verhelst wrote: > Well, that's what we have the 'linux-source' packages for: to allow > other packages to build-depend on them. Since 3.1 or so it is not longer possible to use this package as source in terms of the GPL like the udebs have done for several releases. Bastian -- A little suffering is good for the soul. -- Kirk, "The Corbomite Maneuver", stardate 1514.0 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120201181410.ga31...@wavehammer.waldi.eu.org
Re: Bug#605090: Linux 3.2 in wheezy
On mer., 2012-02-01 at 14:32 +, 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 Description: This is a digitally signed message part
Re: Bug#605090: Linux 3.2 in wheezy
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 Description: This is a digitally signed message part
Re: Bug#605090: Linux 3.2 in wheezy
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 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120201093428.gb31...@grep.be
Re: Bug#605090: Linux 3.2 in wheezy
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 Description: This is a digitally signed message part
Re: Bug#605090: Linux 3.2 in wheezy
On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote: > On Mon, 30 Jan 2012 22:26:50 +0100, Yves-Alexis Perez > 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 Description: This is a digitally signed message part
Re: Bug#605090: Linux 3.2 in wheezy
On 02/01/2012 12:01 AM, 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. > > micah > Having such option to choose between a normal (as default), and grsec kernel (if you know what you're doing (tm)), would really be great, IMO. Yves-Alexis, don't just discard it! Thomas -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f287f13.2070...@goirand.fr
Re: Bug#605090: Linux 3.2 in wheezy
On Mon, 30 Jan 2012 22:26:50 +0100, Yves-Alexis Perez wrote: > On lun., 2012-01-30 at 14:08 +, 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 +, Ben Hutchings wrote: > > > > On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote: > > > > > On dim., 2012-01-29 at 18:22 +, 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 pgpy3qdaRwiBa.pgp Description: PGP signature
Re: Bug#605090: Linux 3.2 in wheezy
On lun., 2012-01-30 at 14:08 +, 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 +, Ben Hutchings wrote: > > > On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote: > > > > On dim., 2012-01-29 at 18:22 +, 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 Description: This is a digitally signed message part
