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 a 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 something related to
argv[0]
. It is a trivial matter for any user to invoke any
application on a system under a different name -- this should not be
permitted to cause a security breach.
To invoke some target
application by another name, the user may
symbolically link the target application with the desired name. To be
precise all the user need do is,
ln -s /target/application ./preferred_name
and then run ./preferred_name
By studying the Linux-PAM configuration file,
/etc/pam.conf
, an attacker can choose the preferred_name
to be that of a service enjoying minimal protection; for example a
game which uses Linux-PAM to restrict access to certain hours of
the day. If the service-name were to be linked to the filename under
which the service was invoked, it is clear that the user is
effectively in the position of dictating which authentication scheme
the service uses. Needless to say, this is not a secure situation.
The conclusion is that the application developer should carefully define the service-name of an application. The safest thing is to make it a single hard-wired name.
Care should be taken to ensure that the conv()
function is
robust. Such a function is provided in the library libpam_misc
(see
below).
The Linux-PAM modules will need to determine the identity of the user who requests a service, and the identity of the user who grants the service. These two users will seldom be the same. Indeed there is generally a third user identity to be considered, the new (assumed) identity of the user once the service is granted.
The need for keeping tabs on these identities is clearly an issue of
security. Basically, the identity of the user requesting a service
should be the current uid
(userid) of the running process; the
identity of the privilege granting user is the euid
(effective
userid) of the running process; the identity of the user, under whose
name the service will be executed, is given by the contents of the
PAM_USER
pam_get_item(2)
.
In addition the identity of a remote user, requesting the service from
a distant location, will be placed in the PAM_RUSER
item.
Care should be taken to ensure that the proper execution of an
application is not compromised by a lack of system resources. If an
application is unable to open sufficient files to perform its service,
it should fail gracefully, or request additional resources.
Specifically, the quantities manipulated by the setrlimit(2)
family of commands should be taken into consideration.