SELinux on Android

Posted Aug 29, 2014 22:12 UTC (Fri) by brugolsky (guest, #28)
In reply to: SELinux on Android by yaap
Parent article: SELinux on Android

"The TLA don't care much about the modem IMHO. To intercept the traffic it's much easier to do it on the network side. And if it happens that the network side is from a non-cooperating country and well protected, it's easier to intercept on the host OS (Android for example) than on the proprietary baseband."

Easier at the moment; less so if the user is using RedPhone, TextSecure, VPN, Tor, etc., on a stripped-down secured version of Android. [Though all of these are just red flags unless they are in very widespread use.]

My point is that many extant hardware designs have uncloseable attack vectors that may subvert or bypass the only (potentially) open part: the App OS. There is way too much hardware out there where the baseband OS has unmediated access to memory, SIM, and (some of) the sensors. That's unnecessary and unacceptable; access to everything except the radio itself ought to be mediated by the App OS. I'd also prefer hardware toggling of radios and sensors; "off" should mean off. And various side-channels ought be closed. Absent a detachable USB LTE modem (bonus points if it can do VoLTE where available), the best solution that I can think of at the moment is to use two smartphones: run the App OS on one, and treat the second phone as a dumb, untrusted IP router (with its sensors physically disabled). Bit bulky in the pocket, though. ;-)

"I like open systems, but based on my experience the best we can get as far as cellular devices go is a fully open host, and an isolated baseband running a validated (and in practice, opaque) firmware blob and controlled by a documented interface."

That would be great; what's missing today is the documented (narrow and verifiable) interface.

to post comments

SELinux on Android

Posted Aug 30, 2014 10:18 UTC (Sat) by yaap (subscriber, #71398) [Link] (1 responses)

Mostly agreed, some more comments as seen from the modem implementation side.

Regarding hardware design, there is no escaping that one has to trust the chip vendor: there could always be some backdoor system (VPro-like, to give an idea). Using discrete chips allows mitigating this, but again from my point of view the main risk is the AP side.
From what I've seen, the power supply of the modem subsystem is always under the control of the AP side. So with a two chips solution there is a safe way to turn the modem off: shut down the power. Restarting will be slower than if the modem is power gated as the modem will have to reboot from scratch. That would add a few seconds when turning the modem back on vs. just power gating the modem (when power gated the modem could go back to active on its own).
The SIM card connected to the modem seems natural to me: the whole system is designed with the assumption that SIM card and modem are slave to the network. In countries with unlocked phones like in Europe, the SIM card processor is the only one guaranteed to be under the operator control by the way, so operators are sensitive about it.
The radio interface must be directly controlled by the modem for real-time reasons. There is no reason for the modem to access any non-telco hardware. With the trend to add IOMMU this can be enforced in a single chip design --- and if you don't trust the chip vendor on that, you can't trust the AP part either IMHO.

Regarding the modem interface it may be improving soon thanks to the USB Forum MBIM class. Up to now Microsoft didn't care for the USB Forum classes and designed its own RNDIS based interfaces. But for W8 they've seen the light and are basing the modem control on the USB Forum MBIM class. The MBIM spec covers both data exchanges with multiple PDNs support, but also the modem control with a message based equivalent to AT commands. Of course there will be gotchas, like some behavior of the MS implementation becoming de-facto undocumented standards ;), but still the core spec is open and there is a strong drive to move to MBIM on the windows side. And this MBIM interface could be used for other OSs like Linux and MacOS. So hopefully, we'll soon have a common interface accross all modems and OSs, and that would make support easier for Linux.

For the two phones solution, you're for sure removing the modem as an attack vector ;)

SELinux on Android

Posted Aug 30, 2014 13:56 UTC (Sat) by brugolsky (guest, #28) [Link]

Thanks for your insights, especially regarding MBIM.

I have to say that vPro, and the mindset that accompanies it, dismays and angers me. I'm tired of phony "openness." If Intel actually wanted to build open, secure systems, we'd all be running something LinuxBIOS/CoreBoot-like, not the garbage that we have. My (AMD) LinuxBIOS boxes used to boot in seconds, and simply did what I asked of them, nothing more. When I had problems with hardware that had errata, I'd throw a "setpci" or similar into the initrd. In over 30 years of managing systems, at least 90% of my head-banging frustration has been caused by opaque, unmodifiable code, and I know that I'm not alone. Given the room for mischief in the networked world, this is only going to get worse, not better.

Sadly, the inevitable conclusion is that a trustworthy design requires networking/radio gear that is discrete from the computational hardware, and outside the security boundary.