[SSSD] daemon using sss (PAM) for auth / account

Stephen Gallagher sgallagh at redhat.com
Wed Aug 29 11:34:01 UTC 2012


On Tue, 2012-08-28 at 20:43 -0400, Michael Mercier wrote:
> Hello,
> 
> I am in the process of doing a proof-of-concept to use FreeIPA as a  
> backend for the tac_plus (tacacs+) daemon.
> PAM authentication was already built in to the application and works  
> with FreeIPA.  I have added some code to tac_plus to also use the  
> account section of the pam file and I have a question regarding (maybe  
> this is PAM specific?) how pam_sss works with HBAC.
> 
> I have done the following in FreeIPA:
> 
> 1.  Created a DNS entry for my device:  pix.beta.local <-> 192.168.0.1
> 2.  Disabled the 'allow_all' HBAC rule
> 3.  Created an HBAC rule tacacs with the following:
>   a) who: user group: ciscoadmin - user mike is part of ciscoadmin
>   b) Accessing: hosts: pix.beta.local
>   c) via service: tac_plus
>   d) from: any host
> 
> I can successfully login (auth) to a Cisco ASA via the tac_plus daemon  
> using PAM, but accounting is giving permission denied.
> Aug 28 16:13:34 ipaserver tac_plus[2217]: pam_sss(tac_plus:auth):  
> authentication success; logname=root uid=0 euid=0 tty= ruser=  
> rhost=192.168.0.1 user=mike
> Aug 28 16:13:34 ipaserver tac_plus[2217]: pam_sss(tac_plus:account):  
> Access denied for user mike: 6 (Permission denied)
> 
> NOTE: I have hardcoded the rhost setting with pam_set_item(pam_handle,  
> PAM_RHOST, "192.168.0.1")
> 
> I see the following in my audit.log
> type=USER_AUTH msg=audit(1346184814.834:168): user pid=2217 uid=0  
> auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0- 
> s0:c0.c1023 msg='op=PAM:authentication acct="mike" exe="/home/tacacs/ 
> tacacs+-F4.0.4.26/.libs/lt-tac_plus" hostname=192.168.0.1  
> addr=192.168.0.1 terminal=pts/0 res=success'
> type=USER_ACCT msg=audit(1346184814.845:169): user pid=2217 uid=0  
> auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0- 
> s0:c0.c1023 msg='op=PAM:accounting acct="mike" exe="/home/tacacs/tacacs 
> +-F4.0.4.26/.libs/lt-tac_plus" hostname=192.168.0.1 addr=192.168.0.1  
> terminal=pts/0 res=failed'
> 
> It seems that the machine the daemon is running on  
> (ipaserver.beta.local) is being used for the HBAC rule (at least that  
> is what is looks like from the dirsrv access log)
> [28/Aug/2012:16:13:33 -0400] conn=29 op=45 SRCH  
> base="cn=hbac,dc=beta,dc=local" scope=2  
> filter="(&(objectClass=ipaHBACRule)(ipaEnabledFlag=TRUE)(| 
> (hostCategory=all) 
> (memberHost 
> = 
> fqdn 
> =ipaserver.beta.local,cn=computers,cn=accounts,dc=beta,dc=local)))"  
> attrs="objectClass cn ipaUniqueID ipaEnabledFlag accessRuleType  
> memberUser userCategory memberService serviceCategory sourceHost  
> sourceHostCategory externalHost memberHost hostCategory"
> 
> If I add the host (ipaserver.beta.local) the daemon is running on to  
> the 'Accessing' list or enable the 'allow_all' rule, I am able to login.
> 
> NOTE: ipaserver.beta.local is also the IPA server (running all ipa  
> services)
> 
> My questions:
> 
> How is 'hostname' & 'addr' in the audit.log being generated?  Is PAM  
> sending these messages to the log (or is this something auditd  
> specific)? Does one or both of them come via the rhost variable from  
> pam_set_item?
> Is it possible to pass 'hostname' or 'addr' as the variable for  
> checking the HBAC rule?

I'm not certain of the exact mechanism, but I *think* it gets hostname
from the PAM rhost attribute and addr from the socket being used. That
said, please see below for reasons why source host (aka "from")
processing is not supported in recent versions of SSSD (1.7.0 and
later).



Copying the reply I sent to a related question on the freeipa-devel
list:

SSSD doesn't support source host processing because it was an impossible
feature to implement properly. PAM provides a srchost attribute, but
specifies no requirements for what it should contain. It may contain:
 * The remote host's hostname as offered by that remote host - This
cannot be trusted, as the remote host may be lying. Potential security
issue.
 * The remote host's IP address - this would necessitate us doing an
rDNS lookup and trying every possible hostname that is returned, which
exposes us to DNS poisoning attacks. Potential security issue
 * Some arbitrary data provided by either the remote server or the local
application.

Since we have no specification for what must be in this field or how it
is presented to us, there's no secure way to determine whether the
remote host actually is the one it claims to be.

Our general answer here is that if you need to be doing srchost
processing, the only secure way to do that is at the firewall level.
This is a limitation of the existing PAM technology and is NOT solvable
by SSSD.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120829/1b9d3d6c/attachment.sig>


More information about the sssd-devel mailing list