grsecurity forums

I love RBAC and find it very straightforward to configure (albeit time consuming). However the one problem which I keep running into and which causes my policies to be far less secure than they should be is the lack of recursive globbing. For example, if I need to allow a program to read to any file with a certain extension under a specific directory with RBAC regardless of the subdirectory it is in, I cannot do it like this like I could in zsh or apparmor:

Code: Select all

/home/myname/**/*.png r


If I wanted it to be recursive, I would have to do something like this:

Code: Select all

/home/myname/*.png r
/home/myname/*/*.png r
/home/myname/*/*/*.png r
/home/myname/*/*/*/*.png r
...
/home/myname/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*.png r


Not only is that very sloppy and would make the policy incredibly long, but it would only work up to so many subdirectories, and I don't like relying on assumptions that an object I want to match is only so many subdirectories deep.

If globbing support doesn't exist, is there any chance it would be a feature that could be added in the future? I can't imagine it would be too difficult to implement in gradm itself, but my understanding of C is too limited to patch it.

If no one has the time to add the feature, I'd appreciate it if someone could at least point me in the right direction and tell me how such a thing would be implemented. The two possibilities I see are 1) add support in the kernel side of things, which would require paths to be resolved at each access (which might be fundamentally impossible with the RBAC architecture, I don't know), or 2) add support to gradm_analyze.c, so that when it encounters a **, it sends a series of commands to /dev/grsec to enable */, then */*/, then */*/*/, etc (basically having ** acting like an alias for the really long recursive globbing example above). I imagine #2 would be much easier?

Hi,

I think this is possible -- our glob handling is a little unusual for performance reasons. Internally each globbed object is "anchored" to a most-specific non-globbed object for lookups, so when walking down the directory heirarchy looking for matches, we'll first match on non-globbed objects (which we deem to be more specific). So a naive implementation would result in some problems with the following series of rules:

/blah
/blah/**/*.png r
/blah/blah2

Here if /blah/blah2/blah3.png were accessed, we'd check for a specific object for it (which doesn't exist), then look for a /blah/blah2 object (which we'll find). Then we'll look for any globbed objects attached to that object (which won't exist) and we'll simply match on /blah/blah2. What would need to happen is we would need to take the *.png and attach it as an object to each more-specific directory object. I think this creates some corner-case problems though, particularly where *.png is being appended as a file existing in what we don't know to be a directory necessarily. It may be that these cases are rare and uninteresting, but I'd have to give it some thought.

-Brad