More Clarifications: Fine-grained file access
By Glenn Faden on Oct 11, 2006
I believe Josh's point was that you didn't have fine-grained labeling on files. And using a loopback filesystem (bind mount to us Linux users) or network filesystem is a hack that becomes necessary when you don't have this sort of per-file labeling.
Actually, I tend to view per-file labeling as a hack.
After years of experience with extended file attributes in Trusted Solaris, we decided that fine-grained file labeling created a false sense of security. The labeling of files was easily bypassed. For example, if you mounted a multilevel UFS file system from Trusted Solaris 8 on a standard Solaris system, the labels were ignored. Similarly, an all-privileged subject could ignore labels. Operating with unlabeled NFS servers was problematic and error prone. Customers were forced to use our special version of UFS instead of their preferred file systems.
Then there was the issue of complexity. Not only were there performance issues with performing MAC checks on file access, but there was the complexity of archiving the labeled filesystems. In Trusted Solaris we required customized archival tools which were not supported by major vendors. Non-standard NFS protocol extensions were required. Privileged users could change the labels of files in ways that prevented the system from working correctly. Pathname traversals would fail because directories had a higher label than the files they contained. Applications needed to be analyzed to determine if they needed multilevel directories or special labeling privileges.
Finally there was the issue of multilevel databases and documentation systems. These environments maintain finer-grained labeling than we could provide at the file system level.
When we realized that we could build multilevel environments without creating customized file systems we saw this as an elegant solution, not a hack. There was still significant engineering required to make the labeling policy robust and automatic. There were many small leaks to stop. But any lingering doubt was removed when we first ran ZFS with Trusted Extensions. It worked properly with no customization, and provided the reliability, scalability, and convenience that we were lacking in Trusted Solaris 8. Now each zone (domain for you SELinux users) has its own file system, and we can clone zones instantaneouly via ZFS snapshots. It's very cool.
It's true that privileges by themselves can be fairly coarse. But modern file systems provide Access Control Lists which are sufficiently granular. While this is an example of a DAC policy, not MAC, it is robust when applied to root-owned files. To prevent privilege escalation, Solaris 10 doesn't honor privileges like file_dac_write when applied to root-owned objects. And there are no privileges to override the mount policy thus ensuring that label relationships are always correct. Lower-level files can only be mounted read-only.
Like all developement efforts, Trusted Extensions is a moving target. We are working with the ZFS team to provide file encryption based on zone labels. We feel that this is ultimately more secure than extended file attributes.