All of lore.kernel.org
 help / color / mirror / Atom feed
* Potential IMA Signing Bug
@ 2020-09-09 19:13 Alexander Gaidis
  2020-09-11 14:21 ` Mimi Zohar
  0 siblings, 1 reply; 4+ messages in thread
From: Alexander Gaidis @ 2020-09-09 19:13 UTC (permalink / raw)
  To: linux-integrity, zohar, dmitry.kasatkin

I am wondering if the following behavior is a bug.

My system is Debian Buster with Linux kernel v5.7.13 running on x86_64
Intel hardware. My kernel's configuration file has the following
relevant security options (+ their dependencies) turned on:

```
CONFIG_INTEGRITY=y
CONFIG_INTEGRITY_SIGNATURE=y
CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y
CONFIG_INTEGRITY_AUDIT=y
CONFIG_IMA=y
CONFIG_IMA_MEASURE_PCR_IDX=10
CONFIG_IMA_LSM_RULES=y
CONFIG_IMA_NG_TEMPLATE=y
CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
CONFIG_IMA_DEFAULT_HASH_SHA256=y
CONFIG_IMA_DEFAULT_HASH="sha256"
CONFIG_IMA_WRITE_POLICY=y
CONFIG_IMA_READ_POLICY=y
CONFIG_IMA_APPRAISE=y
CONFIG_IMA_APPRAISE_BOOTPARAM=y
CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y
# CONFIG_INTEGRITY_TRUSTED_KEYRING is not set
# CONFIG_INTEGRITY_PLATFORM_KEYRING is not set
CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y
CONFIG_EVM=y
CONFIG_EVM_ATTR_FSUUID=y
```

and I updated GRUB to include `ima_appraise=fix` to the boot parameters.
The policy I load looks like the following:

```
measure fowner=1000
appraise fowner=1000 appraise_type=imasig
```

To sign IMA hashes I load an x509 certificate onto root's `_ima` keyring
via the following procedure (assume I have the file x509_ima.genkey as
in the `evmctl` manpage):

```
root@deb:~# openssl req -new -nodes -utf8 -sha1 -days 36500 -batch \
>    	        -x509 -config x509_ima.genkey \
>	        -outform DER -out x509_ima.der -keyout privkey_ima.pem
Generating a RSA private key
......+++++
....+++++
writing new private key to 'privkey_ima.pem'
-----
root@deb:~# ima_id=`keyctl newring _ima @u`
root@deb:~# cat x509_ima.der | keyctl padd asymmetric 'ima_cert' $ima_id
282969187
root@deb:~# keyctl show
Session Keyring
 727602364 --alswrv      0     0  keyring: _ses
  17430979 --alswrv      0 65534   \_ keyring: _uid.0
 822262864 --alswrv      0     0       \_ keyring: _ima
 282969187 --als--v      0     0           \_ asymmetric: ima_cert
```

I have a simple executable, `hello`, that prints a simple "Hello world!"
message. Using the matching private key of the x509 certificate above
and `evmctl` I can hash and sign the executable:

```
user@deb:~$ sudo evmctl -v ima_sign --key /root/privkey_ima.pem hello
hash: 4409ab55775b430524cf9c9bbe798a8213de740e
evm/ima signature: 136 bytes
03020277de1ee90080696c392a74513afcff14208fe5c3a56b466a360becf7ca5aa11a502fd249fc7fa04d7631d9cd10602ba460c0133773ce3c33562e5e0d9770b3c0714f7b19bba4e4de0b88b12d512b7fa99732118de59a3fc098e1655d531a60a3c6052c434959ab739d740a5125f435bf0550eb57c9d09195816c6749a0ab6390196893ef9164
user@deb:~$ getfattr -m . -d hello
# file: hello
security.ima=0sAwICd94e6QCAaWw5KnRROvz/FCCP5cOla0ZqNgvs98paoRpQL9JJ/H+gTXYx2c0QYCukYMATN3POPDNWLl4Nl3CzwHFPexm7pOTeC4ixLVErf6mXMhGN5Zo/wJjhZV1TGmCjxgUsQ0lZq3OddApRJfQ1vwVQ61fJ0JGVgWxnSaCrY5AZaJPvkWQ=
```

After rebooting the machine in appraisal mode and loading the keys and
policy I am unable to run the file as a user:

```
user@deb:~$ ./hello
-bash: ./hello: Permission denied
user@deb:~$ sudo dmesg | tail
...
[   78.593140] integrity: no _ima keyring: -126
[   78.593343] audit: type=1800 audit(1599673725.324:11): pid=582
uid=1000 auid=1000 ses=1 subj==unconfined op=appraise_data
cause=invalid-signature comm="bash" name="/home/user/hello" dev="sda1"
ino=796088 res=0
```

However, after running the file as root and switching back to my user
profile I am able to run the file just fine due to the caching of the
integrity status of the file.

It seems to me that if a user doesn't have access to the key that signs
a file, they should not be able to access the file. Is this a correct
assessment of IMA's behavior? If this is a deliberate design choice, can
you please explain why?

Thank you for your time!

Kind regards,
Alexander Gaidis

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Potential IMA Signing Bug
  2020-09-09 19:13 Potential IMA Signing Bug Alexander Gaidis
@ 2020-09-11 14:21 ` Mimi Zohar
  2020-09-12 22:19   ` Alexander Gaidis
  0 siblings, 1 reply; 4+ messages in thread
From: Mimi Zohar @ 2020-09-11 14:21 UTC (permalink / raw)
  To: Alexander Gaidis, linux-integrity, dmitry.kasatkin

On Wed, 2020-09-09 at 13:13 -0600, Alexander Gaidis wrote:
> I am wondering if the following behavior is a bug.
> 
> My system is Debian Buster with Linux kernel v5.7.13 running on x86_64
> Intel hardware. My kernel's configuration file has the following
> relevant security options (+ their dependencies) turned on:
> 
> ```
> CONFIG_INTEGRITY=y
> CONFIG_INTEGRITY_SIGNATURE=y
> CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y
> CONFIG_INTEGRITY_AUDIT=y
> CONFIG_IMA=y
> CONFIG_IMA_MEASURE_PCR_IDX=10
> CONFIG_IMA_LSM_RULES=y
> CONFIG_IMA_NG_TEMPLATE=y
> CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
> CONFIG_IMA_DEFAULT_HASH_SHA256=y
> CONFIG_IMA_DEFAULT_HASH="sha256"
> CONFIG_IMA_WRITE_POLICY=y
> CONFIG_IMA_READ_POLICY=y
> CONFIG_IMA_APPRAISE=y
> CONFIG_IMA_APPRAISE_BOOTPARAM=y
> CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y
> # CONFIG_INTEGRITY_TRUSTED_KEYRING is not set
> # CONFIG_INTEGRITY_PLATFORM_KEYRING is not set
> CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y
> CONFIG_EVM=y
> CONFIG_EVM_ATTR_FSUUID=y
> ```
> 
> and I updated GRUB to include `ima_appraise=fix` to the boot parameters.
> The policy I load looks like the following:
> 
> ```
> measure fowner=1000
> appraise fowner=1000 appraise_type=imasig
> ```
> 
> To sign IMA hashes I load an x509 certificate onto root's `_ima` keyring
> via the following procedure (assume I have the file x509_ima.genkey as
> in the `evmctl` manpage):
> 
> ```
> root@deb:~# openssl req -new -nodes -utf8 -sha1 -days 36500 -batch \
> >    	        -x509 -config x509_ima.genkey \
> >	        -outform DER -out x509_ima.der -keyout privkey_ima.pem
> Generating a RSA private key
> ......+++++
> ....+++++
> writing new private key to 'privkey_ima.pem'
> -----
> root@deb:~# ima_id=`keyctl newring _ima @u`
> root@deb:~# cat x509_ima.der | keyctl padd asymmetric 'ima_cert' $ima_id
> 282969187
> root@deb:~# keyctl show
> Session Keyring
>  727602364 --alswrv      0     0  keyring: _ses
>   17430979 --alswrv      0 65534   \_ keyring: _uid.0
>  822262864 --alswrv      0     0       \_ keyring: _ima
>  282969187 --als--v      0     0           \_ asymmetric: ima_cert
> ```
> 
> I have a simple executable, `hello`, that prints a simple "Hello world!"
> message. Using the matching private key of the x509 certificate above
> and `evmctl` I can hash and sign the executable:
> 
> ```
> user@deb:~$ sudo evmctl -v ima_sign --key /root/privkey_ima.pem hello
> hash: 4409ab55775b430524cf9c9bbe798a8213de740e
> evm/ima signature: 136 bytes
> 03020277de1ee90080696c392a74513afcff14208fe5c3a56b466a360becf7ca5aa11a502fd249fc7fa04d7631d9cd10602ba460c0133773ce3c33562e5e0d9770b3c0714f7b19bba4e4de0b88b12d512b7fa99732118de59a3fc098e1655d531a60a3c6052c434959ab739d740a5125f435bf0550eb57c9d09195816c6749a0ab6390196893ef9164
> user@deb:~$ getfattr -m . -d hello
> # file: hello
> security.ima=0sAwICd94e6QCAaWw5KnRROvz/FCCP5cOla0ZqNgvs98paoRpQL9JJ/H+gTXYx2c0QYCukYMATN3POPDNWLl4Nl3CzwHFPexm7pOTeC4ixLVErf6mXMhGN5Zo/wJjhZV1TGmCjxgUsQ0lZq3OddApRJfQ1vwVQ61fJ0JGVgWxnSaCrY5AZaJPvkWQ=
> ```
> 
> After rebooting the machine in appraisal mode and loading the keys and
> policy I am unable to run the file as a user:
> 
> ```
> user@deb:~$ ./hello
> -bash: ./hello: Permission denied
> user@deb:~$ sudo dmesg | tail
> ...
> [   78.593140] integrity: no _ima keyring: -126
> [   78.593343] audit: type=1800 audit(1599673725.324:11): pid=582
> uid=1000 auid=1000 ses=1 subj==unconfined op=appraise_data
> cause=invalid-signature comm="bash" name="/home/user/hello" dev="sda1"
> ino=796088 res=0
> ```
> 
> However, after running the file as root and switching back to my user
> profile I am able to run the file just fine due to the caching of the
> integrity status of the file.

For some reason as a user you can't access the _ima keyring -
"integrity: no _ima keyring: -126".   Please create an additional
signed file and try accessing that one as user, after accessing the
original signed one succeeds.

> 
> It seems to me that if a user doesn't have access to the key that signs
> a file, they should not be able to access the file. Is this a correct
> assessment of IMA's behavior? If this is a deliberate design choice, can
> you please explain why?

A signed file is a signed file.   Who signed it shouldn't make a
difference.   The public key needs to be on the appropriate keyring and
accessible by the kernel.

Have you tried automatically loading the public key(s) via dracut or
systemd on boot?  Does that make a difference?

thanks,

Mimi


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Potential IMA Signing Bug
  2020-09-11 14:21 ` Mimi Zohar
@ 2020-09-12 22:19   ` Alexander Gaidis
  2020-09-13  2:09     ` Mimi Zohar
  0 siblings, 1 reply; 4+ messages in thread
From: Alexander Gaidis @ 2020-09-12 22:19 UTC (permalink / raw)
  To: Mimi Zohar, linux-integrity, dmitry.kasatkin

On 9/11/20 8:21 AM, Mimi Zohar wrote:
> On Wed, 2020-09-09 at 13:13 -0600, Alexander Gaidis wrote:
>> I am wondering if the following behavior is a bug.
>>
>> My system is Debian Buster with Linux kernel v5.7.13 running on x86_64
>> Intel hardware. My kernel's configuration file has the following
>> relevant security options (+ their dependencies) turned on:
>>
>> ```
>> CONFIG_INTEGRITY=y
>> CONFIG_INTEGRITY_SIGNATURE=y
>> CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y
>> CONFIG_INTEGRITY_AUDIT=y
>> CONFIG_IMA=y
>> CONFIG_IMA_MEASURE_PCR_IDX=10
>> CONFIG_IMA_LSM_RULES=y
>> CONFIG_IMA_NG_TEMPLATE=y
>> CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
>> CONFIG_IMA_DEFAULT_HASH_SHA256=y
>> CONFIG_IMA_DEFAULT_HASH="sha256"
>> CONFIG_IMA_WRITE_POLICY=y
>> CONFIG_IMA_READ_POLICY=y
>> CONFIG_IMA_APPRAISE=y
>> CONFIG_IMA_APPRAISE_BOOTPARAM=y
>> CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y
>> # CONFIG_INTEGRITY_TRUSTED_KEYRING is not set
>> # CONFIG_INTEGRITY_PLATFORM_KEYRING is not set
>> CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y
>> CONFIG_EVM=y
>> CONFIG_EVM_ATTR_FSUUID=y
>> ```
>>
>> and I updated GRUB to include `ima_appraise=fix` to the boot parameters.
>> The policy I load looks like the following:
>>
>> ```
>> measure fowner=1000
>> appraise fowner=1000 appraise_type=imasig
>> ```
>>
>> To sign IMA hashes I load an x509 certificate onto root's `_ima` keyring
>> via the following procedure (assume I have the file x509_ima.genkey as
>> in the `evmctl` manpage):
>>
>> ```
>> root@deb:~# openssl req -new -nodes -utf8 -sha1 -days 36500 -batch \
>>>    	        -x509 -config x509_ima.genkey \
>>> 	        -outform DER -out x509_ima.der -keyout privkey_ima.pem
>> Generating a RSA private key
>> ......+++++
>> ....+++++
>> writing new private key to 'privkey_ima.pem'
>> -----
>> root@deb:~# ima_id=`keyctl newring _ima @u`
>> root@deb:~# cat x509_ima.der | keyctl padd asymmetric 'ima_cert' $ima_id
>> 282969187
>> root@deb:~# keyctl show
>> Session Keyring
>>  727602364 --alswrv      0     0  keyring: _ses
>>   17430979 --alswrv      0 65534   \_ keyring: _uid.0
>>  822262864 --alswrv      0     0       \_ keyring: _ima
>>  282969187 --als--v      0     0           \_ asymmetric: ima_cert
>> ```
>>
>> I have a simple executable, `hello`, that prints a simple "Hello world!"
>> message. Using the matching private key of the x509 certificate above
>> and `evmctl` I can hash and sign the executable:
>>
>> ```
>> user@deb:~$ sudo evmctl -v ima_sign --key /root/privkey_ima.pem hello
>> hash: 4409ab55775b430524cf9c9bbe798a8213de740e
>> evm/ima signature: 136 bytes
>> 03020277de1ee90080696c392a74513afcff14208fe5c3a56b466a360becf7ca5aa11a502fd249fc7fa04d7631d9cd10602ba460c0133773ce3c33562e5e0d9770b3c0714f7b19bba4e4de0b88b12d512b7fa99732118de59a3fc098e1655d531a60a3c6052c434959ab739d740a5125f435bf0550eb57c9d09195816c6749a0ab6390196893ef9164
>> user@deb:~$ getfattr -m . -d hello
>> # file: hello
>> security.ima=0sAwICd94e6QCAaWw5KnRROvz/FCCP5cOla0ZqNgvs98paoRpQL9JJ/H+gTXYx2c0QYCukYMATN3POPDNWLl4Nl3CzwHFPexm7pOTeC4ixLVErf6mXMhGN5Zo/wJjhZV1TGmCjxgUsQ0lZq3OddApRJfQ1vwVQ61fJ0JGVgWxnSaCrY5AZaJPvkWQ=
>> ```
>>
>> After rebooting the machine in appraisal mode and loading the keys and
>> policy I am unable to run the file as a user:
>>
>> ```
>> user@deb:~$ ./hello
>> -bash: ./hello: Permission denied
>> user@deb:~$ sudo dmesg | tail
>> ...
>> [   78.593140] integrity: no _ima keyring: -126
>> [   78.593343] audit: type=1800 audit(1599673725.324:11): pid=582
>> uid=1000 auid=1000 ses=1 subj==unconfined op=appraise_data
>> cause=invalid-signature comm="bash" name="/home/user/hello" dev="sda1"
>> ino=796088 res=0
>> ```
>>
>> However, after running the file as root and switching back to my user
>> profile I am able to run the file just fine due to the caching of the
>> integrity status of the file.
> 
> For some reason as a user you can't access the _ima keyring -
> "integrity: no _ima keyring: -126".   Please create an additional
> signed file and try accessing that one as user, after accessing the
> original signed one succeeds.
> 

I could access the second file after running the first one as root. See
below:

```
user@deb:~$ getfattr -m . -d hello*
# file: hello
security.ima=0sAwICd94e6QCAaWw5KnRROvz/FCCP5cOla0ZqNgvs98paoRpQL9JJ/H+gTXYx2c0QYCukYMATN3POPDNWLl4Nl3CzwHFPexm7pOTeC4ixLVErf6mXMhGN5Zo/wJjhZV1TGmCjxgUsQ0lZq3OddApRJfQ1vwVQ61fJ0JGVgWxnSaCrY5AZaJPvkWQ=

# file: hello2
security.ima=0sAwICd94e6QCAaWw5KnRROvz/FCCP5cOla0ZqNgvs98paoRpQL9JJ/H+gTXYx2c0QYCukYMATN3POPDNWLl4Nl3CzwHFPexm7pOTeC4ixLVErf6mXMhGN5Zo/wJjhZV1TGmCjxgUsQ0lZq3OddApRJfQ1vwVQ61fJ0JGVgWxnSaCrY5AZaJPvkWQ=

user@deb:~$ ./hello
-bash: ./hello: Permission denied
user@deb:~$ ./hello2
-bash: ./hello2: Permission denied
user@deb:~$ sudo dmesg | tail
...
[  110.374508] integrity: no _ima keyring: -126
[  110.374620] integrity: no _ima keyring: -126
[  110.375295] audit: type=1800 audit(1599931642.814:10): pid=594
uid=1000 auid=1000 ses=1 subj==unconfined op=appraise_data
cause=invalid-signature comm="bash" name="/home/user/hello" dev="sda1"
ino=796088 res=0
[  110.375300] audit: type=1800 audit(1599931642.814:11): pid=594
uid=1000 auid=1000 ses=1 subj==unconfined op=appraise_data
cause=invalid-signature comm="bash" name="/home/user/hello" dev="sda1"
ino=796088 res=0
[  112.556255] integrity: no _ima keyring: -126
[  112.556382] integrity: no _ima keyring: -126
[  112.556401] audit: type=1800 audit(1599931644.994:12): pid=595
uid=1000 auid=1000 ses=1 subj==unconfined op=appraise_data
cause=invalid-signature comm="bash" name="/home/user/hello2" dev="sda1"
ino=796089 res=0
[  112.556449] audit: type=1800 audit(1599931644.994:13): pid=595
uid=1000 auid=1000 ses=1 subj==unconfined op=appraise_data
cause=invalid-signature comm="bash" name="/home/user/hello2" dev="sda1"
ino=796089 res=0
user@deb:~$ su -
Password:
root@deb:~# /home/user/hello
Hello everyone!
root@deb:~# logout
user@deb:~$ ./hello
Hello everyone!
user@deb:~$ ./hello2
Hello everyone!
```

>>
>> It seems to me that if a user doesn't have access to the key that signs
>> a file, they should not be able to access the file. Is this a correct
>> assessment of IMA's behavior? If this is a deliberate design choice, can
>> you please explain why?
> 
> A signed file is a signed file.   Who signed it shouldn't make a
> difference.   The public key needs to be on the appropriate keyring and
> accessible by the kernel.
> 
> Have you tried automatically loading the public key(s) via dracut or
> systemd on boot?  Does that make a difference?

Yes I have, and it does not make a difference.

> 
> thanks,
> 
> Mimi

Thank you for your time!

Warm regards,
Alexander

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Potential IMA Signing Bug
  2020-09-12 22:19   ` Alexander Gaidis
@ 2020-09-13  2:09     ` Mimi Zohar
  0 siblings, 0 replies; 4+ messages in thread
From: Mimi Zohar @ 2020-09-13  2:09 UTC (permalink / raw)
  To: Alexander Gaidis, linux-integrity, dmitry.kasatkin

On Sat, 2020-09-12 at 16:19 -0600, Alexander Gaidis wrote:
> >> user@deb:~$ sudo dmesg | tail
> >> ...
> >> [   78.593140] integrity: no _ima keyring: -126
> >> [   78.593343] audit: type=1800 audit(1599673725.324:11): pid=582
> >> uid=1000 auid=1000 ses=1 subj==unconfined op=appraise_data
> >> cause=invalid-signature comm="bash" name="/home/user/hello" dev="sda1"
> >> ino=796088 res=0
> >> ```
> >>
> >> However, after running the file as root and switching back to my user
> >> profile I am able to run the file just fine due to the caching of the
> >> integrity status of the file.
> > 
> > For some reason as a user you can't access the _ima keyring -
> > "integrity: no _ima keyring: -126".   Please create an additional
> > signed file and try accessing that one as user, after accessing the
> > original signed one succeeds.
> > 
> 
> I could access the second file after running the first one as root. See
> below:

The next steps would be to determine if this bug has existed from the
beginning or was at some point introduced.  In the later case, you
would bisect the kernel based on good and bad starting points to
determine the commit that introduced the bug[1].

Mimi

[1] Documentation/admin-guide/bug-bisect.rst


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-09-13  2:10 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-09 19:13 Potential IMA Signing Bug Alexander Gaidis
2020-09-11 14:21 ` Mimi Zohar
2020-09-12 22:19   ` Alexander Gaidis
2020-09-13  2:09     ` Mimi Zohar

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.