[RFC 0/3] WhiteEgret LSM module

[masanobu2.koike at toshiba.co.jp]

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


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