grsecurity forums

Hi,

I have constant problem with RBAC forgotting objects after package update. For example with git on gentoo. After upgrade I am keep getting

Code: Select all

grsec: From xx.xx.xx.xx: (piotr:U:/bin/zsh) denied access to hidden file /usr/bin/git by /bin/zsh[zsh:6219] uid/euid:1000/1000 gid/egid:100/100, parent /bin/zsh[zsh:6212] uid/euid:1000/1000 gid/egid:100/100

Even that I do have access to object /usr/bin/git in subject / of user role piotr. Same goes for perl. The Portage's TMPDIR is located on another file system so it does not use rename(), so its not connected to the proc's 'exe' symlink that's broken upstream.

It seems to be closely connected to hardlinks, as the /usr/bin/git's inode is present on rootfs 113 times (according to `find / -xdev -inum`)

tl;dr: RBAC renders effectively running system as unusable if objects defined in policy are replaced/owerwritten by hardlinks.

Correct, if there are existing hardlinks to a file, then the RBAC system won't delete the object. It only allows a one-to-one mapping between objects and filenames.

-Brad

Are you okey if I create a 'known issues and workarounds' section under https://en.wikibooks.org/wiki/Grsecurit ... BAC_System? This one along with the rename() issue could help some people to not run into issues.

Sure, that's fine.

-Brad

spender wrote:Correct, if there are existing hardlinks to a file, then the RBAC system won't delete the object. It only allows a one-to-one mapping between objects and filenames.

-Brad

Brad, do you see it possible to address this use case in grsecurity alone? Hacking git build system along with others just to not have hardlinks hadly seems to be an valid solution.

The other option is using globbing rules for everything affected, though it's not supported for subjects.

-Brad

spender wrote:Correct, if there are existing hardlinks to a file, then the RBAC system won't delete the object. It only allows a one-to-one mapping between objects and filenames.

-Brad

There's a bit more. If there's existing hardlink to the inode that happen to be also in policy as an object, then the in-memory object wont be updated/deleted. However even after all the hardlinks are replaced, meaning the inode no longer is linked anywhere, the policy won't get updated. As with the git as example, while portage does do hardlinks, the /usr/bin/git still have other links, but when portage ends, the old inode of /usr/bin/git have no links at all, but still the RBAC does not 'pick up' new object.

Woudn't you consider this as a bug, rather than limitation? As simple as I can get it: if the object has been replaced while it had more than single link on filesystem, even if all the links are gone after that, RBAC won't pick up new inode for given path. Just like the code does not kicks in when htere are more links, on replace, and is never executed again when the additional links are gone. If there's just one link (no additional hardlinks), the replace on object is picked up immediately.

-- Piotr.