All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Bartlett <abartlet-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
To: Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Cc: simo <idra-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>,
	linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org
Subject: Re: [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals
Date: Tue, 15 Nov 2011 09:45:26 +1100	[thread overview]
Message-ID: <1321310728.5973.29.camel@ruth> (raw)
In-Reply-To: <20111114094449.66a35717-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>

On Mon, 2011-11-14 at 09:44 -0500, Jeff Layton wrote:

> The above scheme isn't perfect, but in many cases it will happen to
> work. It's true that there's no reliable mapping between DNS and
> samAccountName, but in a lot of cases the samAccountName *is* the
> capitalized host portion of the DNS name. Does it hurt anything to
> attempt to get a ticket with that name if "cifs/fqdn" fails?

We should never ask for a machine$ name.  It is always the wrong thing
to do, because it will only exist on AD servers, which already do the
mapping between cifs/foo and foo$ internally.  

We should also not map between cifs/ and host/ - cifs/ is a separate
service, just as nfs/ and http/ are. 

> Over the years, we've seen a lot of confused users on the list who are
> not sure what name they need to put in the host portion of the UNC to
> get their krb5 mount to work. This scheme seems like it'll make that a
> bit more forgiving.

I certainly understand the need to make krb5 more forgiving, and
certainly if the KDC indicates that cifs/foo does not exist, then
guessing the DNS domain and asking for cifs/foo.<guessed domain> is
reasonable.  

> If the wrong guesses just end up slowing down the upcall, then I'm ok
> with that. If they potentially open a security hole then that's another
> matter entirely. That's my main question here -- are we opening up any
> vulnerabilities with this scheme?

Each time you second-guess the name, you open up a small security hole,
because you potentially allow a connection that was to be to a trusted
host to be impersonated by less trusted member of the same kerberos
realm.  For that reason, any client-side canonicalisation should be
strictly limited.  

Furthermore, you may do more than just slow down the upcall - if you
connect to the right server with the wrong ticket (because you guessed
wrong - cifs vs host etc), the only way to find out is if the server
gives you a LOGON_FAILURE error, and I think this will be even harder to
debug. 

I do want kerberos to be easier to use, and to 'just work' more often.
I care passionately that Kerberos should be both secure and 'just work'
- falling back to NTLM is an even worse fate.  

I just want to ensure we do not become the source of new expected
behaviour patterns for non-AD domains (such as looking up foo$ or
host/foo for cifs shares), as once we start, it will be very hard to
undo. 

Andrew Bartlett

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

  parent reply	other threads:[~2011-11-14 22:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-14  1:17 [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals Jeff Layton
     [not found] ` <1321233448-13548-1-git-send-email-jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
2011-11-14  1:17   ` [PATCH 1/3] cifs.upcall: move to an on-stack princ buffer Jeff Layton
2011-11-14  1:17   ` [PATCH 2/3] cifs.upcall: move to Simo's suggested algorithm for picking a principal Jeff Layton
2011-11-14  1:17   ` [PATCH 3/3] cifs.upcall: try and guess the domain name on unqualified names Jeff Layton
2011-11-14  2:28   ` [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals Andrew Bartlett
2011-11-14  3:12     ` simo
     [not found]       ` <1321240351.3953.803.camel-akOVU7JyYd8WIfilqQrPtNi2O/JbrIOy@public.gmane.org>
2011-11-14 14:44         ` Jeff Layton
     [not found]           ` <20111114094449.66a35717-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2011-11-14 22:45             ` Andrew Bartlett [this message]
2011-11-14 23:04               ` simo
     [not found]                 ` <1321311883.3953.886.camel-akOVU7JyYd8WIfilqQrPtNi2O/JbrIOy@public.gmane.org>
2011-11-15  1:10                   ` Andrew Bartlett
2011-11-15 14:15                     ` Jeff Layton
     [not found]                       ` <20111115091510.167a9435-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2011-11-15 21:37                         ` Andrew Bartlett
2011-11-16 16:08                           ` simo
     [not found]                             ` <1321459686.3953.1053.camel-akOVU7JyYd8WIfilqQrPtNi2O/JbrIOy@public.gmane.org>
2011-11-17 10:16                               ` Andrew Bartlett
2011-11-17 13:12                                 ` Jeff Layton
     [not found]                                   ` <20111117081256.5801f389-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2011-11-18  0:47                                     ` Andrew Bartlett
  -- strict thread matches above, loose matches on Subject: below --
2011-11-15 11:18 Matthieu Patou
     [not found] ` <4EC24A9C.7080301-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
2011-11-15 13:46   ` 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=1321310728.5973.29.camel@ruth \
    --to=abartlet-eunubhrolfbytjvyw6ydsg@public.gmane.org \
    --cc=idra-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org \
    --cc=jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org \
    --cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@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.