SELinux on Android

Posted Aug 28, 2014 13:35 UTC (Thu) by brugolsky (guest, #28)
Parent article: SELinux on Android

While I'm glad to see this being done, the Linux kernel is as awfully bloated "TCB". Is work underway to also incorporate the most useful bits of Grsecurity?

Tightening security is also a dual-edged sword; if devices remain locked and under the control of the manufacturer or telco carrier, it will make mainstream consumer devices more difficult to root and use for our own purposes. Beware of remote attestation protocols coming next.

I hope that taking security seriously also means that on the hardware side, Google and the device manufacturers will push to make the baseband OS untrusted, and eliminate baseband access to sensors from the hardware designs, despite the pushback that they will no doubt receive from the TLAs. Until then, the only secure "smartphone" is one with a physically separate modem communicating over an auditable wire protocol such as USB.

to post comments

SELinux on Android

Posted Aug 28, 2014 17:16 UTC (Thu) by drag (guest, #31333) [Link] (3 responses)

> While I'm glad to see this being done, the Linux kernel is as awfully bloated "TCB". Is work underway to also incorporate the most useful bits of Grsecurity?

I don't think it would plausible to do this. Gresecurity has it's own role based mechanism and approach to Linux security that is separate from what you'd get with LSM modules like SELinux.

The upshot, though, is that since Gresecurity is largely compatible with SELinux you should be able to mesh these things together if you really wanted to.

> Tightening security is also a dual-edged sword; if devices remain locked and under the control of the manufacturer or telco carrier, it will make mainstream consumer devices more difficult to root and use for our own purposes.

There are phones on the market that are purposely left open (relatively) by their manufacturers. The key is really to steer people towards those devices.

Besides the security situations, Android users can benefit massively from this sort of approach. Many people I know who does not have a 'rooted' phone and the ability to install their own firmwares tends to end up with a unusable device after a couple years, while my phone (and others in similar positions) is faster and better behaved then it was when it was new.

> Until then, the only secure "smartphone" is one with a physically separate modem communicating over an auditable wire protocol such as USB.

The radio is the probably most important part of the 'smartphone', from a security perspective, unfortunately. If not the most, it's certainly very important. It can intercept and manipulate any of the traffic going in and out of the phone, as well as publishing information about the user and the user's location and such things. It has it's own processor and operating system-like environment.

What would be ideal would be to have a 'dumb radio' similar to how most people ended up with 'dumb modems' towards the end of the dial-up internet era. (aka winmodem/linmodem/etc). In this way the hardware is rather minimal and instead of using the processor and firmware built into the radio to manage connections you use the main cpu and use a open source kernel driver to do most of the 'heavy lifting'. Essentially be a 'software defined radio' type setup.

Now, of course, this approach has a large number of problems. Besides technical issues with battery life, reliability, and so on and so forth... The government is not going to want to allow people to know what is going on with their phone's radio.

Right now government surveillance techniques at important events (riots, protests, public appearances of officials) involve setting up fake/temporary cellular radio towers and then sending commands to phone's and phone's radios to disable power management features and report continuously on the identities and locations of people in the vicinity of the 'event'. They don't want to loosen any potential FCC rules to allow people to control their own devices in a way that could potentially defeat that sort of thing. Luckily 'dumb radios' will probably end up much cheaper then full blown radios over a dedicated usb (or whatever) style connection and the economics of technology has a way of overruling the regulator's concerns.. thank goodness.

Now I don't know how realistic 'software radios' for cellular communication actually is, but I am just suggesting that it's the better approach when thinking about things security-wise.

SELinux on Android

Posted Aug 28, 2014 18:51 UTC (Thu) by brugolsky (guest, #28) [Link] (2 responses)

Some random thoughts in reply while I'm waiting for this compile to finish...

Grsecurity is much more than RBAC; the kernel hardening aspects come with some (usually minor) performance penalties, which might be an issue on battery-operated devices, but I'm willing to trade some battery life for better protection against 0days.

I'm fairly optimistic that unlocked phones and tablets will be remain available. We're getting to the point where the functionality of devices several generations old is still perfectly usable.

For USAians, it would be nice if our Congress got rid of the DMCA and demanded more openness for devices, perhaps arguing that device owners have a right to engage in self-service once a device is abandoned by the manufacturer (no more updates). [Though I can hear the wails of protest by lobbyists that the world economy will collapse if the "new shiny" can't be forced upon consumers every 2-3 years.] This might go hand-in-hand with Dan Geer's proposal to hold vendors liable for security, and only allow them to disclaim liability only via openness.

As for softmodems, Nvidia acquired Icera and now uses the Icera LTE softmodem running on the baseband processor of the Tegra 4i. Whether we'll ever get to a place where similar code is, if not open source, at least wrapped in a sandbox with verifiable inputs and outputs, is difficult to say, though I think it unlikely.

If people want to avoid having their communications monitored or blocked at protests, and other events, then they need to ditch telco service and use WiFi with random MACs on their rooted devices. If cruise lines can supply passengers with messaging apps that work on-board, surely we can put better technology in the hands of protesters, particularly since we have mesh networking already available in the Linux networking stack. Sure, then WiFi jammers will be deployed, and the response will eventually require full-on SDR.

Afterwards, needless to say, people will get in their cars all amped up and discuss the whole event, while OnStar or your Android or Tizen-based IVI relays unique IDs and perhaps whole conversations to the interested parties. :-/

SELinux on Android

Posted Sep 1, 2014 14:44 UTC (Mon) by raven667 (subscriber, #5198) [Link] (1 responses)

> I'm willing to trade some battery life for better protection against 0days

You are probably in a tiny minority with that opinion, battery life is a sell-able feature on phones and anything which reduces it is going to be perceived as a negative, you will get beaten up in the marketplace by the vendor without security but one more hour of battery life.

I too would love better protections by default but as you can see from the trends of past history only a small fraction are willing to pay any performance cost for security, those people are the current grsecurity customer base 8-)

SELinux on Android

Posted Sep 1, 2014 16:11 UTC (Mon) by spender (guest, #23067) [Link]

Yes, because it seems Samsung and other vendors who have adopted SELinux with its marginal benefit and 10% performance hit are being pummeled in the market. With users reporting KNOX using up to 62% of their battery (http://forums.androidcentral.com/samsung-safe-knox/326105..., http://forums.androidcentral.com/samsung-safe-knox/304515..., http://forums.androidcentral.com/samsung-galaxy-note-2/35..., etc) Or the ones that have taken on the performance hit of SSP on ARM with its nonexistent security benefit.

In fact, we just got an email within the past hour from a company that's enabled basically all grsecurity features from https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecur... on a system processing ~50 emails a second through anti-virus and anti-spam at only a 14% performance hit. The kernel they were running had full memory sanitization on free enabled, which caught a use-after-free bug in the upstream netfilter code.

I'm leaning towards you being the small fraction, and this just being one big straw man.

-Brad

SELinux on Android

Posted Aug 29, 2014 14:08 UTC (Fri) by yaap (subscriber, #71398) [Link] (8 responses)

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.

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.