Files and directory not fully hidden in grsecurity-2.1.0?

[vs]

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?

[spender]

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

[spender]

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

-Brad

[vs]

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

[spender]

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

[vs]

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

Thanks.

[mikael]

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.

[spender]

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

[mikael]

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)

[ujaku]

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