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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ