Re: [Linux-cifsd-devel] [PATCH 2/5] cifsd: add server-side procedures for SMB3

Stefan Metzmacher
2021-03-22T13:26:46Z

[-- Attachment #1.1: Type: text/plain, Size: 2414 bytes --]

Am 22.03.21 um 07:50 schrieb Christoph Hellwig:
> On Mon, Mar 22, 2021 at 09:47:13AM +0300, Dan Carpenter wrote:
>> On Mon, Mar 22, 2021 at 02:13:41PM +0900, Namjae Jeon wrote:
>>> +static unsigned char
>>> +asn1_octet_decode(struct asn1_ctx *ctx, unsigned char *ch)
>>> +{
>>> + if (ctx->pointer >= ctx->end) {
>>> + ctx->error = ASN1_ERR_DEC_EMPTY;
>>> + return 0;
>>> + }
>>> + *ch = *(ctx->pointer)++;
>>> + return 1;
>>> +}
>>
>>
>> Make this bool.
>>
>
> More importantly don't add another ANS1 parser, but use the generic
> one in lib/asn1_decoder.c instead. CIFS should also really use it.

I think the best would be to avoid asn1 completely in the kernel
and do the whole authentication in userspace.

The kernel can only deal this blobs here, I don't there's need to
look inside the blobs.

1. ksmbd-mount would provide a fixed initial blob that's always
the same and will be returned in the
"2.2.4 SMB2 NEGOTIATE Response" PDU as SecurityBuffer

2. The kernel just blindly forwards the SecurityBuffer
of "2.2.5 SMB2 SESSION_SETUP Request" to userspace
together with the client provided SessionId (from
2.2.1.2 SMB2 Packet Header - SYNC) as well as
negotiated signing and encryption algorithm ids
and the latest preauth hash.

3. Userspace passes a NTSTATUS together with SecurityBuffer blob for the
2.2.6 SMB2 SESSION_SETUP Response back to the kernel:

- NT_STATUS_MORE_PROCESSING_REQUIRED (more authentication legs are required)
SecurityBuffer is most likely a non empty buffer

- NT_STATUS_OK - The authentication is complete:
SecurityBuffer might be empty or not
It also pass a channel signing key, a decryption and encrytion key
as well as the unix token ( I guess in the current form it's only uid/gid)
down to the kernel

- Any other status means the authentication failed, which is a hard error for the client

The PDU definitions are defined here:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/6eaf6e75-9c23-4eda-be99-c9223c60b181

I think everything else belongs to userspace.

Such a "simple" design for the kernel part, would mean that ksmbd-mount would do what the
kernel part is currently doing, but it also means it will be trivial to plug the userspace
part to samba's winbindd in future order to get domain wide authentication.

metze

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]