search

lumag / digsig2-tools

Digital Signatures for ELF files for Linux
GNU General Public License v2.0
0 stars 2 forks source link

Comments to proposal: #1

Open vbwagner opened 6 years ago

vbwagner commented 6 years ago

PKI is very important issue.

  1. Really one, who owns priivate key of the root certificate, actually owns the computer. So, if we want end user to actually own his computer, we should entrust root private key into his hands, and let him issue subsidiary CA certificates to all software sources (distributions, independent package maintainers) he trusts.
  2. pathLen constraint is very important. If we trust some software publisher, it doesn't neccessary mean that we trust all people he trusts.

Unsigned packages from distrbution is not a problem.

  1. First realeases of the system might target source based disitributions, where user rebuilds packages anyway. 2/ Examples of CentOS and Scientific lLinux, show that rebuilding all the packages from such distribution as RedHat is bearable task.
  2. It is possible to unpack Debian package sign executables and repack it back. Astra Linux uses this method to sign packages with bsign.

So, for organization, which maintains dozens of servers with same distribution, it is possbile one way or another, to buiid its own repository where all packages are identical with upstream, except all binaries are signed.

I'm not convinced that we need separately revocable certifficate for each package.

It is clear why we might need to distrust software publisher we've trusted before - say private key was stolen. But I don't think that it is good idea to place burden to the signature system and PKI to block execution of individial, correctly signed binaries.

Only attack I can imagine which can be countered by this mechanism is

  1. Some upstream software has remotely exploitable bug
  2. Bug was found and fixed by maintainer and fixed package signed with same keys is issued and installed on the protected system
  3. Some malicious person bring older, buggy, but correctly signed binary to the protected system
  4. Malicious user use exploitable bug in the signed binary.

CRL format as specified by RFC5280 stores only seraial numbers of revoked certificates, so each certificate authorty can revoke only certificates it issued. So, if we are able to revoke only certificates of software publishers, which we cross-sing with our root CA, we need to maintain (in the kernel space, UEFI variables etc) only one relatively short CRL. If we consider each software publisher as CA which issues new certificate for each binary package it publishes, we have to maintain dozens of CRL, and these CRLs might have thousands of entries (for instance, if distribution have 30000 packages and 3% of them get security updates during distribution lifetime).

vbwagner commented 6 years ago

here I've described (in Russian as SF text) configuration of the tree of trust for newly bought notebook in the world where digital signing of open source binaries is ubiquitous.

lumag commented 6 years ago

@vbwagner

Regarding PKI

  1. Yes, I'm currently researching options for storing root certificate, so that it can not be remotely changed in a system with enforced trust. For now the easiest option is to embed root cert into kernel image (this way platform owner can rebuild a kernel with his own set of keys). It seems that this is the only option for platforms without secure storage (tracked as #3).

  2. tracked as #4

Regarding unsigned distro packages

Of course signing proxy or rebuild-from-source is a viable solution. I'm concerned about being able to:

Regarding signature revocation

Yes, I'm concerned about packages with security bugs in them. However if user can somehow install vulnerable package instead of fixed one, he already has root access (this or that way). DigSig supported revoking individual signatures, so I thought that this feature is at least worth mentioning.