Re: [PATCH] caching daemon release and nsswitch patches

On Wed, 31 Aug 2005, Jilles Tjoelker wrote:

> On Wed, Aug 31, 2005 at 11:18:19PM +0400, Michael Bushkov wrote:
>>> On Tue, Aug 30, 2005 at 05:32:52PM +0400, Michael Bushkov wrote:
>>>> We can't ensure that, I guess. In the upcoming version (before the 1st of
>>>> September), the cache would be per-user. This would solve all the security
>>>> problems. In a little while, I'll implement the ability for cached to act
>>>> as nscd. So you'll be able to choose the behaviour.
>
>>> What about setuid/setgid programs then?
>
>>> setuid root programs can use root's cache, perhaps a similar thing could
>>> be done for other setuid programs, but what about setgid?
>
>>> perhaps don't cache at all for set*id programs (issetugid(2))?
>> Per-user cache uses euid as the user identifier. So every setuid program
>> will use the cache, which corresponds to its euid.
>> But how can setgid affect the cache operations? Do you see some potential
>> issue?
>
> User X puts some garbled information in the cache for his uid, then
> starts a setgid program. That setgid program will use the bad data
> in the cache which is potentially exploitable.
Yes - you're right. I see 2 solutions:

1) The thing that you said - to turn off the caching for set*id programs

2) To separate users in the cache not only by their euid, but by their 
euid and egid together. In this case, if user X poisons the cache and 
starts the setgid program, then it will use the different (not poisoned) 
cache. I don't think that such a partitioning will cause the cache to grow 
too much.

With best regards,
Michael Bushkov
Rostov State University