grsecurity forums

Hi,

For some time i'm having strange problems with wildcards in grsec policies.
For example the following policy:

Code: Select all

/home r
/home/* h
/home/users r
/home/users/* h
/home/users/username1 rwxcdl

Now when I do the following:

Code: Select all

[username1@host /home/users]$ ls
username1
[username1@host /home/users]$

Thats great, I only see my own homedir. But:

Code: Select all

[username1@host /home]$ ls
[username1@host /home]$

I dont see the users directory, not even when I set /home/users to rwxcdl in my policy. I can enter the directory though.

Any ideas about this behaviour?
Thnx in advance.

Vincent

i had some wildcard "strangeness" as well, until i took the approach to add any non-wildcard entries before the wildcard entries, thus:

Code: Select all

/home r
/home/users r
/home/users/username1 rwxcdl
/home/users/* h
/home/* h


I'll look into this. From what you've described, it seems to only involve gr_acl_handle_filldir() which makes use of some special handling.

-Brad

The way readdir lookups work is the inode for the entry in the directory you're listing is looked up in the RBAC policy (using the device number of the parent directory)
It begins with the specific subject for the binary and works back through subjects it inherits from if a match isn't found.

If a specific match for that file still isn't found, then a lookup is performed on the directory being listed. If for the match generated there is no attached globbed object (for instance, the globbed object /home/* gets attached to the /home object, since /home is the greatest static match for the object), then the results of that match are returned.

If for the match found there are attached globbed objects, as would be the case here due to the /home/* rule, then the full pathname for the file being looked up is generated and each of the attached globbed objects are matched against the filename. The first match determines the result.

If no match is found among the globbed objects, then the result is based off the match for the lookup of the directory being listed.

So, from this description, Your /home/users rule should have been matched at the very first inode/device check.

The only thing that I can think of that would cause a problem like the one you described would involve mountpoints. If the directory according to the readdir call had to do with /home as it exists on the / filesystem instead of the root of the filesystem mounted at /home, then the wrong device number might be used for the check. If you can mail me at spender@grsecurity.net and give me a list of mountpoints on your system, I can give you some things to add to your kernel to help debug the problem.

-Brad

Thanks for looking into my problem.

/home is on the root filesystem, but /home/users is a mounted nfs share. Maybe that has something to do with this?
I'll mail you the info.

Vincent

Ok, it looks like a known behavior I've mentioned earlier on the forums. It's not possible to change the hide/show status on mountpoints due to the kind of information about the filesystem we have in a generic sense at the time of the readdir() call. The reason for this is that a stat on /home/users will return the root inode of the /home/users mount, whereas when doing a readdir on /home, the inode for the "users" directory will be one residing on the device /home exists on. Since the RBAC system doesn't have a notion of multiple inodes for a single filename, it can't know that they have the same pathname and should be treated the same.

As noted before, this is a special case that applies only to hiding mountpoints. All other policies are unaffected by being applied to mountpoints. Also, you can workaround this problem by using wildcards, since they are matched against the full pathname and not inode/device numbers. A rule like /home/users* r instead of /home/users r should do the trick.

Let me know if the wildcard rule doesn't fix the problem for you.
-Brad