The next release of the Linux kernel, 6.6 [will] include the KSMBD in-kernel server for the SMB networking protocol, developed by Samsung’s Namjae Jeon.

it has faced considerable security testing and as a result it is no longer marked as experimental.

It’s compatible with existing Samba configuration files.

But why is KSMBD important? First off, it promises considerable performance gains and better support for modern features such as Remote Direct Memory Access (RDMA)… KSMBD also adds enhanced security, considerably better performance for both single and multi-thread read/write, better stability, and higher compatibility. In the end, hopefully, this KSMBD will also mean easier share setups in Linux without having to jump through the same hoops one must with the traditional Samba setup.

  • @[email protected]
    link
    fedilink
    501 year ago

    KSMBD is also important in that placing such core server functionality right inside the kernel represents a significant potential attack surface for crackers. As one comment on Hacker News said “Unless this is formally proven or rewritten in a safer language, you’ll have to pay me in solid gold to use such a CVE factory waiting to happen.”

    Words to live by.

    • tal
      link
      fedilink
      25
      edit-2
      1 year ago

      There have been vulnerabilities on the TCP/IP stack on a number of platforms (maybe all?), and that’s a rather smaller attack surface.

      EDIT: It also looks like ksmbd has already built itself a bit of a security history:

      https://access.redhat.com/solutions/6991749

      EDIT2: A bad security history:

      https://lwn.net/Articles/871866/

      The commit history for ksmbd shows a steady stream of fixes, as expected. Worryingly, though, many of the problems being fixed are clearly security issues — not a good thing in a network filesystem implementation. Examples include:

      • The code to change ownership and permissions did not check existing file permissions first.
      • Failure to validate data lengths could lead to access to invalid data.
      • The server would blindly follow symbolic links during pathname lookup.
      • Numerous failures to validate buffer lengths, such as this one or this one.

      All of those fixes were applied after ksmbd landed in the mainline; there are others that came before. Currently, twelve fixes to ksmbd credit Coverity scans in their changelogs.

      Those would worry me if they showed up in a production userspace network filesystem.