Publishing what started as an review request -<br><br><div class="gmail_quote"><span style="font-size: large; font-weight: bold;">Forwarded conversation</span><br>Subject: <b class="gmail_sendername">New branch on bios-crypto: delegation</b><br>
------------------------<br><br><span class="undefined"><font color="#000000">From: <b class="undefined">Martin Langhoff</b> <span dir="ltr"><<a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a>></span><br>
Date: Thu, May 7, 2009 at 6:43 PM<br>To: "Reuben K. Caron" <<a href="mailto:reuben@laptop.org">reuben@laptop.org</a>>, Daniel Drake <<a href="mailto:dsd@laptop.org">dsd@laptop.org</a>>, "C. Scott Ananian" <<a href="mailto:cscott@laptop.org">cscott@laptop.org</a>><br>
</font><br></span><br>Hi guys,<br>
<br>
Early heads up -- I am working on the tools included in bios-crypto to<br>
prepare them to produce 'sig02' delegated signatures and specially<br>
delegated leases.<br>
<br>
The work I am doing is following the spec on the wiki and the examples<br>
in the bitfrost code. You might want to give brief review at<br>
<a href="http://dev.laptop.org/git/bios-crypto/commit/?h=delegation" target="_blank">http://dev.laptop.org/git/bios-crypto/commit/?h=delegation</a><br>
<br>
- Scott, Daniel - I've patched sig01.c lightly so that it changes its<br>
format slightly for sig02. C is not my native language; I don't think<br>
I did anything particularly stupid, but a review would be welcome.<br>
<br>
- Scott: if you look at make-delegation.sh and the patches to sig01.c<br>
-- does it make sense?<br>
<br>
- Reuben: have a look at the README<br>
<br>
The remaining bit is to rework make-lease.sh to accept and use<br>
delegation signature, like --chained works on make delegation. And<br>
testing this end-to-end.<br>
<br>
cheers,<br>
<br>
<br>
<br>
m<br>
<font color="#888888">--<br>
<a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a><br>
<a href="mailto:martin@laptop.org">martin@laptop.org</a> -- School Server Architect<br>
- ask interesting questions<br>
- don't get distracted with shiny stuff - working code first<br>
- <a href="http://wiki.laptop.org/go/User:Martinlanghoff" target="_blank">http://wiki.laptop.org/go/User:Martinlanghoff</a><br>
</font><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Daniel Drake</b> <span dir="ltr"><<a href="mailto:dsd@laptop.org">dsd@laptop.org</a>></span><br>Date: Thu, May 7, 2009 at 6:55 PM<br>
To: Martin Langhoff <<a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a>><br>Cc: "Reuben K. Caron" <<a href="mailto:reuben@laptop.org">reuben@laptop.org</a>>, "C. Scott Ananian" <<a href="mailto:cscott@laptop.org">cscott@laptop.org</a>><br>
</font><br></span><br>2009/5/7 Martin Langhoff <<a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a>>:<br>
Don't forget that OFW needs to be taught about the new format, and<br>
needs to be extended to correctly verify sig02 leases. Or is that<br>
already being taken care of?<br>
<br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Martin Langhoff</b> <span dir="ltr"><<a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a>></span><br>Date: Thu, May 7, 2009 at 7:03 PM<br>
To: Daniel Drake <<a href="mailto:dsd@laptop.org">dsd@laptop.org</a>><br>Cc: "Reuben K. Caron" <<a href="mailto:reuben@laptop.org">reuben@laptop.org</a>>, "C. Scott Ananian" <<a href="mailto:cscott@laptop.org">cscott@laptop.org</a>><br>
</font><br></span><br>It's not so important in the short term. OFW checks the leases, and<br>
then it executes runos or actos depending on the outcome... but both<br>
are the same thing ATM.<br>
<br>
Once Mitch gets out of his 1.5 work, he'll have a chance to test his<br>
patches for delegation support. As long as runos and actos remain the<br>
same for that period... :-)<br>
<div><div></div></div><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Daniel Drake</b> <span dir="ltr"><<a href="mailto:dsd@laptop.org">dsd@laptop.org</a>></span><br>Date: Thu, May 7, 2009 at 8:50 PM<br>
To: Martin Langhoff <<a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a>><br>Cc: "Reuben K. Caron" <<a href="mailto:reuben@laptop.org">reuben@laptop.org</a>>, "C. Scott Ananian" <<a href="mailto:cscott@laptop.org">cscott@laptop.org</a>><br>
</font><br></span><br>No, it is important. If OFW doesnt trust the lease, it will boot with<br>
the "activate" parameter passed to the kernel, which the OLPC<br>
initramfs will unconditionally interpret as the machine being<br>
unactivated. The consequence being that no systems with act02 leases<br>
will boot.<br>
<font color="#888888"><br>
Daniel<br>
</font><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Martin Langhoff</b> <span dir="ltr"><<a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a>></span><br>
Date: Thu, May 7, 2009 at 9:36 PM<br>To: Daniel Drake <<a href="mailto:dsd@laptop.org">dsd@laptop.org</a>><br>Cc: "Reuben K. Caron" <<a href="mailto:reuben@laptop.org">reuben@laptop.org</a>>, "C. Scott Ananian" <<a href="mailto:cscott@laptop.org">cscott@laptop.org</a>><br>
</font><br></span><br>Good pointer. As things stand, I have to hack inside of the initrd<br>
anyway -- I can make sure that the initrd behaves properly in that<br>
case.<br>
<br>
It sounds like an easy enough fix -- do you think that there are more<br>
reasons to worry?<br>
<div><div></div></div><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Daniel Drake</b> <span dir="ltr"><<a href="mailto:dsd@laptop.org">dsd@laptop.org</a>></span><br>Date: Thu, May 7, 2009 at 9:37 PM<br>
To: Martin Langhoff <<a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a>><br>Cc: "Reuben K. Caron" <<a href="mailto:reuben@laptop.org">reuben@laptop.org</a>>, "C. Scott Ananian" <<a href="mailto:cscott@laptop.org">cscott@laptop.org</a>><br>
</font><br></span><br>Changing the behaviour in this area sounds scary. For testing and<br>
development, maybe OK, but I don't feel that this plan becomes<br>
realistic without firmware support.<br>
<font color="#888888"><br>
Daniel<br>
</font><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Reuben K. Caron</b> <span dir="ltr"><<a href="mailto:reuben@laptop.org">reuben@laptop.org</a>></span><br>Date: Thu, May 7, 2009 at 10:01 PM<br>
To: Daniel Drake <<a href="mailto:dsd@laptop.org">dsd@laptop.org</a>><br>Cc: Martin Langhoff <<a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a>>, "C. Scott Ananian" <<a href="mailto:cscott@laptop.org">cscott@laptop.org</a>><br>
</font><br></span><br>
<div bgcolor="#ffffff" text="#000000">
>From my understanding from
<a href="http://wiki.laptop.org/go/Firmware_Security#Process" target="_blank">http://wiki.laptop.org/go/Firmware_Security#Process</a><br>
<br>
1. OFW check for valid lease.sig<br>
2. No valid lease.sig run actos.zip<br>
3. actos.zip copies lease.sig to /security<br>
4. Continue boot.<br>
<br>
Since OFW will not see a valid lease.sig, will actos have to be run on
every boot? (Increasing boot time?) While not having OFW support is not
ideal, I'm not sure how much room there is in OFW for support. Since
actos.zip and runos.zip are signed by a different key how much does
this actually effect security (making changes to actos and runos) ?<br>
<br>
Apologies if my understanding is grossly in error. <br><font color="#888888">
<br>
Reuben</font><div><div></div></div></div>
<br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Daniel Drake</b> <span dir="ltr"><<a href="mailto:dsd@laptop.org">dsd@laptop.org</a>></span><br>Date: Thu, May 7, 2009 at 10:09 PM<br>
To: <a href="mailto:reuben@laptop.org">reuben@laptop.org</a><br>Cc: Martin Langhoff <<a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a>>, "C. Scott Ananian" <<a href="mailto:cscott@laptop.org">cscott@laptop.org</a>><br>
</font><br></span><br>2009/5/7 Reuben K. Caron <<a href="mailto:reuben@laptop.org">reuben@laptop.org</a>>:<br>
Firstly, note that when booting actos, OFW *additionally* passes an<br>
"activate" parameter to the kernel.<br>
<br>
actos and runos are actually the same file. They could theoretically<br>
be different, and even if so they would be signed with the same key,<br>
but they currently are not.<br>
<br>
So, there's always one initramfs that boots. The initramfs looks for<br>
the presence of the "activate" parameter when deciding what to do:<br>
<br>
1. If the activate parameter is *not* present, it boots the system as<br>
normal. Note that the initramfs does not check the lease even in this<br>
case; it trusts the judgement that OFW made by not passing the<br>
"activate" parameter.<br>
<br>
2. If the activate parameter is present, the initramfs assumes that<br>
there is no lease available on the system (it doesn't bother checking)<br>
and starts hunting on SD, USB and wifi. In the discussions here, there<br>
may well be an act02 lease present on the system which other parts of<br>
the system will trust, but again, lease checking is currently *not*<br>
part of this codepath; the initramfs only listens to what OFW had to<br>
say about the situation.<br>
<br>
IMO changing the semantics here is risky, there is probably a reason<br>
that things are as they are (i.e. firmware-based security), and any<br>
changes would require a careful discussion between all parties...<br>
<font color="#888888"><br>
Daniel<br>
</font><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Martin Langhoff</b> <span dir="ltr"><<a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a>></span><br>
Date: Fri, May 8, 2009 at 9:49 AM<br>To: Daniel Drake <<a href="mailto:dsd@laptop.org">dsd@laptop.org</a>><br>Cc: <a href="mailto:reuben@laptop.org">reuben@laptop.org</a>, "C. Scott Ananian" <<a href="mailto:cscott@laptop.org">cscott@laptop.org</a>><br>
</font><br></span><br>I went to sleep last night wondering about that, so re-read init and<br>
antitheft.py first thing this morning. Your description is correct,<br>
the init process trusts the boot parameter and doesn't recheck things.<br>
<br>
It could very well switch to making the checks itself, and I'll argue<br>
that it is actually a reasonable thing to do, as we're still within<br>
the trusted codebase.<br>
I agree that more discussion will be good.<br>
<br>
However, I suspect that the actual reason is performance. What Mitch<br>
has mentioned serveral times is that as OFW is making the checks, a<br>
smaller, slimmer and faster(!) initrd could be used for the common<br>
case (hence runos.zip being separate).<br>
<br></div><br>-- <br> <a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a><br> <a href="mailto:martin@laptop.org">martin@laptop.org</a> -- School Server Architect<br> - ask interesting questions<br> - don't get distracted with shiny stuff - working code first<br>
- <a href="http://wiki.laptop.org/go/User:Martinlanghoff">http://wiki.laptop.org/go/User:Martinlanghoff</a><br>