1 |
On Fri, Jun 15, 2012 at 8:22 AM, Luca Barbato <lu_zero@g.o> wrote: |
2 |
> If we want to try to get serious on 5, we could try to gather the |
3 |
> hardened/security people across distributions and setup the whole chain |
4 |
> to be parallel and cut deals with OEM to store this trust-chain keys |
5 |
> along with MS. |
6 |
|
7 |
Perhaps. Since we're only talking about the kernel really and that |
8 |
doesn't vary as much across distros, we might even be able to get |
9 |
momentum for it. |
10 |
|
11 |
You could create a standard "secure kernel" - probably as a patch set |
12 |
initially but perhaps merged into mainline with a config option that |
13 |
turns on key verification for loading modules. Anybody could use that |
14 |
to secure their own systems by using their own key in the |
15 |
configuration. The central body could prepare and sign binaries for |
16 |
individual distros. A distro would supply a kernel config file and |
17 |
patch set and identifier for the upstream kernel to build against. |
18 |
The central body would audit the patches and config for security, |
19 |
build the kernel, and sign it, assessing a fee perhaps (likely cheap |
20 |
for config-only, and expensive for extensive patches). The costs need |
21 |
not be all that high - if you assume that vanilla linux with the |
22 |
config option turned on is good enough then you only have to check |
23 |
that the option is set, blacklist "bad" settings, and verify patches. |
24 |
They could revoke certs when security issues are found, by keeping a |
25 |
history of what configs/versions got signed. |
26 |
|
27 |
Users could load the signing key of this body into their custom |
28 |
settings, or OEMs could be persuaded to include it. The latter would |
29 |
never be 100% effective unless a court ordered it. |
30 |
|
31 |
Rich |