8 ms·

Yes, Unix was designed to protect users from each other but the modern need is to protect applications/invocations from each other. It is unfortunate that Unix

• fsflover 3y ago
  The solution is to use https://qubes-os.org https://qubes-os.org. My daily driver, can't recommend it enough.
  • bee_rider 3y ago
    Qubes is one of those things that, I think, everyone knows is better but it seems just far enough away to not want to change. How big of a change is it? If you are, say, a Linux terminal native can you just pick up and run?
    • fsflover 3y ago
      All software runs in Linux VMs, so it is practically the same as running several Linux operating systems with a nice UI.
    • nine_k 3y ago
      You would feel at home more as a cloud native, because everything runs in its own VM, spun up and down on demand.
    • markstos 3y ago
      Qubes is enough of a pain to use that another OS project started to try to take the concept and make it more usable: https://spectrum-os.org/ https://spectrum-os.org/ Doing so has proved hard and slow so far, and Spectrum hasn't had a usable release for the masses yet.
      • dooglius 3y ago
        > Initial versions of Spectrum will have the user be responsible for writing Nix code for each application and resource, and the combinations they make between them. As a qubes user, I think this is interesting but it definitely does not sound more usable.
    • invalidator 3y ago
      Mostly yes. Your applications run in a standard Linux environment and if you pop up a terminal, hey, it's your favorite distro and it works. There's some learning curve for features which exist for valid reasons, especially around communicating between domains. For instance, copy-and-paste between qubes requires extra steps. Plugging in a USB keyboard or mouse doesn't just work - you have to authorize it first (just click the OK button using a PS/2 mouse, or laptop's touchpad). You have to learn how to move files between qubes. USB drives, cameras, and microphones aren't globally available to all applications - you have to attach them to a qube first. You can install software using apt-get inside a qube, but it won't persist across reboots - you have to update the OS template. I want those extra steps and complications - they are features, not a bugs! The first few days you'll be looking things up in the FAQ. After that it's pretty easy. There are a few sore points that don't go away. You don't get GPU acceleration in your web browser, so rendering is slower. Gaming is not an option. Your application qubes live behind a firewall qube, so things that require network broadcast like Chromecast won't work. Those are fine for me but not for everyone.
      • Dylan16807 3y ago
        Please tell me the USB devices that were there at install time get authorized. > You can install software using apt-get inside a qube, but it won't persist across reboots - you have to update the OS template. > I want those extra steps and complications Is it wrong of me to say that enabling persistence, with snapshots, on a qube should be a single toggle?
        • fsflover 3y ago
          > Please tell me the USB devices that were there at install time get authorized. Yes, if you only have a USB keyboard, it will work. Manual creation of a USB VM then is recommended for security: https://www.qubes-os.org/doc/usb-qubes/ https://www.qubes-os.org/doc/usb-qubes/ > Is it wrong of me to say that enabling persistence, with snapshots, on a qube should be a single toggle? Of course you are right. TemplateVMs provide /root partition to AppVMs and software should be installed normally to the former. At every AppVM reboot, their /root is reset to the one from TemplateVM. Ordinary, persistent VMs are also possible. Details: https://www.qubes-os.org/doc/getting-started/ https://www.qubes-os.org/doc/getting-started/
  • _lvbh 3y ago
    I tried it for a week. Feels like overkill so I instead went for Fedora Silverblue & have everything in isolated podman containers. Of course, I’m not being targeted by the state so my threat model is much lower.
    • fsflover 3y ago
      It might be an overkill if you need too big efforts to switch. I did not feel that way. The independent VMs for different workflows even helped to organize my work.
    • throwthat1 3y ago
      Everyone is somewhat targeted by the state already... Just not at a pin point level yet.
    • effie 3y ago
      If you're targeted by state, Qubes on a PC isn't secure enough. It sits at a weird place, where it is stronger than your regular Linux, and showcases interesting ideas, but is quite restrictive in what you can do and doesn't provide any real security guarrantees. It's an open-source small shop project. Xen bugs and kernel bugs are too frequent, big boys know them/buy them/make them/exploit them, surely silently for years. The idea your data on a PC connected to Internet can be really secured from the most powerful actors is very naive.
      • fsflover 3y ago
        Snowden is using and recommending Qubes [0]. Only 25% of Xen bugs on average affect Qubes [1] and never lead to escapes. What is restrictive about Qubes? I do everything I need on it. [0] https://twitter.com/Snowden/status/781493632293605376 https://twitter.com/Snowden/status/781493632293605376 [1] https://www.qubes-os.org/security/xsa/ https://www.qubes-os.org/security/xsa/
        • effie 3y ago
          Don't do things just because twitter persona says so. Is there an independent security audit of Qubes that checks its factual capabilities in security? > Never lead to escapes Escape is the highest form of security failure. I'm talking about data access and exfiltration. Do you store all your important data on a VM with no internet access? Even Qubes users don't, it's hard to work with. Then it's Firefox/ kernel bug away from being accessed remotely. XSAs are publicly known vulnerabilities discovered by someone who wanted to make it public and later were published by the Xen developers. There very probably are publicly unknown vulnerabilities, both in HW and Xen, discovered/created by people who want to profit from exploiting them. There are whole teams focused on this kind of work, payed by states and criminal-enablers like NSO. > What is restrictive about Qubes? No GPU acceleration for video in a VM, legacy OS on dom0. Xen development in support of modern CPUs has fallen behind, didn't even boot on modern Zen X570 platform last time I tried, dysfunctional nested virtualization, using KVM from Linux does not work, can't run Android Studio with phone emulator.
  • jzb 3y ago
    It's one of those things I keep thinking I'd like to try but actually implementing it seems like it'd be a huge pain in the posterior at first. Am I wrong about that?
    • fsflover 3y ago
      Probably depends on the hardware. See this: https://forum.qubes-os.org/t/community-recommended-computers/5560 https://forum.qubes-os.org/t/community-recommended-computers.... Upd: yes, also there is no GPU acceleration in the VMs.
    • nine_k 3y ago
      It's mostly a huge pain in the GPU, unless you only need the basics.
• cookiengineer 3y ago
  The irony behind it is that one could argue that we are using UNIX wrong, because technically each program should run as its own user with its own groups. Which is what apparmor and firejail/sandboxes kind of want to embrace but in practice people just care too less.
  • not2b 3y ago
    That's what Android does: each app runs as a different user.
  • seanw444 3y ago
    It seems like the obvious solution. Users are protected from one another in Unix, applications need to be protected from each other, therefore applications must be users.
  • dathinab 3y ago
    the problem is "just that" is not good enough because programs often to need to have part of the capabilities of the user which started them, just a very well controlled subset of them, something which the UNIX model can't properly represent (through you can hack it on-top of it) There is also the problem of having by default "owner-user owner-group other" as permission sets for files and executable. This works if others is "other humans" (assuming it does work, security issues on shared systems based on that where not uncommon). But this works much less if you want to protect users from rogue programs because then "other" tends to be far to permissive.
    • atahanacar 3y ago
      If everything is a file, and files can have permissions, then you can simply allow the "program user" access to those files using groups.
      • jcrawfordor 3y ago
        The group model is far too inflexible to make this realistic... A file can only have one group, and people use more than one application. ACLs are available on Linux (although seldom used) and help to address this problem, but the ergonomics are very poor. Since ACLs don't address the issue of syscalls, IPC other than file based, etc., It hasn't really made sense to make them the focus or application isolation efforts. The kernel namespacing and capabilities features are a lot more attractive for this use and are more similar to the historic approach of chroot... But the tools still aren't great.
• TillE 3y ago
  This is why I'm still hopeful that capability-based microkernels are the future. They simply fit modern security needs far better than hacky sandbox solutions on top of the same old operating systems with coarse permissions.
• 1letterunixname 3y ago
  The use-case is concerned with is multi-user, most likely remote login, sometimes desktop login. He whines about everyone not having root and breaking the box. Too bad. If you don't like the isolation and privilege separation a system provides, use virtualization, containers, run your own, or change the OS to allow your specialness that doesn't affect other users. It's not wheel's fault, and so substituting root group for wheel was nothing more than a special snowflake move by someone who thought the sysadmins were holding back and the "enemy".