IMA keyctl problems

IMA keyctl problems

[Paul R. Tagliamonte]

Hey all!

I have an asymmetric key loaded into _ima on my root user's @u
keyring. v/r/s is set on the keyrings, and key:

```
 943483453 --alswrv      0 65534  keyring: _uid.0
 559919368 ----s-rv      0     0   \_ keyring: _ima
 475931491 ----s-rv      0     0       \_ asymmetric: Local IMA Key
```

However, when I try and run my VM with IMA set to log, I'm getting a
log full of:

"integrity: no _ima keyring: -126"

Anyone have a tip on what I'm doing wrong?

--
:wq

Re: IMA keyctl problems

[Mimi Zohar]

On Sat, 2017-12-09 at 17:01 -0500, Paul R. Tagliamonte wrote:
> Hey all!
> 
> I have an asymmetric key loaded into _ima on my root user's @u
> keyring. v/r/s is set on the keyrings, and key:
> 
> ```
>  943483453 --alswrv      0 65534  keyring: _uid.0
>  559919368 ----s-rv      0     0   \_ keyring: _ima
>  475931491 ----s-rv      0     0       \_ asymmetric: Local IMA Key
> ```
> 
> However, when I try and run my VM with IMA set to log, I'm getting a
> log full of:
> 
> "integrity: no _ima keyring: -126"

Depending on how the kernel was built (CONFIG_IMA_TRUSTED_KEYRING),
the IMA keys need to be loaded either on the trusted keyring named
.ima or the _ima keyring.  The kernel itself creates the trusted .ima
keyring.

The command "sudo keyctl show %keyring:.ima" will indicate if the
".ima" was created.

Mimi

Re: IMA keyctl problems

[Paul R. Tagliamonte]

Thanks for the quick reply!

Good call, but no such luck --

$ sudo keyctl show %keyring:.ima
Can't find 'keyring:.ima'

  Paul



On Sun, Dec 10, 2017 at 9:18 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Sat, 2017-12-09 at 17:01 -0500, Paul R. Tagliamonte wrote:
>> Hey all!
>>
>> I have an asymmetric key loaded into _ima on my root user's @u
>> keyring. v/r/s is set on the keyrings, and key:
>>
>> ```
>>  943483453 --alswrv      0 65534  keyring: _uid.0
>>  559919368 ----s-rv      0     0   \_ keyring: _ima
>>  475931491 ----s-rv      0     0       \_ asymmetric: Local IMA Key
>> ```
>>
>> However, when I try and run my VM with IMA set to log, I'm getting a
>> log full of:
>>
>> "integrity: no _ima keyring: -126"
>
> Depending on how the kernel was built (CONFIG_IMA_TRUSTED_KEYRING),
> the IMA keys need to be loaded either on the trusted keyring named
> .ima or the _ima keyring.  The kernel itself creates the trusted .ima
> keyring.
>
> The command "sudo keyctl show %keyring:.ima" will indicate if the
> ".ima" was created.
>
> Mimi
>



-- 
:wq

Re: IMA keyctl problems

[Mimi Zohar]

On Sun, 2017-12-10 at 10:06 -0500, Paul R. Tagliamonte wrote:
> Thanks for the quick reply!
> 
> Good call, but no such luck --
> 
> $ sudo keyctl show %keyring:.ima
> Can't find 'keyring:.ima'

Both dracut and systemd have examples for loading keys on the IMA keyring.

- https://git.kernel.org/pub/scm/boot/dracut/dracut.git/tree/modules.d/98integrity/ima-keys-load.sh

- https://github.com/systemd/systemd/blob/master/src/core/ima-setup.c

Also, you might be interested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850339

Mimi

Re: IMA keyctl problems

[Paul R. Tagliamonte]

Hey Mimi,

Thanks again for the quick response!

> Both dracut and systemd have examples for loading keys on the IMA keyring.
>
> - https://git.kernel.org/pub/scm/boot/dracut/dracut.git/tree/modules.d/98integrity/ima-keys-load.sh
>
> - https://github.com/systemd/systemd/blob/master/src/core/ima-setup.c

Yeah, I read those, and I don't see any of them doing anything I'm not
already doing.

The basics of how I'm loading the key are:

```
IMA_KEYRING_NAME="_ima"
IMA_KEY_PERMS="0x0b0b0b0b"
IMA_KEYRING_ID=$(keyctl newring ${IMA_KEYRING_NAME} @us)
IMA_KEY_ID=$(keyctl padd asymmetric 'Local IMA Key' ${IMA_KEYRING_ID}
< ${IMA_DIR}/cert_evm.der)

keyctl link ${IMA_KEYRING_ID} @u

keyctl setperm ${IMA_KEY_ID} ${IMA_KEY_PERMS}
keyctl setperm ${IMA_KEYRING_ID} ${IMA_KEY_PERMS}
```

Can you see what's going wrong here? I also can't seem to read the DER
from the asymmetric key, maybe that's related?

I understand evmctl can do some of this, but I need to understand the
internals here. Is it because I'm linking the keyring in after I build
it?


> Also, you might be interested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850339

Yeah, that's interesting. I'd be interested in sponsoring (after I
generate a new OpenPGP key :) ) such work if you have a debian source
package prepared

> Mimi
>

   Paul



-- 
:wq

Re: IMA keyctl problems

[Paul R. Tagliamonte]

Since I'm still stuck on this, I rebuilt the Debian kernel, patching
security/integrity/didsig.c round-about line 55 on Linux 4.12.2 to
add:

```
pr_err("XXX: type=%s name=%s\n", key_type_keyring, keyring_name[id]);
```

I see logs that look like:

```
integrity: XXX: type=_ima name=(null)
integrity: no _ima keyring: -126
```

That strikes me as weird. Seems like request_key would have wanted a
type of "keyring" or something, and a description of "_ima", not a
type of "_ima" and no description.

Does this rustle up any thoughts from anyone?
  Paul


-- 
:wq

Re: IMA keyctl problems

[Paul R. Tagliamonte]

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

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?

   Paul

Re: IMA keyctl problems

[Mimi Zohar]

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

Re: IMA keyctl problems

[Paul R. Tagliamonte]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: multipart/mixed; boundary="94eb2c0e374a7cbdcf05601125f9", Size: 2327 bytes --]

On Mon, Dec 11, 2017 at 8:48 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> 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.

Not quite, when I say "works as expected" I mean, everything worked
(since I signed all binaries) except for one (which was logged, as I
mentioned, and when I turned it onto enforce, it gave me permission
denied. As root.

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

I was running this as uid 0 in the initramfs. It's in a keyring named
_ima and it's linked to @u. That appears to not be sufficient. How do
I create a keyring that spans all user's @u?

> Even if you don't add any keys during boot, enabling dracut/systemd
> would at least properly create the _ima keyring.

Do you have a pointer as to what I'm doing on? I attached the script
I'm running in my initramfs. I'd rather figure out what I'm doing
wrong before punting this to another tool for now.

As for the current behavior --


I've rebooted the machine, here's some output from a terminal from
both root and the user from the keyring as set up currently --

The user can find the keyring called _ima which is attached to root's
@u, but it is not in the user's @u (which should be fine, except it's
not). The user can still find the _ima keyring.

```
# whoami
root
# keyctl show @u
Keyring
 860222890 --alswrv      0 65534  keyring: _uid.0
1007461092 --alswrv      0     0   \_ keyring: _ima
 484254545 --alswrv      0     0       \_ asymmetric: Local IMA Key
# keyctl show %keyring:_ima
Keyring
1007461092 --alswrv      0     0  keyring: _ima
 484254545 --alswrv      0     0   \_ asymmetric: Local IMA Key
# exit
$ whoami
user
$ keyctl show @u
Keyring
 958372548 --alswrv   1000 65534  keyring: _uid.1000
$ keyctl show %keyring:_ima
Keyring
1007461092 --alswrv      0     0  keyring: _ima
 484254545 --alswrv      0     0   \_ asymmetric: Local IMA Key
$
```

This, however, is in the failed state, unless I change uid to 0 and
check enforcement as root rather than user.


  Paul




-- 
:wq


    [ Part 2, Application/OCTET-STREAM (Name: "ima") 732 bytes. ]
    [ Unable to print this part. ]

Re: IMA keyctl problems

[Mimi Zohar]

On Mon, 2017-12-11 at 09:13 -0500, Paul R. Tagliamonte wrote:
> On Mon, Dec 11, 2017 at 8:48 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > 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.
> 
> Not quite, when I say "works as expected" I mean, everything worked
> (since I signed all binaries) except for one (which was logged, as I
> mentioned, and when I turned it onto enforce, it gave me permission
> denied. As root.

Great!  And if you replaced the "uid=0" with "fowner=0" the appraisal
would succeed whether or not you're running as root.

> > 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.
> 
> I was running this as uid 0 in the initramfs. It's in a keyring named
> _ima and it's linked to @u. That appears to not be sufficient. How do
> I create a keyring that spans all user's @u?

Different files can be signed with different keys, but all keys should
be loaded onto the same _ima keyring.  (This will change once IMA is
namespaced.)

The policy defines which files should be appraised.  If you want to
verify files owned by uid 1000, the policy would include an appraise
rule fowner=1000.

> > Even if you don't add any keys during boot, enabling dracut/systemd
> > would at least properly create the _ima keyring.
> 
> Do you have a pointer as to what I'm doing on? I attached the script
> I'm running in my initramfs. I'd rather figure out what I'm doing
> wrong before punting this to another tool for now.

Normally one starts with something that is known to work, before
attempting/complaining something different doesn't work.

Mimi

Re: IMA keyctl problems

[Paul R. Tagliamonte]

> Great!  And if you replaced the "uid=0" with "fowner=0" the appraisal
> would succeed whether or not you're running as root.

I was looking to appraise any binaries that a single user is running,
not anything any user runs that's owned by root.

> Different files can be signed with different keys, but all keys should
> be loaded onto the same _ima keyring.  (This will change once IMA is
> namespaced.)

Yes. Good copy on that.

My question was about how to ensure the _ima keyring is present in all
user's keyrings, if the IMA module is searching the user executing the
program's keyring. See the terminal output in my last mail.



Once again, the kernel is throwing errors if I try to appraise
binaries that uid 1000 is running unless the _ima keyring is linked to
uid 1000's @u keyring. Is this expected behavior, and if so, where can
I read more about this?




> The policy defines which files should be appraised.  If you want to
> verify files owned by uid 1000, the policy would include an appraise
> rule fowner=1000.

I want to appraise anything run by user 1000, regardless of file
owner. I can only seem to do this if uid 1000's @u has a _ima keyring
under it, and **not** if uid 0's @u has an _ima keyring under it. Is
this expected behavior?

> Normally one starts with something that is known to work, before
> attempting/complaining something different doesn't work.

Cheers, thanks for that.

I'd like to point out that at no point have I complained, even about
things fully deserving of it, such as the lack of documentation or
opaque errors. I've been courteous and tried to provide helpful
information and context proactively. To be honest, I'm a bit
disappointed and frustrated at this side-comment.

I understand you must be frustrated, and I appreciate you replied on a
weekend and it's not your job to provide support, but as a newcomer, I
am just as frustrated with this interaction.

A bit of empathy would be nice.


Cheers,
   Paul


-- 
:wq

Re: IMA keyctl problems

[Mimi Zohar]

On Mon, 2017-12-11 at 11:01 -0500, Paul R. Tagliamonte wrote:
> > Great!  And if you replaced the "uid=0" with "fowner=0" the appraisal
> > would succeed whether or not you're running as root.
> 
> I was looking to appraise any binaries that a single user is running,
> not anything any user runs that's owned by root.
> 
> > Different files can be signed with different keys, but all keys should
> > be loaded onto the same _ima keyring.  (This will change once IMA is
> > namespaced.)
> 
> Yes. Good copy on that.
> 
> My question was about how to ensure the _ima keyring is present in all
> user's keyrings, if the IMA module is searching the user executing the
> program's keyring. See the terminal output in my last mail.

It shouldn't need to search multiple keyrings as all keys should be on
the one and only IMA keyring.

> Once again, the kernel is throwing errors if I try to appraise
> binaries that uid 1000 is running unless the _ima keyring is linked to
> uid 1000's @u keyring. Is this expected behavior, and if so, where can
> I read more about this?

This is definitely not expected behavior.

> > The policy defines which files should be appraised.  If you want to
> > verify files owned by uid 1000, the policy would include an appraise
> > rule fowner=1000.
> 
> I want to appraise anything run by user 1000, regardless of file
> owner. I can only seem to do this if uid 1000's @u has a _ima keyring
> under it, and **not** if uid 0's @u has an _ima keyring under it. Is
> this expected behavior?

The builtin measurement policy measures all files executed (eg.
measure func=BPRM_CHECK).  A similar rule could be defined to appraise
everything executed (eg. audit func=BPRM_CHECK), but the builtin
policy can't do that since it would require knowing and signing all
executables, including scripts, on the file system.  For this reason,
we've defined the builtin appraise TCB policy to appraise only files
owned by root.

> > Normally one starts with something that is known to work, before
> > attempting/complaining something different doesn't work.
> 
> Cheers, thanks for that.
> 
> I'd like to point out that at no point have I complained, even about
> things fully deserving of it, such as the lack of documentation or
> opaque errors.

Agreed, the wiki and documentation definitely need to be updated.
 It's on my "todo" list.  I'm hoping to work my way through it, when
things quiet down.

> I've been courteous and tried to provide helpful
> information and context proactively. To be honest, I'm a bit
> disappointed and frustrated at this side-comment.

Basically you're asking me to replicate your environment to figure out
why your environment isn't working, before you've tried the "normal"
method of creating a keyring/loading keys (eg. dracut/systemd) and
booting the system with a builtin policy.

> I understand you must be frustrated, and I appreciate you replied on a
> weekend and it's not your job to provide support, but as a newcomer, I
> am just as frustrated with this interaction.

>From my perspective, I need to understand if you're reporting a
regression or a new usecase scenario.

> A bit of empathy would be nice.

You definitely have my empathy!  Until files come signed, enabling
IMA-appraisal is difficult.

For now, create the keyring and load the keys in the initramfs, as you
described.  Boot with the builtin policies by adding the
ima_policy="tcb|appraise_tcb" on the boot commnad line.

Only afterwards, replace the builtin "appraise_tcb" policy with a
custom policy, which appraises all executables not just those owned by
root.

Instead of "appraise func=BPRM_CHECK fowner=0 appraise_type=imasig"
the appraise rule would be "appraise func=BPRM_CHECK
appraise_type=imasig".

Mimi

Re: IMA keyctl problems

[Paul R. Tagliamonte]

> Instead of "appraise func=BPRM_CHECK fowner=0 appraise_type=imasig"
> the appraise rule would be "appraise func=BPRM_CHECK
> appraise_type=imasig".

Spot on, thank you!

I didn't have a func=* which was causing this entire mess. I changed
the rule from:

`appraise appraise_type=imasig uid=1000` to:
`appraise appraise_type=imasig func=BPRM_CHECK uid=1000`

All behaves exactly as expected. I now have this VM booting and doing
so with enforced IMA signatures. Neato, thanks!

Weird so much came out as what looked like a keyctl issue. Apologies
for focusing on that and not posting the policy file, It's not clear
exactly why this policy rule bug surfaced like that, but I think I'm
off with a baseline now.

Thanks a ton for the help!
  Paul

-- 
:wq