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