Index: en_US.ISO8859-1/books/handbook/security/chapter.xml =================================================================== --- en_US.ISO8859-1/books/handbook/security/chapter.xml +++ en_US.ISO8859-1/books/handbook/security/chapter.xml @@ -201,7 +201,7 @@ attempt to login. - + Permitted Account Escalation In some cases, system administration needs to be shared @@ -3935,4 +3935,185 @@ See &man.rctl.8; to learn about them. + + + + Shared Administration with Sudo + + + TomRhodesContributed + by + + + + + Security + Sudo + + + System administrators often need the ability to grant + enhanced permissions to users so they may perform privileged + tasks. The idea that team members are provided access + to a &os; system to perform their specific tasks opens up unique + challenges to every administrator. These team members only + need a subset of access beyond normal end user levels; however, + they almost always tell management they are unable to + perform their tasks without superuser access. Thankfully, there + is no reason to provide such access to end users because tools + exist to manage this exact requirement. + + Up to this point, the security chapter has covered permitting + access to authorized users and attempting to prevent unauthorized + access. Another problem arises once authorized users have access + to the system resources. In many cases, some users may need + access to application startup scripts, or a team of + administrators need to maintain the system. Traditionally, the + standard users and groups, file permissions, and even the + &man.su.1; command would manage this access. And as applications + required more access, as more users needed to use system + resources, a better solution was required. The most used + application is currently Sudo. + + Sudo allows administrators + to configure more rigid access to system commands + and provide for some advanced logging features. + As a tool, it is available from the Ports Collection + or by use of the &man.pkg.8; utility. To use + the &man.pkg.8; tool: + + &prompt.root; pkg install sudo + + After the installation is complete, the installed + visudo will open the configuration file with + a text editor. Using visudo is highly + recommended as it comes with a built in syntax checker to verify + there are no errors before the file is saved. + + The configuration file is made up of several small sections + which allow for extensive configuration. In the following + example, web application maintainer, user1, needs to start, + stop, and restart the web application known as + webservice. To + grant this user permission to perform these tasks, add + this line to the end of + /usr/local/etc/sudoers: + + user1 ALL=(ALL) /usr/sbin/service webservice * + + The user may now start webservice + using this command: + + &prompt.user; sudo /usr/sbin/service webservice start + + While this configuration allows a single user access to the + webservice service; however, in most + organizations, there is an entire web team in charge of managing + the service. A single line can also give access to an entire + group. These steps will create a web group, add a user to this + group, and allow all members of the group to manage the + service: + + &prompt.root; pw groupadd -g 6001 -n webteam + + Using the same &man.pw.8; command, the user is added to + the webteam group: + + &prompt.root; pw groupmod -m user1 -n webteam + + Finally, this line in + /usr/local/etc/sudoers allows any + member of the webteam group to manage + webservice: + + %webteam ALL=(ALL) /usr/sbin/service webservice * + + Unlike &man.su.1;, Sudo + only requires the end user password. This adds an advantage where + users will not need shared passwords, a finding in most security + audits and just bad all the way around. + + Users permitted to run applications with + Sudo only enter their own passwords. + This is more secure and gives better control than &man.su.1;, + where the root + password is entered and the user acquires all + root + permissions. + + + Most organizations are moving or have moved toward a two + factor authentication model. In these cases, the user may + not have a password to enter. Sudo + provides for these cases with the NOPASSWORD + variable. Adding it to the configuration above + will allow all members of the webteam + group to manage the service without the password + requirement: + + %webteam ALL=(ALL) NOPASSWORD: /usr/sbin/service webservice * + + + + Logging Output + + An advantage to implementing + Sudo is the ability to enable + session logging. Using the built in log mechanisms + and the included sudoreplay + command, all commands initiated through + Sudo are logged for later + verification. To enable this feature, add a default log + directory entry, this example uses a user variable. + Several other log filename conventions exist, consult the + manual page for sudoreplay for + additional information. + + Defaults iolog_dir=/var/log/sudo-io/%{user} + + + This directory will be created automatically after the + logging is configured. It is best to let the system create + directory with default permissions just to be safe. In + addition, this entry will also log administrators who use the + sudoreplay command. To change + this behavior, read and uncomment the logging options inside + sudoers. + + + Once this directive has been added to the + sudoers file, any user configuration + can be updated with the request to log access. In the + example shown, the updated webteam + entry would have the following additional changes: + + %webteam ALL=(ALL) NOPASSWD: LOG_INPUT: LOG_OUTPUT: /usr/sbin/service webservice * + + From this point on, all webteam + members altering the status of the + webservice application + will be logged. The list of previous and current sessions + can be displayed with: + + &prompt.root; sudoreplay -l + + In the output, to replay a specific session, search for the + TSID= entry, and pass that to + sudoreplay with no other options to + replay the session at normal speed. For example: + + &prompt.root; sudoreplay user1/00/00/02 + + + While sessions are logged, any administrator is + able to remove sessions and leave only a question of why they + had done so. It is worthwhile to add a daily check + through an intrusion detection system (IDS) + or similar software so that other administrators are alerted + to manual alterations. + + + The sudoreplay is extremely extendable. + Consult the documentation for more information. + +