On Wednesday, March 28, 2007 04:16:38 PM -0500 "Christopher D. Clausen"
<cclausen@acm.org> wrote:
> Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
>> On Friday, March 23, 2007 10:04:28 AM -0400 Jeffrey Altman
>> <jaltman@secure-endpoints.com> 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) <jhutz+@cmu.edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA