linux-kernel - Re: [RFC 0/3] WhiteEgret LSM module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <88D2080F-FEFA-4535-ACF1-01A584F469D9@linux.vnet.ibm.com>
Date:   Wed, 31 May 2017 11:36:16 -0400
From:   Mehmet Kayaalp <mkayaalp@...ux.vnet.ibm.com>
To:     Peter Dolding <oiaohm@...il.com>
Cc:     Matthew Garrett <mjg59@...gle.com>,
        Masanobu Koike <masanobu2.koike@...hiba.co.jp>,
        james.l.morris@...cle.com, "Serge E. Hallyn" <serge@...lyn.com>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 0/3] WhiteEgret LSM module

> On May 31, 2017, at 6:59 AM, Peter Dolding <oiaohm@...il.com> wrote:
> 
> Number 1 we need to split the idea of signed and whitelisted.   IMA is
> signed should not be confused with white-listed.    You will find
> policies stating whitelist and signed as two different things.

IMA-appraisal can do both. If the securtiy.ima extended attribute
of the file is a hash and not a signature, then it is whitelisting.

> 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.

I doubt the Australian government is an authority on Linux features.
IMA-appraisal can be set to "fix" mode with a boot parameter. If the 
policy covers what you want to whitelist (e.g. files opened by user x), 
and then when those files are accessed, the kernel writes out the hash. 
Then, you can switch to "enforce" mode to allow only files with hashes.

Also, you can achieve the same thing by signing all whitelisted 
files and add the certificate to .ima keyring and throwing away the
signing key.

> The feature need to include in it name whitelisting or just like the
> Australian Department of Defence other parties will mark Linux has not
> having this feature.

I guess we need to advertise IMA-appraisal better.

> Whitelist is program name/path and checksum/s.   If the file any more
> than that is now not a Whitelist but a Security Policy Enforcement or
> signing.   Whitelist and blacklists are meant to be simple things.
> This is also why IMA fails and is signed to too complete to be a basic
> Whitelist.

When you work out all the little details, you arrive at IMA-appraisal.
You have to consider how the scheme is bootstrapped and how it
is protected against the root. IMA-appraisal either relies on a boot
parameter and write-once policy, or the trusted keyrings.

> Peter Dolding.

Mehmet