Exploring identity squash with OCI File Storage service

June 9, 2022 | 14 minute read
Cody Brinkman
Cloud Architect
Text Size 100%:

Oracle Cloud Infrastructure (OCI) File Storage service provides a durable, scalable, secure, enterprise-grade network file system. Within File Storage, network file system (NFS) exports control client access to your file system. Each export includes client export options, which are several parameter options that specify the level of access granted to NFS clients when they mount the file system. In this blog, we explore one of these export options: Identity squash.

If you are looking for a deep dive into File Storage or NFS security, this blog isn’t for you. Until a month ago, I had never heard of identity squash. This blog was inspired by me hearing about identity squash, trying to set it up, and then struggling to fully understand and implement it with the documentation and blogs currently out there. Instead, I want this blog to be a jumping off point for File Storage and identity squash—something that teaches you the basics and encourages you to dig deeper. For more detailed information, refer to read the official OCI File Storage documentation or corresponding operating system documentation.

FSS concepts

Before jumping into identity squash, I want to discuss some of the key file storage concepts we use in this blog. You need some basic networking concepts to use File Storage, but I assume you know them and don’t discuss them in detail.

  • Mount target: An NFS endpoint that lives in a subnet of your choice and is highly available. A mount target provides the IP address or domain name system (DNS) name used in the mount command when connecting NFS clients and is what the file systems are made available through.

  • Export: Control how NFS clients access file systems when they connect to a mount target. A file system must have at least one export in one mount target for instances to mount the file system.

  • Export path: Uniquely identifies the file system within a mount target, letting you associate many file systems to a single mount target. This path is unrelated to any path within the file system itself, or the client mount point path.

  • Export options: Set of parameters within the export that specify the level of access granted to NFS clients when they connect to a mount target.

An image is useful for visualizing how these concepts work together.

A graphic depicting how File Storage service concepts interact.
Figure 1: File Storage service concepts visualized

Export options

Export options are a set of parameters that specify the level of access granted to NFS clients when they connect to a mount target. Let’s explore what these parameters are.

  • Source: The IP address or CIDR block of a connecting NFS client

  • Require privileged source port (true/false): Determines whether you need to connect from a privileged source port. Privileged ports are any port including 1–1023.

  • Access (Read-only or read/write): Specifies NFS client access

  • Identity squash (All, root, or none): Determines whether clients accessing the file system have their user ID (UID) and group ID (GID) remapped. UID and GID are Linux concepts for identifying users and groups and determining which system resources they can access.

There it is! We finally have our first definition of what identity squash is. Let’s investigate it more.

Identity squash

As stated in the File Storage service documentation, identity squash determines whether the source clients accessing the file have their UID and GID remapped. According to Go Linux Cloud, squash means to limit or destroy the power of the remote user.

Identity squash can be used to prevent users, including superusers (root), from having certain permissions on the mounted NFS volume. This process can help improve security posture by ensuring that no users, including root, mounting this export have root access to the filesystem.

File Storage has the following options for this identity squash parameter:

  • None (default): No users are remapped.

  • Root: Only the root user is remapped.

  • All: All users and groups are remapped.

By default, it maps UID and GID to anonymousUid (65534) and anonymousGid (65534), but you can also specify these values.

Setup

I have three exports mounted on the same virtual machine (VM) to three different directories under the /mnt folder to represent the three squash options: None, root, and all. I mounted the three exports to the same VM for simplicity, but they can also be on three separate machines. Ensure that you have proper networking setup. The following figure shows the reference architecture:

FSS Setup
Figure 2: Setup reference architecture

Next, let’s look at our export options.

A screenshot of the Export Details page in the Oracle Cloud Console showing the None export options
Figure 3: /None export options

A screenshot of the Export Details page in the Oracle Cloud Console showing theRootSquash export options Figure 4: /RootSquash export options

A screenshot of the Export Details page in the Oracle Cloud Console showing the AllSquash export options
Figure 5: /AllSquash export options

Last, let’s look at the file permissions in my /mnt directory.

A screenshot of the Linux file permissions code
Figure 6: Linux file permissions

We have 751 permissions for all three mounts of the file system, and all files in those directories. I also created user cody as a member of the cody group.

  • Owner, root, has read, write, and execute permissions (7)

  • Group, cody, has read and execute permissions (5)

  • Other, any user other than root or cody, have execute permissions (1)

Expected behavior

Before we test this setup, let’s look at the theory and predict what happens with each different squash option.

/None

We aren’t squashing any users in this export. So, all permissions should remain the same:

User Initial permissions Squashed? Final permissions
root read, write, execute No read, write, execute
cody read, execute No read, execute
other execute No execute

/RootSquash

We can now see squashing in action. We’re squashing root to anonymous user, so root has permissions squashed to others permissions: execute only. User cody remains untouched.

User Initial Permissions Squashed? Final Permissions
root read, write, execute Yes execute
cody read, execute No read, execute
other execute No execute

/AllSquash

All users are now squashed to the other user permissions, so every user can execute only.

User Initial Permissions Squashed? Final Permissions
root read, write, execute Yes execute
cody read, execute Yes execute
other execute Yes execute

Actual behavior

Let’s jump into our VM and see what happens! If you don’t want to inspect all the image outcomes, see the Results Summary.

/None

Can root read? Yes!

A screenshot of the output showing that root can read in /None.
Figure 7: root can read in /None

Can root write? Yes!

A screenshot of the output showing that root can write in /None.
Figure 8: root can write in /None

Can root execute? Yes!

A screenshot of the output showing that root can run in /None.
Figure 9: root can execute in /None

Can cody read? Yes!

A screenshot of the output showing that cody can read in /None
Figure 10: cody can read in /None

Can cody write? No.

A screenshot of the output showing that cody can't write in /None
Figure 11: cody can’t write in /None

Can cody execute? Yes!

A screenshot of the output showing that cody can run in /None
Figure 12: cody can execute in /None

Can another user, represented by opc, read? No.

other cannot read in /None
Figure 13: other can't read in /None

Can other write? No.

A screenshot of the output showing that other can't write in /None
Figure 14: other cannot write in /None

Can other execute? Yes!

A screenshot of the output showing that other can run in /None.
Figure 15: other can execute in /None

/RootSquash

Can root read? No.

root cannot read in /RootSquash
Figure 16: root cannot read in /RootSquash

Can root write? No.

root cannot write in /RootSquash
Figure 17: root cannot write in /RootSquash

Can root execute? Yes!

root can run in /RootSquash
Figure 18: root can execute in /RootSquash

Can cody read? Yes!

cody can read in /RootSquash
Figure 19: cody can read in /RootSquash

Can cody write? No.

cody cannot write in /RootSquash
Figure 20: cody cannot write in /RootSquash

Can cody execute? Yes!

cody can run in /RootSquash
Figure 21: cody can execute in /RootSquash

Can other read? No.

other cannot read in /RootSquash
Figure 22: other cannot read in /RootSquash

Can other write? No.

other cannot write in /RootSquash
Figure 23: other cannot write in /RootSquash

Can other execute? Yes!

other can run in /RootSquash
Figure 24: other can execute in /RootSquash

/AllSquash

Can root read? No.

root cannot read in /AllSquash
Figure 25: root cannot read in /AllSquash

Can root write? No.

root cannot write in /AllSquash
Figure 26: root cannot write in /AllSquash

Can root execute? Yes!

root can run in /AllSquash
Figure 27: root can execute in /AllSquash

Can cody read? No.

cody cannot read in /AllSquash
Figure 28: cody cannot read in /AllSquash

Can cody write? No.

cody cannot write in /AllSquash
Figure 29: cody cannot write in /AllSquash

Can cody execute? Yes!

cody can run in /AllSquash
Figure 30: cody can execute in /AllSquash

Can other read? No.

other cannot read in /AllSquash
Figure 31: other cannot read in /AllSquash

Can other rrite? No.

other cannot write in /AllSquash
Figure 32: other cannot write in /AllSquash

Can other execute? Yes!

other can run in /AllSquash
Figure 33: other can execute in /AllSquash

Results summary

/None

User Expected behavior Actual behavior
root read, write, execute read, write, execute
cody read, execute read, execute
other execute execute

/RootSquash

User Expected behavior Actual behavior
root execute execute
cody read, execute read, execute
other execute execute

/AllSquash

User Expected behavior Actual Bbehavior
root execute execute
cody execute execute
other execute execute

Our predictions were all correct! In /None, nothing was squashed, and permissions were the same as they showed in Linux. In /RootSquash, root was squashed to same permissions as other (other), but cody’s permissions remained the same. In /AllSquash, all users had their permissions squashed to other.

Conclusion

In this blog we learned how identity squashing helps improve NFS security by preventing root ownership of file systems by "squashing" permissions to an anonymous UID, GID, or another user of your choice. After learning this concept, we saw it in action by mounting the same file system with all three File Storage service squashing options—None, root, and all—and seeing how permissions are changed for users in each scenario. With no squashing, all users had their expected permissions. With root squashing, only the root user was squashed. In all squashing, all users were squashed.

Identity squashing is only one aspect of securing Oracle Cloud Infrastructure File Storage service. Other export options include restricting access based on source IP or port and specifying a client as read-only. I encourage you to read more about export options.

If you want to try this lab for yourself, check out Oracle Cloud’s Free Tier with US$300 credits for a 30-day free trial. Free Tier also includes several Always Free services that are available for an unlimited time, even after your credits expire.

Cody Brinkman

Cloud Architect

Cody is a Cloud Architect for Oracle Cloud's Commercial accounts


Previous Post

A more sustainable business with cloud

Niharika Kalra | 4 min read

Next Post


How to use EPM Automate and Oracle Object Storage for automated EPM Cloud backups and restore

Mayank Kakani | 9 min read