[tac_plus] Re: PAP authentication in tac_plus F4.0.4.15 overrides ACL restictions
john heasley
heas at shrubbery.net
Thu Mar 4 16:41:59 UTC 2010
Tue, Mar 02, 2010 at 06:52:59AM -0800, Jon Nathan:
> Thanks Jathan. Is there any way then to do ACLs or something similar for
> authorization? Or something more clever I could do in my group definition
> that would prevent them from doing anything after they logged in to a denied
> host?
please try the patch below.
> -Jon
>
>
> On 3/2/10 9:17 AM, "jathan." <jathan at gmail.com> wrote:
>
> > Hey Jon-
> >
> > From what I know of using the ACL feature is that it is an
> > authorization action (i.e. when exec is launched on the device), not
> > authentication. So if you look a little closer it is performing
> > properly by disallowing authorization to occur on the deny match.
> >
> > If I am wrong, please send all threats to /dev/null.
> >
> > On Mon, Mar 1, 2010 at 1:21 PM, Jon Nathan <jnathan at salesforce.com> wrote:
> >> Hello,
> >>
> >> We use tac_plus F4.0.4.15 to manage authentication for our network switches.
> >> Our Cisco MDS (San-OS/NX-OS) switches can only use PAP or MSCHAP to
> >> authenticate, so we were able to accommodate this by adding pap lines to
> >> each user who required access to these switches as follows:
> >>
> >> user = jon {
> >> ? ? ? ?login = PAM
> >> ? ? ? ?pap = des xxx/jE
> >> ? ? ? ?member = saneng
> >> }
> >>
> >> We wanted to restrict some users to certain Cisco MDS switches, so we built
> >> an acl as follows:
> >>
> >> acl = backups_acl {
> >> ? ? ? ?permit = ^10.22(6|8).13.(20|21)$
> >> ? ? ? ?permit = ^10.225.10.(98|99)$
> >> ? ? ? ?permit = ^10.231.(10|11).18$
> >> ? ? ? ?deny = .*
> >> }
> >>
> >> Where the IPs above correspond to the allowed switches. ?However, when we
> >> set a user to a group that used this acl as follows:
> >>
> >> user = jon {
> >> ? ? ? ?login = PAM
> >> ? ? ? ?pap = des xxx/jE
> >> ? ? ? ?member = saneng_backups
> >> }
> >>
> >> group = saneng_backups {
> >> ? ? ? ?default service = permit
> >> ? ? ? ?acl = backups_acl
> >> ? ? ? ?service = exec {
> >> ? ? ? ? ? ? ? ?priv-lvl = 15
> >> ? ? ? ? ? ? ? ?cisco-av-pair = "shell:roles=network-admin vsan-admin"
> >> ? ? ? ?}
> >> }
> >>
> >> We were able to log into the explicitly permitted switches, and all other
> >> Cisco MDS switches that were not permitted. ?It looks like tac_plus accepts
> >> the pap authentication before trying to confirm against the ACL. ?Here are
> >> log snippets from -d 24:
> >>
> >> Logging into a host not permitted by the acl:
> >>
> >>
> >> Mon Mar ?1 21:04:38 2010 [11255]: session.peerip is 10.228.13.17
> >> Mon Mar ?1 21:04:38 2010 [12259]: connect from 10.228.13.17 [10.228.13.17]
> >> Mon Mar ?1 21:04:38 2010 [12259]: pap-login query for 'jon' 0 from
> >> 10.228.13.17 accepted
> >> Mon Mar ?1 21:04:38 2010 [11255]: session.peerip is 10.228.13.17
> >> Mon Mar ?1 21:04:38 2010 [12263]: connect from 10.228.13.17 [10.228.13.17]
> >> Mon Mar ?1 21:04:38 2010 [12263]: Start authorization request
> >> Mon Mar ?1 21:04:38 2010 [12263]: cfg_acl_check(backups_acl, 10.228.13.17)
> >> Mon Mar ?1 21:04:38 2010 [12263]: ip 10.228.13.17 matched deny regex .* of
> >> acl filter backups_acl
> >> Mon Mar ?1 21:04:38 2010 [12263]: authorization query for 'jon' 0 from
> >> 10.228.13.17 rejected
> >>
> >> Logging into a a host permitted by the acl:
> >>
> >> Mon Mar ?1 21:06:03 2010 [14200]: session.peerip is 10.228.13.17
> >> Mon Mar ?1 21:06:03 2010 [14202]: connect from 10.228.13.17 [10.228.13.17]
> >> Mon Mar ?1 21:06:03 2010 [14202]: pap-login query for 'jon' 0 from
> >> 10.228.13.17 accepted
> >> Mon Mar ?1 21:06:03 2010 [14200]: session.peerip is 10.228.13.17
> >> Mon Mar ?1 21:06:03 2010 [14203]: connect from 10.228.13.17 [10.228.13.17]
> >> Mon Mar ?1 21:06:03 2010 [14203]: Start authorization request
> >> Mon Mar ?1 21:06:03 2010 [14203]: do_author: user='jon'
> >> Mon Mar ?1 21:06:03 2010 [14203]: user 'jon' found
> >> Mon Mar ?1 21:06:03 2010 [14203]: exec authorization request for jon
> >> Mon Mar ?1 21:06:03 2010 [14203]: exec is explicitly permitted by line 290
> >> Mon Mar ?1 21:06:03 2010 [14203]: nas:service=shell (passed thru)
> >> Mon Mar ?1 21:06:03 2010 [14203]: nas:cmd= (passed thru)
> >> Mon Mar ?1 21:06:03 2010 [14203]: nas:cisco-av-pair*
> >> svr:cisco-av-pair=shell:roles=network-admin vsan-admin -> replace with
> >> cisco-av-pair=shell:roles=network-admin vsan-admin (f)
> >> Mon Mar ?1 21:06:03 2010 [14203]: nas:shell:roles* svr:absent/deny -> delete
> >> shell:roles* (i)
> >> Mon Mar ?1 21:06:03 2010 [14203]: nas:absent, server:priv-lvl=15 -> add
> >> priv-lvl=15 (k)
> >> Mon Mar ?1 21:06:03 2010 [14203]: replaced 2 args
> >> Mon Mar ?1 21:06:03 2010 [14203]: authorization query for 'jon' 0 from
> >> 10.228.13.17 accepted
> >>
> >>
> >> It looks like a bug in tac_plus. ?Tac_plus is accepting the user's login
> >> before confirming with the ACL that he is logging into a permitted host.
> >> What do you think?
> >>
> >> Thanks,
> >> Jon Nathan
> >> Salesforce.com
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> tac_plus mailing list
> >> tac_plus at shrubbery.net
> >> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
> >>
> >
> >
> >
> > --
> > Jathan.
> > -
>
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
Index: default_fn.c
===================================================================
--- default_fn.c (revision 3276)
+++ default_fn.c (working copy)
@@ -327,7 +327,12 @@
/* Assume the worst */
data->status = TAC_PLUS_AUTHEN_STATUS_FAIL;
verify(name, passwd, data, TAC_PLUS_RECURSE);
+#ifdef ACLS
+ if (verify_host(name, data, S_acl, TAC_PLUS_RECURSE) != S_permit)
+ data->status = TAC_PLUS_AUTHEN_STATUS_FAIL;
+#endif
free(passwd);
+ return;
}
/* Verify the challenge and id against the response by looking up the
@@ -419,8 +424,14 @@
data->status = TAC_PLUS_AUTHEN_STATUS_PASS;
}
+#ifdef ACLS
+ if (verify_host(name, data, S_acl, TAC_PLUS_RECURSE) != S_permit)
+ data->status = TAC_PLUS_AUTHEN_STATUS_FAIL;
+#endif
+
exp_date = cfg_get_expires(name, TAC_PLUS_RECURSE);
set_expiration_status(exp_date, data);
+ return;
}
/*
@@ -528,8 +539,14 @@
data->server_dlen = 8;
memcpy(data->server_data, r_chal, 8);
+#ifdef ACLS
+ if (verify_host(name, data, S_acl, TAC_PLUS_RECURSE) != S_permit)
+ data->status = TAC_PLUS_AUTHEN_STATUS_FAIL;
+#endif
+
exp_date = cfg_get_expires(name, TAC_PLUS_RECURSE);
set_expiration_status(exp_date, data);
+ return;
}
#ifdef MSCHAP
@@ -777,8 +794,14 @@
data->status = TAC_PLUS_AUTHEN_STATUS_PASS;
}
+#ifdef ACLS
+ if (verify_host(name, data, S_acl, TAC_PLUS_RECURSE) != S_permit)
+ data->status = TAC_PLUS_AUTHEN_STATUS_FAIL;
+#endif
+
exp_date = cfg_get_expires(name, TAC_PLUS_RECURSE);
set_expiration_status(exp_date, data);
+ return;
}
#endif /* MSCHAP */
More information about the tac_plus
mailing list