Foomatic-Rip rejects unknown values
Summary
The filter foomatic-rip will reject any values of PPD options FoomaticRIPCommandLine, FoomaticRIPCommandLinePDF, and FoomaticRIPOptionSetting. Users are able to scan drivers of their installed printers by the tool foomatic-hash, which outputs a file which is used for allowing the found values for the filter.
Owner
- Name: Zdenek Dohnal
- Email: zdohnal@redhat.com
Current status
- Targeted release: Fedora Linux 43
- Last updated: 2025-09-18
- Announced
- Discussion thread
- FESCo issue: #3458
- Tracker bug: #2390984
- Release notes tracker: #260
Detailed Description
The filter foomatic-rip supports several PPD options which are used to construct a shell command, which is to be run in a new process. Those options are FoomaticRIPCommandLine, FoomaticRIPCommandLinePDF, and FoomaticRIPOptionSettings. This behavior was implemented around 20 years ago to help printer vendors or enthusiasts with writing printer drivers for Linux. Driver creators did not have to write a new filter which would apply requested changes into a filtered file, but wrote set of shell commands, Postscript code or Perl code which were applied to the print job before sending it to the printer.
However this approach is often the final goal of attackers, who exploit another security vulnerabilities in the printing stack to get users to install and use a malicious PPD file for their printer, which will contain crafted mentioned PPD options. Such issues are mitigated by foomatic-rip being run under user lp in the default configuration.
To prevent unintentional use of malicious foomatic-related PPD options, the filter won't accept any values by default. As a way how to review and create an allowed list of safe values, the tool foomatic-hash is implemented.
The tool foomatic-hash scans a PPD file or a path with drivers defined on its command line and outputs two files - one with found values for users to review, and the other with the found values hashed and ready to be copied into directories where foomatic-rip reads them.
In new Fedora 43 installations users are expected to run foomatic-hash tool, review the scan findings and allow the found values by moving the file with hashes into the directory /etc/foomatic/hashes.d.
Feedback
1. Will we allow every foomatic-related PPD options values which are already in Fedora?
Since foomatic-rip is mostly used with older printers or with printers which have another support alternative (like AirPrint), and there are many such older drivers for printers which are now not used often, there would be many values to review for printing stack maintainers in comparison to additional value it gains for Fedora.
However the package cups-filters provides a directory which is read by foomatic-rip in case a printer driver wants to review and ship allowed hashes. The directory /usr/share/foomatic/hashes.d is present for this purpose and developers can install their files with allowed hashes into this directory.
2. Will the previously installed print queue be working after upgrade?
Based on this feedback the proposal owner will implement a RPM scriptlet which will allow values from installed printers, which were installed in the previous Fedora version. A message will be generated during DNF upgrade if there are print queues with such drivers, and direct user to foomatic-rip man page. EDIT: systemd service will be used based on later feedback.
3. Is it possible to sanitize the values instead of introducing reject/allow mechanism?
Unfortunately this is not possible due functionality of those options. They were meant to construct a shell command, so we cannot forbid interpreter calls or remove/escape special characters since it would break the correct shell command.
4. Introduce foomatic-hash into stable releases without foomatic-rip rejecting the unknown values, so users can prepare files beforehand.
I agree and I'll split the patch to make it happen. It will be done before this Change is accepted, because it does not break the existing behavior.
5. Use containerized solution like bubblewrap for the shell command instead of allow/reject mechanism, because command review is a task requiring expertise.
This would be great if we had control over all drivers user can install into OS - in case of the issue with driver we could fix the driver, but there are several vendors shipping their own PPDs which can use foomatic-rip. If they support the driver no longer, user of such device would have to buy a new printer to get printing working, or cups-filters would have to support the allow list on the top of bubblewrap. Additionally common user is now expected to use devices with IPP Everywhere or AirPrint, which are common standards for more than 10 years, and such devices do not use foomatic-rip. The feature will stick with allow/reject mechanism.
6. RPM upgrade scriptlet won't work in bootable containers or atomic desktops - do the upgrade task as systemd service.
Related to 2. feedback - the RPM scriptlet will be moved into a service file foomaticrip-upgrade.service, which will be run at startup and during upgrade - component cups-filters will ship drop-in file for cups.service with Wants dependency on foomaticrip-upgrade.service.
Benefit to Fedora
The change improves Fedora security while leaving a way for users who depend on the driver with the filter foomatic-rip to allow their drivers.
Scope
- Proposal owners:
Proposal owner will apply the upstream patch implementing the issue, and test upgrade path.
- Other developers:
(optional) Printer driver maintainers might scan drivers provided by their package, review the findings and if there is no discrepancies, ship the file with hashed values at directory /usr/share/foomatic/hashes.d.
- Release engineering: N/A
- Policies and guidelines: N/A (not needed for this Change)
- Trademark approval: N/A (not needed for this Change)
- Alignment with the Fedora Strategy:
Upgrade/compatibility impact
Upgrade from Fedora 42 to Fedora 43 will allow the values of already installed printers to maintain functionality, but users are expected to review the file with found values. The file with findings will be present in the directory /var/tmp in the file with prefix foomatic-scan.
How To Test
How to find out if drivers with foomatic-rip are used with the currently installed printers:
$ sudo grep -Rn 'FoomaticRIPCommandLine\|FoomaticRIPCommandLinePDF\|FoomaticRIPOptionSetting' /etc/cups/ppd
/etc/cups/ppd/ricoh.ppd:52:*FoomaticRIPCommandLine: "printf "%%!PS-Adobe-3.0
/etc/cups/ppd/ricoh.ppd:759:*RIPostScript IRIPS/PostScript Emulation: "%% FoomaticRIPOptionSetting: RIPostScript=IRIPS"
/etc/cups/ppd/ricoh.ppd:760:*FoomaticRIPOptionSetting RIPostScript=IRIPS: "/isGenuine{\n&&
...
In the example, the print queue called ricoh uses the affected PPD options.
If its values are not allowed, the following situation will happen:
$ lp -d ricoh /etc/fstab $ journalctl -u cups -r ... Process is dying with \"ERROR: The value of the key FoomaticRIPCommandLine is not among the allowed values - see foomatic-rip man page for more instructions. ... Job stopped due to filter errors; please consult the syslog file for details. ...
User is expected to run foomatic-hash, to review the scan result in file_to_review, and if the found values do not look malicious or the user accepts them, to copy the file local_hashes into the directory /etc/foomatic/hashes.d:
$ sudo foomatic-hash --ppd-paths /etc/cups/ppd file_to_review local_hashes $ sudo cp local_hashes /etc/foomatic/hashes.d $ lp -d ricoh /etc/fstab (Print job succeeds)
User Experience
Users with new Fedora 43 installations will have to allow FoomaticRip values their drivers use after printer installation.
Steps:
$ sudo foomatic-hash --ppd-paths /etc/cups/ppd file_to_review local_hashes $ sudo cp local_hashes /etc/foomatic/hashes.d
Users who upgrade to Fedora 43 are expected to review the found values from their installed printers after upgrade - the file with findings will be present in the directory /var/tmp in the file with prefix foomatic-scan.
In case a malicious or a suspicious value is found, users can find the driver with the value in the directory /etc/cups/ppd. There the driver file is called <printer_name>.ppd, where <printer_name> is the name of a specific printer user has installed. Users are encouraged to reinstall the printer with a different compatible driver or delete such printer.
Dependencies
(optional) Printer driver packages which use foomatic-rip - e.g. hplip, foomatic-db, ptouch-driver, foo2zjs - in case their maintainers are willing to scan their drivers, review findings and ship the hashes in Fedora.
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) The upstream patch won't be applied in cups-filters
- Contingency deadline: Beta Freeze
- Blocks release? No
Documentation
N/A (not a System Wide Change)
Release Notes
Foomatic-Rip filter rejects values of PPD options FoomaticRipCommandLine, FoomaticRipCommandLinePDF, and FoomaticRipOptionSetting which are not allowed in configuration on new Fedora installations by default. Users are expected to run the tool foomatic-hash, review its findings and if they approve the findings are not malicious, allow the values by moving the file with hashes into /etc/foomatic/hashes.d. See man foomatic-rip and man foomatic-hash for more info.
