All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	samba-technical
	<samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org>
Subject: Re: [PATCH] cifs: eliminate CONFIG_CIFS_WEAK_PW_HASH
Date: Fri, 20 Jan 2012 16:01:05 -0500	[thread overview]
Message-ID: <20120120160105.5e2f7286@tlielax.poochiereds.net> (raw)
In-Reply-To: <CAH2r5ms6YbZp+erat9RQw7-vMxem6vLWp72Yaf=Z8d4p=4+BBQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Fri, 20 Jan 2012 14:45:48 -0600
Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.
> 

There are myriads of ways for someone to screw themselves if you give
them root access. This one is pretty low on the list.

Code quality is important for security too, and the writhing mass of
ifdefs below is impossible to parse by eye and therefore debug. At some
point we have to weigh what requires a Kconfig option, and what doesn't.

Given that this can be administratively prohibited at runtime, I see
absolutely no need to keep this Kconfig option around. It just adds a
maintenance burden for no benefit.

While it's well and good to say you want to hear from "security
specialists", I'm not sure what that means and it sounds awfully open
ended. Is a lack of objection sufficient for you to take this patch or
do you need something else?

[...]

> >> > diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
> >> > index 76e7d8b..0e56b1e 100644
> >> > --- a/fs/cifs/cifsglob.h
> >> > +++ b/fs/cifs/cifsglob.h
> >> > @@ -853,13 +853,8 @@ static inline void free_dfs_info_array(struct dfs_info3_param *param,
> >> >  #define   CIFSSEC_MAY_NTLM     0x00002
> >> >  #define   CIFSSEC_MAY_NTLMV2   0x00004
> >> >  #define   CIFSSEC_MAY_KRB5     0x00008
> >> > -#ifdef CONFIG_CIFS_WEAK_PW_HASH
> >> >  #define   CIFSSEC_MAY_LANMAN   0x00010
> >> >  #define   CIFSSEC_MAY_PLNTXT   0x00020
> >> > -#else
> >> > -#define   CIFSSEC_MAY_LANMAN    0
> >> > -#define   CIFSSEC_MAY_PLNTXT    0
> >> > -#endif /* weak passwords */
> >> >  #define   CIFSSEC_MAY_SEAL     0x00040 /* not supported yet */
> >> >  #define   CIFSSEC_MAY_NTLMSSP  0x00080 /* raw ntlmssp with ntlmv2 */
> >> >
> >> > @@ -870,23 +865,13 @@ require use of the stronger protocol */
> >> >  #define   CIFSSEC_MUST_NTLM    0x02002
> >> >  #define   CIFSSEC_MUST_NTLMV2  0x04004
> >> >  #define   CIFSSEC_MUST_KRB5    0x08008
> >> > -#ifdef CONFIG_CIFS_WEAK_PW_HASH
> >> >  #define   CIFSSEC_MUST_LANMAN  0x10010
> >> >  #define   CIFSSEC_MUST_PLNTXT  0x20020
> >> >  #ifdef CONFIG_CIFS_UPCALL
> >> >  #define   CIFSSEC_MASK          0xBF0BF /* allows weak security but also krb5 */
> >> > -#else
> >> > +#else /* UPCALL */
> >> >  #define   CIFSSEC_MASK          0xB70B7 /* current flags supported if weak */
> >> >  #endif /* UPCALL */
> >> > -#else /* do not allow weak pw hash */
> >> > -#define   CIFSSEC_MUST_LANMAN  0
> >> > -#define   CIFSSEC_MUST_PLNTXT  0
> >> > -#ifdef CONFIG_CIFS_UPCALL
> >> > -#define   CIFSSEC_MASK          0x8F08F /* flags supported if no weak allowed */
> >> > -#else
> >> > -#define          CIFSSEC_MASK          0x87087 /* flags supported if no weak allowed */
> >> > -#endif /* UPCALL */
> >> > -#endif /* WEAK_PW_HASH */
> >> >  #define   CIFSSEC_MUST_SEAL    0x40040 /* not supported yet */
> >> >  #define   CIFSSEC_MUST_NTLMSSP 0x80080 /* raw ntlmssp with ntlmv2 */
> >> >
-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

  parent reply	other threads:[~2012-01-20 21:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-20 20:25 [PATCH] cifs: eliminate CONFIG_CIFS_WEAK_PW_HASH Jeff Layton
     [not found] ` <1327091153-22391-1-git-send-email-jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-01-20 20:34   ` Steve French
     [not found]     ` <CAH2r5msOk=4rz_XUGi+GitzVGyJrSo9B1iGXdjz0Bnymzt0NyQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-20 20:38       ` Jeff Layton
     [not found]         ` <20120120153856.6ded308a-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2012-01-20 20:45           ` Steve French
     [not found]             ` <CAH2r5ms6YbZp+erat9RQw7-vMxem6vLWp72Yaf=Z8d4p=4+BBQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-20 21:01               ` Jeff Layton [this message]
     [not found]                 ` <20120120160105.5e2f7286-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2012-01-21  2:47                   ` Steve French
2012-01-21  4:03               ` Andrew Bartlett
2012-01-21 12:37                 ` Jeff Layton
     [not found]                   ` <20120121073720.3cf546fc-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2012-01-21 17:26                     ` simo
     [not found]                       ` <1327166803.2908.761.camel-akOVU7JyYd8WIfilqQrPtNi2O/JbrIOy@public.gmane.org>
2012-04-27 11:15                         ` Jeff Layton
     [not found]                           ` <20120427071548.4843f5cb-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>
2012-04-27 13:58                             ` Steve French
2012-04-27 15:14                               ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120120160105.5e2f7286@tlielax.poochiereds.net \
    --to=jlayton-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org \
    --cc=smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.