That Didn't Take Long: KSMBD In-Kernel File Server Already Needs Important Security Fix

[intelfx]

<...> all reasons why it is better in kernel should be solved <...>

Yeah, just a sec, right after solving wars, pollution and inequality. Very easy thing to say, very hard thing (almost impossible) to do.

Reality is that for Linux, this train has already sailed. It's a firmly monolithic kernel, for better or worse.

[domih]

Always, always remove ../ : /universe/milkyway/solarsystem/earth/../../../../ ?

[Etherman]

It's not mandatory. Just say <n> if you don't need it.

[zboszor]

Calm down people, it's a storm in a teapot. KSMBD was merged into 5.15-rc1 and this file leak was fixed in -rc2, none of which are to be used in production.

[sverris]

Yes, but code that doesn't need to be fixed is better than code that's fixed quickly.

I tend to agree...

[sdack]

It's not mandatory. Just say <n> if you don't need it.

This, so much. I do not get all them idiots, control freaks and jerks, whose only idea is to take it away for everyone instead of leaving users a choice. These people should not be allowed to post ... Oh, wait, it would be ironic to deny them the choice of talking shit on the Internet, wouldn't it?

But more seriously, I am surprised that this bug slipped through. There should be an automated test for all of the kernel to check for the use of uncanonicalized paths. There is a lot more code, which can have the same issue, and it is indeed a common attack vector. This type of bug should not need to be checked by hand for every patch submission any longer.

[mdedetrich]

But more seriously, I am surprised that this bug slipped through. There should be an automated test for all of the kernel to check for the use of uncanonicalized paths. There is a lot more code, which can have the same issue, and it is indeed a common attack vector. This type of bug should not need to be checked by hand for every patch submission any longer.

Yeah I don't know precisely how kernel contributions are done, but this kind of code is typically always covered by a test and if no test is given then the code is basically refused until tests are provided. Its not only checking that the code is actually working when submitted but its also to prevent regressions when refactoring/maintenance is done.

This seems like very low code quality standards to me :/

[pininety]

Reality is that for Linux, this train has already sailed. It's a firmly monolithic kernel, for better or worse.

While I agree with you, I always have to wonder if it is not possible to build both. For example, if we were able to design a protocol which can be either be transparently compiled out (i.e. no performance overhead) if you want a monolithic kernel or if you want a microkernel allow different modules to be in userspace and only communicate via this protocol, you could have both. Testing would also become much more easy. But I guess such a magic protocoll is impossible.

[mdedetrich]

While I agree with you, I always have to wonder if it is not possible to build both. For example, if we were able to design a protocol which can be either be transparently compiled out (i.e. no performance overhead) if you want a monolithic kernel or if you want a microkernel allow different modules to be in userspace and only communicate via this protocol, you could have both. Testing would also become much more easy. But I guess such a magic protocoll is impossible.

sel4 did this. By protocol you are kind of implying microkernel with message passing however sel4 does some optimizations which make the fastest microkernel to date. You can check their IPC mechanism here https://docs.sel4.systems/Tutorials/ipc.html . You can read their general page at https://docs.sel4.systems/projects/s...questions.html

I guess another compromise would be too have a monolithic kernel but write it in a language that has much better guarantees (such as Rust) and implement various components as dynamic libraries but for this to work you would need a stable ABI, Rust has one bit it is more limited than C https://docs.rs/abi_stable/0.10.2/abi_stable/ (apparently it doesn't support unloading).

[ssokolow]

apparently it doesn't support unloading

I believe that's because such a plugin system would use dlopen or equivalent and POSIX doesn't require that dlclose be thorough enough to be suitable for unloading and reloading plugins. (I remember reading somewhere that you're out of luck if you want runtime unloading of dlopen-based plugins on macOS, for example.)

Don't quote me on this, but I don't think stable_abi imposes a specific loading mechanism... I think it's just an abstraction for doing Rust-to-Rust FFI on top of the C ABI. (If that's true, then you could get unloadable modules just by implementing your own dlopen alternative.)

EDIT: Yeah. Apparently it's enough of a thing that the Objective-C runtime will actually dlopen the library a second time to protect you from yourself.