grsecurity forums

There seems to be an information leakage introduced in current versions of grsecurity-2.1.0 (as published until 01/08/05):

As usual, I've placed a rule in my RBAC default policy to hide /etc/grsec, but it is not hidden completely as it was in grsecurity-2.0.1 (Linux 2.6.7) and grsecurity-2.0.2 (Linux 2.4.28).

I've tried the following commands on with Linux 2.4.28 and 2.6.10 together with grsecurity-2.1.0:

cd /etc
ls

The directory /etc/grsec is not visible in the directory listing, but an access attempt to the hidden directory has been logged (unwanted behaviour, since /etc/grsec was not accessed directly):

grsec: (default:D:/) denied access to hidden file /etc/grsec by /bin/ls[ls:17206] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:25250] uid/euid:0/0 gid/egid:0/0

Also, you are able to find out that /etc/grsec exists, if you use the filename completion of bash. Type in "ls /etc/g" + [Tab] to check that - /etc/grsec is visible in the completion list.

As expected, other commands (like "cd /etc/grsec") fail to access the hidden directory, so I assume that there may be something wrong in the way the ACLs are processed in system calls like readdir.

Any suggestions?

It's the readdir code in grsec that is at fault. Unfortunately, the filldir callbacks in the kernel don't provide me with enough information to do regular lookups as I do elsewhere. I'm writing code now that will hopefully eliminate the problem.

-Brad

Take a look at current CVS. The issue is resolved from my tests.

-Brad

First of all: Thanks for your fast answer and apologies for the bad format of my posting.

The changes you've made in the CVS (fs/readdir.c + gr_acl_handle_filldir()) solved the problem (tested with Linux 2.6.10).

I'm really sorry, but I think, I've found two other issues while testing your code fixes:

1. Linux 2.4.28 + grsecurity-2.1.0-2.4.28-200501051112 (at least with no changes from CVS applied):

There is a rule in my default policy which hides /proc/kcore. But it is still visible (try "ls /proc" and it's there).

2. Linux 2.6.10 + grsecurity-2.1.0-2.6.10-200501081640 (with or without the changes you've made in the CVS):

As above, there is a rule to hide /proc/kcore.

I've started xosview-1.8.2, which reads data from several files in /proc and tried:

cd /proc
ls kcore

xosview crashed!

Logged messages:

- as expected:

grsec: (default:D:/) denied access to hidden file /proc/kcore by /bin/ls[ls:3934] uid/euid:1001/1001 gid/egid:16/16, parent /bin/bash[bash:18508] uid/euid:1001/1001 gid/egid:16/16

- unexpected, because /proc/stat was not hidden (xosview relies on that):

grsec: (default:D:/) denied access to hidden file /proc/stat by /usr/X11R6/bin/xosview.bin[xosview.bin:720] uid/euid:1001/1001 gid/egid:16/16, parent /usr/X11R6/bin/fvwm[fvwm:1167] uid/euid:1001/1001 gid/egid:16/16

I've executed "ls /proc" consecutively and got similar log messages (replace xxxx by any file you find in /proc).

grsec: (default:D:/) denied access to hidden file /proc/xxxx by /bin/ls[ls:3934] uid/euid:1001/1001 gid/egid:16/16, parent /bin/bash[bash:18508] uid/euid:1001/1001 gid/egid:16/16

Possible impact: Users may be able to harm any processes, which rely on the readability of files in /proc.

I hope, you can reproduce and fix this also.

-vs

Can you try 2.1.1 available from http://grsecurity.net/~spender ?
I believe your problem is related to the caching in 2.1.0.

-Brad

Both issues (Linux 2.4.28 + 2.6.10) are fixed in grsecurity-2.1.1.

Thanks.

I have this problem with grsec 2.1.1 and kernel 2.4.29:

# ls /bo*
ls: /boot: No such file or directory

# echo /bo*
/boot

(boot is supposed to be hidden)

Same with find: find / will make an error for /boot, /dev/mem, etc.

Can you show me a paste of the output for it failing on /dev/mem? Mountpoints can't really be hidden (and the user could find out they exist from other methods, such as /proc/self/mounts) so /boot being visible with filldir is a known issue.

-Brad

spender wrote:Can you show me a paste of the output for it failing on /dev/mem?

It looks like an inheritance problem, because I don't have this specific problem since I have put
/boot h
/etc/grsec h
/etc/ssh h
/initrd h
/dev/grsec h
/dev/mem h
/dev/kmem h
/dev/port h
/dev/log h
in find and shell subjects.

However, same problem, I've just had this:
kernel: grsec: (root:U:/usr/lib/tiger/scripts/sub/check_embed) denied access to hidden file /dev/grsec by /usr/lib/tiger/scripts/sub/check_embed[check_embed:9199] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/tiger/scripts/sub/check_embed[check_embed:26960] uid/euid:0/0 gid/egid:0/0

Same error to access /boot... Maybe for /dev/mem too but it does not appear in the logs (kernel: grsec: more alerts, logging disabled for 10 seconds).

In my policy file, here is the subject for check_embed:
subject /usr/lib/tiger/scripts/sub/check_embed {
/bin/ls x
/boot r
/boot/* r
/initrd r
}
subject /usr/lib/tiger/scripts/check_perms:/bin/ls

(/dev/grsec is hidden in the / subject)

Hi,

i've the same problem and i've "solved" by placing /etc +h on /bin/bash object, something like:

Code: Select all

subject /bin/bash o {
   /
   .....
   /etc                        h
   ....
}


in this way i can't see any file inside /etc using "autocomplete" function.

hope this help.
bye!

ujaku