SELinux on Android
One of the more surprising bits from this year's Linux Security Summit (LSS) was the progress that has been made with SELinux on Android. The project has been around for some time now and has made some impressive strides over the years. SELinux developer Stephen Smalley presented the current status of Security Enhancements for Android (SE Android) project, along with what is coming in the next Android release.
Smalley works for the US National Security Agency (NSA), but not for the signals intelligence (i.e. communication gathering) branch he was quick to point out. The job for his part of the NSA is to find ways to protect information held by the government. SELinux was originally developed by the NSA for just that purpose; extending that to work on phones is another piece of the puzzle.
![[Stephen Smalley]](https://static.lwn.net/images/2014/lss-smalley-sm.jpg)
At around the time of the 2013 LSS in September, the Samsung Galaxy S4 phone was shipping with SELinux and the official Android 4.3 ("Jelly Bean") included it, though both were in permissive mode, he said. That was a "baby step", but after that, 4.3 updates to the S4 and other Samsung devices put SELinux into enforcing mode, as did the Android 4.4 ("KitKat") release.
Smalley's presentation looked at the Android Trusted Computing Base (TCB) and how SELinux and other techniques are being used to protect it. All of that work has been done in public by the NSA, Google, and others—in the Android Open Source Project (AOSP) master branch. He said that he would start with what was in Android 4.4, before moving on to what is expected in the upcoming Android "L" release.
Android TCB
The Android TCB consists of the totality of the hardware and software that makes up the system. For the purposes of his talk, though, Smalley said that he would just be looking at the full Android software stack. The Linux kernel is the base of the Android TCB, but user-space code that is privileged in various ways also requires protection.
There is a loose hierarchy that runs from the kernel through the root daemons and non-root daemons (which have some capabilities) to the privileged apps that are run from /system/priv-app. It is a layering of the privileges, going from most trusted to least, he said, though the layering is "not clean". There is no easy separation between what is trusted and what isn't, nor any real attempt to determine what the applications and daemons need to be trusted to do.
Prior to adding SELinux to Android, some kernel hardening and other techniques had been applied to Android. That included setting various kernel parameters (e.g. mmap_min_addr, kptr_restrict) and using kernel features that help block privilege escalation (e.g. NOSUID, NO_NEW_PRIVS). There were also efforts to minimize the number of full-root daemons running in the system and to reduce the capability set of others. In addition, techniques to reduce the exploitability of applications like address-space layout randomization (ASLR), no-execute data sections, FORTIFY_SOURCE, and so on, were applied.
Android 4.4 was the first Google release to ship with SELinux in enforcing mode. It focused on protecting four full-root daemons (installd, netd, vold, and zygote). The intent was to protect the daemons from misuse and to contain the damage that any exploit could do. One example of the kinds of exploits that SELinux can prevent on Android is a local root vulnerability in vold from 2010—fixed in 4.4.3—that was prevented by SELinux.
Unlike standard Linux distributions, SELinux in enforcing mode is mandatory on Android 4.4 (and beyond) systems. The Android compatibility definition and tests both require SELinux. That is an advantage, Smalley said, because other parts of the system can rely on the presence of SELinux.
Another difference between Android and regular distributions is that there is no generic unconfined domain in the Android SELinux policy. Specific domains can be marked with an unconfineddomain attribute, but that is not exactly the same thing. Domains that are marked that way are not completely unrestricted by the policy, as unconfined domains are in other distributions.
Post 4.4, the strategy is to shrink the set of daemons that run with the unconfineddomain attribute. But OEMs may still add daemons with that attribute, so, in parallel, there is an effort to reduce the permissions allowed to those processes. There will also be targeted improvements to the confined domains to further reduce their ability to wreak havoc if they get compromised.
For Android 4.4, only the 4 daemons mentioned (out of a total of 47) are confined. But the Android L developer preview confines 49 out of 61 daemons and privileged apps; it also adds all third-party apps to the confined set. The current AOSP master branch, which is what Smalley expects will end up in the L release, has 62 of 65 daemons and applications confined.
Protections from the policy
Smalley then switched gears to talk about the protections that are embodied in the Android SELinux policies. In order to try to protect the kernel, there are a number of actions the policies prevent, including any process mapping low memory and reading or writing /dev/kmem and /dev/mem. Only the init process can modify process security settings (e.g. mmap_min_addr) or load SELinux policy. No domain can switch SELinux to permissive mode. All of those restrictions apply to "unconfined" domains as well.
Loadable kernel modules are supported on some Android devices, though the Nexus devices turn off CONFIG_MODULES. Only the system_server is allowed to load modules for those devices that do support it; that is done to support loading a wireless driver. In the future, some of the restrictions on module loading that Kees Cook has added may be employed on Android, Smalley said.
The user-mode helpers for hotplug have traditionally been a way to subvert the kernel by assigning an attacker-controlled helper to a particular event, then causing that event to occur. That is prevented on Android by only allowing init to configure the helpers and to only allow helpers to be executed from the root filesystem or /system.
The policies also seek to protect the integrity of files on an Android system. The /system partition has always been mounted read-only, but attacks would simply remount it read-write. The policies now lock down which processes can mount and remount. In addition, write access to /system is only allowed to the recovery process, which is only available in recovery images. Beyond that, writing to block devices, raw I/O, and mknod() are also locked down, even for objects with the unconfineddomain attribute.
Access to ptrace() has also been limited. Only the debuggerd process is allowed to ptrace other domains. Most domains have no ptrace access even within their own domain, and that includes the unconfined domains. Certain sensitive domains (e.g. init, keystore, app-to-non-app ptrace) are further protected with "neverallow" rules in the policy; those prevent any policy change from (mistakenly) overriding them.
There has been a lot of effort to ensure that there is a bare minimum that is both writable and executable. Rootfs files cannot be written, while /system can only be written from recovery—most domains can only execute files from one or the other. Except for Dalvik processes, domains cannot have executable anonymous mappings, nor change file mappings to be executable. Once again, these protections are also active for unconfined domains.
Protections against both symbolic link attacks and malicious socket IPC have been added. No domains can read symbolic links created by apps or the shell. Also, netlink sockets and sockets opened by daemons cannot be accessed by apps or the shell.
It is not just system data that is being protected, either, as there are restrictions on the /data (app data) partition as well. The original 4.4 policy allowed installd and system_server to have largely unrestricted write access to /data, but that has been tightened up considerably in the AOSP master branch. In addition, even more protections have been placed on specific security-critical data files (e.g. /data/property, the system property store, and /data/misc/keystore, the certificate and key store).
There is an additional set of restrictions on the increasingly badly named "unconfined" domain. No process operations (e.g. signals) can be made to other domains and those processes cannot execute other programs without transitioning to some other domain. Those processes also have no internet access, no syslog access, and no audit access.
Protecting the policy
But what policy takes away, it can also give back, Smalley said. An OEM can "remove the goodness we baked in". Part of preventing that is the neverallow rules, but those can simply be commented out by OEMs. In order for devices to pass the compatibility test suite, however, there are two SELinux tests that must be passed. One of those ensures that the neverallow rules are still present through testing—without inspecting the policy itself.
But the project is not just applying SELinux policy. There has been a concerted effort to go beyond just creating policy to "improve the state of security on Android", he said. The need for certain capabilities has been removed from some daemons, others have been de-privileged entirely. Descriptor leaks across fork()/exec() have been found and eliminated as well. Some of those fixes have made their way back to the regular distributions to help provide better security throughout the Linux ecosystem.
SELinux has always focused on more than just the kernel, he said. It can (and does) restrict user-space programs. In 4.4, that was applied to the property service and zygote; in AOSP master that has been extended further. In addition, the hardcoded UID-based access control lists have been replaced with SELinux policy.
There have been some practical challenges in bringing SELinux to Android. Upgrades from non-SELinux devices with unlabeled filesystems required some work. Upgrading to newer policies with different labels had similar challenges. There have been other labeling issues as well, he said.
Next up are projects like simplifying the process of bringing up new devices with SELinux support, applying isolation and sandboxing features to apps, hardening the multi-user boundary in Android, and more. He encouraged anyone interested to check out the home page and the mailing list. Smalley's slides [PDF] are also available.
| Index entries for this article | |
|---|---|
| Security | Android |
| Security | Linux kernel |
| Security | Security Enhanced Linux (SELinux) |
| Conference | Linux Security Summit/2014 |
Posted Aug 28, 2014 13:35 UTC (Thu)
by brugolsky (guest, #28)
[Link] (13 responses)
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.
Posted Aug 28, 2014 17:16 UTC (Thu)
by drag (guest, #31333)
[Link] (3 responses)
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.
Posted Aug 28, 2014 18:51 UTC (Thu)
by brugolsky (guest, #28)
[Link] (2 responses)
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. :-/
Posted Sep 1, 2014 14:44 UTC (Mon)
by raven667 (subscriber, #5198)
[Link] (1 responses)
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-)
Posted Sep 1, 2014 16:11 UTC (Mon)
by spender (guest, #23067)
[Link]
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
Posted Aug 29, 2014 14:08 UTC (Fri)
by yaap (subscriber, #71398)
[Link] (8 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.
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.
Posted Aug 29, 2014 22:12 UTC (Fri)
by brugolsky (guest, #28)
[Link] (2 responses)
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.
Posted Aug 30, 2014 10:18 UTC (Sat)
by yaap (subscriber, #71398)
[Link] (1 responses)
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.
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 ;)
Posted Aug 30, 2014 13:56 UTC (Sat)
by brugolsky (guest, #28)
[Link]
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.
Posted Aug 30, 2014 20:58 UTC (Sat)
by intgr (subscriber, #39733)
[Link] (4 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.
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.
Posted Aug 30, 2014 21:19 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
> Nice straw man there.
Posted Aug 31, 2014 10:45 UTC (Sun)
by yaap (subscriber, #71398)
[Link] (2 responses)
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".
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
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.
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.
Posted Aug 31, 2014 11:30 UTC (Sun)
by dlang (guest, #313)
[Link] (1 responses)
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.
Posted Aug 31, 2014 12:06 UTC (Sun)
by yaap (subscriber, #71398)
[Link]
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.
SELinux on Android
SELinux on Android
Some random thoughts in reply while I'm waiting for this compile to finish...
SELinux on Android
SELinux on Android
SELinux on Android
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."
SELinux on Android
SELinux on Android
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.
SELinux on Android
SELinux on Android
SELinux on Android
So can you design a spec that allows fully untrusted devices and provides a better level of service than LTE?
It's not. A misbehaving phone WILL degrade service for other cell phone tower clients.
SELinux on Android
> developers are too incompetent to work on something as complex as X.
> Usually to be proven wrong months or years later.
So what I mean is that getting to a real product is not possible at an amateur level: you need significant funding.
>> capacity just because he boosted his phone transmit power because
>> it's "l33t"
>
> Nice straw man there.
This is why I believe cellular networks implementation will remain locked.
SELinux on Android
SELinux on Android