Paranoia for helpers - best practices

[Federico Mena Quintero]

Hi, all,

Richard Hughes, of worldwide fame, and I were talking about just how
paranoid we must be when writing PolicyKit helpers.

Both Richard's gnome-color-manager and my gnome-display-properties have
a "Make default" button, which lets you take the configuration you have
and make it the default for the whole system.  Both programs essentially
do this by dropping a file in a well-known systemwide location
(think /etc/program-name/blahblah.conf).

PK helpers run as root, which makes "drop a file generated by a user
into a privileged location" potentially dangerous:

* You don't want users to overwrite important files that are not related
to what they are configuring (/etc/passwd).

* You don't want users to use this mechanism to read files which are not
normally readable by them (/etc/shadow or /home/otheruser/private.txt).

The default policy for these helpers is generally "the user may run this
if he knows the root password", which requires a superuser anyway.  But
let's say the sysadmin wants to relax this policy, so that the Graphic
Designers in the shop can tweak the system's color profiles to their
hearts' content without knowing the root password.  In this case, an
Evil Graphic Designer (invariably of the school of postmodern
deconstructivism) should still not be able to trash system files.

When writing gnome-display-properties-install-systemwide, I thought of
the following attacks:

* You shouldn't be able to copy files that don't belong to you, so you
don't end up with a world-readable copy of a private file.  Solution:
check that the file you copy is of the same UID as PKEXEC_UID.

* You shouldn't be able to write files to arbitrary directories, only to
the systemwide configuration directory for your program.  Solution:
don't let the user pass pathnames with directory components for the
destination, just a basename which you convert
into /etc/myprogram/basename.  This avoids both
"destination=/etc/password" and
"destination=../../../home/evil/now-i-can-read-this.txt".

* Usual Unix stuff:  don't stat() and the open() files in a racy
fashion.  Only accept regular files as input, not sockets or other
garbage.  Don't open destination files in a racy fashion.  Ensure atomic
updates of the destination file.  This is normal stuff, but not entirely
trivial to do.

So... my question is:

* Do we need a list of best practices for PK helpers?

* Do we need some helper APIs so that people can do operations like
those with pre-tested code?

* Do we need, in general, a drop_file_in_scary_place() function with
some generic checks?

  Federico