From owner-svn-doc-all@freebsd.org Mon Apr 18 18:10:52 2016 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B179CB13C1E; Mon, 18 Apr 2016 18:10:52 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D1A910BB; Mon, 18 Apr 2016 18:10:52 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id u3IIApOP058417; Mon, 18 Apr 2016 18:10:51 GMT (envelope-from trhodes@FreeBSD.org) Received: (from trhodes@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id u3IIAp2I058415; Mon, 18 Apr 2016 18:10:51 GMT (envelope-from trhodes@FreeBSD.org) Message-Id: <201604181810.u3IIAp2I058415@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: trhodes set sender to trhodes@FreeBSD.org using -f From: Tom Rhodes Date: Mon, 18 Apr 2016 18:10:51 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r48670 - head/en_US.ISO8859-1/books/handbook/security X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 18:10:52 -0000 Author: trhodes Date: Mon Apr 18 18:10:51 2016 New Revision: 48670 URL: https://svnweb.freebsd.org/changeset/doc/48670 Log: Add a section on installing sudo and some basic instruction on the use Differential Revision: D5235 Reviewed by: wblock, mat Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/security/chapter.xml Mon Apr 18 17:42:15 2016 (r48669) +++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml Mon Apr 18 18:10:51 2016 (r48670) @@ -201,7 +201,7 @@ attempt to login. - + Permitted Account Escalation In some cases, system administration needs to be shared @@ -3935,4 +3935,185 @@ jail:httpd:memoryuse:deny=2G/jail + + + + 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 as + security/sudo 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. + +