Slashdot Mirror


Kurt Seifried On The Danger Of Binary RPMs

Curious__George writes "Kurt Seifried on SecurityPortal (4-11-01) writes on a topic that deserves wider notice in the Linux world: The potential dangers of installing BINARY RPMs (as opposed to SOURCE RPMs). Here is the article in standard and printer-friendly versions." (Read more below.)

"He begins: 'I'm always amazed at the lack of articles on topics like RPM and PAM. These are basic systems components and tools that people use every day but which, generally speaking, are poorly understood (if at all). Prepare to be educated.. . . Generally speaking, RPM's must be installed as root, which means that RPMs can do anything on your system: install new files, overwrite files, reconfigure system settings, add new users, etc.

Why is this important? Because many people download RPMs from semi-trusted or untrusted sources and blindly install them.'

Curious George points out: "The potential for danger (with many newbies and not-so-newbies making use of binary RPMs from untrusted sources) is that Linux could develop an unwarranted reputation for problems by someone (or perhaps some Corporation?) purposely diseminating RPMs with built in vulnerablilities or exploits. We should do our part to educate and spread the word on this issue."

3 of 177 comments (clear)

  1. Er, sure, yah, okay. by FFFish · · Score: 5

    And these self-same newbies are going to be able to download source, *inspect the code for trojans*, and compile?

    Security is as security does. Downloading a binary from an untrusted source isn't a whole lot more risky than downloading an indecipherable source code to compile.

    Unless you're some sort of Code Hero, you just gotta trust that people aren't out to screw ya. I'll take the convienence of binaries over the P.I.T.A. of source, any day...

    --

    --

    --
    Don't like it? Respond with words, not karma.
  2. Source vs. Binary by psocccer · · Score: 5

    I personally use source tarballs all the time, since slackware's "package" management is just tarballs with an installer bootstrap. Do I feel any less succeptable?

    NO

    Why? I'm using the source right? Well, it's not like every time I download a new program I inspect every line of code. That would be rediculous. I don't know how everyone else is, but if there is a configure script, hell, I won't even read the INSTALL file. If I can get it working the first time, I won't even read the README. I've been through enough 'configure ; make ; make install' cycles that I try what looks right first and ask questions later. And I'd bet most others do to. Which makes us all just as vulnerable to attack as the 'binary downloading newbies'.

  3. Inadequate security model by Animats · · Score: 4
    The real problem is installing as root. The security model for most existing OSs, Linux included, is so weak that there's no real way to handle installs securely. But it could be done:

    • NSA Linux mandatory security controls should be used.
    • Files, processes, etc have an associated "integrity level" and "integrity compartment". Data cannot flow into an integrity compartment or upwards in integrity level except through the assistance of a trusted "upgrader/downgrader" program, which is seldom used and requires very explicit user invocation.
    • Integrity levels might be KERNEL_INSTALL, KERNEL_CONFIG, TRUSTED, REGISTERED, UNTRUSTED, HOSTILE. Software running at a given level cannot affect data at a higher level.
    • Each software vendor with a known digital signature gets an "integrity compartment". Installs go into that vendor's integrity compartment. The install program is thus locked out of affecting software from any other vendor. Such installs go in at REGISTERED level.
    • Untrusted software gets a new integrity compartment for each install, and goes in at UNTRUSTED level. Games and web content work this way.

    Basically, this doesn't let application A mess with application B's stuff. It enforces a rigid model on package structure, which may not be a bad thing. It forces vendors to clearly identify apps which need to mess with other apps, because they'll need extra privileges, which users might not want to give them.