linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <shinya1.takumi@toshiba.co.jp>
To: <steve.backup.kemp@gmail.com>
Cc: <jmorris@namei.org>, <serge@hallyn.com>,
	<linux-security-module@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: RE: [RFC v4 0/2] WhiteEgret LSM module
Date: Mon, 5 Nov 2018 06:42:05 +0000	[thread overview]
Message-ID: <KAWPR01MB1444923FD32B82555FC8924392CA0@KAWPR01MB1444.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <CABxV-EV0jYWufjEKsBw9X5AsBT5N8OQjOb2kB_QP_LYvgh-gQg@mail.gmail.com>

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

      parent reply	other threads:[~2018-11-05  6:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-19  5:07 [RFC v4 0/2] WhiteEgret LSM module Shinya Takumi
2018-10-21 12:07 ` Steve Kemp
2018-10-22  9:35   ` Tetsuo Handa
2018-11-20  6:48     ` shinya1.takumi
2018-11-05  6:42   ` shinya1.takumi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=KAWPR01MB1444923FD32B82555FC8924392CA0@KAWPR01MB1444.jpnprd01.prod.outlook.com \
    --to=shinya1.takumi@toshiba.co.jp \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=steve.backup.kemp@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).