Hacker News Reader

> my iPhone is more secure than linux for the same reason

The phrase "more secure" doesn't mean anything, I wish it wasn't used.

One needs to talk about the threat model(s) you care about and how a particular solution addresses them (or not). Any given solution can be both more secure and less secure than an alternative, depending on what threat models you care about. Which may well be different than the threat models someone else cares about.

If you unconditionally trust Apple and all government agencies which have power over Apple (e.g. NSLs) then one could say iOS has a more secure file access model than Linux. But that's a big if. Personally I could never trust a closed source proprietary solution.

> The phrase "more secure" doesn't mean anything

Fair point. I'll elaborate:

The linux (UNIX) security model is designed to protect users from other (potentially malicious) users on the same computer. The system as a whole is designed such that a malicious (or incompetent) user can't make the system as a whole stop working. The system is more important than any particular users' data.

Software is assumed to be correct. Any program a user runs inherits the full permissions of that user.

There's some problems:

1. Computers aren't often shared between mutually-untrusted people.

2. My data is much more precious than my computer itself.

3. Malicious software is everywhere. Every time I install a package some stranger wrote on npm or Cargo, I implicitly give it full access to all my data and my entire network.

So, linux protects me from things I don't need protections from (other users) and doesn't protect me from things I do need protection from (malicious code).

> One needs to talk about the threat model(s) you care about and how a particular solution addresses them (or not).

The threat model for malicious code is, I install an apt package / cargo crate / npm package / intellij or vscode extension and the package contains code which either exfiltrates my data over the internet, or cryptolockers it.

iOS (and Android?) don't let code like this run, since software can only (by default) access the data that it itself has created. Ransomware attacks are trivial on linux and impossible on iOS.

Its much more likely that me or my family suffers from a keylogger or ransomware attack than we suffer as a result of government intrusion into our digital lives. I'm one bad npm install away from having all my data stolen, and it terrifies me.

> Its much more likely that me or my family suffers from a keylogger or ransomware attack than we suffer as a result of government intrusion into our digital lives.

Are you sure? How would you know? We can't know how many people the government blackmails with data taken from their iphones, because it's illegal to publish information about them doing so, whereas ransomware attacks are widely publicised.

As key component of threat modelling is risk management and modelling.

I would counter the “government blackmailing people” by questioning the risk this poses to me as an individual. As much as we’d like to imagine it, and as much as it can often times feel like it, we don’t live in a Kafkaesque society, by and large, as the significant majority of us are of zero interest and have little of anything worth blackmailing.

It seems to be routine for rape complainants to have to hand over their phone and have their messages scrutinized, as a pre-requisite to proceeding with an investigation. That is a form of government blackmail.

I disagree entirely with that notion. If you make a serious accusation, you must be prepared to hand over the necessary evidence to assist the investigation and get a conviction. I'll also say that at that point, the risk has changed dramatically. Risk isn't a static thing. It needs to be assessed regularly and evaluated when your threat model changes. Your exposure to risk is still a factor.

> hand over the necessary evidence

Of course. But you shouldn't have to spill your guts about your entire life (I understand that young folk nowadays life their lives in Instagram selfies).

And more to the point, the first step for the policemen investigating a rape complaint should be to investigate the complaint, not the complainant. If the investigation of the complaint raises questions about the complainant, then there might be grounds for seizing the complainant's device. But they can't make device seizure a pre-requisite for doing their job.

This is rubbish. The police investigate the claim and based on the results of the investigation, the prosecutor decides whether charges can be laid. The prosecutor!

Not the police!

What? Where is this routine? Where do you live? What if you don't have a phone? Why would you give your phone to the police in this situation instead of the prosecutor?

Which government? What level? My god, who told you this thing? For what other crimes is this policy enforced?

The landscape of security switched from the computer to the user.

As user you need to become root in a way or another to install a system program or something that affects the system as a whole. And you are aware that you are doing something that affects the system as a whole. The security was meant for multiuser environments, the computers were shared in a way or another.

But what matters now about that computer (specially when you are the single user of it) is your user, your data, your credentials, your network access, etc, all that you as user (and app you run) can access, or modify. Viruses and malware in general used to be system threats, but it is enough to be user threats now.

Things are moving to containerized in a way or another applications (docker, snaps, whatever do iOS and Android with that, etc), with limited access to your data, credentials and so on.

> 3. Malicious software is everywhere. Every time I install a package some stranger wrote on npm or Cargo, I implicitly give it full access to all my data and my entire network.

This particular case wouldn't really be prevented by an Android/iOS-type security model, I think? That package will be part of the program you're writing, and chances are that program requires more than the bare-minimum access.

That said, it's not extraordinarily difficult to lock this down, if you really want to. Docker is common, but more traditional tools work as well (e.g. running your program as its own user, maybe in a chroot), and/or using cgroups directly.

This applies even more with things like VSCode extensions, which typically run inside the VSCode process, and without filesystem access VSCode is pretty useless.

Linux has lots of protective measures outside of just user isolation. There's capabilities, namespaces, cgroups, seccomp, landlock, selinux, apparmor.

The difference is Linux gives the owner of the machine (for better or worse) decide what to do here. There are distros that try to force you into a more secure posture (Qubes), though.

This is interesting to me. Do you know if Windows OS provides similar features? The ideal for corporate environments (outside of dev) would be desktops that operate in the same way as iOS.

In theory, yes.

https://learn.microsoft.com/en-us/windows/security/threat-pr...

The practical application of this is a different story.

But there is a problem with trying to compare this to things like iOS and phones. Phones are strongly application based, it is completely common to have your data locked up in an app and getting to another app has varying levels of difficulty.

In Windows it is much more common for data to be file based, and applications can be launched and ran by clicking the file. File security is based on the user, so typically any application can access files owned by the same user. A huge portion of workflows would break if this were not the case.

> Chrome pioneered moving each tab to a separate process with full sandbox isolation.

I don't think it was done for security. Before chrome where all tabs ran in single process it was common for a bad site to stall your whole browser. Separating it into single processes was basically admission that, yes, web browser sucks, so the best we can do is give you ability to kill a part of it when it misbehaves.

It was done for both reasons. Here's the Google Chrome comic book talking about it:

https://www.google.com/googlebooks/chrome/small_04.html

Another benefit they cite is reduced memory fragmentation. Because each tab lives in its own memory space, when the tab closes the OS can reclaim all of its memory. Presumably you'd still get framentation, but the OS is probably better able to handle that long term than jemalloc. Clever!

The consumer OS lockdown side does have a lot of interesting points. One I also thought of - I'd bet that, even if we reject web browsers, basically every user's "30 most used apps" has at least one that has a plugin system that loads unverified code, or runs macros in some kind of interpreter that is or may later be proved to be exploitable, or parses structured data from files that can't be trusted using non-memory-safe code, or some other thing I haven't thought of.

> The first time you see dialogues asking "Do you allow this app to open files in your Documents folder" its sort of annoying, but its a fantastic idea.

It’s not a great idea because it’s annoying. It is not really useful in its current incarnation to most people.

Further, banner/modal fatigue is a real thing. People will just ignore and click through.

This is because the dialogs have gotten rid of the disclosure arrows that gave path information and metadata about the binary. Also, executables used to have names consistent with the naming conventions on the platform. Now you just get dialogs with some cryptic name, and a one line manpage.