| 1 |
On Wed, Nov 18, 2009 at 2:41 PM, Marcel Meyer <meyerm@××××××.de> wrote: |
| 2 |
> I mean I can not prevent this potential corrupted kernel from starting and |
| 3 |
> then accessing my /boot partition. But as long as the "attacker" did not |
| 4 |
> invest so much work to keep this kernel alive "behind" a kexec call or |
| 5 |
> starting some virtual machine etc. pp., the newly started kernel should take |
| 6 |
> full control - and if something different (like another kernel from the USB- |
| 7 |
> stick) is started, I will recognize that and don't enter the password for the |
| 8 |
> data. |
| 9 |
> |
| 10 |
> So my main question here is: does it make sense to replace the first kernel by |
| 11 |
> a trusted second one or is it too easy to hide behind such functionality? |
| 12 |
|
| 13 |
If I understand correctly, your goal is simply to ensure that the |
| 14 |
kernel on the USB drive doesn't get tampered with? In that case, |
| 15 |
perhaps a solution would be to keep hashes of it on that same drive, |
| 16 |
and sign those with, say, a key on a smart card. (The FSFE offers one |
| 17 |
along with instructions. [1]) You could verify everything at boot |
| 18 |
time, and if there were discrepancies, custom boot scripts (kept |
| 19 |
alongside the kernel, also hashed and signed) could prevent the |
| 20 |
machine from booting, or something along those lines... |
| 21 |
|
| 22 |
[1] http://fellowship.fsfe.org/card.en.html |
| 23 |
|
| 24 |
-- |
| 25 |
Mansour Moufid |
Archives