grsecurity forums

Posted: **Sun Oct 09, 2011 2:38 pm**

Hi.
I have strange behavior of RBAC and /proc. /proc/sys/kernel/ngroups_max file blocked for unknown reason. It is allowed for reading in subjects, but kernel spends some time and then says that ngroups_max denied for reading/sysctl'ing. Why /proc/*/ngroups_max or something like this also fails? It is safe enough to ignore this? If so, how to get rid of this warnings in logs?
Thanks.

Posted: **Mon Oct 10, 2011 2:40 am**

When you are referring to an error message, please post the full log entry.

-Brad

Posted: **Mon Oct 10, 2011 3:44 am**

spender wrote:When you are referring to an error message, please post the full log entry.

-Brad

I'm sorry, I forgot to include log entry.
Here,

Oct 10 15:07:22 serv kernel: grsec: From 127.0.0.6: (root:U:/usr/sbin/httpd) denied access to hidden file /proc/sys/kernel/ngroups_max by /usr/sbin/httpd[httpd:5058] uid/euid:0/0 gid/egid:33/33, parent /usr/sbin/httpd[httpd:2707] uid/euid:0/0 gid/egid:0/0
Oct 10 15:37:20 serv kernel: grsec: From 127.0.0.6: (root:U:/usr/sbin/sshd) denied sysctl of /proc/sys/kernel/ngroups_max for reading by /usr/sbin/sshd[sshd:5067] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/sshd[sshd:2309] uid/euid:0/0 gid/egid:0/0

Posted: **Mon Oct 10, 2011 4:04 am**

what are your objects for /proc/* in the sshd subject of the root role?

-Brad

Posted: **Mon Oct 10, 2011 8:21 am**

spender wrote:what are your objects for /proc/* in the sshd subject of the root role?

-Brad

Code: Select all: /proc w /proc/bus h /proc/kallsyms h /proc/kcore h /proc/modules h /proc/slabinfo h /proc/sys/kernel/ngroups_max r

Posted: **Mon Oct 10, 2011 8:48 am**

I'm not able to reproduce your problem here, which makes me think there's something else wrong with your policy, or you pasted from something that isn't the correct subject.

-Brad

Posted: **Mon Oct 10, 2011 9:43 am**

spender wrote:I'm not able to reproduce your problem here, which makes me think there's something else wrong with your policy, or you pasted from something that isn't the correct subject.

-Brad

I'm now found I see this only on newer kernels (>2.6.32), so I can't reproduce it on one machine (longterm), but reproducible on 2.6.39 for example. Can you try to reproduce on 2.6.39.x? Thanks.

Posted: **Mon Oct 10, 2011 10:15 am**

I'm unable to reproduce it on the latest 3.0.4 patch either.

-Brad

Posted: **Wed Oct 12, 2011 4:08 pm**

I'm seeing this as well.

How can I help debug it? (You're welcome to remote into the machine if you wish, spender)

UID33 = Apache

Code: Select all: grsec: (root:U:/usr/sbin/cron) denied access to hidden file /proc/sys/kernel/ngroups_max by /usr/sbin/cron[cron:30036] uid/euid:0/0 gid/egid:33/33, parent /usr/sbin/cron[cron:30035] uid/euid:0/0 gid/egid:0/0 grsec: (root:U:/usr/sbin/cron) denied access to hidden file /proc/sys/kernel/ngroups_max by /usr/sbin/cron[cron:30036] uid/euid:0/0 gid/egid:33/33, parent /usr/sbin/cron[cron:30035] uid/euid:0/0 gid/egid:0/0 grsec: (root:U:/usr/sbin/cron) denied access to hidden file /proc/sys/kernel/ngroups_max by /usr/sbin/cron[cron:30129] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/cron[cron:30127] uid/euid:0/0 gid/egid:0/0 grsec: (root:U:/usr/sbin/cron) denied access to hidden file /proc/sys/kernel/ngroups_max by /usr/sbin/cron[cron:30129] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/cron[cron:30127] uid/euid:0/0 gid/egid:0/0 grsec: (root:U:/usr/sbin/cron) denied access to hidden file /proc/sys/kernel/ngroups_max by /usr/sbin/cron[cron:30130] uid/euid:0/0 gid/egid:33/33, parent /usr/sbin/cron[cron:30126] uid/euid:0/0 gid/egid:0/0 grsec: (root:U:/usr/sbin/cron) denied access to hidden file /proc/sys/kernel/ngroups_max by /usr/sbin/cron[cron:30130] uid/euid:0/0 gid/egid:33/33, parent /usr/sbin/cron[cron:30126] uid/euid:0/0 gid/egid:0/0 grsec: (root:U:/usr/sbin/cron) denied access to hidden file /proc/sys/kernel/ngroups_max by /usr/sbin/cron[cron:30220] uid/euid:0/0 gid/egid:33/33, parent /usr/sbin/cron[cron:30218] uid/euid:0/0 gid/egid:0/0 grsec: (root:U:/usr/sbin/cron) denied access to hidden file /proc/sys/kernel/ngroups_max by /usr/sbin/cron[cron:30220] uid/euid:0/0 gid/egid:33/33, parent /usr/sbin/cron[cron:30218] uid/euid:0/0 gid/egid:0/0

Policy

Code: Select all: role root uG role_transitions admin shutdown role_allow_ip <IP Blocks> role_allow_ip <IP Blocks> role_allow_ip 0.0.0.0/32 subject /usr/sbin/cron op { user_transition_allow www-data root group_transition_allow www-data root / h /bin h /bin/dash x /dev h /dev/log rw /etc r /etc/grsec h /etc/gshadow h /etc/gshadow- h /etc/ppp h /etc/samba/smbpasswd h /etc/shadow- h /etc/ssh h /lib rx /lib/modules h /proc h /proc/filesystems r /proc/sys/kernel/ngroups_max r /root /tmp rwcd /usr h /usr/sbin/sendmail x /var h /var/run/utmp r /var/spool/cron/crontabs /var/spool/cron/crontabs/root r /var/spool/cron/crontabs/tim r -CAP_ALL +CAP_DAC_READ_SEARCH +CAP_SETGID +CAP_SETUID +CAP_SYS_RESOURCE bind disabled connect disabled }

Posted: **Thu Oct 13, 2011 4:42 am**

What was the first patch that exhibited this problem for you? Is /proc/sys a symlink to anything on your system? Are you using any kind of namespace support?

-Brad

Posted: **Thu Oct 13, 2011 9:49 am**

spender wrote:What was the first patch that exhibited this problem for you? Is /proc/sys a symlink to anything on your system? Are you using any kind of namespace support?

-Brad

This started from 2.6.39.x kernel and patches (really I can't say when, I used 2.6.37.x before but without RBAC, now only longterm kernels and this one). I noticed inode changing on that file on 2.6.39.x. No any namespace support other than UTS and IPC.

Posted: **Thu Oct 13, 2011 1:19 pm**

Hi spender,

This is the first time I've started using the RBAC system. I've been a grsecurity user for many years, but only now have finally sat down to use RBAC.

So I can't answer the first kernel question sorry, but this is it! This kernel was compiled on Sept25th, so whatever grsec version was current then.

# CONFIG_NAMESPACES is not set

/proc/sys is not a symlink at all.

Posted: **Thu Oct 13, 2011 8:31 pm**

The inode changing would definitely cause it, though a rule like:
/proc/sys/kernel/ngroups_max* r
should work. You just need to have a /proc rule, and not a /proc/sys or /proc/sys/kernel rule (in case the inodes on those change too -- can you confirm?)

-Brad

Posted: **Thu Oct 13, 2011 9:14 pm**

spender wrote:The inode changing would definitely cause it, though a rule like:
/proc/sys/kernel/ngroups_max* r
should work. You just need to have a /proc rule, and not a /proc/sys or /proc/sys/kernel rule (in case the inodes on those change too -- can you confirm?)

-Brad

I'll see will it cause errors again, but I've seen inode change at least for other pseudofiles on /proc/sys/kernel directory.
- gradm required to have /proc/sys/kernel object before ngroups_max*.
update: I can confirm inode changes for /proc pseudofiles and directories on 2.6.39.x. There is no errors on longterm kernels.
/proc/sys/kernel/ngroups_max* r does not solves the problem on 2.6.39.x.

Posted: **Fri Oct 14, 2011 5:41 pm**

The way I currently deal with the problem is that when the error starts, I just reload the RBAC system. That stops it until it triggers again.
I haven't tried the globbing method.

grsecurity forums

/proc/sys/kernel/ngroups_max denied?

/proc/sys/kernel/ngroups_max denied?

Re: /proc/sys/kernel/ngroups_max denied?

Re: /proc/sys/kernel/ngroups_max denied?

Re: /proc/sys/kernel/ngroups_max denied?

Re: /proc/sys/kernel/ngroups_max denied?

Re: /proc/sys/kernel/ngroups_max denied?

Re: /proc/sys/kernel/ngroups_max denied?

Re: /proc/sys/kernel/ngroups_max denied?

Re: /proc/sys/kernel/ngroups_max denied?

Re: /proc/sys/kernel/ngroups_max denied?

Re: /proc/sys/kernel/ngroups_max denied?

Re: /proc/sys/kernel/ngroups_max denied?

Re: /proc/sys/kernel/ngroups_max denied?

Re: /proc/sys/kernel/ngroups_max denied?

Re: /proc/sys/kernel/ngroups_max denied?