samba - Feb 2012 - Proposal to change security=share in Samba 4.0

I recently proposed on samba-technical that for Samba 4.0, that we
change security=share to have the following semantics:

 - All connections are made as the guest user
 - No passwords are required, and no other accounts are available.

Naturally, full user-name/password authentication remain available in
security=user and above.

The rationale is that we need a very simple way to run a 'trust the
network' Samba server, where users mark shares as guest ok.  I want to
keep these simple configurations working.

At the same time, I want to close the door on one of the most arcane
areas of Samba authentication.  The problem comes from the fact that
Samba never implemented security=share properly:  instead of having one
password per share, we tried to guess the username, and match that to a
username/password pair. 

Not only is this code complex, it begins to fail with modern clients and
modern security settings.  For example, NTLMv2 relies on the username
and workgroup, but clients which send NTLMv2 do not send these in the
'tree connect' request that contains the password.  Instead, we must
remember the previous unchecked 'session setup', and apply the password
from there.  If we instead guess the username, then NTLMv2 will not
work.

Finally, Samba clients only send LM passwords to security=share servers.
LM passwords are very insecure, and are now off by default.  As such,
Samba clients will not connect to any server running security=share by
default.

If you use security=share, and feel that your particular configuration
cannot be handled any other way, please let me know, so we can find the
best to handle your particular requirements. 

Thanks, 

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

On 02/27/2012 04:58 AM, Andrew Bartlett wrote:
> I recently proposed on samba-technical that for Samba 4.0, that we
> change security=share to have the following semantics:
> 
>  - All connections are made as the guest user
>  - No passwords are required, and no other accounts are available.
> 
> Naturally, full user-name/password authentication remain available in
> security=user and above.
> 
> The rationale is that we need a very simple way to run a 'trust the
> network' Samba server, where users mark shares as guest ok.  I want to
> keep these simple configurations working.
> 
> At the same time, I want to close the door on one of the most arcane
> areas of Samba authentication.  The problem comes from the fact that
> Samba never implemented security=share properly:  instead of having one
> password per share, we tried to guess the username, and match that to a
> username/password pair. 
> 
> Not only is this code complex, it begins to fail with modern clients and
> modern security settings.  For example, NTLMv2 relies on the username
> and workgroup, but clients which send NTLMv2 do not send these in the
> 'tree connect' request that contains the password.  Instead, we
must
> remember the previous unchecked 'session setup', and apply the
password
> from there.  If we instead guess the username, then NTLMv2 will not
> work.
> 
> Finally, Samba clients only send LM passwords to security=share servers.
> LM passwords are very insecure, and are now off by default.  As such,
> Samba clients will not connect to any server running security=share by
> default.
> 
> If you use security=share, and feel that your particular configuration
> cannot be handled any other way, please let me know, so we can find the
> best to handle your particular requirements. 
> 
> Thanks, 
> 
> Andrew Bartlett
Is there any reason we can not do away with "security = share" and get
rid of this altogether?  Was there not a prior proposal to deprecate
this back in the early days of 3.0.x?

- John T.

On Mon, Feb 27, 2012 at 09:58:44PM +1100, Andrew Bartlett
wrote:
> I recently proposed on samba-technical that for Samba 4.0, that we
> change security=share to have the following semantics:
> 
>  - All connections are made as the guest user
>  - No passwords are required, and no other accounts are available.
> 
> Naturally, full user-name/password authentication remain available in
> security=user and above.
> 
> The rationale is that we need a very simple way to run a 'trust the
> network' Samba server, where users mark shares as guest ok.  I want to
> keep these simple configurations working.
> 
> At the same time, I want to close the door on one of the most arcane
> areas of Samba authentication.  The problem comes from the fact that
> Samba never implemented security=share properly:  instead of having one
> password per share, we tried to guess the username, and match that to a
> username/password pair. 
> 
> Not only is this code complex, it begins to fail with modern clients and
> modern security settings.  For example, NTLMv2 relies on the username
> and workgroup, but clients which send NTLMv2 do not send these in the
> 'tree connect' request that contains the password.  Instead, we
must
> remember the previous unchecked 'session setup', and apply the
password
> from there.  If we instead guess the username, then NTLMv2 will not
> work.
> 
> Finally, Samba clients only send LM passwords to security=share servers.
> LM passwords are very insecure, and are now off by default.  As such,
> Samba clients will not connect to any server running security=share by
> default.
> 
> If you use security=share, and feel that your particular configuration
> cannot be handled any other way, please let me know, so we can find the
> best to handle your particular requirements. 
I'm mostly ok with this, but I'd like to hear from people supporting
paying clients, to make sure we're not breaking a customer setup
that a NAS box might depend on.

Jeremy.

After feedback from my previous proposal, I am proposing to totally
remove security=share from Samba 4.0.  security=share has been
deprecated since Samba 3.6.

The attached patch shows the removal (a lot of complex code is going
away, which I think is a very good thing).   

Naturally, full user-name/password authentication remain available in
security=user and above.

The rationale is that for the bulk of security=share users, we just we
need a very simple way to run a 'trust the network' Samba server, where
users mark shares as guest ok.  This is still supported, and the
smb.conf options are documented at
https://wiki.samba.org/index.php/Public_Samba_Server

At the same time, I want to close the door on one of the most arcane
areas of Samba authentication.

If you have any concerns about this, please let me know,

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-s3-auth-Remove-security-share.patch
Type: text/x-patch
Size: 63004 bytes
Desc: not available
URL:
<http://lists.samba.org/pipermail/samba/attachments/20120301/8d72e099/attachment.bin>