lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 19 Jul 2005 08:38:29 +0200
From: Tino Wildenhain <tino@...denhain.de>
To: John Richard Moser <nigelenki@...cast.net>
Cc: Klaus Schwenk <zooloo_0@....de>, bugtraq@...urityfocus.com
Subject: Re: Installation of software, and security. . .


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.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ