Re: Bug#605090: Linux 3.2 in wheezy
Yves-Alexis Perez cor...@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 -- To UNSUBSCRIBE, email to debian-kernel-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-kernel-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 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 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-kernel-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 Fri, 3 Feb 2012, Christoph Anton Mitterer cales...@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 Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-kernel-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 mar., 2012-01-31 at 11:01 -0500, micah anderson wrote: On Mon, 30 Jan 2012 22:26:50 +0100, Yves-Alexis Perez cor...@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 Description: This is a digitally signed message part
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 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-kernel-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 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 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, 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-kernel-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 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-kernel-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
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-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120201184655.gb2...@dannf.org
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-kernel-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 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
Re: Bug#605090: Linux 3.2 in wheezy
On Thu, 2 Feb 2012, dann frazier da...@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 Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-kernel-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
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 da...@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 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 do, 2012-02-02 at 12:18 +1100, Russell Coker wrote: On Thu, 2 Feb 2012, dann frazier da...@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 Description: This is a digitally signed message part
Re: Bug#605090: Linux 3.2 in wheezy
On Mon, 30 Jan 2012 22:26:50 +0100, Yves-Alexis Perez cor...@debian.org 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 pgpTuJUbNvqex.pgp Description: PGP signature
Re: Linux 3.2 in wheezy
Ben Hutchings b...@decadent.org.uk writes: (See the complaints about removing OpenVZ in wheezy despite 4 years' advance notice of this.) There were complaints when this was originally decided four years ago by the kernel team. What is disturbing is that the complaints then (lxc is not even close to being a drop-in replacement for Linux-Vservers) are still true now. When I said this four years ago, I was somewhat placated by the fact that there was a long period of time still remaining that could result in lxc becoming a good replacement... now that we are getting closer to the wire, its becoming more obvious that this is not going to be the case. micah -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqdz3la6@algae.riseup.net
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-kernel-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: Linux 3.2 in wheezy
(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 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 Description: This is a digitally signed message part
Bug#605090: Linux 3.2 in wheezy
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 Description: Digital signature
Re: Linux 3.2 in wheezy
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. 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: Linux 3.2 in wheezy
Ben Hutchings, 2012-01-29 18:22:05 + : [...] 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. I would like to second the suggestion for also enabling rt for i386. My rationale is that this would allow for smooth audio (low latency and no clicks) on existing hardware. Upgrading the hardware to something more modern (and amd64) would probably lead to good audio without needing rt; I guess it makes as much sense to enable it on i386, where it's really going to make a difference, as on amd64, where it may not be needed for this particular use case. Roland. [Not subscribed to -kernel, please Cc: me on replies; I'll try to check the archives from time to time though.] -- Roland Mas Bee There Orr Bee A Rectangular Thyng! -- in Soul Music (Terry Pratchett) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehuhfcv8@mirexpress.internal.placard.fr.eu.org
Re: Linux 3.2 in wheezy
[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 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120130154049.ga2...@p12n.org
Re: Linux 3.2 in wheezy
Ben Hutchings b...@decadent.org.uk schrieb: 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.) That's not really comparable: Dropping a virtualisation flavour leaves people with OS guests they can no longer operate, while dropping grsec at a later point only makes them fall back to standard Linux security (if we set GRKERNSEC_NO_RBAC=y) Cheers, Moritz -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjidtsd.5q0@inutil.org
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
Linux 3.2 in wheezy
Debian 7.0 'wheezy' will include Linux 3.2. This is currently in unstable and will soon enter testing. The kernel team is open to backporting some features from later kernel versions, particularly to support newer hardware. 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. Compatibility - If you maintain a package for which the current stable version is not compatible with Linux 3.2, excluding kernel module packages, please consider making a stable update that fixes this. If you maintain a kernel module package, please ensure that this is compatible with Linux 3.2 in time for the freeze. Any modules that are not compatible will not be included in the release. I recently tested building all the module packages I could find against Linux 3.1 and have filed bugs against those that failed to build; however I have not tested against Linux 3.2 and would prefer that the respective maintainers did so. We intend to switch to 2-component upstream version numbers in the kernel version string, e.g. 3.3-1-amd64. This change has been deferred until after wheezy to avoid incompatibility with packages in squeeze that assume 3-component version numbers. If your package uses uname(1) or uname(2) please ensure that it is prepared for this *in wheezy* so that we can make the change immediately after. Upstream support Debian, Ubuntu and others will work upstream on a 3.2.y longterm series of bug fixes. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus signature.asc Description: Digital signature
Re: Linux 3.2 in wheezy
On Jan 29, Ben Hutchings b...@decadent.org.uk wrote: 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. As it is well known now, there is no useful replacement for OpenVZ (not I think for VServer, but I am not familiar as much with it) except for the minor use cases. Debian, Ubuntu and others will work upstream on a 3.2.y longterm Which others? -- ciao, Marco signature.asc Description: Digital signature
Re: Linux 3.2 in wheezy
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. We at MSU are definitly interested in -rt for 32-bit x86 (with pae). Before now, we have been building packages locally, however using distribution packages is definitly better. Nikita -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201201292255.57264@blacky.localdomain
Re: Linux 3.2 in wheezy
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. 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. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Linux 3.2 in wheezy
On Sun, 2012-01-29 at 20:03 +0100, Marco d'Itri wrote: On Jan 29, Ben Hutchings b...@decadent.org.uk wrote: 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. As it is well known now, there is no useful replacement for OpenVZ (not I think for VServer, but I am not familiar as much with it) except for the minor use cases. Debian, Ubuntu and others will work upstream on a 3.2.y longterm Which others? Whoever wants to. No distribution that I know of. Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do. signature.asc Description: This is a digitally signed message part
Re: Linux 3.2 in wheezy
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.) It also appears that you never had any response to your question to upstream about minimising the patch set. 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. Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do. signature.asc Description: This is a digitally signed message part
Re: Linux 3.2 in wheezy
On Sun, 2012-01-29 at 21:26 +, Ben Hutchings wrote: 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. Whew I'd also be waiting for this since... well since I knew about PaX ;) I think, given the great security benefits it can give, it would be really worth to have it in debian. Especially as the linux-patch-grsecurity2 package uses to be heavily unmaintained. :( 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. Yeah,... seeing it merged upstream would be the best, of course. 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.) Well I guess you really don't have to bother on this :) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
