On Thu, 2015-05-07 at 15:50 +0200, Zbigniew Jasiński wrote:
> 'ima_appraise_tcb' is default appraise policy. All files with 'root'
> as owner are appraised. It can lock your system if hashes/signatures
> differs.
This only seems useful for read-only root file systems. As soon as root
processes need to rewrite files, they'll run into problems. Not wrong
per-se, but not exactly obvious from the available documentation.
> > Here's another source of confusion for me: how does the ima policy affect
> > evm? Does it perhaps control ima/evm together for a certain file, despite
> > the
> > name ("IMA policy")?
> >
>
> IMA policy does not affect EVM at all.
Agreed, makes more sense this way. But then how is EVM enabled or
disabled? All that I could find is "evm=fix", which enables the special
fix mode.
> > Let's ignore the policy loading problem for a second. When I boot with
> > "i_version ima_appraise=log ima_tcb ima_template_fmt=d-ng|n-ng|status",
> > I still have the problem that files like /etc/resolv.conf cannot be created.
> >
>
> Could you verify that this file system is mounted with 'iversion' flag?
I only used the "i_version" boot parameter, but had not modified fstab.
The result, perhaps after systemd applying fstab parameters, was that
"i_version" was not shown for / by mount.
Adding i_version to fstab changes that, but does not address the
underlying problem.
My hypothesis is that EVM is active, but fails to initialize properly
("evm: init_desc failed"), and thus gets in the way. I would test that
hypothesis if I knew how to turn it off - I can try by compiling it out
of the kernel, but is that really the only option?
> If you add/modify file to protected system in which you use digital
> signatures you need to provide private key for that.
I'm unsure about this part here. How do I tell the kernel for
ima_appraise=fix which private key it is meant to use?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
