Bug 7162 - Feature suggestion: better trust model.
Summary: Feature suggestion: better trust model.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 6.1
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-11-19 23:51 UTC by Aleksey Nogin
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-11-22 19:23:16 UTC


Attachments (Terms of Use)

Description Aleksey Nogin 1999-11-19 23:51:37 UTC
Current versions of rpm provide some help in determining whether I trust
some package enough to go ahead and install it, but people often still have
to do some work by hands.

Basically, rpm provides a way to query the package for all the information
I may want (including GPG/PGP signatures), but it does not provide any
mechanisms to help me put all that information together.

Here is what I would like to see:

(1) A way to quickly know how dangerous installing this package may be. The
levels of danger would be something like:
   (a) May run programs as root (which should be reported if package
installs any files into /etc/cron.*/ hierarchy, installs files containing
scripts into /etc/logrotate.d directory, has some nontrivial
[post][un]install scripts, etc)
   (b) May allow local users to run programs as root (if package installs
setuid programs).
   (c) Should be harmless (if neither a, nor b)

(2) Allow to associate signatures with some level of trust (e.g. I do not
mind installing dangerous packages if they are signed by RedHat and I do
not mind installing "harmless" packages if they are signed by any valid
key).

Comment 1 Chris Siebenmann 1999-11-20 10:22:59 UTC
I've done some small work on safety-auditing RPM packages, but it's
hard. If you assume a malicious RPM author, most if not all of the
bets are off (eg, consider an RPM that plunks a trojan version of
a commonly used-in-scripts binary down in a spot earlier on root's
default $PATH than the real one). Even if you just want to avoid
surprises, it's very system and even release-dependant, and thus
probably best left to an add-on program that uses information from
rpm to work all this out. (Possibly one could make it driven by
a configuration file that could be tuned on each system.)

Comment 2 Trond Eivind Glomsrxd 2002-01-18 17:36:48 UTC
When you're installing programs outside a VM, you can do pretty much everything.
GPG lets you check if you trust the packager, and that's about all you can do.
(you can of course look at scripts and choose not to run them, but that won't
help much). Solution: Don't install packages from untrusted sources unless
heavily scrutinized.


Note You need to log in before you can comment on or make changes to this bug.