grsecurity forums

I'm often getting denied errors like:

Code: Select all

grsec: (users:G:/usr/bin/php5-cgi) denied open of /proc/22684/mounts for reading by /usr/bin/php5-cgi[php-cgi:22684] uid/euid:1356/1356 gid/egid:100/100, parent /usr/sbin/apache2[apache2:21604] uid/euid:33/33 gid/egid:33/33
grsec: (users:G:/usr/bin/php5-cgi) denied open of /proc/22684/mounts for reading by /usr/bin/php5-cgi[php-cgi:22684] uid/euid:1356/1356 gid/egid:100/100, parent /usr/sbin/apache2[apache2:21604] uid/euid:33/33 gid/egid:33/33
grsec: From 31.7.62.152: (users:G:/usr/bin/php5-cgi) denied open of /proc/23088/mounts for reading by /usr/bin/php5-cgi[php-cgi:23088] uid/euid:1356/1356 gid/egid:100/100, parent /usr/sbin/apache2[apache2:22995] uid/euid:33/33 gid/egid:33/33
grsec: From 31.7.62.152: (users:G:/usr/bin/php5-cgi) denied open of /proc/23088/mounts for reading by /usr/bin/php5-cgi[php-cgi:23088] uid/euid:1356/1356 gid/egid:100/100, parent /usr/sbin/apache2[apache2:22995] uid/euid:33/33 gid/egid:33/33


I also sometimes (but much rarer) see:

Code: Select all

(users:G:/) denied open of /proc/filesystems for reading by /usr/bin/id[id:xxxx] uid/euid:1346/1346 gid/egid:100/100
(users:G:/) denied open of /proc/filesystems for reading by /usr/bin/id[id:xxxx] uid/euid:1321/1321 gid/egid:100/100,


It happens on several users and on various commands, but not all the time. I have disabled most of the access on /proc on that group, and all /proc/$PID accesses.
Is that a sign of break-in attempts, or are those users just triggering some rarely used features? I though it was break-in, but looking at most of their directories couldn't find anything to imply that (except on one user which indeed had been php-broken), and then I found:

Code: Select all

% strings  /lib/libc.so.6 | grep /maps
/proc/self/maps
% strings /lib/libselinux.so.1    | grep /filesystems
/proc/filesystems


It is standard Debian Stable (apart from grsec kernel). Why should selinux (which is not used/enabled on the system, BTW) be opening /proc/filesystems, and even more why should libc be opening /proc/self/maps for programs like mv(1) and such? And how should that be handled in grsec policy? I could just deny them as I do currently (is there any downside? I could suppress messages if they are unimportant of course). Or do they serve some purpose? I'm not very comfortable with generally enabling access to /proc/$pid/maps to potentially hostile users unless there is a reason to do it.

(grsec there is currently 2.6.32.45-grsec20110828)

Glibc's format string protection code involves reading /proc/self/maps.

Giving access to /proc/self/maps shouldn't be a problem unless you're not using the /proc restrictions and are worried about users of the same uid being able to see the files mapped in a given process (though still not able to see the mapped addresses if the maps/stat protection is enabled).

In the future I plan to implement a way to represent /proc/self in policy such that it will expand at runtime to the target of the /proc/self symlink.

-Brad

I find a lot of stuff looks at /proc/self/mounts and /proc/filesystems and is pretty benign. New kernels (or at least newer Debian systems) seem to hit /proc/sys/kernel/ngroups_max constantly (though I usually need to do /proc/s*s/kernel/ngroups_max, since somehow the reference to /proc/sys or /proc/sys/kernel -- not sure which -- seems to change, at least to grsec's perspective). You can always hide it, if you don't want to see it in the logs.

spender wrote:Glibc's format string protection code involves reading /proc/self/maps.

Giving access to /proc/self/maps shouldn't be a problem unless you're not using the /proc restrictions and are worried about users of the same uid being able to see the files mapped in a given process (though still not able to see the mapped addresses if the maps/stat protection is enabled).

I do have CONFIG_GRKERNSEC_PROC_MEMMAP=y enabled, but it seems to me that it allows reading adresses and stuff in /proc/self/maps, for example:

Code: Select all

# cat /proc/self/maps
00400000-00408000 r-xp 00000000 09:0c 2240272                            /bin/cat
00607000-00608000 rw-p 00007000 09:0c 2240272                            /bin/cat
00608000-00635000 rw-p 00000000 00:00 0                                  [heap]
2987efbe000-2987f108000 r-xp 00000000 09:0c 736278                       /lib/libc-2.7.so
2987f108000-2987f307000 ---p 0014a000 09:0c 736278                       /lib/libc-2.7.so
2987f307000-2987f30a000 r--p 00149000 09:0c 736278                       /lib/libc-2.7.so
2987f30a000-2987f30c000 rw-p 0014c000 09:0c 736278                       /lib/libc-2.7.so
[...]


but when I try to see some other instance of /bin/cat binary, it seems sanitized:

Code: Select all

# cat /proc/1703/maps
00000000-00000000 r-xp 00000000 09:0c 2240272                            /bin/cat
00000000-00000000 rw-p 00000000 09:0c 2240272                            /bin/cat
00000000-00000000 rw-p 00000000 00:00 0                                  [heap]
00000000-00000000 r-xp 00000000 09:0c 736278                             /lib/libc-2.7.so
00000000-00000000 ---p 00000000 09:0c 736278                             /lib/libc-2.7.so
00000000-00000000 r--p 00000000 09:0c 736278                             /lib/libc-2.7.so
00000000-00000000 rw-p 00000000 09:0c 736278                             /lib/libc-2.7.so
[...]


Is that expected behaviour, i.e. will allowing possible attacker to read all those addresses where is something mapped in /proc/self give attacker any help?

In the future I plan to implement a way to represent /proc/self in policy such that it will expand at runtime to the target of the /proc/self symlink.

-Brad

Oh, ok, so currently allowing access to just /proc/self/maps won't work correctly until that patch is made, right?

So I just should add:

Code: Select all

/proc/*/maps r
/proc/*/filesystems r
/proc/*/mounts r


to that role default subject, and all would be ok (with no holes introduced)?

Thanks!

A process is always allowed to access its own maps file, unless you prevent it with RBAC. I don't recommend this, since as I mentioned earlier, this access is required for some protection code in glibc. What you pasted is therefore expected behavior.

-Brad