[OpenAFS] Re: [OpenAFS-announce] OpenAFS Security Advisory 2007-001:
privilege escalation in Unix-based clients
Wed, 21 Mar 2007 13:39:37 -0400
Jeffrey Altman wrote:
> Jason Edgecombe wrote:
>> Dr A V Le Blanc wrote:
>>> Hm, I have a difficulty about this one. We have a large number of
>>> to which some thousands of users have access, virtually none of which
>>> are authenticated in AFS. These systems have almost their entire
>>> /lib, /bin, and all of /usr in AFS. A substantial part of them
>>> would stop working if we had all suid/sgid programs disabled by
>>> default. Short of copying every single binary of this kind to the
>>> local disk and chmoding it, I can't think how we can cope with
>>> setting suid off. Are we to have a permanent security hole? Or is
>>> there another way of dealing with this?
>>> -- Owen
>> If these are Linux systems, then you could try doing a loopback mount
>> out of AFS. It's not as flexible, but would still work and would allow
>> suid even when AFS disallows it.
>> The basics are make a big file and format it as ext2/ext3/squashfs, put
>> all of your binaries in it. Copy that file out to AFS and have clients
>> mount that file as /usr, /lib, /bin.
> The issue is that copying files out of /afs that have the suid bit set
> is not safe as long as the cache contents were populated using an
> unauthenticated connection to the file servers. This is because when
> unauthenticated connections are used there is no keying material
> available to prevent modifications to either the status data that
> indicates that a file should or should not be executed suid or the
> contents of the file itself.
> It is for this reason that suid is being disabled by default. Of
> course, if you want to execute processes out of /afs suid you can
> do so simply by "fs setcell -cell <cellname> -suid". You do not
> need to use a loopback mount to work around the default settings of
> the cache manager.
> That being said, the only real workaround is to locally copy the
> files using authenticated connections
> <obtain tokens>
> fs flush <dir>
> fs flush <file>
> cp -p <file> /local/path
> chmod xxx /local/path
> and then execute the suid files from the local disk.
> There simply is no other method available at the moment within AFS.
> Jeffrey Altman
> Secure Endpoints Inc.
Ok, so the summary is that any file copied out of /afs while not
authenticated (system:anyuser) can be spoofed. If this correct?
Can this be done from a machine other than the client or server?
I use cfengine for management of some Linux machines. If I can't trust
the files in /afs, then I need to look at using cfengine's native
protocol to copy files instead of afs.
Can I run fs setcell in a startup script to get the same effect as
upgrading the client?