lkml.org 
[lkml]   [2005]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] cifs: handle termination of cifs oplockd kernel thread
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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-30 17:58    [W:0.113 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site