On Do, 02.12.21 14:36, Ben Cotton (
bcotton(a)redhat.com) wrote:
Hmm, so what I am really missing on the feature page: what's the
attack scenario here? Usually security features come with an attack
scenario they are supposed to address. But there's no discussion about
that.
Good point, we were skimpy on that. In case you missed it, Davide just laid it out
in his reply to the same question from Richard Jones higher in the thread. The short
answer is that just this change as-is has no practical threat model, we viewed it as an
enablement step that we believe has a realistic path to broadly authenticated rpm
contents. Alternatively, it does give a sophisticated user an opportunity to build
something like that for themselves as well.
This protects file contents, not the metada, right? So what about
the
metadata? if I see a fs-verity enabled inode with libssl.so data in it
today, and it's a vulnerably version, and I make a hardlink to it, and
then it gets replaced by a fixed version (with a slightly updated
name) — how you intend to make sure, that i can't fool you into loading
my copy of the old file but under the new name?
If the file is still properly signed with a trusted matching certificate in the kernel
keyring we can't/won't do anything about it.
What about signing anyway? What is this precisely signed with? The
keys for that when are they rolled over? Who manages those keys? The
tea for that, who's doing that in Fedora? Is there any protection
against downgrades between RPM package versions? Does this in any way
protect combinations of binaries/libraries? I mean, pretty much all
programs we ship consist of a large number of ELF objects, and you
probably need to sign the combination of them, but this model doesn't
look like it offers that at all? If a security bug is found in library
X, how is it taken out of equation? What would the workflow for that
look like on the Fedora side of things?
I don't have a particularly specific answer to all of these questions,
unfortunately. Perhaps someone with more knowledge about Fedora's existing key
management can weigh in. But imagining we have the LSM hooks setup so that we never load
anything executable without it being signed by a trusted key, then in my mind, banishing a
bad shared library would require revoking the certificate.
I think one could draw a reasonable parallel between package signing and file signing
here, though. Users assemble meaningful system functionality out of a collection of
packages, which are each individually signed. One of those packages could then be found to
be compromised, and need to be removed, otherwise a user could download and install a
perfectly valid signed package and have a bad time, which undermines the value of the
signing. Is there something about composing executables out of files that is meaningfully
different in this sense from composing systems out of packages?
> The security model seems really strange to me I must say: so much
> infrastructure, and it doesn't protect at all how our programs are
> usually combined?
>
> Puzzled,
>
> Lennart