Bug#605090: Updated patch
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 Description: This is a digitally signed message part
Bug#605090: Updated patch
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 Description: This is a digitally signed message part
Bug#605090: Updated patch
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 Description: This is a digitally signed message part
Bug#605090: Updated patch
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 Description: This is a digitally signed message part
Bug#605090: Updated patch
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! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605090: Updated patch
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605090: Updated patch
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605090: Updated patch
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 Description: This is a digitally signed message part
Bug#605090: Updated patch
On Wed, 9 Feb 2011 18:51:02 +0100, maximilian attems m...@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 pgpI0vjcFWczE.pgp Description: PGP signature
Bug#605090: Updated patch
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605090: Updated patch
On jeu., 2011-01-27 at 22:21 +, 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 Description: This is a digitally signed message part
Bug#605090: Updated patch
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 Description: This is a digitally signed message part
Bug#605090: Updated patch
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 Description: This is a digitally signed message part
Bug#605090: Updated patch
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605090: Updated patch
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
Bug#605090: Updated patch
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! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605090: Updated patch
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605090: Updated patch
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)
Bug#605090: Updated patch
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605090: Updated patch
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605090: Updated patch
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 Index: debian/changelog === --- debian/changelog (revision 16824) +++ debian/changelog (working copy) @@ -4,6 +4,9 @@ * [arm] ixp4xx: Revert build fix, now applied upstream which resulted in another build failure + [ Yves-Alexis Perez ] + * Add a grsecurity featureset. + -- Ben Hutchings b...@decadent.org.uk Mon, 10 Jan 2011 00:39:29 + linux-2.6 (2.6.37-1~experimental.1) experimental; urgency=low Index: debian/patches/series/base-extra === --- debian/patches/series/base-extra (revision 16824) +++ debian/patches/series/base-extra (working copy) @@ -1 +1 @@ - ++ features/all/grsec/grsecurity-2.2.1-2.6.37-201101172105+debian.patch featureset=grsec 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 + amd64 + +[grsec] +flavours: + i386 + amd64 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 flavours: 486 686 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 + +CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y +# enforce read-only kernel data +CONFIG_DEBUG_RODATA=y + +# +# Grsecurity +# +CONFIG_GRKERNSEC=y +# CONFIG_GRKERNSEC_LOW is not set +# CONFIG_GRKERNSEC_MEDIUM is not set +CONFIG_GRKERNSEC_HIGH=y +# CONFIG_GRKERNSEC_CUSTOM is not set + +# +# Address Space Protection +# +CONFIG_GRKERNSEC_KMEM=y +CONFIG_GRKERNSEC_IO=y +CONFIG_GRKERNSEC_PROC_MEMMAP=y +CONFIG_GRKERNSEC_BRUTE=y +CONFIG_GRKERNSEC_MODHARDEN=y +CONFIG_GRKERNSEC_HIDESYM=y + +# +# Role Based Access Control Options +# +# CONFIG_GRKERNSEC_NO_RBAC is not set +CONFIG_GRKERNSEC_ACL_HIDEKERN=y +CONFIG_GRKERNSEC_ACL_MAXTRIES=3 +CONFIG_GRKERNSEC_ACL_TIMEOUT=30 + +# +# Filesystem Protections +# +CONFIG_GRKERNSEC_PROC=y +CONFIG_GRKERNSEC_PROC_USER=y +CONFIG_GRKERNSEC_PROC_USERGROUP=y +CONFIG_GRKERNSEC_PROC_GID=64044 +CONFIG_GRKERNSEC_PROC_ADD=y +CONFIG_GRKERNSEC_LINK=y +CONFIG_GRKERNSEC_FIFO=y +CONFIG_GRKERNSEC_ROFS=y +CONFIG_GRKERNSEC_CHROOT=y +CONFIG_GRKERNSEC_CHROOT_MOUNT=y +CONFIG_GRKERNSEC_CHROOT_DOUBLE=y +CONFIG_GRKERNSEC_CHROOT_PIVOT=y +CONFIG_GRKERNSEC_CHROOT_CHDIR=y +CONFIG_GRKERNSEC_CHROOT_CHMOD=y +CONFIG_GRKERNSEC_CHROOT_FCHDIR=y +CONFIG_GRKERNSEC_CHROOT_MKNOD=y +CONFIG_GRKERNSEC_CHROOT_SHMAT=y +CONFIG_GRKERNSEC_CHROOT_UNIX=y +CONFIG_GRKERNSEC_CHROOT_FINDTASK=y +CONFIG_GRKERNSEC_CHROOT_NICE=y +CONFIG_GRKERNSEC_CHROOT_SYSCTL=y +CONFIG_GRKERNSEC_CHROOT_CAPS=y + +# +# Kernel Auditing +# +# CONFIG_GRKERNSEC_AUDIT_GROUP is not set +# CONFIG_GRKERNSEC_EXECLOG is not set +CONFIG_GRKERNSEC_RESLOG=y +CONFIG_GRKERNSEC_CHROOT_EXECLOG=y +CONFIG_GRKERNSEC_AUDIT_PTRACE=y +# CONFIG_GRKERNSEC_AUDIT_CHDIR is not set +CONFIG_GRKERNSEC_AUDIT_MOUNT=y +CONFIG_GRKERNSEC_SIGNAL=y +CONFIG_GRKERNSEC_FORKFAIL=y +CONFIG_GRKERNSEC_TIME=y +CONFIG_GRKERNSEC_PROC_IPADDR=y +# CONFIG_GRKERNSEC_AUDIT_TEXTREL is not set + +# +# Executable Protections +# +CONFIG_GRKERNSEC_EXECVE=y +CONFIG_GRKERNSEC_DMESG=y +CONFIG_GRKERNSEC_HARDEN_PTRACE=y +CONFIG_GRKERNSEC_TPE=y +CONFIG_GRKERNSEC_TPE_ALL=y +CONFIG_GRKERNSEC_TPE_INVERT=y +CONFIG_GRKERNSEC_TPE_GID=64040 + +# +# Network Protections +#
Bug#605090: Updated patch
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
Index: debian/patches/series/30-extra
===
--- debian/patches/series/30-extra (revision 16770)
+++ debian/patches/series/30-extra (working copy)
@@ -22,3 +22,5 @@
+ features/all/xen/radeon-ttm-PCIe-Use-dma_addr-if-TTM-has-set-it.patch featureset=xen
+ features/all/xen/nouveau-ttm-PCIe-Use-dma_addr-if-TTM-has-set-it.patch featureset=xen
+ features/all/xen/radeon-PCIe-Use-the-correct-index-field.patch featureset=xen
+
++ features/all/grsec/grsecurity-2.2.1-2.6.32.27-201101021130+debian.patch featureset=grsec
Index: debian/changelog
===
--- debian/changelog (revision 16770)
+++ debian/changelog (working copy)
@@ -22,6 +22,9 @@
* r8169: Change RTL8111D/RTL8168D initialisation and firmware loading to
match upstream version (for #564628)
+ [ Yves-Alexis Perez ]
+ * Add a grsecurity featureset.
+
[ maximilian attems ]
* [openvz] Reenable NF_CONNTRACK_IPV6. (closes: #580507)
* cifs: fix another memleak, in cifs_root_iget.
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
+ amd64
+
+[grsec]
+flavours:
+ i386
+ amd64
Index: debian/config/i386/defines
===
--- debian/config/i386/defines (revision 16770)
+++ debian/config/i386/defines (working copy)
@@ -7,6 +7,7 @@
openvz
vserver
xen
+ grsec
flavours:
486
686
Index: debian/config/featureset-grsec/config
===
--- debian/config/featureset-grsec/config (revision 0)
+++ debian/config/featureset-grsec/config (revision 0)
@@ -0,0 +1,144 @@
+#
+# Grsecurity
+#
+CONFIG_GRKERNSEC=y
+# CONFIG_GRKERNSEC_LOW is not set
+# CONFIG_GRKERNSEC_MEDIUM is not set
+CONFIG_GRKERNSEC_HIGH=y
+# CONFIG_GRKERNSEC_CUSTOM is not set
+
+#
+# Address Space Protection
+#
+CONFIG_GRKERNSEC_KMEM=y
+CONFIG_GRKERNSEC_IO=y
+CONFIG_GRKERNSEC_PROC_MEMMAP=y
+CONFIG_GRKERNSEC_BRUTE=y
+CONFIG_GRKERNSEC_MODHARDEN=y
+CONFIG_GRKERNSEC_HIDESYM=y
+
+#
+# Role Based Access Control Options
+#
+# CONFIG_GRKERNSEC_NO_RBAC is not set
+CONFIG_GRKERNSEC_ACL_HIDEKERN=y
+CONFIG_GRKERNSEC_ACL_MAXTRIES=3
+CONFIG_GRKERNSEC_ACL_TIMEOUT=30
+
+#
+# Filesystem Protections
+#
+CONFIG_GRKERNSEC_PROC=y
+CONFIG_GRKERNSEC_PROC_USER=y
+CONFIG_GRKERNSEC_PROC_USERGROUP=y
+CONFIG_GRKERNSEC_PROC_GID=64044
+CONFIG_GRKERNSEC_PROC_ADD=y
+CONFIG_GRKERNSEC_LINK=y
+CONFIG_GRKERNSEC_FIFO=y
+CONFIG_GRKERNSEC_ROFS=y
+CONFIG_GRKERNSEC_CHROOT=y
+CONFIG_GRKERNSEC_CHROOT_MOUNT=y
+CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
+CONFIG_GRKERNSEC_CHROOT_PIVOT=y
+CONFIG_GRKERNSEC_CHROOT_CHDIR=y
+CONFIG_GRKERNSEC_CHROOT_CHMOD=y
+CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
+CONFIG_GRKERNSEC_CHROOT_MKNOD=y
+CONFIG_GRKERNSEC_CHROOT_SHMAT=y
+CONFIG_GRKERNSEC_CHROOT_UNIX=y
+CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
+CONFIG_GRKERNSEC_CHROOT_NICE=y
+CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
