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 <[email protected]> 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
>