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. Such a function is provided in the library libpam_misc
(see
below).