From: serge@hallyn.com (Serge E. Hallyn)
To: linux-security-module@vger.kernel.org
Subject: [RFC 0/3] WhiteEgret LSM module
Date: Sun, 4 Jun 2017 11:25:25 -0500 [thread overview]
Message-ID: <20170604162525.GA643@mail.hallyn.com> (raw)
In-Reply-To: <CANA3KFV=K1=KUxBNv+Au2QZKaycT3yd2wFPSsW7L9LCChVavkg@mail.gmail.com>
Quoting Peter Dolding (oiaohm at gmail.com):
> On Thu, Jun 1, 2017 at 1:35 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> > 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.
>
> Complete fail. You have to think of a whitelist as a list you give
> to a security at a gate.
>
> Shot-gunned all over the file system that you have to search down what
> is approved is not acceptable.
>
> I should be more clear you need a whitelist file to tick the box.
So you do what SELinux does. You offer a list of 'at-boot' files which a
relabeling program goes over and measures. But when it is time to check if
someone is allowed ot run a program, you check what is stored with the file
being run. The security.WHITELISTED xattr :) Not the list. It was good
enough for CAPP and LSPP, should be good enough for your org.
If that doesn't suffice, then you will not be able to tick the box, and you
should go back to the people who drew the box and have them update their
requirements. They're usually pretty interested.
> Where you can open up 1 file and see everything that is on the
> approved list. Same with blacklist. Think of it like a list of
That '1 file' is just a user interface/toolset issue. It doesn't restrict
how the kernel implements it.
-serge
--
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-06-04 16:25 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
2017-06-04 2:43 ` Peter Dolding
2017-06-04 16:25 ` Serge E. Hallyn [this message]
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=20170604162525.GA643@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).