0

Is there a mechanism built into rpm or apt that will warn (or prevent) a user from installing a package contains a known security threat?

I'm thinking of an RPM like openssl-1.0.1e-15.el6.x86_64.rpm. Seems odd that it can float out there forever waiting for someone to use it, probably following outdated installation instructions for some offbeat secure software.

Brian
  • 241
  • 1
  • 6
  • 1
    You speak as if `openssl-1.0.1e-15.el6` was a known security problem forever. In reality, it wasn't known (except for a very small number of people, like the people who discovered it, the engineers who fixed it; and perhaps other organizations who have the money and resources to analyze openssl at a fine detail) until a few days ago. Once a threat is "known", in the public sense, yes there are tools to help the sysadmin. `portaudit` on FreeBSD, `yum-security` on RHEL, etc. – Stefan Lasiewski Apr 10 '14 at 03:43

1 Answers1

1

Is there a mechanism built into rpm or apt that will warn (or prevent) a user from installing a package contains a known security threat?

No.

Knowing this kind of thing is part of the job of being a professional systems administrator. I don't expect (or want) my tools to spoon-feed me. Nor do I want them to prevent me from doing something destructive if I so desire. You know that quote about power and responsibility? It applies here as well.

EEAA
  • 109,363
  • 18
  • 175
  • 245
  • Seriously? Why use a package manager at all then? Just maintain the dependencies in your head. – Brian Apr 10 '14 at 04:12
  • Plus, shunning a security tool seems reckless. I wouldn't hire a "professional system administrator" who did so. – Brian Apr 10 '14 at 04:24
  • @UCSDTriton I'm not shunning a tool - I'm stating that package management is not the right place for this. If you want to use separate tools for this, like those mentioned by Stefan, that's great. But package management tools should not be responsible for this. Determining whether or not a package is vulnerable in **your specific configuration** is a very complex task, and is something that could not feasibly be implemented in such a way as to provide a useful signal-to-noise ratio. – EEAA Apr 10 '14 at 04:34