RE: Installation of software, and security. . .
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@xxxxxxxxxxx]
Sent: Sunday, July 17, 2005 3:09 PM
To: Klaus Schwenk
Cc: bugtraq@xxxxxxxxxxxxxxxxx
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 />