Support for non-local file systems?

[scholarsmate]

In the fapolicyd.conf(5) man page, we see this text:

watch_fs
              This is a comma separated list of file systems that should be watched for access permission.  No attempt is made to
              validate the file systems names. They should exactly match the name presented in the first column of /proc/mounts.
              If this is not configured, it will default to watching ext4, xfs, and tmpfs.

A common thing for organizations is to NFS mount user home directories from a file server so people's files kind of follow them around from system to system. For most users, they can read / write files they own in $HOME and /tmp and create files in those same locations and much of the rest of the system is immutable for them. It would be beneficial if we can whitelist non-local files systems like NFS, or CIFS mounts and perhaps even FUSE file systems like SSHFS. When I take a look at the first column in /proc/mounts, I get something like this (showing counts and the fs):

$ sudo cat /proc/mounts | awk '{print $1}' | sort | uniq -c | sort -nbr
     12 cgroup
      5 tmpfs
      1 tracefs
      1 systemd-1
      1 sysfs
      1 sunrpc
      1 selinuxfs
      1 securityfs
      1 pstore
      1 proc
      1 mqueue
      1 hugetlbfs
      1 devtmpfs
      1 /dev/sda1
      1 devpts
      1 /dev/mapper/cl-root
      1 /dev/mapper/cl-home
      1 debugfs
      1 configfs
      1 bpf
      1 binfmt_misc
      1 192.168.1.101:/home/

Does / Can fapolicyd support non-local file systems and if so, are there any caveats to be aware of? I can think of one, which is the IMA support since IMA file metadata is currently only available for local files systems (NFS might work with IMA soon - https://tools.ietf.org/id/draft-ietf-nfsv4-integrity-measurement-06.html and https://patchwork.kernel.org/cover/10843189/).

[stevegrubb]

It should be easy enough to test. As long as the file system type is enabled for watch_fs, it should pick it up if the OS permits it. You would probably need to add the file system root directory to the file trust db, though. If IMA is not available, the you would need to set integrity = sha256.

[scholarsmate]

Would it be possible if IMA is enabled, that fapolicyd could "degrade" to sha256 if the security.ima attribute is missing for any given file?

[stevegrubb]

That should be possible to do.

[enricorastelli]

I wanted to add to this. We setup what are called autotest systems. These can access various builds of our software. Before a change to a piece of software can be committed to our version control system, we run build verification tests on the autotest systems. The builds, too, are located on non-local systems. Now, I tried adding the root path to where our builds are via fapolicyd-cli --file add. There are thousands of files out there and it just sat and sat. This is not a feasible approach. So then I set my sights lower and just tried to trust all of the artifacts for one build. There are well over 2000 artifacts for it to trust. It took fapolicyd about 15 minutes just to add this list of artifacts. If we had to do this for every automated test, there would be a 15 minute startup for any batch of tests. Is there something more feasible for our purposes? I added a rule that allows programs to run if they match the root directory of where our builds are. Are there problems with that approach. I have something like:

allow_log perm=any dir=/path/to/builds/ trust=0 : all

[stevegrubb]

The fapolicyd-cli tool can write the trust to a specific file. You can build trust files in one place and install them into /etc/fapolicyd/trust.d/ This was intended to serve where people populate trust files as a build artifact and then deployment just drops the trust file into trust.d/

I don't think there are problems with that rule. But if all the tests run with a particular uid/gid, I'd add that on the subject side to try to place some limits there. Also, any execution always starts with an object access to the executable. If you get unexpected failures, you might need need to add a rule allowing object access to that directory.