If pam_access's config file (i.e. /etc/security/access.conf) contains special names like LOCAL in the origin field, these will be treated as a hostname sometimes. It performs DNS lookups of these names in the default search domain when used by a network service. If local and remote services share a pam_access config file (seems to be common) with these origins, then anyone controlling DNS can manipulate pam_access's decision by adding a matching DNS lookup.

I've found this to be true as of v1.4.0. I haven't tried it on any newer version, but didn't see any matching Issues.

Example

The user localadmin should only be able to log in locally with the following pam_access configuration at /etc/security/access.conf (shared by sshd, login and more):

+:localadmin:LOCAL
-:localadmin:ALL

Login attempts as localadmin succeed on the console and fail via SSH as expected, but pam_access is trying to look up LOCAL with DNS:

syslog:

Jan 10 23:54:47 server sshd[2051]: pam_access(sshd:account): cannot resolve hostname "LOCAL"
Jan 10 23:54:47 server sshd[2051]: pam_access(sshd:account): access denied for user `localadmin' from `10.0.0.33'

Packet capture, meanwhile:

admin@server:~$  tcpdump -i eth0 -n port 53
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wlp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
23:53:37.230335 IP 10.0.0.44.35353 > 10.0.0.2.53: 8066+ A? LOCAL.example.com. (35)
23:53:37.230927 IP 10.0.0.44.51002 > 10.0.0.2.53: 39403+ AAAA? LOCAL.example.com. (35)

To try a practical example, first logins fail as localadmin via SSH when LOCAL.example.com can't be resolved:

user@clienthost:~$ dig +short LOCAL.example.com
user@clienthost:~$ ssh [email protected]
[email protected]'s password:
Connection closed by 10.0.0.44 port 22

Trying again after adding LOCAL.example.com to DNS yields a successful login:

user@clienthost:~$ dig +short LOCAL.example.com
10.0.0.33
user@clienthost:~$ ssh [email protected]
[email protected]'s password:
localadmin@server:~$