OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: Installation of software, and security. . .

From: Tino Wildenhain (tinowildenhain.de)
Date: Tue Jul 19 2005 - 01:38:29 CDT


Am Sonntag, den 17.07.2005, 16:09 -0400 schrieb John Richard Moser:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Klaus Schwenk wrote:
> > 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
>
> Exactly my point. How do you manage or reduce risk when you can't even
> tell what changes are to be made? An executable has to be run to truly
> understand its actions; scripts can self-modify (variables run as code),
> executables can have odd logic that obfuscates things from heuristics
> examinations. You can't make an auditing tool to list all changes about
> to be made and actions to be taken by installing the program (aside from
> a spare machine and a debugger).
>
...
> Package managers found in Linux typically run a pre-install script to
> prepare the system, and a post-install script to post-configure the
> system. These scripts are bash scripts run as root.
>
> Installing blackdown java on Debian or Ubuntu is something you have to
> be very careful about. The pre-install asks about licensing; if you say
> "No" it stores that you refused the license agreement in a debconf
> database somewhere and aborts the install. You can try to install the
> package again, but it will abort. All combinations of --purge and
> manually editing the dpkg database do nothing. I couldn't find the
> debconf settings database thing it used, so I had to reinstall the system.
...
>
> Yes, you hit the nail on the head with a jackhammer. One discussion on
> autopackage was that the devs don't want to limit the API and thus want
> the prepare, install, and uninstall to be a bash script supplied by the
> package "so it can do anything." I hate this logic. Why does it need
> to be able to do "anything"?
...
maybe not directly related but I loved the installer of amigaos (2.0 and
up) which basically leave the choice to actually "try" an installation,
where all the steps and questions (based on the level you use) were run
but no file changed or moved. You could then inspect the logfile to see
what would be done before running the installer in actual install mode.
Afaic it was running some lisp-like code as script so you didnt need
external scripts.