The article misses the point that Linux capabilities were designed from the beginning to have this. It is not a new idea; it's just completing the job. (It hasn't been completed before now because people just haven't been interested in fine-grained capabilities).
The capability masks stored with the file completely overwrite the process's current capabilities.
However, this flies in the face of the original design. I know the meanings of the 3 capability sets is hard to grasp, but it looks like someone failed here. A file's permitted set is supposed to be those capabilities that get added to a process by virtue of execing the program in that file (the traditional effect of setuid 0). A file's inherited set is supposed to be those that a process is allowed to keep even though it execed that program (it removes capabilities -- the traditional effect of setuid non-zero).
A process also has 3 permission sets that are unfortunately identically named. Simply setting those masks from an attribute of the exec'ed file isn't nearly as useful.
The setting of capabilities is done outside of the check for filesystems mounted with the nosuid option.
This is dangerous as all hell. If it goes in this way, they had better make sure this entire function is disabled by default, or a bunch of systems are going to be compromised by installing the new kernel code.
Here's some interesting information from someone with experience in Linux capabilities (me):
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds