Skip to contentSkip to conversation

Secure NFSv4 mounts and daemons

DISCUSSION Ralph Zack 4 participants 5 messages Jan 14, 2015 – Jan 17, 2015

Subsystems (2)
lore
Share & tools
lore

Ralph Zack

author
#0 lore raw

Hi all,

I have a number of NFSv4 shares which should only be accessible after successful authentication, for which reason they are exported with sec=krb5p. However, this method requires the user to obtain a kerberos ticket to access files on the share, which is fine for regular users but causes issues for daemons which are not kerberos-aware.

What is the common way to handle this problem? It can hardly be the only solution to patch each service to obtain a ticket at startup. Please correct me if I'm wrong, but I could not find any mechanism besides kerberos that provides encryption and authentication for NFS shares. I'd be fine with authentication on a host level, I mainly want to ensure that only trusted machines can accesses these shares and that all traffic is encrypted. Without the overhead of establishing a VPN connection between client and server, in case anyone was going to suggest that ;)

Cheers,

Ralph

#1 lore raw

Hi Ralph,

Op 15-01-15 om 00:12 schreef Ralph Zack:

Quoted 8 lines

Hi all,

I have a number of NFSv4 shares which should only be accessible after successful authentication, for which reason they are exported with sec=krb5p. However, this method requires the user to obtain a kerberos ticket to access files on the share, which is fine for regular users but causes issues for daemons which are not kerberos-aware.

Quoted 9 lines

What is the common way to handle this problem? It can hardly be the only solution to patch each service to obtain a ticket at startup. Please correct me if I'm wrong, but I could not find any mechanism besides kerberos that provides encryption and authentication for NFS shares. I'd be fine with authentication on a host level, I mainly want to ensure that only trusted machines can accesses these shares and that all traffic is encrypted. Without the overhead of establishing a VPN connection between client and server, in case anyone was going to suggest that ;)

I've once seen that something like this makes a ticket:
su -c "echo password | kinit user" user
But never used it in reality.

Maybe you can ask this question better in the Kerberos mailinglist. I think this is not a good solution...

With regards,
Paul van der Vlis

Signature · 2 lines
Paul van der Vlis Linux systeembeheer, Groningen
http://www.vandervlis.nl/
#2 lore raw
Quoted 25 lines · Paul van der Vlis

Hi Ralph,

Op 15-01-15 om 00:12 schreef Ralph Zack:

Quoted 8 lines

Hi all,

I have a number of NFSv4 shares which should only be accessible after successful authentication, for which reason they are exported with sec=krb5p. However, this method requires the user to obtain a kerberos ticket to access files on the share, which is fine for regular users but causes issues for daemons which are not kerberos-aware.

Quoted 9 lines

What is the common way to handle this problem? It can hardly be the only solution to patch each service to obtain a ticket at startup. Please correct me if I'm wrong, but I could not find any mechanism besides kerberos that provides encryption and authentication for NFS shares. I'd be fine with authentication on a host level, I mainly want to ensure that only trusted machines can accesses these shares and that all traffic is encrypted. Without the overhead of establishing a VPN connection between client and server, in case anyone was going to suggest that ;)

I've once seen that something like this makes a ticket:
su -c "echo password | kinit user" user
But never used it in reality.

Quoted 5 lines

Maybe you can ask this question better in the Kerberos mailinglist. I think this is not a good solution...

With regards,
Paul van der Vlis

Wow, looks like kinit /will/ read your password from stdin. I had no idea.

I've done this with a keytab and cron job running as the service's user to keep the credential caches for the service's user fresh. Kinit should be something like kinit -kt /keyab/file batch/[email protected] Run your jobs more frequently than the ticket expiry time and everything should be fine.

Ben

author
#3 lore raw
Quoted 7 lines · Benjamin Coddington

Wow, looks like kinit /will/ read your password from stdin. I had no idea.

I've done this with a keytab and cron job running as the service's user to keep the credential caches for the service's user fresh. Kinit should be something like kinit -kt /keyab/file batch/[email protected] Run your jobs more frequently than the ticket expiry time and everything should be fine.

That is pretty much what I had in mind if there was no better solution. It just seemed bit hacky to me and I thought there was maybe a more elegant solution, but I may end up doing it like that.

Quoted 3 lines · Anthony Messina

I use GSS-Proxy for this:
https://fedorahosted.org/gss-proxy/

That looks very interesting at first glance, I'll have a closer look at it. Thanks!

- Ralph

#4 lore raw
In reply to Ralph Zack
Quoted 6 lines · Ralph Zack

I have a number of NFSv4 shares which should only be accessible after successful authentication, for which reason they are exported with sec=krb5p. However, this method requires the user to obtain a kerberos ticket to access files on the share, which is fine for regular users but causes issues for daemons which are not kerberos-aware.

Quoted 9 lines

What is the common way to handle this problem? It can hardly be the only solution to patch each service to obtain a ticket at startup. Please correct me if I'm wrong, but I could not find any mechanism besides kerberos that provides encryption and authentication for NFS shares. I'd be fine with authentication on a host level, I mainly want to ensure that only trusted machines can accesses these shares and that all traffic is encrypted. Without the overhead of establishing a VPN connection between client and server, in case anyone was going to suggest that

I use GSS-Proxy for this:
https://fedorahosted.org/gss-proxy/

-A

Signature · 2 lines
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E