[Samba] 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

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.

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?

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?

Am I correct in thinking this would make all shares have the same
password as the guest user, or do you mean there really is no password
at all, or alternatively that one would specify the share, provide
it's password and be logged on as guest???

It's been a while since I had a security=share setup, but I remember
WfW clients thinking that they had per-share passwords...