patching gradm for usr-moved distros
Posted: Wed Nov 27, 2013 7:44 pmI've been experimenting with grsec and it's RBAC system on a distro which has relocated most everything to /usr. Naturally, /sbin/gradm being a symlink to /usr/bin/gradm this causes gradm to complain like so:
This is easily solved by patching gradm_defs.h, but it got me looking around a bit more and I also patched gradm_analyze.c inside analyze_acls() where it stats the /lib*/modules dirs and warns if certain roles can write there. I also patched similar stuff in gradm_adm.c and removed most (if not all) the paths which are duplicated due to symlinking etc.
My patches so far are here:
https://gist.github.com/maxrp/7672029
(The shutdown role patch is separate because the shutdown role isn't working as I expect it to yet.)
Is this sane? As near as I can tell it is, but also I'm far from a gradm expert.
It's my understanding that gradm will resolve an object to an inode and as such (if anything) seeing symlinks to things already covered just can create duplicate objects... for a system where the canonical paths for /*bin and /lib* have all moved into /usr/{bin,lib*} is there any reason to not take this approach and only patch on gradm_defs.h (i.e. did I do more than I strictly needed too)?
Thanks for any feedback!
You are attempting to use a gradm binary other than the installed version. Depending on your policy, you could be locking yourself out of your machine by enabling the RBAC system with this binary. Press 'y' if you wish to ignore this warning, or any other key to cancel.
This is easily solved by patching gradm_defs.h, but it got me looking around a bit more and I also patched gradm_analyze.c inside analyze_acls() where it stats the /lib*/modules dirs and warns if certain roles can write there. I also patched similar stuff in gradm_adm.c and removed most (if not all) the paths which are duplicated due to symlinking etc.
My patches so far are here:
https://gist.github.com/maxrp/7672029
(The shutdown role patch is separate because the shutdown role isn't working as I expect it to yet.)
Is this sane? As near as I can tell it is, but also I'm far from a gradm expert.
It's my understanding that gradm will resolve an object to an inode and as such (if anything) seeing symlinks to things already covered just can create duplicate objects... for a system where the canonical paths for /*bin and /lib* have all moved into /usr/{bin,lib*} is there any reason to not take this approach and only patch on gradm_defs.h (i.e. did I do more than I strictly needed too)?
Thanks for any feedback!