4 ms·

"collect it all" But I wonder why we don't have application isolation as a basic design principle. Imagine an OS where applications/serices each get their own

"collect it all" But I wonder why we don't have application isolation as a basic design principle. Imagine an OS where applications/serices each get their own mini-filesystem, without ability to access each other's data. Would that work?

rcthompson 12y ago
I'm pretty sure that's called Android. Or ChromeOS. Or iOS. Of course, then we just give all those permissions back to any apps that ask for them. Edit: And the modern sandbox modes in Windows and OSX.
- tjohns 12y ago
  > Of course, then we just give all those permissions back to any apps that ask for them. At least in the case of Android, there is no permission that will give you access to the root filesystem or other apps' sandboxes. Categorically not allowed. App data is restricted to /data/data/$PACKAGE_NAME. The rest of internal storage is either read-only or completely off-limits (especially in the case of other apps' data). The only way to access data that belongs to other apps is to share the same developer signing key, or explicitly share the data using a content provider. The only exception is external storage (the SD card, if present). But that's because SD cards use FAT and therefore can't support per-application permissions.
  - pjmlp 12y ago
    I lost track of the whole discussion and only do Android occasionally as hobby, but I think SD card access had some security changes as of 4.4.
danieldk 12y ago
Imagin an OS where applications/serices each get their own mini-filesystem, without ability to access each other's data. OS X does this for sandboxed apps: https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html#//apple_ref/doc/uid/TP40011183-CH1-SW1 https://developer.apple.com/library/mac/documentation/Securi... All apps from the App Store are sandboxed.
- java-man 12y ago
  What I meant is the app/service isolation on the OS level. It should not apply just to a subset of apps, but to each and every process that runs on a device.
  - danieldk 12y ago
    Because then every application would be an island and useless. Red Hat Linux tried a variation of this with the SELinux policy that preceded the 'targeted' policy (I forgot its name). Processes that did not have a policy adding permissions would be allowed to virtually read/write nothing. The net result was that nearly everyone switched off SELinux. Afterwards, Red Hat worked in the opposite direction. In the so-called 'targeted' policy processes are allowed to do what a normal UNIX process is allowed to do, unless there is a policy defined for them. Since they provide policies for commonly used daemons it adds security, while not making life too hard for sysadmins. Net result: most people keep SELinux enabled and have safer systems.
tjohns 12y ago
That's the basic idea behind sandboxing, and it's a model that a lot of newer OSes are moving towards, especially in mobile. Android does this for all apps, as does iOS. MacOS is also doing it for apps downloaded from the App Store. On the server side, that's also one of the things that Docker gives you.
- java-man 12y ago
  So, if someone finds a vulnerability in Docker software and roots a process, your filesystem is safe? The idea is not sandboxing, it's "multiverse". Each process, even an OS one, gets its own little filesystem, and connects to a limited set of interfaces explicitly permitted by the user (and that can be audited by the user).
  - deleted 12y ago
    [deleted]
  - tjohns 12y ago
    > So, if someone finds a vulnerability in Docker software and roots a process, your filesystem is safe? You could make the same argument about a vulnerability in the OS itself. There's nothing magic about kernel code that gives it extra protection here. :) In fact, I'd argue that the most probable attack against Docker would already be via a vulnerability in the OS. Docker uses a lot of kernel-level technologies, like cgroups. Beyond that, the most likely way to escape a Docker sandbox would be by finding a buggy syscall, since these weren't always designed with containers in mind. This presentation is a good overview of Docker's attack surface: http://www.slideshare.net/jpetazzo/linux-containers-lxc-docker-and-security http://www.slideshare.net/jpetazzo/linux-containers-lxc-dock... > Each process, even an OS one, gets its own little filesystem, and connects to a limited set of interfaces explicitly permitted by the user (and that can be audited by the user). That would be an interesting research project, at the very least. You'd probably have to rewrite much of userspace, since it breaks many of the assumptions the current generation of system tools rely on.
  - pjmlp 12y ago
    Yes, because you cannot even access the filesytem directly. Applications only get the data handle for specific files, after being authorized to do so.
guardian5x 12y ago
Windows 8/8.1/10 do this with Modern Apps.
GauntletWizard 12y ago
This would completely defeat the point of Dropbox, then; If your Word document is in your Word folder, how does it get to another computer? Do you give the app developer, Microsoft, exclusive right to 'sync' your files elsewhere? Sandboxing is a good idea. An old idea, actually; chroot was added to unix in 1979. But shared filesystems evolved and are the norm, and even if many apps could be sandboxed, Dropbox exists outside the sandbox for a reason.
- ytdht 12y ago
  You could write all files that need to be synced in the Dropbox sandbox?
pjmlp 12y ago
Besides what everyone already mentioned. I think Symbian also did it,
codeonfire 12y ago
do you mean chroot. Unix had that in 1979.

rcthompson 12y ago

I'm pretty sure that's called Android. Or ChromeOS. Or iOS. Of course, then we just give all those permissions back to any apps that ask for them. Edit: And the modern sandbox modes in Windows and OSX.

tjohns 12y ago
> Of course, then we just give all those permissions back to any apps that ask for them. At least in the case of Android, there is no permission that will give you access to the root filesystem or other apps' sandboxes. Categorically not allowed. App data is restricted to /data/data/$PACKAGE_NAME. The rest of internal storage is either read-only or completely off-limits (especially in the case of other apps' data). The only way to access data that belongs to other apps is to share the same developer signing key, or explicitly share the data using a content provider. The only exception is external storage (the SD card, if present). But that's because SD cards use FAT and therefore can't support per-application permissions.
- pjmlp 12y ago
  I lost track of the whole discussion and only do Android occasionally as hobby, but I think SD card access had some security changes as of 4.4.

danieldk 12y ago

Imagin an OS where applications/serices each get their own mini-filesystem, without ability to access each other's data. OS X does this for sandboxed apps: https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html#//apple_ref/doc/uid/TP40011183-CH1-SW1 https://developer.apple.com/library/mac/documentation/Securi... All apps from the App Store are sandboxed.

java-man 12y ago
What I meant is the app/service isolation on the OS level. It should not apply just to a subset of apps, but to each and every process that runs on a device.
- danieldk 12y ago
  Because then every application would be an island and useless. Red Hat Linux tried a variation of this with the SELinux policy that preceded the 'targeted' policy (I forgot its name). Processes that did not have a policy adding permissions would be allowed to virtually read/write nothing. The net result was that nearly everyone switched off SELinux. Afterwards, Red Hat worked in the opposite direction. In the so-called 'targeted' policy processes are allowed to do what a normal UNIX process is allowed to do, unless there is a policy defined for them. Since they provide policies for commonly used daemons it adds security, while not making life too hard for sysadmins. Net result: most people keep SELinux enabled and have safer systems.

tjohns 12y ago

That's the basic idea behind sandboxing, and it's a model that a lot of newer OSes are moving towards, especially in mobile. Android does this for all apps, as does iOS. MacOS is also doing it for apps downloaded from the App Store. On the server side, that's also one of the things that Docker gives you.

java-man 12y ago
So, if someone finds a vulnerability in Docker software and roots a process, your filesystem is safe? The idea is not sandboxing, it's "multiverse". Each process, even an OS one, gets its own little filesystem, and connects to a limited set of interfaces explicitly permitted by the user (and that can be audited by the user).
- deleted 12y ago
  [deleted]
- tjohns 12y ago
  > So, if someone finds a vulnerability in Docker software and roots a process, your filesystem is safe? You could make the same argument about a vulnerability in the OS itself. There's nothing magic about kernel code that gives it extra protection here. :) In fact, I'd argue that the most probable attack against Docker would already be via a vulnerability in the OS. Docker uses a lot of kernel-level technologies, like cgroups. Beyond that, the most likely way to escape a Docker sandbox would be by finding a buggy syscall, since these weren't always designed with containers in mind. This presentation is a good overview of Docker's attack surface: http://www.slideshare.net/jpetazzo/linux-containers-lxc-docker-and-security http://www.slideshare.net/jpetazzo/linux-containers-lxc-dock... > Each process, even an OS one, gets its own little filesystem, and connects to a limited set of interfaces explicitly permitted by the user (and that can be audited by the user). That would be an interesting research project, at the very least. You'd probably have to rewrite much of userspace, since it breaks many of the assumptions the current generation of system tools rely on.
- pjmlp 12y ago
  Yes, because you cannot even access the filesytem directly. Applications only get the data handle for specific files, after being authorized to do so.

guardian5x 12y ago

Windows 8/8.1/10 do this with Modern Apps.

GauntletWizard 12y ago

This would completely defeat the point of Dropbox, then; If your Word document is in your Word folder, how does it get to another computer? Do you give the app developer, Microsoft, exclusive right to 'sync' your files elsewhere? Sandboxing is a good idea. An old idea, actually; chroot was added to unix in 1979. But shared filesystems evolved and are the norm, and even if many apps could be sandboxed, Dropbox exists outside the sandbox for a reason.

ytdht 12y ago
You could write all files that need to be synced in the Dropbox sandbox?

pjmlp 12y ago

Besides what everyone already mentioned. I think Symbian also did it,

codeonfire 12y ago

do you mean chroot. Unix had that in 1979.