proposed PAG handling changes for Arla

[Neulinger, Nathan R.]

I don't believe it was so much the fact that it was using alot of space as
it was due to the fact that the list got huge and took an incredibly long
time to add/remove entries from, yielding periodic multi-second lockups on a
reasonably high-powered machine that got thousands of logins a day.

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul at umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Chris Wing [mailto:wingc at engin.umich.edu]
> Sent: Tuesday, July 20, 1999 12:03 PM
> To: Neulinger, Nathan R.
> Cc: 'Jeffrey Hutzelman'; arla-drinkers at stacken.kth.se
> Subject: RE: proposed PAG handling changes for Arla
> 
> 
> Nathan:
> 
> > In fact, we make use of this behavior in AFS to clean out 
> the tokens out of
> > the kernel when users are gone and have no processes, even 
> though their
> > token hasn't expired.
> 
> I believe Arla's 'fs' command has a PAG garbage collection 
> option which
> does this automatically. In Arla, it's less of an issue since 
> the tokens
> are stored in user space, not kernel space. (arlad does all 
> the real work)
> 
> > If we don't, things get really slow cause the token/pag 
> structures get
> > enormous.
> 
> I haven't tried Arla on a machine with hundreds of users yet, 
> though...
> 
> > Besides, anyone with root is going to be able to attach to any users
> > processes with any number of different tools, and if you're 
> using kerberos,
> > they are going to be able to just access the credentials 
> cache directly.
> 
> From one point of view, there will always be a means to circumvent any
> security measure. In my opinion, this doesn't mean that we 
> shouldn't make
> a reasonable effort to prevent security problems from occurring.
> 
> If setgroups() can't be used to modify one's PAG, then more difficult
> avenues must be pursued. One could try mucking around in /dev/kmem or
> /dev/mem, for instance, but this too can be restricted: on 
> Linux, you can
> use capabilities to give a process the ability to use 
> setgroups() without
> giving it access to /dev/kmem or /dev/mem. On BSD, you can 
> increase the
> securelevel for the same effect.
> 
> The remaining hole would be the possibility of using ptrace 
> to attach to a
> running arlad and trying to steal the tokens that way. This 
> problem can be
> solved in Linux at least by making sure that arlad has full 
> capabilities;
> a process cannot ptrace another with greater capabilities in Linux,
> regardless of UID. Similar solutions probably present 
> themselves for other
> operating systems.
> 
> The problem of securing the tokens does become more difficult 
> the tighter
> the security is desired. I just think that for starters, we 
> should plug
> the most obvious hole.
> 
> Thanks,
> Chris
> 
> wingc at engin.umich.edu
>