PAM_RHOST may contain the IP address of the remote host

[sssd-bot]

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/908

• Created at 2011-06-29 11:53:58 by sbose
• Closed at 2020-03-24 14:22:27 as wontfix
• Assigned to nobody

---

Andreas pointed me to the fact that PAM_RHOST may contain the IP address of the remote host instead of the hostname/FQDN. E.g. sshd of OpenSSH set the IP address here if it is not allowed to use DNS (UseDNS = no in sshd_config).

Currently all access control checks expect that the hostname/FQDN can be found here. I think it would make sense to "canonify" this item. E.g. we can try to do a reverse lookup to find the hostname and maybe aliases. This would lead to the question if we want to try and find aliases if PAM_RHOST contains the hostname, too?

Since this item is not uses only in access checks we should provide a utility to avoid people calling gethostbyname() or similar.

Comments

---

Comment from simo at 2011-06-29 13:26:13

Unfortunately given PTR records are often broken, a reverse lookup may give you totally unreliable information.

Not sure how we can properly fix this, perhaps we should do a forward lookup at rule evaluation, but that wouldn't work that great with group of hosts ...

---

Comment from sgallagh at 2011-06-29 14:48:03

Sumit and I discussed this on IRC a bit today.

I don't think it's our problem if the PTR records give bad information. We can only work with the environment we're given. I think we need to document that forward and reverse zones need to be set up properly or it can result in incorrect access-control resolution.

With this in mind, we SHOULD do the PTR lookup if we receive a PAM_RHOST value that matches an IP address regex (identifying both IPv4 and IPv6 addresses). If this returns multiple values, we need to check ALL host aliases against the rules, so that a DENY rule on an alias will take precedence over an ALLOW rule on a different alias.

---

Comment from dpal at 2011-06-30 15:30:29

Deferred under the premises that we drop the deny rules.

milestone: NEEDS_TRIAGE => SSSD Deferred

---

Comment from dpal at 2012-01-19 03:21:50

Fields changed

rhbz: => 0

---

Comment from sbose at 2017-02-24 14:31:43

Metadata Update from @sbose:

• Issue set to the milestone: SSSD Patches welcome

---

Comment from pbrezina at 2020-03-24 14:22:26

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

---

Comment from pbrezina at 2020-03-24 14:22:27

Metadata Update from @pbrezina:

• Issue close_status updated to: wontfix
• Issue status updated to: Closed (was: Open)