"That Didn't Take Long" - which is a good thing. Fixing young code is always better than fixing old code. For obvious reasons.
Announcement
Collapse
No announcement yet.
That Didn't Take Long: KSMBD In-Kernel File Server Already Needs Important Security Fix
Collapse
X
-
-
Originally posted by ssokolow View Post
Rust would have helped with this part:
The failing to normalize paths before enforcing .. is just an embarrassing beginner's mistake. (I knew to make sure I was doing that for the IRC fserve script I never finished back in my late high school and early university years!)
Of course, in my case, it was more or less because I'd realized early on that the best way to handle security is to make it someone else's fault if the relevant code proves to be broken.
- Likes 8
Comment
-
Originally posted by uid313 View PostImagine if Microsoft would have put SMB/CIFS in the Windows kernel, we would all laugh and ridicule them!
There was even a presentation at a samba conference about this. If you want to look into this your self, boot up a Windows system and look in Windows\system32\drivers for mrxsmb.sys, mrxsmb20.sys,srv.sys, srvnet.sys, and srv2.sys.
I'll also add that macOS has a smb in-kernel driver (e.g. System/Library/Extensions/smbfs.kext), as does Solaris.
- Likes 24
Comment
-
Originally posted by Space Heater View Post
I'm not sure if this is a serious comment or not, but the Windows smb client and server do run in the kernel.
There was even a presentation at a samba conference about this. If you want to look into this your self, boot up a Windows system and look in Windows\system32\drivers for mrxsmb.sys, mrxsmb20.sys,srv.sys, srvnet.sys, and srv2.sys.
I'll also add that macOS has a smb in-kernel driver (e.g. System/Library/Extensions/smbfs.kext), as does Solaris.
- Likes 11
Comment
-
-
Originally posted by mdedetrich View PostIf you want performance you don't really have a choice
It's not like Linus et al are idiots, and they're the ones who approved this, but IMO that doesn't make it any less of a poor choice. I can understand being motivated to do it by history (e.g. "NFS is in the kernel already" etc), despite that being from a time where there were far fewer attacks taking place and the kernel was 1/1000th of its current size; or to win a benchmark against Windows Server etc, but it's still not the choice I'd have made: not least because eventually someone is going to argue that SMB4 "needs to" be in the kernel too, since NFS and SMB3 are, and SMB4 is a @#$%ing nightmare...
Still, at least THIS one was caught early.
- Likes 9
Comment
-
Originally posted by arQon View Post
No, you really do. We've DONE this already, getting samba to sustain GbE line rate on incredibly shitty hardware (as in dual-core 600MHz ARM with no RAM levels of "shitty"). Once you have zerocopy, there's almost nothing that actually *needs* to be in kernelspace because you just aren't making enough roundtrips for it to matter. Electing to massively increase the attack surface of the kernel for the sake of wringing the last few trivial drops of +perf out of something like this is simply a bad decision.
It's not like Linus et al are idiots, and they're the ones who approved this, but IMO that doesn't make it any less of a poor choice. I can understand being motivated to do it by history (e.g. "NFS is in the kernel already" etc), despite that being from a time where there were far fewer attacks taking place and the kernel was 1/1000th of its current size; or to win a benchmark against Windows Server etc, but it's still not the choice I'd have made: not least because eventually someone is going to argue that SMB4 "needs to" be in the kernel too, since NFS and SMB3 are, and SMB4 is a @#$%ing nightmare...
Still, at least THIS one was caught early.
- Likes 5
Comment
Comment