configure grsecurity post-compile

[mvandemar]

I have a vps which apparently has grsecurity compiled on it, but it doesn't look like it was ever configured:

Code: Select all

[~]# sysctl -a | grep grs
kernel.grsecurity.audit_ptrace = 0
kernel.grsecurity.chroot_deny_chmod = 0
kernel.grsecurity.chroot_deny_chroot = 0
kernel.grsecurity.chroot_deny_fchdir = 0
kernel.grsecurity.chroot_deny_mknod = 0
kernel.grsecurity.chroot_deny_mount = 0
kernel.grsecurity.chroot_deny_pivot = 0
kernel.grsecurity.chroot_deny_shmat = 0
kernel.grsecurity.chroot_deny_sysctl = 0
kernel.grsecurity.chroot_deny_unix = 0
kernel.grsecurity.chroot_enforce_chdir = 0
kernel.grsecurity.dmesg = 0
kernel.grsecurity.grsec_lock = 0
kernel.grsecurity.harden_ptrace = 0
kernel.grsecurity.signal_logging = 0
kernel.grsecurity.timechange_logging = 0
kernel.osrelease = 3.8.13-xxxx-grs-ipv6-64-vps


I tried setting some of them, eg. "sysctl -w kernel.grsecurity.chroot_deny_fchdir=1", but when I rebooted they reverted back to the original settings. Is there a way for me to configure these persistently?

The reason I am trying to do so is because I am having issues with cpanel-dovecot-solr, and the cpanel team is telling me that they believe that it is due to grsecurity being installed but not configured. Is there a way to unpatch my kernel? Is grsecurity even doing anything if all of the settings are 0? Is there a known issue with grsecurity and cpanel-dovecot-solr, and do you guys know of any workarounds if so?

Thanks.

-Michael

[spender]

To set sysctls at startup, you can add them to /etc/sysctl.conf, in the same format that sysctl -a shows you.

3.8 is a very old kernel that we don't support -- it's almost certainly vulnerable to DirtyCoW and a number of other privilege escalation vulns, especially with no grsecurity features actually being enabled. We've never heard of any incompatibilities with cpanel-dovecot-solr though, and it's unlikely that there would be any with grsecurity features being disabled. Do you see any relevant logs in dmesg?

-Brad

[mvandemar]

To set sysctls at startup, you can add them to /etc/sysctl.conf, in the same format that sysctl -a shows you.

Thank you, I will try that and see if it helps.

3.8 is a very old kernel that we don't support -- it's almost certainly vulnerable to DirtyCoW and a number of other privilege escalation vulns, especially with no grsecurity features actually being enabled.

It appears to be a custom kernel from my host, OVH, which I didn't realize. The update mirrors are their own servers, and there are no updates available. I will ask them about the vulnerabilities, thank you for that.

Do you see any relevant logs in dmesg?

Nothing:

Code: Select all

[~]# dmesg | grep dovecot
[~]# dmesg | grep grs
[    0.000000] Linux version 3.8.13-xxxx-grs-ipv6-64-vps (kernel@kernel.ovh.net) (gcc version 4.7.2 (Debian 4.7.2-5) ) #3 SMP Fri May 31 13:29:13 CEST 2013


-Michael

[mvandemar]

I just heard back from one of the cpanel techs and this is what they said:

Your issue appears to be a complication of multiple factors. The direct cause is the script used to configure iptables to only allow access to the Solr socket to the root user and the cpanelsolr user:


[01:42:45 ns1 root@8394429 ~/cptechs]cPs# iptables -nvL
Chain INPUT (policy ACCEPT 2759 packets, 282K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 2314 packets, 1435K bytes)
pkts bytes target prot opt in out source destination
2455 1443K cpanel-dovecot-solr all -- * * 0.0.0.0/0 0.0.0.0/0

Chain cpanel-dovecot-solr (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport sports 8984,7984 owner UID match 494
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport sports 8984,7984 owner UID match 0
141 8420 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport sports 8984,7984 reject-with icmp-port-unreachable


I suspect that grsec is breaking the detection used by the kernel to match network connection to UID, as the connection attempts are not being caught by the second rule under the cpanel-dovecot-solr chain. Stopping the cPanel-provided script for starting Solr from adding these rules to iptables allows Solr to be recognized as working. I further suspect that other kernel settings are causing the kernel to not issue the ICMP response to connection attempts, causing the connection attempt to time-out instead of simply exiting immediately with a clear error.

As a temporary workaround, I have left the Solr start-up script in a state that prevents adding the firewall rules. This does open up Solr to potential local brute-force attacks, but the service is still password-protected, so a local attacker would still have to crack that password before they could gain access to the index containing email data.

Please let us know what grsec has to say about the iptables UID match seeming to not function properly.

Thoughts?

-Michael

[spender]

Grsec wouldn't affect that at all.

-Brad