Abort the build if imaevm enabled but header+library not present, use
detected values. Check for lsetxattr() availability. Drop unnecessary
imaevm linkage from the plugin, the plugin only manipulates xattrs and
does not need the IMA library.
The foo_SOURCES style isn't really in cmake ethos, and is wholly
unnecessary here: target_sources() achieves the same exact thing in a
slightly more straightforward way.
These imported targets passed to target_link_library() are supposed to
handle all the pesky compilation, linkage etc details behind the scenes.
I was pretty sure I was missing a trick with this, but this sure isn't
exactly underlined in the documentation.
Unroll the supposedly helpful loop for handling plugins: turns out doing
this cmake native way is plenty shorter and more obvious too. The unroll
kinda belongs to a separate commit but that'd be rather painful for very
little if any gain.
Fixes: #2269 and a whole class of similar cases, allegedly
https://bugzilla.redhat.com/show_bug.cgi?id=2141686 revealed that much
of the rpm-ecosystem is still using the obsolete v3 OpenPGP signature
format, I think largely due to workarounds for legacy rpm versions (from
around the turn of the millennium) that have just been forgotten in
place. Lets at least issue a wake-up warning when that happens.
Unfortunately this is can't really be tested as current GnuPG versions
just ignore any --force-v3-sigs arguments.
Fixes: #2286
There are some missing bits and pieces still to be done for cmake build,
but that is so much easier if you don't have to worry about keeping
compatibility with the system you're about to remove that it doesn't
make sense to drag this on any further. The sooner this is over, the
sooner it is over and we can start making use of cmake's advantages
instead of just trying to bend over backwards to maintain compatibility
with the autotools build.
This is an incomplete release-early version, NOT intended or
suitable for production use. It is intended to replace the autotools
based buildsystem in rpm 4.20, until then it'll be developed alongside
it. This causes some extra complications of course, but then we avoid
a huge flag-day, and that matters more.
To those wondering why cmake and not ${myfavorite}: the community around
us effectively made that choice for us. We've made a lot of noise about
bootstrap dependencies. When libsolv, dnf and all the related stack is
powered by cmake build, it'd be just foolish to go with anything else.
This way people working on the rpm stack have only one build system to
learn, there's peer support available nearby and bootstrap dependencies
are reduced, not increased. It also doesn't hurt that cmake is actually
and actively maintained.
Introduced back in 2007 in 5831404601 the
point was to fake up a sane public header structure with minimal
internal disruption, TEMPORARILY. I think 15 years is temporary enough.
The machinery has worked rather well for what it is, but having the
headers appear in multiple locations is weird and confusing to people,
plus this "physical" separation makes it far more clearer what is
a public header and what isn't.
At this point this is quite literally merely a symbolic change,
as values from PGP hash algo are assumed equal to RPM hash algos,
but it's a necessary first step to supporting hashes not included
in RFC-4880.
Fixes: #1899
At least ECDSA and RSA signatures can vary in length, but the IMA code
assumes constant lengths and thus may either place invalid signatures on
disk from either truncating or overshooting, and segfault if the stars are
just so.
As we can't assume static lengths and attempts to use maximum length
have proven problematic for other reasons, use a data structure that
can actually handle variable length data properly: store offsets into
the decoded binary blob and use them to calculate lengths when needed,
empty data is simply consequtive identical offsets. This avoids a whole
class of silly overflow issues with multiplying, makes zero-length data
actually presentable in the data structure and saves memory too.
Add tests to show behavior with variable length signatures and missing
signatures.
Additionally update the signing code to store the largest IMA signature
length rather than what happened to be last to be on the safe side.
We can't rely on this value due to invalid packages being out there,
but then we need to calculate the lengths on rpmfiles populate so there's
not a lot to gain anyhow.
Fixes: #1833
How do we even _know_ user wants to debug malloc in rpmbuild,
maybe user wants to debug it in _the child_?
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
pgpPrtParams() may leave sig2 unchanged and if we're not in the very
first iteration of the while() loop, we could pass a freed pointer to
pgpDigParamsCmp(). Fix by setting it to NULL after freeing.
Found by Coverity, after commit bd36c5d (subkey binding validation),
although note that the commit didn't introduce this bug; it just seems
to have been a false negative that got "fixed" by the changes in
pgpPrtParams() in that commit.
At least ECDSA and RSA signatures can vary in length, but the IMA code
assumes constant lengths and thus may either place invalid signatures on
disk from either truncating or overshooting, and segfault if the stars are
just so.
Luckily the signatures are stored as strings so we can calculate the
actual lengths at runtime and ignore the stored constant length info.
Extend hex2bin() to optionally calculate the lengths and maximum,
and use these for returning IMA data from the rpmfi(les) API.
Additionally update the signing code to store the largest IMA signature
length rather than what happened to be last to be on the safe side.
We can't rely on this value due to invalid packages being out there,
but then we need to calculate the lengths on rpmfiles populate so there's
not a lot to gain anyhow.
Fixes: #1833
There's no way to safely validate an object to which only a void
pointer is given. Use headerImport() and pass a size to make
verification possible, headerCopyLoad() has been long deprecated anyway.
The argument --verity-algo can be used to specify the algorithm for
the fsverity signatures. If nothing is specified, this will default to
sha256. The available algorithms depend on libfsverity, currently
sha256 and sha512 are supported.
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
This allows a user to remove both types of file signatures from the
package. Previously there was no way to delete IMA signatures, only
replace them by first removing the package signature and then
resigning the package and the files.
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
The fsverity utility follows the symlink when generating a signature.
Since we don't want to sign the same file twice, we need to skip these
links, and instead just generate a dummy zero-length signature here.
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
This generates signatures for all files in the archive, then picks up
ghost files from the header metadata and generates signatures for them
as well. It finally submits them to RPMTAG_VERITYSIGNATURES in header
file order as we cannot rely on archive order and header order being
the same.
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
This adds the array of verity signatures, and a signature length
header. We use 4K block for the Merkle tree, and rely on the kernel
doing the right thing.
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
Various proprietary packages in the wild have subtly malformed data
in the signature header, in particular wrt the immutable region size,
presumably from using some in-house/3rd party signing tools which do
not understand the immutable region business at all. This can prevent
resigning and signature deletion on such packages due to the more
thorough checking that rpmsign does.
As the old wisdom goes, be liberal in what you accept... we can easily
work around the crud by just taking a fresh copy of the contents that
are legit as such (otherwise the package would be uninstallable).
When it comes to IPC with the GPG subprocess that we spawn to sign
packages for us, there has been an evolution of changes over the years.
Initially, we used temporary files to dump package data (header+payload)
to disk, and pointed GPG to those. That being an insanely expensive
operation, we later opted for a pipe bound to stdin on the reader side
[1] to avoid the unnecessary I/O. When GPG 2.1 came along, our own
passphrase entry logic stopped working so we decided to offload [3] that
to GPG instead, for which we also needed to swap the pipe for a named
pipe (FIFO), to free [2] stdin for GPG's own passphrase entry program
(pinentry).
Fast forward to the present, it has become apparent that the FIFO
semantics is not the right choice for us either, as it brings about a
handful of synchronization issues, all of which stem from the fact that
the GPG subprocess, which we cannot control, may or may not open the
input file (our FIFO) for reading before it terminates, causing either
process to hang. That's because an open(2) call on a FIFO blocks until
the other end is also opened. One particular case where such a deadlock
can happen is an expired key [4]; GPG would error out without ever
opening the input file (and rightly so), making RPM stuck.
In a nutshell, here's what the two processes do:
RPM parent:
* spawn GPG child
* open FIFO for writing (blocks)
* write data
* close FIFO
GPG child:
* check key validity <-- may terminate here
* open FIFO for reading (blocks)
* read data
* close FIFO
Which may result in the following execution order:
* parent: spawn GPG child
* parent: open FIFO for writing (blocks)
* child: check key validity (key expired!)
* child: terminate with an error (sends SIGCHLD)
* parent: (continues blocking...)
Now, one way to unblock the parent would be to install a SIGCHLD handler
with SA_RESTART and make it open the FIFO for reading (with O_NONBLOCK)
iff the signal comes from our GPG child (note that RPM can also be used
as a library) so that the restarted open call unblocks right away. This
would, however, still not be entirely safe from race conditions; if
there were other subprocesses, all terminating about the same time,
their SIGCHLD instances could prevent us from receiving the one from
GPG; this is because standard signals do not queue (see signal(7) for a
detailed explanation).
Another way would be to spawn GPG from a wrapper process whose sole
purpose would be to wait(2) for GPG and to open the FIFO if it failed
(without O_NONBLOCK, to ensure the wrapper doesn't exit before the
parent's open call). This would work as long as we could tell exactly
which errors cause GPG to not open the input file, but since that's not
documented, we would have to rely on implementation details, not to
mention the added complexity and ugliness of such a solution, so that's
also a no-go.
Lastly, why not just use O_NONBLOCK in the parent, to prevent it from
blocking in the first place? Since GPG does not use O_NONBLOCK, this
would just push the problem down to the child; if the parent is too fast
and manages to close the FIFO before the child gets a chance to open it,
the child would get stuck once it gets there (thus making the parent
stuck on the wait call).
Luckily, it turns out we actually can take over stdin *and* have GPG use
its pinentry program at the same time! All we need is to make sure the
GPG_TTY environment variable is set to the current terminal (see
gpg-agent(1)). This variable is used [5] by GPG as a fall-back when it
fails to obtain the terminal connected to stdin using ttyname(3), such
as when it is redirected to a pipe.
Thus, in this commit (mostly adapted from the reverse of [2]), we revert
to using the good old pipe(7) which not only avoids race conditions (as
it does not cause open to block), but is also more suitable for this
task in general. (For the record, GPGme also uses [6] a regular pipe
for the IPC.) Since we have access to the original stdin before
redirection, we set GPG_TTY accordingly (if previously unset), to keep
pinentry working.
This commit also resolves the RHBZ linked in [4]. Note that, in the
case of key expiration, GPG isn't particularly specific in the error
message or exit code; all it says is "Unusable secret key" and returns
code 2. For that reason, we can't print anything helpful to stderr
either.
[1] commit 1aace27fb9
[2] commit 6a8924b4c9
[3] commit 0bce5fcf27
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1746353
[5] f3df8dbb69/agent/gpg-agent.c (L1115)
[6] 52f930c1ed/src/engine-gpg.c (L1133)
NSS is a behemoth of a library which drags in a whole runtime subsystem
of its own which is often at odds with normal Unix system behavior
(hello SIGPIPE). Now that we have nicer alternatives available there's
little reason to lug this baggage along. NSS was deprecated in rpm 4.16
(commit 0b9efb93fb).
On packages where a separate payload digest exists (ie those built with
rpm >= 4.14), rpm v3 header+payload signatures are nothing but expensive
legacy baggage, as the payload digest will be signed by a header-only
signature already, without having to recalculate the entire file.
Automatically detect the payload digest presence and only add V3
signatures on packages that need it, but also add an override switch
to force their addition if needed for compatibility or so. A particular
use-case would be ability to signature-level verify the entire package
on rpm older than 4.14.
Fixes: #863
There will be any number of signing flags in the future, and we don't
want to break the ABI for every single one of them by adding new
fields to the sign argument struct. Replace the signfiles field
with a bitfield in the common rpm style. No functional changes.
This is an API change of course, but we'll have to bump the soname for
the next release anyway so might as well do it now.
Commit 8f8fe71841 changed file signing
to use the readily available binary digest from the file objects
instead of recalculating it from the header, but missed one teeny
weeny detail, causing us to pass an array of zeros to be signed on all
files. Oops.
Closes: #723
Permitting corrupted packages to be signed is bad business for everybody
involved, this is something we should've always done. Besides being an
actual security risk, it can lead to odd results with verification
especially with the payload digest on signed packages.
One point worth noting is that this means that pre 4.14-packages cannot
be signed in FIPS mode now because there's no way to validate the package
payload range due to MD5 being disabled. This seems like a feature and
not a limitation, so disabler for the verify step intentionally left out.
Optimally we'd verify the package on the same read that's passed
to gpg but for simplicitys sake that's left as an future exercise,
now we simply read the package twice.
Lotsa unnecessary stuff here:
- No need for rpmtdReset(), headerGet() takes care of that
- In this path, we're always modifying an existing tag so we can
just use headerMod() instead of constructing a new tag
- As we're always shrinking the existing tag, we don't need to
allocate new zeros, just reduce the size. Also make sure we *are*
really shrinking, previously it was only assumed.
No functional changes expected.
Panu Matilainen