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.
