--- Begin Message ---
(Note: Please forward where appropriate as I have no idea how I ended
up in this discussion, nor who is involved, I'm just trying to respond to
an e-mail message forwarded by Donnie Barnes).
On Tue, May 09, 2000 at 10:11:59PM -0400, jeff covey wrote:
> on Sat, May 06, 2000 at 03:56:27PM -0400%, Jeff Johnson said:
>
> JeffC> What facilities does your package manager (or a third party
> JeffC> add-on, such as autorpm) provide for automatic upgrading of
> JeffC> installed packages?
>
> JeffJ> rpm (and all package managers based on rpmlib) depend on
> JeffJ> ordering based on epoch:version-release comparison in order
> JeffJ> to identify the "newer" of two instances of a package with
> JeffJ> the same name.
>
> What I meant was: Does Red Hat provide the ability for a user to issue
> a command that says, "Go get any new versions of the software I have
> installed, and install them for me" as Debian does with APT, or can
> this only be done with third-party tools such as autorpm?
>
RPM has some rudimentary support for FTP and HTTP transfers, but does not
but does not try to download anything other than what was requested.
Neither does dpkg, which is a closer analogue to rpm than APT.
Closer to APT in functionality, is the Red Hat up2date package, which
does dependency resolution using HTTP POST's, and is able to augment
an update request with other packages that will be needed to complete
an upgrade.
> JeffC> Who controls the package archives from which new packages
> JeffC> are downloaded? If it's possible for third party archives
> JeffC> to be used, does your package manager warn the user that
> JeffC> packages are being downloaded from somewhere other than the
> JeffC> official source?
>
> JeffJ> Um, not applicable, as Red Hat packages are often the
> JeffJ> "official source".
>
> Red Hat only provides a limited subset of the software available in
> the RPM format. On http://www.rpmfind.net/linux/RPM/ , users will
> find all of these archives in addition to Red Hat versions and updates:
>
Um, almost all, if not all, binary software distributed by Red Hat (I do not
speak about Cygnus, yet) is in rpm package format with signatures. Perhaps
by "Red Hat" you mean "Red Hat Distribution"? Or do you mean that
ftp.redhat.com has not just Red Hat software?
> PowerTools
> Perl CPAN
> RedHat Contrib Net
> Gnome Desktop Environment
> Libc6 Contribs
> Libc5 RedHat Contribs
> Arch Independent RedHat Contribs
> No Sources RedHat Contribs
> RawHide
> Conectiva Linux
> HelixCode Gnome distribs
> Mandrake
> Mandrake Cooker
> XBF X-Windows servers
> SuSE
> Linux/PPC
> Yellow Dog PPC
> OpenLinux
> Caldera Contribs
> TurboLinux
> Archives for blind users
> DLD
> UltraPenguin
> SGIlinux
> LinuxM68k
> Freshmeat
> Coda
> Beowulf
> RPM.Org
> Stuff on Rufus.W3.Org
> Solaris packages on Real-Time.Com
> RPMs for Cygwin32/Windows
>
> and many of these have multiple subdivisions.
>
> The question I was asking was: Since you obviously can't verify the
> thousands of RPM files packaged by all of these distributions and
> individuals, does rpm provide a warning like "This package has not
> been prepared by Red Hat. While it's probably fine, we cannot confirm
> that it will work with your system. Continue installation? [Y/n]"?
>
The goal of rpm (and tools that use rpmlib, including the Red Hat installer),
by design, is to not prevent unattended installs and automatic updates by
blocking on user interaction. Please note that in the example above there
is little information ("Not packaged by Red Hat") that is helpful in or
pertinent to answering the question "Continue installation? [Y/n]".
Therefor rpm (and the Red Hat installer) do not ask these questions during
package install.
This doesn't mean that better policy (e.g. "Install only packages from Red Hat")
tools aren't needed or useful, just that rpm (and the Red Hat installer) is
not where the implementation should be.
Again, the Red Hat up2date agent currently implements certain install policies
(but not the example above) like "Don't permit /bin/sh" to be replaced, or
"Don't upgrade the kernel package".
> JeffC> Are there procedures in place to check for
> JeffC> trojans/virii/etc. in the package itself (for example, in
> JeffC> the scripts used to install the package)?
>
> JeffJ> Signed rpm packages cannot be altered without being able to
> JeffJ> detect the alteration. The scripts are part of the header,
> JeffJ> which is signed, and so cannot be altered without being
> JeffJ> able to detect the change.
>
> I'm not asking about them being altered after the fact; I'm just
> confirming that a procedure is in place to double-check the official
> signed packages to confirm that, for example, a disgruntled employee
> on his last day of work doesn't add "/bin/rm -rf /" to the preinstall
> script of the binutils package and place it in the errata FTP space.
>
Part of Red Hat QA involves repeated installs of packages before and after
signing that would easily detect the example you have given. Red Hat also
does not release unsigned packages as errata, and there is sufficient
process in place that no single employee, disgruntled or otherwise, is able
to put an errata on the FTP site.
There are, of course, time bombs, viruses, and many other forms of damage
more sophisticated than your example, and more generally, Red Hat, like
many distributions, relies on the scrutiny of the community at large to
detect and correct problems promptly. Enhancing the ability of the community
to detect and correct problems before damage becomes widespread
is the single best approach to insuring the safety (and quality) of
packages that I can think of.
> [Debian folks: This is even more of a question for you, since you're
> accepting packages from people from all over, who may only have their
> reputations, not their jobs and the threat of prosecution, hanging
> over them and keeping them in line.]
>
> JeffC> The answer to the previous question is naturally somewhat
> JeffC> dependent on the nature of the trojan. As a worst case
> JeffC> scenario: Is it possible for someone to insert a trojan
> JeffC> into your upgrade stream which would disable your package
> JeffC> upgrade system on the client side, making it impossible for
> JeffC> you to distribute a fix through the normal method?
>
> JeffJ> Signed rpm packages cannot be used as a vector for trojan
> JeffJ> horses (assuming the installer checks the signature).
>
> Let's say Joe Packager uploads a new package of sendmail to a contrib
> directory. Jane User runs her automatic update script. It sees that
> she has sendmail installed, spots Joe's package, and offers to install
> it for her. Jane checks the signature. Yes, it's from Joe and has
> not been tampered with, so she installs it.
>
> A couple of days later, someone notices that sendmail has been altered
> in this package to silently send copies of all mail to Joe and all his
> friends. You put out warnings about it and distribute a package with
> a version number higher than Joe's, so those people (like Jane) who
> don't bother to read security lists will at least get the fix when
> they run their update scripts.
>
> Unfortunately, Joe's package also did something else: It replaced
> /bin/rpm with a version that will not install any version of sendmail
> or RPM other than Joe's. It will pretend to install your replacement,
> but won't actually do it, so Jane will never know that her system's
> been compromised.
>
> You might say this really isn't your problem, because if people want
> to be safe, they shouldn't install any packages that don't come from
> you, but it isn't reasonable to expect that, since there's a lot of
> software people want that Red Hat doesn't package (otherwise,
> Mandrake, etc. wouldn't exist). People *are* going to be getting
> their RPMs from other places.
>
Um, I question whether the example above illustrates anything but
"Joe is a dangerous moron"
"Jane is too trusting"
"Thank God someone noticed"
"People are going to do whatever they want"
so a specifically informed reply is difficult.
> Would you consider either of these valid solutions to the problem?:
>
> 1. Informing users when they're about to install a package that didn't
> come from you.
Presenting repeated yes/no questions to users usually leads to
simple carriage return answers to accept the default. That isn't
exactly "informing users" in anything other than a (possible) legal sense.
Not valid.
> 2. Making certain core files untouchable by non-Red Hat packages, or
> at least providing much stronger warnings like "WARNING! This
> package, which is not an official Red Hat packages, wishes to
> overwrite /bin/sh, which is a protected Red Hat file. This could
> have dangerous consequences. Proceed at your own risk, and run rpm
> again with --force if you really want to install this package."
>
Attempting to make files unremovable makes the package manager (rather than
the end user) apparently responsible for the end user's safety, and,
like shouting "WOLF! ..." too often or mistakenly, lulls the end user
into a false sense of security. Adding "Proceed at your own risk" would keep
the lawyers happy I'm sure, but would do little to protect the end user.
Insturmenting overrides like "--force" is necessary for many reasons,
but the functionality is more often abused than used correctly.
Not valid.
> Do you have any other ideas about what could be done?
>
Yes, but judging from the types of examples and questions you are asking,
I don't believe that this is the correct forum to present other ideas.
73 de Jeff
--
Jeff Johnson ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC
--- End Message ---