Safer package installation
There's been some discussion on the list lately about the possibility
of secure package installation, and whether it's possible, desirable,
or practical. Secure installation of Unix software can be complicated,
but there are some principles that can simplify things and make it
less error-prone and bug-ridden. Scripts to implement safer software
installation already exist in the form of "opt_depot." Bob Meier and I
plan to investigate the notion of integrating this type of procedure
into dpkg/dselect. The following is a sketch of our ideas and a call for
comments and suggestions.
Installed packages go to a specific place in the file hierarchy, e.g.
"/usr/packages/<package-name>/". There's "/usr/packages/<name>/lib/",
"/usr/packages/<name>/bin/", etc. A script then makes symlinks from, say,
"/usr/lib/<file-name>" to "/usr/packages/<package-name>/lib/<file-name>".
Deinstallation is a snap. All you do is use "find" to track down and
remove all the symlinks to "/usr/packages/<package-name>/*", and then
remove the "/usr/packages/<package-name>/" directory. Note that these
two steps have a very high reliability. You will almost never have
extra files laying around because the maintainer forgot to update a
removal script. Let us reflect for a moment about the contrast between
this and Windows.
It also enhances security noticeably. The package maintainer can
screw up the whole system because of a buggy script the way things
currently stand. Imagine the havok caused by the canonical single-typo
error "rm -r / usr/lib/somedir". I'm pretty sure everyone reading this
list has run into problems with buggy install scripts. Bugs happen,
and we have to try to minimize the problems any one bug can cause.
If we use the "/usr/packages/*" method, though, we can separate
installation into two steps. The maintainer supplies normal install
scripts that handles everything under "/usr/packages/<package-name>/".
It runs as, say, user "tool", group "bin". After that's finished, a
separate, *standard*, Debian-provided script runs (as root) that sets
up the symlinks, and changes the ownership of
"/usr/packages/<package-name>" to, e.g., "bin:bin". (Or "root:root",
or "<package>:dialout,dip", or whatever is needed.)
Thus, a new package cannot affect older, installed packages during
installation (they are owned by another user and group, after all).
Root's job is simple and well-defined, and pretty hard to subvert.
Yes, there are exceptions. Shadow passwords have to muck with
/usr/passwd. PPP has to stick a few things in /etc. Mosaic wants to
set up three separate directories (one for the software, one for
config files, one for documents). Support for installation in more
than one directory will be needed. In more complicated cases the
maintainer can supply a special script that handles these chores, that
will be run as another user, perhaps root. "But wait," you say,
"aren't you giving up your security right there?" No, for a couple of
reasons.
First off, one can determine which packages are most likely to cause
system problems simply by asking the question, "Which packages need a
specially-privileged pre- or post-install script?" These can then be
singled out for special attention. Dselect and dpkg can be set to
prompt, "This package requires a script to run as user "root". Do you
want to [e]xamine the script, [r]un it, or [a]bort installation?"
Second, the riskier, privileged operations are concentrated in
easy-to-find areas by design. A maintainer can't scatter them around
multiple places in multiple scripts. They are thus easier to find and
therefore easier to monitor and debug. (And probably will receive more
attention in the first place when they're written.)
This dovetails pretty well with the idea of maintainer certification.
You can have looser certification for those packages which don't need
special installation handling and rigorous certification for those
packages which need root access. (This also helps to make a more
standard environment for building source-only packages, BTW. Some have
called for more of that sort of thing. :-> )
No, this is not a panacea. Bugs will still happen, and security flaws
can still be found. But the advantages are clear and, I think,
worthwhile. Just knowing that if I uninstall something it won't leave
useless files around wasting disk space is wonderful. (How much cruft
does the average Windows setup accumulate per year?) Enhanced
reliability and security is just a very welcome bonus. (But a *nice*
bonus.)
This does require revision of dpkg, dselect, and the .deb format. We
hope to make the benefits worth the changes. Again, suggestions welcome!
Sincerely,
Ray Ingles (810) 377-7735 inglesra@frc.com
"Is knowledge knowable? If not, how do we know this?" -- Woody Allen
Reply to: