[991] in arla-drinkers
RE: proposed PAG handling changes for Arla
daemon@ATHENA.MIT.EDU (Chris Wing)
Tue Jul 20 13:08:19 1999
From owner-arla-drinkers@stacken.kth.se Tue Jul 20 17:08:18 1999
Return-Path: <owner-arla-drinkers@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 25913 invoked from network); 20 Jul 1999 17:08:18 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 20 Jul 1999 17:08:18 -0000
Received: (from majordom@localhost)
by sundance.stacken.kth.se (8.8.8/8.8.8) id TAA11872
for arla-drinkers-list; Tue, 20 Jul 1999 19:03:37 +0200 (MET DST)
Received: from shaft.engin.umich.edu (wingc@shaft.engin.umich.edu [141.213.33.85])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id TAA11793
for <arla-drinkers@stacken.kth.se>; Tue, 20 Jul 1999 19:03:28 +0200 (MET DST)
Received: from localhost (wingc@localhost)
by shaft.engin.umich.edu (8.9.3/8.9.3) with ESMTP id NAA02795;
Tue, 20 Jul 1999 13:03:21 -0400
X-Authentication-Warning: shaft.engin.umich.edu: wingc owned process doing -bs
Date: Tue, 20 Jul 1999 13:03:21 -0400 (EDT)
From: Chris Wing <wingc@engin.umich.edu>
To: "Neulinger, Nathan R." <nneul@umr.edu>
cc: "'Jeffrey Hutzelman'" <jhutz@cmu.edu>, arla-drinkers@stacken.kth.se
Subject: RE: proposed PAG handling changes for Arla
In-Reply-To: <9DA8D24B915BD1118911006094516EAF029EEB00@umr-mail02>
Message-ID: <Pine.LNX.4.10.9907201211010.2654-100000@shaft.engin.umich.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-arla-drinkers@stacken.kth.se
Precedence: bulk
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@engin.umich.edu
