6 ms·

Are we ever going to end up with the practice of running every app in their own independent VM? Should anything at all run in the host OS? The advantage of ru

• withoutclass 9y ago
  We're there, check out Qubes OS
  • krisives 9y ago
    Great when it works, one of the few variants of Linux that sometimes just doesn't like to run on some hardware still.
• woolvalley 9y ago
  Permmissions dialogs for rare dangerous behaviors I think can work. You have to do it like apple does it although, not like android. Like how often does software need to do screenshots, not many. Same with most other app permissions. Most only need network access and a folder.
  • mcny 9y ago
    I'm afraid apps will abuse these permissions. For example, Facebook app (or a banking app) shouldn't quit if I refuse it a permission. I can't even use the default native email app (edit: on Android) with exchange without giving the exchange server remote administration access. Makes no sense.
    • ndespres 9y ago
      The Exchange server requesting remote permission is a "feature" which allows you or your company's Exchange server admins to send remote wipe command to the handset if it's lost or you leave the company. Not the specific fault of the permission model of the phone, it's part of the activesync suite.
    • eropple 9y ago
      You can use the default email application on Android with services that don't want remote-wipe controls. Exchange does. That's how ActiveSync works. If you don't want that, use IMAP or POP3.
    • woolvalley 9y ago
      That is why permission state needs to be hidden / discouraged from apps. No permission just gives you empty data sets. They should be also rejected from app store if they try to cirumvent unless it's a central feature of the app, like a screenshot app or a location tracking app. With the permission model of apps, then we can start having system apps like istat menus being sold on the app store again too. I think you haven't used iOS that much. In practice it's fairly rare for an app to shut down without a permission unless it's central to the app.
      • firloop 9y ago
        In fact, it's against the App Store guidelines to refuse to work without a permission (unless it's central to the app).
  • Larrikin 9y ago
    How is the Android way different? We're two major and four minor versions since individual permission request were added.
    • woolvalley 9y ago
      Android AFAIK shows a large laundry list of permissions you need to accept when you install an app and you can revoke after the fact. While on iOS there is no laundry list to accept and the built in annoyance of permission alerts encourages apps not to do it unless they need it. Also android takes a while to propagate new versions onto the majority install base :)
      • Nullabillity 9y ago
        You just replied to a post stating that this changed years ago.
• amelius 9y ago
  > Should anything at all run in the host OS? Isn't that equivalent to saying that the set of available kernel calls should be more restricted? (User mode is a kind of sandbox, after all)
  • koolba 9y ago
    Not just the set of kernel calls but the scope of the calls themselves. A text editor should be able to fopen the file I’m editing but it doesn’t need to be able to access ~/Documents/top-secret.txt. You can do this type of thing with SELinux though I’ve yet to see it done in a user friendly way.
    • tzahola 9y ago
      You’re looking for capability-based systems.
  • globuous 9y ago
    It is my understanding that that's what Flatpak is trying to do: "One of Flatpak’s main goals is to increase the security of desktop systems by isolating applications from one another. [...] Limited syscalls. For instance, apps can’t use nonstandard network socket types or ptrace other processes. " [0] But as my other comment mentions [1], I wish I had the knowledge required to understand the meaning / implications of Flatpak apps. Please let me know if I'm misunderstanding :) Happy Saturday night y'all ! [0] http://docs.flatpak.org/en/latest/working-with-the-sandbox.html http://docs.flatpak.org/en/latest/working-with-the-sandbox.h... [1] https://news.ycombinator.com/item?id=16351192 https://news.ycombinator.com/item?id=16351192
• userbinator 9y ago
  Imagine still actively using several perfectly good apps that were last updated 10 or 20 years ago? I do. I don't know exactly what my oldest binary is, but it's probably from the 80s (some text processing utilities), and I still actively use apps I wrote myself over a decade ago. Of course, I use Windows which has historically been far better at backwards compatibility than Mac OS.
• bradgessler 9y ago
  Check out QubesOS.
• badsectoracula 9y ago
  > Imagine still actively using several perfectly good apps that were last updated 10 or 20 years ago? I regularly use Borland C++ 5 (because it has a nice enough customizable IDE and a very fast C compiler which is practically instant on modern PCs), which (IIRC) was released in 1996. And i also use a ton of other stuff from the 90s, including many games. Things already work without the overhead and resource wastage of virtual machines, all it takes is OSes and libraries try to not break their ABIs.
• zanny 9y ago
  A lot of the motivations to develop and push for Wayland are around security and privacy. An X window, or just more generally any program running on a computer with an X session and either the same privilege or greater than the user running it can view anything on that screen, send any combination of inputs it wants or steal the pointer / keyboard indefinitely. At the end of the day people don't care about security that much. Wayland is still getting there. Its getting better, particularly in the last year, but its not a huge priority for many people so it has taken upwards of ten years to become usable.
  • danieldk 9y ago
    At the end of the day people don't care about security that much. Wayland is still getting there. Its getting better, particularly in the last year, but its not a huge priority for many people so it has taken upwards of ten years to become usable. I think many people are also not aware of how bad X11 security is. The other day I mentioned that X11 applications can read all keystrokes to someone who does system administration/security at an ISP. To my big surprise, he was not aware of this. (Didn't everyone play with xev at some point?) On Linux, I only use Wayland because of X11's broken security model. Fortunately, it works very well these days with the amdgpu driver.
    • wander_homer 9y ago
      However the way Wayland (or its broader ecosystem) "fixes" security is just stupid. Instead of using a fine grained whitelisting based permission system to grant different clients all the permissions they need to do their work (taking screenshots, reading the color of a point, listening to a certain key combination, apply some filtering to the display, get the size/position of a different client, ...) it treats every client as untrustworthy with no standard way to change that. And let's not forget that just using Wayland doesn't grant any improved security compared to X11. There are numerous other ways to get input data, display contents, etc., so you need further sandboxing anyway, at which point you might just as well sandbox X11 clients you don't trust to get the same security. The benefit here is that you can decide if you trust your color picker and let it do its work by not sandboxing it, while Wayland just decides for you that no color picker can be trusted.
• solatic 9y ago
  > The advantage of running every app in their own VM means that apps won't get necessarily tossed to the side in this constant arms race of upgrades, especially for apps that don't need internet. Imagine still actively using several perfectly good apps that were last updated 10 or 20 years ago? Not "especially for apps that don't need the Internet", only for apps that don't need the Internet. Anything that connects to the Internet needs constant and rigorous update discipline to stay ahead of a constant stream of exploits. Sandboxing applications within their own VMs leads to a false sense of security. Now, whoever is responsible for distributing the app, is responsible for distributing the OS that runs the app as well. If the underlying OS doesn't get updated, Murphy guarantees that there will be an OS-level exploit within that VM. And then, even if the exploit is sandboxed to only affect that app and its OS, the attacker still owns anything that the user passes through that app, including but not limited to usernames and passwords (which are often reused across websites and apps), any sensitive information that passes through the app (banking and financial accounts, anybody?), and any privileges existing within the VM (session tokens, client keys, privileged access / firewall passthrough to other machines in the local network, etc.). It's one thing to sandbox each app within its own userland-level sandbox, but sandboxing each app within its own VM / OS only makes security even more difficult. That kind of deployment model only makes sense if a sysadmin is doing so to make deployments more predictable and has the full power to reinitiate deployments when OS updates are released. On an end-user level, you're either risking the end-user's security (if upstream controls the OS update) or wasting the end-user's resources.
• 3pt14159 9y ago
  I tried doing this when I got a new MacBook Pro. The problem is all these damn pixels make it impossible to even quarantine the web browser unless you're willing on letting VM Ware patch your macOS kernel (uh, no thanks).
• stephenc_c_ 9y ago
  That's essentially what Docker containers have done to server-side applications. Every application is isolated from the host in a container and bundled with only the dependencies it needs. The only shared component is the kernel and anything you mount into it from the host.