31–40 of 88 posts
Earlier quoted context omitted.
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".
This 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…
Running everything in a web app is, admittedly, a fundamental change in the stack. But it's fortunately one where a lot of people have independently put work into making this happen. I do my most security-sensitive work on a Chromebook (using the SSH and mosh apps from the Chrome app store) for precisely this reason: it's the right security model, and it's available in my local computer store and works.
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).
I don't know what you base that opinion on since it's not an easy comparison to reason about. One metric you could use would be actual vulnerabilities. In the last year there have been several hypervisor escape vulnerabilites that compromised Qubes OS VM isolation completely, most (all?) of which have been present in Xen for the entire lifetime of the Qubes project.
By contrast during the same period only one Linux kernel vulnerability (DirtyCow) affected Subgraph sandboxed applications, and it would only have been exploitable using techniques which have not been disclosed in any public exploit so far.
This 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…
The well-developed, well-security-researched, well-deployed application platform you're looking for is the web. You get exactly this sort of setup if you use WebGL: you interact with an API that expects to be called by unprivileged hostile applications, instead of with a library that helps your direct access to the graphics card driver. Every individual application lives in a separate protection domain (an HTTP origi…
E.g. I would go so far, that it shouldn't be possible by default for the server to send me a huge HTML/CSS/JS blob that does all kind of weird stuff (e.g. reporting to the host, mouse movement analysis, etc.).
I am probably in a minority with the following opinion, but I think a page shouldn't even have the ability to enforce a layout which in the end draws pixels on your screen. The web is a step forward and HTML is a good idea, but it is not used anymore in its intended form - it works very well for text distribution, but richer applications have to resort to JS.
Now if you disable JS you could in theory render it as you like, but this is far from trivial.
//edit:
Lets consider a bus company offering search to find offers that get you from A to B (i.e. a route planner, trip finder, ...).
This app shouldn't ship you random HTML/JS, but just the information you need to query its database, which is simply some GETing and POSTing of specified requests. When connecting to the app (going to https://trip-search.example.com) the host could disclose it self as an application having type `(From, Date, To, Date) -> Maybe TripList` or something like that (I think one gets the idea).
The web is great, but I think security should and must go further, I do not want run random Turing machines.
This 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…
The well-developed, well-security-researched, well-deployed application platform you're looking for is the web. You get exactly this sort of setup if you use WebGL: you interact with an API that expects to be called by unprivileged hostile applications, instead of with a library that helps your direct access to the graphics card driver. Every individual application lives in a separate protection domain (an HTTP origi…
> I do my most security-sensitive work on a Chromebook
I would highly recommend you use a WebGL whitelist then. WebGL might have been designed with security in mind, but the OpenGL drivers which it, nevertheless, is a very thin wrapper around were, I can assure you, not written with security in mind. WebGL allows some surprisingly direct ways of manipulating hardware and there are a million attack vectors lurking in every WebGL implementation/OpenGL driver combination.
Earlier quoted context omitted.
The well-developed, well-security-researched, well-deployed application platform you're looking for is the web. You get exactly this sort of setup if you use WebGL: you interact with an API that expects to be called by unprivileged hostile applications, instead of with a library that helps your direct access to the graphics card driver. Every individual application lives in a separate protection domain (an HTTP origi…
You are right, that is the most secure platform at the moment to distribute graphical user interface programs, but I think it should go further. E.g. I would go so far, that it shouldn't be possible by default for the server to send me a huge HTML/CSS/JS blob that does all kind of weird stuff (e.g. reporting to the host, mouse movement analysis, etc.). I am probably in a minority with the following opinion, but I thi…
I do certainly agree that we need a way of distributing hyper-text content efficiently and in a standard way. Unfortunately the web seems to be moving away from that goal, and AMP isn't quite right and has its own problems.
I'm not sure how I feel about permissions by default. I think permission fatigue is definitely a thing, and for most apps I don't actually care about them exfiltrating mouse movements to the host, as long as they can only exfiltrate it to the one host. On the other hand, I'm a little weirded out that if I plug my piano into my Chromebook, JavaScript can receive and send MIDI events without any permission prompt.
EDIT to your edit: I'm totally okay with running random Turing machines, if their execution environment is constrained (which it is). The only resources that an arbitrary Turing-complete programming language can access are any external resources that it's specifically given an interface to, and time/memory/power consumption. The web platform is pretty good (though, yes, not perfect) at locking down the interfaces given to JS. So it's just a matter resource limits, which is fairly easy; I'm not always thrilled with how much CPU and battery life Twitter takes, for instance, but it's always killable. (Again, in theory.)
You can construct something that's capable of using plenty of memory or power out of any sufficiently powerful Turing-incomplete language. See, for instance, CSS. (I bet with the mechanism you're proposing, you can end up chaining server-side APIs in ways that let you DoS the client, because the server is always more powerful.) And given how easy it is to achieve Turing-completeness by mistake, it doesn't seem like a productive constraint.
Earlier quoted context omitted.
The well-developed, well-security-researched, well-deployed application platform you're looking for is the web. You get exactly this sort of setup if you use WebGL: you interact with an API that expects to be called by unprivileged hostile applications, instead of with a library that helps your direct access to the graphics card driver. Every individual application lives in a separate protection domain (an HTTP origi…
> You get exactly this sort of setup if you use WebGL > I do my most security-sensitive work on a Chromebook I would highly recommend you use a WebGL whitelist then. WebGL might have been designed with security in mind, but the OpenGL drivers which it, nevertheless, is a very thin wrapper around were, I can assure you, not written with security in mind. WebGL allows some surprisingly direct ways of manipulating hardw…
Earlier quoted context omitted.
You are right, that is the most secure platform at the moment to distribute graphical user interface programs, but I think it should go further. E.g. I would go so far, that it shouldn't be possible by default for the server to send me a huge HTML/CSS/JS blob that does all kind of weird stuff (e.g. reporting to the host, mouse movement analysis, etc.). I am probably in a minority with the following opinion, but I thi…
I'm not sure I get why enforcing a layout is a problem from the point of view of application distribution - if nothing else, an app should be able to embed a text renderer and draw onto a itself. (It's probably a terrible idea, but it should be able to, because a text renderer is just a program that takes in data and outputs some pixels, and that class of programs is useful.) I do certainly agree that we need a way o…
Yeah, but in my opinion that is already a specific type of application, like e.g. a computer game, PDF viewer, plotting application.
It is totally different from e.g. an application like Wikipedia or a news page, that provides mostly text and images.
In the end there should just be more of the functionality on client side (rules how to render news pages, how to render wikipedia, etc.).
This 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 i…
Earlier 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.
https://www.youtube.com/watch?v=Nol8kKoB-co
I believe Joanna from Qubes also set-up this forum for discussions on secure operating systems:
Joanna also talked a bit about the trade-offs between the two here:
https://secure-os.org/pipermail/desktops/2015-October/000002...
I believe initially there were some discussions to integrate Subgraph into Qubes as a TemplateVM (just like the Debian VM, Ubuntu VM, etc), but the Subgrapth guys thought Grsecurity wouldn't work well with Qubes OS. I think that situation has improved, and there is some progress in making Grsecurity work with TemplateVMs and AppVMs.
https://twitter.com/Phoul/status/801114260881424384
However, even if it does work, I'm not sure how excited the Subgraph guys are about making their OS "just" a Qubes OS TemplateVM. They may think that's the wrong business strategy for them as a company. I'm just saying this as someone watching from the outside. They may actually not believe that at all.
However, I did also notice the relationship between the two projects got a little colder, at least for a while, and in public, after Edward Snowden called Qubes his preferred secure OS.