Error writing to /proc/sys/kernel/grsecurity/acl (Not below)

[666]

Hello,

I am getting:

[root ~/gradm]# gradm -a
Password:
Error writing to /proc/sys/kernel/grsecurity/acl
write: Invalid argument

[root ~/gradm]# cat /proc/sys/kernel/grsecurity/acl
cat: /proc/sys/kernel/grsecurity/acl: Operation not permitted

[root ~/gradm]# ls -fal /proc/sys/kernel/grsecurity/acl
-rw------- 1 root root 0 Jan 5 10:10 /proc/sys/kernel/grsecurity/acl

Grsecurity is configured with HIGH option. Actually, I have tried all options and the above error is present in all kernel compiles. Password is correct.

When I log in as a normal user and do ps, it shows only the processors belonging to the user. Also logs are there so grsec works.

When I run nmap:

[root /etc/grsec]# nmap -O localhost

Starting nmap V. 3.00 ( http://www.insecure.org/nmap/ )
Interesting ports on localhost.localdomain (127.0.0.1):
(The 1600 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
Remote operating system guess: Linux Kernel 2.4.0 - 2.5.20
Uptime 0.024 days (since Sun Jan 5 08:45:59 2003)

Nmap run completed -- 1 IP address (1 host up) scanned in 7 seconds

Why does nmap show the OS correctly when grsec is installed? Isn't grsec supposed to confuse OS guessing?

There was a similiar post below but it did not solve my problem. Sorry for repeating.

OS is Redhat 8.0, latest grsec with kernel 2.4.20. No patches applied to the kernel except the grsec patch.

Thanks!

Jimmy

[cmouse]

hmm... i've had this error too. I'm not sure, it could be a flaw in the gradm software or then not. I got it working by stabbing the gradm code. (not posting source here as it's insecure as hell).

The 'normal user' problem:

That is default behaviour that users not belonging to trusted group (if enabled in kernel, you most likely have allowed this for root only) can only see their OWN processes. If you want this user to see all processes(i can't see any reason for it) you need to add this user to the trusted group. You can do this with usermod ('man usermod' for details). The user must log in again after being added to the group.

The OS fingerprinting problem:

grsecurity kernel by default won't hinder OS fingerprinting. To achieve this, you need to use the 'stealth' iptables module and/or following grsecurity options (if you have sysctl support enabled, they are not enabled per default, path is /proc/sys):

kernel/grsecurity/rand_rpc = 1
kernel/grsecurity/altered_pings = 1
kernel/grsecurity/rand_ip_ids = 1

Enable these and it will make OS fingerprinting harder. And you make it even harder, by using this in iptables (assuming you have stealth support compiled)
iptables -A INPUT -j DROP -ptcp -m stealth
iptables -A INPUT -j DROP -pudp -m stealth

These will ensure your PC will not be identified with -O option. (the iptables is optional and shouldn't be required for hindering -O...)

[Sharky]

did the same
result " nothing"
any one can still scan and detect your OS remotely.
even with stealth mode support
I know the reason do you ?

[msi]

did the same
result " nothing"
any one can still scan and detect your OS remotely.
even with stealth mode support
I know the reason do you ?

so, what is it?