debian 8 grsec vs thunderbird

[haaber]

Hello,
back in March I compiled a grsec kernel (precisely 4.8.13) for my debian
8 following the nice tutorial for qubes. I put my std debian-8 on this
new kernel. Since the rebranding of icedove to thunderbird, the
thunderbird executable died misrably with "killed". Funnily, it work run
under debian-9. So I was searching for differences, and I found that my
grsec kernel actually kills the thunderbird. Any comments?

Bernhard

[haaber]

Some update : the same happens with 4.9.20.grsec. The reason seems
visible in ulimit -a:

core file size (blocks, -c) 0

whereas thunderbird requests 4096 (whatsoever unit). Remains to
understand /etc/security/limits.conf

Bernhard

[Reg Tiangha]

On 05/31/2017 04:59 AM, haaber wrote:
> Some update : the same happens with 4.9.20.grsec. The reason seems
> visible in ulimit -a:
>
> core file size (blocks, -c) 0
>
> whereas thunderbird requests 4096 (whatsoever unit). Remains to
> understand /etc/security/limits.conf
>
> Bernhard

systemd actually ignores /etc/security/limits.conf, although anything
launched by a gnome-terminal (and maybe some other things as well) does
respect that file.

systemd looks at /etc/systemd/user.conf and /etc/systemd/system.conf
instead so if you're changing variables in limits.conf, you could try
setting them there as well.

Or you can disable the memory protections on Thunderbird; that's what
coldkernel actually did by default if you used their paxctld
configuration, but it only had a listing for Icedove and not for
Thunderbird.

You could add a listing under /etc/paxctld.conf for Thunderbird:

/usr/lib/thunderbird/thunderbird m

and/or manually convert the executable with paxctl if you have it installed:

sudo paxctl -cm /usr/lib/thunderbird/thunderbird

[haaber]

Thank you very much Reg! That solves miraculously the problem. I was
playing with -E instead and it did not help me. At least I learned some
minimal experience with paxctl that way :)) Bernhard

[Reg Tiangha]

On 2017-05-31 12:34 PM, haaber wrote:
> Thank you very much Reg! That solves miraculously the problem. I was
> playing with -E instead and it did not help me. At least I learned some
> minimal experience with paxctl that way :)) Bernhard

Lower case letters disable the specific protection and upper case
letters enable them. So the 'm' disabled memory protections, and the 'E'
would have enabled the emulation of trampolines.

You can learn what all the options are by looking at paxctl's man page:

man paxctl

and if grsec is killing processes you actually want to run, you can look
at the logs, see what protection is being triggered, and can use
paxctl/paxctld to disable it just for that executable or library.

[haaber]

> and if grsec is killing processes you actually want to run, you can look
> at the logs, see what protection is being triggered, and can use
> paxctl/paxctld to disable it just for that executable or library.

I tried, but I dd not learn anything useful. Here, for example, is a
sniplet of my syslog (sorry for broken long lines)

May 21 22:21:15 localhost kernel: [ 717.509203] PAX: execution attempt
in: <anonymous mapping>, 715894beb000-715894e5b000 715894beb000
May 21 22:21:15 localhost kernel: [ 717.509216] PAX: terminating task:
/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java(java):5500, uid/euid:
0/0, PC: 0000715894beb060, SP: 000071589f156488
May 21 22:21:15 localhost kernel: [ 717.509222] PAX: bytes at PC:
85 f6 0f 84 11 00 00 00 0f ae f0 0f ae 3f 48 83 c7 40 ff ce
May 21 22:21:15 localhost kernel: [ 717.509239] PAX: bytes at SP-8:
000071589f1564c0 000071589daf685b 000071589f156530 000071589f156530
000071589f1564c0 000071589de1a558 000071589f156a40 000071589f156a40
000071589f156a20 000071589dee2f37 000071589f156b40

how do you read off the protection that was being triggered in this ??
Bernhard

[Reg Tiangha]

Usually dmesg gives some hints, but most of the time it's the memory
protection, so that's a good first thing to try. You can also google the
executable and grsecurity and see what comes up since you're probably
not the only one to encounter the issue.

In this case, Java is well known to be incompatible with the full set of
PAX protections. You could try disabling just the memory protections to
see if that helps:

sudo paxctl -cm /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java

and/or if it doesn't, then disable a bunch more:

sudo paxctl -cpemrxs /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java

Java, WINE, and other things that emulate other things usually don't
play nice with grsecurity and so you'll need to figure out which
binaries or libraries grsec/pax is killing and modify their protection
permissions to get them to run.