Re: [Tails-dev] Tails: pcmcia / firewire / etc.
intrigeri: The issue about the exact delay that was raised (5 minutes starting when, 1 minute starting at the same time as GDM, anything else?) is still in need of a conclusion. One minute is enough for the oh, I forgot to plug in the network card case. I'd still be more in favor of 5 to handle to the oh, I forget to plugin in the card used to hook up the scanner case. Five minutes are not a long window. If someone jumps one you while you are using Tails, you have a problem anyway. So this is meant to protect from attacks that can happen while you are on a short break. And I think your attention is probably going to be focused on Tails for at least 5 minutes after it has started. -- Ague pgp9fU7Y58jGG.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
hi, intrigeri wrote (12 Oct 2012 09:27:35 GMT) : Hi, intrigeri wrote (28 Sep 2012 15:27:50 GMT) : * de-activate PCMCIA and ExpressCard on systems that don't have any PCMCIA or ExpressCard devices after running for 5 minutes. This is going to byte some users, but probably only the first time. I am strongly inclined towards this one, for PCMCIA, ExpressCard FireWire and even Bluetooth. That was two weeks ago, and the only other expressed opinion (Ague's) was in favor of the same. Looks like we've got a consensus, right? Deadline: Friday, October 19th. I updated the many tickets involved (f11198b). The issue about the exact delay that was raised (5 minutes starting when, 1 minute starting at the same time as GDM, anything else?) is still in need of a conclusion. That should not be the hardest part of the implementation, though, so I don't think it's a blocker right now. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
intrigeri: Hi, Jacob Appelbaum wrote (13 Oct 2012 11:02:17 GMT) : As this is a modular kernel - is there a reason not to simply add a enable firewire widget? There are several I can see: * It is a UX failure every time someone has to go out of their way to have Tails work with their hardware. * Every such widget we add to Tails Greeter makes the greeter worse for every Tails user: more cluttered, more complicated. That's why I still prefer the let's guess what the user wants approach: if they plug a device in the X slot, that's probably because they want to use it, so let's keep the X bus enabled, and disable it else. OTOH, I understand your concern, and I now think the 5 minutes delay that was suggested may be a bit too long. We did not specify exactly when the 5 minutes countdown starts, anyway. Perhaps we could start an initscript right after GDM, have it sleep 1 minute, and then disable these dangerous buses if unused? (This gives a clear visual indication of when the countdown starts.) Regardless of the solution proposed above, would it be possible to have an alternate grub menu that disables these dangerous interfaces from the get go? There could be an Advanced grub menu entry, that displays these alternative kernel-param boot options. Surely, there should be *some* secure option where the window of attack is zero? ~abel signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
On Mon, Oct 15, 2012 at 02:47:05PM +, Abel Luck wrote: intrigeri: Hi, Jacob Appelbaum wrote (13 Oct 2012 11:02:17 GMT) : As this is a modular kernel - is there a reason not to simply add a enable firewire widget? There are several I can see: * It is a UX failure every time someone has to go out of their way to have Tails work with their hardware. * Every such widget we add to Tails Greeter makes the greeter worse for every Tails user: more cluttered, more complicated. That's why I still prefer the let's guess what the user wants approach: if they plug a device in the X slot, that's probably because they want to use it, so let's keep the X bus enabled, and disable it else. OTOH, I understand your concern, and I now think the 5 minutes delay that was suggested may be a bit too long. We did not specify exactly when the 5 minutes countdown starts, anyway. Perhaps we could start an initscript right after GDM, have it sleep 1 minute, and then disable these dangerous buses if unused? (This gives a clear visual indication of when the countdown starts.) Regardless of the solution proposed above, would it be possible to have an alternate grub menu that disables these dangerous interfaces from the get go? Please note that Tails is using SYSLINUX at the moment and not GRUB. There could be an Advanced grub menu entry, that displays these alternative kernel-param boot options. Surely, there should be *some* secure option where the window of attack is zero? How would you label it so that it does not puzzle users who are using a FireWire external disks, but never had to think about the word FireWire before? What would you write in the end-user documentation? Who would be using such option? I am afraid about the endless stream of why are you not making it the default?, like the one we already get regarding Javascript. Answers would probably be even quite similar. I'm not having such option, but it really needs to be done right. -- Ague pgp8l9z0LmDSa.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
Ague Mill: On Mon, Oct 15, 2012 at 02:47:05PM +, Abel Luck wrote: intrigeri: Hi, Jacob Appelbaum wrote (13 Oct 2012 11:02:17 GMT) : As this is a modular kernel - is there a reason not to simply add a enable firewire widget? There are several I can see: * It is a UX failure every time someone has to go out of their way to have Tails work with their hardware. * Every such widget we add to Tails Greeter makes the greeter worse for every Tails user: more cluttered, more complicated. That's why I still prefer the let's guess what the user wants approach: if they plug a device in the X slot, that's probably because they want to use it, so let's keep the X bus enabled, and disable it else. OTOH, I understand your concern, and I now think the 5 minutes delay that was suggested may be a bit too long. We did not specify exactly when the 5 minutes countdown starts, anyway. Perhaps we could start an initscript right after GDM, have it sleep 1 minute, and then disable these dangerous buses if unused? (This gives a clear visual indication of when the countdown starts.) Regardless of the solution proposed above, would it be possible to have an alternate grub menu that disables these dangerous interfaces from the get go? Please note that Tails is using SYSLINUX at the moment and not GRUB. Noted. There could be an Advanced grub menu entry, that displays these alternative kernel-param boot options. Surely, there should be *some* secure option where the window of attack is zero? How would you label it so that it does not puzzle users who are using a FireWire external disks, but never had to think about the word FireWire before? Sorry, I wasn't clear. The bootime options I proposed were the firewire disabled options. Assuming, as seems to be the reasoning so far, that the default behavior will be the most usable (enabled for X minutes then disabled, or w/e), my idea is to have a disabled from boot alternative option. To answer your question, my thought was it would be hidden behind an advanced menu, so users who didn't care and didn't know will not pay it any mind. Example (for the sake of clarity): ++ || | * Boot Tails | | * Memtester | | * Advanced |- option behind this menu || ++ What would you write in the end-user documentation? Who would be using such option? The documentation would explain, in layman's terms, the risk of such interfaces, then it would explain the default behavior of the X-minute window. Next, it would explain the the potential threat scenarios in which a user might be concerned about that window, and, finally, instruct how to use the advanced option. I would use such an option, I imagine Jake would as well (though I won't speak for him). Any potential tails user (1) with the awareness of such attacks and (2) desire mitigate them. I am afraid about the endless stream of why are you not making it the default?, like the one we already get regarding Javascript. Answers would probably be even quite similar. I'm not having such option, but it really needs to be done right. Absolutely it should be done right. You shouldn't be afraid of that question. The answer to why are you not making it the default? is being discussed right now in this email thread, see Jacob's point in the great-great-grandfather of this message and intrigeri's reply. I still think this should be the default, and the enabled firewire the advanced option. I can't imagine the majority of users use firewire. Putting the majority at risk for the minority doesn't seem a good idea, BUT I can concede that thought with the 1-minute window proposal. Nevertheless, my point (repeating myself here), is that there should be a zero-second window option regardless, for those that care. Moreover, that option does not have to significantly affect the UX. ~abel signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
On Sat, Oct 13, 2012 at 5:18 AM, Maxim Kammerer m...@dee.su wrote: On Sat, Oct 13, 2012 at 5:04 AM, Steve Weis stevew...@gmail.com wrote: I think the kernel is working as expected. Debian and Ubuntu are both also vulnerable by default, since FireWire modules are loaded automatically. From Documentation/debugging-via-ohci1394.txt: “The alternative firewire-ohci driver in drivers/firewire uses filtered physical DMA by default, which is more secure but not suitable for remote debugging.” There is some more information in 1394 OHCI Spec v1.1 [1, §5.14.2]. drivers/firewire/ohci.c doesn't touch OHCI1394_PhyReqFilter* registers at all if CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set, so physical request DMA should be forwarded to asynchronous request DMA. Could it be that the kernel does not implement AR DMA correctly? There is also something strange when the spec is compared to the older v1.0 spec [2, §5.13.2]. The older spec does not have a clarification wrt. what happens on a bus reset, in Table 5-21 (whether it has such a clarification in §5.13.1, for instance). It has such a clarification in the newer v1.1 spec, in Table 5-22. Is it possible that when implementing OHCI 1.0, vendors did not know what to do, and kept the physReq* registers values even over a soft reset? This is quite unlikely, of course, but did you try to power off the computer completely before performing the test? [1] http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/ohci_11.pdf [2] ftp://ftp.microsoft.com/bussys/1394/OHCI/Released_Specs/OHC1.0.pdf -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
On Sun, Oct 14, 2012 at 9:57 PM, Steve Weis stevew...@gmail.com wrote: There are two alternative driver stacks (e.g. ieee1394 and firewire-core) and the docs talk about them both interchangeably. It's a bit confusing. The CONFIG_FIREWIRE_OHCI_REMOTE_DMA kernel hacking option may only be relevant to the legacy ohci1394 module. Indeed, the doc is confusing, but it's easier to look at the source files. CONFIG_FIREWIRE_OHCI_REMOTE_DMA is used by the new stack, and I was actually wrong previously when saying that physReq* registers are only written to if the option is disabled (missed an #else in an #ifdef). The ohci_enable_phys_dma() function in drivers/firewire/ohci.c enables physical DMA for a specified node, and this function is called by none other than the sbp2 module (via a wrapper), in sbp2_probe() and sbp2_update(). So: One thought is that it the sbp2 module might be allowed to circumvent whatever filtering is happening. Sbp2 enables full DMA access, and I haven't been able to carry out Firewire DMA attacks via Inception without it. This must be exactly the case. Sbp2 actually uses DMA filtering — it “filters” physical DMA to a specific Firewire node. blacklist firewire_sbp2 This (or disabling CONFIG_FIREWIRE_SBP2) should be enough to prevent physical DMA attacks on Firewire — there is currently no other way to enable physical DMA in Firewire than via firewire_sbp2 or via unfiltered physical DMA (enabled by CONFIG_FIREWIRE_OHCI_REMOTE_DMA). Of course, there is also asynchronous DMA, but its accessible memory regions are kernel's responsibility. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
On Sun, Oct 14, 2012 at 11:38 PM, Maxim Kammerer m...@dee.su wrote: there is currently no other way to enable physical DMA in Firewire than via firewire_sbp2 or via unfiltered physical DMA (enabled by CONFIG_FIREWIRE_OHCI_REMOTE_DMA). Ah, there is also CONFIG_PROVIDE_OHCI1394_DMA_INIT + ohci1394_dma=early, which enables unfiltered physical DMA during early boot, but the effects will be reverted by card soft reset during normal firewire_ohci initialization. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
On Fri, Oct 12, 2012 at 06:15:07PM -0700, Steve Weis wrote: Hi. I booted Tails' latest release and was able to scrape memory contents via FireWire. All the necessary firewire modules are enabled by default and Inception worked out of the box. This would let someone root a machine through, say, a daisy chained thunderbolt monitor. I'd either remove support from the kernel, blacklist the modules in modprobe, or disable support with a boot param. We can't just do that. Tails is also meant to be a safe environment to produce sensitive documents. Being able to retrieve a video from a DV camera, edit it and send it online is a use case Tails should support. From the recent discussions regarding ExpressCards and the likes, it looks like we are moving to a common pattern of you have 5 minutes to plug things on those ports that can be dangerous, otherwise, they will be disabled. This should work for FireWire too, even if it feels more cumbersome to me than for an expansion card. -- Ague pgp4q3EidLIt5.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
Ague Mill: On Fri, Oct 12, 2012 at 06:15:07PM -0700, Steve Weis wrote: Hi. I booted Tails' latest release and was able to scrape memory contents via FireWire. All the necessary firewire modules are enabled by default and Inception worked out of the box. This would let someone root a machine through, say, a daisy chained thunderbolt monitor. I'd either remove support from the kernel, blacklist the modules in modprobe, or disable support with a boot param. We can't just do that. Tails is also meant to be a safe environment to produce sensitive documents. Being able to retrieve a video from a DV camera, edit it and send it online is a use case Tails should support. I'd hardly call this safe. I mean, sure - those video people are safely able to download videos over firewire - but for every person that does that, how many people will be vulnerable to DMA attacks without even having a clue about firewire? From the recent discussions regarding ExpressCards and the likes, it looks like we are moving to a common pattern of you have 5 minutes to plug things on those ports that can be dangerous, otherwise, they will be disabled. This should work for FireWire too, even if it feels more cumbersome to me than for an expansion card. As this is a modular kernel - is there a reason not to simply add a enable firewire widget? That way everyone is secure by default and when someone wishes to enable it, someone will be able to be notified of the danger they have just enabled? All the best, Jacob ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
Hi, intrigeri wrote (28 Sep 2012 15:27:50 GMT) : * de-activate PCMCIA and ExpressCard on systems that don't have any PCMCIA or ExpressCard devices after running for 5 minutes. This is going to byte some users, but probably only the first time. I am strongly inclined towards this one, for PCMCIA, ExpressCard FireWire and even Bluetooth. That was two weeks ago, and the only other expressed opinion (Ague's) was in favor of the same. Looks like we've got a consensus, right? Deadline: Friday, October 19th. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
Hi, * de-activate PCMCIA and ExpressCard on systems that don't have any PCMCIA or ExpressCard devices after running for 5 minutes. This is going to byte some users, but probably only the first time. I am strongly inclined towards this one, for PCMCIA, ExpressCard FireWire and even Bluetooth. Seems this could be a consensus. Without disagremment before Oct 19 I consider this as agreed. Cheers ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
Alan: Hi, * de-activate PCMCIA and ExpressCard on systems that don't have any PCMCIA or ExpressCard devices after running for 5 minutes. This is going to byte some users, but probably only the first time. I am strongly inclined towards this one, for PCMCIA, ExpressCard FireWire and even Bluetooth. Seems this could be a consensus. Without disagremment before Oct 19 I consider this as agreed. I would add Thunderbolt to the list as well: http://www.breaknenter.org/2012/02/adventures-with-daisy-in-thunderbolt-dma-land-hacking-macs-through-the-thunderbolt-interface/ All the best, Jacob ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
On Sat, Oct 13, 2012 at 1:30 AM, Jacob Appelbaum ja...@appelbaum.net wrote: I would add Thunderbolt to the list as well: http://www.breaknenter.org/2012/02/adventures-with-daisy-in-thunderbolt-dma-land-hacking-macs-through-the-thunderbolt-interface/ As far as I can see, all these attacks (PCMCIA, ExpressCard, Thunderbolt) rely on attaching to a FireWire interface one way or another, and then accessing arbitrary memory via DMA. But such ability is (or can be) disabled by default in the newer firewire-ohci module, as described in debugging-via-ohci1394.txt, and even discussed on the relevant Tails TODO page. So why disable the interfaces? Looks like an overkill to me. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
Hi. I booted Tails' latest release and was able to scrape memory contents via FireWire. All the necessary firewire modules are enabled by default and Inception worked out of the box. This would let someone root a machine through, say, a daisy chained thunderbolt monitor. I'd either remove support from the kernel, blacklist the modules in modprobe, or disable support with a boot param. Iommu should be enabled as well for good measure, although it can be circumvented. Cheers. On Oct 12, 2012 5:48 PM, Jacob Appelbaum ja...@appelbaum.net wrote: Maxim Kammerer: On Sat, Oct 13, 2012 at 1:30 AM, Jacob Appelbaum ja...@appelbaum.net wrote: I would add Thunderbolt to the list as well: http://www.breaknenter.org/2012/02/adventures-with-daisy-in-thunderbolt-dma-land-hacking-macs-through-the-thunderbolt-interface/ As far as I can see, all these attacks (PCMCIA, ExpressCard, Thunderbolt) rely on attaching to a FireWire interface one way or another, and then accessing arbitrary memory via DMA. But such ability is (or can be) disabled by default in the newer firewire-ohci module, as described in debugging-via-ohci1394.txt, and even discussed on the relevant Tails TODO page. So why disable the interfaces? Looks like an overkill to me. My understanding is that this assumption doesn't actually pan out in practice. I've cc'ed Steve who may have some more information to contribute. As I understand things, he found that as predicted, the default it is off doesn't actually always turn DMA off. All the best, Jacob ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
I think the kernel is working as expected. Debian and Ubuntu are both also vulnerable by default, since FireWire modules are loaded automatically. I can send some fix suggestions if you like. On Oct 12, 2012 7:35 PM, Maxim Kammerer m...@dee.su wrote: On Sat, Oct 13, 2012 at 3:15 AM, Steve Weis stevew...@gmail.com wrote: Hi. I booted Tails' latest release and was able to scrape memory contents via FireWire. All the necessary firewire modules are enabled by default and Inception worked out of the box. This would let someone root a machine through, say, a daisy chained thunderbolt monitor. Thanks for testing! Shouldn't such behavior be classified as a kernel bug? I can't find anything related on the kernel bugtracker. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
On Sat, Oct 13, 2012 at 5:04 AM, Steve Weis stevew...@gmail.com wrote: I think the kernel is working as expected. Debian and Ubuntu are both also vulnerable by default, since FireWire modules are loaded automatically. From Documentation/debugging-via-ohci1394.txt: “The alternative firewire-ohci driver in drivers/firewire uses filtered physical DMA by default, which is more secure but not suitable for remote debugging.” Isn't this supposed to limit DMA? I can send some fix suggestions if you like. Not being a kernel developer, I am not sure I will be able to act on them. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
Hi, a...@boum.org wrote (26 Sep 2012 17:44:34 GMT) : We didn't reach a conclusion on this topic. The page on pcmcia is still tagged discuss. Thank you for resurrecting this discussion! It's unclear to me what exact part of it you intended to resurrect, but anyway, I guess it's good to have the whole picture in mind, and we might even manage to find a common solution for PCMCIA, ExpressCard, FireWire, and perhaps even Bluetooth. This is all about todo/protect_against_external_bus_memory_forensics, that links to: * todo/disable expresscard? * todo/disable pcmcia? * todo/disable_firewire? * If a firewire card was inserted into the slot and the bus is active, pop up a dialog and ask hey, you want to use firewire/etc.? I'm not sure it's possible to let a bus / slot enabled enough so that the kernel and udev are able to pop up such a message, while *not* allowing the inserted device to do Bad™ things. Details might be tricky to get right. I hope we don't need something that clever, implementation -wise. * disable these buses by default, allow opt-in through tails-greeter to enable I guess this would be our worst case solution, if we find nothing better. UX failure IMHO. * ask that users assert they want to use this or that bus, and make the assertion bind to a single device, rather than all devices blindly I guess that's basically the same as the per-device pop up dialog idea. * de-activate PCMCIA and ExpressCard on systems that don't have any PCMCIA or ExpressCard devices after running for 5 minutes. This is going to byte some users, but probably only the first time. I am strongly inclined towards this one, for PCMCIA, ExpressCard FireWire and even Bluetooth. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
On Wed, Sep 26, 2012 at 07:44:34PM +0200, a...@boum.org wrote: Issue: 32bit PCMCIA gets DMA. It is thus usable by an adversary for external bus memory forensics on a running Tails. Question: we now have to discuss what usability vs. security balance we want. Ideas: * If a firewire card was inserted into the slot and the bus is active, pop up a dialog and ask hey, you want to use firewire/etc.? I don't know how this would be possible without serious kernel hacking. * disable these buses by default, allow opt-in through tails-greeter to enable * ask that users assert they want to use this or that bus, and make the assertion bind to a single device, rather than all devices blindly * de-activate PCMCIA and ExpressCard on systems that don't have any PCMCIA or ExpressCard devices after running for 5 minutes. This is going to byte some users, but probably only the first time. I still prefer the later. -- Ague pgpi8mXnZmBpw.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
Hi, We didn't reach a conclusion on this topic. The page on pcmcia is still tagged discuss. Issue: 32bit PCMCIA gets DMA. It is thus usable by an adversary for external bus memory forensics on a running Tails. Question: we now have to discuss what usability vs. security balance we want. Ideas: * If a firewire card was inserted into the slot and the bus is active, pop up a dialog and ask hey, you want to use firewire/etc.? * disable these buses by default, allow opt-in through tails-greeter to enable * ask that users assert they want to use this or that bus, and make the assertion bind to a single device, rather than all devices blindly * de-activate PCMCIA and ExpressCard on systems that don't have any PCMCIA or ExpressCard devices after running for 5 minutes. This is going to byte some users, but probably only the first time. This is related to [[https://tails.boum.org/todo/disable_expresscard__36__]] Please give your thoughts. Cheers -- pgpsLd1OZy4tU.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
Hi, I'd still go for [...] A possible middle-ground could be to [...] FWIW, I've created a parent ticket for these issues, and pasted the various implementation ideas in there: todo/protect_against_external_bus_memory_forensics Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
Hi, Jacob Appelbaum wrote (22 Aug 2012 21:01:22 GMT) : Pop up a dialog and ask hey, you want to use firewire? - at least if they had enabled a password, they will have to bypass a screen lock or authenticate to enable full memory forensics. I'm not sure I understand clearly what you are suggesting. When do you think such a dialog should appear? Cheers! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
intrigeri: Hi, Jacob Appelbaum wrote (22 Aug 2012 21:01:22 GMT) : Pop up a dialog and ask hey, you want to use firewire? - at least if they had enabled a password, they will have to bypass a screen lock or authenticate to enable full memory forensics. I'm not sure I understand clearly what you are suggesting. When do you think such a dialog should appear? If a firewire card was inserted into the pcmcia slot and pcmcia/cardbus is active, I suggest it. If such things were entirely disabled, I'd have a setup wizard that stores preferences in the persistent storage area. All the best, Jacob ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
Hi Jake, Jacob wrote (late 2011): Disable all firewire kernel modules. This will help fight against forensics programs that will attempt to suck out memory with the internal firewire or a cardbus/pcmcia card. And ta...@boum.org replied (05 Jan 2012 23:54:40 GMT) : Recent Linux kernels shipped by Debian use filtered physical DMA; unfiltered physical DMA seems to be disabled (CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set). Do you know which class of attacks is still practicaly doable on such a system? We are still very interested in your answer to this question :) Thanks a lot in advance! (Reference: https://tails.boum.org/todo/disable_firewire__63__/) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Tails: pcmcia / firewire / etc.
Hi, (Please Cc: any subsequent reply to the public tails-dev@boum.org ML.) Disable all firewire kernel modules. This will help fight against forensics programs that will attempt to suck out memory with the internal firewire or a cardbus/pcmcia card. Disable all pcmcia kernel modules; we should try to power off the bus entirely. Thanks for bringing up these issues. They raise the question of usability vs. security balance. One of the Tails usecase is indeed Working on sensitive documents, which includes audio and video. Such a task might include using external firewire devices. We thus have to discuss and investigate this issue furether. Will be tracked there: https://tails.boum.org/todo/disable_expresscard__63__/ https://tails.boum.org/todo/disable_pcmcia__63__/ https://tails.boum.org/todo/disable_firewire__63__/ Recent Linux kernels shipped by Debian use filtered physical DMA; unfiltered physical DMA seems to be disabled (CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set). Do you know which class of attacks is still practicaly doable on such a system? -- pgpOeJvDcD6Xg.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
