Could not open /dev/grsec - Permission denied with gradm2

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

Could not open /dev/grsec - Permission denied with gradm2

Postby Polynomial » Sun Nov 28, 2010 5:52 pm

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?
Polynomial
 
Posts: 3
Joined: Sun Nov 28, 2010 5:47 pm

Re: Could not open /dev/grsec - Permission denied with gradm

Postby spender » Sun Nov 28, 2010 6:59 pm

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

Re: Could not open /dev/grsec - Permission denied with gradm

Postby Polynomial » Mon Nov 29, 2010 5:25 am

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
 
Posts: 3
Joined: Sun Nov 28, 2010 5:47 pm

Re: Could not open /dev/grsec - Permission denied with gradm

Postby d-b » Mon Nov 29, 2010 11:33 am

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
d-b
 
Posts: 1
Joined: Mon Nov 29, 2010 11:31 am

Re: Could not open /dev/grsec - Permission denied with gradm

Postby Polynomial » Tue Nov 30, 2010 7:54 am

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.
Polynomial
 
Posts: 3
Joined: Sun Nov 28, 2010 5:47 pm


Return to grsecurity support

cron