grsecurity forums

I upgraded to grsecurity-2.1.8 from 2.1.6 today and ran into some trouble. My issue involves connecting to /dev/log.

When the RBAC system is first enabled, everything appears to work ok. However, when I send the HUP signal to syslog-ng, the RBAC system denys any further attempts to use /dev/log. Following is a little demonstration:

Code: Select all

radon ~ # logger start
radon ~ # gradm -a admin
radon ~ # gradm -a admin
Password:
radon ~ # killall -HUP syslog-ng
radon ~ # gradm -u
radon ~ # logger "this will fail"
radon ~ # gradm -D
Password:
radon ~ # gradm -E
radon ~ # logger "works again"


And the corresponding logs produced:

Code: Select all

Jan 29 14:17:09 radon logger: start
Jan 29 14:17:25 radon grsec: From 202.173.182.14: (default:D:/sbin/gradm) successful change to special role admin (id 77) by /sbin/gradm[gradm:8076] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:18860] uid/euid:0/0 gid/egid:0/0
Jan 29 14:17:33 radon syslog-ng[1768]: SIGHUP received, restarting syslog-ng
Jan 29 14:17:35 radon syslog-ng[1768]: new configuration initialized
Jan 29 14:17:35 radon syslog-ng[1768]: Changing permissions on special file /dev/tty12
Jan 29 14:17:35 radon syslog-ng[1768]: Changing permissions on special file /dev/tty12
Jan 29 14:17:35 radon grsec: From 202.173.182.14: (default:D:/usr/sbin/syslog-ng) denied chown of /dev/log by /usr/sbin/syslog-ng[syslog-ng:1768] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 29 14:17:35 radon grsec: From 202.173.182.14: (default:D:/usr/sbin/syslog-ng) denied chmod of /dev/log by /usr/sbin/syslog-ng[syslog-ng:1768] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 29 14:17:39 radon grsec: From 202.173.182.14: (admin:S:/) successful unauth of special role admin (id 77) by /sbin/gradm[gradm:16750] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:18860] uid/euid:0/0 gid/egid:0/0
Jan 29 14:18:08 radon grsec: From 202.173.182.14: (default:D:/usr/bin/logger) denied connect() to the unix domain socket /dev/log by /usr/bin/logger[logger:27755] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:18860] uid/euid:0/0 gid/egid:0/0
Jan 29 14:18:29 radon grsec: From 202.173.182.14: shutdown auth success for /sbin/gradm[gradm:27561] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:18860] uid/euid:0/0 gid/egid:0/0
Jan 29 14:18:31 radon grsec: From 202.173.182.14: (default:D:/sbin/gradm) grsecurity 2.1.8 RBAC system loaded by /sbin/gradm[gradm:7745] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:18860] uid/euid:0/0 gid/egid:0/0
Jan 29 14:18:42 radon logger: works again


As you can see, when /dev/log becomes inaccessable, simply disabling and enabling (restarting works too) the RBAC system rectifies the problem.

Also, if someone knows how to stop the chown and chmod messages produced by syslog-ng, I would love to hear them. Following are my ACL's for syslog-ng and logger.

Code: Select all

subject /usr/sbin/syslog-ng dpo {
        /                               h
        /etc                            h
        /etc/ld.so.cache                r
        /etc/syslog-ng/syslog-ng.conf   r
        /etc/resolv.conf                r
        /etc/syslog-ng                  r
        /etc/group                      r
        /etc/passwd                     r
        /lib                            rx
        /proc                           h
        /proc/kmsg                      r
        /usr                            h
        /usr/sbin/syslog-ng             rx
        /usr/share/zoneinfo             r
        /var                            h
        /var/log                        rwc
        /var/run
        /var/run/syslog-ng.pid          w
        /var/lib/config_repository      h
        /dev
        /dev/log                        rwcd
        /dev/null                       rw
        /dev/urandom                    r
        /dev/tty12                      rw
        /dev/vc
        /dev/grsec                      h
        /dev/mem                        h
        /dev/kmem                       h
        /dev/port                       h

        -CAP_ALL
        +CAP_MKNOD
        +CAP_FSETID
        +CAP_CHOWN

        bind    disabled
        connect disabled
}

subject /usr/bin/logger {
        /dev/log                        rw
        /var/run/utmp                   rw
}


Note that logger extends the default policy where /dev has find access.

Look forward to your replies.

Cheers,

Brad

What's the hardlink count on /dev/log? If you change your rules to /dev/log*, does it work without problems?

-Brad

What's the hardlink count on /dev/log? If you change your rules to /dev/log*, does it work without problems?

The hardlink count is 1

Code: Select all

radon ~ # ls -l /dev/log
srw-rw-rw-  1 root root 0 Jan 31 23:24 /dev/log


Adding * to /dev/log for only the syslog-ng subject had no effect, but adding it for all subjects appears to have rectified the problem. It also removed the message regarding chown and chmod for syslog-ng.

After submitting my original post, I also noticed that this problem also occurred on another file in another subject. Adding the * to the file also seems to have fixed the problem.

Is this behaviour a bug or is it something in the grsec rules that I am unaware of? Why is this not a problem with all the other files that are listed in my policy file?

Thank you for your help Brad.

Cheers,

Brad

What was the filename of the grsecurity patch you applied?

-Brad

What was the filename of the grsecurity patch you applied?

grsecurity-2.1.8-2.4.32-200601211647.patch

I should probably also mention that I am using hardened-sources-2.4.32-r2 from the Gentoo Linux distribution. It also contains several other kernel patches. Should I try patching a vanilla kernel manually?

Cheers,

Brad

Can you mail me an strace -f of this logger application? I want to see how exactly the /dev/log device is getting renamed. Also, for debugging purposes, you can add below the call to lookup_name_entry in gr_handle_rename() in grsecurity/gracl.c:

if (matchn != NULL)
printk(KERN_ALERT "renaming %s\n", matchn->filename);

-Brad

Could I have an strace beginning from the execution of logger? I received your syslog-ng strace, and noticed it's not renaming but deleting/recreating the file. I'll do some tests on it, but want to make sure first that the logger application isn't doing anything else with /dev/log so I can track the problem down.

-Brad

Sorry Brad, I'm not sure that I follow you. The strace that I sent you was beginning from the execution of the logger. Here's what I did:

Code: Select all

/etc/init.d/syslog-ng stop
strace -f -o syslog-ng.strace syslog-ng


Then from another terminal I ran the following a few times:

Code: Select all

killall -HUP syslog-ng


Then to terminate syslog-ng:

Code: Select all

killall syslog-ng


Btw, I had to run the strace in admin role. Even reloading the RBAC system will kill the strace. I'm guessing this is the correct behaviour of the RBAC system

I've noticed a few other occurences of this bug. One was with sshd trying to write to /var/log/wtmp:

Code: Select all

Feb  2 18:30:33 radon grsec: From 202.173.182.14: (default:D:/usr/sbin/sshd) denied open of /var/log/wtmp for writing by /usr/sbin/sshd[sshd:6152] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/sshd[sshd:5367] uid/euid:0/0 gid/egid:0/0
Feb  2 18:33:33 radon grsec: From 202.173.182.14: (default:D:/usr/sbin/sshd) denied open of /var/log/wtmp for writing by /usr/sbin/sshd[sshd:28609] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/sshd[sshd:5367] uid/euid:0/0 gid/egid:0/0
Feb  2 18:33:47 radon grsec: From 202.173.182.14: (default:D:/usr/sbin/sshd) denied open of /var/log/wtmp for writing by /usr/sbin/sshd[sshd:7421] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/sshd[sshd:5367] uid/euid:0/0 gid/egid:0/0


However the subject for sshd allows writing to this file:

Code: Select all

subject /usr/sbin/sshd dpo {
        /                               hs
        /bin/bash                       x
        /sbin/MAKEDEV                   rx
        /dev
        /dev/log*                       rw
        /dev/random                     r
        /dev/urandom                    r
        /dev/null                       rw
        /dev/ptmx                       rw
        /dev/pts                        rw
        /dev/tty                        rw
        /dev/tty?                       rw
        /dev/pty                        rw
        /etc                            r
        /etc/grsec                      h
        /home                           r
        /lib                            rx
        /root
        /proc
        /proc/kcore                     h
        /proc/sys                       hs
        /usr
        /usr/lib                        rx
        /usr/local/portage              r
        /usr/share/zoneinfo             r
        /var/empty
        /var/log
        /var/mail
        /var/log/lastlog                rw
        /var/log/wtmp                   w
        /var/run
        /var/run/sshd.pid               rwcd
        /var/run/utmp                   rw
        /var/lib/config_repository      h

        -CAP_ALL
        +CAP_CHOWN
        +CAP_SETGID
        +CAP_SETUID
        +CAP_SYS_CHROOT
        +CAP_SYS_RESOURCE
        +CAP_SYS_TTY_CONFIG
        +CAP_FOWNER
        +CAP_FSETID
        +CAP_NET_BIND_SERVICE
}


Another is tenshi trying to write to /var/lib/tenshi/tenshi.pid:

Code: Select all

Jan 31 23:16:29 radon grsec: From 202.173.182.14: (tenshi:U:/usr/sbin/tenshi) denied unlink of /var/lib/tenshi/tenshi.pid by /usr/sbin/tenshi[tenshi:13384] uid/euid:102/102 gid/egid:10017/10017, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 31 23:16:29 radon grsec: From 192.168.0.1: (tenshi:U:/usr/sbin/tenshi) denied open of /var/lib/tenshi/tenshi.pid for writing by /usr/sbin/tenshi[tenshi:1640] uid/euid:102/102 gid/egid:10017/10017, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 31 23:19:28 radon grsec: From 192.168.0.1: (tenshi:U:/usr/sbin/tenshi) denied unlink of /var/lib/tenshi/tenshi.pid by /usr/sbin/tenshi[tenshi:5451] uid/euid:102/102 gid/egid:10017/10017, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 31 23:19:28 radon grsec: From 192.168.0.1: (tenshi:U:/usr/sbin/tenshi) denied open of /var/lib/tenshi/tenshi.pid for writing by /usr/sbin/tenshi[tenshi:19623] uid/euid:102/102 gid/egid:10017/10017, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 31 23:28:29 radon grsec: From 192.168.0.1: (tenshi:U:/usr/sbin/tenshi) denied create of /var/lib/tenshi/tenshi.pid for writing by /usr/sbin/tenshi[tenshi:493] uid/euid:102/102 gid/egid:10017/10017, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0


And the tenshi ACL:

Code: Select all

role tenshi u
subject / o {
        /                               h

        -CAP_ALL

        bind disabled
        connect disabled
}

subject /usr/sbin/tenshi o {
        /                               h
        /usr                            h
        /usr/bin/tail                   x
        /usr/lib                        r
        /usr/sbin/tenshi                rx
        /usr/share/zoneinfo             r
        /var                            h
        /var/lib/tenshi
        /var/lib/tenshi/tenshi.pid*     rwcd
        /var/lib/config_repository      h
        /var/run
        /etc                            r
        /etc/grsec                      h
        /etc/ssh                        h
        /etc/shadow                     h
        /etc/passwd                     h
        /lib

        -CAP_ALL

        bind    disabled
        connect 127.0.0.1/32:25 stream tcp
}


As with /dev/log, putting the '*' after the /var/lib/tenshi/tenshi.pid fixed the issue.

If you give me a bit more detail on what you want with syslog-ng strace, I'll try and get that done asap.

Cheers,

Brad

Hello,
I experience the same behaviour on my server since we update to the latest stable version of grsec patch for 2.4.32 kernel and gradm.

Code: Select all

radon ~ # logger start
radon ~ # gradm -a admin
radon ~ # gradm -a admin
Password:
radon ~ # killall -HUP syslog-ng
radon ~ # gradm -u
radon ~ # logger "this will fail"


this gave the same thing on /dev/log but since it's a machine with many users, I can't gradm -D

Code: Select all

gradm -R


Leads to kernel panic and anyway the server kernel panic alone 24/48h after the first "strange" grsec message about /dev/log

If I can help any way ask me, but since I have a lot of user connected, I can't desactivate the rbac/reboot,...,

Thanks
Xavier

Hi xav4,

Upgrade to the latest patch in http://grsecurity.net/~spender. This fixed the problem for me and the person in this post:
http://forums.grsecurity.net/viewtopic.php?t=1412

Btw, running gradm -R should not result in a kernel panic. This sounds like another issue.

Cheers,

Brad

Hello Brad;
The upgrade of both grsec and gradm does not fix neither the /dev/log problem nor the kernel panic when gradm -R.

Xavier