A poorly (or maliciously) written application can defeat any Linux-PAM module's authentication mechanisms by simply ignoring it's return values. It is the applications task and responsibility to grant privileges and access to services. The Linux-PAM library simply assumes the responsibility of authenticating the user; ascertaining that the user is who they say they are. Care should be taken to anticipate all of the documented behavior of the Linux-PAM library functions. A failure to do this will most certainly lead to a future security breach.
In general writers of authorization-granting applications should
assume that each module is likely to call any or all `libc'
functions. For `libc' functions that return pointers to
static/dynamically allocated structures (ie. the library allocates the
memory and the user is not expected to `free()
' it) any module
call to this function is likely to corrupt a pointer previously
obtained by the application. The application programmer should either
re-call such a `libc' function after any call to the Linux-PAM
library, or copy the structure contents to some safe area of memory
before passing control to the Linux-PAM library.
When picking the service name that corresponds to the first entry
in the /etc/pam.conf
file, the application programmer should
avoid the temptation of choosing, argv[0]
. Since a user can
always establish the service that uses the weakest authentication
service. By symbolically linking the targeted application to a link of
that name, the user assumes power to choose the authentication method
for any application.
Care should be taken to ensure that the conv()
function is
robust.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter