3. Security issues of Linux-PAM

Contents of this section

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