Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread

[Steve French <smfrench@austin.rr.com>]

J. Bruce Fields wrote:

>On Sat, Apr 30, 2005 at 08:28:27AM -0500, Steve French wrote:
>  
>
>>Miklos Szeredi wrote:
>>
>>    
>>
>>>>>- network/userspace filesystems should be fine aswell
>>>>>    
>>>>>
>>>>>          
>>>>>
>>>>They should, but again I wonder if NFS with all it's complexity is
>>>>being careful enough with what it accepts from the server.
>>>>  
>>>>        
>>>>
>>it is possible for the client to validate that the
>>server is who it says it is, and both NFSv4 (actually the newer NFS
>>RPC) and CIFS of course allow packet signing which helps, not sure if
>>AFS allows packet signing.
>>    
>>
>
>None of this helps in the situation Miklos is considering, where the
>attacker is a user on the client doing the mount.  So presumably the
>user gets to choose a server under his/her control, and all the
>authentication does is prove to the user that s/he got the right server,
>which doesn't protect the kernel at all.
>
>The only defense is auditing the client code's handling of data it
>receives from the server
>  
>
I agree that periodic auditing of returned data, and testing with 
intentionally corrupted server responses
is necessary and should continue.

But you bring up an interesting point about security policy.    For the 
case of evil user trying to mount
to evil server (e.g. one under evil user's control), in one sense it is 
no different than allowing a user to
mount an evil cdrom or usb storage device with evil contens - a device 
which may contain specially
crafted data (file and directory contents and metadata) designed to 
crash the system, but there is
a difference - for network filesystems the server also can delay the 
responses, throw away
the responses or corrupt the frame headers (this can just as often 
happen due to buggy network
hardware and routers too).  Obviously we need to continue to audit for 
both cases - but it would
not hurt to optionally verify that the server can prove its identity and 
prove that it has been properly
added to a security domain that you trust - ie allow an NFSv4 mount and 
the CIFS mount helper
to be configured/built so that users could only mount to servers that are:
    1) In the clients security domain (ie kerberos realm)
    2) In a trusted domain (realm)
IIRC this is already done for the case of some services such as winbind, 
and I vaguely remember
IBM OS/2 doing this (verifying the server's identity during mount) when 
using Kerberized SMB back in
the early 1990s in the Directory and Security server product.