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

From: Steve French
Date: Sat Apr 30 2005 - 10:56:41 EST

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@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at