Installation of software, and security. . .
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I just had some time to think, and I've come across something that
bothers me a lot. I've been attempting to write a small reference that
pools together all of the knowledge I've accumulated about security
enhancements that can be minimally invasive and cooperate properly in a
desktop environment, to design a system secure enough for server use but
specifically friendly for home use.
The goal of download-click-install software is a particular problem.
Some stuff from another post I made elsewhere, but it's really good stuff.
Starting from the ground up, we will examine the current path of
installation in Windows and various package managers.
Windows installation has two paths:
A) A setup.exe program coded by some third party such as Real Networks
or Nullsoft is executed with administrative privileges to modify the system.
B) A .msi Microsoft Installer package is unpacked, and a script coded by
some third party is executed with administrative privileges to process
shell commands and possibly run a setup.exe program to modify the system.
Debian follows a slightly different model consisting of multiple steps:
1) dpkg unpacks a package.
2) A pre-installation script coded by some third party is executed with
administrative privileges to prepare (modify) the system or the package.
3) dpkg copies files to the system.
4) A post-installation script coded by some third party is executed with
administrative privileges to configure the system for the package.
Autopackage also has its method:
1) The package is unpacked by autopackage. (if autopackage doesn't
exist, the package is run as a script; but this is out of scope)
2) A chunk of Autopackage is fed into bash so that it understands prep
script and install script commands.
3) The prep script coded by a third party is fed into bash to check
dependencies. Whatever access the package manager has (administrative
if installing to the system) are inherited by this script.
4) The install scirpt coded by a third party is fed into bash to check
dependencies. Whatever access the package manager has (administrative
if installing to the system) are inherited by this script.
The common factor in each of these methods is that third party code is
run with privileged access before, during, or after the installation.
This may be a problem.
I fear that attempting to secure any desktop system may be a futile
attempt if the package manager allows privileged execution of third
party code during installation. Measures such as warning the user of
SUID programs being installed and other good-practices (obviously a full
audit would be best practice, but not feasible) are pointless if the
program can simply do its dirty work in the preinstall and postinstall
scripts, and get itself some SUID.
Social engineering is a particularly difficult problem. It can't be
fixed but it can be helped; the risks can be reduced. 99% of programs
can run fine without SUID/privileged access, so normal users should be
able to see that as a "red flag" in the same way they see chainletters
and programs delivered in e-mails as "red flags" when they used to mail
them around and run them. Nobody has to be a security expert, they just
need a little help now and then.
Does anyone else think there's a problem with how application
installation is handled?
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC2K60hDd4aOud5P8RAsx9AJ9Z1VQO8TU/Tmk/oKEuvGxfM0N9mwCZAaeL
/omueksiNCE4as9rIdJMcyo=
=THNa
-----END PGP SIGNATURE-----