[sudo-users] Sudo and Group Changes

[Edward Capriolo]

On Tue, Dec 8, 2009 at 12:08 PM, Robert Maxwell
<robert.maxwell at ie.ibm.com> wrote:
>
> Hi Guys
>
> I was asked by a team member to go and see if I could break sudo, and I
> think I have uncovered what may be a security violation within sudo.
>
> If I create 2 groups, one called test, and the other called beatles.
> Now in sudoers file i have the following lines.
>
> %test ALL= /usr/bin/write
> %beatles ALL=/usr/bin/more
>
> Now if I have 2 users one in each, for sake of things,a user called  paul
> is a part of the beatles group, and a user called testy is part of the test
> group.
> Under Testy, if I do a sudo -l I get the output that testy can run the
> write command.
> and same for paul, he can only run the more command.
>
> If I go into a new terminal, edit the /etc/group file to change the GID's
> of both of test and beatles, as in switch the GIDs around, and then do a
> sudo -l again while both shells were logged in while the changes were made,
> I get under both users the option to execute both write and more under the
> 2 user names.
>
> Now if it was the case that the user being moved from the wheel group, but
> the user was logged in while the change was moved, he would still have
> access to the whole commands associated with the wheel group as well as the
> group he was moved to.
>
> Now the version of Sudo I am using is 1.6.9p15 on AIX 5.3
>
> Just wondering if this kind of issue has occurred before, or if it
> considered to be a massive security breach?
>
>
> Is mise le meas / Regards,
>
> Robert Maxwell - IBM Global Account - IGA CTS
>
> ____________________________________________________________
> sudo-users mailing list <sudo-users at sudo.ws>
> For list information, options, or to unsubscribe, visit:
> http://www.sudo.ws/mailman/listinfo/sudo-users
>
I do not think this is a sudo issue as much as it is a system level
issue. This same problem exists without sudo. Some programs trust read
only environmental variable that last for your session. For example
just because a root password is changed does that imply everyone
logged in with the old password should be forcibly kicked out?

Some systems take advantage of USER/GID caching as well. Those to
suffer in that they may retain this information long after an
authoritative change is made.

If you want to solve the security problem you are having make sure you
terminate all user shells, local and remote after making a
passwd/group change.