/proc/sys/kernel/ngroups_max denied?

[Undine]

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.

[spender]

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

-Brad

[Undine]

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

[spender]

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

-Brad

[Undine]

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


[spender]

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

[Undine]

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.

[spender]

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

-Brad

[tjh]

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
}


[spender]

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

[Undine]

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.

[tjh]

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.

[spender]

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

[Undine]

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.

[tjh]

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.