[Freeipa-users] PAM / SSSD / HBAC

[Stephen Gallagher]

On Tue, 2012-08-28 at 17:21 -0400, Rob Crittenden wrote:
> Michael Mercier wrote:
> > On 2012-08-22, at 4:12 PM, Rob Crittenden wrote:
> >
> >> Michael Mercier wrote:
> >>> Hello,
> >>>
> >>> In Aug 2010, someone posted a message to this list about integrating
> >>> tacacs+ with freeipa
> >>> https://www.redhat.com/archives/freeipa-users/2010-August/msg00058.html
> >>>
> >>> At the time, it was mentioned that this was not on the roadmap, has this
> >>> changed?
> >>
> >> No, still not on the roadmap.
> >>
> >>
> >>> If RedHat has no plans to do this, where can I find the freeipa
> >>> documentation that would allow me to do a proof-of-concept?  I would use
> >>> the freely available tac_plus (http://www.shrubbery.net/tac_plus/) as a
> >>> staring point.
> >>
> >> http://freeipa.org/page/Contribute (in Developer Documentation and Developement Process) and
> >> http://abbra.fedorapeople.org/freeipa-extensibility.html
> >>
> >>>
> >>> Some of the specific things I am looking for:
> >>> 1.  How should passwords be verified?  sssd, pam, ldap lookup, krb?
> >>> 2.  How the ldap schema should be designed for best integration?
> >>
> >> I'd start by seeing if there is already one defined as a real or quasi standard.
> >>
> >>> 3.  The proper way to query the ldap server (standard ldap calls or is
> >>> there some specific freeipa api)
> >>
> >> Standard LDAP calls.
> >>
> >>> 4.  I am sure I am not asking something!!
> >>>
> >>> I tried asking some similar questions on freeipa-devel but didn't
> >>> receive a response.
> >>
> >> rob
> >
> > Hello,
> >
> > I have started playing with having the tac_plus daemon use Freeipa and have some questions regarding HBAC.
> >
> > I have done the following:
> >
> > 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.  I have added some code to also attempt to do PAM accounting for the device and can't get this to work.
> >
> > 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)
> >
> > 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.
> >
> > 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 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"
> >
> > Is it possible to get the 'hostname' (pix.beta.local/192.168.0.1) passed through to HBAC?
> > It looks like the 'msg' portion of the audit data is coming from PAM (Is this correct)?
> > Should I be posting this to the devel list instead?
> >
> 
> An educated guess would be that the tac_plus daemon would need to be 
> modified to send the requesting server hostname to PAM.

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: <http://listman.redhat.com/archives/freeipa-users/attachments/20120829/b202cd47/attachment.sig>