Filesystem Security: XFS
From linsec.ca
The XFS filesystem was created by SGI for the IRIX operating system and was later ported to Linux. As of the 2.5 (?) Linux kernel, it has been included as a supported filesystem "out of the box". XFS is a powerful enterprise-scale filesystem with the following features:
- XFS can recover data on a filesystem very quickly and accurately because it is a journaling filesystem. On very large partitions, this can save a lot of time as XFS does it's check in seconds rather than minutes, or even hours
- XFS can handle extremely large disk sizes because it is a 64-bit filesystem. It can handle file sizes as large as a million terabytes.
- XXFS can handle very fast disk writes in the order of multiple GB/sec. It also handles journaling transactions very quickly.
- XFS can utilize quotas and extended ACLs.
While XFS was designed for IRIX and currently has the most power and capabilities on that system, XFS is scalable enough to handle everything Linux will throw at it as the Linux kernel matures, grows, and becomes faster.
ACLs
XFS supports extended Access Control Lists which allow you to fine-tune permissions on your XFS filesystems. In order to utilize this, your kernel must be compiled with XFS ACL support; most kernels that support XFS also support XFS ACLs. There are four different ACL entry formats that can be used with the setfacl tool (comes in SGI's acl package):
- [d[efault]:][u[ser]:]uid[:perms] - Permissions of a named user. Permissions of the file owner if uid is empty.
- [d[efault]:]g[roup]:gid[:perms] - Permissions of a named group. Permissions of the owning group if gid is empty.
- [d[efault]:]m[ask][:][:perms] - Effective rights mask.
- [d[efault]:]o[ther][:][:perms] - Permissions of others.
A few examples are in order. Assume you have a file named file that is owned by the user joe and group joe and is mode 640; only the user joe has access to read and write to the file. However, assume you would like user frank to have read access to the file, without reducing the default permissions of the file, you would use:
# setfacl -m u:frank:r file
Where this really comes in handy is for the execution of certain files. Assuming you have an allergy to sudo and prefer using su directly, you could change the permissions of su from 4755 to 4700. This would only allow root to execute su (and keep the suid bit). You could then set ACLs like this:
# setfacl -m u:joe:rx /bin/su
Now, if anyone other than root or joe try executing su, they will get "permission denied". If user joe, however, executes su, he will be able to use it as he normally would.
You can view the ACLs for any file using the getfacl tool. The chacl tool allows you to change the ACLs associated with any file.
