Steve Kemp wrote:

This is an interesting idea, and an evolution since the initial 
approach which was submitted based upon xattr attributes.  I still 
find the idea of using attributes simpler to manage though, since 
they're easy to add, and audit for.

I suspect the biggest objection to this module is that maintaining a 
whitelist at all is often impractical.

We also consider that it is an important point of view.
We seem that it is easy to control of executions by file path rather than xattr attributes.
Because the WEUA can easily get file information by file path in user space.

For example, in industrial control systems (ICS), the frequency of software updates are rarer than information systems.
The maintenance cost of whitelist is low in such systems. 
Following the NIST guideline describes importance of the whitelist execution control technology for ICS.
https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-167.pdf

Moreover, there are various requirements depending on ICS.
WhiteEgret users can implement the WEUA which is specialized for their own ICS.
I guess that maintenance cost of whitelist can be decreased in ICS.

My (trivial/toy/silly) module went the attribute-reading way:

https://github.com/skx/linux-security-modules/tree/master/security/whi
telist

For a completely crazy take upon the idea of userspace decisions 
though you can laugh at my attempt here:

https://github.com/skx/linux-security-modules/tree/master/security/can
-exec

I callback to userspace for every decision, via 
call_usermodehelper_setup.  The crazy part is that it actually works 
at all!

Steve

Takumi Shinya