Abnormal behaviour of RBAC system

Discuss usability issues, general maintenance, and general support issues for a grsecurity-enabled system.

Abnormal behaviour of RBAC system

Postby bplant » Sat Jan 28, 2006 11:25 pm

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
bplant
 
Posts: 73
Joined: Sat May 28, 2005 10:36 pm

Postby spender » Tue Jan 31, 2006 7:47 am

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

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Postby bplant » Tue Jan 31, 2006 8:29 am

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
bplant
 
Posts: 73
Joined: Sat May 28, 2005 10:36 pm

Postby spender » Tue Jan 31, 2006 10:30 pm

What was the filename of the grsecurity patch you applied?

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Postby bplant » Tue Jan 31, 2006 11:54 pm

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
bplant
 
Posts: 73
Joined: Sat May 28, 2005 10:36 pm

Postby spender » Wed Feb 01, 2006 12:05 am

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
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Postby spender » Thu Feb 02, 2006 7:38 am

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
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Postby bplant » Fri Feb 03, 2006 3:31 am

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 :wink:

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
bplant
 
Posts: 73
Joined: Sat May 28, 2005 10:36 pm

Postby xav4 » Thu Mar 09, 2006 2:59 pm

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
Last edited by xav4 on Sun Mar 12, 2006 9:03 am, edited 1 time in total.
xav4
 
Posts: 2
Joined: Thu Mar 09, 2006 2:48 pm

Postby bplant » Thu Mar 09, 2006 5:46 pm

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
bplant
 
Posts: 73
Joined: Sat May 28, 2005 10:36 pm

Postby xav4 » Fri Mar 10, 2006 3:17 pm

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
xav4
 
Posts: 2
Joined: Thu Mar 09, 2006 2:48 pm


Return to grsecurity support

cron