How to ensure integrity and security enforcing signed unmodified RPM package?

Question

There is a way to verify files related to specific package against original RPM content:

# Verify `vsftpd` package.
rpm -V vsftpd

How to complete the chain and verify that rpm command itself hasn't been changed?

If I replace rpm by a script which always succeeds, this type of verification will never fail.

score 6 · Accepted Answer · answered Apr 18 '16 at 03:40

This turns out to be quite a difficult problem, if you limit yourself to the single system which you're trying to validate.

Fortunately, we live in the real world, where there is more than one computer!

Some possibilities for verifying the binary include:

Using another reference system which has the same package version of RPM installed, take a hash of the binary and compare it on each system.

For added assurance, reinstall the signed package from the repositories on the reference system before doing the comparison.

Example:
```
# yum reinstall rpm
...
Complete!

# rpm -q rpm
rpm-4.11.3-17.el7.x86_64

# sha256sum /usr/bin/rpm
743810f3c3a9e5eea8ba9bc87351db6b4e8c6393018b9bb56beb873a64ae5431  /usr/bin/rpm
```
Use a host-based intrusion detection system such as OSSEC or Tripwire to detect unexpected changes to your filesystem. This won't guarantee that your binaries are unaltered, of course, but if done properly it can give you warning that an attack is in progress.

Note that both of these fail if prelinking is in use, which is one reason why it's generally not enabled by default anymore on recent systems.

I also guessed that the general approach is to distribute checksum (locally or remotely) - this will make it very difficult for attacker to consistently change it in all locations. The single offline host is a real problem. If copies of the binary or its checksum are hidden around filesystem, periodic software update sessions may only reveal the fact of changes, but any way to enforce authenticity of packages for proprietary software will immediately unmask itself to be attacked. All additional offline methods (possibly some security through obscurity) will not stand long too. — uvsmtid, Apr 20 '16 at 16:24

score 2 · Answer 2 · answered Apr 18 '16 at 03:44

2

# rpm -K rpm-2.3-1.i386.rpm
rpm-2.3-1.i386.rpm: size pgp md5 OK

answered Apr 18 '16 at 03:44

dmourati

How do you know that I haven't replaced rpm with a binary that pretends to validate everything? – Michael Hampton Apr 18 '16 at 03:45
Hmm, a topping the chain problem then. You'd have to do this in a trusted environment before the host is subject to tampering and record the results I suppose. – dmourati Apr 18 '16 at 03:52
2

This requirement was stated in the original question. – Michael Hampton Apr 18 '16 at 06:05

2 Answers2