Bug#605090:

[Yves-Alexis Perez]

On ven., 2016-01-08 at 00:44 +, ban...@openmailbox.org wrote:
> I've been experimenting with the source package in unstable. There is 
> still some security advantages of building the source package such as 
> unique RANDSTRUCT values not known publicly: 
> https://github.com/Whonix/grsecurity-installer/issues/1#issuecomment-
> 169819722

Yeah but that's definitely not the point here, which was to provide a binary
package. For people willing to build their own kernels, the make deb-pkg way
is the most effective imho (or you could use Brad's build service).
> 
> Installing the build dependencies on Debian stable would upgrade a lot 
> of core libs to unstable. Can you consider adding the gcc and other 
> build tools Debian stable versions to the package control file?

I actually have a jessie branch which I'll try to upload to jessie-backports
at one point. For now it's available on my repository, as previously.

Regards,
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#605090:

[bancfc]

I've been experimenting with the source package in unstable. There is 
still some security advantages of building the source package such as 
unique RANDSTRUCT values not known publicly: 
https://github.com/Whonix/grsecurity-installer/issues/1#issuecomment-169819722


Installing the build dependencies on Debian stable would upgrade a lot 
of core libs to unstable. Can you consider adding the gcc and other 
build tools Debian stable versions to the package control file?



@Jacob

At the moment we have someone willing to work on expanding the paxrat 
exceptions configuration list. We are also looking at some of the 
prerequisities for Debian packaging and useful  features: 
https://github.com/subgraph/paxrat/issues


Can you please help in getting it packaged in Debian?

Bug#605090:

[Yves-Alexis Perez]

On mar., 2016-01-05 at 15:33 +0100, HacKurx wrote:
> There are 52 variables sysctl with grsecurity but 42 are used in
> grsec.conf (linux-grsec-base-0.1).
> To know the list :
> cat /usr/src/linux-4.3.3/grsecurity/grsec_sysctl.c | grep "\.procname"

Please report bugs like these against linux-grsec-base package. grsec.conf
still needs love, don't hesitate to provide patches.

Regards,
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#605090:

[HacKurx]

There are 52 variables sysctl with grsecurity but 42 are used in
grsec.conf (linux-grsec-base-0.1).
To know the list :
cat /usr/src/linux-4.3.3/grsecurity/grsec_sysctl.c | grep "\.procname"

kernel.grsecurity.disable_priv_io
kernel.grsecurity.linking_restrictions
kernel.grsecurity.enforce_symlinksifowner
kernel.grsecurity.symlinkown_gid
kernel.grsecurity.deter_bruteforce
kernel.grsecurity.fifo_restrictions
kernel.grsecurity.ptrace_readexec
kernel.grsecurity.consistent_setxid
kernel.grsecurity.ip_blackhole
kernel.grsecurity.lastack_retries
kernel.grsecurity.exec_logging
kernel.grsecurity.rwxmap_logging
kernel.grsecurity.signal_logging
kernel.grsecurity.forkfail_logging
kernel.grsecurity.timechange_logging
kernel.grsecurity.chroot_deny_shmat
kernel.grsecurity.chroot_deny_unix
kernel.grsecurity.chroot_deny_mount
kernel.grsecurity.chroot_deny_fchdir
kernel.grsecurity.chroot_deny_chroot
kernel.grsecurity.chroot_deny_pivot
kernel.grsecurity.chroot_enforce_chdir
kernel.grsecurity.chroot_deny_chmod
kernel.grsecurity.chroot_deny_mknod
kernel.grsecurity.chroot_restrict_nice
kernel.grsecurity.chroot_execlog
kernel.grsecurity.chroot_caps
kernel.grsecurity.chroot_deny_bad_rename
kernel.grsecurity.chroot_deny_sysctl
kernel.grsecurity.tpe
kernel.grsecurity.tpe_gid
kernel.grsecurity.tpe_invert
kernel.grsecurity.tpe_restrict_all
kernel.grsecurity.socket_all
kernel.grsecurity.socket_all_gid
kernel.grsecurity.socket_client
kernel.grsecurity.socket_client_gid
kernel.grsecurity.socket_server
kernel.grsecurity.socket_server_gid
kernel.grsecurity.audit_group
kernel.grsecurity.audit_gid
kernel.grsecurity.audit_chdir
kernel.grsecurity.audit_mount
kernel.grsecurity.dmesg
kernel.grsecurity.chroot_findtask
kernel.grsecurity.resource_logging
kernel.grsecurity.audit_ptrace
kernel.grsecurity.harden_ptrace
kernel.grsecurity.harden_ipc
kernel.grsecurity.grsec_lock
kernel.grsecurity.romount_protect
kernel.grsecurity.deny_new_usb

"kernel.pax.softmode" is not listed in that.

 --
 Best regards,

 HacKurx (Loic)
 blog.opensec.fr

Bug#605090:

[HacKurx]

Hi,

Add and use "paxctld" in Debian for configure PaX flags (equivalent to
paxd from arch linux):
https://grsecurity.net/download.php

And if you want inspiration for the making available of all:
https://projects.archlinux.org/svntogit/community.git/tree/trunk?h=packages/grsec-common

And one you know:
https://projects.archlinux.org/svntogit/community.git/tree/trunk?h=packages/paxd

For nvidia :
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nvidia-grsec

and to test the set:
https://github.com/slimm609/checksec.sh

-- 
Best regards,

HacKurx (Loic)
blog.opensec.fr

Bug#605090:

[HacKurx]

On Tue, 05 Jan 2016 15:40:50 +0100 Yves-Alexis Perez  wrote:
> On mar., 2016-01-05 at 15:33 +0100, HacKurx wrote:
> > There are 52 variables sysctl with grsecurity but 42 are used in
> > grsec.conf (linux-grsec-base-0.1).
> > To know the list :
> > cat /usr/src/linux-4.3.3/grsecurity/grsec_sysctl.c | grep "\.procname"
>
> Please report bugs like these against linux-grsec-base package. grsec.conf
> still needs love, don't hesitate to provide patches.
>
> Regards,
> --Â
> Yves-Alexis
>

Ok no problem, I will do a patch :)

Bug#605090:

[Jacob Appelbaum]

For those following along at home, I would suggest booting the grsec
enabled kernel once - then saving the output of `sudo lsmod` into a
file. Take every module you want (ie: all of them) and put the list
into /etc/initramfs-tools/modules - then you'll need to run
`dpkg-reconfigure linux-image-4.3.0-1-grsec-amd64` to ensure that
those modules are in the initramfs at boot time.

This should allow you to disable all module loading and thus close a
rather serious vulnerability: the ability to load kernel modules if
you are root. If the attacker has to force you to reboot, it also
means that the attacker has to leave a trace behind... First reboot
and make sure that it works and if it does, then set the sysctl
'kernel.modules_disabled=1' in /etc/sysctl.d/grsec.conf to stop all
module loading after that sysctl is set. This is also probably a fine
time to have finished your grsec tuning and so you can also probably
set `kernel.grsecurity.grsec_lock=1` as well.

The above may not work for everyone - and you may want to trim the
/etc/initramfs-tools/modules file to be less than the full output of
`lsmod` - ykmmv...

Bug#605090:

[Jacob Appelbaum]

On 12/21/15, Mickaël Salaün  wrote:
> On 21/12/2015 00:14, Jacob Appelbaum wrote:
>> I was left with:
>>
>> [ 1802.373906] grsec: denied untrusted exec (due to not being in
>> trusted group and file in non-root-owned directory) of
>> /run/user/1000/orcexec.bCtW1V by
>> /usr/bin/pulseaudio[alsa-source-ALC:3038] uid/euid:1000/1000
>> gid/egid:1000/1000, parent /lib/systemd/systemd[systemd:1]
>> uid/euid:0/0 gid/egid:0/0
>> [ 1802.373967] grsec: denied untrusted exec (due to not being in
>> trusted group and file in non-root-owned directory) of
>> /home/error/orcexec.SzaIXb by
>> /usr/bin/pulseaudio[alsa-source-ALC:3038] uid/euid:1000/1000
>> gid/egid:1000/1000, parent /lib/systemd/systemd[systemd:1]
>> uid/euid:0/0 gid/egid:0/0
>> [ 1802.374015] grsec: denied untrusted exec (due to not being in
>> trusted group and file in world-writable directory) of
>> /tmp/orcexec.5bPuTr by /usr/bin/pulseaudio[alsa-source-ALC:3038]
>> uid/euid:1000/1000 gid/egid:1000/1000, parent
>> /lib/systemd/systemd[systemd:1] uid/euid:0/0 gid/egid:0/0
>>
>> I have no idea why pulse audio is trying to exec anything but audio
>> works fine regardless - so I'm just going to ignore it.
>
> grsecurity enforce a healthy execution environment not respected by liborc.
> Pulseaudio creates executable files in /tmp, writable by everyone (with the
> sticky-bit exception), which are then forbidden from being executed.
>

Oh - I'm well aware that grsecurity is doing the correct thing! I'm
rather asking, why does pulse audio do this crazy thing? :-(

> You can set $TMPDIR to a private directory (e.g. /home//tmp) and this
> should do the trick. However, the better solution is to create a private FS
> namespace for your user (e.g. using pam_namespace) to polyinstanciate a
> private /tmp for every user.

I think grsecurity will still stop it as the trusted path execution
should stop it.

Bug#605090: Git tag signing

[Yves-Alexis Perez]

On dim., 2015-12-20 at 21:55 +, ban...@openmailbox.org wrote:
> I just wanted to mention Git tag signing. Its a very useful security 
> feature we use for protecting source code builds in our project.
> 
> https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

Ben Hutchings signs his src:linux tags (which I'm merging to my tree). I
didn't tag anything yet but I do intend to use signed tags too.

Regards,
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#605090:

[Jacob Appelbaum]

I'm also running this kernel with AppArmor and it seems to work without issue.

I followed the steps on https://wiki.debian.org/AppArmor/HowToUse
which sets "apparmor=1 security=apparmor" on the kernel command line
as documented:

sudo perl -pi -e 's,GRUB_CMDLINE_LINUX="(.*)"$,GRUB_CMDLINE_LINUX="$1
apparmor=1 security=apparmor",' /etc/default/grub
sudo update-grub
sudo reboot

It works without issue. This gives a kernel with grsecurity and
apparmor - hooray!

Bug#605090:

[Yves-Alexis Perez]

On lun., 2015-12-21 at 05:51 +, ban...@openmailbox.org wrote:
> Is there other ways to deal with unwanted network stack modules like 
> Appletalk besides going in and manually disabling them in config before 
> compiling?
> 
> Is disabling module loading enough?

Only you can say if it's enough for your use case. Once
kernel.modules_disabled=1, userland can't insert or remove modules from the
kernel anymore, but the object file will still be present on the filesystem.
> 
> Please give some insight if its okay to discuss.

I think it's irrelevant to this bug. I'm trying very hard *not* to modify the
kernel configuration from the standard linux kernel. If you need more
customization, rebuild your own kernels, it's really easy (you can see my
Kernel Recipes presentation [1]).

[1] https://kernel-recipes.org/en/2015/talks/hardened-kernels-for-everyone/

Regards,
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#605090:

[Yves-Alexis Perez]

On dim., 2015-12-20 at 23:14 +, Jacob Appelbaum wrote:
> To make my Debian Jessie system work with pax, I had to set pax flags
> for these three binaries:
> 
>   paxctl -c -m /usr/bin/gnome-shell
>   paxctl -c -m /usr/bin/gnome-session
>   paxctl -c -m /usr/bin/pulseaudio
> 
> If you don't want to modify the binary, you can also set the
> attributes in the file system:
> 
>   setfattr -n user.pax.flags -v m /usr/bin/gnome-shell
>   setfattr -n user.pax.flags -v m /usr/bin/gnome-session
>   setfattr -n user.pax.flags -v m /usr/bin/pulseaudio

For people reading this at home. Don't just blindly apply those commands to
your system, please check the grsecurity/PaX documentation before. You can
find bits of them at https://en.wikibooks.org/wiki/Grsecurity
> 
> You will need the `attr` package to run the above command. See
> https://wiki.debian.org/grsecurity/setfattr for more information. It
> may make sense to add a suggestion on the grsec kernel package for
> attr.

I can do that.
> 
> The above allowed me to properly start GDM and to login to my system.
> To use iceweasel and other utilities, I had to modify other things. I
> also was able to set `kernel.grsecurity.disable_priv_io=0` after
> running the setfattr commands above.

Good to know. With modesetting drivers I think privileged I/O is not useful
anymore in Xorg.
> 
> I additionally had to set the following to make the following programs
> "work" with this kernel:
> 
>   setfattr -n user.pax.flags -v m /usr/bin/seahorse
>   setfattr -n user.pax.flags -v m /usr/bin/iceweasel
>   setfattr -n user.pax.flags -v m /usr/bin/chromium
>   setfattr -n user.pax.flags -v m /usr/lib/chromium/chromium
> 
> For those who care pulse audio was also making some log entries about
> "denied resource overstep by requesting 25 for RLIMIT_NICE against
> limit 0 for /usr/bin/pulseaudio" - I reconfigured it with an edit to
> /etc/pulseaudio/daemon.conf to add 'high-priority = no' and the kernel
> stopped complaining.

Ok.
> 
> 
> 

> It might make sense to have a different bug where we track things that
> need to be done for user space. That said - this is now my main kernel
> - hooray!

You can try to open relevant bugs to the relevant packages, but in some case
it'll just be closed as “wontfix” because the package really needs rewritable
code segments, or upstream doesn't have manpower to change it, or whatever.
> 
> 
> As a side note, I found that kernel.modules_disabled=1 caused me a
> bunch of problems. It might be interesting to ensure that this is
> called before GDM3 login but not beforehand...

Indeed, modules_disabled=1 is really restrictive, but it also prevents a
robust way to prevent inserting code in the kernel, and improving the
userspace/kernelspace barrier.

I mostly use it on server boxes, where I first run a standard kernel, do
everything I need to do, then pick all loaded modules from lsmod and put them
in /etc/initramfs-tools/modules to have them loaded from the initramfs. Then
set kernel.modules_disabled=1 to prevent any further modification to the
running kernel.

Regards,
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#605090:

[Yves-Alexis Perez]

On dim., 2015-12-20 at 22:37 +, Jacob Appelbaum wrote:
> ( One difference I've noticed is that I no longer have the little
> frame buffer penguins at boot time - I think on this computer, I
> should see a bunch of them. I assume this is expected behavior but
> wanted to note it anyway. )

I /never/ saw any penguins on my Debian kernels, CONFIG_LOGO is not set on
i386/amd64 afair.

Regards,
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#605090:

[Mickaël Salaün]

On 21/12/2015 00:14, Jacob Appelbaum wrote:
> I was left with:
> 
> [ 1802.373906] grsec: denied untrusted exec (due to not being in
> trusted group and file in non-root-owned directory) of
> /run/user/1000/orcexec.bCtW1V by
> /usr/bin/pulseaudio[alsa-source-ALC:3038] uid/euid:1000/1000
> gid/egid:1000/1000, parent /lib/systemd/systemd[systemd:1]
> uid/euid:0/0 gid/egid:0/0
> [ 1802.373967] grsec: denied untrusted exec (due to not being in
> trusted group and file in non-root-owned directory) of
> /home/error/orcexec.SzaIXb by
> /usr/bin/pulseaudio[alsa-source-ALC:3038] uid/euid:1000/1000
> gid/egid:1000/1000, parent /lib/systemd/systemd[systemd:1]
> uid/euid:0/0 gid/egid:0/0
> [ 1802.374015] grsec: denied untrusted exec (due to not being in
> trusted group and file in world-writable directory) of
> /tmp/orcexec.5bPuTr by /usr/bin/pulseaudio[alsa-source-ALC:3038]
> uid/euid:1000/1000 gid/egid:1000/1000, parent
> /lib/systemd/systemd[systemd:1] uid/euid:0/0 gid/egid:0/0
> 
> I have no idea why pulse audio is trying to exec anything but audio
> works fine regardless - so I'm just going to ignore it.

grsecurity enforce a healthy execution environment not respected by liborc. 
Pulseaudio creates executable files in /tmp, writable by everyone (with the 
sticky-bit exception), which are then forbidden from being executed.

You can set $TMPDIR to a private directory (e.g. /home//tmp) and this 
should do the trick. However, the better solution is to create a private FS 
namespace for your user (e.g. using pam_namespace) to polyinstanciate a private 
/tmp for every user.

Regards,
 Mickaël



signature.asc
Description: OpenPGP digital signature

Bug#605090:

[bancfc]

Is there other ways to deal with unwanted network stack modules like 
Appletalk besides going in and manually disabling them in config before 
compiling?


Is disabling module loading enough?

Please give some insight if its okay to discuss.

Bug#605090:

[Jacob Appelbaum]

To make my Debian Jessie system work with pax, I had to set pax flags
for these three binaries:

  paxctl -c -m /usr/bin/gnome-shell
  paxctl -c -m /usr/bin/gnome-session
  paxctl -c -m /usr/bin/pulseaudio

If you don't want to modify the binary, you can also set the
attributes in the file system:

  setfattr -n user.pax.flags -v m /usr/bin/gnome-shell
  setfattr -n user.pax.flags -v m /usr/bin/gnome-session
  setfattr -n user.pax.flags -v m /usr/bin/pulseaudio

You will need the `attr` package to run the above command. See
https://wiki.debian.org/grsecurity/setfattr for more information. It
may make sense to add a suggestion on the grsec kernel package for
attr.

The above allowed me to properly start GDM and to login to my system.
To use iceweasel and other utilities, I had to modify other things. I
also was able to set `kernel.grsecurity.disable_priv_io=0` after
running the setfattr commands above.

I additionally had to set the following to make the following programs
"work" with this kernel:

  setfattr -n user.pax.flags -v m /usr/bin/seahorse
  setfattr -n user.pax.flags -v m /usr/bin/iceweasel
  setfattr -n user.pax.flags -v m /usr/bin/chromium
  setfattr -n user.pax.flags -v m /usr/lib/chromium/chromium

For those who care pulse audio was also making some log entries about
"denied resource overstep by requesting 25 for RLIMIT_NICE against
limit 0 for /usr/bin/pulseaudio" - I reconfigured it with an edit to
/etc/pulseaudio/daemon.conf to add 'high-priority = no' and the kernel
stopped complaining.

I now only see two grsec denied messages on by Debian jessie system after boot:

[9.560994] grsec: denied use of ioperm() by
/usr/lib/xorg/Xorg[Xorg:891] uid/euid:0/0 gid/egid:0/0, parent
/usr/sbin/gdm3[gdm3:885] uid/euid:0/0 gid/egid:0/0
[   12.091674] grsec: denied priority change of process
(rtkit-daemon:1066) by /usr/lib/rtkit/rtkit-daemon[rtkit-daemon:1066]
uid/euid:107/107 gid/egid:114/114, parent
/lib/systemd/systemd[systemd:1] uid/euid:0/0 gid/egid:0/0

After login - I see the following grsec messages:

[  448.243314] grsec: denied untrusted exec (due to not being in
trusted group and file in non-root-owned directory) of
/run/user/1000/orcexec.pIjl0t by
/usr/bin/pulseaudio[alsa-source-ALC:1617] uid/euid:1000/1000
gid/egid:1000/1000, parent /lib/systemd/systemd[systemd:1]
uid/euid:0/0 gid/egid:0/0
[  448.243366] grsec: denied untrusted exec (due to not being in
trusted group and file in non-root-owned directory) of
/home/error/orcexec.iEBctM by
/usr/bin/pulseaudio[alsa-source-ALC:1617] uid/euid:1000/1000
gid/egid:1000/1000, parent /lib/systemd/systemd[systemd:1]
uid/euid:0/0 gid/egid:0/0
[  448.243405] grsec: denied untrusted exec (due to not being in
trusted group and file in world-writable directory) of
/tmp/orcexec.VrI4V4 by /usr/bin/pulseaudio[alsa-source-ALC:1617]
uid/euid:1000/1000 gid/egid:1000/1000, parent
/lib/systemd/systemd[systemd:1] uid/euid:0/0 gid/egid:0/0
[  448.999276] grsec: denied RWX mmap of  by
/usr/share/system-config-printer/applet.py[applet.py:1661]
uid/euid:1000/1000 gid/egid:1000/1000, parent
/usr/bin/gnome-session[x-session-manag:1464] uid/euid:1000/1000
gid/egid:1000/1000
[  448.999349] grsec: denied untrusted exec (due to not being in
trusted group and file in world-writable directory) of /tmp/ffixSCBQp
by /usr/share/system-config-printer/applet.py[applet.py:1661]
uid/euid:1000/1000 gid/egid:1000/1000, parent
/usr/bin/gnome-session[x-session-manag:1464] uid/euid:1000/1000
gid/egid:1000/1000
[  448.999395] grsec: denied untrusted exec (due to not being in
trusted group and file in world-writable directory) of
/var/tmp/ffiQhZWhL by
/usr/share/system-config-printer/applet.py[applet.py:1661]
uid/euid:1000/1000 gid/egid:1000/1000, parent
/usr/bin/gnome-session[x-session-manag:1464] uid/euid:1000/1000
gid/egid:1000/1000
[  448.999422] grsec: denied untrusted exec (due to not being in
trusted group and file in world-writable directory) of
/dev/shm/ffi5YViJ6 by
/usr/share/system-config-printer/applet.py[applet.py:1661]
uid/euid:1000/1000 gid/egid:1000/1000, parent
/usr/bin/gnome-session[x-session-manag:1464] uid/euid:1000/1000
gid/egid:1000/1000
[  448.999457] grsec: more alerts, logging disabled for 10 seconds
[  449.760884] EXT4-fs (sdb1): mounted filesystem with ordered data
mode. Opts: (null)

To eliminate most of those issues, I ran:

  setfattr -n user.pax.flags -v m /usr/bin/seahorse
  setfattr -n user.pax.flags -v m /usr/bin/gjs-console
  setfattr -n user.pax.flags -v m /usr/bin/python

I was left with:

[ 1802.373906] grsec: denied untrusted exec (due to not being in
trusted group and file in non-root-owned directory) of
/run/user/1000/orcexec.bCtW1V by
/usr/bin/pulseaudio[alsa-source-ALC:3038] uid/euid:1000/1000
gid/egid:1000/1000, parent /lib/systemd/systemd[systemd:1]
uid/euid:0/0 gid/egid:0/0
[ 1802.373967] grsec: denied untrusted exec (due to not being in
trusted group and file in non-root-owned directory) of
/home/error/orcexec.SzaIXb by

Bug#605090: Git tag signing

[bancfc]

I just wanted to mention Git tag signing. Its a very useful security 
feature we use for protecting source code builds in our project.


https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

Bug#605090: linux-grsec testing

[Yves-Alexis Perez]

On dim., 2015-12-20 at 00:32 +, ban...@openmailbox.org wrote:
> Hi. After testing the kernel X doesn't boot because restrict mprotect is 
> enabled.


Hi,

it's most likely because you're using nvidia/nouveau or amd/radeon graphic
card, and the userland driver uses LLVMpipe which in turns uses JIT code. I
don't have the issue with my intel graphic card.

>  Are there plans to integrate a PaX exception list so mprotect 
> can be enabled system wide while common software can still work?

I don't have any, I'm mostly interested in the kernel part right now. Also the
exceptions are really system-specific, and you don't want them if you don't
really need them.

Regards,
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#605090: linux-grsec testing

[Yves-Alexis Perez]

On dim., 2015-12-20 at 19:28 +, ban...@openmailbox.org wrote:
> Agreed but there are many major software packages especially on the 
> desktop that need exceptions to work for example Iceweasel and by 
> extension Tor Browser.

Sure. I'm just not interested in maintaining that list myself.
> 
> For these you can just use paxd.conf that's maintained by Arch but the 
> list will need some tweaking for binary paths and package name 
> differences between them and Debian. Please see:
> 
> https://wiki.archlinux.org/index.php/PaX#User_exceptions
> https://github.com/thestinger/paxd/blob/master/paxd.conf

If you're volunteering to package paxd for Debian, feel free :)

Regards,
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#605090: linux-grsec testing

[bancfc]

On 2015-12-20 09:51, Yves-Alexis Perez wrote:

On dim., 2015-12-20 at 00:32 +, ban...@openmailbox.org wrote:
Hi. After testing the kernel X doesn't boot because restrict mprotect 
is 

enabled.



Hi,

it's most likely because you're using nvidia/nouveau or amd/radeon 
graphic
card, and the userland driver uses LLVMpipe which in turns uses JIT 
code. I

don't have the issue with my intel graphic card.


I see. In a KVM guest there is a similar conflict situation with the QXL 
driver too.





 Are there plans to integrate a PaX exception list so mprotect 
can be enabled system wide while common software can still work?


I don't have any, I'm mostly interested in the kernel part right now. 
Also the
exceptions are really system-specific, and you don't want them if you 
don't

really need them.



Agreed but there are many major software packages especially on the 
desktop that need exceptions to work for example Iceweasel and by 
extension Tor Browser.


For these you can just use paxd.conf that's maintained by Arch but the 
list will need some tweaking for binary paths and package name 
differences between them and Debian. Please see:


https://wiki.archlinux.org/index.php/PaX#User_exceptions
https://github.com/thestinger/paxd/blob/master/paxd.conf

Great work. I look forward to testing more releases in the future.


Regards,

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Jacob Appelbaum]

It may make sense for us to have a package of paxrat with common
configurations for Debian users:

  https://github.com/subgraph/paxrat

This would ensure that everyone can use this kernel and have xorg work
as expected, for example.

Otherwise, I think we will see a lot of people who just run:

  paxctl -m /usr/bin/Xorg

paxctl one off runs isn't great for a full solution.

paxrat improves on this as package updates and other things can stomp
on pax related xattributes. paxrat seems very very useful in this
context - we get configuration files as well as dpkg hooks.

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Jacob Appelbaum]

On 12/19/15, Yves-Alexis Perez  wrote:
> On jeu., 2015-11-05 at 22:08 +0100, Yves-Alexis Perez wrote:
>> On sam., 2015-10-10 at 21:55 +0200, Yves-Alexis Perez wrote:
>> > This is really a work in progress and this mail a request for comment.
>> > Especially missing is:
>>
>> So, did any of you have the chance to test it? I'm currently running the
>> 4.2.5
>> kernel with grsecurity-3.1-4.2.5-201511021814 (just uploaded to my
>> repository
>> and to git.d.o) and it works just fine.
>>
>> I'm really interested by any feedback you would have on this.
>>
> With a lot of help from Ben I've made quite some progress in having the
> less possible differences with src:linux package. With 4.3.3 we still have few
> things differing, some of them which I think will be integrated in the
> upcoming src:linux releases.
>

Great news - this looks fantastic!

> I'm intending to upload the current version to NEW during the week-end, so
> if any of you want to test it, now would be a good time.
>

I've installed it - I've also tuned a few things. It seems to work as
well as my previous kernel - audio works, etc.

> You can find it on the git repository
> at https://anonscm.debian.org/cgit/colla
> b-maint/linux-grsec.git and the source and binary packages on my apt
> repository
> at https://perso.corsac.net/~corsac/debian/kernel-grsec/packages/

To boot Debian Jessie (with some testing pacakes too) to X - I had to set:

kernel.grsecurity.disable_priv_io=0
kernel.pax.softmode=1
kernel.grsecirity.grsec_lock=0

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Ben Hutchings]

On Sat, 2015-12-19 at 17:03 +, Jacob Appelbaum wrote:
> On 12/19/15, Jacob Appelbaum  wrote:
[...]
> > To boot Debian Jessie (with some testing pacakes too) to X - I had to set:
> > 
> > kernel.grsecurity.disable_priv_io=0
> > kernel.pax.softmode=1
> > kernel.grsecirity.grsec_lock=0
> > 
> 
> With that stuff set - I also see the following:
> 
> Dec 19 17:44:32 vula kernel: [ 4047.508272] WARNING: CPU: 5 PID: 2109
> at /build/linux-grsec-4.3.3/debian/build/s
> ource_grsec/include/drm/drm_crtc.h:1577
> drm_helper_choose_crtc_dpms+0x8e/0x90 [drm_kms_helper]()
[...]
> Lots of things like that in my kernel log...

Almost certainly an upstream bug.  See
 for bug reporting.

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.

signature.asc
Description: This is a digitally signed message part

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Jacob Appelbaum]

On 12/19/15, Jacob Appelbaum  wrote:
> On 12/19/15, Yves-Alexis Perez  wrote:
>> On jeu., 2015-11-05 at 22:08 +0100, Yves-Alexis Perez wrote:
>>> On sam., 2015-10-10 at 21:55 +0200, Yves-Alexis Perez wrote:
>>> > This is really a work in progress and this mail a request for comment.
>>> > Especially missing is:
>>>
>>> So, did any of you have the chance to test it? I'm currently running the
>>> 4.2.5
>>> kernel with grsecurity-3.1-4.2.5-201511021814 (just uploaded to my
>>> repository
>>> and to git.d.o) and it works just fine.
>>>
>>> I'm really interested by any feedback you would have on this.
>>>
>> With a lot of help from Ben I've made quite some progress in having the
>> less possible differences with src:linux package. With 4.3.3 we still have
>> few
>> things differing, some of them which I think will be integrated in the
>> upcoming src:linux releases.
>>
>
> Great news - this looks fantastic!
>
>> I'm intending to upload the current version to NEW during the week-end,
>> so
>> if any of you want to test it, now would be a good time.
>>
>
> I've installed it - I've also tuned a few things. It seems to work as
> well as my previous kernel - audio works, etc.
>
>> You can find it on the git repository
>> at https://anonscm.debian.org/cgit/colla
>> b-maint/linux-grsec.git and the source and binary packages on my apt
>> repository
>> at https://perso.corsac.net/~corsac/debian/kernel-grsec/packages/
>
> To boot Debian Jessie (with some testing pacakes too) to X - I had to set:
>
> kernel.grsecurity.disable_priv_io=0
> kernel.pax.softmode=1
> kernel.grsecirity.grsec_lock=0
>

With that stuff set - I also see the following:

Dec 19 17:44:32 vula kernel: [ 4047.508272] WARNING: CPU: 5 PID: 2109
at /build/linux-grsec-4.3.3/debian/build/s
ource_grsec/include/drm/drm_crtc.h:1577
drm_helper_choose_crtc_dpms+0x8e/0x90 [drm_kms_helper]()
Dec 19 17:44:32 vula kernel: [ 4047.508272] Modules linked in:
binfmt_misc cfg80211 bridge stp llc snd_hda_codec
_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel
snd_hda_codec nouveau snd_hda_core intel_rapl io
sf_mbi snd_hwdep ttm eeepc_wmi x86_pkg_temp_thermal asus_wmi
drm_kms_helper sparse_keymap intel_powerclamp coret
emp snd_pcm rfkill drm iTCO_wdt video iTCO_vendor_support i2c_algo_bit
snd_timer kvm_intel fb_sys_fops mxm_wmi sb_edac syscopyarea psmouse
pcspkr mei_me serio_raw edac_core kvm joydev lpc_ich sysfillrect mei
snd mfd_core evdev sysimgblt soundcore i2c_i801 shpchp 8250_fintek wmi
tpm_infineon tpm_tis processor tpm button loop fuse autofs4 ext4 crc16
mbcache jbd2 algif_skcipher af_alg uas usb_storage hid_generic
hid_cherry usbhid hid dm_crypt dm_mod sg sd_mod crct10dif_pclmul
crc32_pclmul crc32c_intel jitterentropy_rng hmac drbg ahci libahci
ansi_cprng aesni_intel aes_x86_64 xhci_pci lrw gf128mul glue_helper
ablk_helper ehci_pci libata ehci_hcd xhci_hcd cryptd e1000e ptp
scsi_mod usbcore usb_common pps_core
Dec 19 17:44:32 vula kernel: [ 4047.508303] CPU: 5 PID: 2109 Comm:
kworker/5:0 Tainted: GW   4.3.0-1-grsec-amd64 #1 Debian
4.3.3-1+grsec1
Dec 19 17:44:32 vula kernel: [ 4047.508304] Hardware name: System
manufacturer System Product Name/P9X79, BIOS 4608 12/24/2013
Dec 19 17:44:32 vula kernel: [ 4047.508305] Workqueue: events a0696b70
Dec 19 17:44:32 vula kernel: [ 4047.508305]  
729b2a82b7c3ba87  a04779a0
Dec 19 17:44:32 vula kernel: [ 4047.508307]  812f376f
 810648e7 880dfb95d000
Dec 19 17:44:32 vula kernel: [ 4047.508308]  880036954000
 0003 
Dec 19 17:44:32 vula kernel: [ 4047.508310] Call Trace:
Dec 19 17:44:32 vula kernel: [ 4047.508314]  [] ?
sysrq_drm_fb_helper_restore_op+0x20/0x2db9 [drm_kms_helper]
Dec 19 17:44:32 vula kernel: [ 4047.508315]  [] ?
dump_stack+0x40/0x61
Dec 19 17:44:32 vula kernel: [ 4047.508317]  [] ?
warn_slowpath_common+0x77/0xb0
Dec 19 17:44:32 vula kernel: [ 4047.508319]  [] ?
drm_helper_choose_crtc_dpms+0x8e/0x90 [drm_kms_helper]
Dec 19 17:44:32 vula kernel: [ 4047.508322]  [] ?
drm_helper_connector_dpms+0x60/0x100 [drm_kms_helper]
Dec 19 17:44:32 vula kernel: [ 4047.508338]  [] ?
nouveau_connector_hotplug+0x69/0xb0 [nouveau]
Dec 19 17:44:32 vula kernel: [ 4047.508346]  [] ?
nvif_notify_work+0x2c/0xc0 [nouveau]
Dec 19 17:44:32 vula kernel: [ 4047.508355]  [] ?
nvkm_notify_work+0x78/0x80 [nouveau]
Dec 19 17:44:32 vula kernel: [ 4047.508356]  [] ?
process_one_work+0x14d/0x390
Dec 19 17:44:32 vula kernel: [ 4047.508358]  [] ?
worker_thread+0x63/0x490
Dec 19 17:44:32 vula kernel: [ 4047.508359]  [] ?
rescuer_thread+0x320/0x320
Dec 19 17:44:32 vula kernel: [ 4047.508360]  [] ?
kthread+0xeb/0x110
Dec 19 17:44:32 vula kernel: [ 4047.508362]  [] ?
kthread_park+0x60/0x60
Dec 19 17:44:32 vula kernel: [ 4047.508363]  [] ?
ret_from_fork+0x3e/0x70
Dec 19 17:44:32 vula kernel: [ 4047.508364]  [] ?
kthread_park+0x60/0x60
Dec 19 17:44:32 vula kernel: 

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Yves-Alexis Perez]

On jeu., 2015-11-05 at 22:08 +0100, Yves-Alexis Perez wrote:
> On sam., 2015-10-10 at 21:55 +0200, Yves-Alexis Perez wrote:
> > This is really a work in progress and this mail a request for comment.
> > Especially missing is:
> 
> So, did any of you have the chance to test it? I'm currently running the
> 4.2.5
> kernel with grsecurity-3.1-4.2.5-201511021814 (just uploaded to my
> repository
> and to git.d.o) and it works just fine.
> 
> I'm really interested by any feedback you would have on this.
> 
With a lot of help from Ben I've made quite some progress in having the less
possible differences with src:linux package. With 4.3.3 we still have few
things differing, some of them which I think will be integrated in the
upcoming src:linux releases.

I'm intending to upload the current version to NEW during the week-end, so if
any of you want to test it, now would be a good time.

You can find it on the git repository at https://anonscm.debian.org/cgit/colla
b-maint/linux-grsec.git and the source and binary packages on my apt
repository at https://perso.corsac.net/~corsac/debian/kernel-grsec/packages/

Any comment appreciated, obviously.

Regards,
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#605090: linux-grsec testing

[bancfc]

Hi. After testing the kernel X doesn't boot because restrict mprotect is 
enabled. Are there plans to integrate a PaX exception list so mprotect 
can be enabled system wide while common software can still work?

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Yves-Alexis Perez]

On sam., 2015-11-07 at 14:54 +, Ben Hutchings wrote:
> 1. linux-grsec-{source,support} are included in debian/control but not
> built by debian/rules.real.  I think these should be built; the latter
> will be needed to build metapackages as in linux-latest.
> 
> 
> 3. The changes to gencontrol.py and rules.real to disable most arch:all
> packages should depend on configuration, not the source package name.
> They would then be acceptable for inclusion on the master branch.
> 
So following your patch, I've pushed a split-docs [1] branch on my git
repository implenting this

I used the section name [docs] with enabled: true by default, and I used
DO_DOCS environment variable to pass the information from rules.gen to
rules.real (like FOREIGN_KERNEL case for example), I hope that's the right
thing to do.

I guess I could also call the env var SKIP_DOCS with the opposite logic if you
prefer (at that point it's really bikeshedding I guess).

I /think/ those two patches should be acceptable for inclusion.

Regards,

[1] https://anonscm.debian.org/cgit/collab-maint/linux-grsec.git/log/?h=split-
docs
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Ben Hutchings]

On Tue, 2015-11-10 at 10:42 +0100, Yves-Alexis Perez wrote:
> On sam., 2015-11-07 at 14:54 +, Ben Hutchings wrote:
> > I've given this a quick review and found a few issues:
> 
> Thanks!
> > 
> > 1. linux-grsec-{source,support} are included in debian/control but not
> > built by debian/rules.real.  I think these should be built; the latter
> > will be needed to build metapackages as in linux-latest.
> 
> Done. Right now the package name is hardcoded in debian/rules.real, I'll see
> if there's a way to get it from the configuration somehow (after I get more
> info from the #3 and #4 replies).

This seems to work:

--- a/debian/rules.real
+++ b/debian/rules.real
@@ -13,6 +13,7 @@ DEB_HOST_MULTIARCH:= $(shell dpkg-architecture -a'$(ARCH)' 
-qDEB_HOST_MULTIARCH)
 DEB_BUILD_ARCH:= $(shell dpkg-architecture -a'$(ARCH)' -qDEB_BUILD_ARCH)
 endif
 MAINTAINER := $(shell sed -ne 's,^Maintainer: .[^<]*<\([^>]*\)>,\1,p' 
debian/control)
+SOURCE_PACKAGE_NAME := $(shell dpkg-parsechangelog -SSource)
 DISTRIBUTION := $(shell dpkg-parsechangelog -SDistribution)
 SOURCE_DATE := $(shell dpkg-parsechangelog -SDate)
 SOURCE_DATE_UTC_ISO := $(shell date -u -d '$(SOURCE_DATE)' +%Y-%m-%d)
@@ -191,7 +192,7 @@ install-dummy:
    dh_prep
    +$(MAKE_SELF) install-base
 
-install-doc: PACKAGE_NAME = linux-doc-$(VERSION)
+install-doc: PACKAGE_NAME = $(SOURCE_PACKAGE_NAME)-doc-$(VERSION)
 install-doc: DIR = $(BUILD_DIR)/build-doc
 install-doc: PACKAGE_DIR = debian/$(PACKAGE_NAME)
 install-doc: OUT_DIR = $(PACKAGE_DIR)/usr/share/doc/$(PACKAGE_NAME)
@@ -210,7 +211,7 @@ install-doc: $(STAMPS_DIR)/build-doc
    gzip -9nqfr $(OUT_DIR)/Documentation
    +$(MAKE_SELF) install-base
 
-install-manual: PACKAGE_NAME = linux-manual-$(VERSION)
+install-manual: PACKAGE_NAME = $(SOURCE_PACKAGE_NAME)-manual-$(VERSION)
 install-manual: DIR=$(BUILD_DIR)/build-doc
 install-manual: DH_OPTIONS = -p$(PACKAGE_NAME)
 install-manual: $(STAMPS_DIR)/build-doc
@@ -329,7 +330,7 @@ install-libc-dev_$(ARCH):
 
    +$(MAKE_SELF) install-base
 
-install-support: PACKAGE_NAME = linux-support-$(ABINAME)
+install-support: PACKAGE_NAME = $(SOURCE_PACKAGE_NAME)-support-$(ABINAME)
 install-support: DH_OPTIONS = -p$(PACKAGE_NAME)
 install-support: PACKAGE_DIR = debian/$(PACKAGE_NAME)
 install-support: PACKAGE_ROOT = /usr/share/$(PACKAGE_NAME)
@@ -440,7 +441,7 @@ install-udeb_$(ARCH):
    dh_gencontrol
    dh_builddeb
 
-install-source: PACKAGE_NAME = linux-source-$(VERSION)
+install-source: PACKAGE_NAME = $(SOURCE_PACKAGE_NAME)-source-$(VERSION)
 install-source: DH_OPTIONS = -p$(PACKAGE_NAME)
 install-source: $(BUILD_DIR)/linux-source-$(UPSTREAMVERSION).tar.xz $(foreach 
FEATURESET,$(filter-out 
none,$(ALL_FEATURESETS)),$(BUILD_DIR)/linux-patch-$(UPSTREAMVERSION)-$(FEATURESET).patch.xz)
    dh_testdir
--- a/debian/templates/control.main.in
+++ b/debian/templates/control.main.in
@@ -1,4 +1,4 @@
-Package: linux-source-@version@
+Package: @source_package@-source-@version@
 Build-Profiles: 
 Architecture: all
 Section: kernel
@@ -13,7 +13,7 @@ Description: Linux kernel source for version @version@ with 
Debian patches
  features that have already been (or are believed to be) accepted by the
  upstream maintainers.
 
-Package: linux-doc-@version@
+Package: @source_package@-doc-@version@
 Build-Profiles: 
 Architecture: all
 Depends: ${misc:Depends}
@@ -27,7 +27,7 @@ Description: Linux kernel specific documentation for version 
@version@
  /usr/share/doc/linux-doc-@version@/Documentation/00-INDEX
  for the detailed description of the contents.
 
-Package: linux-manual-@version@
+Package: @source_package@-manual-@version@
 Build-Profiles: 
 Architecture: all
 Depends: ${misc:Depends}
@@ -46,7 +46,7 @@ Description: Linux kernel API manual pages for version 
@version@
  may be installed at a time.  The linux-doc package containing the
  documentation in other formats is free from such restriction.
 
-Package: linux-support-@abiname@
+Package: @source_package@-support-@abiname@
 Build-Profiles: 
 Architecture: all
 Section: devel
--- END ---

[...]
> > 3. The changes to gencontrol.py and rules.real to disable most arch:all
> > packages should depend on configuration, not the source package name.
> > They would then be acceptable for inclusion on the master branch.
> 
> By “configuration”, I guess you mean stuff in debian/config/featureset-
> grsec/defines? Unfortunately some of the stuff I touch in gencontrol.py and
> rules.real is not run when featureset is defined, but is more generic than
> that.
> 
> Or do you mean I would then modify debian/config/defines (and not the one
> under the featureset-grsec folder) in src;linux-grsec?

You would modify debian/config/defines.

> > 4. There's no need to remove the templates for packages you don't
> > build.  However, if you leave them in place, you'll need to override
> > do_extra() in gencontrol.py to omit the extra packages dependent on the
> > configuration (as for (3)).
> 
> Ok, I'll check 

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Yves-Alexis Perez]

On sam., 2015-11-07 at 14:54 +, Ben Hutchings wrote:
> I've given this a quick review and found a few issues:

Thanks!
> 
> 1. linux-grsec-{source,support} are included in debian/control but not
> built by debian/rules.real.  I think these should be built; the latter
> will be needed to build metapackages as in linux-latest.

Done. Right now the package name is hardcoded in debian/rules.real, I'll see
if there's a way to get it from the configuration somehow (after I get more
info from the #3 and #4 replies).
> 
> 2. udebs are included in debian/control but not built, and they should
> not be built.   You can fix this by deleting or commenting-out
> debian/installer/{amd64,i386}/kernel-versions

Good point. I'm currently disabling them by
using DEBIAN_KERNEL_DISABLE_INSTALLER when running gencontrol.py. Thanks for
the pointer.
> 
> 3. The changes to gencontrol.py and rules.real to disable most arch:all
> packages should depend on configuration, not the source package name.
> They would then be acceptable for inclusion on the master branch.

By “configuration”, I guess you mean stuff in debian/config/featureset-
grsec/defines? Unfortunately some of the stuff I touch in gencontrol.py and
rules.real is not run when featureset is defined, but is more generic than
that.

Or do you mean I would then modify debian/config/defines (and not the one
under the featureset-grsec folder) in src;linux-grsec?
> 
> 4. There's no need to remove the templates for packages you don't
> build.  However, if you leave them in place, you'll need to override
> do_extra() in gencontrol.py to omit the extra packages dependent on the
> configuration (as for (3)).

Ok, I'll check that. Again, what do you envision as configuration: a “source
package name” in debian/config/defines? Or even a boolean “grsec”? Or more
generic than that, a “build_extra” boolean?
> 
> 5. CONFIG_X86_X32 should be disabled, since you've disabled the patch
> to make x32 support dependent on a kernel parameter.

Ok, done.
> 
> 6. In debian/patches/features/all/grsec/gen-patch you can use the
> filterdiff -p1 to avoid assuming the path prefix will be 'b/'.

Thanks, done as well.

I've not yet pushed the local changes, I'll wait a bit for the replies.

Regards,
-- 
Yves-Alexis


signature.asc
Description: This is a digitally signed message part

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Ben Hutchings]

On Thu, 2015-11-05 at 22:08 +0100, Yves-Alexis Perez wrote:
> On sam., 2015-10-10 at 21:55 +0200, Yves-Alexis Perez wrote:
> > This is really a work in progress and this mail a request for comment.
> > Especially missing is:
> 
> So, did any of you have the chance to test it? I'm currently running the 4.2.5
> kernel with grsecurity-3.1-4.2.5-201511021814 (just uploaded to my repository
> and to git.d.o) and it works just fine.
> 
> I'm really interested by any feedback you would have on this.

I've given this a quick review and found a few issues:

1. linux-grsec-{source,support} are included in debian/control but not
built by debian/rules.real.  I think these should be built; the latter
will be needed to build metapackages as in linux-latest.

2. udebs are included in debian/control but not built, and they should
not be built.   You can fix this by deleting or commenting-out
debian/installer/{amd64,i386}/kernel-versions

3. The changes to gencontrol.py and rules.real to disable most arch:all
packages should depend on configuration, not the source package name.
They would then be acceptable for inclusion on the master branch.

4. There's no need to remove the templates for packages you don't
build.  However, if you leave them in place, you'll need to override
do_extra() in gencontrol.py to omit the extra packages dependent on the
configuration (as for (3)).

5. CONFIG_X86_X32 should be disabled, since you've disabled the patch
to make x32 support dependent on a kernel parameter.

6. In debian/patches/features/all/grsec/gen-patch you can use the
filterdiff -p1 to avoid assuming the path prefix will be 'b/'.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.

signature.asc
Description: This is a digitally signed message part

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Yves-Alexis Perez]

On sam., 2015-10-10 at 21:55 +0200, Yves-Alexis Perez wrote:
> This is really a work in progress and this mail a request for comment.
> Especially missing is:

So, did any of you have the chance to test it? I'm currently running the 4.2.5
kernel with grsecurity-3.1-4.2.5-201511021814 (just uploaded to my repository
and to git.d.o) and it works just fine.

I'm really interested by any feedback you would have on this.

Regards,
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Yves-Alexis Perez]

control: reassign -1 wnpp
control: retitle -1 ITP: linux-grsec -- Linux kernel with grsecurity patch

On mer., 2015-09-30 at 12:53 +0200, Yves-Alexis Perez wrote:
> I should be able to push something for review pretty soon

So here we are. I've pushed a git tree [1] of a linux-grsec source
package, heavily based on src:linux (it's actually a clone of linux.git
and I've worked in a grsec/sid branch).

I've kept the featureset idea, and on top of that:

- disabled all regular packages from src:linux (linux-libc-dev and
friends)
- disabled all non grsecurity featureset
- renamed the source package to linux-grsec

You can build it the same way you build the src:linux from git. I've
also uploaded packages for sid and Jessie to my repository [2],
including a .dsc [3] so rebuild should be easy.

This is really a work in progress and this mail a request for comment.
Especially missing is:

- various updates to the the debian/control templates (like
Maintainers/Uploaders etc.)
- updates to debian/copyright
- stuff I missed.

I started this with 4.1.7, updated from the v4.1.6-1 tag in the
linux.git. I've then pulled the 4.2.3-1 tag and it seemed to not break
that much, so it might indeed be workable (but we'll see in the long
run).

In any case, everything is in the git folder, and feel free to ask
questions if needed.

I don't intent to upload this to Debian right away, obviously :)

Regards,

[1] https://anonscm.debian.org/cgit/collab-maint/linux-grsec.git
[2] http://perso.corsac.net/~corsac/debian/kernel-grsec/packages/
[3] 
http://perso.corsac.net/~corsac/debian/kernel-grsec/packages/sid/linux-grsec_4.2.3-1.dsc
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#605090: update?

[Yves-Alexis Perez]

On Tue, Sep 15, 2015 at 12:20:06PM -0400, Erinn Clark wrote:
> * Yves-Alexis Perez  [2015:09:15 08:12 +0200]: 
> > I quickly discussed about that with Jacob on IRC following your ping,
> > and yes, my current plan is to start from the current src:linux git
> > repository (trying to avoid too much duplicate work), remove uneeded
> > stuff for us and add the grsecurity patch on top.
> > 
> > That way we might be able to sync / cherry-pick stuff from src:linux
> > every once in a while. If that's unmaintainable then we'll just
> > completely fork.
> > 
> > I didn't yet start the actual work, but I intend to do that in the
> > following days/weeks depending on my work schedule.
> 
> Awesome! Please update the ticket with a git repo where the development is
> happening once you begin, I'd love to be able to follow along and contribute 
> if
> possible. I'm currently building my own grsec kernel packages as it is and
> would be happy to at least test.

Hi,

I should be able to push something for review pretty soon, I've
restarted working on this. Also I just gave my talk at kernel recipes
2015 [1]. Slides and video should be avaiable at one point on the
website, but in the meantime the former is available at [2].

Regards,

[1] https://kernel-recipes.org/en/2015/hardened-kernels-for-everyone/
[2] 
http://perso.corsac.net/~corsac/debian/kernel-grsec/PEREZ_Yves-Alexis_hardened-kernels.pdf
-- 
Yves-Alexis Perez


signature.asc
Description: PGP signature

Bug#605090: update?

[Yves-Alexis Perez]

On mar., 2015-09-15 at 00:12 +0100, Ben Hutchings wrote:
> There were several discussions with various people involved; the result
> as I understand it was that a linux-grsecurity package is likely to be
> acceptable in unstable (only) and Jacob would be ready to work on such a
> package in Debian.  I offered to help him with initial packaging, but
> not to be a maintainer.

I quickly discussed about that with Jacob on IRC following your ping,
and yes, my current plan is to start from the current src:linux git
repository (trying to avoid too much duplicate work), remove uneeded
stuff for us and add the grsecurity patch on top.

That way we might be able to sync / cherry-pick stuff from src:linux
every once in a while. If that's unmaintainable then we'll just
completely fork.

I didn't yet start the actual work, but I intend to do that in the
following days/weeks depending on my work schedule.

Regads,
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#605090: update?

[Erinn Clark]

* Yves-Alexis Perez  [2015:09:15 08:12 +0200]: 
> I quickly discussed about that with Jacob on IRC following your ping,
> and yes, my current plan is to start from the current src:linux git
> repository (trying to avoid too much duplicate work), remove uneeded
> stuff for us and add the grsecurity patch on top.
> 
> That way we might be able to sync / cherry-pick stuff from src:linux
> every once in a while. If that's unmaintainable then we'll just
> completely fork.
> 
> I didn't yet start the actual work, but I intend to do that in the
> following days/weeks depending on my work schedule.

Awesome! Please update the ticket with a git repo where the development is
happening once you begin, I'd love to be able to follow along and contribute if
possible. I'm currently building my own grsec kernel packages as it is and
would be happy to at least test.


signature.asc
Description: Digital signature

Bug#605090: update?

[Ben Hutchings]

On Mon, 2015-09-14 at 17:23 -0400, micah wrote:
> Erinn Clark  writes:
> 
> > I'm just wondering if there are any updates to this bug and in particular 
> > I'm
> > curious what could happen now that the grsecurity stable patches are only
> > available to sponsors. I still think getting grsec into Debian is a very
> > important and worthwhile goal, but we should begin discussing it again 
> > since I
> > believe there is more momentum. (I'd like to participate if possible, as 
> > well.)
> 
> There was some discussion at the most recent Debconf about doing
> this. I wasn't there, but my understanding is that there were some
> discussions about how to move this forwards... Maybe Jake can fill us in
> with the details?

There were several discussions with various people involved; the result
as I understand it was that a linux-grsecurity package is likely to be
acceptable in unstable (only) and Jacob would be ready to work on such a
package in Debian.  I offered to help him with initial packaging, but
not to be a maintainer.

The recent change in distribution of grsecurity patches for stable
kernel branches should not affect this.

Ben.

Bug#605090: update?

[micah]

Erinn Clark  writes:

> I'm just wondering if there are any updates to this bug and in particular I'm
> curious what could happen now that the grsecurity stable patches are only
> available to sponsors. I still think getting grsec into Debian is a very
> important and worthwhile goal, but we should begin discussing it again since I
> believe there is more momentum. (I'd like to participate if possible, as 
> well.)

There was some discussion at the most recent Debconf about doing
this. I wasn't there, but my understanding is that there were some
discussions about how to move this forwards... Maybe Jake can fill us in
with the details?

Bug#605090: update?

[Erinn Clark]

Hi,

I'm just wondering if there are any updates to this bug and in particular I'm
curious what could happen now that the grsecurity stable patches are only
available to sponsors. I still think getting grsec into Debian is a very
important and worthwhile goal, but we should begin discussing it again since I
believe there is more momentum. (I'd like to participate if possible, as well.)

Erinn


signature.asc
Description: Digital signature

Bug#605090: update?

[Yves-Alexis Perez]

On lun., 2015-09-14 at 14:15 -0400, Erinn Clark wrote:
> Hi,
> 
> I'm just wondering if there are any updates to this bug and in particular I'm
> curious what could happen now that the grsecurity stable patches are only
> available to sponsors. I still think getting grsec into Debian is a very
> important and worthwhile goal, but we should begin discussing it again since I
> believe there is more momentum. (I'd like to participate if possible, as 
> well.)
> 
Hey Erinn,

I somehow stopped updating this bugs, but my latest attempts are more
or less documented on my blog [1]. I'm also giving a talk about all
this in Kernel Recipes 2015 [2].

Right now the “easy” solution (make deb-pkg) is the best I can provide,
and it's definitely not suitable for inclusion in Debian. But I'm
planning to restart attempts to have something worth including in
Debian.

Regards,

[1]: http://www.corsac.net/?cat=3
[2]: https://kernel-recipes.org/en/2015/hardened-kernels-for-everyone/
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#605090: Proposing amd64-hardened architecture for Debian

[Ben Hutchings]

On Tue, 2014-04-22 at 22:41 +0200, Yves-Alexis Perez wrote:
[...]
 NOTE: I don't want to dismiss Mempo attempts, especially the
 reproducible build part, and I also think it's valuable to provide our
 users a grsec kernel as part of the distribution, just that I prefered
 to go the featureset way.

I do want to see the Mempo reproducible build work go upstream and/or
into src:linux, as appropriate.  Unfortunately it's currently siloed
just like grsec itself.

 I had the impression that adding a new copy of the linux sources was not
 really something appreciated by the project, and re-using linux-source
 (binary) package means the patch porting needs to be done anyway.

That was what I thought, too.  Specifically, the security team is
generally opposed to such duplication.

 But if I'm wrong or if things have changed since them, and there's
 indeed a consensus for the vanilla + grsecurity + make deb-pkg as an
 easy way to provide grsec kernels in the Debian archive, then I'm all
 for it.

Well 'make deb-pkg' doesn't work with a source package so you can't use
it as a basis for official Debian packages.

The options I see are:
- Provide a source package based on src:linux that includes only the
grsec featureset on top of an appropriate base version
- Provide a source package that builds only a 'source' binary package
(like linux-source-3.13)

In any case, it needs long-term upstream support, which for jessie would
presumably mean using 3.13 as a base, whereas src:linux will be a later
version.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


signature.asc
Description: This is a digitally signed message part

Bug#605090: Proposing amd64-hardened architecture for Debian

[Yves-Alexis Perez]

On Wed, Apr 23, 2014 at 12:45:10PM +0100, Ben Hutchings wrote:
 On Tue, 2014-04-22 at 22:41 +0200, Yves-Alexis Perez wrote:
 [...]
  NOTE: I don't want to dismiss Mempo attempts, especially the
  reproducible build part, and I also think it's valuable to provide our
  users a grsec kernel as part of the distribution, just that I prefered
  to go the featureset way.
 
 I do want to see the Mempo reproducible build work go upstream and/or
 into src:linux, as appropriate.  Unfortunately it's currently siloed
 just like grsec itself.

Well, I guess the non-grsec related stuff can go upstream/src:linux, but
as I'm not involved in the project, I can't really say.
 
  I had the impression that adding a new copy of the linux sources was not
  really something appreciated by the project, and re-using linux-source
  (binary) package means the patch porting needs to be done anyway.
 
 That was what I thought, too.  Specifically, the security team is
 generally opposed to such duplication.

Well, speaking with my security team hat, I can't say I really like it,
but that's not really like having multiple copies of a library either.

Sharing an orig.tar.xz between multiple source packages would be nice
here (although it wouldn't help in case we have different versions).

In any case, that's something I'd accept, but I don't think I can have
the final word on this :)

  But if I'm wrong or if things have changed since them, and there's
  indeed a consensus for the vanilla + grsecurity + make deb-pkg as an
  easy way to provide grsec kernels in the Debian archive, then I'm all
  for it.
 
 Well 'make deb-pkg' doesn't work with a source package so you can't use
 it as a basis for official Debian packages.

Yeah, sorry my words were a bit confusing. I really mean “using a
vanilla linux.tar.xz, adding the grsecurity patch and the Debian .config
and building a Debian package with that”.
 
 The options I see are:
 - Provide a source package based on src:linux that includes only the
 grsec featureset 

Which is more or less what I do with my current patchset (except that I
keep the src:linux name, but that could be changed pretty easily I
think).

 on top of an appropriate base version

I'm not sure I understand what you mean here. You mean staying at
3.2/3.13 for example?

 - Provide a source package that builds only a 'source' binary package
 (like linux-source-3.13)

I'm not sure what's the point here? Is it about having a source package
providing a binary package containing the unpatched vanilla linux sources,
which a src:linux-grsec package could build-depend on, then I guess we
can just have vanilla linux as orig.tar.xz instead of having to
build-dep on a linux-source-vanilla-3.13.
 
 In any case, it needs long-term upstream support, which for jessie would
 presumably mean using 3.13 as a base, whereas src:linux will be a later
 version.

I guess so.

Regards,
-- 
Yves-Alexis Perez


signature.asc
Description: Digital signature

Bug#605090: Proposing amd64-hardened architecture for Debian

[Ben Hutchings]

On Wed, 2014-04-23 at 17:34 +0200, Yves-Alexis Perez wrote:
 On Wed, Apr 23, 2014 at 12:45:10PM +0100, Ben Hutchings wrote:
  On Tue, 2014-04-22 at 22:41 +0200, Yves-Alexis Perez wrote:
[...]
  The options I see are:
  - Provide a source package based on src:linux that includes only the
  grsec featureset 
 
 Which is more or less what I do with my current patchset (except that I
 keep the src:linux name, but that could be changed pretty easily I
 think).
 
  on top of an appropriate base version
 
 I'm not sure I understand what you mean here. You mean staying at
 3.2/3.13 for example?

Yes.

  - Provide a source package that builds only a 'source' binary package
  (like linux-source-3.13)
 
 I'm not sure what's the point here? Is it about having a source package
 providing a binary package containing the unpatched vanilla linux sources,
 which a src:linux-grsec package could build-depend on, then I guess we
 can just have vanilla linux as orig.tar.xz instead of having to
 build-dep on a linux-source-vanilla-3.13.
[...]

No, I meant that you might build a single binary package that would
contain the grsec-patched source.  That would encourage building custom
kernels with build-time randomisation.  I understand that's not the way
you want to go.

Presumably your current package builds a linux-source-3.13 which
includes an upstream source tarball plus a grsec patch?

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein



signature.asc
Description: This is a digitally signed message part

Bug#605090: Proposing amd64-hardened architecture for Debian

[Yves-Alexis Perez]

On Wed, Apr 23, 2014 at 05:02:03PM +0100, Ben Hutchings wrote:
 No, I meant that you might build a single binary package that would
 contain the grsec-patched source.  That would encourage building custom
 kernels with build-time randomisation.  I understand that's not the way
 you want to go.

Indeed. There's already a (quite outdated) linux-patch-grsecurity2
package which contains the patch for people wanting to patch the kernel
themselves. But that's not really useful imho.
 
 Presumably your current package builds a linux-source-3.13 which
 includes an upstream source tarball plus a grsec patch?

In my case, it's actually the src:linux orig.tar.xz with the (adapted)
grsec patch added to debian/patches (like other featuresets).

Regards,
-- 
Yves-Alexis Perez


signature.asc
Description: Digital signature

Bug#605090: Proposing amd64-hardened architecture for Debian

[Ben Hutchings]

On Mon, 2014-04-21 at 05:28 +0200, Carlos Alberto Lopez Perez wrote:
 On 17/04/14 00:23, Aaron Zauner wrote:
  Now shipping grsec is a really good idea. I'd like to see that as well.
 
 There has been an attempt to provide an official grsec-flavour of the
 Debian kernel, but it didn't worked:
 
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090
 
 For those interested, Corsac provides packages:
 
 https://wiki.debian.org/grsecurity

There was a recent discussion on -private where I think there was some
consensus that a grsecurity kernel package could be included in Debian
as a separate source package.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


signature.asc
Description: This is a digitally signed message part

Bug#605090: Proposing amd64-hardened architecture for Debian

[Yves-Alexis Perez]

On Tue, Apr 22, 2014 at 08:30:01PM +0100, Ben Hutchings wrote:
 On Mon, 2014-04-21 at 05:28 +0200, Carlos Alberto Lopez Perez wrote:
  On 17/04/14 00:23, Aaron Zauner wrote:
   Now shipping grsec is a really good idea. I'd like to see that as well.
  
  There has been an attempt to provide an official grsec-flavour of the
  Debian kernel, but it didn't worked:
  
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090
  
  For those interested, Corsac provides packages:
  
  https://wiki.debian.org/grsecurity
 
 There was a recent discussion on -private where I think there was some
 consensus that a grsecurity kernel package could be included in Debian
 as a separate source package.

I'm a bit unsure about that consensus. Right now there are two attempts
to provide a grsecurity package for Debian:

- mine, which is about adding a grsec featureset to the src:linux
  package (so basically adding grsec patch on top of the Debian patches,
  and re-using everything else). This attempt was already NACK-ed by the
  kernel team;
- the Mempo/SameKernel attempt, which is about using a vanilla kernel
  and adding grsecurity on top of it (and, I guess, a .config which
  looks like the src:linux one)

The latter is much easier in term of management since all the
integration is done by spender (he's actually working on providing
.deb builds of grsec packages), so I didn't really consider it worthy to
investigate time on it since basically everyone can do it with a simple
script.

NOTE: I don't want to dismiss Mempo attempts, especially the
reproducible build part, and I also think it's valuable to provide our
users a grsec kernel as part of the distribution, just that I prefered
to go the featureset way.

I had the impression that adding a new copy of the linux sources was not
really something appreciated by the project, and re-using linux-source
(binary) package means the patch porting needs to be done anyway.

But if I'm wrong or if things have changed since them, and there's
indeed a consensus for the vanilla + grsecurity + make deb-pkg as an
easy way to provide grsec kernels in the Debian archive, then I'm all
for it.

Regards,
-- 
Yves-Alexis Perez


signature.asc
Description: Digital signature

Bug#605090: (no subject)

[Tomasz Wartalski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I hope there will be some progress on this issue. There are advantages
in providing a grsec-patched kernel inside debian.

E.g: with a grsec patched vanilla kernel my radeon GPU tends to lock up
every couple of days and my computer doesn’t reliably recover from
standby. This ain’t happen with a stock debian kernel or a kernel build
out of the debian sources.

I’ve tried Yves-Alexis´s grsec-patched debian kernel and sources,
mentioned in this bugreport and they work like a charm. No more GPU
lock-ups and the standby issues are gone. I’m pretty sure there will be
other machine configurations out there, where folks just cannot run the
grsec-patched vanilla kernel using debian.

Please continue your work on this Yves-Alexis.

Cheers,

Tomasz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk/6fIMACgkQiypP+gYHZb9sOwCcDSfigVr5vnl/XhFDOoYaS+Be
EEQAoKKt89FtfJbXHzxFBKWCOiC+/DaH
=V+Zg
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#605090: (no subject)

[Kees de Jong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Is there a status update on this work? Will Wheezy get a grsec feature
set kernel? Thanks for all the work so far!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPvlEPAAoJENRhrNqNnJdg5i4H/3kGJ8fquM9SCJksiWBikrbi
BxzjEaZHJbbFkogZ0V443lOF3DqCV7bgFCroyGY0emxV8ZCqe6SD8jUsorBcXKLA
+pKHcF1pWB4CVAZQj4Dc0P4goDkYbXV39dR9XSzA4ynaTIErKLRfECpOKami6zPs
1eUvOPk91hZ0thVJw909A6/ec1PxP1Y5NNhDVLdNGN4ptWkTwDGi7ATqNblhwURE
bTbM/Z0RWbcW9kDuAcoI2k8KfpLHDCEomwtKMYGIDULwcUM78pvyjbNCQ9RuIj3r
6e1uoQPqNpYOdIIma+a1r4PGSh2Dbw7X+OG9kfOK0KW+FWBjmaAxCA5NDCzWeX0=
=FXI2
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#605090: Linux 3.2 in wheezy

[Goswin von Brederlow]

Yves-Alexis Perez cor...@debian.org writes:

 On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
 On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
  On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
   What is stopping you from creating another package, that provides the
   kernel with grsecurity patches applied? Don't bother the kernel team
   with it, and just maintain it yourself in the archive? Its free software
   afterall. 
   
  
  Honestly, having multiple linux source package in the archive doesn't
  really sound like a good idea. I don't really think the kernel team
  would appreciate, I'm pretty sure ftpmasters would disagree, and as a
  member of the security team, It's definitely something I would object.
 
 Well, that's what we have the 'linux-source' packages for: to allow
 other packages to build-depend on them.
 

 Hmhm, that might be a good idea indeed. I need to investigate and try
 that a bit.

 Ben, what would kernel team think of that?

 Regards,
 -- 
 Yves-Alexis

Don't forget to set Build-With: in the resulting binary package. That
ensure DAK will keep the right linux-source package around as long as
your package is in the repository. Otherwise you will have GPL
violations.

MfG
Goswin



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#605090: Grsec to follow 3.2 stable release

[Yves-Alexis Perez]

This might be relevant for interested people:


 Linux 3.2 chosen as new stable kernel, 2.6.32 support continues (Feb 04
 2012) 
 The PaX Team and I have decided on Linux 3.2 as the new stable
 kernel, joining with the choice made by Debian and Ubuntu. We will
 continue to support 2.6.32 until the end of this year, at least.

(http://grsecurity.net/news.php#newstable)

Regards,
-- 
Yves-Alexis




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#605090: Linux 3.2 in wheezy

[Christoph Anton Mitterer]

On Thu, 2012-02-02 at 12:18 +1100, Russell Coker wrote:
 The current approach of having a kernel patch package seems to work well.
Phew... well there are many people running at stable... and for
them it does not... as the package seems more or less orphaned.

Also,.. configuring something complex like grsec is probably nothing for
the end-user who, however, should have also an easy way to benefit from
it.


 It 
 removes the need for involvement of the kernel and security teams (presumably 
 security changes to the kernel will usually not require changes to the 
 grsecurity patch) and allows the users to easily build their own kernels.
Well, even though it means [much] work for them,... wouldn't that
involvement be just the good thing? Having some real experts, looking
after everything?!


 Spender suggested that people who want GRSecurity on Debian would be better 
 off using a .deb he provides and working on user-space hardening.
Well IMHO, at best, one should never need to rund anything from outside
the Debian archives ;)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#605090: Linux 3.2 in wheezy

[Ben Hutchings]

On Fri, Feb 03, 2012 at 12:55:59AM +0100, Christoph Anton Mitterer wrote:
 On Thu, 2012-02-02 at 12:18 +1100, Russell Coker wrote:
  The current approach of having a kernel patch package seems to work well.
 Phew... well there are many people running at stable... and for
 them it does not... as the package seems more or less orphaned.
 
 Also,.. configuring something complex like grsec is probably nothing for
 the end-user who, however, should have also an easy way to benefit from
 it.

There is an easy way to benefit from it.  Download and build an
official release.  I assume 'make deb-pkg' works like in mainline
Linux.

  It 
  removes the need for involvement of the kernel and security teams 
  (presumably 
  security changes to the kernel will usually not require changes to the 
  grsecurity patch) and allows the users to easily build their own kernels.
 Well, even though it means [much] work for them,... wouldn't that
 involvement be just the good thing? Having some real experts, looking
 after everything?!

You flatter us.  General experience with kernel development does not
make someone an expert that is capable of understanding all the
implications of rebasing a patch or patch set that modifies many core
kernel features.

  Spender suggested that people who want GRSecurity on Debian would be better 
  off using a .deb he provides and working on user-space hardening.
 Well IMHO, at best, one should never need to rund anything from outside
 the Debian archives ;)

Wishing it so doesn't make it practically possible.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#605090: Linux 3.2 in wheezy

[Christoph Anton Mitterer]

On Fri, 2012-02-03 at 00:34 +, Ben Hutchings wrote:
 There is an easy way to benefit from it.
Well still the user wouldn't know how to configure it...
Actually I must admit that I haven't followed PaX/grsec now for some
time (mainly due to the deb package being always out of date in sid).

Wasn't it once the case with PaX that packages have to be compiled
specially? Or some ELF headers added or so?
And there were no execute features which are perhaps superseded to some
extent (now that AMD64 has NX bit)...
So what I mean in the end,... I'm surely not an expert with respect to
the kernel, but at least I used to have my own .config since years,..
still it would mean quite some effort for me to get PaX/grsec running in
a way that I for myself believe I've done it right.
And this does not include tracing problems (I _very_ vaguely remember
that one had to make exceptions e.g. for Java?)

And that's why I think that such special frameworks like PaX/grsec,
SElinux, Apparmor, Smack, etc. pp. make only sense if well supported by
the distro, at least for some (blind guess:) 80-90% of all potential
users.



 You flatter us.  General experience with kernel development does not
 make someone an expert that is capable of understanding all the
 implications of rebasing a patch or patch set that modifies many core
 kernel features.
Well come on Ben,.. you've already helped me so often with issues with
the kernel,... you guys have at least some very good overview on
everything!


  Well IMHO, at best, one should never need to rund anything from outside
  the Debian archives ;)
 Wishing it so doesn't make it practically possible.
Well.. so far I do :D


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#605090: Linux 3.2 in wheezy

[Russell Coker]

On Fri, 3 Feb 2012, Christoph Anton Mitterer cales...@scientia.net wrote:
 Wasn't it once the case with PaX that packages have to be compiled
 specially? Or some ELF headers added or so?

Some shared libraries have code which can't be run without an executable 
stack, it's a small number of libraries that are written in assembler code.  
We want to allow running them but don't want to give all programs permission 
to execute code on the stack.

From memory the GR Security option for this was to flag the rare executables 
that want an executable stack and are permitted to have it.

The solution devised by libc/gcc upstream was to have a special assembly 
section in every shared object that doesn't require an executable stack and if 
an executable only loads shared objects that don't require it then the 
executable stack is disabled.  Then we have SE Linux policy to prevent most 
programs from having an executable stack which means that if they are tricked 
into loading some of the rare libraries that need it then it doesn't do 
anything bad.

The downside to the latter approach is that lots of shared objects which have 
some assembler code needed to be patched.

The PaX approach involved less work.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#605090: Linux 3.2 in wheezy

[Yves-Alexis Perez]

On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
 On Mon, 30 Jan 2012 22:26:50 +0100, Yves-Alexis Perez cor...@debian.org 
 wrote:
  So I think it's perfectly clear that nor Debian nor Grsecurity are
  really interested in Debian shipping a Grsecurity kernel.
 
 Well, I don't think its fair to say Debian is not interested in
 shipping a Grsecurity kernel. I think its more accurate to say that the
 current configuration of the Debian kernel team doesn't find the time to
 deal with it... but I'm not sure that speaks for all of Debian.

Well, in this case, that's mostly the same. I'm sure there are people in
Debian which are interested (even outside of me). But here, the kernel
team has the final word (well, or the tech ctte, but I really don't see
the point of that).
 
[…]

 
  Anyway, I'll keep updating the current setup for interested people, but
  without any interest from either party, that definitely looks like a
  dead end.
 
 What is stopping you from creating another package, that provides the
 kernel with grsecurity patches applied? Don't bother the kernel team
 with it, and just maintain it yourself in the archive? Its free software
 afterall. 
 

Honestly, having multiple linux source package in the archive doesn't
really sound like a good idea. I don't really think the kernel team
would appreciate, I'm pretty sure ftpmasters would disagree, and as a
member of the security team, It's definitely something I would object.

Regards,
-- 
Yves-Alexis


signature.asc
Description: This is a digitally signed message part

Bug#605090: Linux 3.2 in wheezy

[Yves-Alexis Perez]

On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
 On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
  On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
   What is stopping you from creating another package, that provides the
   kernel with grsecurity patches applied? Don't bother the kernel team
   with it, and just maintain it yourself in the archive? Its free software
   afterall. 
   
  
  Honestly, having multiple linux source package in the archive doesn't
  really sound like a good idea. I don't really think the kernel team
  would appreciate, I'm pretty sure ftpmasters would disagree, and as a
  member of the security team, It's definitely something I would object.
 
 Well, that's what we have the 'linux-source' packages for: to allow
 other packages to build-depend on them.
 

Hmhm, that might be a good idea indeed. I need to investigate and try
that a bit.

Ben, what would kernel team think of that?

Regards,
-- 
Yves-Alexis


signature.asc
Description: This is a digitally signed message part

Bug#605090: Linux 3.2 in wheezy

[Wouter Verhelst]

On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
 On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
  What is stopping you from creating another package, that provides the
  kernel with grsecurity patches applied? Don't bother the kernel team
  with it, and just maintain it yourself in the archive? Its free software
  afterall. 
  
 
 Honestly, having multiple linux source package in the archive doesn't
 really sound like a good idea. I don't really think the kernel team
 would appreciate, I'm pretty sure ftpmasters would disagree, and as a
 member of the security team, It's definitely something I would object.

Well, that's what we have the 'linux-source' packages for: to allow
other packages to build-depend on them.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#605090: Linux 3.2 in wheezy

[Ben Hutchings]

On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote:
 On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
  On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
   On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
What is stopping you from creating another package, that provides the
kernel with grsecurity patches applied? Don't bother the kernel team
with it, and just maintain it yourself in the archive? Its free software
afterall. 

   
   Honestly, having multiple linux source package in the archive doesn't
   really sound like a good idea. I don't really think the kernel team
   would appreciate, I'm pretty sure ftpmasters would disagree, and as a
   member of the security team, It's definitely something I would object.
  
  Well, that's what we have the 'linux-source' packages for: to allow
  other packages to build-depend on them.
  
 
 Hmhm, that might be a good idea indeed. I need to investigate and try
 that a bit.
 
 Ben, what would kernel team think of that?

I don't speak for the whole team, but I don't see that it solves any
problem.  You would have to Build-Depend on exact versions of
linux-source, so that you know your external patches will apply.  Then
you would have to rebase the patches every time linux-2.6 is updated,
making sure (without much help from upstream) that you don't introduce a
subtle security problem.

Ben.

-- 
Ben Hutchings
Lowery's Law:
 If it jams, force it. If it breaks, it needed replacing anyway.


signature.asc
Description: This is a digitally signed message part

Bug#605090: Linux 3.2 in wheezy

[Yves-Alexis Perez]

On mer., 2012-02-01 at 14:32 +, Ben Hutchings wrote:
 On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote:
  On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
   On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
 What is stopping you from creating another package, that provides the
 kernel with grsecurity patches applied? Don't bother the kernel team
 with it, and just maintain it yourself in the archive? Its free 
 software
 afterall. 
 

Honestly, having multiple linux source package in the archive doesn't
really sound like a good idea. I don't really think the kernel team
would appreciate, I'm pretty sure ftpmasters would disagree, and as a
member of the security team, It's definitely something I would object.
   
   Well, that's what we have the 'linux-source' packages for: to allow
   other packages to build-depend on them.
   
  
  Hmhm, that might be a good idea indeed. I need to investigate and try
  that a bit.
  
  Ben, what would kernel team think of that?
 
 I don't speak for the whole team, but I don't see that it solves any
 problem.  You would have to Build-Depend on exact versions of
 linux-source, so that you know your external patches will apply.  Then
 you would have to rebase the patches every time linux-2.6 is updated,
 making sure (without much help from upstream) that you don't introduce a
 subtle security problem.
 
Well, that's already what I do and intended to do (and that's clear from
the beginning of the bug report).

Wrt not introducing subtle security problems, what I mostly do is remove
the security backports from the grsec patch which are already applied to
Debian kernel, so this part is fairly straightforward.

Now indeed when doing the job for Squeeze kernel it's a bit less
straightforward because of the huge amount of driver backports, but from
my own experience, the conflicts are still mostly about changed context
lines.

Regards,
-- 
Yves-Alexis


signature.asc
Description: This is a digitally signed message part

Bug#605090: Linux 3.2 in wheezy

[Ben Hutchings]

On Wed, Feb 01, 2012 at 06:41:43PM +0100, Yves-Alexis Perez wrote:
 On mer., 2012-02-01 at 14:32 +, Ben Hutchings wrote:
  On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote:
   On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
 On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
  What is stopping you from creating another package, that provides 
  the
  kernel with grsecurity patches applied? Don't bother the kernel team
  with it, and just maintain it yourself in the archive? Its free 
  software
  afterall. 
  
 
 Honestly, having multiple linux source package in the archive doesn't
 really sound like a good idea. I don't really think the kernel team
 would appreciate, I'm pretty sure ftpmasters would disagree, and as a
 member of the security team, It's definitely something I would object.

Well, that's what we have the 'linux-source' packages for: to allow
other packages to build-depend on them.

   
   Hmhm, that might be a good idea indeed. I need to investigate and try
   that a bit.
   
   Ben, what would kernel team think of that?
  
  I don't speak for the whole team, but I don't see that it solves any
  problem.  You would have to Build-Depend on exact versions of
  linux-source, so that you know your external patches will apply.  Then
  you would have to rebase the patches every time linux-2.6 is updated,
  making sure (without much help from upstream) that you don't introduce a
  subtle security problem.
  
 Well, that's already what I do and intended to do (and that's clear from
 the beginning of the bug report).
 
 Wrt not introducing subtle security problems, what I mostly do is remove
 the security backports from the grsec patch which are already applied to
 Debian kernel, so this part is fairly straightforward.
 
 Now indeed when doing the job for Squeeze kernel it's a bit less
 straightforward because of the huge amount of driver backports, but from
 my own experience, the conflicts are still mostly about changed context
 lines.

But your upstream disagrees on that point.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#605090: Linux 3.2 in wheezy

[dann frazier]

On Wed, Feb 01, 2012 at 02:32:19PM +, Ben Hutchings wrote:
 On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote:
  On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
   On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
 What is stopping you from creating another package, that provides the
 kernel with grsecurity patches applied? Don't bother the kernel team
 with it, and just maintain it yourself in the archive? Its free 
 software
 afterall. 
 

Honestly, having multiple linux source package in the archive doesn't
really sound like a good idea. I don't really think the kernel team
would appreciate, I'm pretty sure ftpmasters would disagree, and as a
member of the security team, It's definitely something I would object.
   
   Well, that's what we have the 'linux-source' packages for: to allow
   other packages to build-depend on them.
   
  
  Hmhm, that might be a good idea indeed. I need to investigate and try
  that a bit.
  
  Ben, what would kernel team think of that?
 
 I don't speak for the whole team,

and nor do I..

 but I don't see that it solves any
 problem.  You would have to Build-Depend on exact versions of
 linux-source, so that you know your external patches will apply.  Then
 you would have to rebase the patches every time linux-2.6 is updated,
 making sure (without much help from upstream) that you don't introduce a
 subtle security problem.

Whilte it may help the kernel team to not have to worry about problems
in the grsec flavor when preparing uploads, preventing delays for the
non-grsec images. But, that just pushes the coordination down a ways -
for stable updates we would need to add the grsec build into the
pipeline, and there'd be delays in grsec security updates that go in
via linux-2.6. Not nak'ing the idea, but it does extend some critical
paths.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#605090: Linux 3.2 in wheezy

[Russell Coker]

On Thu, 2 Feb 2012, dann frazier da...@dannf.org wrote:
 Whilte it may help the kernel team to not have to worry about problems
 in the grsec flavor when preparing uploads, preventing delays for the
 non-grsec images. But, that just pushes the coordination down a ways -
 for stable updates we would need to add the grsec build into the
 pipeline, and there'd be delays in grsec security updates that go in
 via linux-2.6. Not nak'ing the idea, but it does extend some critical
 paths.

The current approach of having a kernel patch package seems to work well.  It 
removes the need for involvement of the kernel and security teams (presumably 
security changes to the kernel will usually not require changes to the 
grsecurity patch) and allows the users to easily build their own kernels.

If a user has a choice between using Spender's Debian package and a kernel-
patch package to build their own kernel then I think that they should be able 
to do whatever they want.

Spender suggested that people who want GRSecurity on Debian would be better 
off using a .deb he provides and working on user-space hardening.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#605090: Linux 3.2 in wheezy

[Kees de Jong]

Perhaps you should contact Julien Tinnes of http://kernelsec.cr0.org/ 
He has been too busy to work on the kernels lately but maybe he wants to
help.





On do, 2012-02-02 at 12:18 +1100, Russell Coker wrote:

 On Thu, 2 Feb 2012, dann frazier da...@dannf.org wrote:
  Whilte it may help the kernel team to not have to worry about problems
  in the grsec flavor when preparing uploads, preventing delays for the
  non-grsec images. But, that just pushes the coordination down a ways -
  for stable updates we would need to add the grsec build into the
  pipeline, and there'd be delays in grsec security updates that go in
  via linux-2.6. Not nak'ing the idea, but it does extend some critical
  paths.
 
 The current approach of having a kernel patch package seems to work well.  It 
 removes the need for involvement of the kernel and security teams (presumably 
 security changes to the kernel will usually not require changes to the 
 grsecurity patch) and allows the users to easily build their own kernels.
 
 If a user has a choice between using Spender's Debian package and a kernel-
 patch package to build their own kernel then I think that they should be able 
 to do whatever they want.
 
 Spender suggested that people who want GRSecurity on Debian would be better 
 off using a .deb he provides and working on user-space hardening.
 
 -- 
 My Main Blog http://etbe.coker.com.au/
 My Documents Bloghttp://doc.coker.com.au/
 
 


-- 
Met vriendelijke groet,
Kees de Jong



De informatie opgenomen in dit bericht kan vertrouwelijk
zijn en is uitsluitend bestemd voor de
geadresseerde(n). 
Indien u dit bericht onterecht ontvangt, wordt u
verzocht de inhoud niet te gebruiken en de afzender
direct te informeren door het bericht te retourneren.
--
The information contained in this message may be
confidential and is intended to be exclusively for the
addressee(s). 
Should you receive this message unintentionally, please
do not use the contents herein and notify the sender
immediately by return e-mail. 











signature.asc
Description: This is a digitally signed message part

Bug#605090: Linux 3.2 in wheezy

[Yves-Alexis Perez]

 On do, 2012-02-02 at 12:18 +1100, Russell Coker wrote: 
  On Thu, 2 Feb 2012, dann frazier da...@dannf.org wrote:
   Whilte it may help the kernel team to not have to worry about problems
   in the grsec flavor when preparing uploads, preventing delays for the
   non-grsec images. But, that just pushes the coordination down a ways -
   for stable updates we would need to add the grsec build into the
   pipeline, and there'd be delays in grsec security updates that go in
   via linux-2.6. Not nak'ing the idea, but it does extend some critical
   paths.
  
  The current approach of having a kernel patch package seems to work well.  
  It 
  removes the need for involvement of the kernel and security teams 
  (presumably 
  security changes to the kernel will usually not require changes to the 
  grsecurity patch) and allows the users to easily build their own kernels.
  
  If a user has a choice between using Spender's Debian package and a kernel-
  patch package to build their own kernel then I think that they should be 
  able 
  to do whatever they want.
  
  Spender suggested that people who want GRSecurity on Debian would be better 
  off using a .deb he provides and working on user-space hardening.
  

(please don't top-post)
If people on the CC: list want to be dropped, please ask :)

On jeu., 2012-02-02 at 07:18 +0100, Kees de Jong wrote:
 Perhaps you should contact Julien Tinnes of http://kernelsec.cr0.org/ 
 He has been too busy to work on the kernels lately but maybe he wants
to help.
 
 

Well Julien was aware of my initiative and, afaict, he didn't really
have time for that, nor was interested in the porting part.

And as I said before, I'm not interested in shipping just a patch in
Debian. If users want to patch the kernel, configure it and built it, I
think they're better off getting the latest patch from grsecurity.net
and kernel from kernel.org. The point was in shipping a binary package
with a default setup secure enough, and a way to tune the features
through sysctl.

Regards,
-- 
Yves-Alexis


signature.asc
Description: This is a digitally signed message part

Bug#605090: Linux 3.2 in wheezy

[micah anderson]

On Mon, 30 Jan 2012 22:26:50 +0100, Yves-Alexis Perez cor...@debian.org wrote:
 On lun., 2012-01-30 at 14:08 +, Ben Hutchings wrote:
  On Mon, 2012-01-30 at 11:05 +0100, Yves-Alexis Perez wrote:
   (adding few CC:s to keep track on the bug)
   
   On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote:
On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
 On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote:
[...]
   Now, I still think having a hardened Debian kernel inside the
   distribution is helpful
  [...]
  
  I agree and I would like to see hardening of *all* our configurations,
  where the performance cost is not too much.  That's going to protect all
  our users rather than just people who seek out a special paranoid
  configuration.

Would you agree that there are some small hardening things that can be
done that don't impact performance that much? In particular the
privilege boundries mentioned earlier does not seem to introduce any
particular performance cost worth worrying about.

 So I think it's perfectly clear that nor Debian nor Grsecurity are
 really interested in Debian shipping a Grsecurity kernel.

Well, I don't think its fair to say Debian is not interested in
shipping a Grsecurity kernel. I think its more accurate to say that the
current configuration of the Debian kernel team doesn't find the time to
deal with it... but I'm not sure that speaks for all of Debian.

 I find that sad, because I do think there are users of both which would
 benefit from that, and not only people who seek out a special paranoid
 configuration.

I agree. On some machines, I would gladly trade perfomance for a
hardened kernel where that is more important and it is unfortunate that
the attempt to appeal to all possible configurations at the same time
results in a kernel that doesn't allow for specialized configurations
that people want/need.

 Anyway, I'll keep updating the current setup for interested people, but
 without any interest from either party, that definitely looks like a
 dead end.

What is stopping you from creating another package, that provides the
kernel with grsecurity patches applied? Don't bother the kernel team
with it, and just maintain it yourself in the archive? Its free software
afterall. 

micah


pgpc7nzojHiMK.pgp
Description: PGP signature

Bug#605090: Linux 3.2 in wheezy

[Yves-Alexis Perez]

(adding few CC:s to keep track on the bug)

On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote:
 On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
  On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote:
   Featuresets
   ---
   
   The only featureset provided will be 'rt' (realtime), currently built
   for amd64 only.  If there is interest in realtime support for other
   architectures, we may be able to add that.  However, we do need to
   consider the total time taken to build binary packages for each
   architecture.
   
   If there are particular container features that should be enabled or
   backported to provide a useful replacement for OpenVZ or VServer,
   please let us know.  We cannot promise that these will all be enabled
   but we need to know what is missing. 
  
  So in the end what are the reasons for not trying the grsecurity
  featureset? #605090 lacks any reply from the kernel team since quite a
  while, and especially after answers were provided to question asked.
 
 You already know the main reason:
  Feature-wise, Brad Sprengler and the PaX team still add stuff, like the
  gcc plugins or hardening features like symbols hiding, fix bugs (for
  example in RBAC code), while few of them reach mainline.
 
 I realise that the mainline Linux developers have sometimes been
 unreasonably resistant to these changes and I'm not intending to assign
 blame for this.  But practically this means that we have to either carry
 the featureset indefinitely or disappoint users by removing it in a
 later release.  (See the complaints about removing OpenVZ in wheezy
 despite 4 years' advance notice of this.)

I understand this, and I still see the grsec featureset as a valuable
project. Indeed, reducing the diff wrt. upstream in Debian kernel is an
important goal (especially considering the time involvement).

Now, I still think having a hardened Debian kernel inside the
distribution is helpful and needed for some people (some of them have
said so on the bug report, some other directly told me). I can continue
providing kernels for stable and sid outside of Debian, but that means
it's painful to find them, so less people will use it. I'm sure I don't
have to remind people, but having a hardened kernel can buy you some
time when some vulnerabilities are found in the kernel, like
the /proc/pid/mem one (even when it does not prevent completely the
vulnerability, it can prevents the exploit to be successful, for
example).
 
 It also appears that you never had any response to your question to
 upstream about minimising the patch set.

Indeed. Brad, I'm not sure if you received the initial mail, so if you
have any comment…
 
  Not doing anything is indeed a way to just get rid of the question, but
  I would have at least appreciated a definitive answer on the bug rather
  than via the dda mail.
 
 I'm sorry about that; it completely slipped my mind as there have been
 no discussions about it for some months.

Well, the last mail from the kernel team on the bug was indeed months
ago (nov 10th afaict), but I kept adding info and replies since.

Anyway, thanks for your answer.

Regards,
-- 
Yves-Alexis


signature.asc
Description: This is a digitally signed message part

Bug#605090: Linux 3.2 in wheezy

[Brad Spengler]

 Indeed. Brad, I'm not sure if you received the initial mail, so if you
 have any comment???

It looks like there were quite a few messages I wasn't involved in ;)  

Regarding minimizing the patchset, we do that already where we see 
opportunities to do so.  We used to carry a large constifying patch 
which has now been replaced with a gcc plugin.  Likewise with the kernel 
stack clearing feature.

As far as gutting the patch for whatever features someone not involved 
in the project thinks are the only ones necessary (I saw a few posts 
in the thread asking for that) -- I don't think it's a good idea and 
I'm not interested at all in assisting that.

If we're going to be in the business of telling other people what to do 
with their free time, might I suggest that Debian improve its userland 
hardening so that it's not in last place?  As a Debian user myself, I
can assure you that no one cares about a miniscule performance hit from
PIE on i386 in su/passwd.  There's no reason not to have these privilege
boundaries hardened -- and very disappointing for us as 
MPROTECT/ASLR/GRKERNSEC_BRUTEFORCE would have provided an effective 
deterrent against exploitation of the /proc/pid/mem vuln were it not
for distros' userland hardening being asleep on the job.  That failure
will continue to bite users.

Frankly it makes more sense for me to offer .debs myself than to deal 
with a bureaucracy and non-standard kernel in Debian.  It contains 
who-knows-what extra code, and I doubt anyone looked at any of it to see if 
it allows for some way to leak information I prevent against a vanilla 
kernel, or a way to bypass any other existing protection.  There's more 
to security (a whole-system concept) than just the ripping of individual 
features.

-Brad


signature.asc
Description: Digital signature

Bug#605090: Linux 3.2 in wheezy

[Ben Hutchings]

On Mon, 2012-01-30 at 11:05 +0100, Yves-Alexis Perez wrote:
 (adding few CC:s to keep track on the bug)
 
 On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote:
  On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
   On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote:
Featuresets
---

The only featureset provided will be 'rt' (realtime), currently built
for amd64 only.  If there is interest in realtime support for other
architectures, we may be able to add that.  However, we do need to
consider the total time taken to build binary packages for each
architecture.

If there are particular container features that should be enabled or
backported to provide a useful replacement for OpenVZ or VServer,
please let us know.  We cannot promise that these will all be enabled
but we need to know what is missing. 
   
   So in the end what are the reasons for not trying the grsecurity
   featureset? #605090 lacks any reply from the kernel team since quite a
   while, and especially after answers were provided to question asked.
  
  You already know the main reason:
   Feature-wise, Brad Sprengler and the PaX team still add stuff, like the
   gcc plugins or hardening features like symbols hiding, fix bugs (for
   example in RBAC code), while few of them reach mainline.
  
  I realise that the mainline Linux developers have sometimes been
  unreasonably resistant to these changes and I'm not intending to assign
  blame for this.  But practically this means that we have to either carry
  the featureset indefinitely or disappoint users by removing it in a
  later release.  (See the complaints about removing OpenVZ in wheezy
  despite 4 years' advance notice of this.)
 
 I understand this, and I still see the grsec featureset as a valuable
 project. Indeed, reducing the diff wrt. upstream in Debian kernel is an
 important goal (especially considering the time involvement).
 
 Now, I still think having a hardened Debian kernel inside the
 distribution is helpful
[...]

I agree and I would like to see hardening of *all* our configurations,
where the performance cost is not too much.  That's going to protect all
our users rather than just people who seek out a special paranoid
configuration.

Ben.

-- 
Ben Hutchings
Lowery's Law:
 If it jams, force it. If it breaks, it needed replacing anyway.


signature.asc
Description: This is a digitally signed message part

Bug#605090: Linux 3.2 in wheezy

[Peter Samuelson]

[Brad Spengler]
 Frankly it makes more sense for me to offer .debs myself than to deal
 with a bureaucracy and non-standard kernel in Debian.  It contains
 who-knows-what extra code, and I doubt anyone looked at any of it to
 see if it allows for some way to leak information I prevent against a
 vanilla kernel, or a way to bypass any other existing protection.

I hope you aren't complaining that the Debian kernel team doesn't
include your patch, and also complaining that Debian kernel team
includes too many patches, in the same email.

Probably that isn't what you tried to say, but that's kinda what it
sounded like.

Peter



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#605090: Linux 3.2 in wheezy

[Yves-Alexis Perez]

On lun., 2012-01-30 at 14:08 +, Ben Hutchings wrote:
 On Mon, 2012-01-30 at 11:05 +0100, Yves-Alexis Perez wrote:
  (adding few CC:s to keep track on the bug)
  
  On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote:
   On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote:
 Featuresets
 ---
 
 The only featureset provided will be 'rt' (realtime), currently built
 for amd64 only.  If there is interest in realtime support for other
 architectures, we may be able to add that.  However, we do need to
 consider the total time taken to build binary packages for each
 architecture.
 
 If there are particular container features that should be enabled or
 backported to provide a useful replacement for OpenVZ or VServer,
 please let us know.  We cannot promise that these will all be enabled
 but we need to know what is missing. 

So in the end what are the reasons for not trying the grsecurity
featureset? #605090 lacks any reply from the kernel team since quite a
while, and especially after answers were provided to question asked.
   
   You already know the main reason:
Feature-wise, Brad Sprengler and the PaX team still add stuff, like the
gcc plugins or hardening features like symbols hiding, fix bugs (for
example in RBAC code), while few of them reach mainline.
   
   I realise that the mainline Linux developers have sometimes been
   unreasonably resistant to these changes and I'm not intending to assign
   blame for this.  But practically this means that we have to either carry
   the featureset indefinitely or disappoint users by removing it in a
   later release.  (See the complaints about removing OpenVZ in wheezy
   despite 4 years' advance notice of this.)
  
  I understand this, and I still see the grsec featureset as a valuable
  project. Indeed, reducing the diff wrt. upstream in Debian kernel is an
  important goal (especially considering the time involvement).
  
  Now, I still think having a hardened Debian kernel inside the
  distribution is helpful
 [...]
 
 I agree and I would like to see hardening of *all* our configurations,
 where the performance cost is not too much.  That's going to protect all
 our users rather than just people who seek out a special paranoid
 configuration.

So I think it's perfectly clear that nor Debian nor Grsecurity are
really interested in Debian shipping a Grsecurity kernel.

I find that sad, because I do think there are users of both which would
benefit from that, and not only people who seek out a special paranoid
configuration.

Anyway, I'll keep updating the current setup for interested people, but
without any interest from either party, that definitely looks like a
dead end.

Regards,
-- 
Yves-Alexis


signature.asc
Description: This is a digitally signed message part

Bug#605090: definitely, a worth while patchset

[Adam K]

Hey,

 This patch-set should replace linux-patch-grsecurity2.This patch-set provides 
excellent default settings and capability. For example, the user and group 
setup helps with creating consistent access user and group ids across servers. 
Most of the default kernel settings match with gentoo's hardened project kernel 
settings. Since this patch-set integrates with debian patch-sets, servers get 
benefits from both patch-sets. And, admins don't have to choose between 
patching the vanilla sources or resolving conflicts between the debian and 
grsec patch-sets.

I believe a statistic needs to be done on how much of the grsec feature set is 
used by grsec users. For example, I use RBAC instead of SELINUX and Tomoyo 
almost always. There's also things like extra chroot security features that 
should be taken into consideration. My hypothesis for this statistic is that 
most grsec users use RBAC as well. For those that don't, I understand that a 
split between larger and smaller feature sets, PAX vs RBAC, would be helpful. 
For this split to happen, with grsec's history, I think a large interest needs 
to be shown for them to split the patch-set. So, if this is accepted, maybe the 
level of interest needed to get a split patch will be generated.

Currently, I like this as a patch-set more than a binary because of security 
conflicts with things like xen. However, if I wasn't using xen, I would use the 
binary.

(Note: I accidently sent this message to 605090-subscr...@bugs.debian.org 
first.)

- 

Bug#605090: [RFC] Add a grsec featureset to Debian kernels

[Yves-Alexis Perez]

On mer., 2011-12-28 at 05:45 +0100, Carlos Alberto Lopez Perez wrote:
 Hello,
 
 
 What is the status of this? It has been a looong time ago since last update.

Sorry for the delay. As the BTS doesn't automatically CC the submitter,
please keep me on CC: when replying to this bug.

For sid, I keep updating the kernels from time to time, you can see the
grsec-patches (against the sid svn branch) at
http://anonscm.debian.org/gitweb/ and binary packages can be found at
http://molly.corsac.net/~corsac/debian/kernel-grsec/packages/sid/ (I
don't upload every built kernel there since it's a bit huge.

For squeeze, I'm a bit lagging but I should update both the relevant
branch in grsec-patches and the repository.

I don't give a status update each time I update the repositories in
order not to flood people, and I still hope some positive answer from
the kernel team (until it's obvious it's too late for Wheezy).
 
 
 I am also interested in having a Debian kernel with the grsec+pax
 featureset and I am sure that many sysadmins would appreciate this
 possibility. There is a huge user base of grsec from hosting companies.

Thanks for the support.
 
 
 I agree that this RBAC thing may be not interesting for everybody giving
 the fact that it duplicates some functionality (we already have SELinux
 and TOMOYO).
 
 
 So if you really feel so strong about removing this feature from the
 debian-grsec-kernel it can be easily done just by setting
 CONFIG_GRKERNSEC_NO_RBAC=y in the .config (there is no need to ask
 upstream to split the patch).

This was mostly about upstreaming things, in fact. But disabling an
option doesn't make the patch smaller.
 
 
 Anyway I think RBAC is a nice feature and it don't hurts: Its far easier
 to use than SElinux [1] and we already have in Debian the user-space
 tools to work with it:
 
   CC'ing Laszlo Boszormenyi
   (maintainer of linux-patch-grsecurity2, paxctl and gradm2)

Note that linux-patch-grsecurity2 should really be removed now.
 
 
 
 I would like to see this moving forward, so I volunteer myself to help
 with the maintenance of this featureset.
 
Thanks for that :)
-- 
Yves-Alexis


signature.asc
Description: This is a digitally signed message part

Bug#605090: [RFC] Add a grsec featureset to Debian kernels

[Carlos Alberto Lopez Perez]

Hello,


What is the status of this? It has been a looong time ago since last update.


I am also interested in having a Debian kernel with the grsec+pax
featureset and I am sure that many sysadmins would appreciate this
possibility. There is a huge user base of grsec from hosting companies.


I agree that this RBAC thing may be not interesting for everybody giving
the fact that it duplicates some functionality (we already have SELinux
and TOMOYO).


So if you really feel so strong about removing this feature from the
debian-grsec-kernel it can be easily done just by setting
CONFIG_GRKERNSEC_NO_RBAC=y in the .config (there is no need to ask
upstream to split the patch).


Anyway I think RBAC is a nice feature and it don't hurts: Its far easier
to use than SElinux [1] and we already have in Debian the user-space
tools to work with it:

  CC'ing Laszlo Boszormenyi
  (maintainer of linux-patch-grsecurity2, paxctl and gradm2)



I would like to see this moving forward, so I volunteer myself to help
with the maintenance of this featureset.



Regards!


[1] http://www.cs.virginia.edu/~jcg8f/SELinux%20grsecurity%20paper.pdf


-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Bug#605090: [grsec] update on featureset

[Yves-Alexis Perez]

On mar., 2011-10-11 at 16:52 +0200, Yves-Alexis Perez wrote:
 Ok so the tarball on the website isn't really convenient so, for now,
 I've put the quilt serie on a git repository on git.d.o:
 http://anonscm.debian.org/gitweb/?p=users/corsac/grsec-patches.git;a=summary

Now upgraded to grsecurity 2.2.2-3.0.8-201110250925 against
linux-2.6_3.0.0-6.

Package (i386 and amd64) should be available on:

deb http://molly.corsac.net/~corsac/debian/kernel-grsec/packages/ sid/

tonight.
 
 Could we move forward on this?

Since I got not reply at all after this mail, I'm asking again. I know
people are busy and I know this bug is not the easiest to handle, but
I'd really like to move on.

Since the RT featureset was added not that long ago, I guess the concept
of featureset is still welcome. I know the situation is different, but
still, I really think Debian users would appreciate a grsecurity
featureset, which wouldn't harm other people kernels thanks to the
alternate image.

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM


signature.asc
Description: This is a digitally signed message part

Bug#605090: [grsec] update on featureset

[Ben Hutchings]

On Thu, 2011-11-10 at 15:46 +0100, Yves-Alexis Perez wrote:
 On mar., 2011-10-11 at 16:52 +0200, Yves-Alexis Perez wrote:
  Ok so the tarball on the website isn't really convenient so, for now,
  I've put the quilt serie on a git repository on git.d.o:
  http://anonscm.debian.org/gitweb/?p=users/corsac/grsec-patches.git;a=summary
 
 Now upgraded to grsecurity 2.2.2-3.0.8-201110250925 against
 linux-2.6_3.0.0-6.
 
 Package (i386 and amd64) should be available on:
 
 deb http://molly.corsac.net/~corsac/debian/kernel-grsec/packages/ sid/
 
 tonight.
  
  Could we move forward on this?
 
 Since I got not reply at all after this mail, I'm asking again. I know
 people are busy and I know this bug is not the easiest to handle, but
 I'd really like to move on.
 
 Since the RT featureset was added not that long ago, I guess the concept
 of featureset is still welcome. I know the situation is different, but
 still, I really think Debian users would appreciate a grsecurity
 featureset, which wouldn't harm other people kernels thanks to the
 alternate image.

Every extra featureset that requires additional effort from the existing
team members reduces the effort that can be spent on other tasks.

Is the grsecurity patch getting bigger or smaller over time?

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?


signature.asc
Description: This is a digitally signed message part

Bug#605090: [grsec] update on featureset

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/11/2011 16:24, Ben Hutchings wrote:
 Every extra featureset that requires additional effort from the existing
 team members reduces the effort that can be spent on other tasks.

Yes, I definitely understand that, and I really intend to provide enough
help to minimize the burdain on existing team members which don't care
about that featureset.
 
 Is the grsecurity patch getting bigger or smaller over time?

It's a bit hard to tell. Putting aside the various security backports
(mainly relevant for the 2.6.32 patch), the size seems to have decreased
a little since 2.6.39 (and risen in the 3.0 serie).

Feature-wise, Brad Sprengler and the PaX team still add stuff, like the
gcc plugins or hardening features like symbols hiding, fix bugs (for
example in RBAC code), while few of them reach mainline.

Regards,
- -- 
Yves-Alexis Perez
ANSSI/ACE/LAM
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iQIcBAEBCgAGBQJOu/91AAoJENcc3UqWxbaOkVAQAK5kcuOvmrASldaP0c/CpvXm
AgQBfFLhPJjO8KxB/qDhdAcc4m9Kn7rYbmbFgHi5ujdHu99ccki1+wzZv12LFZkc
VzNs12RQT8OboxQybfNcsRRgledwRGOCIefkKM91z05YSLBOmxNalpC//mcEqx+Y
rSvoZ/+/X/ZFp7krKHULR2oeqJFohjBejnS3/6eLSQDN8HCvGi0QN/MF45X9O+aE
vVhfzkDAV3LuyYXOi82Vi9y01W/7KtLbTGf8TEi7vh2XWwrdzHagnc/Lg28adxfu
QaL/ufabLUY34fdB0R5AfSjKcpnyX4J/tpDEWeObtQTMQc/p/kb0yJXWBTAk3azI
/PlF63OUxUhOh9wFASbYR5nZC+e8ToATA3XAYJ/nGoXKvC2vxD73DIk7jspgstS0
bVYLcuSQ4ZkxG2w3CmbgqdF0/92JTZ5PQEvL/0lM2lwYDFt4cZ4kY2xDK+7uo0uD
8j5Js51T0PPROhg0wKK3Zk5wxnReUj8sOnfB96GtCc8x05N5CCxr49pi6Zfdk6BM
yO1tfvq75x9jfspzAv+mkhZDbfo47NcbKYLM+aZvJGKHavqCU0ejSOTCSNgsH8og
cY8/tEhIMd3dSY4IXmj8eHl3gSVTkzwRDpRVpGxmicf3HGlfs2tMpLAtiRY4JS8I
eOmxJ7Wbkpv5dstazq8y
=eBwV
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#605090: [grsec] update on featureset

[Moritz Muehlenhoff]

On Thu, Nov 10, 2011 at 05:44:37PM +0100, Yves-Alexis Perez wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 On 10/11/2011 16:24, Ben Hutchings wrote:
  Every extra featureset that requires additional effort from the existing
  team members reduces the effort that can be spent on other tasks.
 
 Yes, I definitely understand that, and I really intend to provide enough
 help to minimize the burdain on existing team members which don't care
 about that featureset.
  
  Is the grsecurity patch getting bigger or smaller over time?
 
 It's a bit hard to tell. Putting aside the various security backports
 (mainly relevant for the 2.6.32 patch), the size seems to have decreased
 a little since 2.6.39 (and risen in the 3.0 serie).
 
 Feature-wise, Brad Sprengler and the PaX team still add stuff, like the
 gcc plugins or hardening features like symbols hiding, fix bugs (for
 example in RBAC code), while few of them reach mainline.

Maybe we can ask upstream, whether the RBAC code and the rest of the
patch set can be separated? I don't think there's much interest in RBAC
for a Debian feature set, while the rest is quite interesting.

Cheers,
Moritz



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#605090: [grsec] update on featureset

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/11/2011 18:06, Moritz Muehlenhoff wrote:
 Maybe we can ask upstream, whether the RBAC code and the rest of the
 patch set can be separated? I don't think there's much interest in RBAC
 for a Debian feature set, while the rest is quite interesting.
 
Unfortunately, I already asked upstream about a nicely splitted patch,
but Brad didn't seem interested back in time. It might be worth
re-asking though.

Regards,
- -- 
Yves-Alexis Perez
ANSSI/ACE/LAM
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iQIcBAEBCgAGBQJOvAcIAAoJENcc3UqWxbaOK3cP/jUKp59eQbTfQ30JmQsAtKFB
3A2r9PRFvs0eex7O/DYXz2Ua/MFnfCxYg2Xuv79aqH+8mBX/WlmNmZfL7uHCT3Zx
AgvT6A4LFxm5HNtQV4xnqflmEaxFCWBxVgv39ITeCvNKfxXKM6tYIXmb38GEhB79
srxrL1wW7Kad62YXngQeltTWbJIkWBBgcC29zERXpY/DDoQhwAvel4jSTu+L54NB
zmc8X3YI7gcwMq0Xke+aPNqGu+IfQaUpOu8BVa3WwxN8fNhYkDddkmrJ2YdpcjeJ
sawNl08d6zgZWntDTKe/KjvJpV9goxP/jKR9vUFYgSl+S90tGKzMzpAQFddgwTh9
h422D1Pbd9swyHQ32AN2RIxVEAf6zXcyZPpGw5NSdsbwu3A+1A4/BsTDkVNOKarq
msS+0tFwSdwqe8aOvFawenuHmh1s33c6urZn6Bve6a1tWCTs1Lapydcl34VYAJrX
ii5zsBAlA/Vl3NujUh8V0rvYzHADB4qjQFIUS+TyEEOaHLVBK4/fUlcGxZnS4HcV
6lw/+Nm7nSbgwBv7lbGRJwOgoT38KRNsh/03IQyC8qNLooHn31HJvctGxMt+o7Hu
E2HqxJC2SPBQGoPXQdqRHK+Bi2z/ukS4u3dtfWsBZxkQQVi9w3Zq7Ele6dx7cXvb
YOF14DsTQbVkg+hgaptH
=j3zh
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#605090: splitting grsecurity patchset

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Brad,

as you may know from IRC, I'm trying to include a new grsecurity
featureset to the Debian kernels. The point is basically to add a new
binary package to the existing architecture, so people interested in
kernel hardening can chose to run a grsecurity-enabled kernel instead of
the default one.

Currently the patch is a bit large and poses some maintainance issues to
the kernel team, and something which would help us would be to have
access to some splitted version of the patchset, with few files for
large features (such as RBAC).

I'm not sure how much work does this involve for you (I'm not sure how
you're working internally), but it'd be quite appreciated (and not only
for Debian kernel people).

Regards,
- -- 
Yves-Alexis Perez
ANSSI/ACE/LAM
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iQIcBAEBCgAGBQJOvAroAAoJENcc3UqWxbaOIMgP/0CXIyGP+pZQsRcGfniYH5NX
DMviV1kHzurddtGu/VIPdygoJ+ORz9kEiISU9neeO9O99a/n7KQ4vRSIbcv9ODU3
pxAfprz0ej4TWsVk5kRQBNTWuF8Dd9Abzg0x0RdQcrkqmxgORiHAPW/PhyTelyKL
cEf7mXFNEt2aVT63urm21OziAz/CmXRbGidocwHYiX+RcBpD0RCQ9rj5OLFru9R2
8RGtVDqVewqAekOEb4ZV2SQ5g4uPiX51vrazTtxYLp1+g2rSuHDTX/+r734+0EmQ
Gw6QaLPat6gvkIvsMS3BNk0mnM8GVM3SlSNvW+Ile00GqJeR/nPzd2ECelEcgP4x
+ErBJICCUvKuhNw3uChkh8gNkD9WXqrnHi+7qgGaxs4aP+VmD2Y7gaN4V1RSRgf/
N+8o6u2SZvsaUvC5LFtp37RwppR7xIGrVswMKgojgwl9Vp1xY1EcOb0k90YqA2eu
SfQlT7rJGM10W2gkVvLdP93wY4S4R2HI56rlEElQlRqJwGbwLh0nGwPMAKtIQlHG
sWdwEpCIRiMc0wSN+6Xcd+VoFua7a1QVSCtv3TEga+tWPGNzeRJKHPThHWiQUXb6
GCeUKdKgt76NrJ/aiqeSpD79YQTTQCUpb2egK8KdGP6d4JnXpi/TXhQ+mtq9DpUb
9hEH75ILvIqr9hUuSAR/
=Bosl
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#605090: [grsec] update on featureset

[Yves-Alexis Perez]

Ok so the tarball on the website isn't really convenient so, for now,
I've put the quilt serie on a git repository on git.d.o:
http://anonscm.debian.org/gitweb/?p=users/corsac/grsec-patches.git;a=summary

The master branch for is for the sid branch in debian kernel svn, and
there's a squeeze branch too (though it's for now out of date).

I've updated the patches to the latest svn (sid) version and the latest
grsecurity/pax patches and I'll put updated packages on my server
tonight.

Could we move forward on this?

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM


signature.asc
Description: This is a digitally signed message part

Bug#605090: [grsec] update on featureset

[Yves-Alexis Perez]

On mar., 2011-10-11 at 16:52 +0200, Yves-Alexis Perez wrote:
 
 I've updated the patches to the latest svn (sid) version and the latest
 grsecurity/pax patches and I'll put updated packages on my server
 tonight. 

Packages are available on:

deb http://molly.corsac.net/~corsac/debian/kernel-grsec/packages/ sid/

Regards,
-- 
Yves-Alexis


signature.asc
Description: This is a digitally signed message part

Bug#605090: Update on grsecurity featureset

[Yves-Alexis Perez]

On jeu., 2011-09-01 at 05:20 +0100, Ben Hutchings wrote:
 On Wed, 2011-08-31 at 18:33 +0200, Yves-Alexis Perez wrote:
  Ok, here's an updated patchset.
  
  Tarball can be found at
  http://molly.corsac.net/~corsac/debian/kernel-grsec/grsec-patches.tar.xz
  (and already extracted in grsec-patches/ folder).
  
  It's a folder with a quilt patche series
  
  * 01_support-linux-3.0.patch
  
  This is unrelated but needed to support linux3 naming scheme in
  genorig.py.
 
 Already done on trunk.

Ha, fair enough, I was wondering how people did the orig for 3.x :) Can
this be committed to sid/, since it has 3.0 anyway?
 
  * 02_force-hostcc-version.patch
  
  This one is needed because grsecurity ships two gcc (= 4.5) plugins.
  Those need to be built with the same compiler version as the rest of the
  kernel, but right now they're built with HOSTCC which is not set right
  now, so defaults to 'gcc' which is gcc-4.6 at that time. So export
  HOSTCC to the (non CROSS_COMPILE) version.
 
 gcc plugins surely need to be built _for_ the compiler version used for
 the kernel, not _by_ that version.

I'm not sure about what you mean here. I assumed that building a gcc
plugin with a given gcc version meant that it was built *for* this
version (and thus forcing the compiler for those plugins to the same
version used for the kernel meant the plugin would work at kernel build
time).

 
 Also, you are changing HOSTCC for all build tools and not just these
 plugins.

Yes, as said on #debian-kernel this was because it seemed more logical
to use the same thing everywhere and because at one point I had issues
with building perf for squeeze 2.6.32 on a box where gcc was at 4.6. And
in fact, afaict, I'm forcing HOSTCC for the whole build, but I have to
admit I found that more consistent to have CC and HOSTCC at the same
version.

If you think it's a bad idea I can try to modify grsecurity patch to add
it to the plugins Makefile (that'd be debian specific the same way I
remove localversion) but kernelvariables looked like a good place.
 
  03_enable-strict-user-copy-check.patch
  
  This one in not directly involved with grsecurity. Could be enabled by
  itself (#639919)
 
 Without the strict check, the crap code produces a compile-time warning
 and a run-time warning and *no copying*.  With the strict check, the
 crap code results in FTBFS (but only on i386 and s390!).  So how is this
 an improvement for us?

I've replied to the specific bug so we can track it there, since it's
unrelated (and is not needed per se on the grsecurity featureset).
 
  04_add-linux-grsec-base-templates.patch
  
  This one adds basic templates for a linux-grsec-base binary packages to
  be built by linux-2.6 but I still didn't figured out how to patch
  genorig.py to make it do it.
 
 Don't add such a package to linux-2.6.  It should be a new source
 package, like linux-base is now (after I initially made that mistake).

Well, that's what I did when you suggested it (packaging is at
http://anonscm.debian.org/gitweb/?p=collab-maint/linux-grsec-base.git;a=summary)
 but afaiui Bastian asked it not to be a new source package. Anyway, this can 
be dropped easily if not needed.
 
  05_add-grsec-featureset.patch
  
  This is the main part, adding the featureset and config.
 
 And linux-grsec-base, a second time!

Woops, fixed :)
 
  06_grsecurity.patch
  
  The main grsecurity patch, not really readable since the quilt patch
  adds a patch :) It's basically the genuine grsecurity patch (right now
  grsecurity-2.2.2-3.0.4-201108301903.patch) with two little change:
  
  * removing the -grsec localversion
  * oneliner to make it apply against debian sources
 
 You should provide a gen-patch script to help in regenerating the patch.

Yeah good point. At least localversion should be easy to filterdiff. And
maybe add a specific .kernelvariables and the relevant include to the
plugins Makefile. Thanks for the suggestion.

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM


signature.asc
Description: This is a digitally signed message part

Bug#605090: Updated patch

[Yves-Alexis Perez]

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: Update on grsecurity featureset

[Yves-Alexis Perez]

Ok, here's an updated patchset.

Tarball can be found at
http://molly.corsac.net/~corsac/debian/kernel-grsec/grsec-patches.tar.xz
(and already extracted in grsec-patches/ folder).

It's a folder with a quilt patche series

* 01_support-linux-3.0.patch

This is unrelated but needed to support linux3 naming scheme in
genorig.py.

* 02_force-hostcc-version.patch

This one is needed because grsecurity ships two gcc (= 4.5) plugins.
Those need to be built with the same compiler version as the rest of the
kernel, but right now they're built with HOSTCC which is not set right
now, so defaults to 'gcc' which is gcc-4.6 at that time. So export
HOSTCC to the (non CROSS_COMPILE) version.

03_enable-strict-user-copy-check.patch

This one in not directly involved with grsecurity. Could be enabled by
itself (#639919)

04_add-linux-grsec-base-templates.patch

This one adds basic templates for a linux-grsec-base binary packages to
be built by linux-2.6 but I still didn't figured out how to patch
genorig.py to make it do it.

05_add-grsec-featureset.patch

This is the main part, adding the featureset and config.

06_grsecurity.patch

The main grsecurity patch, not really readable since the quilt patch
adds a patch :) It's basically the genuine grsecurity patch (right now
grsecurity-2.2.2-3.0.4-201108301903.patch) with two little change:

* removing the -grsec localversion
* oneliner to make it apply against debian sources

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM


signature.asc
Description: This is a digitally signed message part

Bug#605090: Update on grsecurity featureset

[Ben Hutchings]

On Wed, 2011-08-31 at 18:33 +0200, Yves-Alexis Perez wrote:
 Ok, here's an updated patchset.
 
 Tarball can be found at
 http://molly.corsac.net/~corsac/debian/kernel-grsec/grsec-patches.tar.xz
 (and already extracted in grsec-patches/ folder).
 
 It's a folder with a quilt patche series
 
 * 01_support-linux-3.0.patch
 
 This is unrelated but needed to support linux3 naming scheme in
 genorig.py.

Already done on trunk.

 * 02_force-hostcc-version.patch
 
 This one is needed because grsecurity ships two gcc (= 4.5) plugins.
 Those need to be built with the same compiler version as the rest of the
 kernel, but right now they're built with HOSTCC which is not set right
 now, so defaults to 'gcc' which is gcc-4.6 at that time. So export
 HOSTCC to the (non CROSS_COMPILE) version.

gcc plugins surely need to be built _for_ the compiler version used for
the kernel, not _by_ that version.

Also, you are changing HOSTCC for all build tools and not just these
plugins.

 03_enable-strict-user-copy-check.patch
 
 This one in not directly involved with grsecurity. Could be enabled by
 itself (#639919)

Without the strict check, the crap code produces a compile-time warning
and a run-time warning and *no copying*.  With the strict check, the
crap code results in FTBFS (but only on i386 and s390!).  So how is this
an improvement for us?

 04_add-linux-grsec-base-templates.patch
 
 This one adds basic templates for a linux-grsec-base binary packages to
 be built by linux-2.6 but I still didn't figured out how to patch
 genorig.py to make it do it.

Don't add such a package to linux-2.6.  It should be a new source
package, like linux-base is now (after I initially made that mistake).

 05_add-grsec-featureset.patch
 
 This is the main part, adding the featureset and config.

And linux-grsec-base, a second time!

 06_grsecurity.patch
 
 The main grsecurity patch, not really readable since the quilt patch
 adds a patch :) It's basically the genuine grsecurity patch (right now
 grsecurity-2.2.2-3.0.4-201108301903.patch) with two little change:
 
 * removing the -grsec localversion
 * oneliner to make it apply against debian sources

You should provide a gen-patch script to help in regenerating the patch.

Ben.



signature.asc
Description: This is a digitally signed message part

Bug#605090: Great idea to get grsec flavored Debian kernels

[Helge Kreutzmann]

Hello,
it would be really great to get grsec enabled kernels. We've using them
for years (self compiled) and except for the recent problems with
iceweasel (cf. #623997) without any modifications / problems (except
for a root kit we caught 7 years ago, but that's on purpose).

Greetings

   Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software libre: http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#605090: Updated patch

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Bastian Blank]

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

[Bastian Blank]

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

[maximilian attems]

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

[Yves-Alexis Perez]

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

[micah anderson]

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

[Kees Cook]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Ian Campbell]

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

[Bastian Blank]

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

[Yves-Alexis Perez]

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

[Bastian Blank]

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