We have a situation here where for various reasons we need to deal
with the possibility of host impersonation, where someone might take
over the IP address of a machine that's authorized to do NFS v3 mounts.
Our solution on our current Solaris fileservers is authenticating the
clients when and as they make NFS mounts through a callback process
based on intercepting netgroup membership checks with an NSS module.
We'd like to bring up some sort of host authentication on Linux so that
we can use Linux as an NFS server in our environment. Unfortunately a
straight port of our Solaris solution appears infeasible due to a glibc
issue[*], which leaves me looking around for ideas. The options that I
can think of now are:
- modify the mountd source to stuff in a callout to our authentication
system at mount time.
drawback: we'd have to maintain a custom hack to mountd (and figure
out where in the source to put it).
- use ipsec between clients and servers.
drawback: the ipsec overhead and speed reduction
- put together some firewall based system that only allows access to
the NFS and/or mountd ports after host verification.
drawback: I'd like to automatically trigger verification on mount
requests rather than require clients to trigger it in an out-of-band
way and I'm not sure if there's any easy way to do that.
(Perhaps the answer is the 'spawn' tcpwrappers option to trigger a
callout.)
Are there options that I'm not seeing here or that I haven't
considered? Are there good fixes to the drawbacks I've listed
that I'm not seeing?
Out of the options that people can see (possibly not just these ones),
what do people think would be the best way to do this?
(I suspect that there is no interest in adding some general system for
NFS mount authentication checks to mountd.)
Thanks in advance for any opinions et al that people feel like
offering.
PS: 'switch to NFS v4 to strongly authenticate user requests' is not an
option for us. We specifically value things that cannot be done
with true verification of user identification, like cron, and we
don't have and don't want to build the infrastructure that would
be required for strongly authenticated NFS v4.
- cks
[*: Building a NSS module that supports netgroup lookups requires using
an internal glibc header file to get a definition of a struct that
is passed to NSS netgroup lookup functions.
]
On Tue, Nov 04, 2014 at 11:53:13AM -0500, Chris Siebenmann wrote:
> [*: Building a NSS module that supports netgroup lookups requires using
> an internal glibc header file to get a definition of a struct that
> is passed to NSS netgroup lookup functions.
It seems like that's where you should attack the problem. I've Cced the
glibc list to open the question if they really intended it to be a
private interface.
And even if they do using it anyway and dealign with the fact that you
have to be extremly careful with libc updates still sounds a lot less
painful than the other options.
> On 11/04/2014 11:53 AM, Chris Siebenmann wrote:
> > PS: 'switch to NFS v4 to strongly authenticate user requests' is not an
> > option for us. We specifically value things that cannot be done
> > with true verification of user identification, like cron, and we
> > don't have and don't want to build the infrastructure that would
> > be required for strongly authenticated NFS v4.
> The exact same "strongly authenticate" that in v4 is available
> with v3. NFS secure mounts (-o krb5) are available
> with all NFS protocol versions.
>
> Tying NFS secure mounts with an FreeIPA environment should work
> out well..
NFS v4 isn't the problem; strong authentication of user identities (and
Kerberos) is the problem. Our environment and our users rely on the many
forms that setuid takes[*] and as far as I know those are impossible with
strong identification (in any NFS or remote filesystem protocol) because
the point of strong authentication is that the server no longer trusts
clients when they say 'honest, I'm working on behalf of uid <X>'.
(Instead the client must prove it by presenting a secret only the user
is supposed to have access to, which the user must have somehow loaded
on the client.)
- cks
[*: including but not limited to crontabs, .forward files, user run web
apps and CGI-BINs, and detached processes left running for weeks.
]
On Wed, 05 Nov 2014 11:45:55 -0500
Chris Siebenmann <[email protected]> wrote:
> > On 11/04/2014 11:53 AM, Chris Siebenmann wrote:
> > > PS: 'switch to NFS v4 to strongly authenticate user requests' is
> > > not an option for us. We specifically value things that cannot be
> > > done with true verification of user identification, like cron,
> > > and we don't have and don't want to build the infrastructure that
> > > would be required for strongly authenticated NFS v4.
> > The exact same "strongly authenticate" that in v4 is available
> > with v3. NFS secure mounts (-o krb5) are available
> > with all NFS protocol versions.
> >
> > Tying NFS secure mounts with an FreeIPA environment should work
> > out well..
>
> NFS v4 isn't the problem; strong authentication of user identities
> (and Kerberos) is the problem. Our environment and our users rely on
> the many forms that setuid takes[*] and as far as I know those are
> impossible with strong identification (in any NFS or remote
> filesystem protocol) because the point of strong authentication is
> that the server no longer trusts clients when they say 'honest, I'm
> working on behalf of uid <X>'.
On a Linux server you can use gss-proxy and give it authority to
impersonate any user through the s4u2proxy protocol.
It will require a KDC that can manage s4u2proxy (AD or FreeIPA).
> (Instead the client must prove it by presenting a secret only the user
> is supposed to have access to, which the user must have somehow loaded
> on the client.)
>
> - cks
> [*: including but not limited to crontabs, .forward files, user run
> web apps and CGI-BINs, and detached processes left running for weeks.
> ]
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> in the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Simo Sorce * Red Hat, Inc * New York
On 11/05/2014 11:45 AM, Chris Siebenmann wrote:
>> On 11/04/2014 11:53 AM, Chris Siebenmann wrote:
>>> PS: 'switch to NFS v4 to strongly authenticate user requests' is not an
>>> option for us. We specifically value things that cannot be done
>>> with true verification of user identification, like cron, and we
>>> don't have and don't want to build the infrastructure that would
>>> be required for strongly authenticated NFS v4.
>> The exact same "strongly authenticate" that in v4 is available
>> with v3. NFS secure mounts (-o krb5) are available
>> with all NFS protocol versions.
>>
>> Tying NFS secure mounts with an FreeIPA environment should work
>> out well..
>
> NFS v4 isn't the problem; strong authentication of user identities (and
> Kerberos) is the problem. Our environment and our users rely on the many
> forms that setuid takes[*] and as far as I know those are impossible with
> strong identification (in any NFS or remote filesystem protocol) because
> the point of strong authentication is that the server no longer trusts
> clients when they say 'honest, I'm working on behalf of uid <X>'.
Gotta... Interesting... I was just talking to a customer about
this very problem... Not being able to tie multiple GSS contexts
to a single uid...
steved.
>
> (Instead the client must prove it by presenting a secret only the user
> is supposed to have access to, which the user must have somehow loaded
> on the client.)
>
> - cks
> [*: including but not limited to crontabs, .forward files, user run web
> apps and CGI-BINs, and detached processes left running for weeks.
> ]
>
On 11/04/2014 11:53 AM, Chris Siebenmann wrote:
> PS: 'switch to NFS v4 to strongly authenticate user requests' is not an
> option for us. We specifically value things that cannot be done
> with true verification of user identification, like cron, and we
> don't have and don't want to build the infrastructure that would
> be required for strongly authenticated NFS v4.
The exact same "strongly authenticate" that in v4 is available
with v3. NFS secure mounts (-o krb5) are available
with all NFS protocol versions.
Tying NFS secure mounts with an FreeIPA environment should work
out well..
steved.