values for "client signing" and "server signing"

Andrew Bartlett abartlet at samba.org
Thu Oct 27 17:27:25 MDT 2011


On Wed, 2011-10-26 at 16:15 +0200, Stefan (metze) Metzmacher wrote:
> Hi,
> 
> the values for "client signing" and "server signing" are not very
> well defined (at least for me they are confusing).
> 
> static const struct enum_list enum_smb_signing_vals[] = {
>         {False, "No"},
>         {False, "False"},
>         {False, "0"},
>         {False, "Off"},
>         {False, "disabled"},
>         {True, "Yes"},
>         {True, "True"},
>         {True, "1"},
>         {True, "On"},
>         {True, "enabled"},
>         {Auto, "auto"},
>         {Required, "required"},
>         {Required, "mandatory"},
>         {Required, "force"},
>         {Required, "forced"},
>         {Required, "enforced"},
>         {-1, NULL}
> };
> 
> Globals.client_signing = Auto;
> Globals.server_signing = False;
> 
> From the smb.conf manpage:
> 
> client signing (G)
> 
>            This controls whether the client is allowed or required to
> use SMB signing. Possible values are auto,
>            mandatory and disabled.
> 
>            When set to auto, SMB signing is offered, but not enforced.
> When set to mandatory, SMB signing is
>            required and if set to disabled, SMB signing is not offered
> either.
> 
>            Default: client signing = auto
> 
> server signing (G)
> 
>            This controls whether the client is allowed or required to
> use SMB signing. Possible values are auto,
>            mandatory and disabled.
> 
>            When set to auto, SMB signing is offered, but not enforced.
> When set to mandatory, SMB signing is
>            required and if set to disabled, SMB signing is not offered
> either.
> 
>            Default: server signing = Disabled
> 
> "enabled" is not documented and seems to have the same behavior as "auto"
> in release up to 3.6.x.
> 
> However on the client side I see 4 possible states instead of 3:
> 1. never use signing
> 2. use signing if the server requires it
> 3. use signing if the server supports it
> 4. require smb signing
> 
> In master we support 4 possible states and we use the following logic:
> 
>         switch (signing_state) {
>         case false:
>                 /* never */
>                 allow_smb_signing = false;
>                 desire_smb_signing = false;
>                 mandatory_signing = false;
>                 break;
>         case true:
>                 /* if the server supports it */
>                 allow_smb_signing = true;
>                 desire_smb_signing = true;
>                 mandatory_signing = false;
>                 break;
>         default:
>         case Undefined:
>         case Auto:
>                 /* if the server requires it */
>                 allow_smb_signing = true;
>                 desire_smb_signing = false;
>                 mandatory_signing = false;
>                 break;
>         case Required:
>                 /* always */
>                 allow_smb_signing = true;
>                 desire_smb_signing = true;
>                 mandatory_signing = true;
>                 break;
>         }
> 
> In source4 we have this:
> static const struct enum_list enum_smb_signing_vals[] = {
>         {SMB_SIGNING_OFF, "No"},
>         {SMB_SIGNING_OFF, "False"},
>         {SMB_SIGNING_OFF, "0"},
>         {SMB_SIGNING_OFF, "Off"},
>         {SMB_SIGNING_OFF, "disabled"},
>         {SMB_SIGNING_SUPPORTED, "Yes"},
>         {SMB_SIGNING_SUPPORTED, "True"},
>         {SMB_SIGNING_SUPPORTED, "1"},
>         {SMB_SIGNING_SUPPORTED, "On"},
>         {SMB_SIGNING_SUPPORTED, "enabled"},
>         {SMB_SIGNING_REQUIRED, "required"},
>         {SMB_SIGNING_REQUIRED, "mandatory"},
>         {SMB_SIGNING_REQUIRED, "force"},
>         {SMB_SIGNING_REQUIRED, "forced"},
>         {SMB_SIGNING_REQUIRED, "enforced"},
>         {SMB_SIGNING_AUTO, "auto"},
>         {-1, NULL}
> };
> 
> In the client SMB_SIGNING_AUTO and SMB_SIGNING_SUPPORTED have the same
> behavior.
> But in the server SMB_SIGNING_AUTO triggers behavior depending on the
> server role,
> a dc requires signing, while other roles disable it by default.
> 
> Maybe we should add a SMB_SIGNING_DEFAULT "default" setting, which
> indicates the default
> value if not specified in the configuration.
> 
> Then remove SMB_SIGNING_AUTO and map "auto" to SMB_SIGNING_SUPPORTED.
> Then we could have a new "desired", "if_required" that maps to
> SMB_SIGNING_DESIRED
> and lets the client use signing if the server supports it.

I don't see the value in the desired setting, due to historical
behaviours of Windows clients and servers.  It seems to me that SMB
signing is only ever enabled on DCs, and there it is required.  I say
this because what is the value of negotiated SMB signing, when the
negotiation is subject to MITM attacks.  If SMB signing had been in the
protocols early enough, we could have required that session setup
packets be signed, and so had a sensible way to turn this off safely for
bulk data.  However, we don't, and as I understand it even SMB2 didn't
do this properly.

The choice of what options to present to the client depends on if we
wish to give users maximum choice, or just the options they can actually
use to improve network security:

Therefore, for the client, I see three settings:
 - disabled
 - default (use if available or required eg by the DC), matches windows
default as I recall
 - required (paranoid, for specialist environments)

On the server I see three settings:
 - disabled
 - default (off for normal servers, required for the DC)
 - required

The additional option of 'supported' (available but not required) on the
server are possible as well, but it would only be helpful for testing,
it would not improve network security because a MITM can just disable
it.  

On the client, I guess we can have the option of 'only if required' but
would anyone use it, given no servers set 'supported' due to the
performance cost?

The only other detail is to ensure that in our DC client code (eg
winbindd) we should ensure we require smb signing, to protect that
communication from alteration. 

I do appreciate you sorting out the options here, it is important to get
this in common, both for your work in the client libs, and for the work
towards a common loadparm.  I trust your judgement in working it out
from here.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org



More information about the samba-technical mailing list