| skyline | hi i am new to linux. I am very much interested about it. where should i start | 00:31 |
|---|---|---|
| skyline | ? | 00:31 |
| === Ursinha-afk is now known as Ursinha | ||
| === m_conley_away is now known as m_conley | ||
| bizhanMona | Hi I am trying to understand for ubuntu 12.04 secure boot, what is the relationship between the grub , Intel UEFI and ubuntu framework to support secure boot? Thx | 14:41 |
| desrt | bizhanMona: my understanding is (roughly) that the stage1 bootloader will be signed with the microsoft key | 14:46 |
| desrt | it will verify that the second stage (grub) is signed by a canonical key which will be kept in the launchpad infra | 14:46 |
| desrt | and there will be no kernel signing | 14:46 |
| ogra_ | http://blog.canonical.com/2012/06/22/an-update-on-ubuntu-and-secure-boot/ | 14:47 |
| ogra_ | also see the url from the first comment | 14:47 |
| desrt | ie: you will have to use canonical's grub (which they can rebuild as they see fit) but you will be able to use your own kernels without signature | 14:47 |
| bizhanMona | Thanks so much for the info: I will dive into those urls will be back with more questions :) | 14:48 |
| desrt | uhm | 14:48 |
| desrt | don't read the email linked from that first comment | 14:49 |
| desrt | it's no longer the latest story | 14:49 |
| desrt | it was suspected that the GPLv3 may cause canonical to be forced to give up their signing keys but after a clarification from the FSF this is no longer understood to be the case | 14:49 |
| desrt | so grub _will_ be used (contrary to that email) | 14:49 |
| desrt | here is an updated post clarifying that situation: http://blog.canonical.com/2012/09/20/quetzal-is-taking-flight-update-on-ubuntu-secure-boot-plans/ | 14:50 |
| ogra_ | oh, crap that was the totally wrong url | 14:50 |
| ogra_ | yeah, rather read what desrt posted | 14:51 |
| * ogra_ shouldn't do drive by support on sundays :) | 14:52 | |
| bizhanMona | desrt: you mentioned the grub should be signed by canonical. So the OEM vendors can not use their own key? | 14:53 |
| desrt | the trampoline loader (signed once by microsoft) will contain canonical's key | 14:53 |
| desrt | so it can only load a grub that has been signed by canonical | 14:54 |
| desrt | imho our approach leaves a lot to be desired | 14:55 |
| desrt | the fact that grub will happily hand-off to any kernel is a bit troubling from a security standpoint | 14:55 |
| desrt | it seems like we're pretending that we've added security just for the sake of convincing microsoft to sign our trampoline code | 14:55 |
| desrt | mind you... | 14:56 |
| desrt | if they buy it, i'm totally happy | 14:56 |
| desrt | because it gives the greatest amount of freedom | 14:56 |
| bizhanMona | desrt: So what is missing in chain of trust is authentication of the kernel by grub at this time? | 14:57 |
| desrt | ya... | 14:57 |
| desrt | particularly considering grub hands-off to the kernel without so much as a flash on the screen these days | 14:57 |
| desrt | if i was interested in attacking windows systems i'd grab a copy of canonical's trampoline, a signed copy of our grub and have it autostart my bootkit | 14:58 |
| desrt | i suspect this will happen | 14:58 |
| desrt | and it will be interesting to see microsoft's response | 14:58 |
| bizhanMona | desrt: we were looking for FIPS-142/3 certification secure boot is big part of that, from what you explained this will not happen, Is there any plan how to handle the grub kernel authentication, does anyone working on that? | 15:00 |
| desrt | red hat | 15:01 |
| desrt | they've taken the approach of signing the world | 15:01 |
| desrt | bootloader, kernel, all | 15:01 |
| desrt | and installing their own key in the bios of the machine | 15:01 |
| bizhanMona | Do you have any references to that please? | 15:02 |
| desrt | oh. i tell a lie | 15:03 |
| desrt | they decided not to use that approach | 15:03 |
| desrt | here's the most up to date summary: http://mjg59.dreamwidth.org/12368.html | 15:03 |
| desrt | basically the same as the canonical approach | 15:04 |
| desrt | but they will also modify grub to only load trusted kernels | 15:04 |
| desrt | which makes it actually secure... | 15:04 |
| desrt | an interesing illustration of my point, though: | 15:06 |
| desrt | if i'm on a fedora system | 15:06 |
| desrt | and i want to install a custom kernel... | 15:06 |
| desrt | (without disabling secureboot) | 15:06 |
| desrt | the obvious choice is for me to install ubuntu's grub on my fedora system | 15:07 |
| desrt | because it'll load anything i want | 15:07 |
| desrt | so red hat is no more secure than ubuntu, as long as ubuntu's bootloader exists and is signed by microsoft | 15:07 |
| desrt | which is exactly why i suspect that microsoft may revoke it at some point.... | 15:07 |
| desrt | because the same logic applies equally well to the security of windows machines.... | 15:08 |
| mdeslaur | even if you sign the kernel and kernel modules, you're only secure for a couple of weeks until the next kernel security issue | 15:08 |
| desrt | ya well | 15:08 |
| desrt | what can you do about that? | 15:08 |
| desrt | bugs happen, of course | 15:09 |
| mdeslaur | which means microsoft would have to revoke fedora's key every kernel security update | 15:09 |
| desrt | but why bother exploiting small and quickly-closed kernel privilege escallation issues when you can just exploit the giant gaping hole in the front door | 15:09 |
| desrt | mdeslaur: i think that would be a bit different.... | 15:09 |
| desrt | will they also revoke their own keys every windows update? | 15:10 |
| mdeslaur | why bother investing time and money in getting everything signed, when the first security issue a couple of weeks later results in your key being revoked anyway? | 15:10 |
| desrt | right. it's an interesting point. | 15:10 |
| desrt | it's a spectrum | 15:10 |
| desrt | on one end you have **anything** that lets you gain control over the hardware | 15:11 |
| desrt | and on the other end you have ultra-simple 512-byte-trampoline-rootkit-injector type things | 15:11 |
| mdeslaur | if a fedora kernel with a known security issue can be used as a signed bootloader to circumvent windows secure boot, then microsoft has two choices: 1- they ignore it, 2- they revoke the signing key | 15:11 |
| * desrt thinks that grub is closer to the trampoline than the full OS | 15:11 | |
| desrt | mdeslaur: yes. absolutely. | 15:12 |
| desrt | but how long does it take to get the kernel to the point where you can kexec() untrusted code? | 15:12 |
| desrt | and how much crap flashes on the screen meanwhile? | 15:12 |
| mdeslaur | desrt: that's trivial, and that's not important | 15:12 |
| desrt | you forgot option 3 | 15:12 |
| kklimonda | mdeslaur: wouldn't kernel be signed with a "grub signing key", and when security update is issued Fedora would just have to revoke the certificate for the previous kernel? why does MS have to do that? | 15:13 |
| desrt | microsoft asks fedora to blackball their own kernels | 15:13 |
| desrt | how do you expect microsoft will handle their own kernel security flaws? | 15:13 |
| mdeslaur | kklimonda: because malware authors will just use the grub that contains the key that boots the insecure kernel | 15:13 |
| mdeslaur | desrt: fedora can't blackball their own kernels, it's technically not possible | 15:13 |
| desrt | mdeslaur: it's just as possible as any revocation system | 15:14 |
| desrt | there are shortcomings, of course | 15:14 |
| kklimonda | mdeslaur: why isn't it possible? | 15:14 |
| desrt | but if microsoft can blackball the fedora bootloader then redhat can blackball individual kernels | 15:14 |
| mdeslaur | desrt: no, it's not. malware authors will just use the previous version of grub that contains the key that boots the insecure kernel | 15:14 |
| kklimonda | ah | 15:14 |
| mdeslaur | once it's out there, the only way to prevent it from being used is to have the firmware itself blacklist the signing key | 15:15 |
| desrt | mdeslaur: the revocation list is stored in the system's firmware... | 15:15 |
| mdeslaur | desrt: the revocation list for the grub signing key, not the revocation list for the kernel signing key | 15:15 |
| mdeslaur | desrt: in rh,s design, the kernel signing key is stored in grub itself | 15:15 |
| desrt | mdeslaur: so revoke your grub and push a new one out with the kernel | 15:16 |
| mdeslaur | desrt: yes, which means microsoft will have to revoke grub's signing key once a month when a new kernel vulnerability comes out | 15:16 |
| desrt | mdeslaur: and i suspect they will do the same thing to themselves? | 15:16 |
| desrt | mdeslaur: one thing i can tell you with absolute certainty: | 15:16 |
| mdeslaur | desrt: of course not, it's all smoke and mirrors | 15:16 |
| desrt | if microsoft plans to revoke redhat keys when kernel exploits are discovered then canonical's key will be revoked on day 1 | 15:17 |
| mdeslaur | desrt: definitely | 15:17 |
| desrt | yet somehow we are pushing forward with this plan | 15:17 |
| desrt | after discussion with microsoft, no less | 15:17 |
| mdeslaur | desrt: so back to my initial statement: why bother with it all if all you're doing is gaining a two week advantage? | 15:18 |
| desrt | mdeslaur: WE GOTTA DO SOMETHING!!! | 15:18 |
| desrt | good enough reason? :) | 15:18 |
| mdeslaur | desrt: fedora and ubuntu are both relying on the fact that microsoft won't revoke the keys | 15:18 |
| mdeslaur | desrt: so cross your fingers :P | 15:18 |
| desrt | mdeslaur: revocations in the evil-security world are actually quite rare... | 15:18 |
| mdeslaur | but, if they don't revoke, then secure boot is worthless at protecting windows machines against malware | 15:19 |
| * desrt has never heard of the trigger actually being pulled on a dvd/bluray/hdcp revocation | 15:19 | |
| desrt | so here's an interesting question: how is the revocation list managed? | 15:19 |
| mdeslaur | so it's either 1- secure boot is defeated all over using a modified fedora/ubuntu grub/kernel, or 2- microsoft revokes the initial fedora/ubuntu keys and then stops signing new versions | 15:19 |
| desrt | OS contacts microsoft's servers and uploads the new list into the firmware? | 15:20 |
| mdeslaur | desrt: microsoft has control of the revocation list | 15:20 |
| mdeslaur | desrt: yes | 15:20 |
| desrt | we could just conveniently fail to do this.... | 15:20 |
| desrt | problem solved! | 15:20 |
| mdeslaur | desrt: sure, that works for two weeks, until updated hardware starts shipping | 15:20 |
| desrt | sure | 15:20 |
| desrt | then you have to sign again :) | 15:20 |
| mdeslaur | desrt: you assume microsoft is going to actually sign fedora/ubuntu stuff a second time :) | 15:21 |
| * kklimonda finds it funny that an arbitrary company should have this kind.. oh, who am I kidding | 15:21 | |
| mdeslaur | kklimonda: yeah, right? :) | 15:22 |
| desrt | anyway | 15:22 |
| desrt | it's obviously insecure, in the end | 15:22 |
| mdeslaur | yep | 15:22 |
| desrt | but it's clear that they're trying to raise the bar, at least | 15:23 |
| desrt | by what amount, who knows? | 15:23 |
| mdeslaur | they're trying to prevent the windows activation cracks that insert themselves at the boot loader level | 15:23 |
| * desrt suspects raising it high enough to securely load an unprompted-arbitrary-code-execution-platform (aka GRUB) may not be high enough | 15:23 | |
| kklimonda | mdeslaur: nice, haven't thought of this one before but it's a good point | 15:24 |
| mdeslaur | kklimonda: that's the sole reason for secure boot's existence | 15:24 |
| kklimonda | although I'm pretty sure current windows 7 cracks don't have to do that | 15:24 |
| mdeslaur | kklimonda: yes, that's exactly what they do | 15:24 |
| desrt | mdeslaur: too much tinfoil hat going around | 15:24 |
| desrt | microsoft has some real legitimate reasons for cleaning this problem up | 15:25 |
| mdeslaur | kklimonda: they insert themselves at the bootloader level, and emulate the bios calls to get the OEM indentification info out of the firmware | 15:25 |
| mdeslaur | attention lurkers: I have no inside knowledge of any of this stuff, and is all pulled out of my ass. kthx. | 15:26 |
| kklimonda | mdeslaur: ah, I know that's how it used to work but have always assumed that the newer cracks just replace some libraries in Windows itself.. | 15:27 |
| mdeslaur | kklimonda: ah, maybe. I'm not exactly an expert on what the latest stuff does. | 15:28 |
| kklimonda | nah, you may as well be right - I haven't had to read about it in years as I still have a valid key | 15:29 |
| kklimonda | it's just that hacking bootloader have always struck me as a very... volatile solution | 15:30 |
| === m_conley is now known as m_conley_away | ||
| === jbicha is now known as Guest28143 | ||
| === Guest28143 is now known as jbicha_ | ||
| bizhanMona | h | 16:49 |
| jbicha_ | oh lovely, changing the theme to HighContrast or Adwaita makes the messaging menu and sync menu disappear :( | 17:33 |
| jbicha_ | and it makes the session menu ugly | 17:34 |
| jbicha_ | why can't they use the hicolor fallback icons like they're supposed to? | 17:35 |
| === jbicha__ is now known as jbicha | ||
| jbicha | robert_ancell: hey could you sync libcroco for bug 1053169? | 22:46 |
| ubot2 | Launchpad bug 1053169 in libcroco "New upstream version 0.6.6" [Undecided,Fix committed] https://launchpad.net/bugs/1053169 | 22:46 |
| robert_ancell | jbicha, ok | 22:46 |
| === Amaranthus is now known as Amaranth | ||
| robert_ancell | jbicha, synces | 23:03 |
| robert_ancell | jbicha, synced | 23:03 |
| mlankhorst | just curious, does anyone here ever leave apport enabled? I would but every time i leave it on it pops up that something has gone wrong right after first use | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!