[Rpm-maint] [rpm-software-management/rpm] Request to apply IMA signatures to files even if deemed a configuration file (#364)

[patrickc25000]

While using the relatively new "--signfiles" rpm option (i.e. rpm --addsign 
[--signfiles] PACKAGE), I found that IMA signatures for non-executable 
configuration files, as indicated by the RPM packager, were not applied as part 
of an RPM upgrade (and I assume installation) even though the signatures for 
these configuration files were in the metadata for the RPM package. 
Conceptually, IMHO, the author of the IMA policy in place for the system should 
be determining what files are appraised (and therefore need  IMA signatures 
affixed to them) and not the packager of an RPM. If the author of the IMA 
policy wants to appraise certain files of an RPM package, whether they are 
configuration files or not, why shouldn't they be allowed to do this and 
allowed to use RPM to update the appraised files. On some systems, for example 
embedded systems or appliances like a smart phone, where these configuration 
files are not allowed to be altered (i.e. are immutable), the owner of the 
system should be allowed to specify an IMA policy that protects these immutable 
configuration files from alteration. Of course, if the author of the IMA policy 
cannot prevent the configuration file from being updated, for example, the IMA 
policy is running on a system which is open and users can logon and edit 
configuration files or if the post install script of the RPM updates the 
configuration file, and many more examples, then the author of the IMA policy 
cannot list the file as being appraised since for their use of the RPM, the 
configuration file is mutable. 

Therefore, could the RPM IMA signature support be changed so that the RPM 
updating code treats the configuration file(s) like any other file and sets an 
IMA signature on them. The signature is an extended attribute of course (i.e. 
security.ima) and therefore ignored if the configuration file is not in the IMA 
policy as being appraised (which given how the code works today, the 
configuration file cannot be in the IMA policy because appraisal will fail due 
to the signature missing).

Thank you.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/364___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Problem with --signfiles for files that are hardlinked together (#333)

[patrickc25000]

Conan-Kudo,
The problem can be seen in version 4.13.0-6 from the Redhat Enterprise Linux 7 
distribution.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/333#issuecomment-337431733___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] Problem with --signfiles for files that are hardlinked together (#333)

[patrickc25000]

We have encountered a problem when performing an RPM update while Integrity 
Measurement Architecture (IMA) signatures are applied to the files. In other 
words, we are having a problem with the "--signfiles" support in the RPM 
package.

When we install a new glibc RPM on a system with SELinux and IMA enabled, we 
are seeing appraise errors with 3 files. Looking at an strace (see attached), I 
see that the files are referenced different from the normal sequence (i.e. of 
open, lsetxattr of security.ima, lsetxattr of security.selinux, rename) and 
instead, there is a hard link call made before the open. Taking just one of 
these files that results in an appraise error, namely 
/usr/libexec/getconf/XBS5_LP64_OFF64;59d3a6c8, and looking for references to it 
and some related files (i.e. /usr/libexec/getconf/POSIX_V6_LP64_OFF64;59d3a6c8 
and /usr/libexec/getconf/POSIX_V7_LP64_OFF64), I see the following summary: 

Create POSIX_V6 temp file and rename as POSIX_V6 regular file and hard link 
POSIX_V7 temp file to POSIX_V6 regular file and rename POSIX_V7 temp file as 
POSIX_V7 regular file and hard link XBS5 temp file to POSIX_V6 regular file and 
open XBS5 temp file and then set security.ima on the XBS5 temp file. Since the 
set of security.ima is done after the open and the open will not be creating a 
file since it has a hard link to an existing file at that point, the open will 
encounter an appraise error (in this strace, just resulting in a log entry) 
since the security.ima signature will not be found.

Below are the relevant entries within the strace to support the problem summary 
above: 

write(2, "create 100755  3 (   0,   0)"..., 89create 100755  3 (   0,   
0) 0 /usr/libexec/getconf/POSIX_V6_LP64_OFF64;59d3a6c8
open("/usr/libexec/getconf/POSIX_V6_LP64_OFF64;59d3a6c8", 
O_WRONLY|O_CREAT|O_TRUNC, 0666) = 30
lstat("/usr/libexec/getconf/POSIX_V6_LP64_OFF64", {st_mode=S_IFREG|0755, 
st_size=26648, ...}) = 0
lstat("/usr/libexec/getconf/POSIX_V6_LP64_OFF64", {st_mode=S_IFREG|0755, 
st_size=26648, ...}) = 0
removexattr("/usr/libexec/getconf/POSIX_V6_LP64_OFF64", "security.capability") 
= -1 ENODATA (No data available)
rename("/usr/libexec/getconf/POSIX_V6_LP64_OFF64;59d3a6c8", 
"/usr/libexec/getconf/POSIX_V6_LP64_OFF64") = 0
write(2, "create 100755  3 (   0,   0)"..., 89create 100755  3 (   0,   
0) 0 /usr/libexec/getconf/POSIX_V7_LP64_OFF64;59d3a6c8
link("/usr/libexec/getconf/POSIX_V6_LP64_OFF64", 
"/usr/libexec/getconf/POSIX_V7_LP64_OFF64;59d3a6c8") = 0
lstat("/usr/libexec/getconf/POSIX_V7_LP64_OFF64", {st_mode=S_IFREG|0755, 
st_size=26648, ...}) = 0
lstat("/usr/libexec/getconf/POSIX_V7_LP64_OFF64", {st_mode=S_IFREG|0755, 
st_size=26648, ...}) = 0
removexattr("/usr/libexec/getconf/POSIX_V7_LP64_OFF64", "security.capability") 
= -1 ENODATA (No data available)
rename("/usr/libexec/getconf/POSIX_V7_LP64_OFF64;59d3a6c8", 
"/usr/libexec/getconf/POSIX_V7_LP64_OFF64") = 0
write(2, "create 100755  3 (   0,   0)"..., 85create 100755  3 (   0,   
0) 26648 /usr/libexec/getconf/XBS5_LP64_OFF64;59d3a6c8
link("/usr/libexec/getconf/POSIX_V6_LP64_OFF64", 
"/usr/libexec/getconf/XBS5_LP64_OFF64;59d3a6c8") = 0
open("/usr/libexec/getconf/XBS5_LP64_OFF64;59d3a6c8", O_WRONLY|O_CREAT|O_TRUNC, 
0666) = 30
chown("/usr/libexec/getconf/XBS5_LP64_OFF64;59d3a6c8", 0, 0) = 0
chmod("/usr/libexec/getconf/XBS5_LP64_OFF64;59d3a6c8", 0755) = 0
utimensat(AT_FDCWD, "/usr/libexec/getconf/XBS5_LP64_OFF64;59d3a6c8", 
{{1506436625, 0}, (1506436625, 0}}, AT_SYMLINK_NOFOLLOW) = 0
lsetxattr("/usr/libexec/getconf/XBS5_LP64_OFF64;59d3a6c8", "security.ima", 
"...", 265, 0) = 0
lsetxattr("/usr/libexec/getconf/XBS5_LP64_OFF64;59d3a6c8", "security.selinux", 
"system_u:object_r:bin_t:s0", 27, 0) = 0
write(2, "lsetfilecon: (/usr/libexec/getco"..., 90lsetfilecon: 
(/usr/libexec/getconf/XBS5_LP64_OFF64;59d3a6c8, system_u:object_r:bin_t:s0)
lstat("/usr/libexec/getconf/XBS5_LP64_OFF64", {st_mode=S_IFREG|0755, 
st_size=26648, ...}) = 0
lstat("/usr/libexec/getconf/XBS5_LP64_OFF64", {st_mode=S_IFREG|0755, 
st_size=26648, ...}) = 0
removexattr("/usr/libexec/getconf/XBS5_LP64_OFF64", "security.capability") = -1 
ENODATA (No data available)
rename("/usr/libexec/getconf/XBS5_LP64_OFF64;59d3a6c8", 
"/usr/libexec/getconf/XBS5_LP64_OFF64") = 0

As you can see in the sequence above, an open of an existing file (because it 
is a hard link) is made before the lsetxattr call to add the IMA signature and 
this is the problem. Note, although the open of the existing file is performed 
with the O_TRUNC option, by design, the IMA support in the kernel appraises the 
file (i.e. validates the signature) before the truncation of the file.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/333___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org