grsecurity forums

I've compiled grsec and installed it fine, and /dev/grsec exists. I tried to run make install for gradm2 but it failed with "Could not open /dev/grsec - Permission denied". I tried chmodding it to 777 for testing, same issue. I "fixed" the make install by modifying the makefile to change DESTDIR to /grsec and that installed, but I get the same error when trying to use gradm.

If the system automatically enables the security patches and can run securely without using gradm then I'd be happy to just drop this issue. But it is confusing. Ideas?

Are you using grsecurity 2.2.1 with gradm 2.2.1 both obtained from grsecurity.net? Are there any kernel logs associated with the error? What does uname report for the kernel version?
This could be associated with running make install for gradm when a grsecurity kernel is not currently running.

-Brad

It seems grsec isn't running. This is odd.

I compiled ok, installed the .deb packages in / and copied across the vmlinuz file. I've rebooted and verified that /boot/vmlinuz file is in fact the correct one:

Code: Select all

vps:/boot# md5sum vmlinuz
1a132383ef328f692e7db649a2c83165  vmlinuz
vps:/boot# md5sum vmlinuz-2.6.32.26-grsec
1a132383ef328f692e7db649a2c83165  vmlinuz-2.6.32.26-grsec

For some reason when I do uname -R I get 2.6.18-128.1.1.el5.028stab062.3 instead of my newer kernel.

Any idea what I'm doing wrong?

Polynomial wrote:It seems grsec isn't running. This is odd.

I compiled ok, installed the .deb packages in / and copied across the vmlinuz file. I've rebooted and verified that /boot/vmlinuz file is in fact the correct one:

Code: Select all

vps:/boot# md5sum vmlinuz
1a132383ef328f692e7db649a2c83165  vmlinuz
vps:/boot# md5sum vmlinuz-2.6.32.26-grsec
1a132383ef328f692e7db649a2c83165  vmlinuz-2.6.32.26-grsec

For some reason when I do uname -R I get 2.6.18-128.1.1.el5.028stab062.3 instead of my newer kernel.

Any idea what I'm doing wrong?

Clearly your vps is using the kernel of the host (xen I assume). If the vps provider supports using your own kernel through pvgrub then you perhaps need to generate an appropriate menu.lst file

I spoke to them, they don't offer it. So I'm moving.

I've now got grsec working on my Debian VM, but there's a problem. After the patch, iptables stopped working:

Code: Select all

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT -p tcp --dport 22 -j ALLOW
iptables -A INPUT -p tcp --dport 80 -j ALLOW
iptables -A INPUT -p udp --sport 53 -j ALLOW
iptables -A OUTPUT -p tcp --sport 22 -j ALLOW
iptables -A OUTPUT -p tcp --sport 80 -j ALLOW
iptables -A OUTPUT -p udp --dport 53 -j ALLOW
iptables -N synflood_ban
iptables -A INPUT -p tcp -m tcp -m state --state NEW -j synflood_ban
iptables -A synflood_ban -m recent --set --name SYNCOUNT --rsource
iptables -A synflood_ban --update --seconds 30 --hitcount 20 --name SYNCOUNT --rsource -j DROP

Everything works until the last two lines, which both report "No chain/target/match by that name". I've checked iptables --list and it shows synflood_ban with one reference. My friend's Debian machine runs those rules perfectly well. I checked my iptables version, it's up to date.

Update: To make matters more confusing, 'iptables -A synflood_ban -p tcp --dport 1234 -j DROP' works fine.
Update 2: This occurs with or without the gradm iptables patch.