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] [day] [month] [year] [list]
Message-ID: <f100f766cfd74fbbbe89fac2022027bf@TGXML276.toshiba.local>
Date:   Thu, 15 Jun 2017 07:56:50 +0000
From:   <masanobu2.koike@...hiba.co.jp>
To:     <mkayaalp@...ux.vnet.ibm.com>, <oiaohm@...il.com>
CC:     <mjg59@...gle.com>, <james.l.morris@...cle.com>,
        <serge@...lyn.com>, <linux-security-module@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: RE: [RFC 0/3] WhiteEgret LSM module

Hi Mehmet,

Thank you for your suggestion to use IMA appraisal.
I'm sorry for the delay in replying to you. I'm studying IMA appraisal.

There is something I don't understand yet. Could you please teach me
the following items?
We assume that "fixing" has already finished and that IMA appraisal
is running in "enforce" mode.

- I have a question for a procedure of labeling and appraising a new
or updated executable file.
Suppose that we want to create a new executable file (included in policy)
and make it be measured and appraised.
Then what kind of procedure should I do?
Similarly, how do I update appraised file to be continuously permitted
to execute?

- When we copy (cp command with -a option) or move an appraised executable
file to somewhere, is the copied or moved executable file permitted to
execute as well?

- (related to the above question) What kind of data is hashed to security.ima?

Thanks in advance,

Masanobu Koike

> -----Original Message-----
> 
> > 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.ht
> m
> > 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