grsecurity forums

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?

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

Thanks,
-Brad

Sent e-mail, thanks.

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

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

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!

mnalis wrote: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 .

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

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!