Hacker News Reader

Comment by mirimir | Hacker News Reader

I really don't get the security model for smartphones. It seems horribly brittle. I mean, the fundamental protection is using apps from trusted sources, basically Google or Apple. Anything not trusted can't install, unless you've rooted the phone. And so old-school Windows-style malware is blocked.

However, when trusted apps are installed, they often demand all sorts of privileged access. And if they're malicious, there's no way to protect against them. Except that they get reported to Google/Apple and become unavailable. But that doesn't help people who already got pwned.

What am I missing?

View on HN

There are many layers of protection. For example with iOS every application runs in a restricted sandbox. It should be impossible for malicious application to access data from another application. There's old UNIX permissions system in place, so you can't replace iOS kernel with something else. Firmware checks kernel signature, so even if you've found a bug, you'll still have a hard time replacing a kernel. Very sensitive data is protected by a secure hardware chips. So even if you think that you got pwned, it doesn't mean the end of the world.

Malware persistence methods are also being cut off on iOS, so even with a 0-day, it is still a challenge to survive reboot.

A variant of the 'single non-root user' problem on Unix systems.

A non-root user (hopefully) can't root the system or rm -rf /root.

But everything interesting is stored in that user's home folder with implicit RW permissions anyway.

On Android apps just request everything. I imagine (without explicit knowledge) that an app given permissions could rewrite, erase, or pull down over the network contacts / photos / etc in the background.

I remember learning Unix on my school's big Unix system. Lots of talk about how important root was. I understood it from a system standpoint sure.

Yet I was confused, because as a user all I cared about was my stuff that was ... right there in a non root account.

As you say all the stuff I was concerned about was right there, but nobody talked about how important that was.

"If someone steals my laptop while I'm logged in, they can read my e-mail, take my money, and impersonate me to my friends... but at least they can't install drivers without my permission" https://xkcd.com/1200/

On a large multi user system there’s a big difference between “your stuff” and “everyone’s stuff” on a single user system like a phone - not so much.

The point is that your trust envelope extends to the authors of software, which are frequently not acting in the best interests of the user, and have their own goals and incentives (including competing goals with other software authors).

On my Linux systems, particularly under Debian, there's some assurance provided through the Debian Project, its guiding documents (social contract, constitution, policy), and debian developers. The project explicitly serves the users. This doesn't prevent bugs and occasional malice, but tends to tremendously reduce incentives for it.

Smartphones ... are a mess, and Android rather particularly so. I've suggested entirely rethinking how app development is performed, particularly for basic utilities, closer to the Debian model. I have little hope of this occurring.

Although you can leverage multiuser capable systems for more security by, say, using different user accounts for playing games and banking, or whatever.

> On Android apps just request everything

That was true up to Marshmallow (Android 6), when finer grained permissions were added.

Let me just update to it, oh wait....

Ah, finer-grained permissions, something I've seen on a BlackBerry in 2009.

I learned quite recently that Android was using one user ID per installed app, effectively isolating them one from another. However, I am not sure I understood what you meant by

> On Android apps just request everything

Well, this is as true as with any other operating system, isn't it?

Nowadays, I try to use F-droid as much as I can, applications there ask for reasonable permissions, and are open source, which makes it easier to trust them.

OK, but doesn't AppArmor protect against that?

And it looks like it's been ported to Android and iOS. But it's not default, I guess.

But neither is AppArmor in Linux. So why haven't we heard about apps stealing stuff from /home/user/? Is it just that distros do a better job of policing their repos? Or that the userbase is too small to attract malicious app developers?

> rm -rf /root

I don’t think this will do much besides blow away the root user's home directory, which probably doesn't have much in it anyway. But I get what you mean.

I think that he meant "rm -rf /" :)

Just in case, for a bit of fun:

http://www.marriedtothesea.com/041808/this-is-what-i-get.gif

How many years after Android permissions changed for the better will users who have never owned an Android phone complain about a problem that no longer exist.

Well, because there is this thing called lack of updates.

On German consumer shops, most "deal of the day" are still a mix of 4.4 and 5.1.

Until Google finally matches the permission model that iOS has had for years, and until the changes roll out to the majority of users instead of the few that own Pixel phones?

It has been there since Android 6.0.

Only available to around 60% of Android users.

It doesn't change the fact that it is there. :D

It is NOT there for at least 40% of android users.

«Anything not trusted can't install, unless you've rooted the phone»

Not true on Android. Apps can be installed from third party sources, without having to root the phone.

And on iOS, apps can restrict what permissions you can give them. Uber for instance allows only “no location” or “location all the time”, and does not allow “location while using the app”.

The Uber app now allows the "While using the app" option, fortunately. No longer need to remember to toggle it off.

Or, more accurately, iOS forced apps to support "Location while using", precisely because apps like Uber abused their permissions: https://www.engadget.com/2017/09/21/ios-11-uber-always-on-lo...

The main line of defense is the permissions system. If an app wants to access the user's camera, contacts, etc, it needs to come up with a good excuse for why or risk the user just tapping "deny". This seriously limits the damage a malicious app can do.

Aside from making the permissions system even _more_ fine-grained, I don't know how you'd make the situation much better than it already is.

> If an app wants to access the user's camera, contacts, etc, it needs to come up with a good excuse for why or risk the user just tapping "deny".

This isn't how many users use apps. For them any of these prompts are getting in the way of using the app, so they tap the button that would let them use the app quicker, without reading what the message said.

"Deny" will (usually) let you use the app just as quickly as "Accept". Permissions on iOS and Android are just-in-time and optional.

How exactly does tapping "Deny" on Snapchat's request to access the camera let you use the app?

That'd be silly, since it's obvious why Snapchat would want camera access. If you don't want to grant it access to your camera though, you _should_ be able to click "Deny" and still use the app to read messages.

Presumably you can still view things sent to you and look at the sponsored Snapchat stories.

Yes. I'm still hoping that I can one day run Linux on my phone, and iOS/Android apps in a sandbox.

iOS apps run in a sandbox

>trusted sources, basically Google or Apple.

I'd say open source apps are more trustworthy that Google or Apple.

Only if you inspect the source, understand the source, and build it yourself. Most people just check if an app is OSS and then install the binary version from the app store.

I've installed plenty of OSS apps but I've never built them myself and while I've looked at the source code, I have no way of knowing if what was in the repository was what got delivered.

For me, using FLO apps is more about freedom from lock-in.

You're right; I don't usually vet apps past the simple "is it FLO?" check (although I will do this before accepting a suspicious permission). However, I do keep a copy of the source of most of the apps I use. As a result, if it were to come out that the app is doing something shady, I could remove that part and keep enjoying the functionality of the app, whereas with a proprietary app I'd be SoL.

I also know that the developers know this, so they have an incentive not to do that stuff if they don't want a competing fork to take off. That is the main reason why I trust FLO apps more.

The viability of OSS is based on presumably someone within the community has or will check that connection. The risk of that highly encourages OSS owners to tell the truth in what they're doing.

Realistically though no one is checking, especially on smaller projects. You may be putting yourself at even higher risk since open source contributors are often not vetted as deeply as random employees.

Quite a lot of people do look into sources, actually. Quality of those checks, and how much do they cover in the end - that is the question. But it is better than nothing, and absolute majority of closed source apps offers you exactly nothing in this regard. Surely, opensourced code is not inherently safe, but with time passing, while userbase is big enough, it gets some attention, which means advantage on a scale of probabilities.

There are actually two gains from having the source in the open. One, that you can inspect the source - and in case of popular applications, even if you don't, you can be sure that someone already had and would speak up if they noticed anything off.

But the second one is, if there really is something off, there's an unambiguous proof of it - you can point directly at the implementation! And with luck, even at the particular person or organization responsible.

> and in case of popular applications, even if you don't, you can be sure that someone already had and would speak up if they noticed anything off.

You can’t be sure of that at all. This isn’t just an epistemological point either - people are still routinely finding vulnerabilities in the most widely used open source software that were introduced two decades ago. This is despite extremely lucrative incentives for finding them. In many cases it’s because no one bothered to look; in other cases it’s because the numerous (ostensibly qualified) people who looked weren’t capable of finding them.

Open source software is a red herring for security. Its benefits are vastly overstated. You gain an incremental improvement in the theoretical ease of review, but this almost always comes at the cost of the overseeing organization having fewer resources to devote to security because its more difficult and uncommon to monetize open source software.

Overall I’d say open source software is at best weakly correlated with improved security posture. As it turns out most people don’t inspect their code before running it, and this includes those who fully buy into the many eyes aphorism. Of those who do inspect it, approximately all of them are woefully incapable of identifying real vulnerabilities beyond all but the lowest hanging fruit. Those who remain are typically extremely well paid for their expertise and will only look at software which features a sizable bounty.

Unfortunately most open source software, including widely used open source software, does not have a bug bounty and isn’t on e.g. Google Project Zero’s radar.

> Overall I’d say open source software is at best weakly correlated with improved security posture. As it turns out most people don’t inspect their code before running it, and this includes those who fully buy into the many eyes aphorism.

I and sure many others do look at the code, even for languages that I don't know. I often end up removing functionality that I don't need (less unnecessary code often means less security vulnerabilities) or patch it slightly to suit my needs better. For proprietary code I don't have that luxury, the other issue is that a lot of free-ware software tracks you and won't give you any opt-out options.

It's not weakly correlated if let's say I can remove finger protocol and get direct security benefits. Things like that make outdated proprietary binaries unusable from security perspective.

> approximately all of them are woefully incapable of identifying real vulnerabilities beyond all but the lowest hanging fruit.

Sure, but more often that not it is those that will get exploited and open source makes it damn easy to fix. Bug bounty shouldn't be the only incentive to make the software more secure.

Vulnerabilities are everywhere, let's not be mistaken here. Closed source is full of them too, you just don't have a chance to know it in most cases. The fact that bugs are found, and publicly announced does, in fact, prove that the model works. That said, I agree that "opensource" label is overadvertised, and many people started to see it as a synonym to "safe" which is definitely a grave mistake. But dismissing its small advantages, just because someone believes they are big doesn't make sense too.

I didn’t dismiss its small advantages, I put them in context so it would be clear that they’re small.

I guess that the argument is that: 1) sources are available, so anyone can look at them; and 2) that if sources and binaries are in a distro's repo, someone knowledgeable must have looked at them. Also, some repos (Debian and ?) are signed, so you know that you're getting authentic binaries.

But even with that, it's taken years to find some serious bugs.

Reply on news.ycombinator.com