Installation of software, and security. . .

[John Richard Moser]

-----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-----

[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).

> 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

Flaw in the virus scanner but eh.

> 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).
>

Yes, evil. Nuff said.

> 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

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.

That pre-install script could very well have 'dd if=/dev/urandom
of=/dev/hda' and that would be it (I'm on sata so it'd be /dev/sda).

It's a step in the right direction; files are copied where they go by
the package manager. Problem is, other files can be copied around by
the scripts too, and the PM won't remove those.

> what a specific packet will do exactly. As for Windows the situation is more or

It will install X files, and run some script that you can read, but
probably won't understand.

> 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.
>

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"?

- --
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.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC2rrchDd4aOud5P8RAowyAJ0Ty8CgXLMH5lCHhGwL3H 1X4CG/+wCgjJq8
bZYd2oX7moQvJNknR1z1uoM=
=MIlk
-----END PGP SIGNATURE-----

[Klaus Schwenk]

-----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-----

[Tim Nelson]

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--0-804175947-1121745661=:3530
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Sun, 17 Jul 2005, John Richard Moser wrote:

>> 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.
>>
>
> 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"?

I think you're both right :). I agree that packages need to be
able to do anything, but it'd be nice if we could try to eliminate the pre
and post install scripts.

One thing that would be useful is if someone could look at the
things that are typically done in pre/post install scripts, and then
integrate those into the package manager. We have a set of custom RPMs
here, and they do a variety of things in the pre and post install scripts,
but the main ones are:
- Reconfigure other software; apache never needs this, because it
uses the conf.d directory, but the tomcat we use doesn't seem to
work this way, and it should
- Service reloads; after we add a file which does the apache config,
we need to reload apache; if RPM supported us going
"%reload apache", then we wouldn't need the post-install script
for that

My suggested solution would be to:
1. Build in to RPM (or whatever) any relatively harmless features
which are regularly used (eg. reload)
2. Issue a security warning and quit for any packages that have
pre/post install scripts, and any actions that might cause trouble
(eg. reload)
3. Set --with-scripts (or something) to enable running scripts, and
--with-actions to enable potentially troublesome actions (eg.
reload), or --without-actions to just install files and not do the
actions.

?

:)

--
Kind Regards,

Tim Nelson
Server Administrator

P: 03 9934 0888
F: 03 9934 0899
E: tim.nelson@webalive.biz
W: www.webalive.biz

WebAlive Technologies
Level 1, Innovation Building
Digital Harbour
1010 La Trobe Street
Docklands Melbourne VIC 3008

This email (including all attachments) is intended solely for the named addressee. It is confidential and may contain legally privileged information. If
you receive it in error, please let us know by reply email, delete it from your system and destroy any copies. This email is also subject to copyright. No
part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner.

Emails may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems. We give no
warranties in relation to these matters. If you have any doubts about the authenticity of an email purportedly sent by us, please contact us immediately.

--0-804175947-1121745661=:3530--

[Tino Wildenhain]

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.

[Kerry Thompson]

On Sun, 2005-07-17 at 16:09 -0400, John Richard Moser wrote:
> 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).
>

I agree, you really can't do it that way: auditing any non-trivial
software package is way too hard for anyone ( read: not cost
effective ). But there are systems which can constrain what the
installation process can do and, in turn, what the installed software is
capable of doing on a system.

SELinux, for example, has a security policy for the rpm package
installer. In short, it allows the rpm executable to install new files,
overwrite some files, and set permissions. It permits the execution of
an installation script, but constrains the functions executed by that
script to fairly simple operations like chmod, chown, etc. All other
operations ( eg. network access to download and install the spyware-du-
jour ) is blocked - and blocked at the kernel level.

So while you can't audit package xyz directly, you can ( on the SELinux
system ) constrain what that package is permitted to do. And there are
tools which will audit the policy rules, so you can audit what the
package can do and come up with a worst-case scenario if the package
turned out to be malicious.

There are also other constraints in play in the real world - if a
package distribution site was distributing malicious packages then I'm
sure we would all hear about it, and the repercussions would be swift,
severe, and probably quite a public spectacle.

--
Kerry Thompson
http://www.crypt.gen.nz

[Jason Coombs]

Tim Nelson wrote:
> On Sun, 17 Jul 2005, John Richard Moser wrote:
>> 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"?
>
> I think you're both right :). I agree that packages need to be able
> to do anything, but it'd be nice if we could try to eliminate the pre
> and post install scripts.

Developers think that installers need to be able to do anything because
the developers think of themselves as being trustworthy. The code
written for an installer doesn't do anything harmful and it can be
trusted, so why should it not have the ability to do anything that the
developer decides it needs to do?

All malicious attacks originate from the hands and minds of other
people, malicious people, therefore a typical developer cannot see any
harm in their own way of thinking or in their own installer. Even those
developers who perceive an unacceptable risk or intrinsic flaw in the
way that these things get built and deployed have a very hard time
seeing themselves as responsible for the harm caused by others.

The truth is that people who expressly allow systems that are harmful to
continue to exist can be held responsible for the damage that those
systems cause, regardless of the fact that the malicious actor who
initiates the specific harm in each instance is somebody else entirely.

See: Metro-Goldwyn-Mayer Studios Inc. v. Grokster, Ltd.
http://www.supremecourtus.gov/opinions/04pdf/04-480.pdf

Thus, if you are a developer and you deploy software without giving
serious thought to the things that you could do to make the entire
process of software distribution and installation safer for everyone,
then you are part of the problem.

Hopefully everyone can now see that applying digital signatures to code
is a pointless exercise in somebody else's arbitrary business strategy
(i.e. VeriSign and other purveyors of so-called 'federated identity
solutions') and is not being used today as a means of achieving improved
information security. A very sad state of affairs, given that signed
code at least attempts to address these issues of security during the
software installation/distribution process, albeit today's
implementations as a rule are very poorly-conceived.

We would all receive vastly-improved installation security if every
software vendor would adopt a standard for code/data/installer
authentication (that does not require digital signatures but that could
optionally use them) based on a keyed hash algorithm and a low-cost
specialized electronic device that sits on the desktop or in the server
room alongside the box to which software is deployed and is used to
verify hashes and explain forensically what the installer intends to do
to configure the box and deploy the code and data to it.

Of course that's just the ideal improvement, which I personally believe
the industry could even train end-users to understand and use.
Particularly if the proposed device were to generate an installation key
that the user would be required to enter in order to install the
software. (Sure, greedy people would try to use this to increase license
revenue or improve controls over intellectual property and copyright;
they will just have to be fought back by those who understand that the
point is security not personal enrichment.)

Short of the ideal stand-alone embedded system this concept could also
be built as software-only. Does anyone care? Will anyone ever build it?

Regards,

Jason Coombs
jasonc@science.org

[Matt Beaumont]

--VS++wcV0S1rZb1Fb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 19, 2005 at 14:01:01 +1000, Tim Nelson wrote:
> My suggested solution would be to:
> 1. Build in to RPM (or whatever) any relatively harmless features
> which are regularly used (eg. reload)

That's a double-edged sword. On the one hand, a "standard library" of
useful installation actions could make life easier for developers and
package maintainers. On the other hand, the package management system
would then also have to play nice with the idiosyncracies of the service
management mechanisms on whatever systems are supported by the former.=20

> 2. Issue a security warning and quit for any packages that have
> pre/post install scripts, and any actions that might cause trouble
> (eg. reload)
> 3. Set --with-scripts (or something) to enable running scripts, and
> --with-actions to enable potentially troublesome actions (eg.
> reload), or --without-actions to just install files and not do the
> actions.

Good idea in principle, but a malicious package will just arrange to
tell J. Random User to run the install with whatever dangerous flags
allow the malware to do its thing, and, corollary to the "J. Random User
will always just click OK" principle of user psychology, the user will
follow the instructions and the box will get 0wned.

Anyway, that's just my two cents.=20

Cheers,
Matt

--VS++wcV0S1rZb1Fb
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFC3S5r6jbu++NtcqMRAri/AKCLPH+T69v9cr0i1TLMP8VrUO5xAQCgm241
6n7z7/WpDZOEfmzPlJ8m1kU=
=SEoK
-----END PGP SIGNATURE-----

--VS++wcV0S1rZb1Fb--

[Burton Strauss]

Remember, if you DID NOT require 'root' access to install a privileged
binary, that in itself represents a major privilege escalation hole. So the
reality is that to install software (binary or source you compile yourself)
- regardless of platform - at some point you need to access privileged
system resources (whether that's /usr/sbin/ or the Windows registry doesn't
matter).

That is precisely why you should only install binary packages from reputable
sources and why said reputable sources should sign their package such that
you can verify that the downloaded file is in fact the one you expected to
receive (this is typically through some form of a hash value or signature).

How many of us actually do this? That's a matter for another thread...


As to why you need the option to 'do anything'? It's because there is no
simple set of transformations that everyone agrees on which are required as
part of an installation. Start simple:

Write to the binary directory. Ok, what are they? That's distribution
dependent (/usr/sbin, /sbin/, /opt/sbin, what???)
Create a user/group. Remember, different distributions have different
structures for users (RedHat's user-specific groups)
Change file ownership.

etc., etc., etc.

Keep building the list. But remember: Anything you forget to permit will
cause some package, somewhere out there to fail to install. And that's why
most packaging processes allow unlimited scripting.


-----Burton



-----Original Message-----
From: John Richard Moser [mailto:nigelenki@comcast.net]
Sent: Sunday, July 17, 2005 3:09 PM
To: Klaus Schwenk
Cc: bugtraq@securityfocus.com
Subject: Re: Installation of software, and security. . .

-----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).

> 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

Flaw in the virus scanner but eh.

> 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).
>

Yes, evil. Nuff said.

> 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

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.

That pre-install script could very well have 'dd if=/dev/urandom
of=/dev/hda' and that would be it (I'm on sata so it'd be /dev/sda).

It's a step in the right direction; files are copied where they go by the
package manager. Problem is, other files can be copied around by the
scripts too, and the PM won't remove those.

> what a specific packet will do exactly. As for Windows the situation
> is more or

It will install X files, and run some script that you can read, but probably
won't understand.

> 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.
>

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"?

<snip />

[Burton Strauss]

I think you are wrong. Suppose you do create that (mythical) complete =
set
of actions inside the package manager.

You can't add security - by definition if you run an rpm-type install =
you
are root, so there's nothing new.

You can't use something like SELinux unless you split the package in two =
(a
god-equivalent version to add the permissions for the install to the =
SElinux
databases and then a non-root install using those permissions). So =
instead
of hacking into the install, just hack into the god-equiv part).

All you've done for yourself is to create another (mini) 'language' the
packager has to learn, instead of using good ole
(insert-name-of-shell-here). =20

Where there could be gains are in a small number of those 'hard to do =
right'
actions, which are usually erroneously scripted. But as it is, many =
RPMs
(and I'm guilty here), don't use what IS available. So adding more =
things
won't really help that much either.

Fixing package scripts to take advantage of your new, wonderful actions
would be a massive task, across 1000s of packages (and egos) to fix.

So if there's nothing gained, well, why bother?

However, there is somewhere you can affect things - and that is within =
rpm
itself. How: enable/force better logging of the actions performed =
during a
script. Down to the line-of-a-script level if you want. That would be
effective/useful, even if nobody ever fixed up a script.



-----Burton
=20

-----Original Message-----
From: Tim Nelson [mailto:tim.nelson@webalive.biz]=20
Sent: Monday, July 18, 2005 11:01 PM
To: John Richard Moser
Cc: Klaus Schwenk; bugtraq@securityfocus.com
Subject: Re: Installation of software, and security. . .

On Sun, 17 Jul 2005, John Richard Moser wrote:

>> like a complete mess. Far too many programs wouldn't need an=20
>> installation in the first place. And it's hard to give end users a=20
>> 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.
>>
>
> Yes, you hit the nail on the head with a jackhammer. One discussion=20
> on autopackage was that the devs don't want to limit the API and thus=20
> want the prepare, install, and uninstall to be a bash script supplied=20
> by the package "so it can do anything." I hate this logic. Why does=20
> it need to be able to do "anything"?

I think you're both right :). I agree that packages need to be able
to do anything, but it'd be nice if we could try to eliminate the pre =
and
post install scripts.

One thing that would be useful is if someone could look at the
things that are typically done in pre/post install scripts, and then
integrate those into the package manager. We have a set of custom RPMs
here, and they do a variety of things in the pre and post install =
scripts,
but the main ones are:
- Reconfigure other software; apache never needs this, because it
uses the conf.d directory, but the tomcat we use doesn't seem to
work this way, and it should
- Service reloads; after we add a file which does the apache config,
we need to reload apache; if RPM supported us going
"%reload apache", then we wouldn't need the post-install script
for that

My suggested solution would be to:
1. Build in to RPM (or whatever) any relatively harmless features
which are regularly used (eg. reload)
2. Issue a security warning and quit for any packages that have
pre/post install scripts, and any actions that might cause trouble
(eg. reload)
3. Set --with-scripts (or something) to enable running scripts, and
--with-actions to enable potentially troublesome actions (eg.
reload), or --without-actions to just install files and not do the
actions.

?

:)

--
Kind Regards,
=A0
Tim Nelson
Server Administrator
=A0
P: 03 9934 0888
F: 03 9934 0899
E: tim.nelson@webalive.biz
W: www.webalive.biz
=A0
WebAlive Technologies
Level 1, Innovation Building
Digital Harbour
1010 La Trobe Street
Docklands Melbourne VIC 3008

This email (including all attachments) is intended solely for the named
addressee. It is confidential and may contain legally privileged
information. If you receive it in error, please let us know by reply =
email,
delete it from your system and destroy any copies. This email is also
subject to copyright. No part of it should be reproduced, adapted or
transmitted without the written consent of the copyright owner.

Emails may be interfered with, may contain computer viruses or other =
defects
and may not be successfully replicated on other systems. We give no
warranties in relation to these matters. If you have any doubts about =
the
authenticity of an email purportedly sent by us, please contact us
immediately.

[David F. Skoll]

John Richard Moser wrote:

> 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"?

But who cares? Suppose you invent a package format that ONLY
allows packages to copy files into their final locations. And it doesn't
permit script execution, nor does it permit SUID or SGID files.

It's still dead easy to compromise the system. I can think of several
ways off-hand (all examples are UNIXy):

- Install a malicious startup script in /etc/init.d
- Install a malicious cron job in /etc/cron.d
- Install a malicious script in /etc/profile.d for those systems that use it

You're assuming that an installation mechanism that allows an attacker
to place whatever files he wants in whatever locations he wants is
somehow safer than one that also permits install scripts to run.
That's pretty naive.

Even if the package manager knows about /etc/init.d, /etc/cron.d and
friends and refuses to permit packages to drop scripts there, some
random package X might make use of a script or module directory that
a malicious package Y can drop files in.

Essentially, you should consider it just as dangerous to install software as
to run it.

Regards,

David.

[Alexander Klimov]

On Sat, 16 Jul 2005, John Richard Moser wrote:
> Windows installation has two paths:
> [...]
>
> Debian follows a slightly different model consisting of multiple steps:
> [...]
>
> 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.

There is also a great difference between what you call `third party:'
it is really `third' in Windows case (you and MS are the first and the
second), but in case of Debian most often it is not `third party code'
because it is the code prepared/checked and signed by the second party
(Debian) and so the code is trusted (you have to trust your OS
vendor).

If you get some software from somebody you can not trust then your
best bet is to run it inside some separated environment (as a separate
user, from vmware, etc.)

BTW: some package management systems do ask about executing code, for
example, the pkgadd utility warns you that some scripts must be
executed with super-user permissions.

--
Regards,
ASK

[John Richard Moser]

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



Burton Strauss wrote:
> At best the SCOTUS Grokster opinion bounces the case back to the lower
> courts saying "You erred in dismissing under Betamax".
>
> It's also pretty clear that the Supremes said "Oh, and from looking at the
> facts of this case in that light, MGM will probably win".
>
> So it's now clear that a non-infringing purpose isn't an absolute shield for
> a technological device. You also have to have clean hands regarding the
> usage of it.
>
>
> "Thus, if you are a developer and you deploy software without giving serious
> thought to the things that you could do to make the entire process of
> software distribution and installation safer for everyone, then you are part
> of the problem." is a HUGE stretch.
>
> The mere fact that somebody COULD put a nasty script into SOME package? No
> way... Now if you sold/gave away your Wonka-Magic-Software-Installer saying
> "Oh, and BTW, Wink, Wink, if you were to add this script to your package,
> you will install 27 Trojan and SpyWare apps and we'll pay you $2/copy
> distributed". Well, then, you don't have clean hands...
>
>
> I guess that puts me in the camp that thinks Grokster isn't a bad decision.
>
> It might become one - after a couple more cycles through the courts make the
> new rules clear.
>
> But on it's face? No... In fact, I'd love to see the same kind of rules
> applied to a couple of other industries/technologies - Guns for example (how
> many Deer do you find running around the woods wearing Kevlar?). Tobacco,
> Pharma and 'Nutritional' Supplements for others...
>
>
> OK, back to relevant stuff...
>
> How do we hit the middle ground - enough control over what is done so that
> there is:
>
> * At least a record of what was done.
> * Some attempt at obtaining informed consent.
>
> And, Can we do this within (or just beyond) current packaging methods?
>

Problem being that when you run a program with full access, it has full
access. That means you may see executable code that makes finite
decisions etc, but you'll have to write a hugely complex,
turring-complete emulator to properly determine the system's eventual state.

The other way is to shield the system from all these things it can do
and let it do whatever as long as it doesn't really do anything; then
merge the changes. Mandatory access control policy can do this; though
then you're pushing the responsibility down to another level of the
system (controlling the package manager becomes a kernel duty). In the
case of Autopackage it's been agreed that this is a good course of
action, but Autopackage itself (the project) MUST define the policy and
state that this is the supported rule set and packages which break
because they violate it are SOL.

>
> -----Burton
>
>
>
> -----Original Message-----
> From: Jason Coombs [mailto:jasonc@science.org]
> Sent: Tuesday, July 19, 2005 12:16 PM
> To: Tim Nelson
> Cc: John Richard Moser; Klaus Schwenk; bugtraq@securityfocus.com
> Subject: Re: Installation of software, and security. . .
>
> Tim Nelson wrote:
>
>>On Sun, 17 Jul 2005, John Richard Moser wrote:
>>
>>>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"?
>>
>> I think you're both right :). I agree that packages need to be
>>able to do anything, but it'd be nice if we could try to eliminate the
>>pre and post install scripts.
>
>
> Developers think that installers need to be able to do anything because the
> developers think of themselves as being trustworthy. The code written for an
> installer doesn't do anything harmful and it can be trusted, so why should
> it not have the ability to do anything that the developer decides it needs
> to do?
>
> All malicious attacks originate from the hands and minds of other people,
> malicious people, therefore a typical developer cannot see any harm in their
> own way of thinking or in their own installer. Even those developers who
> perceive an unacceptable risk or intrinsic flaw in the way that these things
> get built and deployed have a very hard time seeing themselves as
> responsible for the harm caused by others.
>
> The truth is that people who expressly allow systems that are harmful to
> continue to exist can be held responsible for the damage that those systems
> cause, regardless of the fact that the malicious actor who initiates the
> specific harm in each instance is somebody else entirely.
>
> See: Metro-Goldwyn-Mayer Studios Inc. v. Grokster, Ltd.
> http://www.supremecourtus.gov/opinions/04pdf/04-480.pdf
>
> Thus, if you are a developer and you deploy software without giving serious
> thought to the things that you could do to make the entire process of
> software distribution and installation safer for everyone, then you are part
> of the problem.
>
> Hopefully everyone can now see that applying digital signatures to code is a
> pointless exercise in somebody else's arbitrary business strategy (i.e.
> VeriSign and other purveyors of so-called 'federated identity
> solutions') and is not being used today as a means of achieving improved
> information security. A very sad state of affairs, given that signed code at
> least attempts to address these issues of security during the software
> installation/distribution process, albeit today's implementations as a rule
> are very poorly-conceived.
>
> We would all receive vastly-improved installation security if every software
> vendor would adopt a standard for code/data/installer authentication (that
> does not require digital signatures but that could optionally use them)
> based on a keyed hash algorithm and a low-cost specialized electronic device
> that sits on the desktop or in the server room alongside the box to which
> software is deployed and is used to verify hashes and explain forensically
> what the installer intends to do to configure the box and deploy the code
> and data to it.
>
> Of course that's just the ideal improvement, which I personally believe the
> industry could even train end-users to understand and use.
> Particularly if the proposed device were to generate an installation key
> that the user would be required to enter in order to install the software.
> (Sure, greedy people would try to use this to increase license revenue or
> improve controls over intellectual property and copyright; they will just
> have to be fought back by those who understand that the point is security
> not personal enrichment.)
>
> Short of the ideal stand-alone embedded system this concept could also be
> built as software-only. Does anyone care? Will anyone ever build it?
>
> Regards,
>
> Jason Coombs
> jasonc@science.org
>
>

- --
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.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC3XufhDd4aOud5P8RAnY/AJ4lefhFbWbk/lQL7i95BhqwqHm2+wCfXVII
mWrFatz9c4ESScrwfnPLErw=
=7the
-----END PGP SIGNATURE-----

[Burton Strauss]

At best the SCOTUS Grokster opinion bounces the case back to the lower
courts saying "You erred in dismissing under Betamax".

It's also pretty clear that the Supremes said "Oh, and from looking at the
facts of this case in that light, MGM will probably win".

So it's now clear that a non-infringing purpose isn't an absolute shield for
a technological device. You also have to have clean hands regarding the
usage of it.


"Thus, if you are a developer and you deploy software without giving serious
thought to the things that you could do to make the entire process of
software distribution and installation safer for everyone, then you are part
of the problem." is a HUGE stretch.

The mere fact that somebody COULD put a nasty script into SOME package? No
way... Now if you sold/gave away your Wonka-Magic-Software-Installer saying
"Oh, and BTW, Wink, Wink, if you were to add this script to your package,
you will install 27 Trojan and SpyWare apps and we'll pay you $2/copy
distributed". Well, then, you don't have clean hands...


I guess that puts me in the camp that thinks Grokster isn't a bad decision.

It might become one - after a couple more cycles through the courts make the
new rules clear.

But on it's face? No... In fact, I'd love to see the same kind of rules
applied to a couple of other industries/technologies - Guns for example (how
many Deer do you find running around the woods wearing Kevlar?). Tobacco,
Pharma and 'Nutritional' Supplements for others...


OK, back to relevant stuff...

How do we hit the middle ground - enough control over what is done so that
there is:

* At least a record of what was done.
* Some attempt at obtaining informed consent.

And, Can we do this within (or just beyond) current packaging methods?


-----Burton



-----Original Message-----
From: Jason Coombs [mailto:jasonc@science.org]
Sent: Tuesday, July 19, 2005 12:16 PM
To: Tim Nelson
Cc: John Richard Moser; Klaus Schwenk; bugtraq@securityfocus.com
Subject: Re: Installation of software, and security. . .

Tim Nelson wrote:
> On Sun, 17 Jul 2005, John Richard Moser wrote:
>> 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"?
>
> I think you're both right :). I agree that packages need to be
> able to do anything, but it'd be nice if we could try to eliminate the
> pre and post install scripts.

Developers think that installers need to be able to do anything because the
developers think of themselves as being trustworthy. The code written for an
installer doesn't do anything harmful and it can be trusted, so why should
it not have the ability to do anything that the developer decides it needs
to do?

All malicious attacks originate from the hands and minds of other people,
malicious people, therefore a typical developer cannot see any harm in their
own way of thinking or in their own installer. Even those developers who
perceive an unacceptable risk or intrinsic flaw in the way that these things
get built and deployed have a very hard time seeing themselves as
responsible for the harm caused by others.

The truth is that people who expressly allow systems that are harmful to
continue to exist can be held responsible for the damage that those systems
cause, regardless of the fact that the malicious actor who initiates the
specific harm in each instance is somebody else entirely.

See: Metro-Goldwyn-Mayer Studios Inc. v. Grokster, Ltd.
http://www.supremecourtus.gov/opinions/04pdf/04-480.pdf

Thus, if you are a developer and you deploy software without giving serious
thought to the things that you could do to make the entire process of
software distribution and installation safer for everyone, then you are part
of the problem.

Hopefully everyone can now see that applying digital signatures to code is a
pointless exercise in somebody else's arbitrary business strategy (i.e.
VeriSign and other purveyors of so-called 'federated identity
solutions') and is not being used today as a means of achieving improved
information security. A very sad state of affairs, given that signed code at
least attempts to address these issues of security during the software
installation/distribution process, albeit today's implementations as a rule
are very poorly-conceived.

We would all receive vastly-improved installation security if every software
vendor would adopt a standard for code/data/installer authentication (that
does not require digital signatures but that could optionally use them)
based on a keyed hash algorithm and a low-cost specialized electronic device
that sits on the desktop or in the server room alongside the box to which
software is deployed and is used to verify hashes and explain forensically
what the installer intends to do to configure the box and deploy the code
and data to it.

Of course that's just the ideal improvement, which I personally believe the
industry could even train end-users to understand and use.
Particularly if the proposed device were to generate an installation key
that the user would be required to enter in order to install the software.
(Sure, greedy people would try to use this to increase license revenue or
improve controls over intellectual property and copyright; they will just
have to be fought back by those who understand that the point is security
not personal enrichment.)

Short of the ideal stand-alone embedded system this concept could also be
built as software-only. Does anyone care? Will anyone ever build it?

Regards,

Jason Coombs
jasonc@science.org

Trojans embedded in installation scripts have been a problem in commercial
space for many years, despite risk of exposure. I can recall a DBMS that
installed its basic relational engine to run at elevated priority relative
to everything else on the box, apparently in order to make itself look bett=
er,=20
particularly in side by side tests with competitors. I can recall also vari=
ous
instances of commercial products adding backdoor accounts "for maintenance"=
without
so much as a by-your-leave, and more. The more obscure the installation scr=
ipt,
the greater the temptation to some outfits to put in functionality for thei=
r own
convenience or advantage. Of course, with spyware now not blushing to add k=
eystroke
monitors and backdoors, simple jiggering with priorities sounds very tame i=
ndeed.

The platform features to find out about this are still that there need to b=
e ways
to get install scripts to report what they would do, in detail, rather than
actually altering anything on the box, and to unhide operations that otherw=
ise
might be kept quiet. Ideally this should be possible at any time to the box=
owner,
regardless of the wishes of the installer, and there ought to be a further =
option
to create a detailed log. The other necessary thing to get rid of such beha=
vior by
anyone is that disclosure of what is going on should be protected from legal
challenge (so long as it is truthful) and should be paid attention to by th=
e buying
public.

It is simply not true that commercial vendors are always clean here; even v=
ery=20
large ones have sometimes strayed into underhanded behavior for many years.
That almost nobody tries to (or even can) examine install operations before
turning them loose just makes matters worse.

Glenn Everhart


-----Original Message-----
From: Jason Coombs [mailto:jasonc@science.org]
Sent: Tuesday, July 19, 2005 1:16 PM
To: Tim Nelson
Cc: John Richard Moser; Klaus Schwenk; bugtraq@securityfocus.com
Subject: Re: Installation of software, and security. . .


Tim Nelson wrote:
> On Sun, 17 Jul 2005, John Richard Moser wrote:
>> 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"?
>=20
> I think you're both right :). I agree that packages need to be able=
> to do anything, but it'd be nice if we could try to eliminate the pre=20
> and post install scripts.

Developers think that installers need to be able to do anything because=20
the developers think of themselves as being trustworthy. The code=20
written for an installer doesn't do anything harmful and it can be=20
trusted, so why should it not have the ability to do anything that the=20
developer decides it needs to do?

All malicious attacks originate from the hands and minds of other=20
people, malicious people, therefore a typical developer cannot see any=20
harm in their own way of thinking or in their own installer. Even those=20
developers who perceive an unacceptable risk or intrinsic flaw in the=20
way that these things get built and deployed have a very hard time=20
seeing themselves as responsible for the harm caused by others.

The truth is that people who expressly allow systems that are harmful to=20
continue to exist can be held responsible for the damage that those=20
systems cause, regardless of the fact that the malicious actor who=20
initiates the specific harm in each instance is somebody else entirely.

See: Metro-Goldwyn-Mayer Studios Inc. v. Grokster, Ltd.
http://www.supremecourtus.gov/opinions/04pdf/04-480.pdf

Thus, if you are a developer and you deploy software without giving=20
serious thought to the things that you could do to make the entire=20
process of software distribution and installation safer for everyone,=20
then you are part of the problem.

Hopefully everyone can now see that applying digital signatures to code=20
is a pointless exercise in somebody else's arbitrary business strategy=20
(i.e. VeriSign and other purveyors of so-called 'federated identity=20
solutions') and is not being used today as a means of achieving improved=20
information security. A very sad state of affairs, given that signed=20
code at least attempts to address these issues of security during the=20
software installation/distribution process, albeit today's=20
implementations as a rule are very poorly-conceived.

We would all receive vastly-improved installation security if every=20
software vendor would adopt a standard for code/data/installer=20
authentication (that does not require digital signatures but that could=20
optionally use them) based on a keyed hash algorithm and a low-cost=20
specialized electronic device that sits on the desktop or in the server=20
room alongside the box to which software is deployed and is used to=20
verify hashes and explain forensically what the installer intends to do=20
to configure the box and deploy the code and data to it.

Of course that's just the ideal improvement, which I personally believe=20
the industry could even train end-users to understand and use.=20
Particularly if the proposed device were to generate an installation key=20
that the user would be required to enter in order to install the=20
software. (Sure, greedy people would try to use this to increase license=20
revenue or improve controls over intellectual property and copyright;=20
they will just have to be fought back by those who understand that the=20
point is security not personal enrichment.)

Short of the ideal stand-alone embedded system this concept could also=20
be built as software-only. Does anyone care? Will anyone ever build it?

Regards,

Jason Coombs
jasonc@science.org


************************************************** ********************
This transmission may contain information that is privileged, confidential =
and/or exempt from disclosure under applicable law. If you are not the inte=
nded recipient, you are hereby notified that any disclosure, copying, distr=
ibution, or use of the information contained herein (including any reliance=
thereon) is STRICTLY PROHIBITED. If you received this transmission in erro=
r, please immediately contact the sender and destroy the material in its en=
tirety, whether in electronic or hard copy format. Thank you
************************************************** ********************

[Peter Keel]

Well, since you can't be sure what a package will do, the user/admin
should at least have the possibility to examine the contents of a
package, manually or with virus-scanners or whatever without actually
running any script or some unpack-in-place routine provided by the
package itself.

So far, some Installers fail this miserably:

NullSoft Installer
http://nsis.sourceforge.net/
The packager has complete control over any switches given to the
package, and most choose not to provide an "unpack only" switch.
There is no official way to unpack these packages, 7zip and the
likes fail.

Loki Installer
http://www.lokigames.com/development/setup.php3
It seems you can give the parameter --noexec, which will probably
not execute any scripts. Changing this in the prepended script would
probably lead to a wrong md5-sum; but a specially prepared loki-setup
would produce packets which could ignore that. So chances are slim
somebody could change an already existing package, but the packager
himself can do as he sees fit. And then, unpacking such a package
by hand is not very feasible.

For some others are third-party tools available, like
http://innounp.sourceforge.net/ which you can use to examine packages by
hand or plug in into your antivirus.

I consider it mandatory that packages allow being unpacked in place, by
a tool that is not part of the package itself. Its the least thing you
can do.

Regards
Peter
--
Operator in charge of Security Tel +41 1 287 2993
Cyberlink Internet Services AG Fax +41 1 287 2991
Richard Wagnerstrasse 6 admin@cyberlink.ch
CH-8002 Zuerich http://www.cyberlink.ch

[joop gerritse]

On Sunday 17 July 2005 21:52, 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 its actions nor is it observed by some system service. As

Occasionally, I have been using INCTRL5 to check at least the most obvuious=
=20
items for change before and after installation.

=2D-=20
Joop Gerritse
M=C3=BChlenstra=C3=9Fe 11
D-47546 Kalkar-Wissel
Germany
+49 2824 971487
http://www.jjge.nl