1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
|
### meta-integrity
OpenEmbedded layer for Linux integrity support
#### Integrity Measurement Architecture (IMA)
The Linux IMA subsystem introduces hooks within the Linux kernel to support
measuring the integrity of files that are loaded (including application code)
before it is executed or mmap()ed to memory. The measured value (hash) is then
registered in a log that can be consulted by administrators.
To support proven integrity of the files, the IMA subsystem can interact with
the TPM chip within the system to protect the registered hashes from tampering
by a rogue administrator or application. The IMA subsystem, as already
supported by the Linux kernel, supports reporting on the hashes of files and
commands ran by privileged accounts (and more if you create your own
measurement policies).
In addition, IMA appraisal can even register the measured value as an extended
attribute, and after subsequent measurement(s) validate this extended attribute
against the measured value and refuse to load the file (or execute the
application) if the hash does not match. In that case, the IMA subsystem allows
files and applications to be loaded if the hashes match (and will save the
updated hash if the file is modified) but refuse to load it if it doesn't. This
provides some protection against offline tampering of the files.
By default, the following constraint conditions are applied by design of this
layer:
- Appraise the files for exec'd (the executables), files mmap'd for exec
(shared libraries), kernel modules and firmwares in effective root identity
(euid=0).
- Enforce verifying the IMA signature when running the executables, shared
libraries, kernel modules and firmwares.
- Deny to run the newly created executables, shared libraries, kernel modules
and firmwares.
- Deny to run the tampered executables, shared libraries, kernel modules and
firmwares.
- Deny to run any executables, shared libraries, kernel modules and firmwares
in the filesystems without file extended attribute supported.
- Allow to run the manually signed executables, shared libraries, kernel
modules and firmwares.
- Allow to run the updated executables, shared libraries, kernel modules and
firmwares during RPM installation.
- Enforce the subsequent policy file write to be verified by a trusted IMA
certificate.
NOTE:
- The different behaviors when executing a script, e.g, launching a python
script with "./test.py" is allowed only when test.py is signed, and launching
a python script with "python test.py" is always allowed as long as the python
interpreter is signed.
- Extended file system attribute is required for IMA appraisal, but not
all file systems can support it. Typically, the pseudo file systems, such as
sysfs, proc, tmpfs and ramfs, certain disk-based file systems, such as FAT,
and network file systems, such as NFS, don't support extended attribute,
meaning IMA appraisal is not available with them.
##### Dependency
- [meta-tpm](https://github.com/jiazhang0/meta-secure-core/tree/master/meta-tpm)
This layer provides the kernel configurations and TSS for TPM 1.x enablement.
- [meta-tpm2](https://github.com/jiazhang0/meta-secure-core/tree/master/meta-tpm2)
This layer provides the kernel configurations and TSS for TPM 2.0 enablement.
##### Use The External IMA Policy
initramfs is a good place to run some IMA initializations, such as loading
the IMA policy, as well as the trusted IMA certificate used to verify IMA
signatures.
###### The default external IMA policy
The default external IMA policy enforces appraising all the executable, shared
library, kernel modules and firmwares with the digital signature in the
effective root identity (euid=0). Hence, the opportunity of loading the default
external IMA policy occurs at the end of initramfs initializations, just before
switch_root.
Instead of running switch_root directly from initramfs, a statically linked
switch_root from the real rootfs is launched and it must be already signed
properly. Otherwise, switch_root will fail to mount the real rootfs and kernel
panic will happen due to this failure.
The default external IMA policy is located at `/etc/ima/ima_policy.default` in
initramfs.
###### The custom external IMA policy
If the default external IMA policy cannot meet the protection requirement, it
is allowed to define the custom external IMA policy, which will be used instead
of the default external IMA policy.
The custom external IMA policy file is eventually installed to `/etc/ima/ima_policy`
in initramfs.
In addition, the IMA policies signed by the trusted IMA certificate in the real
rootfs are also attempted to be loaded if any, in the pattern of file name as
`/etc/ima/ima_policy*`.
##### IMA certificate & private Key
The private key come in two flavors; one used to sign all regular files in
rootfs and one used by RPM to re-sign the executable, shared library, kernel
module and firmware during RPM installation. Correspondingly, the IMA
certificate is used to verify the IMA signature signed by the private key.
In addition, initramfs is a good place to import the IMA certificate likewise.
Note that the IMA certificate must be signed by the system trusted key by
design. This guarantees the imported IMA certificate is always trustworthy.
###### The default IMA certificate & private key
The default IMA certificate & private key are generated by the build system. By
default, the sample keys are used for the purpose of development and
demonstration. Please ensure you know what your risk is to use the sample keys
in your product, because they are completely public.
Private keys are not installed into the target image. If you understand your
risks, you can copy them to your target file system or to an external storage.
If you do so, a typical signing command is as following:
# evmctl ima_sign --hashalgo sha256 --key path/to/x509_ima.key --pass=<passowrd> /path/to/file
or
# evmctl ima_sign --hashalgo sha256 --key /path/to/x509_ima.key --pass=<passowrd> -r /path/to/directory
The following command can be used to verify a file's IMA signature with specified certificate:
# evmctl ima_verify --key /etc/keys/x509_ima.der /path/to/file
### RPM File Signing
The payloads in a RPM are signed by the private key during the build, and each
IMA signatures for the corresponding payload file will be eventually written
to the filesystem during RPM installation.
In order to check whether a RPM is signed, run the command
`rpm -qp --queryformat "%{FILESIGNATURES:arraysize}\n" <rpm>`
If the result is not none or zero, the specified RPM contains the signed
payloads.
### Tarball Signing
Packing the IMA signatures into a tarball is another method to preserve the
IMA signatures. Be aware of using `--xattrs --xattrs-include=security\\.ima`
with both extraction and creation operations.
### Best practice
The following best practices should be applied with using IMA.
- Enable UEFI/MOK secure boot
UEFI/MOK secure boot can verify the integrity of initramfs, providing the
protection against tampering of the external IMA policy files and IMA public
keys stored in initramfs.
- Moderate measuring
Measuring the files owned by non-root user may introduce malicious attack.
Malicious user may create lots of files with different names or trigger
violation conditions to generate a mass of event logs recorded in the runtime
measurement list, and thus exhaust the persistent kernel memory.
- Performance influence
Moderate policy can make a good balance between the performance and security.
Tune the default external policy (`/etc/ima_policy.default`) and modulate the
custom policy for the product requirement.
- Use IMA digital signature to protect the executable
Using the digital signature scheme DIGSIG is safer than digest-based scheme.
Meanwhile, use `appraise_type=imasig` in your IMA policy to enforce running
this.
- Use the measurement and audit rules together
The runtime measurement list is unable to track down the order of changes for
a file, e.g, a file content varies in order of X -> Y -> X. However, audit log
can record these changes in the right order.
##### Known Issues
- The following operations may break the behavior of appraisal and cause the
failure of launching the executables, shared libraries, kernel modules and
firmwares:
- the syscalls used to set file last access and modification times.
- the syscalls used to set ownership of a file.
- the syscalls used to set permissions of a file.
To fix the failure, manually re-sign the affected file.
- Overwriting an existing file with the same content is deemed as tampering of
the file.
- The default IMA rules provides the ability of measuring the boot components
and calculating the aggregate integrity value for attesting. However, this
function conflicts with the luks feature which employs PCR policy session to
retrieve the passphrase in a safe way. If both of them are enabled, the
default IMA rules will be not used.
### Reference
[Official IMA wiki page](https://sourceforge.net/p/linux-ima/wiki/Home/)
[OpenEmbedded layer for EFI Secure Boot](https://github.com/jiazhang0/meta-secure-core/tree/master/meta-efi-secure-boot)
[OpenEmbedded layer for signing key management](https://github.com/jiazhang0/meta-secure-core/tree/master/meta-signing-key)
[OpenEmbedded layer for TPM 1.x](https://github.com/jiazhang0/meta-secure-core/tree/master/meta-tpm)
[OpenEmbedded layer for TPM 2.0](https://github.com/jiazhang0/meta-secure-core/tree/master/meta-tpm2)
|
