Re: [Linux-ima-user] Clarification requested. Comments about some info in the wiki.

[Mimi Z. <zo...@li...>]

On Thu, 2015-01-08 at 13:08 -0700, Curtis Veit wrote:
> Hi I am new to using IMA and am responsible for securing some systems,
> IMA looks like a great solution for maintain system integrity. As I
> read the documents I find there are areas that I think I understand
> but have some uncertainty.
> It would be greatly appreciated if anyone has time to help correct my
> errors in thought. Hopefully the comments and questions can be used to
> help improve the wiki. ( I would be happy to add to the wiki as well,
> if and when I understand enough to avoid introducing errors.)

> At
> http://sourceforge.net/p/linux-ima/wiki/Home/#understanding-the-ima-appraisal-policy
> Under the "IMA-appraisal" heading. The text reads, "The inital method
> for validating 'security.ima' are hashed based, which provides file
> data integrity, and digital signature based, which in addition to
> providing file data integrity, provides authenticity."
> 
> This brought at least one question to my mind...
> 
> 1. How do I write a policy that ensures that the digital signature
> approach is required for specific groups of files?

Yes, on the policy rule requiring signatures add
"appraise_type:=imasig".

> 2. Do I understand correctly that if I am using the hash (no digital
> signature), if a malicious user or executable "updates" a file, the
> system will automatically set an updated hash in the filesystem? I.e.
> there is a comment about hashes being used to prevent "off-line"
> filesystem modifications. If I understood then I think the wiki is
> pretty clear on this. (but it would be nice to be able to have
> certainty when reading.) If I misunderstood then clarification is
> badly needed.

Right, immutable files should be labeled with file signatures.  Mutable
files by definition change, requiring the security.ima xattr to change
to reflect the file data.

> Another question not specifically at that location: I seems like the
> hashes are associated with measurement not appraise. And that the
> hashes are not stored in the xattrs while the appraisal related
> signature are. Did I get that correct? If the hashes are in the log is
> that log file protected from tampering? How?

The measurement log is stored in memory and can be attested to, so that
a remote host can verify the integrity of the system.

> In the text under heading "Labeling the filesystem with 'security.ima'
> extended attributes" there is a difference in parameters given (log vs
> enforce). I am assuming that "enforce" is the correct parameter to
> use.
> 
> * ima_appraise= appraise integrity measurements\ Format: { "off" |
> "log" | "fix" } \
> off - is a runtime parameter that turns off integrity appraisal
> verification.
> enforce - verifies and enforces runtime file integrity. [default]
> fix - for non-digitally signed files, updates the 'security.ima' xattr
> to reflect the existing file hash.

You don't need to specify any option, except when labeling the
filesystem.  In that case you need to boot in "fix" mode.  

> I am sure there will be more questions as I check out using IMA. My
> main concerns with deploying at this point is wondering how best to
> manage:
> 
> 1. setting the initial policy for the target system. (Do I use hashes
> and/or signatures, and where for each?)

The two builtin policies are ima_tcb and ima_appraise_tcb.  Different
use case scenarios require different policies.  It would be nice to
document some best practices.  Perhaps people on this mailing list will
be willing to share their experiences and policies.

> 2. how to manage updates in the target system given a combination of
> distro updates and local updates? (given that the distros do not
> currently support IMA. And if they did I would potentially need two
> public keys, one for the distro signed matter and one for the locally
> signed matter. Does IMA even support using two keys?)

RHEL, Suse, and Ubuntu have all enabled IMA/IMA-appraisal in their
latest releases.  None of them include file signatures in their software
packages, so you'll need to locally label the filesystem and load the
public key on the IMA keyring.

To prevent just any key from being loaded on the IMA keyring, as of
linux-3.17, the IMA keyring is now a trusted keyring, meaning only keys
signed by a key on the system keyring can be loaded onto the IMA
keyring.

Mimi