--- Begin Message ---
On Fri, May 05, 2000 at 10:42:46AM -0400, jeff covey wrote:
> We're interested in presenting an editorial on freshmeat about
> security issues related to package management systems, and were hoping
> you would have the time to answer a few questions. If you don't have
> time or if there's someone who would be better able to answer, please
> let me know.
>
Um, this was forwarded to me as the rpm maintainer, but I'm not exactly sure
how to provide what you wish.
> ------------------------------------------------------------------------------
> The popularity of apt and rpm has led to a large number of users
> relying on automatic upgrades through their package management
> systems. Old timers who insist on compiling everything from source
> can be understandably concerned about the process of downloading a
> binary and installing it with minimal admin intervention. The
> convenience is bought at the price of trust in the system. How would
> you answer the following questions? Do you agree or disagree that the
> concerns they express are valid? If they are valid and are not
> currently addressed, do you have any ideas about how the problems
> could be fixed?
>
> * What facilities does your package manager (or a third party add-on,
> such as autorpm) provide for automatic upgrading of installed
> packages?
rpm (and all package managers based on rpmlib) depend on ordering
based on epoch:version-release comparison in order to identify the "newer"
of two instances of a package with the same name.
> * Who controls the package archives from which new packages are
> downloaded? If it's possible for third party archives to be used,
> does your package manager warn the user that packages are being
> downloaded from somewhere other than the official source?
Um, not applicable, as Red Hat packages are often the "official source".
> * Does your package manager support digital signatures that can
> confirm that the package is from the packager it claims to be from
> and has not been tampered with?
rpm supports header/payload signatures using md5 as well as all algorithms
implemented in either pgp/pgp5/gpg (e.g. RSA, DSS, Diffie-Hellman, ...)
> * Are there procedures in place to check for trojans/virii/etc. in the
> original source package?
Checking for trojans/virii in sources is outside rpm's abilities and is
solely the responsibility of the packager.
> * Are there procedures in place to check for trojans/virii/etc. in the
> package itself (for example, in the scripts used to install the
> package)?
Signed rpm packages cannot be altered without being able to detect the
alteration. The scripts are part of the header, which is signed, and so
cannot be altered without being able to detect the change.
> * If someone were to sneak a trojan into a package, it could spread to
> thousands of machines overnight as admins performed automated
> upgrades on their systems. If this were to happen, would it be
> possible for you to prepare a package that would fix the problem on
> the next dist-upgrade (not everyone reads security bulletins, so not
> everyone will be aware that she's been compromised)?
Um, yes, as Red Hat releases security errata as quickly as possible, and
these updates are copied to mirror sites and up2date servers as part
of the process of releasing an errata.
> * The answer to the previous question is naturally somewhat dependent
> on the nature of the trojan. As a worst case scenario: Is it
> possible for someone to insert a trojan into your upgrade stream
> which would disable your package upgrade system on the client side,
> making it impossible for you to distribute a fix through the normal
> method?
Signed rpm packages cannot be used as a vector for trojan horses
(assuming the installer checks the signature).
> * If the answer to the previous question is "yes", do you think it
> would be beneficial to establish a class of protected packages which
> can only be upgraded with packages that come signed by you?
Implementing better install policies based on explicitly verifying
signatures is in everyone's interest.
> ------------------------------------------------------------------------------
>
> That's a start, anyway; we may have more questions for you later as we
> ponder your replies. :)
>
> Thanks for your time!
Hope it helps
73 de Jeff
--
Jeff Johnson ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC
--- End Message ---