3 ms·

Only security thing they point out is USB access for the modem, and you can fix that quite easily with a bunch of udev rules, I guess. Disable device auto-probi

by megous 5y ago

Only security thing they point out is USB access for the modem, and you can fix that quite easily with a bunch of udev rules, I guess. Disable device auto-probing on the USB port the modem is connected to, and bind the proper modem/ACM driver to the device manually via udev rule. Then there will be no exposure to "all Linux USB drivers" and you'll avoid modem exposing itself as a keyboard and typing things into your console, or whatever. It's the same thing you should be doing on the desktop if you fear untrusted USB devices.

fsflover 5y ago
Or just use Qubes OS with a dedicated VM for usb devices: https://qubes-os.org https://qubes-os.org.
- megous 5y ago
  That will still allow execution of kernel code you may not want executed (even though in a VM), and is thus strictly worse. Especially for the modem, which you need to run and interact with all the time on a phone, this sounds like overkill.
  - rank0 5y ago
    Not sure I understand your comment. Of course kernel code is executed in the guest VM…what’s the problem with that? An adversary would have to break Xen security controls to gain access to your other domains.
    - megous 5y ago
      VM has to have some communication bridge to the host, for all the features of the modem. That's still quite a lot of attack surface, once guest VM is compromised. It's better to not expose the needless attack surface rather than just attempting to isolate the attack into a leaky VM.
      - rank0 5y ago
        My understanding is that the paravirtualization provided by Xen is an effective control. The guest shouldn’t have direct access to the hardware device io right? What is the alternative? If you don’t use a VM you have to expose dom0 directly to device io. EDIT: ah I see we’re talking about a Linux phone! I agree with your point I’m not sure mobile devices have the resources to isolate every component into a VM. Overkill indeed!
        bpye 5y ago
        Mobile devices could, if the SOC allowed every device to be isolated with an IOMMU. Apple does this, Nvidia too (though some SoCs are broken) and I think Qualcomm might as well. A lot of the other ARM SoCs seem to have just one or maybe two domains (GPU and everything else), and a non standard IOMMU for even that too. I’ve looked a few times for an ARM SBC with a nice architecture to play with this stuff, Nvidia seemed to be the only option but they are also unobtanium right now.
simonh 5y ago
>Only security thing they point out is USB access for the modem.. And the pointless supply chain vulnerability, introduced in order to game the FSF certification process, and lying about security features in their competitors, and accusing them of using binary blobs which they actually do as well while doing so with a worse security implementation. >you can fix that quite easily with a bunch of udev rules, I guess Exactly, why didn't they? I would understand if some of those were just teething troubles but that phone came out well over a year ago and bear in mind this analysis and criticism comes from within the OSS community trying to help them get this fixed, and hitting a brick wall.

by megous 5y ago

fsflover 5y ago

Or just use Qubes OS with a dedicated VM for usb devices: https://qubes-os.org https://qubes-os.org.

megous 5y ago
That will still allow execution of kernel code you may not want executed (even though in a VM), and is thus strictly worse. Especially for the modem, which you need to run and interact with all the time on a phone, this sounds like overkill.
- rank0 5y ago
  Not sure I understand your comment. Of course kernel code is executed in the guest VM…what’s the problem with that? An adversary would have to break Xen security controls to gain access to your other domains.
  - megous 5y ago
    VM has to have some communication bridge to the host, for all the features of the modem. That's still quite a lot of attack surface, once guest VM is compromised. It's better to not expose the needless attack surface rather than just attempting to isolate the attack into a leaky VM.
    - rank0 5y ago
      My understanding is that the paravirtualization provided by Xen is an effective control. The guest shouldn’t have direct access to the hardware device io right? What is the alternative? If you don’t use a VM you have to expose dom0 directly to device io. EDIT: ah I see we’re talking about a Linux phone! I agree with your point I’m not sure mobile devices have the resources to isolate every component into a VM. Overkill indeed!
      - bpye 5y ago
        Mobile devices could, if the SOC allowed every device to be isolated with an IOMMU. Apple does this, Nvidia too (though some SoCs are broken) and I think Qualcomm might as well. A lot of the other ARM SoCs seem to have just one or maybe two domains (GPU and everything else), and a non standard IOMMU for even that too. I’ve looked a few times for an ARM SBC with a nice architecture to play with this stuff, Nvidia seemed to be the only option but they are also unobtanium right now.

simonh 5y ago

>Only security thing they point out is USB access for the modem.. And the pointless supply chain vulnerability, introduced in order to game the FSF certification process, and lying about security features in their competitors, and accusing them of using binary blobs which they actually do as well while doing so with a worse security implementation. >you can fix that quite easily with a bunch of udev rules, I guess Exactly, why didn't they? I would understand if some of those were just teething troubles but that phone came out well over a year ago and bear in mind this analysis and criticism comes from within the OSS community trying to help them get this fixed, and hitting a brick wall.