pam_access Configuration Treats TTY Names as Hostnames

[Steve Benson]

Comments in PAM service files at /etc/pam.d/* suggest a line to uncomment to configure complicated authorization rules using pam_access (which in turn is configured by /etc/security/access.conf):

/etc/pam.d/sshd:

    # Uncomment and edit /etc/security/access.conf if you need to set complex
    # access limits that are hard to express in sshd_config.
    # account required pam_access.so

/etc/pam.d/login:

    # Uncomment and edit /etc/security/access.conf if you need to
    # set access limits.
    # (Replaces /etc/login.access file)
    # account required pam_access.so

Comments in /etc/security/access.conf indicate the origin in this file can be a TTY or domain name:

    # The third field should be a list of one or more tty names (for
    # non-networked logins), host names, domain names (begin with "."),

I wanted to configure a user on my server, 'localadmin', who can only log in on the console and not via any network service and tried to achieve this using pam_access as follows:

I uncommented the default ‘account required pam_access.so’ lines in /etc/pam.d/sshd and /etc/pam.d/login.

I add the following in /etc/security/access.conf intending to allow user 'localadmin' to only log in on the console:

    +:localadmin:tty1
    -:localadmin:ALL

This seems to work. Login via SSH fails and succeeds on the console, as expected.

However, /var/log/auth.log suspiciously indicates it is treating tty1 as a hostname during the failed SSH attempt:

    Dec 15 01:28:12 server sshd[5868]: pam_access(sshd:account): cannot resolve hostname "tty1"
    Dec 15 01:28:12 server sshd[5868]: pam_access(sshd:account): access denied for user `localadmin' from `10.0.0.101'

It is confirmed to be doing DNS lookups for 'tty1' in the search domain during the login attempt:

    admin@server:~$ resolvectl status eth0
    ...
       DNS Servers: 10.0.0.2
        DNS Domain: example.com
    admin@server:~$ sudo tcpdump -i eth0 -n port 53
    01:28:12.100348 IP 10.0.0.42.44968 > 10.0.0.2.53: 21558+ [1au] A? tty1.example.com. (45)
    01:28:12.100666 IP 10.0.0.42.44669 > 10.0.0.2.53: 40453+ [1au] AAAA? tty1.example.com. (45)
    01:28:12.103027 IP 10.0.0.2.53 > 10.0.0.42.44968: 21558 NXDomain* 0/1/1 (95)
    01:28:12.103027 IP 10.0.0.2.53 > 10.0.0.42.44669: 40453 NXDomain* 0/1/1 (95)

I configured my DNS service to resolve hostname 'tty1' to the IP address the SSH connection originates from:

    admin@server:~$ dig +short tty1.example.com
    10.0.0.101

SSH access is then unexpectedly allowed:

    user@clienthost:~$ ip -4 a show dev eth0
        inet 10.0.0.101/24 ...
    user@clienthost:~$ ssh localadmin@10.0.0.42
    localadmin@10.0.0.42's password:
    localadmin@server:~$

I think the local origins should be completely separated from network origins in /etc/security/access.conf somehow (maybe with separate access.conf files used for local and network PAM services).

Other requested bug report info:

root@server:~# lsb_release -rd
Description: Ubuntu 22.04.3 LTS
Release: 22.04
root@server:~# apt-cache policy pam
N: Unable to locate package pam
root@server:~# apt-cache policy libpam-modules
libpam-modules:
  Installed: 1.4.0-11ubuntu2.3
  Candidate: 1.4.0-11ubuntu2.3
  Version table:
 *** 1.4.0-11ubuntu2.3 500
        500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages
        100 /var/lib/dpkg/status
     1.4.0-11ubuntu2 500
        500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages

[Seth Arnold (seth-arnold)]

Steve, nice find. I haven't really thought much about this file, it always seemed a bit of a relic of the time when there were individually-wired serial connections to different offices.

I believe for your actual use case, "LOCAL" is the better choice.

As for the rest of it, it feels like the solution would be removing DNS / names from the interface entirely. That's a pretty drastic change and probably not suitable.

Can we make this bug public? I believe it'd be easier to discuss with others if it were public.

Thanks

[Steve Benson (sbhl)]

Sure, I don't mind if this is made public. Thanks for the suggestion, Seth, however LOCAL actually has the same problem - if I change my access.conf as follows:

    +:localadmin:LOCAL
    -:localadmin:ALL

It will then try to look up "LOCAL" as a hostname. Here's /var/log/auth.log and packet capture during an SSH login attempt as the localadmin user:

    Dec 15 18:37:44 server sshd[1437]: pam_access(sshd:account): cannot resolve hostname "LOCAL"

    18:38:08.577059 IP 10.0.0.42.36932 > 10.0.0.2.53: 37576+ A? LOCAL.example.com. (35)
    18:38:08.577362 IP 10.0.0.42.47397 > 10.0.0.2.53: 54274+ AAAA? LOCAL.example.com. (35)

I was thinking of working around this by creating two different access.conf files, one to be used by local PAM services (i.e. referenced from /etc/pam.d/login) and another for network services. pam_access.so has an option to specify an access.conf file to enable this.

[Seth Arnold (seth-arnold)]

I wondered if it would look up LOCAL too but figured the reference in the manual to pam_get_item(3) meant that it would special case this one without any lookups. I should have looked at the source instead.

I like your idea of using two different files for local vs networked services. (Though that doesn't exactly help with su or sudo, since they can be used by both.)

It's not ideal but it's straightforward.