Uttered Stuart Ellis <s.ellis@xxxxxxxxxxxxxx>, spake thus: > I'll happily say +1 to a tutorial for sudo, anyhow - it doesn't seem to > get as much press as it should. OK, I've gotten a mini-howto for sudo together. As soon as I get my CLA paperwork through, I'll share it. It's very rough, I don't like it, but it's a beginning. Gosh, how did that attachment get there? Cheers
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"; [ <!ENTITY % FEDORA-ENTITIES-EN SYSTEM "../common/fedora-entities-en.xml"> %FEDORA-ENTITIES-EN; <!ENTITY BOOKID "sudo-tutorial-0.1 (2005-04-03)"> <!-- change version of manual and date here --> <!ENTITY LEGALNOTICE SYSTEM "../common/legalnotice-en.xml"> <!ENTITY PROGRAM "sudo(8)"> ]> <article id="sudo-tutorial" lang="en"> <articleinfo> <title>A &PROGRAM; Tutorial</title> <subtitle>Not a pseudo-tutorial!</subtitle> <copyright> <year>2005</year> <holder>&FORMAL-RHI;</holder> <holder>Tommy Reynolds <Tommy.Reynolds@xxxxxxxxxxxxx></holder> </copyright> <authorgroup> <author> <surname>Reynolds</surname> <firstname>Tommy</firstname> <email>Tommy.Reynolds@xxxxxxxxxxxxx</email> </author> </authorgroup> &LEGALNOTICE; </articleinfo> <section id="intro"> <title>Introduction</title> <para> The security of a Linux system depends largely on the enforcement of <firstterm>file access permissions</firstterm>. Access to a file is granted or withheld by comparing the identity of the user making the request against permissions associated with the file itself. Most of the configuration files, and many system administration activities, must be accessed by the privileged system user, commonly known as the <firstterm>superuser</firstterm> or the <firstterm>root</firstterm> account, and are not available to ordinary users. </para> <para> In this tutorial, we examine a technique for safely granting trusted users access to these programs and files that would normally be denied. The system administrator can keep the root password concealed, yet still allow selected users to obtain privileged access. Everybody wins with this approach. </para> <para> Although <application>sudo(8)</application> offers robust control for a networked environment, we shall consider only local use in this tutorial. For more information, consult <ulink url="http://www.sudo.ws/sudo";><filename>http://www.sudo.ws/sudo</filename> </ulink>, the official web site. </para> </section> <section id="bad-karma"> <title>What Not To Do</title> <para> As part of logging onto the system, you must establish your identity. Exactly how this is done is decided by the system administrator, but it typically involves you entering a <firstterm>password</firstterm>. Once you have successfully identified yourself to the system, the system maintains a set of <firstterm>credentials</firstterm> (such as the <firstterm>user-id</firstterm>, or <abbrev>uid</abbrev>); these credentials are what the system uses to grant or deny access to system resources such as applications, directories, or files. </para> <section id="bad-karma-su"> <title>Perhaps You Have Heard Of The su(1) Application?</title> <para> One technique, used since <trademark>UNIX</trademark> systems began, is for the user to temporarly assume the privileges of the superuser account. The <application>su(1)</application> <footnote> <para> When writing about programs or system configuration files, it is customary to indicate which section of the on-line manual pages contain its documentation. For example, section one (1) documents applications; section two (2) documents system calls, section three (3) a library function and so on. Sometimes the same name may be both a system call and a library function, knowing the manual page section is important. Compare the results of "<userinput>man 2 exit</userinput>" with "<userinput>man 3 exit</userinput>". </para> </footnote> changes the identification for the current user by <emphasis>s</emphasis>ubstituting <emphasis>u</emphasis>ser credentials. </para> <example> <title>Traditional Approach Using su(1)</title> <screen> $ id uid=500(reynolds) gid=500(reynolds) groups=500(reynolds) $ su -c id Password: uid=0(root) gid=0(root) groups=0(root),1(bin)... </screen> </example> <para> There are some problems with this approach: </para> <itemizedlist> <listitem> <para> The superuser password is compromised. </para> <para> Once anyone other than the system administrator knows the superuser password, everyone will know it. A secret must be kept a secret; promises not to tell are not sufficient security. </para> </listitem> <listitem> <para> There is no audit trail. </para> <para> With a superuser shell, a user can do anything that the root account can do. We must trust<footnote> <para> In security parlance, "to trust" is identical to "be at risk from". </para> </footnote>the user to access only the files and programs they claimed to need. </para> </listitem> </itemizedlist> </section> <section id="bad-karma-suid"> <title>Please, No Set-UserID Shell</title> <para> Another technology, used by the <application>su(1)</application> program, takes advantage of a neat feature. </para> <para> Normally, the files accessible to an application or shell depend on who is executing that program. Recall those <emphasis>credentials</emphasis> mentioned earlier? An application executes using the credentials of the user who runs the program. </para> <para> Stop, wait, there's more! </para> <para> Files have access permissions<footnote> <para> You can use "<userinput>$ ls -l foo</userinput>" to see the file access permissions for <filename>foo</filename>. Refer to the <application>ls(1)</application> documentation for help decoding the first column of output, where the permissions are shown. </para> </footnote>, but since a program is a file, the program has file access permissions, too. </para> <para> By setting a special flag, called the <firstterm>set user id bit</firstterm>, we can cause the system to check "credentials" made from the program file access permissions, instead of using the credentials for the user running the application<footnote> <para> The commands: </para> <screen> # chown root:root /bin/foo # chmod 06555 /bin/foo </screen> <para> would give whomever runs <filename>/bin/foo</filename> the same privileges that the superuser account would have while running the same application. </para> </footnote>. </para> <para> This ability to use the credentials of an application, instead of those of the user, can be a great boon to multiuser applications such as databases or email delivery agents. The feature has its proper use on a Linux system. </para> <para> As useful as it is, one must resist the temptation to make a shell program, such as <filename>/bin/bash</filename>, or a shell script, such as <filename>/usr/local/bin/i_can_fly</filename>, be set user ID to root. </para> <para> If this were to be done, then <emphasis>any</emphasis> user running that script or application would be able to access any file that the root account could access. </para> <para> Again, the objections to this method a similar to those we mentioned for the <application>su(1)</application> program: no control, and no traceability. </para> </section> </section> <section id="at-last"> <title>A Safer Alternative: sudo(8)</title> <para> The <application>sudo(8)</application> program solves the dilemma of how to allow ordinary users access to certain privileged system resources yet still keep the superuser password secret. </para> <para> Before granting privileges to a user, the <application>sudo(8)</application> program checks the configuration file <filename>/etc/sudoers</filename> and: </para> <itemizedlist> <listitem> <para> Grants privileges to the user without requiring any password at all. </para> </listitem> <listitem> <para> Grants privileges to the user if, and only if, the user supplies the correct password to prove their identity. Note that this is the password for the user accound, <emphasis>not</emphasis> the superuser password. </para> </listitem> <listitem> <para> Deny the access and notify the system administrator of the failed attempt via an email sent to the root account. </para> </listitem> </itemizedlist> <para> <application>Sudo(8)</application> keeps a log of all activity in the <filename>/var/log/secure</filename> file. Thus, there is an audit trail recording everything done in the name of the system administrator. </para> <section id="at-last-setup"> <title>Controlling Access To sudo(8)</title> <para> The <filename>/etc/sudoers</filename> file configures the programs that users can access using <application>sudo(8)</application>, along with whether or not a password will be needed. </para> <para> The system administrator adds users to this file using the <filename>/usr/sbin/visudo</filename> command. Each non-comment line in the file has two parts: </para> <orderedlist> <listitem> <para> A username ("reynolds"), or a group name ("%wheel").</para> </listitem> <listitem> <para> A list of machine names where a program may be run, or the keyword <literal>ALL</literal>. Following an equal sign (<literal>=</literal>), a list of user identities the command may be run as, enclosed in round brackets (parenthesis); the wildard <literal>ALL</literal> may also appear. Finally, a list of applications which may be run as the named users; the keyword <literal>ALL</literal> is a wildcard. </para> </listitem> </orderedlist> <para> The following examples should help make this clear: </para> <example> <title>/etc/sudoers Examples</title> <variablelist> <varlistentry> <term> <computeroutput>reynolds ALL=(ALL) ALL</computeroutput> </term> <listitem> <para> User reynolds can execute any command as any user, but must know the password to the reynolds account. </para> </listitem> </varlistentry> <varlistentry> <term> <computeroutput>reynolds ALL=(root) shutdown</computeroutput> </term> <listitem> <para> User reynolds can execute only command <application>shutdown</application>, but must know the password to the reynolds account. </para> </listitem> </varlistentry> <varlistentry> <term> <computeroutput>reynolds ALL=(root) NOPASSWD: /usr/bin/id</computeroutput> </term> <listitem> <para> User reynolds can execute only the application <filename>/usr/bin/id</filename>; no password will be needed. </para> </listitem> </varlistentry> </variablelist> </example> </section> <section id="at-last-using"> <title>Using sudo(8)</title> <para> Once the system administrator has entered the necessary setup into the <filename>/etc/sudoers</filename> file, users can safely access privileged system resources and activities like this: </para> <screen> $ sudo reboot Password: </screen> <para> There will be a log entry written to the <filename>/var/log/secure</filename> file to show who did the deed. </para> <para> Of course, the sysadmin may have configured <application>sudo(8)</application> not to request a password. In this case, the command is immediately executed although the audit trail entry will still be written. </para> </section> </section> <index id="generated-index"></index> </article>
Attachment:
pgp8cbFe84bWa.pgp
Description: PGP signature
