Current File : //usr/share/doc/pam-devel-1.1.8/html/mwg-see-programming-sec.html
<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 V1.78.1"><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"><security/pam_modules.h></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>
Mini Shell