[gentoo-hardened] ebuild signing, Harden What?, Use Scenario

[Gavin Vess]

ebuild signing
===========
How could a user safely evaluate risk, without ebuild "certification" (e.g. used by others that verified ebuild signature prior to installing)?  If a risk assessment ranking system existed, then unsigned ebuilds/level/frameworks/packages/etc. could be classified as high risk.  Would this encourage Gentoo users to pressure package developers and offload this task to the Gentoo community?

Harden What?
========================
Aaron wrote:
> We need multiple levels here.  The base kern / os, the framework that apps are run in, and finally the apps themselves.

Independent of whether or not multiple hardened versions/configurations will exist, won't we need dependency tracking between the key hardened components (kern, kern config, frameworks, policies, apps)?  For example, a hardened app available through "emerge --patch security_risks" might require a hardened framework below it (e.g. rely on features of a hardened kern, or the application of rules in the firewall that potentially affect other hardened apps).  Stop me if I'm getting lost in detail ;)

Use Scenario
===========
1) Average user checks the Gentoo Risk Assessment Rating for app Foo and learns that Foo is rated "Very Unsafe" unless hardened.
2) User reads about tradeoffs in using hardened Foo instead of soft Foo (unhardened and unhindered by security measures).
3) Uses chooses hardened Foo.
4) User knows little (nothing?) about hardened frameworks / kern layers.
5) Before user can proceed, user needs to be informed about requirements/impact of upgrading/downgrading/changing to hardened Foo, including what changes are necessary in kern & framework (e.g. some base firewall package/policy).
6) User upgrades kern [config], base framework(s) and policies, as needed.
7) User emerges hardened Foo.

Cheers,
Gavin
http://www.vess.com/