Kerberized NFSv4 in a mixed OS environment

Keve

Keve

I am planning to set up a new network file share. The environment is not hostile, no more than 5 users. Still, for practical reasons (e.g. accidental delete or overwrite by the least experienced) the directory layout is designed that certain users get read access only to some folders, or no access at all. The rules are not complex, traditional POSIX file access permissions can handle the job.
I have reasons to avoid samba, hence the intention to try a kerberized NFSv4. No particular need for LDAP or NIS, and I would prefer to not have one, unless having one is a technical necessity. No Windows or Mac servers on the network (and we intend to keep it that way) so the use of an Active Directory or an OpenDirectory is not an option. Client computers are a mixture of FreeBSD, Linux, Windows and macOS/OSX/MacOS X.

I am in the design/preparation phase. I refreshed my knowledge with the current kerberos chapter of the FreeBSD Handbook, and also studied related pages on the web -of which I found Armin Moradi's walkthrough particularly useful.

docs.freebsd.org

Chapter 16. Security

Hundreds of standard practices have been authored about how to secure systems and networks, and as a user of FreeBSD, understanding how to protect against attacks and intruders is a must
docs.freebsd.org docs.freebsd.org

There is one detail I am apparently missing though, and could use your pointer or clarification. Armin's guide excludes the creation of his user accounts and the setup of access permissions each have to the shared folders. So I do not yet see how one user will have RW access while another only R or nothing.
I can set this up nicely using the POSIX file permissions of the FreeBSD server (NFSv4 file share and KDC being the same host). But I do not see the connection between the user accounts of the FreeBSD host (to whom the POSIX file permissions happen to belong), and the user principles created in kadmin. Is there a never mentioned and invisible/automatic/obvious/default relationship between host user-accounts and kerberos user-principals with a matching name? E.g. a FreeBSD user named docbrown has a connection to docbrown@KERBEROS.REALM? Because that is the only way that could explain how POSIX permissions would affect the connected network users. If there is no such invisible link between host user accounts and kerberos user principals (which sounds more realistic for me), then where and how can I define which local user account's access permission applies to which kerberos user principal. Or, how else would I set POSIX file permissions to a file or folder on the host for bifftannen@KERBEROS.REALM if the host recognizes no such account. Unless, some jiggery-pokery in PAM config makes the kerberos user principals known to the host OS. But no such thing is mentioned in the above two sources. Varying forms of which is however often mention when LDAP is introduced.

Do my logic and my questions make sense?
Am I on the right track with these? Or did I confuse things in a bad way?
So, what am I missing?
 
You can wrap it in a [noparse]...[/noparse] bbcode block. Or use [icode]...[/icode] for it. The forum software detects URLs and email addresses automagically and will make then 'clickable'.
 
If you does not enforce user access on the client side, it is possible for a client to authenticate to kerberos while mounting as another user id. If we ignore the mixed OS environment, NFS over TLS could achieve this.
With the --certuser option of rpc.tlsservd, the username that is part of the certificate will be used instead of the one that is provided by the RPC request header. With this you can control which user
can access which directory with more certainty.
 
SirDice said:
You can wrap it in a [noparse]...[/noparse] bbcode block. Or use [icode]...[/icode] for it. The forum software detects URLs and email addresses automagically and will make then 'clickable'.
Click to expand...
It took a little fiddling to keep the string bold-face without [B] and [/B] showing up in the text, but other than that, [noparse] worked like a charm.
 
monwarez said:
If you do not enforce user access on the client side, it is possible for a client to authenticate to kerberos while mounting as another user id.
Click to expand...
That sounds odd. And such case would indeed worry me.
I was under the impression that -sec=krb5p:krb5i:krb5 in the exports file would take care of this. Not having sys in the list (and making sure that any/all shares use the krb security options ONLY) should allow connections/mounts only to those with a valid kerberos ticket for the NFSv4 service of this host. As much as I understand how kerberos works, a user could only mount as a different user if she/he first kinits as that other user. Which would require that other user's password too.
However, this is all irrelevant until I understand how POSIX file permissions connect to kerberos user principals. LDAP users on the server and clients could explain this, but Armin's walkthrough specifically mentiones that in his case LDAP was not necessary, and I am interested in a similar setup, assuming it is possible.

The rpc.tlsservd is new for me. I would prefer not to bring in another player, but I will still look into that too, because it never hurts to learn what it can be used for.
 
Keve said:
Is there a never mentioned and invisible/automatic/obvious/default relationship between host user-accounts and kerberos user-principals with a matching name?
Click to expand...
Kerberos only does authentication not authorization.

Keve said:
E.g. a FreeBSD user named docbrown has a connection to docbrown@KERBEROS.REALM?
Click to expand...
Your /etc/krb5.conf defines a default realm. Any 'plain' user account is automatically matched with the same username in that default realm. Or you give it a fully qualified name, including the realm.
 
SirDice said:
Your /etc/krb5.conf defines a default realm. Any 'plain' user account is automatically matched with the same username in that default realm.
Click to expand...
Splendid. That might be the bit I was missing.
This is good enough now for me to test things in practice and see how they work out. ;-)
 
You must log in or register to reply here.
Back
Top