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) which are not really compatible with DEBUG_RODATA. Regards, -- Yves-Alexis Perez ANSSI/ACE/LAM
Attachment:
signature.asc
Description: This is a digitally signed message part