Hacker News new | ask | show | jobs
by Chris_Newton 4172 days ago
This seems like yet another good example of why robust application-level access control would be a helpful thing to build into modern operating systems, in addition to the typical user-based controls. This may have been both a rookie mistake and a regrettable failure of code review processes, but in any case it simply shouldn’t be possible for an application running on a modern system to wipe out all user data without warning in such a sweeping way.

I have often made this argument in the context of sandboxing communications software like browsers and e-mail clients, where it is relatively unusual to need access to local files except for their own data. In that context, restricting access to other parts of the filesystem unless explicitly approved would be a useful defence against security vulnerabilities being exploited by data from remote sources. It’s hard to encrypt someone’s data and hold it for ransom or to upload sensitive documents if your malware-infected process gets killed the moment it starts poking around where it has no business being.

More generally, I see no reason that we shouldn’t limit applications’ access to any system by default, following the basic security principle of least privilege. We have useful access control lists based on concepts of ownership by users and groups and reserving different parts of the filesystem for different people. Why can’t we also have something analogous where different files or other system resources are only accessible to applications that have been approved for that access?

8 comments

Isn't this the basic idea behind the sandbox in OS X?

I think OS X (and mobile app development in general) shows both that this is great in theory and a net improvement over not having it, but that there are some common pitfalls to address.

First, there are a handful of apps where this model doesn't work so well -- e.g. text editors, FTP clients, etc. So you're inconveniencing quite a few legit apps which need broader access.

Second, as a corollary of the first, that means you're going to have a lot of apps that legitimately need to ask users to approve broader access. And as the number of apps asking for approval goes up, the more likely users are to simply ignore the warning and approve all. This is especially problematic since we can assume the average user is a good judge of which apps need which access.

Edit: One way of reducing user acceptance fatigue might to introduce greater granularity into the requested permissions and then tier the permissions requested -- e.g. commonly asked vs. uncommon. E.g. an app may legitimately need permission to write to any file in your home directory, but it's highly unlikely they'll need permission to write to more than X number of files per second. Or at least they shouldn't be able to do so without the OS throwing up lots of warnings outside of the app.

Sandboxed applications in OS X can read/write to arbitrary locations if they use the system Open/Save dialogs to ask the user about those files (after opting into sandboxing, of course). See here [1].

For files and folders the user cares and knows about (documents, projects, etc), this shouldn't be a problem. For files the user doesn't care about (caches, configuration), you can just leave them in your sandboxed container.

[1] https://developer.apple.com/library/mac/documentation/Securi...

Lots of applications (like Emacs and vim) don't use the system file dialogs though. It'd be nice to preserve old-fashioned file access for them.
But these are applications for knowledgeable users I think which is not the type of users the GGP is talking about. For these it might be ok to ask for permission. Or to grant it automatically if you are root or sudo'ed. And many use cases could get around with allowing silently to write if the file has been previously been opened by the same application.
I will not use a system that pops up some kind of UAC-like approval dialog for every call Emacs makes to open(2).
The OS X sandbox doesn't work that way. If you do "Open" and pick the root of your hard drive one time, the application gets and keeps access to the entire drive.

Disk scanning programs like DaisyDisk from the app store have to make you do this before they can get any information about disk usage.

Well, of course, sandboxing is opt-in, and there are still lots of programs out there that don't use them.

I'm not sure Emacs or vim, as an example, would ever be able to be sandboxed from the filesystem.

Aquamacs seems to use the system dialogs with no trouble.
Sure, File->Open invokes the system dialog. Not C-x C-f. Not automatic filename history, or tags table traversal, or perusal of the M-x grep results buffer, and so on. Emacs is a generic runtime environment and needs generic file access.
It helps if you assume good faith of the application developer. Part of developing an application should be defining what permissions you need at install time. This won't help against legitimate malice, but it would defend against this type of mistake, and (if it is configured such that the app cannot change its own permissions) will also mitigate any exploit of the app.
Is it really a net improvement? There are a number of developers out there that have pulled out of the app store (off the top of my head, Atlassian for SourceTree, and Panic for Transmit) because the sandbox restrictions would force them to remove functionality from their applications.

As far as Apple's implementation goes, sandboxes are for kids, not adults that need to get work done.

SourceTree and Transmit need to stomp all over directories to get things done. Yes, it's useful. But it's not common for applications to need that kind of access. The sandbox seems to work fine for the other 99% of applications. I think Apple even uses the sandbox heavily for their own apps, check ~/Library/Containers next time you use an OS X system.

The only complaint here is about the app store, sandboxing is wonderful.

Steam is another category of application which wants to write to directories used by other applications...
Why? In my Windows VM, all Steam data lives in C:\Program Files\Steam. (Plus start menu entries etc.)
Steam manages game installation and updates; those games are themselves separate applications. That's what I was referring to.
Why not have Apple require apps to run usefully with just basic permissions? Anything beyond access to own files is optional. This could certainly be gamed, but scrupulous app authors could gain a ton of trust from playing ball.
This is essentially already the case as Mac App Store apps must be sandboxed. This works fine for a lot of apps, but has presented issues for many prominent developers. (e.g. Panic had a fairly difficult time adapting Coda to the sandbox, if I recall correctly.)
Like AppArmor, or SELinux, or any of the other applications which have their hooks in the LSM? They do a fantastic job of this, if you can figure out how to use them.

The truth is that they are too hard for even your average Sysadmin to configure & manage, let alone your average desktop user.

setenforce=1 (yeah, right).

Yes, and I also agree that there are substantial unsolved problems in making such fine-grained systems practically useful for non-expert users.

I’d like to see the industry moving in that general direction, though. Even a much simpler model could bring real benefits relative to the status quo, where in application terms our current security model is analogous to everything being root.

Broadly I agree; the original work on access control assumed that it was users who might be untrustworthy and programs were safe, in a "classified documents" context.

However, applying program-level access control is very un-UNIX. How do you compose multiple programs with different security regimes? This bug happened because the "steam" program called the "rm" program via the "shell" program. Inheriting capabilities mostly solves this, but we're familiar with how hard selinux is to use as a result and it still doesn't save the user from command line typos.

I think it's time to make a stronger case for time-reversible filesystems. Accidental deletion matters less if you can just get in your time machine.

You are describing a problem that has been solved several times over. Blame steam, the distro devs, or the user for not implementing one of the many long existing solutions: chroot [0].

[0] http://en.wikipedia.org/wiki/Chroot

If a problem has been solved several times over, that's a sign that it has never really been solved. If there's a thing that most apps should do, then doing it should be the default, and avoiding the default should be the thing that takes work.
So what, your definition of a solved problem is one that never occurs again due to uniform implementation of countermeasures? That isn't realistic. That is like saying that plane geometry isn't a solved problem because people are still walking around having not read Euclid's "Elements", doing geometry wrong.
For the record, plane geometry wasn't solved by Euclid's "Elements"; the conjecture about the 5th postulate remained open for a substantial amount of time, and other axioms were introduced when it was pointed out that Euclid's work relied on numerous implied axioms.
Damn it. Well at least I can still trust in Plato's theory of forms.
Just because you've invented solar panels does not mean that you've solved the energy crisis. Sometimes the implementation of technology is just as inventive as the invention itself.
lol, ok lets break this down Barney style:

Converting sunlight to electricity is a solved problem. The "energy crisis" remains unsolved.

Jailing processes is a solved problem. Preventing users from shooting themselves in the foot remains unsolved.

Now let us reexamine the post:

> ...would be a helpful thing to build into modern operating systems...

Already built in.

> Why can’t we also have something analogous where different files or other system resources are only accessible to applications that have been approved for that access?

We do. Solved problem. Now if we want to prevent users from shooting themselves, that is a different problem.

That last paragraph sure makes it sound like the writer is unaware of these solution's existence... but let us suppose that he knows about them and is coming at it from your perspective. In that case I agree, we don't have a solution in place - and I'd love to see one in common use. I'd think you'd be able to implement such a system through package management for the majority of software, an added chroot step. That is why I included distro and application devs in those that share blame for the problem. Users are also included, to a smaller degree, because this is a known problem with a known solution.

I’m well aware of strategies using chroot, virtual machines, and the like. These are useful tools up to a point, but a long way short of what I would ideally like to see. For example, they restrict access at a very coarse level compared to the kinds of user/group/ACL models we use in many other contexts. By their nature, they also do not admit convenient ways to break out of the jail with the user’s explicit consent. Once you get beyond individual applications with their own dedicated file types and consider more generic cases like text editors working on text files that are likely to exist throughout a filesystem, this lack of flexibility is a serious limitation. Another key distinction is that chroot and the like are voluntary mechanisms, usually off by default and therefore not completely enforced by the OS.

Some systems mentioned in this HN discussion are closer to the kind of model I had in mind. As other posters have pointed out, the difficulty is how you structure a system so that it is reasonably effective by default but still usable by non-experts. I believe we could achieve this — or at least get much closer than the typical security models we use at the moment — but it will surely take a lot more thought and experimentation than we have attempted as an industry so far. Microsoft’s UAC mechanism makes an interesting case study here: it was fundamentally a reasonable idea, but the first implementation proved too intrusive for average users to tolerate and lost much of its effectiveness as a result.

Role-based and other access control mechanisms unfortunately come off all too frequently as bolted on and arcane hacks.

The real issue lies in the fact that the file system resides in a global namespace, when it shouldn't. Much like each process has its own environment variables, so should it have its own namespace. Linux does support so-called "mount namespaces" now, but once again they're not inherent parts of the system, but have to be tacked on through explicit unshares, and thus lose the cohesiveness of platforms such as Plan 9. [1]

[1] http://doc.cat-v.org/plan_9/4th_edition/papers/names

As a more immediate fix with less collateral damage, since Unix programmers refuse to stop putting `rm -rf` commands in shell scripts (they seem to think the suggestion is an insult to their manhood), change the behavior of rm so that by default it either disregards -rf or moves the target files to a trash directory where they can be retrieved in the event of an error.
A simple alias would work as a quick fix:

    alias rm='rm -I'
With the -I flag, rm asks the user before removing multiple files or removing recursively. One of the top in my aliases file.
Already exists - libtrash.
> robust application-level access control would be a helpful thing to build into modern operating systems

Something like Windows Store apps, but which ideally wouldn't require the use of a specific store? (Only Entreprise apps can bypass the store from what I know)

Or use a check pointed file system with off-site storage. My PC can catch fire any day and I would lose nothing.

Sure, this Steam thing sucks but your disk could die any moment; be prepared. RAID is not backup