[tac_plus] Re: PAP authentication in tac_plus F4.0.4.15 overrides ACL restictions
Jon Nathan
jnathan at salesforce.com
Thu Mar 4 22:27:05 UTC 2010
Thanks John, that patch works perfectly! Do you think you'll include it in
a new release, or should I just use 4.0.4.19+acl_patch?
-Jon
On 3/4/10 11:41 AM, "john heasley" <heas at shrubbery.net> wrote:
> 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