5 ms·

"Any application" would have to include applications that compromise your system. For example, suppose you want an application that deletes any files on your h

"Any application" would have to include applications that compromise your system. For example, suppose you want an application that deletes any files on your hard ending with tmp. I offer it for download, you get it, run it, like it. Now (just because I can) I change the application (without telling you) to delete all files ending with doc. You've been compromised.

stcredzero 18y ago
If "Open File" (which may or may not mean a dialog) is a service provided by the Operating System, then there is no reason why a sandboxed application would have access to anything more than the particular file you have open. People have been researching other security models for decades now. I'm afraid I have to say: they're way ahead of you!
- te_platt 18y ago
  Right, but then you are only including applications that have limited access to files, not any application. I was just lured into a good paradox. :)
  - stcredzero 18y ago
    In such schemes, all applications have limited access to files. Again, these guys are way ahead of you.
    - kragen 18y ago
      Not true; in KeyKOS, for example, the shell had full access to all the files the user had access to, because that is where the user held the keys of their directories. In CapDesk the window system has the same role. In general you need to be able to run "utility" programs like the tmp-remover in the example. That doesn't necessarily mean the author of the utility programs has to be able to send updates without your approval, or that they need to be able to receive communications from their utility program, or that you can't delegate your approval of application updates to a third party who vets the code, or that the utilities can't be small and clear enough that you don't have any doubt about what they're doing, or that all programs need to have full access to your files, or that you can't store your files somewhere where you can roll back undesired deletions.
      - stcredzero 18y ago
        In those cases, the security schemes are somewhat weak. A proper sandboxing scheme wouldn't need a .tmp file remover. Once you removed a given application, all of the .tmp files it produced would just disappear with it. The only reason you'd want to run such a utility would be to clean out the .tmp files within a particular sandbox. In that case, you'd give permission for it to operate on the whole of that particular sandbox's contents. Worst case, it trashes that sandbox, then you roll back to your previous backup. They were supposed to have a sandboxing scheme along these lines in the OLPC.
        kragen 18y ago
        If you think KeyKOS's security scheme was "somewhat weak", you should read the DTOS review of it (in http://www.cs.utah.edu/flux/fluke/html/dtos/HTML/final-docs/mer.pdf http://www.cs.utah.edu/flux/fluke/html/dtos/HTML/final-docs/...), which was mostly positive. It includes a pretty balanced picture of its pluses and minuses, although it doesn't seem to have been based on experience actually using KeyKOS. If your files belong to your applications instead of to you, or if your sandboxes don't nest, then your sandboxing scheme is pretty lame. Most of the time there are worse cases than just deleting your documents: the utility could send all of your documents to its owner over the internet. You can prevent this with sandboxing policies too; KeyKOS solved an analogous problem in the context of a multiuser non-networked mainframe. More difficult is to keep it from inserting backdoors into your programs or subtly corrupting your files. I don't see how the solution "then you roll back to your previous backup" is dependent upon only the utility only having access to a single sandbox. It seems like it works just as well if you give it access to everything except your basic UI (and the TCB it depends on, e.g. the kernel, the bootloader) and your backups.
        stcredzero 18y ago
        Ah, so you're talking about capabilities? I thought you were arguing in favor of the other guy's position -- that there's nothing you can do about malicious apps. (And maybe in the face of ignorant and gullible users, there ultimately is nothing, but lets leave social engineering out of this for now.) I just didn't want to explain capabilities for the nth time, so I thought I'd throw the OLPC at him. Even a sandboxing scheme like the OLPC's addresses his objections. Not sure if it was supposed to nest.
Retric 18y ago
What if no application could delete files? I don't mind a program flagging them as unimportant but if I have enough space to restore any file deleted in the last month what's the problem? Toss in a wizard to restore things to before I installed that program and it becomes harder to damage the system. Heck, add a pop up if the OS wants to destroy a file that was marked as unimportant in the last month and it's going to become hard to damage the system like that. You can even treat updates like deletes where the OS protects the old state for a week / month / year.

stcredzero 18y ago

If "Open File" (which may or may not mean a dialog) is a service provided by the Operating System, then there is no reason why a sandboxed application would have access to anything more than the particular file you have open. People have been researching other security models for decades now. I'm afraid I have to say: they're way ahead of you!

te_platt 18y ago
Right, but then you are only including applications that have limited access to files, not any application. I was just lured into a good paradox. :)
- stcredzero 18y ago
  In such schemes, all applications have limited access to files. Again, these guys are way ahead of you.
  - kragen 18y ago
    Not true; in KeyKOS, for example, the shell had full access to all the files the user had access to, because that is where the user held the keys of their directories. In CapDesk the window system has the same role. In general you need to be able to run "utility" programs like the tmp-remover in the example. That doesn't necessarily mean the author of the utility programs has to be able to send updates without your approval, or that they need to be able to receive communications from their utility program, or that you can't delegate your approval of application updates to a third party who vets the code, or that the utilities can't be small and clear enough that you don't have any doubt about what they're doing, or that all programs need to have full access to your files, or that you can't store your files somewhere where you can roll back undesired deletions.
    - stcredzero 18y ago
      In those cases, the security schemes are somewhat weak. A proper sandboxing scheme wouldn't need a .tmp file remover. Once you removed a given application, all of the .tmp files it produced would just disappear with it. The only reason you'd want to run such a utility would be to clean out the .tmp files within a particular sandbox. In that case, you'd give permission for it to operate on the whole of that particular sandbox's contents. Worst case, it trashes that sandbox, then you roll back to your previous backup. They were supposed to have a sandboxing scheme along these lines in the OLPC.
      - kragen 18y ago
        If you think KeyKOS's security scheme was "somewhat weak", you should read the DTOS review of it (in http://www.cs.utah.edu/flux/fluke/html/dtos/HTML/final-docs/mer.pdf http://www.cs.utah.edu/flux/fluke/html/dtos/HTML/final-docs/...), which was mostly positive. It includes a pretty balanced picture of its pluses and minuses, although it doesn't seem to have been based on experience actually using KeyKOS. If your files belong to your applications instead of to you, or if your sandboxes don't nest, then your sandboxing scheme is pretty lame. Most of the time there are worse cases than just deleting your documents: the utility could send all of your documents to its owner over the internet. You can prevent this with sandboxing policies too; KeyKOS solved an analogous problem in the context of a multiuser non-networked mainframe. More difficult is to keep it from inserting backdoors into your programs or subtly corrupting your files. I don't see how the solution "then you roll back to your previous backup" is dependent upon only the utility only having access to a single sandbox. It seems like it works just as well if you give it access to everything except your basic UI (and the TCB it depends on, e.g. the kernel, the bootloader) and your backups.
        stcredzero 18y ago
        Ah, so you're talking about capabilities? I thought you were arguing in favor of the other guy's position -- that there's nothing you can do about malicious apps. (And maybe in the face of ignorant and gullible users, there ultimately is nothing, but lets leave social engineering out of this for now.) I just didn't want to explain capabilities for the nth time, so I thought I'd throw the OLPC at him. Even a sandboxing scheme like the OLPC's addresses his objections. Not sure if it was supposed to nest.

Retric 18y ago

What if no application could delete files? I don't mind a program flagging them as unimportant but if I have enough space to restore any file deleted in the last month what's the problem? Toss in a wizard to restore things to before I installed that program and it becomes harder to damage the system. Heck, add a pop up if the OS wants to destroy a file that was marked as unimportant in the last month and it's going to become hard to damage the system like that. You can even treat updates like deletes where the OS protects the old state for a week / month / year.