Differential D5235 Diff 15292 head/en_US.ISO8859-1/books/handbook/security/chapter.xml

Changeset View

Standalone View

head/en_US.ISO8859-1/books/handbook/security/chapter.xml

Show First 20 Lines • Show All 195 Lines • ▼ Show 20 Lines	superuser can change the shell for other users:</para>

<screen>&prompt.root; <userinput>chsh -s /usr/sbin/nologin <replaceable>toor</replaceable></userinput></screen>		<screen>&prompt.root; <userinput>chsh -s /usr/sbin/nologin <replaceable>toor</replaceable></userinput></screen>

<para>The <filename>/usr/sbin/nologin</filename> shell prevents		<para>The <filename>/usr/sbin/nologin</filename> shell prevents
the system from assigning a shell to the user when they		the system from assigning a shell to the user when they
attempt to login.</para>		attempt to login.</para>
</sect2>		</sect2>

<sect2 xml:id="security-sudo">		<sect2 xml:id="security-accountmgmt">
<title>Permitted Account Escalation</title>		<title>Permitted Account Escalation</title>

<para>In some cases, system administration needs to be shared		<para>In some cases, system administration needs to be shared
with other users. &os; has two methods to handle this. The		with other users. &os; has two methods to handle this. The
first one, which is not recommended, is a shared root password		first one, which is not recommended, is a shared root password
used by members of the <systemitem		used by members of the <systemitem
class="groupname">wheel</systemitem> group. With this		class="groupname">wheel</systemitem> group. With this
method, a user types <command>su</command> and enters the		method, a user types <command>su</command> and enters the
▲ Show 20 Lines • Show All 3,715 Lines • ▼ Show 20 Lines	jail:httpd:memoryuse:deny=2G/jail</programlisting>
&man.rctl.8;. However, if removing all rules for a single		&man.rctl.8;. However, if removing all rules for a single
user is required, this command may be issued:</para>		user is required, this command may be issued:</para>

<screen>&prompt.root; <userinput>rctl -r user:trhodes</userinput></screen>		<screen>&prompt.root; <userinput>rctl -r user:trhodes</userinput></screen>

<para>Many other resources exist which can be used to exert		<para>Many other resources exist which can be used to exert
additional control over various <literal>subjects</literal>.		additional control over various <literal>subjects</literal>.
See &man.rctl.8; to learn about them.</para>		See &man.rctl.8; to learn about them.</para>
		</sect2>
		</sect1>

		<sect1 xml:id="security-sudo">
		<info>
		<title>Shared Administration with Sudo</title>

		<authorgroup>
		<author><personname><firstname>Tom</firstname><surname>Rhodes</surname></personname><contrib>Contributed
		by </contrib></author>
		</authorgroup>
		</info>

		<indexterm>
		<primary>Security</primary>
		<secondary>Sudo</secondary>
		</indexterm>

		<para>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.</para>

		<para>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 <application>Sudo</application>.</para>

		<para><application>Sudo</application> 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
		<package role="port">security/sudo</package> or by use of
		the &man.pkg.8; utility. To use the &man.pkg.8; tool:</para>

		<screen>&prompt.root; <userinput>pkg install sudo</userinput></screen>

		<para>After the installation is complete, the installed
		<command>visudo</command> will open the configuration file with
		a text editor. Using <command>visudo</command> is highly
		recommended as it comes with a built in syntax checker to verify
		there are no errors before the file is saved.</para>

		<para>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
		<replaceable>webservice</replaceable>. To
		grant this user permission to perform these tasks, add
		this line to the end of
		<filename>/usr/local/etc/sudoers</filename>:</para>

		<programlisting>user1 ALL=(ALL) /usr/sbin/service webservice *</programlisting>

		<para>The user may now start <replaceable>webservice</replaceable>
		using this command:</para>

		<screen>&prompt.user; <userinput>sudo /usr/sbin/service <replaceable>webservice</replaceable> start</userinput></screen>

		<para>While this configuration allows a single user access to the
		<application>webservice</application> 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:</para>

		<screen>&prompt.root; <userinput>pw groupadd -g 6001 -n webteam</userinput></screen>

		<para>Using the same &man.pw.8; command, the user is added to
		the webteam group:</para>

		<screen>&prompt.root; <userinput>pw groupmod -m user1 -n webteam</userinput></screen>

		<para>Finally, this line in
		<filename>/usr/local/etc/sudoers</filename> allows any
		member of the webteam group to manage
		<replaceable>webservice</replaceable>:</para>

		<programlisting>%webteam ALL=(ALL) /usr/sbin/service webservice *</programlisting>

		<para>Unlike &man.su.1;, <application>Sudo</application>
		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.</para>

		<para>Users permitted to run applications with
		<application>Sudo</application> only enter their own passwords.
		This is more secure and gives better control than &man.su.1;,
		where the <systemitem class="username">root</systemitem>
		password is entered and the user acquires all
		<systemitem class="username">root</systemitem>
		permissions.</para>

		<tip>
		<para>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. <application>Sudo</application>
		provides for these cases with the <literal>NOPASSWORD</literal>
		variable. Adding it to the configuration above
		will allow all members of the <replaceable>webteam</replaceable>
		group to manage the service without the password
		requirement:</para>

		<programlisting>%webteam ALL=(ALL) NOPASSWORD: /usr/sbin/service webservice *</programlisting>
		</tip>

		<sect2 xml:id="security-sudo-loggin">
		<title>Logging Output</title>

		<para>An advantage to implementing
		<application>Sudo</application> is the ability to enable
		session logging. Using the built in log mechanisms
		and the included <application>sudoreplay</application>
		command, all commands initiated through
		<application>Sudo</application> 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 <application>sudoreplay</application> for
		additional information.</para>

		<programlisting>Defaults iolog_dir=/var/log/sudo-io/%{user}</programlisting>

		<tip>
		<para>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
		<application>sudoreplay</application> command. To change
		this behavior, read and uncomment the logging options inside
		<filename>sudoers</filename>.</para>
		</tip>

		<para>Once this directive has been added to the
		<filename>sudoers</filename> file, any user configuration
		can be updated with the request to log access. In the
		example shown, the updated <replaceable>webteam</replaceable>
		entry would have the following additional changes:</para>

		<programlisting>%webteam ALL=(ALL) NOPASSWD: LOG_INPUT: LOG_OUTPUT: /usr/sbin/service webservice *</programlisting>

		<para>From this point on, all <replaceable>webteam</replaceable>
		members altering the status of the
		<replaceable>webservice</replaceable> application
		will be logged. The list of previous and current sessions
		can be displayed with:</para>

		<screen>&prompt.root; <userinput>sudoreplay -l</userinput></screen>

		<para>In the output, to replay a specific session, search for the
		<literal>TSID=</literal> entry, and pass that to
		<application>sudoreplay</application> with no other options to
		replay the session at normal speed. For example:</para>

		<screen>&prompt.root; <userinput>sudoreplay user1/00/00/02</userinput></screen>

		<warning>
		<para>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 (<acronym>IDS</acronym>)
		or similar software so that other administrators are alerted
		to manual alterations.</para>
		</warning>

		<para>The <command>sudoreplay</command> is extremely extendable.
		Consult the documentation for more information.</para>
</sect2>		</sect2>
</sect1>		</sect1>
</chapter>		</chapter>