Jeff Layton jlayton at redhat.com
Sat Jan 21 05:37:20 MST 2012

On Sat, 21 Jan 2012 15:03:31 +1100
Andrew Bartlett <abartlet at samba.org> wrote:

> On Fri, 2012-01-20 at 14:45 -0600, Steve French wrote:
> > My general thinking on this is as follows:
> > 
> > If the kernel is distributed to all the workstations in an organization
> > with this Kconfig option disabled, it makes it harder for individual users
> > to make the mistake of enabling lanman (sec=lanman, or the Kconfig
> > option) on a public network and thus send weak password hashes
> > which could be discovered simply.   Most distros make the choice
> > of enabling broader compatibility with old pre-1997 servers but
> > it is a very small set of servers who would require lanman support,
> > and a large number of potential attackers who could benefit if
> > users enable lanman on a public network.  I suspect that there
> > are environments where removing code (via Kconfig) is preferred
> > to trusting all owners of all workstations running that organizations
> > standard linux to never enable lanman at runtime.
> > 
> > But ... the opinion of security specialists on this would be welcome.
> We have been though some of this with the kerberos libs, which now allow
> (default?) to not even compile with weak crypto.  If the weak crypto is
> not compiled in, it can therefore be asserted that the weak crypto
> cannot be used, and this makes it easier to comply with security
> audits/certification etc.
> I don't want to make your code more complex than it needs to be, but LM
> encryption really, really needs to go away.  If it is not a major
> bother, I would like to make it easier for that to happen if possible.

The only way for it to go away completely is for all servers that
support only that encryption to go away completely. Unfortunately,
that's a tall order -- there are still at least some in the field and
people need to get at data on them.

Jeff Layton <jlayton at redhat.com>

More information about the samba-technical mailing list