www.cendio.com
Bug 5682 - tl-session does spurious lookup of "thinlinc" hostname
: tl-session does spurious lookup of "thinlinc" hostname
Status: CLOSED FIXED
: ThinLinc
VSM Agent
: pre-1.0
: PC Unknown
: P2 Normal
: 4.6.0
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2015-10-27 16:07 by
Modified: 2016-04-12 12:25 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2015-10-27 16:07:58
We've gotten a report that tl-session is trying to look up the host "thinlinc"
as part of every session startup. If there are problems with this lookup then
the startup can be delayed, possibly up until the point where vsmagent gives up
and considers the startup failed.

We're not sure where this lookup is coming from, but the current theory is that
some PAM module does this as a result of us setting PAM_RHOST to "thinlinc". We
added that for a good reason though so removing is not a good idea. Perhaps
using an IP address from the RFC 5737 range instead?

More investigation is needed.
------- Comment #2 From cendio 2015-10-27 16:09:12 -------
I've confirmed this issue on our internal ThinLinc system (4.4.0 on RHEL 6).
------- Comment #3 From cendio 2015-12-11 14:06:11 -------
It's the auditing that is causing this. Backtrace:

#0  getaddrinfo (name=0x60ea00 "thinlinc", service=0x0, hints=0x7fffffff5ab0, 
    pai=0x7fffffff5ae8) at ../sysdeps/posix/getaddrinfo.c:2294
#1  0x0000003ee4606ce6 in _resolve_addr (buf=0x7fffffff7e60 "?", 
    host=0x60ea00 "thinlinc") at audit_logging.c:65
#2  0x0000003ee4607639 in audit_log_user_message (audit_fd=7, type=2300, 
    message=0x611420 "pam:
default-context=unconfined_u:unconfined_r:unconfined_t:s0
selected-context=unconfined_u:unconfined_r:unconfined_t:s0", 
    hostname=0x60ea00 "thinlinc", addr=<value optimized out>, 
    tty=0x60e9e0 "/dev/thinlinc", result=1) at audit_logging.c:263
#3  0x00007ffff5dafb27 in ?? () from /lib64/security/pam_selinux.so
#4  0x00007ffff5db05a6 in pam_sm_open_session ()
   from /lib64/security/pam_selinux.so
#5  0x0000003110202cee in ?? () from /lib64/libpam.so.0
#6  0x0000003110207168 in pam_open_session () from /lib64/libpam.so.0

Will have to check the code to see if it can be avoided.
------- Comment #4 From cendio 2015-12-11 14:07:34 -------
A second audit call is made during login:

#0  getaddrinfo (name=0x60ea00 "thinlinc", service=0x0, hints=0x7fffffff6b80, 
    pai=0x7fffffff6bb8) at ../sysdeps/posix/getaddrinfo.c:2294
#1  0x0000003ee4606ce6 in _resolve_addr (buf=0x7fffffff8f90 "?", 
    host=0x60ea00 "thinlinc") at audit_logging.c:65
#2  0x0000003ee4607876 in audit_log_acct_message (audit_fd=8, type=1105, 
    pgname=0x0, op=0x7fffffff9050 "PAM:session_open", name=0x605170 "tltest", 
    id=4294967295, host=0x60ea00 "thinlinc", addr=0x0, 
    tty=0x60e9e0 "/dev/thinlinc", result=1) at audit_logging.c:405
#3  0x00000031102080a0 in ?? () from /lib64/libpam.so.0
#4  0x000000311020825d in ?? () from /lib64/libpam.so.0

And a third during logout:

#0  getaddrinfo (name=0x60ea00 "thinlinc", service=0x0, hints=0x7fffffff6ba0, 
    pai=0x7fffffff6bd8) at ../sysdeps/posix/getaddrinfo.c:2294
#1  0x0000003ee4606ce6 in _resolve_addr (buf=0x7fffffff8fb0 "?", 
    host=0x60ea00 "thinlinc") at audit_logging.c:65
#2  0x0000003ee4607876 in audit_log_acct_message (audit_fd=8, type=1106, 
    pgname=0x0, op=0x7fffffff9070 "PAM:session_close", name=0x605170 "tltest", 
    id=4294967295, host=0x60ea00 "thinlinc", addr=0x0, 
    tty=0x60e9e0 "/dev/thinlinc", result=1) at audit_logging.c:405
#3  0x00000031102080a0 in ?? () from /lib64/libpam.so.0
#4  0x000000311020825d in ?? () from /lib64/libpam.so.0
------- Comment #5 From cendio 2015-12-11 14:23:27 -------
These log messages are not conditional in any way. And we have to make sure
RHOST is set to get the proper policy with (at least) pam_ck_connector and
pam_systemd. Fortunately it only has to be non-empty and not some variation of
"localhost" and "localdomain".

Let's see if there is something decent that can be fed to getaddrinfo() without
causing an actual lookup.
------- Comment #6 From cendio 2015-12-11 14:58:40 -------
Urgh. No terrific alternatives here.

 a) Fake name, e.g. "thinlinc"

    - Causes DNS lookup, which can also result in a hit and an incorrect IP
address being logged.

 b) Invalid name, e.g. "<thinlinc>"

    - No lookup, but throws an error which may be logged (disabled by default).

    - Might trip up other modules who also assume this is something valid

 c) Numeric address, e.g. "203.0.113.1"

    - Administrators might not know that this is a reserved address and will
think they're getting weird connections.

    - An IPv4 address will throw an error on a IPv6 only system, and vice versa

 c.2) Well known numeric address, e.g. "0.0.0.0"

    - More obvious fake to administrators, but might be identified as invalid
by PAM modules or considered equivalent to localhost.

 d) Nothing at all

    - ConsoleKit and systemd mark the session as local and the user gets a
bunch of privileges it's not supposed to.

Right now c) seems like the least bad alternative.
------- Comment #7 From cendio 2015-12-11 16:14:02 -------
There's also:

 e) Set it to the client's address

    - This address can change on reconnect but we have no way of informing the
modules of this. So logs and session information will retain the initial
address.

    - We might fail to get the address so we still need some dummy fallback.
------- Comment #8 From cendio 2015-12-15 12:52:08 -------
One more:

 f) Modify /etc/hosts

    - This file might get changed and the entry removed
------- Comment #9 From cendio 2015-12-17 15:53:59 -------
We're going with option c), but an address higher up in the range to avoid
confusion with any address used in documentation.
------- Comment #11 From cendio 2015-12-17 16:05:00 -------
See bug 5755 for follow-up for IPv6.
------- Comment #13 From cendio 2016-01-08 11:12:44 -------
(In reply to comment #9)
> We're going with option c), but an address higher up in the range to avoid
> confusion with any address used in documentation.

Tested with ThinLinc 4.5.0post 4992 and CentOS 7:

 * There are no longer any DNS lookups for the 'thinlinc' hostname on login or
logut.

 * Sessions are still listed as remote (verified using loginctl show-session)