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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]