Bad PrivateTmp=true workaround

[Tim Waugh]

In HPLIP-3.12.6, hpfax has this:

    # REVISIT:
    tmp_dir = '/tmp'
    Cups_service_file="/usr/lib/systemd/system/cups.service"
    if os.path.exists(Cups_service_file):
       cmd="grep PrivateTmp=true %s"%Cups_service_file
       sts, out = utils.run(cmd)
       if sts == 0:
          tmp_dir = '/var/log/hp'

This is wrong. Firstly, /usr/lib/systemd/system/cups.service is not the right place. Even if it were, it can be overridden by a file in /etc.

Besides, why not just use an HPLIP-private directory regardless of whether PrivateTmp is in use in CUPS? Why try to create a predictable filename in /tmp (and thus expose yourself to a denial of service by someone already having created them all), when you can just as easily use your own directory?

I'd suggest something like /var/run/hp.

Even better, since this is all in order to send a D-Bus message with data, why not change the D-Bus API so that a file descriptor is passed directly to the D-Bus service? (See e.g. colord or printerd for an example of this.)

[Tim Waugh (twaugh)]

In 3.12.11 it's even worse: now /var/log/hp and /var/log/hp/tmp are both world-writeable! That's really bad news. Any user can now e.g. delete files they don't own, etc.

Please don't use temporary directories for transferring files between different contexts. For the fax service, D-Bus is able to transfer files in method calls (by passing file descriptors) and this is a much better way of doing it than (a) writing to predictable filenames and risking symlink attacks, or (b) leaving world-writeable directories around tempting DoS attacks.

[Tom E. Gundersen (tomegundersen)]

Could we get a comment on what the status is with the world-writeable bit on these directories? What would break if we change it to 775 downstream? Is there any reason to believe that keeping it at 777 won't lead to serious exploits?

[Johannes Meixner (jsmeix)]

In hplip-3.12.11 in the openSUSE "Printing" project I change it to
drwxrwxr-x ... root lp ... /var/log/hp

I want to make sure that openSUSE users won't get
a security issue delivered "out of the box".

I do not care what might fail if it is not mode 777.

[Johannes Meixner (jsmeix)]

An openSUSE 12.2 user reported that hp-sendfax fails
because of missing /var/log/hp/tmp/ directory, see
https://bugzilla.novell.com/show_bug.cgi?id=800312

I don't have a HP device with fax functionality
so that I cannot reproduce it on my own.

I assume it happens because in openSUSE
/var/log/hp/ is not writable by arbitrary users
(it is "drwxrwxr-x root lp /var/log/hp" see previous comment)
so that /var/log/hp/tmp/ cannot be created therein
when a normal user runs hp-sendfax.

The openSUSE user reported that
  # mkdir /var/log/hp/tmp
  # chown root:lp /var/log/hp/tmp/
  # chmod 775 /var/log/hp/tmp/
makes it work for him but he also had added
his normal user account to the "lp" group.

I assume adding the user to the group "lp" is required
here so that hp-sendfax works for this user because
otherwise the user cannot write in
  drwxrwxr-x root lp /var/log/hp/tmp

[Carsten Ziepke (carsten-ziepke)]

Just some more clarifications to my description (I am the openSUSE 12.2 user Johannes mentioned):

My test user was later no more in the group "lp" (this was just the case earlier in my tests).
But fax sending works with: drwxrwxr-x root lp /var/log/hp/tmp (like in my description)

User who wants to send a fax is:
uid=1010(carsten) gid=100(users) Gruppen=100(users),33(video)

Directory settings:
drwxrwxr-x 3 root lp 4096 25. Jan 09:51 hp (/var/log)
drwxrwxr-x 2 root lp 4096 25. Jan 09:38 tmp (/var/log/hp)

User is adding a file via hp-sendfax (temporary files in /var/log/hp/tmp):
prw-rw-rw- 1 root lp 0 25. Jan 09:38 hpfax-pipe-45
-rw------- 1 lp lp 0 25. Jan 09:38 hplipfaxLog_QdLyvl

[Amarnath Chitumalla (amarnath-chitumalla)]

Hi,

In latest HPLIP, Private Tmp issue is being handled by creating the /var/log/hp/tmp directory with 775 permissions (root-lp-others) and HPLIP is not creating any predictable temporary files. Please let us know if any change is required.

Thanks & Regards,
Amarnath