On 05/28/10 11:12 AM, John Zolnowsky wrote:
On 05/24/10 01:24 PM, Brock Pytlik wrote:
[snip]
At the image level, there will be three settings for verification of
signatures: ignore, verify, and require. Ignore means that all signature
actions will be ignored, though certificates will be downloaded, the
system will act exactly as it does prior to the signature putback.
Verify means that all signature actions found will be verified and when
a publisher is added, an attempt will be made to gather its CA certs and
verify them against the root CAs on the system.
Is signature validation is required only for signatures applied by
configured publishers? Presumably manifests can have signatures applied
by unrecognized publishers that should be treated as irrelevant.
There are two failure modes here. One is, "I could get a cert for this
signature even though it's not the configured publisher and that
signature was invalid." The second is, "I couldn't validate this
signature because I couldn't find the cert for it."
I feel strongly that the first is an error that prevents the
installation of the package. The second I hadn't considered. Right now,
I'm leaning towards saying that if you're publishing a package with a
signature action that isn't your own, you're responsible for providing
the associated cert(s) for that signature. This is not big burden for
publishers because they'd have to work to remove the cert from the repo.
What's the point of requiring validation of all signatures?
Isn't the trust invested in the first enabled publisher to verify
its signature sufficient to warrant installation?
No, I would think that the first signature found to be invalid disables
installation.
If a publisher's CA
certs fail validation, then the attempt to add it will fail. If any of a
package's signatures don't verify, the package will not be installed.
However, publishers without any CA certs defined will be added and
packages without signatures will be installed. Require functions exactly
like verify, except packages without signatures will not be installed
and publishers without CA certs will not be added. I propose that the
default behavior be verify.
Publishers may have their own setting for this property which overrides
the image's property. Each publisher will default to the image's
behavior unless the property is set either when added or later.
Wordsmithing nit: I initially misinterpreted the paragraph above to
be about a property set by the package publisher. I'd recommend
emphasizing
that this an attribute a client can associate with a configured
publisher.
as the next paragraph makes clear.
That's fair, we've overloaded the term publisher to both mean, "someone
who publishes packages" and "the client setting which knows about those
who present packages to them."
The image property, "signature-policy", will be set by using the pkg
set-property command should a user/admin wish to change the default.
'pkg set-publisher' will be augmented with
'--signing-policy=verify|ignore|require'. set-publisher will also get a
'--add-ca-cert=/path/to/cert' so a user can add additional ca certs for
a publisher. This will most likely be useful for publishers with a
self-signed certificate.
Both the image and publisher may eventually get properties with allow
the user to set a common name which must appear in the chain of certs
used to verify the signature. This would allow, for example, an image to
be created which required a signature from the QA department to be on
all installed packages, a signature done by Oracle, for example,
wouldn't allow the package to be installed. I'm unclear whether setting
this property would make pkg ignore all signatures which don't meet the
common name criteria, or whether it would still verify all signatures
but would ensure that the common name was found. I'm leaning to the
latter interpretation. I consider setting this common name requirement
something that could be deferred to a second delivery, but am willing to
listen to reasons that it needs to be in the initial delivery.
The value of this concept isn't clear. If signature validation can apply
only to enabled publishers, this functionality would naturally fall out
of publisher configuration.
I don't understand what you mean that it would naturally fall out.
When a user adds a new publisher, its CA certs will be retrieved and
verified if possible. The common names will be extracted and shown to
the user as something like, "Packages from this publisher have been
signed by the following organization(s):". Behind the scenes, the client
has gotten the CA certs from the publisher as well as any intermediate
certs needed to verify the CA certs, verified that the CA certs have a
chain of trust that extends to a root CA on the client system, then
stored the certs within the image directory's publisher information.
If the publisher has a self signed CA cert, and the publisher is not set
to ignore signatures, then adding that publisher will fail. We can
either have the user obtain the self-signed cert on their own, from the
website for example, and have them use --add-ca-cert to install the cert
for the publisher.
I would guess the same issue and solution would apply for trust anchors
outside the default set.
In general, I am not handling how or where trust anchors are stored on
the system. I'm simply a consumer of them. That said, if a user found
that the trust anchors they wanted weren't present in the default set
and found whatever interface might exist to add a CA cert to the default
set lacking, they could add the desired trust anchor as a CA cert to
each publisher as needed.
When a signed package is to be installed, the signature actions of the
destination manifest are verified. The first step is to download the CS
cert for the signature from the publisher and check that the manifest
^^^^^^^^^^^^^
Wouldn't that have to come from the repository?
Yes, apologies. To be clearer, when the publisher publishes a signed
package into a repository, part of what is placed into the repo is the
certificate information needed to validate the signature.
Would pkgsend/pkgrecv be augmented to propagate any certificates
associated
with package signatures?
Yep.
[snip]
Thanks for taking a look.
Brock
_______________________________________________
security-discuss mailing list
[email protected]
