[995] in arla-drinkers
RE: proposed PAG handling changes for Arla
daemon@ATHENA.MIT.EDU (Neulinger, Nathan R.)
Tue Jul 20 15:28:06 1999
From owner-arla-drinkers@stacken.kth.se Tue Jul 20 19:28:05 1999
Return-Path: <owner-arla-drinkers@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 27878 invoked from network); 20 Jul 1999 19:28:03 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 20 Jul 1999 19:28:03 -0000
Received: (from majordom@localhost)
by sundance.stacken.kth.se (8.8.8/8.8.8) id VAA15412
for arla-drinkers-list; Tue, 20 Jul 1999 21:23:05 +0200 (MET DST)
Received: from umr.edu (hermes.cc.umr.edu [131.151.1.68])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id VAA15406
for <arla-drinkers@stacken.kth.se>; Tue, 20 Jul 1999 21:22:57 +0200 (MET DST)
Received: from umr-mail01.cc.umr.edu (umr-mail01.cc.umr.edu [131.151.37.121]) via ESMTP by hermes.cc.umr.edu (8.8.7/R.4.20) id OAA03444; Tue, 20 Jul 1999 14:22:41 -0500 (CDT)
Received: by umr-mail01 with Internet Mail Service (5.5.2448.0)
id <3598W8XR>; Tue, 20 Jul 1999 14:22:40 -0500
Message-ID: <9DA8D24B915BD1118911006094516EAF029EEB02@umr-mail02>
From: "Neulinger, Nathan R." <nneul@umr.edu>
To: "'Chris Wing'" <wingc@engin.umich.edu>
Cc: arla-drinkers@stacken.kth.se
Subject: RE: proposed PAG handling changes for Arla
Date: Tue, 20 Jul 1999 14:22:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="ISO-8859-1"
Sender: owner-arla-drinkers@stacken.kth.se
Precedence: bulk
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@umr.edu
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
> -----Original Message-----
> From: Chris Wing [mailto:wingc@engin.umich.edu]
> Sent: Tuesday, July 20, 1999 12:03 PM
> To: Neulinger, Nathan R.
> Cc: 'Jeffrey Hutzelman'; arla-drinkers@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@engin.umich.edu
>
