[solved] denied executable mmap of / (root dir?)

[peetaur]

I have seen other threads such as this one about a similar thing, but in my case it seems not to make sense.

This is while RBAC is enabled:

Code: Select all

2014-10-09T23:37:19.200621+02:00 peetaur kernel: [30687.023201] grsec: (peter:U:/usr/bin/kdeinit4) denied executable mmap of / by /usr/bin/kdeinit4[klipper:5283] uid/euid:1000/1000 gid/egid:100/100, parent /usr/lib/systemd/systemd[systemd:1] uid/euid:0/0 gid/egid:0/0
2014-10-09T23:37:19.236634+02:00 peetaur kernel: [30687.059456] grsec: (peter:U:/) denied access to hidden file /var/cache/fontconfig/df311e82a1a24c41a75c2c930223552e-x86_64.cache-4 by /usr/lib64/kde4/libexec/drkonqi[drkonqi:17044] uid/euid:1000/1000 gid/egid:100/100, parent /usr/bin/kdeinit4[kdeinit4:4779] uid/euid:1000/1000 gid/egid:100/100


Why should I need to set a rule for exec on "/"? Wouldn't that not make sense and give x to the whole machine like the following?

Code: Select all

role peter u
subject / {
    / x
    ...
}


And the effect of this problem is quite severe. I ran full learning across 2 days, over probably more than 3 reboots and different people using the machine, but grsec is killing many KDE processes (konsole, klipper, plasma-desktop, etc.) and won't let me log in on text ttys. Killing X with ctrl+alt+backspace meant that X didn't start again. So I had to sysrq+u,s,b to reboot after enabling RBAC when all my consoles died. I thought full learning would have allowed these things to run and start, since I use them many times per day, and I would only have to add more rules for things that didn't run yet (maybe some weekly cronjobs, or system updates when the IPv4 addresses in the policy are stale, etc.). (and then after rebooting, KDE was very broken, and restoring ~/.kde4 from backup solved that...). And the fontconfig problem above should not affect the text TTYs, so something important isn't even being logged. (and I realize grsecurity is probably intended for servers, but if it is going to fail, it should at least log it, and be understood first, before I implement it somewhere important)


So how can I satisfy grsec so it won't kill klipper, plasma-desktop, konsole, etc.?
Do I need to duplicate my settings I already set with paxctl in the policy too?
Do I really need to set "/ x"?
Is there some important logging I am missing and can enable?


Linux peter 3.16.3-grsec-peter-grsec+ #1 SMP PREEMPT Fri Oct 3 12:03:24 CEST 2014 x86_64 x86_64 x86_64 GNU/Linux
gradm-3.0-201408301734.tar.gz
grsecurity-3.0-3.16.3-201409282025.patch (the test version, not stable)
systemd-208-23.3

[spender]

I imagine it's trying to create executable shared memory. Don't add 'x' to /, but instead add 'x' to the subject (allows executable shared memory).

-Brad

[peetaur]

Okay, so I have redone my full learning started later in the init process, so it doesn't inherit /etc/init.d/ subject, and manually added "x" to the subject modes for kdeinit4 (which I think solved the previous problem). And now:
- Right after enabling RBAC, it is impossible to run "gradm -a admin" as root; it says gradm doesn't exist. Also /proc/$$/status is hidden so I can't see the RBAC line there.
- neither X nor plasma nor other KDE processes are killed, but the desktop doesn't work; after a time, the desktop clock ticks, but keyboard and mouse are ignored (no mouse cursor even)
- logins from text TTYs still don't work; you can type login, hit enter, and it stops there
- after a bit longer, ctrl+alt+f* won't work either

After a forced reboot via sysrq+u,s,b, I see these logs, hand picked from grsecurity.log (my separate log with configured rsyslogd):

Code: Select all

2014-10-12T12:13:17.081715+02:00 peetaur kernel: [ 8846.829934] grsec: (default:D:/) use of CAP_SYS_ADMIN denied for /usr/bin/Xorg[Xorg:3988] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/kdm[kdm:3973] uid/euid:0/0 gid/egid:0/0
2014-10-12T12:13:39.283687+02:00 peetaur kernel: [ 8869.044784] grsec: (default:D:/) denied access to hidden file /proc/4583/status by /usr/bin/kdeinit4[konsole:4552] uid/euid:1000/1000 gid/egid:100/100, parent /usr/lib/systemd/systemd[systemd:1] uid/euid:0/0 gid/egid:0/0
2014-10-12T12:13:39.308705+02:00 peetaur kernel: [ 8869.069473] grsec: (default:D:/) denied truncate of /var/log/journal/aeb6c64acf54421ffc2947947fe9342a/system.journal by /usr/lib/systemd/systemd-journald[systemd-journal:358] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/systemd/systemd[systemd:1] uid/euid:0/0 gid/egid:0/0
2014-10-12T12:13:50.139701+02:00 peetaur kernel: [ 8879.906680] grsec: (default:D:/) denied access to hidden file /proc/4397/mounts by /usr/bin/ksysguardd[ksysguardd:4397] uid/euid:1000/1000 gid/egid:100/100, parent /usr/bin/kdeinit4[plasma-desktop:4385] uid/euid:1000/1000 gid/egid:100/100

While it sounds scary for Xorg (role root) to have CAP_SYS_ADMIN, it actually seems to have it already, so (1) why is CAP_SYS_ADMIN denied? (2) And why is /proc (role peter) denied also?
(3) And why doesn't TTY1 work? I think only the "denied truncate" line is related, but that also seems to be allowed in the policy.

Code: Select all

role root uG
role_transitions admin shutdown
...

subject /usr/bin/Xorg o {
user_transition_allow root nobody
group_transition_allow root
    /               h
   ...
    -CAP_ALL
    +CAP_DAC_READ_SEARCH
    +CAP_SETGID
    +CAP_SETUID
    +CAP_IPC_OWNER
    +CAP_SYS_RAWIO
    +CAP_SYS_ADMIN
    ...
}

subject /usr/lib/systemd/systemd-journald o {
    /
    ...
    /var                h
    /var/log/journal        rwc
   ...
}


Code: Select all

role peter u
...

subject /usr/bin/kdeinit4 ox {
    /
    ...
    /proc               r
    /proc/bus           h
    /proc/kallsyms          h
    /proc/kcore         h
    /proc/modules           h
    /proc/slabinfo          h
    ...
    -CAP_ALL
    ...
}

[spender]

In a full-learned config, you shouldn't have anything in your default role, so you need to investigate why users who should have their own individual roles were booted into the default role. This generally would mean you didn't learn enough and/or you were learning the IPs allows to access each role and didn't learn all of the needed ones. You could uncomment the "dont-learn-allowed-ips" from the learn_config. Also it's important when learning to enable the policy at the same location you enabled full learning from.

-Brad

[peetaur]

Right, the default role is quite bare.

Code: Select all

role default
subject /
    /           h
    -CAP_ALL
    connect disabled
    bind    disabled


My learning has been going on for several days. I have been testing only on a single machine, learning on the same machine where I have enabled RBAC. By IP you mean ip address, right? My IP is static. I would assume that the local system would not need to know any more IPs. And in the config I see lots of 0.0.0.0/32, and also the IP for a samba client to this machine, but I don't see my own IP there.

I have no idea how to investigate why users are in the default role, and wasn't even sure if the "(default:D:/)" in the log was significant. I'm a noob, and won't have a working understanding of RBAC policy building until I can get these problems solved. I would love to help get this missing conceptual knowledge into the documentation. So I guess you're saying that these processes are being denied things from the root and peter role because they are in the default role instead. And that sounds like a problem, but also I have no idea how it chooses the role. Should I just add "role_transitions peter" everywhere?

What is the right way to start learning automatically on boot? Might this problem still be caused by how I am starting learning? I planned to do learning and enforcing in the same place on boot, with a scripti like this:

Code: Select all

#! /bin/sh

mode=learn
if [ "$mode" = "learn" ]; then
    logfile=/etc/grsec/learning/learning.log
    mkdir -p /etc/grsec/learning/
    gradm -F -L "$logfile"
elif [ "$mode" = "enable" ]; then
    gradm -E
fi


[peetaur]

So, I did an experiment...

I modified the gradm source code so it will let me apply a bad policy with the default role with full access.

Code: Select all

diff -ur gradm.orig/gradm_analyze.c gradm/gradm_analyze.c
--- gradm.orig/gradm_analyze.c  2014-10-13 20:07:27.667509475 +0200
+++ gradm/gradm_analyze.c       2014-10-13 19:50:42.399160204 +0200
@@ -1144,7 +1144,8 @@
                       "configuration.  These must be fixed before the "
                       "RBAC system will be allowed to be enabled.\n",
                       errs_found);
-               exit(EXIT_FAILURE);
+              printf("DEBUG - forcing\n");
+               //exit(EXIT_FAILURE);
        }
 
        return;


I modified my policy to gives every permission to the default role (which gradm should forbid, but my code change allowed it), except for testing I hid the /root dir.

Code: Select all

role default
subject / rvka
    / rwcdmlxi
    /root h


Then I added these lines to the root and peter roles:

Code: Select all

role_allow_ip   0.0.0.0/0
role_allow_ip   127.0.0.6/32


Then I enabled RBAC (gradm -E)

And then I could still log in as root in the text TTYs, but would get errors still, since it was still using the default role:

Code: Select all

peter:/etc/grsec # gradm -S
The RBAC system is currently enabled.
peter:/etc/grsec # grep RBAC /proc/$$/status
peter:/etc/grsec # grep RBAC /proc/1/status
peter:/etc/grsec # ls /root
ls: cannot access /root: No such file or directory


Code: Select all

[ 2567.914724] grsec: From 127.0.0.6: (default:D:/) denied access to hidden file /root by /usr/bin/ls[ls:7676] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:7201] uid/euid:0/0 gid/egid:0/0

Also, logging into the admin role doesn't work as root (since default has no transition, only root does, and the roles aren't working properly).

Code: Select all

peter:/etc/grsec # gradm -a admin
Password:
Invalid password.


Code: Select all

[ 3290.095890] grsec: (default:D:/) special role admin failure for /sbin/gradm[gradm:8249] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:7910] uid/euid:0/0 gid/egid:0/0

And then in case my other learned roles were interfering, I commented out my include that includes those files, ran "gradm -R" and then KDE was dying, killing my konsoles, etc. but I could still log into a text TTY and "gradm -D" to stop it. And then I put the includes back.

And then I tried adding role_transitions everywhere:

Code: Select all

role default
role_transitions admin shutdown root peter
subject / rvka
    / rwcdmlxi
    /root h

...

role root
role root uG
role_transitions admin shutdown default peter
...

role peter u
role_transitions admin shutdown default root
...


And then I could log into the admin role from root, but still couldn't list /root before that, but could after being admin.

Code: Select all

[Mon Oct 13 20:22:01 2014] grsec: (default:D:/) denied access to hidden file /root/bin/grrole by /bin/bash[bash:7910] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/sudo[sudo:7909] uid/euid:0/0 gid/egid:100/100
[Mon Oct 13 20:22:11 2014] grsec: (default:D:/) successful change to special role admin (id 4) by /sbin/gradm[gradm:8447] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:8326] uid/euid:0/0 gid/egid:0/0

So from this, I would simply conclude it's bugged (I am using the test patch after all). It seemingly will never work to get any role other than "default" until I authenticate to "admin". (but I also don't really know what to expect... when should I be default, and when should it be peter? at kdm login? tty login? it doesn't ever say anything other than default or admin.) I'll try kernel 3.14 soon, in a VM.

[peetaur]

So I tested 3.14.21, which behaves exactly the same. Next plan is to try another distro in a VM to see if it behaves differently. (currently using openSUSE)

[peetaur]

Okay, so I tried it in debian 7.6 with kernel 3.16.5.

Code: Select all

role root uG
role_transitions admin shutdown
role_allow_ip   192.168.[...]/32
role_allow_ip   0.0.0.0/32
subject /  {
        /                               h
        /bin                            h
        /bin/dash                       x
        /bin/grep                       x
        /bin/ls                         x
        ...


Code: Select all

# gradm -D
Password:

# gradm -E

# gradm -a admin
-bash: /sbin/gradm: No such file or directory

# ls
-bash: /bin/ls: No such file or directory

It's still quite broken. And I expect if I use my modified gradm to give the default role full access, I would be able to see that I'm in the default role still.

Please tell me what I'm doing wrong... there are no clues. I have done nothing contradictory to the documentation as far as I know. I have done nothing special as far as I know.

[peetaur]

so I think this is mostly solved. I have lots of other problems but I'll deal with them separately.

The root cause of it was the running in init.d and then that caused me to do some other changes that broke the tests after I moved the learning out of init.d.

And also when I think it's working, it still says "default:D:/" as the role in learning mode. I thought that was a sign of trouble, but it's apparently normal.