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 S'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 PV.

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?

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 PV.
>>
>
Yes, you hit the nail on the head with a jackhammer. 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.

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 (or something) to enable running scripts, and
to enable potentially troublesome actions (eg.
reload), or to just install files and not do the
actions.

?

:)

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.

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

Matt Beaumont wrote:

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,

This whole discussion is entirely pointless.

modern systems, installing software is *by definition* highly
dangerous, no matter what. If you let someone drop files in places of
their choosing (or even with a few restrictions), you've basically
agreed to give up control of your machine.

Consider how many packages need to install startup scripts or cron jobs.
And consider how those could be used to compromise a system.

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

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