13 ms·

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 addi

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?

andrewfong 12y ago
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.
- gizmo686 12y ago
  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.
- ejdyksen 12y ago
  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/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW17 https://developer.apple.com/library/mac/documentation/Securi...
  - quotemstr 12y ago
    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.
    - wtallis 12y ago
      Aquamacs seems to use the system dialogs with no trouble.
      - quotemstr 12y ago
        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.
    - 12y ago
vmarsy 12y ago
> 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)
falcolas 12y ago
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).
- deleted 12y ago
  [deleted]
- Chris_Newton 12y ago
  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.
woodman 12y ago
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 http://en.wikipedia.org/wiki/Chroot
- wpietri 12y ago
  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.
  - woodman 12y ago
    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.
    - ObviousScience 12y ago
      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.
      - woodman 12y ago
        Damn it. Well at least I can still trust in Plato's theory of forms.
    - thevardanian 12y ago
      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.
vezzy-fnord 12y ago
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 http://doc.cat-v.org/plan_9/4th_edition/papers/names
pjc50 12y ago
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.
rwallace 12y ago
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.
- anon4 12y ago
  Already exists - libtrash.
- raldu 12y ago
  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.
SixSigma 12y ago
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

andrewfong 12y ago

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.

gizmo686 12y ago
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.
ejdyksen 12y ago
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/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW17 https://developer.apple.com/library/mac/documentation/Securi...
- quotemstr 12y ago
  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.
  - wtallis 12y ago
    Aquamacs seems to use the system dialogs with no trouble.
    - quotemstr 12y ago
      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.
  - 12y ago

vmarsy 12y ago

> 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)

falcolas 12y ago

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).

deleted 12y ago
[deleted]
Chris_Newton 12y ago
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.

woodman 12y ago

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 http://en.wikipedia.org/wiki/Chroot

wpietri 12y ago
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.
- woodman 12y ago
  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.
  - ObviousScience 12y ago
    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.
    - woodman 12y ago
      Damn it. Well at least I can still trust in Plato's theory of forms.
  - thevardanian 12y ago
    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.

vezzy-fnord 12y ago

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 http://doc.cat-v.org/plan_9/4th_edition/papers/names

pjc50 12y ago

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.

rwallace 12y ago

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.

anon4 12y ago
Already exists - libtrash.
raldu 12y ago
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.

SixSigma 12y ago

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