First, thanks for your comments. I'm replying to both mails at once. On mer., 2011-01-26 at 08:25 +0100, Bastian Blank wrote: > On Tue, Jan 18, 2011 at 06:32:50PM +0100, Yves-Alexis Perez wrote: > > Index: debian/config/i386/grsec/defines > > =================================================================== > > --- debian/config/i386/grsec/defines (revision 0) > > +++ debian/config/i386/grsec/defines (revision 0) > > @@ -0,0 +1,9 @@ > > +[base] > > +flavours: > > + 686 > > No new non-pae image. Ok. In fact it's a good idea anyway because having PAE on means we have NX which makes it easier for Grsecurity. > > > + amd64 > > Why? Because people using 64bit kernels on i386 might still want a grsec variant. > > > +[grsec] > > +flavours: > > + i386 > > + amd64 > > What is this? I didn't really find the syntax for the “defines” files so I looked at the others ones and xen has that [xen] section but maybe it's only used internall by xen feature set. Will remove and check it doesn't break anything. > > > Index: debian/config/i386/defines > > =================================================================== > > --- debian/config/i386/defines (revision 16824) > > +++ debian/config/i386/defines (working copy) > > @@ -3,6 +3,7 @@ > > openvz > > vserver > > xen > > + grsec > > This was a sorted list. Fixed. > > > Index: debian/config/featureset-grsec/config > > =================================================================== > > --- debian/config/featureset-grsec/config (revision 0) > > +++ debian/config/featureset-grsec/config (revision 0) > > @@ -0,0 +1,152 @@ > > +# Disable XEN for UDEREF support > > +CONFIG_XEN=n > > Nope. Disabling core stuff needs more information. As the comment says, this is because UDEREF conflicts with XEN. The help for the Kconfig option says: config PAX_MEMORY_UDEREF bool "Prevent invalid userland pointer dereference" depends on X86 && !UML_X86 && !XEN select PAX_PER_CPU_PGD if X86_64 help By saying Y here the kernel will be prevented from dereferencing userland pointers in contexts where the kernel expects only kernel pointers. This is both a useful runtime debugging feature and a security measure that prevents exploiting a class of kernel bugs. The tradeoff is that some virtualization solutions may experience a huge slowdown and therefore you should not enable this feature for kernels meant to run in such environments. Whether a given VM solution is affected or not is best determined by simply trying it out, the performance impact will be obvious right on boot as this mechanism engages from very early on. A good rule of thumb is that VMs running on CPUs without hardware virtualization support (i.e., the majority of IA-32 CPUs) will likely experience the slowdown. I was assuming people wanting a grsec kernel would prefer having UDEREF than XEN, but we might as well use the more conservative approach and keep XEN enabled (and UDEREF disabled) and wait for feedback from users. If bugreports are reported asking for UDEREF we can still revisite that later. > > > Index: debian/config/featureset-grsec/defines > > =================================================================== > > --- debian/config/featureset-grsec/defines (revision 0) > > +++ debian/config/featureset-grsec/defines (revision 0) > > @@ -0,0 +1,8 @@ > > +[description] > > +part-short-grsec: Grsecurity and PaX protection > > This is already too long. What would be a good limit? Would “Grsecurity protection” work? As I understand it it's added to the short description of the various packages for that featureset so the total should be kept under 80 chars. Looking at other featureset we could go for “Grsecurity support” but I'm not sure it makes much sense. > > > +[image] > > +depends: linux-grsec-base,, paxctl > > Why is paxctl necessary? Also syntax error. PAX security features will enforce W^X mmap() (RANDMMAP), which some application don't like (for example browsers with JIT javascript engines). If one wants to use those application she has to disable it on the executable itself, which is done using paxctl (which can be used to enable/disable other protection type at runtime). It's not strictly a dependency so it can be demoted to Recommends (or moved to linux-grsec-base only) if you prefer. Syntax error is fixed. > > > --- debian/config/amd64/grsec/config (revision 0) > > +++ debian/config/amd64/grsec/config (revision 0) > > @@ -0,0 +1,5 @@ > > +# > > +# PaX > > +# > > +CONFIG_PAX_PER_CPU_PGD=y > > +CONFIG_TASK_SIZE_MAX_SHIFT=42 > > Remove, no real settings here. What do you mean by “real” settings? PAX_PER_CPU_PGD is enabled by UDEREF and TASK_SIZE_MAX_SHIFT is set to 42 on amd64 because of how it has been implemented without segmentation. More info can be found there: http://grsecurity.net/pipermail/grsecurity/2010-April/001024.html Due to the performances concerns, I've decided to keep UDEREF and KERNEXEC disabled on amd64 for now anyway, so those will disappear (independently of the i386 decision). On mer., 2011-01-26 at 09:03 +0100, Bastian Blank wrote: On Tue, Jan 18, 2011 at 06:32:50PM +0100, Yves-Alexis Perez wrote: > > I've started working on 2.6.37 since Brad Sprengler recently released > > the grsecurity patch for that kernel. > > Is there VCS or is this just a code drop without information about > changes? I was not even able to find older patches. Who does code > reviews without that information? No there is no VCS unfortunately. PAX part can be found http://www.grsecurity.net/~paxguy1/ and I follow the RSS for grsecurity on http://grsecurity.net/testing_rss.php > > The patch includes several modifications to selinux and random other > parts. Why are they not merged? Please show that they have been > submitted at least. As I already pointed out on the first mail, Brad Sprengler has already said he wasn't interested in upstreaming stuff. There is an upstreaming effort for some specific bits (like the https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Upstream Hardening I already gave). The selinux-specific part are related to the effort to make function pointers structures read-only (or do you have other specific parts in mind?). > > > Initial packaging for linux-grsec-base is at > > http://git.debian.org/?p=collab-maint/linux-grsec-base.git;a=summary if > > needed. > > Why is this not part of the patch below? The grsec.conf was attached to the initial bug report. As there is no easy way to ship an external file in the linux-image, I was told it'd be a better idea to make an external package and that helps because I can do the user creation there and add a README. > > Currently the patch only includes informations for i386 and amd64. > Please state your intentions about other architectures. For now I only tested on those architectures. Some hardening features are not architecture-dependent so it'd be nice to have them everywhere, but some are (especially the memory protection stuff, dependening on if the architecture support segmentation or not, has an NX bit etc. For example ARM support has been added recently (http://grsecurity.net/news.php#armdev). As it might require some config tuning I think other architectures should be enabled after some testing and if users are interested in the featureset. Right now I guess it makes sense for armel, ppc, sparc. I lack data for other arches. > > > + [ Yves-Alexis Perez ] > > + * Add a grsecurity featureset. > > *nitpick* the patch calls it "Grsecurity". Thanks, corrected. > > > Index: debian/config/featureset-grsec/config > > =================================================================== > > --- debian/config/featureset-grsec/config (revision 0) > > +++ debian/config/featureset-grsec/config (revision 0) > > @@ -0,0 +1,152 @@ > > +CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y > > Please show why this should not be enabled globaly. Good point, it should. I'll make a separated bug report. > > > +CONFIG_DEBUG_RODATA=y > > x86 specific and default on. Fixed. Thank you for your review. Regards, -- Yves-Alexis Perez ANSSI/ACE/LAM
Attachment:
signature.asc
Description: This is a digitally signed message part