Bad PrivateTmp=true workaround

Bug #1016507 reported by Tim Waugh on 2012-06-22
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
HPLIP
Undecided
Unassigned
Arch Linux
New
Undecided
Tom E. Gundersen

Bug Description

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) wrote :

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.

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?

Changed in archlinux:
assignee: nobody → Tom E. Gundersen (tomegundersen)
Johannes Meixner (jsmeix) wrote :

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) wrote :

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) wrote :

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

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

Changed in hplip:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.