<solar> klasikahl; hey do you have any time to work on docs? <klasikahl> solar: if you can assign a bug to me, i'll do it after i finish up on bug 31079 ------------------------------------------------------ grsecurity2 is making it's way into more kernels in the portage tree, but we have no documentation to point our users at, thus something is needed. What I have in mind is getting just enough data out there for a user to get started. I've started on two chapters of this but was hoping you would be able to lend a hand on getting it out the door. Recommended Kernel configuration && Roles and ACL's http://dev.gentoo.org/~solar/xml/grsecurity2.xml Many aspects will still apply from the existing grsec1 doc such as subject and object flags. http://www.gentoo.org/proj/en/hardened/grsecurity.xml Capability Names and Descriptions this time can come from http://www.gentoo.org/proj/en/hardened/capabilities.xml as a hyperlink vs being put into the doc. ------------------------------------------------------ Stuff that can be added to it. ------------------------------------------------------ # Role flags: # A -> This role is an administrative role, thus it has special privilege normal # roles do not have. In particular, this role bypasses the # additional ptrace restrictions # N -> Don't require authentication for this role. To access # the role, use gradm -n <rolename> # s -> This role is a special role, meaning it does not belong to a # user or group, and does not fall under ACL enforcement # u -> This role is a user role # g -> This role is a group role # G -> This role can use gradm to authenticate to the kernel # An ACL for gradm will automatically be added to the role # T -> Enable TPE for this role # l -> Enable learning for this role # # a role can only be one of user, group, or special # # role_allow_ip IP/optional netmask # eg: role_allow_ip 192.168.1.0/24 # You can have as many of these per role as you want # They restrict the use of a role to a list of IPs. If a user # is on the system that would normally get the role does not # belong to those lists of IPs, the system falls back through # its method of determining a role for the user # # Role hierarchy # user -> group -> default # First a user role attempts to match, if one is not found, # a group role attempts to match, if one is not found, # the default role is used. # # role_transitions <special role 1> <special role 2> ... <special role n> # eg: role_transitions www_admin dns_admin # # role transitions specify which special roles a given role is allowed # to authenticate to. This applies to special roles that do not # require password authentication as well. If a user tries to # authenticate to a role that is not within his transition table, he # will receive a permission denied error # # Nested subjects # subject /bin/su:/bin/bash:/bin/cat # / rwx # +CAP_ALL # grant privilege to specific processes if they are executed # within a trusted path. In this case, privilege is # granted if /bin/cat is executed from /bin/bash, which is # executed from /bin/su. # # Configuration inheritance on nested subjects # nested subjects inherit rules from their parents. In the # example above, the nested subject would inherit rules # from the nested subject for /bin/su:/bin/bash, # and the subject /bin/su # View the 1.9.x documentation for more information on # configuration inheritance # # new modes: # m -> allow creation of setuid/setgid files/directories # and modification of files/directories to be setuid/setgid # M -> audit the setuid/setgid creation/modification # c -> allow creation of the file/directory # C -> audit the creation # d -> allow deletion of the file/directory # D -> audit the deletion # # New learning system: # To learn on a given subject: add l (the letter l, not the number 1) # to the subject mode # To learn on a given role, add l to the role mode # For both of these, to enable learning, enable the system like: # gradm -L /etc/grsec2/learning.logs -E # and then generate the rules after disabling the system after the # learning phase with: # gradm -L /etc/grsec2/learning.logs -O /etc/grsec/acl # To use full system learning, enable the system like: # gradm -F -L /etc/grsec2/learning.logs # and then generate the rules after disabling the system after the # learning phase with: # gradm -F -L /etc/grsec2/learning.logs -O /etc/grsec/acl
If your using grsecurity on a system with devfsd, then adding: # GRSecurity REGISTER grsec PERMISSIONS root.root 0622 to /etc/devfsd.conf and reboot might help, i had to do that my self... Niki Guldbrand <grsec mailing list>
klasikahl should I reassign this to a more active developer? I see you have had the last one done for about a month.
It's quite optional. Right now I'm sitting down to finish up the doc. I am trying to get it final tonight before I leave for San Diego tomorrow night.
I have some acls if you want ... they are *home-made so they need testing (dunno how secure they are but still)
Bugghy, Feel free to post a URL to where your RBAC files live. Please hoever don't attach them here. (That would be another bug in due time)
I've posted here the acls I've made so far: http://rootshell.be/~bugghy/acls.php Please mail me any comments/suggestions/improvements to bugghy@rootshell.be Note that they aren't tested in a server environment.
I've ben updating this doc over the weekened. http://dev.gentoo.org/~solar/xml/grsecurity2.html http://dev.gentoo.org/~solar/xml/grsecurity2.xml Hopefully Swift can look it over and gentooify it.
Will get on it today
I've reviewed the document and put a bit more text in it (not much though) and made it look a little bit prettier :) I'm not able to attach it to this bug though but you can find it at http://dev.gentoo.org/~swift/grsecurity2.html and http://dev.gentoo.org/~swift/grsecurity2.xml
Thanks... Commited to the CVS and updated the hardened page.
