5 ms·

> This is par for the course. Open source does not have any warranty, it can break or be deprecated at any time. I don't care to discuss Wayland right now, if y

by nsajko 6y ago

> This is par for the course. Open source does not have any warranty, it can break or be deprecated at any time. I don't care to discuss Wayland right now, if you don't want to use it you don't have to. There is no relation between open-source licensing or culture and careless breakage. Even if there was, what would be the justification for it (Red Hat's behavior). > This is wrong on several levels. For example, namespacing and SELinux policies still work even when processes share the same user, and there are valid reasons why you would want to do that. I know about cgroups, namespacing, SELinux and how they could hypothetically provide other means of privilege separation than users and groups already provide; but I don't see how that applies to Wayland. I doubt anyone has actually set up a system with sandboxed untrusted processes in a way that would justify the Wayland security model. The way I see it, Wayland will over time gain even more extension protocols than X Windows has to accomodate things that were not thought out during the design phase. I also doubt the user namespace implementation in the kernel will be solid enough for secure usage for many years. Or that compositor and application programmers will understand the security implications of their software on the possible security models well enough for users to actually have a usable and feature-complete system where the Wayland-implied security model could shine.

cycloptic 6y ago
>There is no relation between open-source licensing or culture and careless breakage. There is no relation between open-source licensing or culture and working software either. Go take a look around on github and you will see tons of broken, outdated and unmaintained software. (I am not saying there is anything wrong with this, eventual death is a fundamental part of any product lifecycle) >I doubt anyone has actually set up a system with sandboxed untrusted processes in a way that would justify the Wayland security model. There already is one, called Flatpak.
- nsajko 6y ago
  > There already is one, called Flatpak. I said "a system", making a sandboxing program like Flatpak is the easy part. Also, why is it that neither https://flatpak.org https://flatpak.org nor https://github.com/flatpak/flatpak https://github.com/flatpak/flatpak mention security or "secure"? I think that is because Flatpak is not meant for running untrusted/malicious processes (without using additional protection; such as a virtual machine, another OS user, or another physical machine). I am not sure why that is, but it may be because, as I said, it is simply too complicated to think through everything while satisfying relevant security models, or because Flatpak programmers know that for real security you do not want user namespaces in your Linux (attack surface increase, etc.). Also, even if Flatpak and the kernel were perfect, if you want to sandbox a complex application with only Flatpak; using the app and configuring its sandbox would then be an impractical nightmare for either administrators or users. See the article linked here about the problems with Flatpak-sandboxing complex real-world programs: https://news.ycombinator.com/item?id=18180017 https://news.ycombinator.com/item?id=18180017. And this comment is also informative: https://news.ycombinator.com/item?id=14409234 https://news.ycombinator.com/item?id=14409234 Basically, for real secure and robust sandboxing I think one needs to use the Chromium setuid + seccomp + multiple processes approach. This implies thinking about security while designing the program, and it being open-source; so it is only applicable to trusted software that deals with untrusted data, or executes Javascript or something. So, if a program is designed with security in mind (e.g., Chromium), Flatpak provides nothing beneficial. On the other hand, if one needs to execute real-world untrusted software, it again seems it is necessary to use another user account or another machine.
  - cycloptic 6y ago
    Sandboxing is part of an overall security solution and also has other uses besides security. And as you know there are many other parts to securing your system. Of course if you already implement sandboxing yourself then you probably don't need to use Flatpak to make security guarantees. I think you have made a lot of wild assumptions from reading those posts you linked, and those assumptions don't apply to everyone. Regardless of your feelings on Flatpak/Wayland in certain applications, they are being used for security purposes right now. The Chromium security model also makes a lot of assumptions and only applies to certain applications.

by nsajko 6y ago

cycloptic 6y ago

>There is no relation between open-source licensing or culture and careless breakage. There is no relation between open-source licensing or culture and working software either. Go take a look around on github and you will see tons of broken, outdated and unmaintained software. (I am not saying there is anything wrong with this, eventual death is a fundamental part of any product lifecycle) >I doubt anyone has actually set up a system with sandboxed untrusted processes in a way that would justify the Wayland security model. There already is one, called Flatpak.

nsajko 6y ago
> There already is one, called Flatpak. I said "a system", making a sandboxing program like Flatpak is the easy part. Also, why is it that neither https://flatpak.org https://flatpak.org nor https://github.com/flatpak/flatpak https://github.com/flatpak/flatpak mention security or "secure"? I think that is because Flatpak is not meant for running untrusted/malicious processes (without using additional protection; such as a virtual machine, another OS user, or another physical machine). I am not sure why that is, but it may be because, as I said, it is simply too complicated to think through everything while satisfying relevant security models, or because Flatpak programmers know that for real security you do not want user namespaces in your Linux (attack surface increase, etc.). Also, even if Flatpak and the kernel were perfect, if you want to sandbox a complex application with only Flatpak; using the app and configuring its sandbox would then be an impractical nightmare for either administrators or users. See the article linked here about the problems with Flatpak-sandboxing complex real-world programs: https://news.ycombinator.com/item?id=18180017 https://news.ycombinator.com/item?id=18180017. And this comment is also informative: https://news.ycombinator.com/item?id=14409234 https://news.ycombinator.com/item?id=14409234 Basically, for real secure and robust sandboxing I think one needs to use the Chromium setuid + seccomp + multiple processes approach. This implies thinking about security while designing the program, and it being open-source; so it is only applicable to trusted software that deals with untrusted data, or executes Javascript or something. So, if a program is designed with security in mind (e.g., Chromium), Flatpak provides nothing beneficial. On the other hand, if one needs to execute real-world untrusted software, it again seems it is necessary to use another user account or another machine.
- cycloptic 6y ago
  Sandboxing is part of an overall security solution and also has other uses besides security. And as you know there are many other parts to securing your system. Of course if you already implement sandboxing yourself then you probably don't need to use Flatpak to make security guarantees. I think you have made a lot of wild assumptions from reading those posts you linked, and those assumptions don't apply to everyone. Regardless of your feelings on Flatpak/Wayland in certain applications, they are being used for security purposes right now. The Chromium security model also makes a lot of assumptions and only applies to certain applications.