Re: [PATCH] caching daemon release and nsswitch patches

On Thu, Sep 01, 2005 at 12:00:09AM +0400, Michael Bushkov wrote:
> 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.

I'd be inclined toward the first option.  Getting edge cases right for
suid apps requires lots of thinking so I'd rather just not support the
feature initially.  Performance critical suid applications probably
aren't too common anyway.

-- Brooks