Best Practice for Default Export Policy Rules

[delicate tusk]

Can anyone tell me what the best practice is for the default export policy on an SVM that contains both SMB and NFS volumes?
Traditionally, we've set the protocol to "cifs,nfs" and clientmatch to be "0.0.0.0/0", and the rorule to "any". Should the rwrule and superuser be "none"? The OnTap documentation and the Security Hardening Guide both say that even with "none", anonymous access is granted, which is confusing to me.

The SMB volumes all inherit the default policy, but the NFS volumes have individual policies that specify which clients can access them. For the NFS volumes, does the specific export policy assigned to the volume override the default policy set for the SVM? I'm worried that someone could possibly mount the SVM root and then traverse the underlying volumes.

Any help is appreciated!

[torn cobalt]

we have export policies only for our nfs3 volumes - we are not using nfs4 - and we have it not for our cifs volumes. ,where it is not necessary... and in the nfs ro policy we have only single ips for hosts which is operated by our linux administrator.... and we specified also in the rw policy /24 /or /32 and only for hosts and ranges which would need access. i cannot say if client match with 0.0.0.0/0 works in that way as you wanna have it

[pulsar harness]

The default policy is automatically applied to the root junction path /. If you use tighter policies for individual volumes further down in the path that's exactly right. You just have to ensure that the default policy on top won't block access you want to allow further down. That's why the default is rather wide. "none" will not grant access, but also won't block anything further down the path, unlike "never".
If you have no rules in the default policy (or whatever policy you use for /), then access to your volumes will fail.
The command export-policy check-access can help you understand the chain.

For best practise I would use a net definition that is as narrow as you can go / as wide as you have to. If all your nfs clients are in a class C net, then use that as default policy. No need for the whole world to snoop in your root.

[delicate tusk]

Thank for the responses... so, are there any security concerns if the svm default export policy looks like this?

`vserver policyname ruleindex protocol clientmatch rorule rwrule anon superuser allow-suid allow-dev

---

vs01 default 1 cifs,nfs 0.0.0.0/0 any any 65534 any true true`

Any NFS volumes in that SVM will have a more specific policy.
CIFs volumes in the SVM will inherit that default policy.
The NFS clients are not restricted to a particular subnet, so we can't really narrow down the default clientmatch at all.

[pulsar harness]

I have concerns allowing rw and superuser access.😁 I would set rwrule and superuser to "none" in the default policy.

[delicate tusk]

Thanks, @pulsar harness, that's what I was thinking.
That won't prevent any superuser or rw access to volumes in the SVM if there is a more specific rules assigned to them, right?

[valid swift]

I tend to keep cifs and nfs separate by mounting them under small "mount point" volumes under root so they have entirely different trees ... then exports for cifs aren't a problem at all unless you're mixing protocoll access to the same filesystems, and even then I keep them in different hierarchies

you don't have to have export rules for CIFS exported volumes at all if the cifs option "export policies enabled" isn't enabled