[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

Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.14.0/tools/debugedit.c:2144]: (style) Array index 'lndx' is used before limits check. (#332)

[Mark Wielaard]

On Fri, Oct 13, 2017 at 07:30:01AM +, dcb314 wrote:
> Source code is
> 
>   while (r_offset > (dso->lines.table[lndx].old_idx
>  + 4
>  + dso->lines.table[lndx].unit_length)
>  && lndx < dso->lines.used)
> lndx++;
> 
> Suggest limit check array index before use, not after.

Yes, nice catch. The conditions should be swapped.
Patch attached.

Cheers,

Mark
>From 3be44f93ab963169b1b1f4f24c7adffb2029f0df Mon Sep 17 00:00:00 2001
From: Mark Wielaard 
Date: Fri, 13 Oct 2017 23:27:32 +0200
Subject: [PATCH] debugedit: edit_dwarf2 check lndx is in range before checking
 r_offset.

---
 tools/debugedit.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/debugedit.c b/tools/debugedit.c
index a271b916e..fa47aa5e2 100644
--- a/tools/debugedit.c
+++ b/tools/debugedit.c
@@ -2141,10 +2141,10 @@ edit_dwarf2 (DSO *dso)
  r_offset = rel.r_offset;
}
 
- while (r_offset > (dso->lines.table[lndx].old_idx
-+ 4
-+ dso->lines.table[lndx].unit_length)
-&& lndx < dso->lines.used)
+ while (lndx < dso->lines.used
+&& r_offset > (dso->lines.table[lndx].old_idx
+   + 4
+   + 
dso->lines.table[lndx].unit_length))
lndx++;
 
  if (lndx >= dso->lines.used)
-- 
2.13.6

___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RFC: SUSE/openSUSE's proposed relocation of /var/lib/rpm

[Panu Matilainen]

On 10/12/2017 05:44 PM, Mark Hatle wrote:

On 10/12/17 4:52 AM, Neal Gompa wrote:

On Mon, Oct 9, 2017 at 11:25 AM, Richard Brown  wrote:


What do you all think? And if a change like this is on the cards as an rpm 
default, where would the likely
location be?



So, I think we should probably expose this as an configure switch, and
default to /var/lib/rpm. Most people have literally no reason to move
it. The switch would move the rpmdb to the alternate location of
/usr/lib/rpmdb (or whatever the agreed alternate path is).

This wouldn't really affect rpm-ostree, as they'd adjust the dbpath
the same way they've always done it. But for people changing the
system rpmdb location everywhere, the configure switch makes it clear
there's only two supported paths. It should be very clear that you're
on your own for anything else.




I agree with this.  I see no compelling reason for my applications to move the
location of the database from one version to another.

Moving the DB will also complicated OS upgrades (package based) and other 
things.

I don't object to be it being configurable, but I'd like the option to remain at
the current location for as long as I and my customers need it there.


The database path has always been trivially configurable with a macro 
without having to patch rpm, nobody is taking that away. And because 
it's so trivial to change it really doesn't need a configure switch either.


It's also way, way early to discuss about changing defaults. For that, 
there needs to be at least

a) a viable new location (which is what I think this discussion is about)
b) a way to handle migration in a reasonably transparent manner
c) a reason with actual benefits to majority of users (that's what 
*defaults* are about)


For the time being, there's no benefit to moving things around for the 
vast majority of users, on the contrary it'd just cause a whole lot of 
pain with very little if any gain. Maybe that'll change some day, maybe 
some day most users will be on snapshotable setup (I wouldn't predict 
against that) or something like that.


So I don't see us changing the default anytime soon, but I think we all 
need to acknowledge the existence (and importance) of the snapshot case, 
we might need to do *something* to better support that.


- Panu -
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] rpm-4.14.0/tools/debugedit.c:2144]: (style) Array index 'lndx' is used before limits check. (#332)

[dcb314]

Source code is

  while (r_offset > (dso->lines.table[lndx].old_idx
 + 4
 + dso->lines.table[lndx].unit_length)
 && lndx < dso->lines.used)
lndx++;

Suggest limit check array index before use, not after.


-- 
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/332___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 released!

[Panu Matilainen]

On 10/12/2017 11:16 PM, Thierry Vignaud wrote:

On 12 October 2017 at 11:22, Panu Matilainen  wrote:


In short, RPM 4.14.0 is out now. It's not quite what we originally had in
mind - some things we planned for didn't make it, but perhaps more
importantly, it's actually a whole lot MORE than we ever could've
anticipated.

Some highlights:
- Major revamp of debuginfo packages
   - Debuginfo packages are parallel installable
   - Debuginfo can be split to subpackages and separate source package
   - Debugedit supports string/line table rewriting
- Major macro engine changes to sanitize and improve the "language"
   - Parametric macro arguments are expanded and quotable
   - Scoping is enforced for automatic macros
   - Buggy "block level" scoping is gone, only macros defined inside
 parametric macros are considered local
- Major rewrite of package/header reading and signature checking to
   utilize a single codepath
- Support for with/without/unless rich dependencies
- A configurable mode to conserve SSD disks
- Experimental LMDB database backend

...and I'm sure I missed several things worth being on that list, because
there's an absolutely *huge* amount of enhancements and fixes all over the
place, from over 20 contributors. For details and download information, head
over to

 http://rpm.org/wiki/Releases/4.14.0



Hi
Can you create the proper tag in the rpm-4.14.x branch?
(or push it if it already exists on your machine)
Thanks



Yeah, realized yesterday evening I'd forgotten to tag it. And forgotten 
all about it again this morning, so thanks for the reminder :)


Tagged & pushed now,

- Panu -
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint