From rt_e at mail.ru Fri Oct 1 09:35:44 2010 From: rt_e at mail.ru (=?koi8-r?Q?=E9=D7=C1=CE_=EB=CF=CC=C5=D3=CE=C9=CB=CF=D7?=) Date: Fri, 01 Oct 2010 13:35:44 +0400 Subject: [tac_plus] restrict authentication from remote address Message-ID: Hi. I use Version F4.0.4.18 of Tacacs and I were confronted with a problem. I would like to use a specific username, for authentication to the devices in network but only from a specific ip address(rem_addr). How can I do it in my version? From kissg at ssg.ki.iif.hu Tue Oct 12 10:27:50 2010 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Tue, 12 Oct 2010 12:27:50 +0200 (CEST) Subject: [tac_plus] IOS XR Message-ID: Hi, folks! I'm just studying IOS XR administrative model. At first sight classifying users as group members and inheritance is a built in feature of the IOS. I.e. the whole tac_plus.conf should be replicated in the router... Uhm. Have you any experience with IOS XR + tac_plus combination? Regards Gabor From kissg at ssg.ki.iif.hu Wed Oct 13 07:36:00 2010 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Wed, 13 Oct 2010 09:36:00 +0200 (CEST) Subject: [tac_plus] IOS XR In-Reply-To: <20101012185531.GF3658@shrubbery.net> References: <20101012185531.GF3658@shrubbery.net> Message-ID: > I'm just studying IOS XR administrative model. > At first sight classifying users as group members and > inheritance is a built in feature of the IOS. > > I.e. the whole tac_plus.conf should be replicated in the router... > Uhm. > Have you any experience with IOS XR + tac_plus combination? Meanwhile I found that the following config file snippet works well: service = exec { task = "#operator,rwxd:bgp,rd:ospf" } The only problem I found that tac_plus - unlike IOS XR - does not concatenate privileges defined in various nested groups. It sends back the first hit only. So the authorization model differs depending on where authorization actually happens. So I plan to modify the source in order to parse "task" keyword and at least concatenate all values found during inheritance. Later I can imagine revocation of some privileges granted by more general groups, like this: group = friend { service = exec { task = "rwxd:bgp,rwxd:ospf" } } user = johndoe { member = friend service = exec { task = "!wxd:bgp,!wx:ospf" } } So his permissions finally would be "r:bgp,rd:ospf". More complex schemas are also possible. :) Regards Gabor From kissg at ssg.ki.iif.hu Fri Oct 15 10:53:20 2010 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Fri, 15 Oct 2010 12:53:20 +0200 (CEST) Subject: [tac_plus] IOS XR In-Reply-To: References: <20101012185531.GF3658@shrubbery.net> Message-ID: > Meanwhile I found that the following config file snippet works well: > > service = exec { > task = "#operator,rwxd:bgp,rd:ospf" > } > > The only problem I found that tac_plus - unlike IOS XR - does not > concatenate privileges defined in various nested groups. > It sends back the first hit only. > So the authorization model differs depending on where authorization > actually happens. > > So I plan to modify the source in order to parse "task" keyword > and at least concatenate all values found during inheritance. I gave up. :-( This would require fundamental changes in config.c. Gabor -- No smoke, no drugs, no vindoze. From kissg at ssg.ki.iif.hu Fri Oct 15 10:57:16 2010 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Fri, 15 Oct 2010 12:57:16 +0200 (CEST) Subject: [tac_plus] tac_plus enhancement Message-ID: Dear friends, Multiple group membership+ACL continuation feature is added to version 4.0.4.19. It is available as Debian package for lenny. Location and instructions are in file http://bakaacsin.ki.iif.hu/~kissg/pd/tac_plus/README Gabor -- Wenn ist das Nunst?ck git und Slotermeyer? Ja! ... Beiherhund das Oder die Flipperwaldt gersput. From alan.mckinnon at gmail.com Fri Oct 15 11:12:35 2010 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Fri, 15 Oct 2010 13:12:35 +0200 Subject: [tac_plus] tac_plus enhancement In-Reply-To: References: Message-ID: <201010151312.35800.alan.mckinnon@gmail.com> Apparently, though unproven, at 12:57 on Friday 15 October 2010, Kiss Gabor (Bitman) did opine thusly: > Dear friends, > > Multiple group membership+ACL continuation feature is added > to version 4.0.4.19. > > It is available as Debian package for lenny. > Location and instructions are in file > http://bakaacsin.ki.iif.hu/~kissg/pd/tac_plus/README URL appears to have a typo. This works: http://bakacsin.ki.iif.hu/~kissg/pd/tac_plus/README -- alan dot mckinnon at gmail dot com From kissg at ssg.ki.iif.hu Fri Oct 15 12:44:53 2010 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Fri, 15 Oct 2010 14:44:53 +0200 (CEST) Subject: [tac_plus] tac_plus enhancement In-Reply-To: <201010151312.35800.alan.mckinnon@gmail.com> References: <201010151312.35800.alan.mckinnon@gmail.com> Message-ID: > > It is available as Debian package for lenny. > > Location and instructions are in file > > http://bakaacsin.ki.iif.hu/~kissg/pd/tac_plus/README > > URL appears to have a typo. This works: > > http://bakacsin.ki.iif.hu/~kissg/pd/tac_plus/README Oooops. My mistake. Thanks for the correction. :) Gabor -- A mug of beer, please. Shaken, not stirred. From heas at shrubbery.net Fri Oct 15 15:30:12 2010 From: heas at shrubbery.net (john heasley) Date: Fri, 15 Oct 2010 15:30:12 +0000 Subject: [tac_plus] IOS XR In-Reply-To: References: <20101012185531.GF3658@shrubbery.net> Message-ID: <20101015153012.GD27450@shrubbery.net> Fri, Oct 15, 2010 at 12:53:20PM +0200, Kiss Gabor (Bitman): > > Meanwhile I found that the following config file snippet works well: > > > > service = exec { > > task = "#operator,rwxd:bgp,rd:ospf" > > } > > > > The only problem I found that tac_plus - unlike IOS XR - does not > > concatenate privileges defined in various nested groups. > > It sends back the first hit only. > > So the authorization model differs depending on where authorization > > actually happens. > > > > So I plan to modify the source in order to parse "task" keyword > > and at least concatenate all values found during inheritance. > > I gave up. :-( > This would require fundamental changes in config.c. i havent thought about this feature, which is probably most sensibly done as an external authorization script, but i have begun rewritting the config parser to make it more flexible to changes....and thread-safe. > Gabor > -- > No smoke, no drugs, no vindoze. > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From kissg at ssg.ki.iif.hu Fri Oct 15 15:54:18 2010 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Fri, 15 Oct 2010 17:54:18 +0200 (CEST) Subject: [tac_plus] IOS XR In-Reply-To: <20101015153012.GD27450@shrubbery.net> References: <20101012185531.GF3658@shrubbery.net> <20101015153012.GD27450@shrubbery.net> Message-ID: > > > So I plan to modify the source in order to parse "task" keyword > > > and at least concatenate all values found during inheritance. > > > > I gave up. :-( > > This would require fundamental changes in config.c. > > i havent thought about this feature, which is probably most sensibly > done as an external authorization script, but i have begun rewritting > the config parser to make it more flexible to changes....and thread-safe. IMHO this not a parser issue. config.c functions should traverse the graph of user/group nodes more aggressively and not to stop at the first svc_exec (and similarly svc_cmd!) sub-node found. Config file syntax would be similarly extended as in case of ACLs: (svc_cmd is the simpler so I demonstrate with it) group = bystander { cmd = show { permit interface deny .* } } group = operator { cmd = show { permit ip return } } user = johndoe { cmd = show { permit clock return } member = operator member = bystander } Traverse would be continued with the next parent or sibling group if keyword 'return' is found instead if regexp match. I developed the general graph traversal routines years ago we just have to use them. Have a nice weekend. :) Gabor From heas at shrubbery.net Fri Oct 15 16:44:45 2010 From: heas at shrubbery.net (john heasley) Date: Fri, 15 Oct 2010 16:44:45 +0000 Subject: [tac_plus] IOS XR In-Reply-To: References: <20101012185531.GF3658@shrubbery.net> <20101015153012.GD27450@shrubbery.net> Message-ID: <20101015164445.GM27450@shrubbery.net> Fri, Oct 15, 2010 at 05:54:18PM +0200, Kiss Gabor (Bitman): > > > > So I plan to modify the source in order to parse "task" keyword > > > > and at least concatenate all values found during inheritance. > > > > > > I gave up. :-( > > > This would require fundamental changes in config.c. > > > > i havent thought about this feature, which is probably most sensibly > > done as an external authorization script, but i have begun rewritting > > the config parser to make it more flexible to changes....and thread-safe. > > IMHO this not a parser issue. its not a parser issue, i just refuse to change the parser any further until its written in a way that is easier to update and there are several requests for additions, like your multiple group change. > config.c functions should traverse the graph of user/group > nodes more aggressively and not to stop at the first svc_exec (and > similarly svc_cmd!) sub-node found. > > Config file syntax would be similarly extended as in case of ACLs: > (svc_cmd is the simpler so I demonstrate with it) > > group = bystander { > cmd = show { > permit interface > deny .* > } > } > > group = operator { > cmd = show { > permit ip > return > } > } > > user = johndoe { > cmd = show { > permit clock > return > } > member = operator > member = bystander > } > > Traverse would be continued with the next parent or sibling group > if keyword 'return' is found instead if regexp match. that doesnt really make sense; if operator is evaluated before bystander, it has a return, so bystander is never evaluated. if bystander were to preceed operator, it has deny .*, so operator is not evaluated. i don't like grammar that is mysteriously ignored. maybe a grammar more like a simple form of juniper's policy configuration would be better. user = foo { cmd = A B DENYALL } policy = A show { permit clock } policy = B show { permit ip } policy = DENYALL show { deny .* } that could be extended to be able to set variables to make more clever decisions. > I developed the general graph traversal routines years ago we just > have to use them. > > Have a nice weekend. :) > > Gabor From alan.mckinnon at gmail.com Fri Oct 15 17:06:20 2010 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Fri, 15 Oct 2010 19:06:20 +0200 Subject: [tac_plus] IOS XR In-Reply-To: <20101015164445.GM27450@shrubbery.net> References: <20101015164445.GM27450@shrubbery.net> Message-ID: <201010151906.21244.alan.mckinnon@gmail.com> Apparently, though unproven, at 18:44 on Friday 15 October 2010, john heasley did opine thusly: > > config.c functions should traverse the graph of user/group > > nodes more aggressively and not to stop at the first svc_exec (and > > similarly svc_cmd!) sub-node found. > > > > > > > > Config file syntax would be similarly extended as in case of ACLs: > > (svc_cmd is the simpler so I demonstrate with it) > > > > > > > > group = bystander { > > cmd = show { > > permit interface > > deny .* > > } > > } > > > > > > > > group = operator { > > cmd = show { > > permit ip > > return > > } > > } > > > > > > > > user = johndoe { > > cmd = show { > > permit clock > > return > > } > > member = operator > > member = bystander > > } > > > > > > > > Traverse would be continued with the next parent or sibling group > > if keyword 'return' is found instead if regexp match. > > that doesnt really make sense; if operator is evaluated before bystander, > it has a return, so bystander is never evaluated. if bystander were to > preceed operator, it has deny .*, so operator is not evaluated. i don't > like grammar that is mysteriously ignored. Or change the rules slightly for default statements. deny .* is a default catch-all and by definition there can only be one of those. You can deftly avoid collisions like you describe by moving the definition out of the user/group/whatever stanza and into a "global" or "default" area where it right fully belongs. I honestly don't see any other way to avoid these types of collisions, as a configuration language should never permit a circumstance where "deny *" and "permit *" are both valid for the same thing at the same time. -- alan dot mckinnon at gmail dot com