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
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
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,
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,
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
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
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
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
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.
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
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
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.
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
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.
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
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.
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
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
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
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 @@
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
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
22 matches
Mail list logo
