[RFC v4 0/2] WhiteEgret LSM module

[shinya1.takumi at toshiba.co.jp]

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