grsecurity forums

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


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.

Do you see any relevant logs in dmesg?

Code: Select all

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


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.