The CUPS and Printing Support in Kicksecure

Hello :grinning_face_with_smiling_eyes: :waving_hand:

So whats up with the printing situation in kicksecure?

[user ~]% apt list --installed | grep cups

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libcups2t64/stable,now 2.4.10-3+deb13u2 amd64 [installed,automatic]
[user ~]% 

If its just libcups2t64 does this effectively mean at the minimum that CUPS is missing for local printing?

Why is CUPS not included?

Too much of an attack surface not worth maintaining for a small % of users?

CUPS is often reachable over internal networks, and sometimes even the public internet. I have never seem a distro that distributes a hardened version of it. There was some new 2026 CVE’s that maybe you saw that are very similar to the 2024 CVE’s that are on official cups github security advisory section.


My Debian 13 shows lots of cups packages man that are prob unnecessary for basic printing (no network printing):

debian13@localhost:~$ apt list --installed | grep cups

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

cups-client/stable,now 2.4.10-3+deb13u2 amd64 [installed,automatic]
cups-common/stable,now 2.4.10-3+deb13u2 all [installed,automatic]
cups-core-drivers/stable,now 2.4.10-3+deb13u2 amd64 [installed,automatic]
cups-daemon/stable,now 2.4.10-3+deb13u2 amd64 [installed,automatic]
cups-filters-core-drivers/stable,now 1.28.17-6+deb13u1 amd64 [installed,automatic]
cups-filters/stable,now 1.28.17-6+deb13u1 amd64 [installed,automatic]
cups-ipp-utils/stable,now 2.4.10-3+deb13u2 amd64 [installed,automatic]
cups-pk-helper/stable,unstable,now 0.2.6-2.1 amd64 [installed]
cups-ppdc/stable,now 2.4.10-3+deb13u2 amd64 [installed,automatic]
cups-server-common/stable,now 2.4.10-3+deb13u2 all [installed,automatic]
cups/stable,now 2.4.10-3+deb13u2 amd64 [installed]
libcups2t64/stable,now 2.4.10-3+deb13u2 amd64 [installed,automatic]
libcupsfilters1t64/stable,now 1.28.17-6+deb13u1 amd64 [installed,automatic]
libcupsimage2t64/stable,now 2.4.10-3+deb13u2 amd64 [installed,automatic]
printer-driver-hpcups/stable,unstable,now 3.22.10+dfsg0-8.1 amd64 [installed,automatic]
python3-cups/stable,now 2.0.4-2+b2 amd64 [installed,automatic]
python3-cupshelpers/stable,unstable,now 1.5.18-4 all [installed,automatic]
debian13@localhost:~$

Network printing or printing to a remote cups server is like 1% of linux users if any at all lets be honest unless you are enterprise or advanced you are most likely not doing this.

Currently I have a Brother printer that just worx out of the box on Debian 13. Most modern printers including Brother can use IPP-over-USB (Driverless Printing). Mine I just plugged in USB printer cable and it just worked either the driver was included by default or its using driverless printing.

I’m just trying evaluate the printing situation in Kicksecures defaults. Modern brands work without needing network access. HP however, the brand has gone down hill tremendously, partly why I switched. Modern HP printers effectively require network access for cloud, updates and BS.

Due to this fact, most security conscious are not going to mess with HP printers on linux and aren’t going to use a printer connected to a network either. So that makes this fall in the 1% of users again (my opinion).

Would you say supporting printing in general would be 0.1% of kicksecure user base. Kicksecures wiki page on printing not very clear compared to Whonix’s page. Does anyone even print on Whonix? Again this prob a small % of users.

My use case when printing is QR codes and things I’m studying.

Would Kicksecure reconsidering shipping CUPS included with hardening and isolation :red_question_mark:

It’s not entirely clear to me what “CUPS with hardening and isolation” would look like. Applying special configuration to CUPS would be likely undesirable in Kicksecure because it would diverge from upstream, in a way that would potentially incur greater maintenance effort. See:

If you need to print but are also concerned about the security implications, you might be able to install a dedicated Kicksecure or Debian 13 virtual machine with CUPS installed within, then pass through your USB printer to the VM and print from there.

2 Likes

cups isn’t installed by default because it opens a listening port by default.

2 Likes

Just looked through manpages and online documentation for cups. I take it CUPS does not natively support a .d/ drop-in directory structure (like /etc/cups/cups.d/`) right​:red_question_mark:

To close the listening port you have to edit the /etc/cups/cupsd.conf directly I guess and :crossed_fingers: that nothing is changed after updates.

This GitHub issue specifically addresses the removal and requested reinstatement of the Include directive in cupsd.conf. A feature that would allow one configuration file to reference another.

Ok, this is for apple but looks like it could relate here. Uncertain if a .d/ drop in directory support ever existed at all :person_shrugging:

I’m trying to reduce my reliance on virtual machines for security. The reason I’m trying Kicksecure :person_facepalming: you know is partly this reason to do most on a secure host. Since you suggested it, I might give er a go and see what its like. Wish me luck :joy: :zany_face:

1 Like

I’d encourage you to not do that :slight_smile: Kicksecure is very hardened in comparison to vanilla Debian, but even so, vulnerabilities can (and have) existed in system components like the Linux kernel that Kicksecure was vulnerable to, and where no major Linux distribution could have reasonably been immune to the vuln before it was found. (The recent Copy Fail and Dirty Frag vulns are good examples.) Using Kicksecure as a hardened virtual machine host is good defense-in-depth.

2 Likes
$ ss -l | grep -E "cups|ipp|631"
u_str LISTEN 0      4096                                                                                            /run/cups/cups.sock 17283                            * 0          
tcp   LISTEN 0      128                                                                                                       127.0.0.1:ipp                        0.0.0.0:*  

Is that this?

I was reading about Unix socket handling on GitHub (possibly related to privleap or other kick documentation), and it made me look at more how CUPS handles its sockets and configuration on Debian/Ubuntu. Here’s what I’m seeing on my debian system:

Socket unit location:

$ systemctl show cups.socket -p FragmentPath
FragmentPath=/lib/systemd/system/cups.socket

Socket file locations:

$ find /usr/lib/systemd /lib/systemd -name "cups.socket" 2>/dev/null
/usr/lib/systemd/system/cups.socket
/lib/systemd/system/cups.socket

CUPS configuration directory:

$ ls -a /etc/cups
.                  cups-files.conf  raw.types           subscriptions.conf.O
..                 interfaces       snmp.conf
cups-browsed.conf  ppd              ssl
cupsd.conf         raw.convs        subscriptions.conf

Something I learned about cupsd.conf packaging. On Debian/Ubuntu, cupsd.conf is not treated as a proper dpkg conffile. Instead, the cups-daemon.postinst script checks whether cupsd.conf exists, if it doesn’t, it copies from /usr/share/cups/cupsd.conf.default. This means the file gets created on initial install but isn’t updated during package upgrades via dpkg’s normal conffile mechanism, even if the admin never modified it.

Upstream CUPS rejected a request to move cupsd.conf.default out of /etc/cups/, though for a different reason than user confusion.
non-CUPS code expects to find cupsd.conf.default in SERVERROOT.

Default config template location:

$ find /usr/share/ -name "cups-files.conf.default" 2>/dev/null
/usr/share/cups/cups-files.conf.default