User questions

User questions

[Ken Williams]

I am looking at Linux IMA to try and understand how it might be useful
for my application.  I am playing around with it a bit now and as I do
so, I am finding myself with questions about the usage model and user
configuration.  With that opening, my first question is:

Is this an acceptable forum for asking user and usage questions?

If yes, then let me describe my environment;
I am running an older kernel, 4.14.238, on a fsl device in a system
that does not have a TPM although I am running an implementation of
OP-TEE.  In my case, I want to do the best I can to prevent file
modification, without considering off-line attacks.  My deployment
mechanism is os-tree.

When I look at the measurement capability, I cannot see how that can
help since I do not have a TPM in which to anchor the measurements so
it looks like I need to implement appraisal.  I did find this link,
https://sourceforge.net/p/linux-ima/mailman/linux-ima-user/?viewmonth=201409&viewday=10,
where Mimi says "Enabling IMA-appraisal is anything but simple". and I
actually found that kind of re-assuring as it confirmed that my
learning curve in this area may not be out of line.  My plan is to
pre-sign the files prior to installation and I see that effort as
being outside of the scope of my inquiries here.  So now, does it look
like I am starting in the right direction?

Thanks for reading through this and I welcome any comments.

Ken

Re: User questions

[Mimi Zohar]

On Thu, 2022-09-15 at 22:36 -0700, Ken Williams wrote:
> I am looking at Linux IMA to try and understand how it might be useful
> for my application.  I am playing around with it a bit now and as I do
> so, I am finding myself with questions about the usage model and user
> configuration.  With that opening, my first question is:
> 
> Is this an acceptable forum for asking user and usage questions?
> 
> If yes, then let me describe my environment;
> I am running an older kernel, 4.14.238, on a fsl device in a system
> that does not have a TPM although I am running an implementation of
> OP-TEE.  In my case, I want to do the best I can to prevent file
> modification, without considering off-line attacks.  My deployment
> mechanism is os-tree.
> 
> When I look at the measurement capability, I cannot see how that can
> help since I do not have a TPM in which to anchor the measurements so
> it looks like I need to implement appraisal.  I did find this link,
> https://sourceforge.net/p/linux-ima/mailman/linux-ima-user/?viewmonth=201409&viewday=10,
> where Mimi says "Enabling IMA-appraisal is anything but simple". and I
> actually found that kind of re-assuring as it confirmed that my
> learning curve in this area may not be out of line.  My plan is to
> pre-sign the files prior to installation and I see that effort as
> being outside of the scope of my inquiries here.  So now, does it lookg
> like I am starting in the right direction?
> 
> Thanks for reading through this and I welcome any comments.

Let's add some context to the above quote.  One of the differences
between IMA-appraisal and IMA-measurement is that IMA-appraisal
requires quite a bit of configuration (e.g. keys, signing files, and
policy).  This is in comparison to IMA-measurement, which requires just
a policy.

As long as the IMA-appraisal policy encompasses just those things that
can and should be signed, enforcing the IMA-appraisal policy is
straight forward:
- Create a local CA key and build it into the kernel.
- Create a public/private key pair signed by the local CA key
- Sign files.
- Load the public key on the IMA keyring.
- Load the IMA appraise policy.

Examples of the first 2 steps can be seen in the ima-evm-utils README. 
Examples of the last two steps can be seen in dracut 98integrity
modules.  systemd can be configured to load an IMA custom policy.

-- 
thanks,

Mimi

Re: User questions

[Ken Williams]

Hi Mimi and others and thanks for responding.

My primary goal right now is to develop an understanding of IMA for
the purpose of determining if and how it can be useful for my application.
For that, I have outlined below a few implementation scenarios.

I have played around with IMA a bit so as to get some understanding of
the process, configuration and capabilities.  This included creating a
policy file
for measurements as well as signing files and enabling appraisal.
All of this was done on-target and obviously putting a private key on the target
is not right but this was a familiarization exercise.  In any case, my current
understanding is that options available to me, without a TPM device, are:

- Measure files which have no security.ima=<HASH> xattr
  In this case I can detect if a previously measured file has changed.
  This is a nice exercise for getting my feet wet but without a TPM,
  it is hard to embrace this alone as being a security tool that can
  work for me.

- Measure files which do have a security.ima=<HASH> xattr
  This is a good step up but I cannot see how this enables the
  detection of a 'bad' but properly labeled file without a link to
  some kind of file validation server.  Again, I have no TPM.

- Attest to files which have been signed with a private key prior to
installation
 With this, I understand that as long as I have control over the file
installation
  process, I have a level of protection equal to that of the signing algorithm.
  If I am correct, I also understand that this applies only to immutable files,
  typically executable binaries.  The process of signing the files would be
  off-target and outside the scope of my questions and comments here.

  Again, I do not have a TPM so I understand that an off-line attack
is still possible
  but it looks like this might be the best I can get out of IMA for
the environment
  I have.

Russell, regarding your comment regarding inclusion of the i-node in
the signing,
I understood that to be included in signing for EVM, not for the
attestation part of IMA.

Thanks for any comments.

Ken


> Let's add some context to the above quote.  One of the differences
> between IMA-appraisal and IMA-measurement is that IMA-appraisal
> requires quite a bit of configuration (e.g. keys, signing files, and
> policy).  This is in comparison to IMA-measurement, which requires just
> a policy.
>
> As long as the IMA-appraisal policy encompasses just those things that
> can and should be signed, enforcing the IMA-appraisal policy is
> straight forward:
> - Create a local CA key and build it into the kernel.
> - Create a public/private key pair signed by the local CA key
> - Sign files.
> - Load the public key on the IMA keyring.
> - Load the IMA appraise policy.
>
> Examples of the first 2 steps can be seen in the ima-evm-utils README.
> Examples of the last two steps can be seen in dracut 98integrity
> modules.  systemd can be configured to load an IMA custom policy.
>
> --
> thanks,
>
> Mimi
>

Re: User questions

[Mimi Zohar]

Hi Ken,

On Sun, 2022-09-18 at 16:47 -0700, Ken Williams wrote:
> Hi Mimi and others and thanks for responding.
> 
> My primary goal right now is to develop an understanding of IMA for
> the purpose of determining if and how it can be useful for my application.
> For that, I have outlined below a few implementation scenarios.
> 
> I have played around with IMA a bit so as to get some understanding of
> the process, configuration and capabilities.  This included creating a
> policy file
> for measurements as well as signing files and enabling appraisal.
> All of this was done on-target and obviously putting a private key on the target
> is not right but this was a familiarization exercise.  In any case, my current
> understanding is that options available to me, without a TPM device, are:
> 
> - Measure files which have no security.ima=<HASH> xattr
>   In this case I can detect if a previously measured file has changed.
>   This is a nice exercise for getting my feet wet but without a TPM,
>   it is hard to embrace this alone as being a security tool that can
>   work for me.
> 
> - Measure files which do have a security.ima=<HASH> xattr
>   This is a good step up but I cannot see how this enables the
>   detection of a 'bad' but properly labeled file without a link to
>   some kind of file validation server.  Again, I have no TPM.

In either case, the TPM is needed for remote attestation.  The 'ima-
sig' template includes the file signature, if available, in the
measurement list.   With just the public key, the remote attestation
server can verify the file signature.

> 
> - Attest to files which have been signed with a private key prior to
> installation
>  With this, I understand that as long as I have control over the file
> installation
>   process, I have a level of protection equal to that of the signing algorithm.
>   If I am correct, I also understand that this applies only to immutable files,
>   typically executable binaries.  The process of signing the files would be
>   off-target and outside the scope of my questions and comments here.
> 
>   Again, I do not have a TPM so I understand that an off-line attack
> is still possible
>   but it looks like this might be the best I can get out of IMA for
> the environment
>   I have.

IMA file hashes are used for mutable files, which cannot be signed. 
When file hashes are stored as security.ima, EVM HMAC must be used to
detect off line file metadata changes.

-- 
thanks,

Mimi

Re: User questions

[Russell Coker]

On Friday, 16 September 2022 15:36:52 AEST Ken Williams wrote:
> If yes, then let me describe my environment;
> I am running an older kernel, 4.14.238,

Things are changing all the time in IMA, getting an older kernel to work might 
be a problem.  However I have seen some documentation about using it in 
embedded systems in vehicles which is a use that tends to have long support 
times, so some old versions will be supported.

> learning curve in this area may not be out of line.  My plan is to
> pre-sign the files prior to installation and I see that effort as
> being outside of the scope of my inquiries here.  So now, does it look
> like I am starting in the right direction?

For typical uses of Linux you would want pre-signed executables.  You want to 
have the system running the programs to not have the signing key and provide 
the signatures from a trusted system.

I've been thinking of having some sort of system that proxies the packages of 
software and creates signatures for them.  The default signing includes the 
Inode number of the file, that can be disabled or the system installing could 
say "give me a signature for /bin/bash from package bash version 5.2~rc2-2 
with Inode 27597791".

The next issue is that the current kernel code doesn't allow signing unsigned 
files unless you boot with "ima_appraise=fix evm=fix" on the kernel command-
line.  I've been thinking of writing a kernel patch to give a compile time 
option to remove that requirement.

As for reasons to use IMA without TPM, one example is virtual machines.  The 
host OS provides a known good kernel and initramfs and we want that kernel to 
ensure that it's not running a corrupt user-space.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: User questions

[Mimi Zohar]

Hi Russell,

> For typical uses of Linux you would want pre-signed executables.  You want to 
> have the system running the programs to not have the signing key and provide 
> the signatures from a trusted system.
> 
> I've been thinking of having some sort of system that proxies the packages of 
> software and creates signatures for them.  The default signing includes the 
> Inode number of the file, that can be disabled or the system installing could 
> say "give me a signature for /bin/bash from package bash version 5.2~rc2-2 
> with Inode 27597791".

EVM portable & immutable signatures do not include the inode.

> 
> The next issue is that the current kernel code doesn't allow signing unsigned 
> files unless you boot with "ima_appraise=fix evm=fix" on the kernel command-
> line.  I've been thinking of writing a kernel patch to give a compile time 
> option to remove that requirement.

When EVM is initialized to only support portable & immutable signatures
(no HMAC key), then the file metadata may be updated.  Refer to the
last paragraph of the cover letter: 
https://lore.kernel.org/linux-integrity/20210514152753.982958-1-roberto.sassu@huawei.com/

--  
thanks,

Mimi