On Wednesday, March 28, 2007 04:16:38 PM -0500 "Christopher D. Clausen"
<[EMAIL PROTECTED]> wrote:
Jeffrey Hutzelman <[EMAIL PROTECTED]> wrote:
On Friday, March 23, 2007 10:04:28 AM -0400 Jeffrey Altman
<[EMAIL PROTECTED]> wrote:
Kim Kimball wrote:
I'm still wondering if
a. Removing system:anyuser from ACLs will prevent this privilege
escalation
b. Removing system:anyuser from ACLs except "system:anyuser l" will
prevent the privilege escalation (i.e. the only occurrence of
system:anyuser is with l permission)
Any definitive conclusions?
As has been discussed on this list over the last few days, modifying
the contents of unprotected data retrieved via anonymous connections
is just one form of attack that can be executed.
What Jeff is trying to say is "no".
Changing ACL's will not prevent this attack.
Changing servers will not prevent this attack.
Period.
The only way to prevent this attack is for clients not to honor suid
bits from sources not trusted _by the client_. Since the current AFS
client has no way to obtain a secure connection to the fileserver
with which the user cannot tamper, all sources must be considered
untrusted.
If there was a way to make the client only use encrypted connections
(force fs setcrypt on and ignore unencrypted connections) would that be
sufficient to prevent the privilege escalation?
No. Even if you could do that, the connections are encrypted and
authenticated using keys known to the user making the request. So a user
can spoof the response to his own (authenticated) request, indicating that
a file is suid 0 when it really is not.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
