On Wed, 5 Feb 2014 10:56:39 -0500 Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
> Hi Neil!
>
>
> On Feb 4, 2014, at 10:09 PM, NeilBrown <neilb@xxxxxxx> wrote:
>
> > On Tue, 4 Feb 2014 11:20:52 -0500 "J. Bruce Fields" <bfields@xxxxxxxxxxxx>
> > wrote:
> >
> >> On Tue, Feb 04, 2014 at 09:34:52AM +1100, NeilBrown wrote:
> >>> Also, I've been wondering if we could avoid the need to explicitly enable
> >>> the gss stuff by gating it on the existence of /etc/krb5.keytab.
> >>> Do you think that would be reasonable?
> >>
> >> That would be great. I hate that people have to care about these
> >> support daemons, they should just be started automatically when they're
> >> needed.
> >>
> >> Is /etc/krb5.keytab the best indicator?
> >
> > I was hoping you would tell me. :-)
>
> rpc.gssd has to run in cases where there is no /etc/krb5.keytab. Remember the discussion we had last year about using root’s user credential as the client’s machine credential? We want the kernel to be able to find out whether there is a machine credential available, and one can be available even if there is no keytab.
Hi Chuck,
thanks for reminding me about that! Yes we clearly cannot key
off /etc/krb5.keytab for rpc.gssd.
Maybe /etc/krb5.conf? Seems a bit lame.
How about /etc/gssapi_mech.conf ?? rpc.gssd seems to exit if that doesn't
exist. What if systemd is told not to run rpc.gssd if that file is
missing?
I guess that otherwise we can make it on-by-default, but document that people
can turn it off with
systemctl mask rpc-gssd
which is probably easier that requiring "systemctl enable nfs-secure".
>
> > It occurred to me as a good test when I tried running rpc.svcgssd in a fresh
> > VM and it wouldn't start. I eventually found the error message complaining
> > that it couldn't find that file.
> >
> > It isn't perfect as an empty /etc/krb5.keytab will still result in failure
> > and exit. However if a sysadmin has created a keytab and is using NFS, it
> > seems reasonable to be ready to provide gss services.
> >
> > rpc.gssd doesn't fail in the same way, but it does complain if the file
> > doesn't exist, so I suspect it is at least a good indicator.
> >
> > The only thing that bothers me is that gssd is theoretically more general
> > than krb5. However as the reality seems to be that it is exactly krb5, I
> > don't let that bother me too much.
> >
> >>
> >> Simplest might be to start unconditionally and just not care if it
> >> fails. Or is there a problem cluttering up logs with unimportant
> >> failures?
> >
> > More a problem with starting things that aren't necessary, and possibly
> > leaving them running.
> > Every process you start adds a little to the boot time. We only get the best
> > experience if everyone contributes a little bit, no matter how little.
> > Also, every running process theoretically adds the to the attack service.
>
> rpc.gssd doesn’t expose a network listener. What attack vector is exposed by running rpc.gssd?
Not all attacks are external. Also not all decisions relating to security
are completely rational. And the 'attack surface' argument may apply better
to other services but might cause a spill-over to people not wanting to run
anything they don't have to.
>
> Why would we insist on using a potentially insecure mechanism to provide strong security?
>
> > So some people will definitely not want these processes to be started.
>
> How many such people are there? The trend I expect is that more and more people will want to use security features, and fewer will want “sec=sys,” especially if we work hard to make security features as painless as possible (as we should be doing).
I honestly don't know. I may be seeing spectres that aren't there. But I've
certainly heard a strong preference to not run unnecessary daemons more than
once in the past.
When NFS is only used over a tightly coupled local network (infiniband?) you
really do want sec=sys.
>
> It seems to me that provisionally starting rpc.gssd optimizes for a fairly uncommon case that will become less and less common going forward. I believe we should start designing as if security is the default use case. I would feel more comfortable if we knew more precisely what proportion of our users want to disable gssd and why.
>
> > i.e. I agree with SteveD:
> >> I think we want to stay away (and move away) from unconditionally
> >> starting anything…
>
> I believe we should make things simple both for us and for our customers. Thus I agree philosophically with the Gnome strategy of removing less frequently used configuration options to reduce complexity, make things easier to configure, more reliable, and easier to troubleshoot.
I certainly agree with making things simple. If we can make a configuration
irrelevant, e.g. by gets nfsd to auto-tune the number of threads so the
setting becomes pointless, then I've very happy to remove that sort of
configuration. But if a configuration option actually means something I
certainly don't want to remove it.
So I'm leaning towards having "systemctl {un,}mask rpc-gssd" be the
configuration tool for rpc.gssd.
Thanks,
NeilBrown
Attachment:
signature.asc
Description: PGP signature
