Key for signing downloadable printer driver packages

Submitted by till on Wed, 10/08/2008 - 17:00.

Printer-friendly versionHi, I would like to let the OpenPrinting server sign the downloadable printer driver packages so that the distribution's printer setup tools, download tools (like Jockey), and/or packaging systems (rpm, dpkg, yum, apt, ...) can verify that the drivers really come from the OpenPrinting server. Do we already have keys at the Linux Foundation, for example keys which we are using for other downloadable packages, perhaps keys which are already in the distros? Or should we generate new keys for OpenPrinting? How would one then get the new keys into the distros? Till

[Webdevel] Key for signing downloadable printer driver packages
Submitted by tytso on Wed, 10/08/2008 - 18:00.

On Wed, Oct 08, 2008 at 06:55:05PM +0200, Till Kamppeter wrote:
>
> I would like to let the OpenPrinting server sign the downloadable
> printer driver packages so that the distribution's printer setup tools,
> download tools (like Jockey), and/or packaging systems (rpm, dpkg, yum,
> apt, ...) can verify that the drivers really come from the OpenPrinting
> server.
>
> Do we already have keys at the Linux Foundation, for example keys which
> we are using for other downloadable packages, perhaps keys which are
> already in the distros? Or should we generate new keys for OpenPrinting?
> How would one then get the new keys into the distros?

I sent a note on a proposed public key hierarchy for the LSB releases;
extending this to cover OpenPrinting shouldn't be hard. The previous
LSB keys weren't installed into the distributions, since the distro's
weren't pulling packages directly from a Linux Foundation server as
would be the case with the OpenPrinting drivers.

We've been talking rolling a high-level public key every year or two,
that would be signed by a long-term master key. That means that there
needs to be a way of downloading new keys periodically. This can be
done via package dependencies.

In terms of negotiating with the distributions, not all of the
distributions may be willing to include our key as a trusted key, at
least not initially. So we may need to have plan where users can
install a package that updates the key databsae automatically, with
instructions that walk the user through the procedure. When distro's
see the value of being able to automatically download drivers,
hopefully they will change their minds.

Something else to think about --- many customers, both in the
Financial Services Sector and in the Government/Defense sector, keep
their machines on networks that do not have access to the outside
world. So whatever tools Open Printing is designing should ideally
have a means of dealing with customers that have to manually download
the drivers, get them approved by the local Site Security Officer, and
then manually transports the driver into the secure machine room via
USB key.

Regards,

- Ted

[Webdevel] Key for signing downloadable printer driver packages
Submitted by till on Wed, 10/08/2008 - 18:30.

Theodore Tso wrote:
> On Wed, Oct 08, 2008 at 06:55:05PM +0200, Till Kamppeter wrote:
>> I would like to let the OpenPrinting server sign the downloadable
>> printer driver packages so that the distribution's printer setup tools,
>> download tools (like Jockey), and/or packaging systems (rpm, dpkg, yum,
>> apt, ...) can verify that the drivers really come from the OpenPrinting
>> server.
>>
>> Do we already have keys at the Linux Foundation, for example keys which
>> we are using for other downloadable packages, perhaps keys which are
>> already in the distros? Or should we generate new keys for OpenPrinting?
>> How would one then get the new keys into the distros?
>
> I sent a note on a proposed public key hierarchy for the LSB releases;
> extending this to cover OpenPrinting shouldn't be hard. The previous
> LSB keys weren't installed into the distributions, since the distro's
> weren't pulling packages directly from a Linux Foundation server as
> would be the case with the OpenPrinting drivers.
>
> We've been talking rolling a high-level public key every year or two,
> that would be signed by a long-term master key. That means that there
> needs to be a way of downloading new keys periodically. This can be
> done via package dependencies.
>
> In terms of negotiating with the distributions, not all of the
> distributions may be willing to include our key as a trusted key, at
> least not initially. So we may need to have plan where users can
> install a package that updates the key databsae automatically, with
> instructions that walk the user through the procedure. When distro's
> see the value of being able to automatically download drivers,
> hopefully they will change their minds.
>

Only distribution with client software for driver download is Ubuntu
Intrepid now. Fedora has at least download for single PPDs from
OpenPrinting.

As distros want to have high security when it comes to automatically
downloading software from the internet, I think they will accept
including the keys, especially when they already include the client
software.

And Ubuntu Intrepid does not only download printer drivers but also
kernel drivers via Jockey (which AFAIK will also be hosted at the LF).
So I think we should quickly make available appropriate keys so that
they can still go into Intrepid (RC freeze in a week or so).

> Something else to think about --- many customers, both in the
> Financial Services Sector and in the Government/Defense sector, keep
> their machines on networks that do not have access to the outside
> world. So whatever tools Open Printing is designing should ideally
> have a means of dealing with customers that have to manually download
> the drivers, get them approved by the local Site Security Officer, and
> then manually transports the driver into the secure machine room via
> USB key.

Everything can also get looked up and installed manually. Also the
client software (system-config-printer, Jockey) handles the case of not
being connected to the internet gracefully. So our printer drivers can
also be used in such secure environments. PPD files for PostScript
printers will, even if they are also available as packages, always be
available as single PPDs, so that security auditing gets faster for just
a few PostScript printers.

Till

[Webdevel] Key for signing downloadable printer driver packages
Submitted by tytso on Wed, 10/08/2008 - 19:45.

On Wed, Oct 08, 2008 at 08:18:08PM +0200, Till Kamppeter wrote:
> Only distribution with client software for driver download is Ubuntu
> Intrepid now. Fedora has at least download for single PPDs from
> OpenPrinting.
>
> As distros want to have high security when it comes to automatically
> downloading software from the internet, I think they will accept
> including the keys, especially when they already include the client
> software.
>
> And Ubuntu Intrepid does not only download printer drivers but also
> kernel drivers via Jockey (which AFAIK will also be hosted at the LF).
> So I think we should quickly make available appropriate keys so that
> they can still go into Intrepid (RC freeze in a week or so).

Some distributions have gotten very paranoid because of liability
concerns when the key is controlled by someone outside their company.
So simply generating a key having it signed by the LSB master key is
not hard. The question is whether Ubuntu has any policy about how the
key should be protected in order for them to be comfortable including
it as a trusted key in Interpid. I see you've encloded Martin Pitt,
so perhaps he can comment on that issue.

The plan I've proposed is that LSB 4.0 release key would only be
stored on-line on LF servers (even though it's encrypted) while we are
doing the final build process. Other than that, it would be stored
off-line, and only those people who are directly involved with the
final release process would know the pass-phrase associated with the
key, on a need-to-know basis.

Presumably we'll want to establish similar policy for the OpenPrinting
key. The key is to making sure the policy is rigorous enough that (a)
distributions are comfortable including the key, and (b) we keep the
key safe so it doesn't get compromised, while at the same time not
making it too difficult for you to release new drivers.

- Ted

[Webdevel] Key for signing downloadable printer driver packages
Submitted by till on Thu, 10/09/2008 - 11:30.

Martin Pitt wrote:
> Hi Till,
>
> thanks for starting this.
>
> Till Kamppeter [2008-10-08 20:18 +0200]:
>>> In terms of negotiating with the distributions, not all of the
>>> distributions may be willing to include our key as a trusted key, at
>>> least not initially.
>
> Right, it will take some time to disseminate them, but the trust here
> is just trusting the validity of the key owner; it does not
> automatically imply trusting the packages, so I think having the keys
> at least available (not necessarily installed by default) in many
> distros should be relatively uncontroversial.
>

How do we make these keys available in the distros? Do we only have to
create the keys and the distros package them? Or do we need to make an
LSB package of them?

>> Only distribution with client software for driver download is Ubuntu
>> Intrepid now. Fedora has at least download for single PPDs from
>> OpenPrinting.
>
> For the record, the thing I would *really* want is signed packages
> with just PPDs (or a single PPD), since those are relatively harmless
> for enabling by default.
>

Currently I am preparing the script-controlled auto generation of LSB
driver packages from manufacturer-supplied PPD files, so that PPDs can
get contributed as before but will be available both as single files and
as packages.

>> And Ubuntu Intrepid does not only download printer drivers but also
>> kernel drivers via Jockey (which AFAIK will also be hosted at the LF).
>
> No, it's not doing that yet. We are currently working on a database
> for drivers, but it will be under control by the respective distros.
>
>> So I think we should quickly make available appropriate keys so that
>> they can still go into Intrepid (RC freeze in a week or so).
>
> For intrepid it's too late anyway, so don't worry. No hurry here,
> let's rather discuss it properly first before setting up something
> which won't be accepted by many distros in the end.
>

Then we should perhaps at first work out a concept of how the key should
look like, how they should get signed, packaged and made available to
the distros and then present the concept to the distros. Any suggestions
of experts on signing packages and distro security?

Do we also need to make a concept of a policy how printer driver
packages have to be created by the manufacturers/driver developers and
about how they get accepted?

I think we should get everything done for the spring editions of the
distros then. WDYT?

>>> Something else to think about --- many customers, both in the
>>> Financial Services Sector and in the Government/Defense sector, keep
>>> their machines on networks that do not have access to the outside
>>> world.
>
> I'm aware of that, but for those the situation didn't really change.
> They can still use the drivers we ship by default, or continue to use
> whichever means they used so far to get printer and other drivers.
> Which might be, as Till pointed out, to download the package manually,
> inspect it, and install it manually.

In this case OpenPrinting only serves as the one-stop location to find
and download the drivers.

Till

[Webdevel] Key for signing downloadable printer driver packages
Submitted by tytso on Thu, 10/09/2008 - 18:30.

On Thu, Oct 09, 2008 at 08:07:32AM +0200, Martin Pitt wrote:
>
> Right, it will take some time to disseminate them, but the trust here
> is just trusting the validity of the key owner; it does not
> automatically imply trusting the packages, so I think having the keys
> at least available (not necessarily installed by default) in many
> distros should be relatively uncontroversial.

Sure, but last I checked, the systems used by both dpkg and RPM based
systems are pretty coarse-grained. Once you configure your system to
accept a key, the packaging system will blindly accept any package
signed by that particular signing key --- at least, as far as I know.

One could posit a system with appropriate fine-grained polciy
controls, where you say, "this key is trusted for packages that
install only into /usr/share/ppd/*, /usr/share/doc/*, and no setuid
executabes are allowed". It's not clear how useful that would be,
given that a shared library with a trojan horse could easily get run
by some process with root privs, but it might make some distributions
at least *somewhat* more willing to allow a signing key to be
configured as being trusted.

> For the record, the thing I would *really* want is signed packages
> with just PPDs (or a single PPD), since those are relatively harmless
> for enabling by default.

So does Ubuntu have some system for allowing some types of packages
but not others? That would very useful if so.

> For intrepid it's too late anyway, so don't worry. No hurry here,
> let's rather discuss it properly first before setting up something
> which won't be accepted by many distros in the end.

That is indeed the challenge, and we need to someone representing all
of the distributions involved in this discussion.

- Ted

[Webdevel] Key for signing downloadable printer driver packages
Submitted by Wichmann Mats D on Thu, 10/09/2008 - 18:45.

Theodore Tso wrote:
> On Thu, Oct 09, 2008 at 08:07:32AM +0200, Martin Pitt wrote:
>>
>> Right, it will take some time to disseminate them, but the trust here
>> is just trusting the validity of the key owner; it does not
>> automatically imply trusting the packages, so I think having the keys
>> at least available (not necessarily installed by default) in many
>> distros should be relatively uncontroversial.
>
> Sure, but last I checked, the systems used by both dpkg and RPM based
> systems are pretty coarse-grained. Once you configure your system to
> accept a key, the packaging system will blindly accept any package
> signed by that particular signing key --- at least, as far as I know.

don't want to nitpick too much, but for debs it's a repository
key, not a package key... debs aren't individually signed but
the repository is.

[Webdevel] Key for signing downloadable printer driver packages
Submitted by tytso on Thu, 10/09/2008 - 21:30.

On Thu, Oct 09, 2008 at 10:49:55PM +0200, Martin Pitt wrote:
>
> openprinting.org already goes into the right direction by offering a
> separate repository for each driver, so the repos can be enabled
> individually depending on which driver the user wants.
>

Not that I want to dissuade distributions from trusting Linux
Foundation staff :-), but does the separate repository really provide
enough of a benefit to be worth the annoying to the end user of
determining which repo's they need to enable?

Without the fine-grained access controls, what would happen if a bad
guy breaks into an external third party repository, and drops in a
package for sshd with a higher version number? If instead of one
repository, you have 100 repositories, it would be annoying for end
users to figure out which one of the 100 repositories they need to
enable for their printer(s), and the cost to the attacker is they
might have install 99 hard links. :-)

Maybe the right answer is we have a master repository which we can
offer the distro's to mirror, with perhaps a weekly or monthly update
cycle, and the distro's can do what ever quality checking their
professional paranoids decide is necessary before they rebroadcast out
to their customers? We'd still need to have signing keys, of course,
but the question what we need to do in order to assure that distro's
will be willing to consume our drivers.

- Ted

[Webdevel] Key for signing downloadable printer driver packages
Submitted by till on Thu, 10/09/2008 - 22:15.

Theodore Tso wrote:
> On Thu, Oct 09, 2008 at 10:49:55PM +0200, Martin Pitt wrote:
>> openprinting.org already goes into the right direction by offering a
>> separate repository for each driver, so the repos can be enabled
>> individually depending on which driver the user wants.
>>
>
> Not that I want to dissuade distributions from trusting Linux
> Foundation staff :-), but does the separate repository really provide
> enough of a benefit to be worth the annoying to the end user of
> determining which repo's they need to enable?
>

The idea of having one repository for each driver is the following: A
user has for example an Epson inkjet printer which works perfectly with
the locally installed Gutenprint driver. Now he adds a Lexmark printer
which needs a driver which is not part of the distro and therefore not
locally installed. system-config-printer asks Jockey to look for a
driver for the detected printer. Jockey installs the driver which
Lexmark has uploaded into the OpenPrinting archive and adds the
repository in which the Lexmark driver is to /etc/apt/sources.list, so
that the system automatically finds updates of the driver. Imagine that
all drivers on OpenPrinting are in one repository. Then this repository
gets added and so also the Gutenprint driver gets updated by automatic
updates. This can lead the Epson inkjet to stop working if a newer
version of Gutenprint has a regression bug. With each driver having its
own repository only the drivers which the user has actually taken from
OpenPrinting get auto-updated.

> Without the fine-grained access controls, what would happen if a bad
> guy breaks into an external third party repository, and drops in a
> package for sshd with a higher version number? If instead of one
> repository, you have 100 repositories, it would be annoying for end
> users to figure out which one of the 100 repositories they need to
> enable for their printer(s), and the cost to the attacker is they
> might have install 99 hard links. :-)
>

The enabling of the repositories is done automatically by Jockey. If it
installs a driver, it activates its repository, if it uninstalls the
driver, it deactivates its repository. So even if OpenPrinting will have
200 repositories, there will be no machine in real live having so many
repositories, An office print server has perhaps 5 different printers
and a CUPS server catering for all 10000 cashier desks of a supermarket
chain has 10000 queues, but probably these printers are only very few
different models and so there are not more than 3 or 4 drivers.

> Maybe the right answer is we have a master repository which we can
> offer the distro's to mirror, with perhaps a weekly or monthly update
> cycle, and the distro's can do what ever quality checking their
> professional paranoids decide is necessary before they rebroadcast out
> to their customers? We'd still need to have signing keys, of course,
> but the question what we need to do in order to assure that distro's
> will be willing to consume our drivers.

If the distro rebroadcasts the drivers, they could rearrange them to
have less repositories if they want. And they can still use our high
amount of repositories to easily exclude an unwished driver (I hope they
will never need to do so).

Till

[Webdevel] Key for signing downloadable printer driver packages
Submitted by till on Fri, 10/10/2008 - 09:30.

Martin Pitt wrote:
> Theodore Tso [2008-10-09 17:11 -0400]:
>> Not that I want to dissuade distributions from trusting Linux
>> Foundation staff :-), but does the separate repository really provide
>> enough of a benefit to be worth the annoying to the end user of
>> determining which repo's they need to enable?
>
> There is also a repository index which has all packages, so if you
> install them manually you probably want to use that one.
>

For manual install the user can choose. But I recommend the
driver-specific one to suppress unwished updates.

>> Without the fine-grained access controls, what would happen if a bad
>> guy breaks into an external third party repository, and drops in a
>> package for sshd with a higher version number?

The fine-grained repositories make such an impact much more difficult.
If the bad guy adds the faked sshd to one repo, he will hit only the
users which have the appropriate class of printers. If he wants to hit
all users, he needs to add the package to all repositories.

>
> Oh, I'm not saying that those fine-grained checks wouldn't be useful,
> just that they are inherently hard to implement.
>
>> Maybe the right answer is we have a master repository which we can
>> offer the distro's to mirror, with perhaps a weekly or monthly update
>> cycle, and the distro's can do what ever quality checking their
>> professional paranoids decide is necessary before they rebroadcast out
>> to their customers? We'd still need to have signing keys, of course,
>> but the question what we need to do in order to assure that distro's
>> will be willing to consume our drivers.
>
> That would be a safer approach indeed. It should be done anyway for
> packages like ghostscript and gutenprint, splix, and everything
> which has real compiled code. Packaged PPD files are not so much of an
> issue, since they have an almost zero potential to break your system,
> so my preference is to limit the search to those packaged PPD files.
> It's currently not yet possible with the openprinting.org search,
> though.

You can already query for packages without binaries. These packages are
architecture-independent, so you query with "architectures=noarch". See
filters table on

http://www.linuxfoundation.org/en/OpenPrinting/Database/Query

Till

[Webdevel] Key for signing downloadable printer driver packages
Submitted by tytso on Sat, 10/11/2008 - 12:00.

On Fri, Oct 10, 2008 at 11:17:45AM +0200, Till Kamppeter wrote:
> For manual install the user can choose. But I recommend the
> driver-specific one to suppress unwished updates.

Maybe I don't understand, but if you use the combined repository, it
doesn't follow that you must install all of the packages in the
combined repository; so I'm not sure why the only way to suppressed
undesired updates is to use a driver-specific repository?

> The fine-grained repositories make such an impact much more difficult.
> If the bad guy adds the faked sshd to one repo, he will hit only the
> users which have the appropriate class of printers. If he wants to hit
> all users, he needs to add the package to all repositories.

True; which means the bad guy would have to add an extra hard link and
add a few lines to each the repository's index file. I'm not sure the
extra effort required is large enough that we could honestly call that
a significant barrier for the attacker. :-)

In any case, if we get back to the topic of the signing key for
OpenPrinting, who would need to have access to the signing key, and
how often will it need to be used --- i.e., how frequently do you
expect new printer drivers to be added or updated? Is this something
that would be done every day? Every week? Would it be batched to
once a every month or two? Etc.

- Ted

[Webdevel] Key for signing downloadable printer driver packages
Submitted by till on Mon, 10/13/2008 - 13:45.

Theodore Tso wrote:
> Maybe I don't understand, but if you use the combined repository, it
> doesn't follow that you must install all of the packages in the
> combined repository; so I'm not sure why the only way to suppressed
> undesired updates is to use a driver-specific repository?
>

Imagine a distro has splix-1.1.1-1 installed which is used for a
printer. Now the user needs the newest gutenprint 5.2.0 and installs it
from OpenPrinting. To keep his OpenPrintiung-installed Gutenprint up
-to-date, he adds the OpenPrinting repository to /etc/apt/sources.list.
Now SpliX 2.0.0 gets uploaded to OpenPrinting. With one repository for
all drivers, the next auto update of our user would update SpliX, what
the user really doe not want to happen.

This was the reason why I introduced per-driver repositories. I will
rename the packages soon (see other mail). Then I can drop the
per-driver repos.

> True; which means the bad guy would have to add an extra hard link and
> add a few lines to each the repository's index file. I'm not sure the
> extra effort required is large enough that we could honestly call that
> a significant barrier for the attacker. :-)
>
>
> In any case, if we get back to the topic of the signing key for
> OpenPrinting, who would need to have access to the signing key, and
> how often will it need to be used --- i.e., how frequently do you
> expect new printer drivers to be added or updated? Is this something
> that would be done every day? Every week? Would it be batched to
> once a every month or two? Etc.

The procedure I was thinking about is that manufacturers/driver
developers upload into a hot folder (or via a web app). If they are
trusted, a script should put the LSB RPM package into the public
download area, generate the corresponding Debian package, update the
indices, and finally sign the packages or indices appropriate to the
needs of the package manager tools of the distros, and in the end
auto-post an announcement in the announcements forum.

For uploaders not trusted, the uploads stay in a queue and one will be
able to browse this queue with a web app. Admins will then be able to
download the package for testing and pass it through to get into the
public download area, using the script mentioned above.

With such a procedure the key with which the packages/indices get
actually signed needs to be without password, as a script will do the
signing. So this key probably needs to get changed regularly.

Package uploads which would get treated by such a script would happen
perhaps once in 2 weeks, dependent on the number of manufacturers who
will contribute drivers.

The master key needs to get accessed perhaps twice a year, to sign the
new package key.

Till

[Webdevel] Key for signing downloadable printer driver packages
Submitted by Wichmann Mats D on Sat, 10/11/2008 - 15:15.

Theodore Tso wrote:
> On Fri, Oct 10, 2008 at 11:17:45AM +0200, Till Kamppeter wrote:
>> For manual install the user can choose. But I recommend the
>> driver-specific one to suppress unwished updates.
>
> Maybe I don't understand, but if you use the combined repository, it
> doesn't follow that you must install all of the packages in the
> combined repository; so I'm not sure why the only way to suppressed
> undesired updates is to use a driver-specific repository?

both apt and yum have ways to restrict what does get installed,
but really, a third-party repository should *not* be providing
packages that have the same name as ones being provided by the
distro.

[Webdevel] Key for signing downloadable printer driver packages
Submitted by till on Mon, 10/13/2008 - 11:15.

Wichmann, Mats D wrote:
> both apt and yum have ways to restrict what does get installed,
> but really, a third-party repository should *not* be providing
> packages that have the same name as ones being provided by the
> distro.
>

I already was thinking about renaming the packages to lsb-... and also
to rename the executable and filters which are linked into system
directories to lsb-... or lsb_.... This way conflicts can get completely
excluded and then I could remove the per-package repos and leave only
one repo per LSB version.

Till

[Webdevel] Key for signing downloadable printer driver packages
Submitted by Wichmann Mats D on Mon, 10/13/2008 - 13:00.

Till Kamppeter wrote:
> Wichmann, Mats D wrote:
>> both apt and yum have ways to restrict what does get installed,
>> but really, a third-party repository should *not* be providing
>> packages that have the same name as ones being provided by the
>> distro.
>>
>
> I already was thinking about renaming the packages to lsb-... and also
> to rename the executable and filters which are linked into system
> directories to lsb-... or lsb_.... This way conflicts can get
> completely excluded and then I could remove the per-package repos and
> leave only one repo per LSB version.
>
> Till

If you are able to do this, keeping namespaces clean this way is
definitely recommended.

[Webdevel] Key for signing downloadable printer driver packages
Submitted by Wichmann Mats D on Mon, 10/13/2008 - 13:00.

If you are able to do this, keeping namespaces clean this way is
definitely recommended.

[Webdevel] Key for signing downloadable printer driver packages
Submitted by till on Thu, 10/09/2008 - 21:30.

Martin Pitt wrote:
> Till Kamppeter [2008-10-09 13:26 +0200]:
>> How do we make these keys available in the distros? Do we only have to
>> create the keys and the distros package them? Or do we need to make an
>> LSB package of them?
>
> Only having LSB packages on openprinting.org isn't enough, since the
> trust chain needs a root, which can only be on the original distro
> installation media. Thus distros need to ship at least the "LSB master
> key", which can then be used to verify project keys (and those can
> then be downloaded from anywhere); those project keys in turn can be
> used to sign e. g. the openprinting.org package archive.
>

This could be the master key mentioned on the LSB mailing list for the
LSB 4.0.

>> Currently I am preparing the script-controlled auto generation of LSB
>> driver packages from manufacturer-supplied PPD files
>
> Right, so the secret key for the op.o archive needs to be on a box
> which is on the internet (probably indirectly, with one ssh hop in
> between), and probably won't have a password. That's why I think we
> need a good mechanism to revoke those keys, and for updating them once
> a year or so. See my other reply.
>

This key is the one which the archive management script on the server is
supposed to use to sign the packages? Is this the same as the project
key mentioned in the beginning of your posting?

> This actually sounds like a good topic for March's LF collaboration
> summit? We have you on board, as well as a lot of distro
> representatives.

I think we cannot wait for the LF Summit in March, as then we would miss
all the spring editions of the distros. We must solve it earlier.

Till

Key for signing downloadable printer driver packages

Active forum topics