you'd have to hijack the rx connection entirely or spoof all the relevan
fetchdata replies, but it coyuld be done
On Wed, 21 Mar 2007, Kim Kimball wrote:
DETAIL under ACKNOWLEDGMENTS, referring to
Benjamin Bennet from PSC seem less specific than
spoofing a FetchStatus reply.
"Connections other than those on behalf of a user
are thus not as
general practice authenticated, although it is
theoretically possible to do so.
Because the connection is not authenticated it is
possible to spoof network
traffic from the server without it being detected.
Trusting unauthentic server
answers to allow assignment of proper privilege
level can allow privilege escalation. "
My reading of this says that network traffic from
a server can be spoofed, in general, since an
anonymous user will operate over an
unauthenticated connection. If so it seems it
would be possible to place a file in the cache as
well as spoof status.
Those more knowledgeable please debunk!
Thanks.
Kim
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.
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
