Major changes
From MinorFs Wiki
Major changes
Written in Python instead of Perl
I've decided to not re-use the old Perl MinorFs code but to move to Python. I ran into the limitations of Perl when trying to implement a caretaker pattern based file system, and python seems to have a very good implementation of the Fuse bindings. Next to this, the old Perl code had dependencies on Perl modules not available as standard packages for either Ubuntu or OpenSuse.
All dependencies available in Ubuntu AND OpenSuse
The old perl MinorFs has dependencies that made manual instalation of many dependencies a must, and kept me from creating deb or rpm packages from it. I'll try hard to not use any python modules that are not available in both Ubuntu and OpenSuse. This should make it possible to distribute MinorFs2 as a package for these two Linux distributions. Something that should lower the bar for potential MinorFs users substantially and may help convince package maintainers and developers to at least make use of the facilities that MinorFs offers for keeping secrets from any malware that runs under the same UID as the software users trust with their secrets.
Crypto hook
MinorFs2 in its first release won't do much to strongly encrypt the data stored. It will however create a hook for encrypting filesystem data with a key derived from the strong path used to access the data.
Better privilege separation
In MinorFs we had a filesystem ViewFs that had to run as root. MinorFs shall take care it does not have full file-systems running as root. We plan to have a single simple dbus service that runs as root and accesses files under /proc/$PID/ in order to map process id's to persistence id's.
Smarter use of hashing, no more database
The old design used a sqlite database to map capabilities to raw storage paths. The new design will make smarter use of hashing to eliminate the need for this database.
Multi granularity
The old MinorFs pushed a rather purist reality on MinorFs users. It toled the user: your processes MUST be looked at as incarnations of pseudo persistent processes. For most existing programs this was a rather bad fit. It was an excellent fit for new programs written in the E language using the E-language persistence facilities. But as it turns out not that many projects are interested in using the AppArmor/MinorFs/E-Language stack. For this reason, the new design sets out to provide the MinorFs facility as a multi granularity facility. Picking what granularity to use for a particular process shall be configurable in a way not unlike that used by AppArmor profiles.
Overlay filesystems instead of symlinks to CapFs
While AppArmor can be used to create a strong static least privilege system where each and every process has at least some level of confinement, it hardly ever is. The use of unprotected CapFs strong paths poses a vulnerability when there are unconfined or insufficiently confined processes that could steal these tokens of authority. When processes don't delegate amongst themselves, their private storage could be protected by implementing the functionality of the old ViewFs with an overlay rather than a symlink solution. This comes at an overhead, but relatively cheaply keeps tokens of authority from being stolen from processes trough the /proc/$PID/ content.
No raw CapFs access for unconfined processes
While the use of overlay is a basic protection for strong tokens being stolen, when doing least authority you shall be decomposing, attenuating (read only) and delegating access to sub trees of the private storage facilities. These 3 actions require the usage of so called sparse capabilities. An unconfined process CAN steal sparse capabilities from other processes running under the same user id. While we can't stop these sparse caps from being stolen (other than configuring the system not to allow the existence of unconfined untrusted processes), we can stop these untrusted unconfined processes from USING the sparse capabilities themselves. As we can't distinguish between untrusted and trusted unconfined processes, CapFs won't allow any unconfined process to access any of its data.
