PAX flags in grsec policy ignored in newer patches?

[mnalis]

With grsec-2.9.1-2.6.32.60-201212271948 I'm having folowing problems running update-grub

Code: Select all

Dec 29 21:31:52 data kernel: PAX: From x.x.x.x: execution attempt in: <anonymous mapping>, 3bc4d473000-3bc4d488000 3fffffea000
Dec 29 21:31:52 data kernel: PAX: terminating task: /usr/sbin/grub-probe(grub-probe):3643, uid/euid: 0/0, PC: 000003bc4d486e60, SP: 000003bc4d486e08
Dec 29 21:31:52 data kernel: PAX: bytes at PC: 41 bb b0 61 40 00 49 ba 50 6e 48 4d bc 03 00 00 49 ff e3 00
Dec 29 21:31:52 data kernel: PAX: bytes at SP-8: 0000000000000000 0000000000402bbb 0000000000000000 0000000000631960 000003bc4d486e60 0000000000406346 0000000000000000 000003bc4d48727f 0000000000000003 000000000040601e 0000000000000000


I have (in admin role) subject:

Code: Select all

subject /usr/sbin/grub-probe
        -PAX_SEGMEXEC
        -PAX_PAGEEXEC


(and similar subjects for other grub-* stuff)

It used to work in grsec-2.9-2.6.32.59-201205131656 to allow update-grub to run, but now it doesn't. (only kernel changed in between)

So in grsec-2.9.1-2.6.32.60-201212271948 I've had to enable CONFIG_PAX_PT_PAX_FLAGS and do

Code: Select all

paxctl -Cpsm /usr/sbin/grub-probe

to enable it to work.

However, I much prefer leaving binaries untouched and using /etc/grsec/policy ACLs to override such protection; is it still possible, and if it is, what am I doing wrong?

[spender]

Can you mail me your .config and a link to the vmlinux?

Thanks,
-Brad

[mnalis]

Sent e-mail, thanks.

[PaX Team]

as a sidenote, grub binaries should run fine with EMUTRAMP enabled on them, no need to disable PaX.

[spender]

I've looked at the kernel disassembly and the code looks fine to me. Are you sure you executed it from the admin role? Could you create a similar subject for /bin/cat in the admin role and give me the output of 'cat /proc/self/status'?

Thanks,
-Brad

[mnalis]

To: Pax Team
Thanks, I've tried that too without success, but assumed that is because I can't use "+PAX_EMUTRAMP" in policy, because my kernel was compiled without CONFIG_PAX_EMUTRAMP option. Or can I still use "+PAX_EMUTRAMP" in policy file? I've also tried "paxctl -CzEx /usr/sbin/grub-probe" instead of "paxctl -Cpsm /usr/sbin/grub-probe" but it didn't work (probably for the same reason that CONFIG_PAX_EMUTRAMP was not enabled in kernel).


To: Spender
As sure as I can be, I did "gradm -a admin" and authenticated, and dmesg(8) and other restricted commands worked (which don't work before authentication as admin role).

This is part of /etc/grsec/policy which should be relevant - the file did not change, only the kernel did (that is, the same policy seems too have worked under grsec-2.9-2.6.32.59-201205131656, but not grsec-2.9.1-2.6.32.60-201212271948)

Code: Select all

role admin sA
role_allow_ip 0.0.0.0/32
role_allow_ip 192.168.200.0/24
role_alllow_ip x.x.x.x/x


subject / rvka
        / rwcdmlxi
        RES_AS 24000M 24000M

subject /usr/sbin/grub-setup
        -PAX_SEGMEXEC
        -PAX_PAGEEXEC

subject /usr/sbin/grub-probe
        -PAX_SEGMEXEC
        -PAX_PAGEEXEC

subject /usr/sbin/grub-mkdevicemap
        -PAX_SEGMEXEC
        -PAX_PAGEEXEC

subject /bin/cat
        -PAX_SEGMEXEC
        -PAX_PAGEEXEC



after that goes "role default G" and it's rules.

Here I've reinstalled plain Debian Squeeze binaries, reloaded policy, entered admin role, and problem is still here

Code: Select all

# apt-get install --reinstall grub-pc grub-common
[...]
# gradm -R
Password:
# gradm -a admin
Password:
# paxctl -v /usr/sbin/grub-probe                                         
PaX control v0.5
Copyright 2004,2005,2006,2007 PaX Team <pageexec@freemail.hu>

file /usr/sbin/grub-probe does not have a PT_PAX_FLAGS program header, try conversion
#  update-grub
Killed (core dumped)
# dmesg -c
grsec: From x.x.x.x: (admin:S:/) successful change to special role admin (id 10) by /sbin/gradm[gradm:21387] uid/euid:0/0 gid/egid:0/0, parent /bin/zsh4[zsh:11752] uid/euid:0/0 gid/egid:0/0
PAX: From x.x.x.x: execution attempt in: <anonymous mapping>, 3d1b23a1000-3d1b23b7000 3fffffe9000
PAX: terminating task: /usr/sbin/grub-probe(grub-probe):21912, uid/euid: 0/0, PC: 000003d1b23b5a80, SP: 000003d1b23b5a28
PAX: bytes at PC: 41 bb b0 61 40 00 49 ba 70 5a 3b b2 d1 03 00 00 49 ff e3 00
PAX: bytes at SP-8: 0000000000000000 0000000000402bbb 0000000000000000 0000000000631960 000003d1b23b5a80 0000000000406346 0000000000000000 000003d1b23b5ea1 0000000000000003 000000000040601e 0000000000000000
# cat /proc/self/status
Name:   cat
State:  R (running)
Tgid:   29850
Pid:    29850
PPid:   11752
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 64
Groups: 0 510
VmPeak:    21496 kB
VmSize:    21496 kB
VmLck:         0 kB
VmHWM:       508 kB
VmRSS:       508 kB
VmData:    17788 kB
VmStk:        84 kB
VmExe:        48 kB
VmLib:      1500 kB
VmPTE:        32 kB
Threads:        1
SigQ:   1/16382
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000000000000
CapInh: 0000000000000000
CapPrm: fffffffffffffeff
CapEff: fffffffffffffeff
CapBnd: fffffffffffffeff
voluntary_ctxt_switches:        0
nonvoluntary_ctxt_switches:     1
PaX:    PeMRs
RBAC:   admin:S:/


Thanks for tracing this down!

[PaX Team]

Thanks, I've tried that too without success, but assumed that is because I can't use "+PAX_EMUTRAMP" in policy, because my kernel was compiled without CONFIG_PAX_EMUTRAMP option. Or can I still use "+PAX_EMUTRAMP" in policy file? I've also tried "paxctl -CzEx /usr/sbin/grub-probe" instead of "paxctl -Cpsm /usr/sbin/grub-probe" but it didn't work (probably for the same reason that CONFIG_PAX_EMUTRAMP was not enabled in kernel).

obviously if you disable a feature in the kernel .config then it's not usable .

[spender]

Hi mnalis,

I'm surprised that policy ever worked before -- perhaps something else changed in your kernel configuration (the new configuration system was implemented in the meantime). Please remove the "i" mode from the default object in the / subject. That's the inheritance flag which would cause any executed app from admin role to inherit the / subject -- your other subjects were never being reached.

-Brad

[mnalis]

thanks, that was it. I seems grsec-2.9.(0) series indeed had a bug which ignored "i" on that default policy, so my bug in policy went unnoted. (i did try several times across several reboots, and always update-grub worked with that same policy in grsec-2.9-2.6.32.59-201205131656, but not in grsec-2.9.1-2.6.32.60-201212271948, so my mind conveniently skipped over that "i").

Anyway just to let you know that it was indeed a configuration problem in 2.9.1 (and possible bug in 2.9 series which is now obsoleted). Thanks!