Re: Installation of software, and security. . .

[Klaus Schwenk <zooloo_0 () web de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I had some similar thoughts on that topic recently and do agree with you that
the current habit of installation handling has several problems.

First of all (at least on MS-based OS's) it's pretty hard to tell what exactly
is done by the installer. Even harmless software does not always keep a log of
its actions nor is it observed by some system service. As with malware and/or
malicious scripts it is relatively easy to hide inside the installer letting it
pass through virus detections and the like. In any case this may lead to
unwanted alterations to the system (be it with good or bad intentions).

Now this has been discussed more than once before (and I hope I did not annoy
too many of you), but besides common sense advise to not execute every program
Joe User stumbles upon there has been little to no effort to reduce the usage of
installation scripts/executables. Packet managers as found on *nix derivates are
imho a step in the right direction but need to be better at telling the user
what a specific packet will do exactly. As for Windows the situation is more or
like a complete mess. Far too many programs wouldn't need an installation in the
first place. And it's hard to give end users a rule of thumb on how to handle
installation programs when there is no real agreement on what installers should
(not) do. At least from my POV.

John Richard Moser schrieb:
> 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 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC2rcKlTx3gW8+0V4RAi92AKCOKpu/WvrS52yu/fl7/aGu85FUTwCfaoIi
MURxyuqvM4IP+4C0A5aNyq8=
=vGMC
-----END PGP SIGNATURE-----