From: serge@hallyn.com (Serge E. Hallyn)
To: linux-security-module@vger.kernel.org
Subject: [RFC 0/3] WhiteEgret LSM module
Date: Wed, 31 May 2017 10:35:49 -0500 [thread overview]
Message-ID: <20170531153549.GB31189@mail.hallyn.com> (raw)
In-Reply-To: <0e0aa575-263a-893a-7ade-f2dc7ce679c2@schaufler-ca.com>
Quoting Casey Schaufler (casey at schaufler-ca.com):
>
>
> On 5/31/2017 3:59 AM, Peter Dolding wrote:
> > ...
> >
> > Like you see here in Australian government policy there is another
> > thing called whitelisted.
> > https://www.asd.gov.au/publications/protect/top_4_mitigations_linux.htm
> > Matthew Garrett you might want to call IMA whitelisting Australian
> > government for one does not agree. IMA is signed. The difference
> > between signed and white-listed is you might have signed a lot more
> > than what a particular system is white-listed to allowed used.
> >
> To be clear, I'm all for a security module to support this policy.
> As the explicit requirement is for a whitelist, as opposed to allowing
> for a properly configured system*, you can't use any of the existing
> technologies to meet it. This kind of thing** is why we have a LSM
> infrastructure.
>
> Unfortunately, the implementation proposed has very serious issues.
> You can't do access control from userspace. You can't count on
> identifying programs strictly by pathname. It's much more complicated
> than it needs to be for the task.
>
> Suggestion:
>
> Create an security module that looks for the attribute
>
> security.WHITELISTED
Bonus, you can have EVM verify the validity of these xattrs, and
IMA verify the interity of the file itself.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-05-31 15:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-30 11:11 [RFC 0/3] WhiteEgret LSM module Masanobu Koike
2017-05-30 17:18 ` Casey Schaufler
2017-06-06 9:28 ` masanobu2.koike at toshiba.co.jp
2017-05-30 20:50 ` Matthew Garrett
2017-05-31 10:59 ` Peter Dolding
2017-05-31 15:22 ` Casey Schaufler
2017-05-31 15:35 ` Serge E. Hallyn [this message]
2017-06-04 2:43 ` Peter Dolding
2017-06-04 16:25 ` Serge E. Hallyn
2017-06-02 17:39 ` Steve Kemp
2017-06-02 19:00 ` Casey Schaufler
2017-06-02 20:28 ` Steve Kemp
2017-05-31 15:36 ` Mehmet Kayaalp
2017-06-04 2:21 ` Peter Dolding
2017-06-04 18:51 ` Mehmet Kayaalp
2017-06-15 7:56 ` masanobu2.koike at toshiba.co.jp
2017-06-01 12:31 ` masanobu2.koike at toshiba.co.jp
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=20170531153549.GB31189@mail.hallyn.com \
--to=serge@hallyn.com \
--cc=linux-security-module@vger.kernel.org \
/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).