grsecurity forums

Debian 6.0.3 system.

I have a problem when I have my RBAC policy enabled that logrotate doesn't work properly.

Firstly, there's no denies in the log to help me with this, thus my frustration.

What it'll do it move /var/log/syslog to /var/log/syslog.1 as it's supposed to, it also creates a new /var/log/syslog. But this file stays empty and it keeps writing to the /var/log/syslog.1 file, until I restart it.

If I don't have the RBAC system enabled - it works fine.

Does anyone have any clues/pointers as to how I could track this down? The lack of any grsec deny messages is what's really bugging me.

Can you paste the logrotate subject?

-Brad

Code: Select all


subject /usr/sbin/logrotate o {
        /                               r
        /bin                            h
        /bin/dash                       x
        /bin/gzip                       x
        /boot                           h
        /dev/grsec                      h
        /dev/kmem                       h
        /dev/log                        h
        /dev/mem                        h
        /dev/port                       h
        /etc                            r
        /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
        /lib                            rx
        /lib/modules                    h
        /lib64/modules                  h
        /proc                           h
        /proc/filesystems               r
        /selinux
        /sys                            h
        /usr                            h
        /usr/lib/gconv/gconv-modules.cache      r
        /usr/lib/locale/locale-archive  r
        /usr/sbin/logrotate             rx
        /var                            h
        /var/lib                        h
        /var/lib/logrotate/status       rw
        /var/log                        rwcd
        +CAP_ALL
        bind    disabled
        connect disabled
        sock_allow_family all
}


I haven't allowed hardlinking for /var/log, because this is what was learnt and I'm not seeing errors.

I think the problem is not necessarily with logrotate, but that rsyslog (is that the syslog you're using?) wasn't reloaded successfully. On my system, logrotate will issue a reload of rsyslog which will happen via a kill(pid, SIGHUP). rsyslog will then reopen /var/log/syslog. The fact that syslog is still logging to the .1 file, which is a rename()'d version of the old /var/log/syslog shows this. Does the problem still happen if you change the system date (date -s "Jan 1 2012") while in admin mode and run strace -f logrotate /etc/logrotate.conf ? If not, could you add a subject for strace:

subject /usr/bin/strace tr


It'll need some tweaking, but what I really need to see is the results of an strace while RBAC is enabled.

-Brad

I am using rsyslog, yea.

This is my subject:

Code: Select all

# role: root
subject /usr/sbin/rsyslogd dhop {
        /                               h
        /dev                            h
        /dev/log                        wd
        /dev/xconsole                   rw
        /etc                            h
        /etc/ld.so.cache                r
        /lib                            h
        /lib/libgcc_s.so.1              rx
        /var                            h
        /var/log                        a
        /var/run/rsyslogd.pid           wd
        /var/spool/postfix/dev/log      wd
        -CAP_ALL
        bind    disabled
        connect disabled
}


I'm wondering if the /var/log a might be the problem? That's what was learnt, but wouldn't I also need maybe a "w" or a "c" there?

Logrotate creates the new /var/log/syslog prior to restarting rsyslog, not rsyslog itself.

-Brad

Hmmm Ok.

I'm loath to do the time thing on this server as it'll mess up all the logs. I will try adding the "k" mode to logrotate though, so it can properly send signals to rsyslog (which is protected)

Hopefully this'll fix it, I'll report back.

If it was due to rsyslog being a protected task, the denied signal would have been logged (and you said there were no logs).

-Brad

Good point.
Ok, I'll keep looking, try some of your suggestions and get back to you.

Thanks for the assistance.

Tim

I noticed you also have 'h' in the subject mode. IIRC the restart script will access /proc/pid/status based on the pidfile for rsyslog. 'h' would prevent this and not be logged. You should just remove the 'h' really from rsyslog, otherwise you'll have to add 'v' to logrotate and also add inheritance object modes to objects in the logrotate subject so that all the shell scripts it executes can view rsyslog. Problem solved I think

-Brad

Ahh. Yes, that would make sense.

Thanks! I'll report back.

Working like a charm now.

Thanks.

Well, this is embarrassing.
I just searched for this problem and look who's had it previously and had it answered.

I'm such a muppet.