1#@!#!123s

32759 1#@!#!123s
: / proc / thread-self / root / usr / share / doc / pam-devel / html /
Filename : mwg-see-programming-sec.html
back
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>5.1. Security issues for module creation</title><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot"><link rel="home" href="Linux-PAM_MWG.html" title="The Linux-PAM Module Writers' Guide"><link rel="up" href="mwg-see-programming.html" title="Chapter 5. Programming notes"><link rel="prev" href="mwg-see-programming.html" title="Chapter 5. Programming notes"><link rel="next" href="mwg-see-programming-syslog.html" title="5.2. Use of syslog(3)"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">5.1. Security issues for module creation</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="mwg-see-programming.html">Prev</a> </td><th width="60%" align="center">Chapter 5. Programming notes</th><td width="20%" align="right"> <a accesskey="n" href="mwg-see-programming-syslog.html">Next</a></td></tr></table><hr></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="mwg-see-programming-sec"></a>5.1. Security issues for module creation</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="mwg-see-programming-sec-res"></a>5.1.1. Sufficient resources</h3></div></div></div><p>
          Care should be taken to ensure that the proper execution
          of a module is not compromised by a lack of system resources.
          If a module is unable to open sufficient files to perform its
          task, it should fail gracefully, or request additional resources.
          Specifically, the quantities manipulated by the <span class="citerefentry"><span class="refentrytitle">setrlimit</span>(2)</span> family of commands should be taken into
          consideration.
        </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="mwg-see-programming-sec-who"></a>5.1.2. Who´s who?</h3></div></div></div><p>
          Generally, the module may wish to establish the identity of
          the user requesting a service. This may not be the same as
          the username returned by <code class="function">pam_get_user()</code>.
          Indeed, that is only going to be the name of the user under
          whose identity the service will be given. This is not
          necessarily the user that requests the service.
        </p><p>
          In other words, user X runs a program that is setuid-Y, it
          grants the user to have the permissions of Z. A specific example
          of this sort of service request is the <span class="command"><strong>su</strong></span>
          program: user <span class="command"><strong>joe</strong></span> executes
          <span class="command"><strong>su</strong></span> to become the user <span class="command"><strong>jane</strong></span>.
          In this situation X=<span class="command"><strong>joe</strong></span>, Y=<span class="command"><strong>root</strong></span>
          and Z=<span class="command"><strong>jane</strong></span>. Clearly, it is important that
          the module does not confuse these different users and grant an
          inappropriate level of privilege.
        </p><p>
          The following is the convention to be adhered to when juggling
          user-identities.
        </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
              X, the identity of the user invoking the service request.
              This is the user identifier; returned by the function
              <span class="citerefentry"><span class="refentrytitle">getuid</span>(2)</span>.
            </p></li><li class="listitem"><p>
              Y, the privileged identity of the application used to
              grant the requested service. This is the
              <span class="emphasis"><em>effective</em></span> user identifier;
              returned by the function <span class="citerefentry"><span class="refentrytitle">geteuid</span>(2)</span>.
            </p></li><li class="listitem"><p>
              Z, the user under whose identity the service will be granted.
              This is the username returned by
              <code class="function">pam_get_user()</code> and also stored in the
              <span class="emphasis"><em>Linux-PAM</em></span> item,
              <span class="emphasis"><em>PAM_USER</em></span>.
            </p></li><li class="listitem"><p>
              <span class="emphasis"><em>Linux-PAM</em></span> has a place for
              an additional user identity that a module may care to make
              use of. This is the <span class="emphasis"><em>PAM_RUSER</em></span> item.
              Generally, network sensitive modules/applications may wish
              to set/read this item to establish the identity of the user
              requesting a service from a remote location.
            </p></li></ul></div><p>
          Note, if a module wishes to modify the identity of either the
          <span class="emphasis"><em>uid</em></span> or <span class="emphasis"><em>euid</em></span> of the
          running process, it should take care to restore the original
          values prior to returning control to the
          <span class="emphasis"><em>Linux-PAM</em></span> library.
        </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="mwg-see-programming-sec-conv"></a>5.1.3. Using the conversation function</h3></div></div></div><p>
          Prior to calling the conversation function, the module should
          reset the contents of the pointer that will return the applications
          response. This is a good idea since the application may fail
          to fill the pointer and the module should be in a position to
          notice!
        </p><p>
          The module should be prepared for a failure from the
          conversation. The generic error would be
          <span class="emphasis"><em>PAM_CONV_ERR</em></span>, but anything other than
          <span class="emphasis"><em>PAM_SUCCESS</em></span> should be treated as
          indicating failure.
        </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="mwg-see-programming-sec-token"></a>5.1.4. Authentication tokens</h3></div></div></div><p>
          To ensure that the authentication tokens are not left lying
          around the items, <span class="emphasis"><em>PAM_AUTHTOK</em></span> and
          <span class="emphasis"><em>PAM_OLDAUTHTOK</em></span>, are not available to
          the application: they are defined in
          <code class="filename">&lt;security/pam_modules.h&gt;</code>. This
          is ostensibly for security reasons, but a maliciously
          programmed application will always have access to all memory
          of the process, so it is only superficially enforced. As a
          general rule the module should overwrite authentication tokens
          as soon as they are no longer needed. Especially before
          <code class="function">free()</code>'ing them. The
          <span class="emphasis"><em>Linux-PAM</em></span> library is
          required to do this when either of these authentication
          token items are (re)set.
        </p><p>
          Not to dwell too little on this concern; should the module
          store the authentication tokens either as (automatic) function
          variables or using <code class="function">pam_[gs]et_data()</code> the
          associated memory should be over-written explicitly before it
          is released. In the case of the latter storage mechanism, the
          associated <code class="function">cleanup()</code> function should
          explicitly overwrite the <code class="varname">*data</code> before
          <code class="function">free()</code>'ing it: for example,
          </p><pre class="programlisting">
/*
 * An example cleanup() function for releasing memory that was used to
 * store a password.
 */

int cleanup(pam_handle_t *pamh, void *data, int error_status)
{
    char *xx;

    if ((xx = data)) {
        while (*xx)
            *xx++ = '\0';
        free(data);
    }
    return PAM_SUCCESS;
}
          </pre><p>
        </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="mwg-see-programming.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="mwg-see-programming.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="mwg-see-programming-syslog.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 5. Programming notes </td><td width="20%" align="center"><a accesskey="h" href="Linux-PAM_MWG.html">Home</a></td><td width="40%" align="right" valign="top"> 5.2. Use of <span class="citerefentry"><span class="refentrytitle">syslog</span>(3)</span></td></tr></table></div></body></html>