[sudo-users] Offtopic: Re: sudo + ldap - nisNetgroupTriple

[Jr Aquino]

Does anyone on the mailing list know where in the c code from sudo I  
would need to make modifications to make it look to a new type of ldap  
object for the netgroup's?

I believe I have demonstrated that my method and my reasoning is sane.

I have even managed to get openldap to fully crash when using a modify  
to the nis.schema to allow for nisNetgroupTriple to be an  
caseExactIA5Match and then making a modification to a nisNetgroupTriple.

Seems that some ldap servers can allow for this behavior and others  
are more strict to the RFC to the point where I can crash out a  
'stable' openldap daemon.

Either way, I'd like to look into the possibility of making these code  
modifications and feel like the hostGroup object really isn't terribly  
different from a nisNetgroup other than the lack of the unused tuple  
format.

Please let me know if any of you can tell me where I can start hacking  
at the code!

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Jr Aquino | Information Security Specialist
Citrix Online Division

Citrix Systems, Inc.
7408 Hollister Avenue
Goleta, CA  93117 USA
www.citrixonline.com

Desk: 805-690-3478
Email: jr.aquino at citrixonline.com

www.gotomypc.com | Access Your PC from Anywhere
www.gotomeeting.com | Online Meetings Made Easy
www.gotoassist.com | Remote Support Made Easy


On May 26, 2010, at 8:28 AM, Jr Aquino wrote:

> Right, thats why I said role based access.
>
> the sudo role can contain:
>
> sudorole:
>
> sudoUser: %someusergroup
> userGroup: someusergroup
>
> sudoHost: +somehostgroup
> hostGroup: somehostgroup
> hostGroup: nosudohostgroup
>
> sudoCommand: ALL
>
> someusergroup:
> memberUid: username
>
> somehostgroup:
> host: hosta
> host: hostb
> host: hostc
>
> nosudohostgroup:
> host: hostd
> host: hoste
> host: hostf
>
>
> I am not suggesting that the hostgroups or usergroups as they are  
> represented in the role should double as both login and escalation  
> rights. I define those separately with sudoHost vs hostGroup and  
> sudoUser vs userGroup.
>
> However I DO want to utilize the same sets of hostgroups /  
> usergroups as they are static containers that define groups of hosts  
> or users.
>
> In this demonstration, username has login and sudo access to hosta,  
> hostb, hostc, but it _only_ has login access to hostd, hoste, hostf.
>
> Does this help ease the confusion?
>
> On May 26, 2010, at 7:51 AM, Patrick Spinler wrote:
>
>> On 05/26/2010 09:16 AM, Jr Aquino wrote:
>>
>>> As such, I'd like to have a list of hosts that both sudo and  
>>> pam_ldap
>>> can look to without having to duplicate the same data in 2 different
>>> formats.
>>
>> Here's where I'd urge you to give careful consideration to your
>> approach.  You're talking about using the same object type for
>> semantically different purposes, and in fact to contain different  
>> objects.
>>
>> *) A group of hosts for use in sudo rules
>> *) A group of users for use in sudo rules
>> *) A group of users to provision to a host
>>
>> In fact, these are all different, and *should* be represented
>> differently in your repository.  We do something like this:
>>
>> auth_<somegroup>   - a list of people provisioned to a host
>> sudo_<somegroup>   - a list of people granted a specific sudo command
>> hgrp_<somegroup>   - a list of hosts
>>
>> Even in the first two instances, provisioning v. sudo, I *want* to  
>> keep
>> these separate.  For example, when an intern joins our unix team  
>> for a
>> summer assignment, I probably want to allow that intern to log into  
>> our
>> machines so she can e.g. gather configuration info, but I probably  
>> don't
>> want to grant that intern the full sudo rights I give normal unix  
>> admins.
>>
>> -- Pat
>