[OpenAFS] Re: [OpenAFS-announce] OpenAFS Security Advisory 2007-001: privilege escalation in Unix-based clients

[Jason Edgecombe]

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
>>> systems
>>> 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?

Jason