Full system learning and CAP_DAC_OVERRIDE

[pyllyukko]

Ehlo.

I'm trying to develop a RBAC policy and here's one issue I feel I keep constantly running into.

So the full system learning seems to work quite nicely for most of the times, but it doesn't seem to "pick up" root's processes that exercise CAP_DAC_OVERRIDE (or CAP_DAC_READ_SEARCH) when they are reading information from another user's processes through /proc/<pid>/. I also have GRKERNSEC_PROC_USER, so root doesn't have read access to those files in /proc.

Here's a specific example:

* console-kit-daemon is running as the root user
* User sends a message via D-Bus
* ConsoleKit tries to acquire some info from the PID that sent the message and fails: open("/proc/23893/environ", O_RDONLY) = -1 EACCES (Permission denied)
* Full system learning has registered CAP_SYS_PTRACE as the only required capability for console-kit-daemon

I think I gain better security when I relax the permissions on /proc, so I don't need to grant these daemons such a powerful capability "over nothing". Should the full system learning be improved so that it would register the need for this capability when root doesn't have read access to all of /proc?

I thought about setting GRKERNSEC_PROC_GID to 0, but I'm not entirely sure whether this is a "proper" solution.

[spender]

What kernel log appears for that denial? Also what was the process it was trying to get information about? I don't think there's any problem with CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH here, and you're actually seeing some other problem entirely (possibly a missing subject mode, which RBAC doesn't learn).

-Brad

[pyllyukko]

Kernel logs:

Code: Select all

[13228.360649] grsec: (root:U:/usr/sbin/console-kit-daemon) use of CAP_DAC_READ_SEARCH denied for /usr/sbin/console-kit-daemon[console-kit-dae:1208] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
[13228.360663] grsec: (root:U:/usr/sbin/console-kit-daemon) use of CAP_DAC_OVERRIDE denied for /usr/sbin/console-kit-daemon[console-kit-dae:1208] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0


The process it was trying to get information about was the one sending the message via D-Bus. It's not a missing subject, for instance the console-kit-daemon has the following from full system learning:

Code: Select all

# Role: root
subject /usr/sbin/console-kit-daemon o {
        /                               h
        /dev                            h
        /dev/log                        rw
        /dev/null                       r
        /dev/urandom                    r
        /etc                            r
        /etc/ConsoleKit                 h
        /etc/ConsoleKit/run-seat.d     
        /etc/ConsoleKit/run-session.d   
        /etc/grsec                      h
        /etc/gshadow                    h
        /etc/gshadow-                   h
        /etc/ppp                        h
        /etc/samba/smbpasswd            h
        /etc/shadow                     h
        /etc/shadow-                    h
        /etc/ssh                        h
        /lib64                          rx
        /lib64/modules                  h
        /proc                           r
        /proc/bus                       h
        /proc/kallsyms                  h
        /proc/kcore                     h
        /proc/modules                   h
        /proc/slabinfo                  h
        /proc/sys                       h
        /usr                            h
        /usr/bin                        h
        /usr/bin/pm-is-supported        x
        /usr/lib64                      h
        /usr/lib64/ConsoleKit/run-seat.d       
        /usr/lib64/ConsoleKit/run-session.d     
        /usr/libexec                    h
        /usr/libexec/ck-collect-session-info    x
        /usr/libexec/udev-acl           x
        /var                           
        /var/backups                    h
        /var/log/ConsoleKit/history     r
        /var/run                       
        /var/run/ConsoleKit             
        /var/run/ConsoleKit/database    rwcd
        /var/run/ConsoleKit/database~   rwcd
        -CAP_ALL
        +CAP_SYS_PTRACE
        bind    disabled
        connect disabled
}


And the policy-kit-daemon is only one example, as there are other similar processes that fail to query info through /proc.

[spender]

Ok, I see what the problem is, your logs helped track it down. It has to do with a change I made to the ordering of one particular check: overriding DAC when trying to access a directory. The way the upstream kernel works is by first checking for CAP_DAC_OVERRIDE and then for CAP_DAC_READ_SEARCH for this case. The problem (as evidenced by SELinux policies that were claimed to be written manually by experts, but were clearly developed from audit2allow) is that CAP_DAC_OVERRIDE, being a superset of CAP_DAC_READ_SEARCH, would be the only capability learned, ending up with a weaker policy. So I had reordered it so that CAP_DAC_READ_SEARCH would be checked first, but then there's another problem. If the process only had CAP_DAC_OVERRIDE allowed in policy, then it would get a denied CAP_DAC_READ_SEARCH each time, even though it's not necessary. Hence the addition of the initial _nolog variant, though the shortcircuit behavior means that nothing would get learned in this case. What would normally happen is that a process triggering this check would likely hit one of the other checks when overriding DAC to read/write a file, and would get learned at that point. I'll have to think a bit about a fix, but will have it in the upcoming 4.9 patch (and I'll provide a split-out version for you here).

Thanks,
-Brad

[spender]

The fix is now available at:
https://grsecurity.net/~spender/capdacfix.diff

Thanks for the report!
-Brad

[pyllyukko]

I tried the patch and now it indeed reports CAP_DAC_READ_SEARCH for these subjects. Thanks!