SELinux on Android

Posted Aug 29, 2014 14:08 UTC (Fri) by yaap (subscriber, #71398)
In reply to: SELinux on Android by brugolsky
Parent article: SELinux on Android

Hi, telecom engineer here.

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.

It is still a good idea to isolate the host OS environment from the baseband using an IOMMU (SMU in the ARM world) or a separate chip. Mostly for robustness: you don't want complex sub-system A to corrupt the environment of complex sub-system B because of a bug. That's the road to debugging hell. And it removes the baseband as an attack vector, which is always nice (even if there are likely easier vectors).

The software of the baseband will remain locked. A radio system is extremely complex (have a look at the zillion specs @ 3gpp.org --- and for sure a lot of this complexity is historic or could be avoided. But there's still of lot of intrinsic complexity there, because the domain is hard) and very fragile. Airwaves are a shared medium, and the worst jammer is often a buggy or malfunctioning device. You don't want a clueless person degrading possibly several cells capacity just because he boosted his phone transmit power because it's "l33t" and without understanding the impact in term of interference.

To avoid that there is a long and complex certification process before a new baseband software version is released in the field. And in many places it is simply illegal to use a device that has not been certified (e.g.: GCF certification is required in Europe). This complex certification is costly but frankly necessary for the system to operate properly. And it does put doing a baseband outside of the reach of people without deep pockets.

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.

to post comments

SELinux on Android

Posted Aug 29, 2014 22:12 UTC (Fri) by brugolsky (guest, #28) [Link] (2 responses)

"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.

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.

SELinux on Android

Posted Aug 30, 2014 20:58 UTC (Sat) by intgr (subscriber, #39733) [Link] (4 responses)

> A radio system is extremely complex (have a look at the zillion specs @ 3gpp.org --- and for sure a lot of this complexity is historic or could be avoided. But there's still of lot of intrinsic complexity there, because the domain is hard) and very fragile.

We've heard this argument many times in the past, that open source developers are too incompetent to work on something as complex as X. Usually to be proven wrong months or years later.

The real question is whether anyone has enough motivation to do so.

> You don't want a clueless person degrading possibly several cells capacity just because he boosted his phone transmit power because it's "l33t"

Nice straw man there.

SELinux on Android

Posted Aug 30, 2014 21:19 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

> We've heard this argument many times in the past, that open source developers are too incompetent to work on something as complex as X. Usually to be proven wrong months or years later.
So can you design a spec that allows fully untrusted devices and provides a better level of service than LTE?

> Nice straw man there.
It's not. A misbehaving phone WILL degrade service for other cell phone tower clients.

SELinux on Android

Posted Aug 31, 2014 10:45 UTC (Sun) by yaap (subscriber, #71398) [Link] (2 responses)

> We've heard this argument many times in the past, that open source
> developers are too incompetent to work on something as complex as X.
> Usually to be proven wrong months or years later.

Competence is not the topic here. Did you know that Fabrice Bellard implemented a LTE eNB in software on a PC using a GNU Radio SDR box for example? Well I did, so I know that a very talented person can implement significant parts of the system.

But because of the huge scope and certification constraints (necessary for the system to work at scale) to get to a deployment quality product requires a lot of QA. The test equipment alone is above $1M, and if you go through a certification lab it'll cost more over time. And it's a lot of human effort to move from "works in the lab" to certified and then to "works well in the field".
So what I mean is that getting to a real product is not possible at an amateur level: you need significant funding.

On principle an open source implementation is possible, but due to the practical funding requirements there would need to be a business case. I don't see one, but would be happy to be proven wrong.

I think we can all agree that Fabrice Bellard contributions to open source are outstanding. But he didn't open source his eNB implementation, it's closed source through a company call Amarisoft (http://www.amarisoft.com/). I guess that even for someone as open source friendly as him the level of work involved requires getting some money out of it. And here I don't think one could monetize this work if open sourced. Why? Because Amarisoft is not a deployment ready product, it's more a technological platform. Only a few companies have the resources to get this into a field product, and if open source they could do this directly without paying. Just my opinion here.

>> You don't want a clueless person degrading possibly several cells
>> capacity just because he boosted his phone transmit power because
>> it's "l33t"
>
> Nice straw man there.

I don't think so, I had real situations in mind when I wrote this.

When open source WiFi AP became available (and I love them, been an OpenWRT user for a while) you could see in the forum people boasting about how they boosted the Tx power to "get better performance". Some did it thinking they extended their reach, not realizing that without boosting the STA side the UL would still limit the reach. Other did it for higher throughput, apparently without realizing too that they could get higher MCS at the price of more interference for others, and that if everyone did the same everyone would loose.

Another example is from the implementation of a 2G device stack (I seem to remember it was discussed on LWN, TBC). The guys told they did their first field tests at max Tx power because gain control wasn't implemented yet. Now this is not as bad in 2G as it would in 3G, but still no operator would allow that in their network.

All this from memory, and I won't spend time searching for precise reference. But it seems common sense that if some parameters become easy to tweak thanks to an open source implementation, some people who are not on top of the consequences will do so, possibly with bad results for others. Not everyone of course, but you can't expect all users to act responsible and it take only one to mess up a cell or more. The tragedy of the commons do apply to airwaves.
This is why I believe cellular networks implementation will remain locked.

I like open source, use Debian whenever I can, but I also believe that locked certified radios attached to open host is the best scheme for all. It's just my opinion, but it's back by years of experience in the field.

SELinux on Android

Posted Aug 31, 2014 11:30 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

Harald Welte has deployed an open source cell site several times over recent years, so it's possible to do it from a technical point of view.

As for the problems of people tweaking things, turning up power and so on was done before OpenWRT was available, game console hacks show that you don't need open source to tamper with things (in fact, many of the hacks to the consoles are far more sophisticated and complex than what would be needed if the source was available and could be installed)

As software radios become more common and cheaper (such as the $30 Baofeng uv-5r series that can transmit 136-174,400-480MHZ) the technical capability for people to stomp all over the radio spectrum becomes easier, but contrary to the fears of the 'communications professionals" (very similar to what you express), it has not resulted in mass jamming.

It's already possible to buy cellular repeaters (I have done so), which could also be misused to cause all sorts of problems.

Yes, there will always be people who are going to cause problems, outlawing things doesn't stop them, and frequently doesn't even slow them down (see C.B. amplifiers for one example)

I also think that it's inevitable, it will take a while still, but as it becomes cheaper to implement the radio protocol in more general purpose systems for less money, you will see people starting to do exactly that. You will also see the industry trying to block it and continuing to sell much more expensive versions of the equipment. There will be times when that expensive version is needed (usually in the middle of the big cities where there are more radios per square foot), but there is also a huge area where it will be 'good enough' and not cause noticeable problems.

SELinux on Android

Posted Aug 31, 2014 12:06 UTC (Sun) by yaap (subscriber, #71398) [Link]

I mostly agree with what you say, with comments.

Yes, there has been no mass jamming so far. But:

1) people playing with RF devices are a small minority;

2) it's very easy to underestimate the impact to others. When there's a problem and you shoot yourself in the foot, well you'll definitely notice it and then fix the problem. When you create a problem only for others it's a very different situation: it's easy to overlook. More so because the other people suffering from the issue typically won't understand the root cause or be able to trace the issue to its cause. They'll usually blame their device or network, and move along. This create a strong bias toward underestimating the created issues.

Because of the later, my recommendation to people playing with radio systems: have fun (I certainly can understand the interest ;), but please please be cautious for others. Try to be paranoid on what could go wrong before moving to the field.

An example: the SDR systems typically have no RF filtering, because there is no configurable filters of sufficient performance (yet). Without filter a device will create a lot of interference in surrounding frequencies and possibly jam other, unrelated systems. Not a problem in the lab at very low power, but you want to have proper filtering in the field.