On Sun, 2017-12-10 at 22:59 -0500, Paul R. Tagliamonte wrote:
> (break-break)
>
> Phew. OK. I think I've made sense of what was going on here.
>
> I took another look at my policy and on a hunch, figured I ought to
> look at the only unique line I had written:
>
> ```
> appraise appraise_type=imasig uid=1000
> ```
>
> When I changed that to uid=0, everything worked as expected.
The "uid=" is a condition that limits which files to appraise. By
changing "uid=" to 0, I assume by "worked as expected" means nothing
verified.
>
> On a hunch, I changed it back to uid=1000, got the error, and ran:
>
> ```
> keyctl link %keyring:_ima %keyring:_uid.1000
> ```
>
> At which point, the kernel errors went away, and I got the single
> `IMA-signature-required` error I was looking for. Huzzah!
>
>
> Now, can anyone point me in the right direction as to why I had to
> link this keyring to a user to enforce policy?
>
> Is there a reason the lookup doesn't behave as if it were doing a
> %keyring:{_,.}ima lookup? That works even before linking it to
> _uid.1000.
>
> Do other tools load this for each UID on the system? What happens if a
> new user is added at runtime?
>
> This was a pretty not-obvious way for this system to fail, are there
> docs that cover this?
This all seems to indicate that the keys are not being loaded onto
root's _ima keyring. See if there is a difference if you "su -",
before creating the _ima keyring.
Even if you don't add any keys during boot, enabling dracut/systemd
would at least properly create the _ima keyring.
Mimi
