They try to avoid saying it, but it's mostly a patched Linux.
imho the qubes approach is more viable and exposes far less attack surface. Qubes is also, contrary to it's reputation, a very usable OS (with KDE in dom0, at least).
Subgraph OS: Adversary resistant computing platform
21–30 of 88 posts
Re: Subgraph OS: Adversary resistant computing platform
#22Earlier quoted context omitted.
No updated iso since June. Any plans for an update soon? Also, shouldn't you just use Wayland for the stable 1.0 release? Why even bother with X11 at this point? Do you plan to support flatpaks as well?
The new ISO is coming very soon. We've just been busy with consulting we do to support the project and there were some issues with gpg2. Wayland is one huge reason why we aren't even calling this "beta". Wayland is absolutely part of the plan. We are working on integration now. Flatpaks: probably not. Different vision. Flatpak is an 'appstore' type model, not sure we will want that in Subgraph OS, but it's worth a de…
Good to hear you're considering it. It may be worth looking into appimages as well. They don't seem to focus as much on security, but perhaps their isolation is better? Flatpaks seem to share quite a bit with each other, and I worry it may create another X11-situation. Flatpaks may still be better overall, though, if they can also have good isolation.
I doubt you should even bother with snaps. They don't seem to be that well supported outside of Ubuntu, and I doubt they will ever be.
Re: Subgraph OS: Adversary resistant computing platform
#23Re: Subgraph OS: Adversary resistant computing platform
#24They try to avoid saying it, but it's mostly a patched Linux.
Hi, I'm an SGOS dev. I don't know what you mean by "mostly a patched Linux", but here's what Subgraph OS is so far -- and it's a young project: we have a kernel patched with grsec/PaX/RAP, but we have also developed our own application sandbox framework (namespaces + limited fs + seccomp bpf whitelisting), app firewall, event monitoring subsystem, usb disable on desktop lock (based on grsec), etc. Here's a walkthroug…
Hey, cool project! Any chance you could give a quick rundown of how this compares to Qubes? Like, the tradeoffs, etc.
Re: Subgraph OS: Adversary resistant computing platform
#25Earlier quoted context omitted.
imho the qubes approach is more viable and exposes far less attack surface. Qubes is also, contrary to it's reputation, a very usable OS (with KDE in dom0, at least).
I honestly find the XFCE desktop more usable.
I greatly prefer a desktop that has searchable menus and decent Hi DPI support (although the older version in F23/Q dom0 isn't quite plugnplay). Personally I think that KDE also looks better. Especially XFCEs window decorations are just so... 90s "design".
Re: Subgraph OS: Adversary resistant computing platform
#26This is a step in the right direction (in the sense that we should sandbox applications harder), but in my opinion we have to change fundamental aspects of our stack (e.g. Proprietary Firmware Linux GNU-System-Libs X GTK Evince), to gain more security. In particular I think it is harmful that all applications share the same view on the FS and have in principal the possibility to use e.g. full unixoish capabilities. M…
You might be interested in coeffects. Just like monads can be used in a language like Haskell to model effectful operations, you can use the dual of monads, comonads, to model the dual of effects, coeffects!
Coeffects can be used to represent the "context" of a program, which includes things like permissions or capabilities that the program may have access to. They provide a fascinating way of modeling all kinds of information that is traditionally not handled by even powerful type systems like OCaml's or Haskell's.
You can read a lot more about the topic on Tomas Petricek's website: http://tomasp.net/coeffects/
I especially recommend this short article from 2014: http://tomasp.net/blog/2014/why-coeffects-matter/
Re: Subgraph OS: Adversary resistant computing platform
#27Looks interesting. I'm looking for a more secure minimal OS, for use with backend services. Would it make sense to use it as a server OS, or is it primarily for desktop use?
Also, is there a docker image that is ready to go? That would be immensely useful.
Re: Subgraph OS: Adversary resistant computing platform
#28Earlier quoted context omitted.
Hi, I'm an SGOS dev. I don't know what you mean by "mostly a patched Linux", but here's what Subgraph OS is so far -- and it's a young project: we have a kernel patched with grsec/PaX/RAP, but we have also developed our own application sandbox framework (namespaces + limited fs + seccomp bpf whitelisting), app firewall, event monitoring subsystem, usb disable on desktop lock (based on grsec), etc. Here's a walkthroug…
Hey, cool project! Any chance you could give a quick rundown of how this compares to Qubes? Like, the tradeoffs, etc.
I suspect that it doesn't at all seeing as how it is a Linux distribution with some nice features for security and privacy baked in by default.
Re: Subgraph OS: Adversary resistant computing platform
#29They try to avoid saying it, but it's mostly a patched Linux.
Hi, I'm an SGOS dev. I don't know what you mean by "mostly a patched Linux", but here's what Subgraph OS is so far -- and it's a young project: we have a kernel patched with grsec/PaX/RAP, but we have also developed our own application sandbox framework (namespaces + limited fs + seccomp bpf whitelisting), app firewall, event monitoring subsystem, usb disable on desktop lock (based on grsec), etc. Here's a walkthroug…
Linux = kernel.
Re: Subgraph OS: Adversary resistant computing platform
#30This is a step in the right direction (in the sense that we should sandbox applications harder), but in my opinion we have to change fundamental aspects of our stack (e.g. Proprietary Firmware Linux GNU-System-Libs X GTK Evince), to gain more security. In particular I think it is harmful that all applications share the same view on the FS and have in principal the possibility to use e.g. full unixoish capabilities. M…
> limited to interacting with a drawing library (e.g. OpenGL)
Isolation between applications running on the same graphics hardware is rather weak (GPUs don't have something like a MMU), so that exercise is left to the reader ^W driver getting a lot of stuff right. Most don't, or didn't. That's why eg. Qubes doesn't allow sharing a graphics card among domains (well and the fact that the drivers don't support that either), so an untrusted system can only get it's dedicated GPU, with no sensitive data ever going on the same hardware, and the DMA capabilities of the GPU are kept in check by the IOMMU of the CPU. The host only gets involved in blitting the framebuffer somewhere else for display.