hidden files visible

[glaeken]

Kernel 2.4.29 grsec 2.1.1 (downloaded yesterday)

strace log of midnight commander:

getcwd("/", 4095) = 2
stat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
lstat64("/lost+found", {st_mode=S_IFDIR|0755, st_size=16384, ...}) = 0
lstat64("/bin", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/boot", 0xbffff1e0) = -1 ENOENT (No such file or directory)

"boot" dir is visible as "?boot" even for normal users with ACL turned ON
I have many other directories (not mount points) which behave the same way.

Earlier version of grsec didn't behave like this.
Maybe someone had the same problem?
TIA

[spender]

Visible mountpoints are a known issue. Users could get that information from other places like /proc/self/mounts. It causes a problem with the RBAC system since it allows for two inodes to match the same path (the directory on the parent filesystem, and the root of the filesystem mounted in that directory resolve to the same filename).

-Brad

[glaeken]

I have boot on / and it is not a mount point, sory for wrong description.
Even files are visible this way, i.e. /etc/shadow

[spender]

I'll have to see your policy and an strace of the application that is able to view the hidden files. In the strace you pasted, the process can't have any knowledge of /boot since it never does a readdir/getdents. When it tries to stat /boot, it gets the correct error: -ENOENT.

-Brad

[glaeken]

Every process(subject) which has a flag "O" is able to see hidden files, that's why mc saw my hidden files, I tested it on "ls" and if it gets O then hidden files are visible (but they return -ENOENT anyway)

Is this a correct behavior?

[spender]

That's not correct behavior. The interesting thing is that the subject flag for "O" is the same numerical value as the object flag for the find operation, which would suggest that somewhere a subject lookup is being done instead of an object lookup. Can you mail your policy file to spender@grsecurity.net so I can try to replicate this problem?

-Brad