This would seem to better guard against accidentally missing existing capabilities, and also protect against newer capabilities that might be added in a future kernel.
But on the top of the article, the author explicitly recognzied this and explained why they went down that route:
> I wanted specifically to find a minimal set of restrictions to run untrusted code. This isn't how you should approach containers on anything with any exposure: you should restrict everything you can. But I think it's important to know which permissions are categorically unsafe!
This is a very good piece of writing with extensive references and I'll definitely find this useful to share in the future. She documents a ton of tradeoffs she made and resources she chose not to constrain (including the aforementioned syscalls and capabilities), which is important in this type of design and something that I wish I saw more of.
[1]: https://github.com/jessfraz/contained.af/blob/master/seccomp...
I agree, you should iterate over all your existing capabilities and drop those that are not in the white-list. (I have implemented this functionality in one of my projects this way.)
BUT:
Maybe the reason some people do it otherwise, is that capabilities API have only a drop function for the bounding set, and people just don't think they should use it in reverse mode - Sapir-Whorf Hypothesis in operation! ;)
edit: seems like the author have a different reason though