Fixing the Desktop Linux Security Model

Partners didn’t get access earlier. Nobody got access except Google and they had good reason for it:

We felt that open sourcing it at that point would be difficult because people would try to wedge it into phones and create a bad user experience.

i.e. if they open sourced it, people would try to use it before it’s ready so they only open sourced it once finished.

The apps included in AOSP were never complete implementations. They were just templates and were meant to be replaced.

Google’s other proprietary apps are irrelevant to AOSP. AOSP doesn’t even include them.

Huawei could still use AOSP because it’s open source. They just couldn’t use Google’s proprietary apps.

Complain about Google’s apps being proprietary if you want but don’t pretend it’s the same as the OS.

Would take me a time to get to the bottom of a labyrinth of a said b and c said d…

I actually like Lennart Poettering’s vision a lot he laid out here:

Also the functionality of systemd core, the drop-in config functionality and its success (distribution adaption) doesn’t make it look incompetent at all.

In comparison to Android, the people who reported http://cloak-and-dagger.org, judging by the timeline also didn’t seem to be happy with Google’s way to handle the security vulerability.

Pwnie Awards are plenty as per Pwnie Awards - Wikipedia Debian was also on the list

And also Linux

Brown, Bob (July 31, 2009). “Twitter, Linux, Red Hat, Microsoft “honored” with Pwnie Awards”. NetworkWorld. Retrieved January 3, 2013.

Therefore it’s hard to use that as a criteria for judgement.

That makes my point that they don’t publish git master branch as normal Open Source projects do.

If they are worried, they should just request their trademark replaced with something not to be confused with Google.

Even these getting less and less and harder to use as reported by programmers. Harder and harder to actually make use of AOSP. In comparison, Debian has a ideological commitment to Libre Software. Google not so much. Therefore if I had to bet, I guess it’s more likely that Debian or successors will be usable longer than Android (or successors).

On AOSP website I don’t see any download links. Only source code. Not a single phone is sold with AOSP. Also no pre-made, downloadable ROMS from AOSP website. Doesn’t seem like a usual Open Source project.

It’s similar to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898259#17 - should Microsoft be an upstream for Debian? Is Android an OK upstream? Technically, “none of this necessarily contradicts Debian’s formal standards / Open Source / Free Software definition”.

I could ignore everything else and go with Android for an upstream but there are other factors. Other concepts such as tivoization, malicious feature, antifeature, tyrant software, treacherous computing or DRM (digital restrictions management) are less popular and less well defined. What could possibly go wrong. And therefore Android doesn’t seem like a good choice because in this case even if these concepts are less well defined, it seems a more clear case to me. The question is, is it sane to totally discard any conflict of interest because it is Open Source? Some say yes, I say no.

1 Like

Most distributions don’t care for security so that’s not a good indicator. We could probably even create our own init with compatible syntax with systemd if you want.

I don’t see why you’re comparing it to android.

Debian’s was because of a mistake. It isn’t the same and we’ve already talked about replacing Debian.

And we know Linux is a mess too hence hardened-kernel.

madaidan via Whonix Forum:

Most distributions don’t care for security so that’s not a good indicator.

And security-fussed distributions are also using systemd or don’t exist.

We could probably even create our own init with compatible syntax with systemd if you want.

The main issue is this one:

Then also distributions that went non-systemd such as Devuan. That
doesn’t look easy at all.

And then there were also a lot people working on that.

I don’t see any reason to pick on the init system as there’s a lot
things which arguably could use a rewrite:

Due to this it’s hard to pick which projects to reinvent. Then also
project resources are very scare. Therefore I cannot take up tons of
complex projects.

Issues mentioned in this thread are also ambitious to say the least. I
am also convinced it doesn’t make sense to debate priorities since these
debates are to complex and endless. There’s always an argument which
trumps other arguments.

I guess it’s about to define what I can do with the Whonix project.
There’s things I am good at and things where I am not good at. For now,
certainly I cannot become upstream for tons of new packages and/or
significant amount of C / assembler code.

  • research and implementation project
  • take existing components available from Debian, rare exceptions
  • reconfigure for anonymity/privacy/security according to research results
  • use things which are already documented elsewhere and feasible to
    implement
  • no huge architectural changes such as recompilation of packages from
    Debian / don’t replace systemd
  • if there’s a more secure base distribution, worthwhile, suitable for
    re-basing, rebase to it

I don’t see why you’re comparing it to android.

Because suggestions originate from Daniel Micay who works on GrapheneOS
which is Android based. He has a point in his analysis and there’s lots
of other valid points here too, but I still think it’s not feasible to
address them all at once since there’s always another argument around
the corner invalidating the whole design.

Debian’s was because of a mistake. It isn’t the same and we’ve already talked about replacing Debian.

Debian as far I know didn’t apply any organization or policy level fixes
which would prevent such an issue in future.

1 Like

Being security-focused doesn’t mean they’re interested in doing big security changes. The only one I can think of is AOSP which uses its own init.

The init is the first process started and one of the most privileged processes. A vulnerability in systemd can be critical.

We should fix as much as possible. We don’t have to rewrite the entire OS just to fix one important part.

1 Like

If I may comment as an outsider, it seems as though you guys are getting different subjects mixed up.

The subject line is about the system security model. As the introductory post said, at the moment, Whonix uses a traditional Linux model inherited from Debian, with essentially no isolation between applications. And under that model, a lot of the things you’re talking about seem relatively unimportant.

You seem to have gone afield from the question of making a model change, to talk about point hardening things. And maybe that’s right, because I don’t think you can actually improve the model very much under Debian, Android, or anything else that’s really available. But if you’re going to worry about point hardening, I think you should think first about hardening things that are actually going to be under attack.

Threats and protections

Probably the most interesting remote attackers are people at the “other end” of actual Tor connections. Most of the attack surface available to them is in actual applications, like Web browsers and programs that might be used to view or manipulate downloaded files.

You ship the Tor browser, various archive programs, PDF utilities, media players, etc… and you allow users to install almost anything Debian offers. You can reasonably expect users to downloading Microsoft Word document and viewing them in LibreOffice, to view PDFs with random viewers, to play potentially hostile audio and video files, and to do all sorts of other risky things with applications.

Those application programs can leak data over Tor. More relevant to the sorts of issues you’ve been talking about, though, is the fact that if something manages to completely break through one them, then all of the interesting information inside the workstation becomes available by design (and what’s brilliant about Whonix is that what’s exposed at least does not include the real IP address or computer serial number or whatever).

If you don’t have isolation between the applications, then things like kernel bugs and systemd bugs really don’t matter very much, especially not on the workstation.

The things you’ve talked about that actually harden the applications are things like libc (but I suspect the vast majority of the applications’ bugs are in their own code) and stack protections (which are mostly compiler options that you could perhaps turn on). Changing the model to isolating applications would be a win… but I’m going to argue that that’s too hard.

Kernel hardening and the init process are second order issues. They will only really start to matter after you have application isolation.

On the workstation, there’s almost zero remote kernel attack surface. There is truly zero remote systemd attack surface. If a remote attacker can interact with the workstation kernel or systemd enough to really exploit them, that implies that that attacker already has all the interesting information in the workstation, and has therefore already owned “the user’s data”

The only reason to try to elevate privilege once you were inside the workstation would be to try to attack the host via hypervisor bugs… which may or may not actually require you to be running in kernel mode at all. The hypervisor presents a really large, really weird attack surface for any code code at all running in either the workstation or the gateway VM. And it’s an attack surface that’s easy to forget about.

The gateway VM is a little different from the workstation, but systemd bugs and most kernel bugs still seem relatively uninteresting there.

Both remote attackers and attackers who’ve already owned the workstation will have reasons to target the gateway.

Truly remote attackers, on the other ends of Tor connections, are going to have to get into the workstation first to get access to most of the juiciest targets on the gateway. They have almost no direct access to the gateway’s kernel, only a bit more to the Tor process, and none at all to services like systemd. To even poke the TCP/IP stack, they would have to own the workstation first.

I’m not going to say that nobody at all might attack the gateway from a more local “remote” position… but even an attacker on the LAN only has access to the gateway’s IP stack and relatively limited parts of its Tor process.

So, if you were going to talk about changing OS platforms, I’d suggest you think much more about application hardening and isolation, and much less about stuff that’s far from the attack surface… like the init system.

And now I’m going to argue that you can’t do the isolation.

Isolating in Debian

To isolate applications in Debian or any traditional Linux environment, you’d have to deal with a bunch of stuff that would break applications if you changed it. Long before you hard to worry about the kernel or init system, you’d run into probably-insurmountable issues with things like…

  • X11. X doesn’t isolate its clients at all. Any program can mess with the keyboard, clipboard, other applications’ displayed windows, and who knows what else. There’ve been various attempts to fix it, but they’re hard to get working and most of them don’t get maintenance. It was a bad design even by 1985 standards. I had to tell the CIA as much in about 1990.
  • The fact that applications largely expect to share the file system name space with one another, and can get pretty unusable if they don’t share at least a lot of it.
  • D-Bus. This passes around a huge number of messages that ask for who-knows-what, which results in a complicated security policy, much of it defined per-endpoint by developers who may not have much clue.

Basically I don’t think you can do it, period. It’s too big a project.

I also don’t think you could do it in Android.

Isolating in Android

Android does try to isolate applications from one another. An application at least has a chance of keeping a file private. Something properly written to take advantage of the isolation can get something out of it. A nice contained application like a cryptocurrency wallet can get something out of it.

… but you’d be forced to give your users a lot of applications that weren’t written with so much care, and the system is complicated enough that not only will it probably have breaking bugs, but it almost guarantees bugs in how applications use it.

It’s not really true that Android has a model for isolating applications. What it has is a huge collection of shared resources and IPC endpoints, each with its own ad-hoc set of security restrictions. The whole thing is kind of reminiscent of D-Bus, but even more weird and complicated and used by far more programs. Those resources and restrictions change so much that Android has to formally version the API; each Android app actually declares which version it targets.

A lot of Android’s IPC-based APIs let one application ask another, or some part of the system, to do things that might result in network traffic… and the recipients of those requests rarely worry at all about what information that traffic will leak. Lots of services are architected to expect to work with “the cloud” in various ways. You can take that stuff out (which is what I think GrapheneOS tries to do), but you’re fighting the architecture all the way.

Furthermore, Android’s best supported method of sharing data files among applications, the one that’s by far the most commonly used by actual programs your users might want to run, is to dump them all into a big shared directory tree with no meaningful security controls at all. There’s this nifty “provider” API that nothing uses… and then there’s the unstructured shared storage that everything uses. And even when isolation is enforced, it tends to be more like “give application A access to all data in application B”, rather than “give application A access to this particular document”.

So you get limited practically useful application isolation from Android.

I also agree with Patrick that it would be a bad idea to become dependent on Android. In the end, Google will take Android in whatever direction benefits Google, and that’s not likely to include caring at all about whether the core system is in any way useful for anonymity. It may not include caring about whether AOSP without the Google apps and services is even usable at all. And it probably won’t include caring about privacy in general, or at least about privacy from Google.

For that matter, a lot of real third party Android apps are actively hostile to anything resembling anonymity. Dominant apps actively try to circumvent any privacy controls that Google does bother to put in place. Not only are those apps dangerous in themselves, but they still provide the functionality that users need… which makes it hard to generate demand for alternative apps with better privacy, and drives the overall ecosystem away from what youw want.

A random Debian program has more access to other apps’ data… but is far less likely to be deliberately trying to thwart the aims of Whonix than a random Android program.

You could end up having to maintain a huge amount of divergent code if you went with anything based on Android.

Upshot on isolation

To be honest, I can’t even think of any realistically usable operating system that has a good isolation model. The closest thing would be something like Genode’s Sculpt, and that’s just not ready. In fact, I think you get more actually useful security by being integrated into Qubes than you’d get by going to, say, Android. At least in Qubes the user can take a document off into an isolated VM and work on it.

You may be able to do some ad-hoc sandboxing with namespace-based stuff like bubblewrap. But be careful; that kind of thing is complicated.

Some random comments on hardening

You’ve talked about syscall filters like Apparmor and SELinux (and the more granular modes of things like bubblewrap), and about anti-buffer-overflow measures like canaries, poisoning, ASLR, “check-before-call”, stack frame reorganizations, etc, etc, etc.

All of these “hardening” measures are hacks. They make assumptions about the behavior of programs that aren’t guaranteed to follow those assumptions. If they work, they work. If they don’t, they don’t. And you have no real way to know whether you’ve gotten them right. The buffer overflow protection ones are especially suspect; I don’t think there are any that don’t have relatively generalizable workarounds.

I’m not saying you shouldn’t use hardening or sandboxing… but if you have a choice between “hardening” a random half-assed application (or library), and finding a good, well-written, well-analyzed, well-tested application written using relatively fail-safe tools, I think you’re nearly always going to get better security with the intrinsically safer application.

I don’t think it’s fair to say that SELinux is harder to set up than AppArmor. There’s nothing intrinsically complicated about what SELinux does. And SELinux comes out of the box with a reasonably nice granular default policy… or at least it does on Red Hat/CentOS/Fedora. I don’t really know about the SELinux policy available under Debian.

1 Like

You’ve written a lot about how kernel bugs don’t matter much when there’s no application isolation yet we are working on application isolation as mentioned in the post. Read the apparmor-profile-everything and sandbox-app-launcher sections.

We’re aware of X11 and it’s already been discussed to death. We’re likely going to switch to Wayland but the current issue is that XFCE doesn’t yet support it. If we can’t switch, I can add X11 sandboxing to sandbox-app-launcher via a nested X server like xpra.

AppArmor supports DBus mediation.

It’s not that complicated. There are only a few main namespaces. Mount, PID, net, IPC, UTS, cgroup and user namespaces. There’s also a time namespace in some very recent Linux version but nothing uses that yet.

The short answer to all of those responses is that I think you’re underestimating how hard it is to do any of that in any useful way, and still keep the system remotely usable even for sophistacted users, let alone naive ones.

The various X security extensions have always failed to get adoption because they break behavior the user expects, and even make programs crash outright. I don’t see how xpra is likely to be very different. Adding D-Bus mediation is trivial, but developing the policy for what messages to actually let through is not trivial. There aren’t very many name spaces in Linux, but deciding what specific items needs to be shared into other processes’ name spaces is still a hard problem… assuming that you can even share them at all at the granularity you need.

In all of these things, the sharing you need to enable is very close to the sharing that will destroy a lot of the security. There are a million details to think about, and any little mistake can hose you.

Also, don’t forget that isolating applications in the sense of programs has serious limitations from the beginning. The user is probably going to use a lot of the programs on the system to process information that’s effectively in “security compartment” X… and a lot of the same programs to process information in compartment Y. To deal with that, you need to isolate different instances of the same program, depending on which data they’re handling. You need to do that without confusing the user beyond all sanity, and without being too vulnerable to likely user errors.

That’s all really, really hard if the programs themselves don’t know at least something about what you’re doing… which they don’t.

On traditional Linux, you’re coming in after the fact and trying to isolate a bunch of pre-existing programs that don’t expect to be isolated from each other, that try to cooperate using the very communication channels you have to sever, and that don’t expect to be responsible for maintaining any isolation at all between different things they themselves communicate with.

On Android, you’re dealing with a developer culture that’s, if anything, more concerned with circumventing the system’s isolation than with assisting it… and there’s still no concept of different instances of the same program. What Android’s application isolation is really trying to do is to let users decide which developers they trust with which data, which is different from generalized compartmentation.

I’m not saying you’ll get nothing out of the things you suggest, but you write as if you think you can get a lot with the resources you have, and I’m not seeing how.

How will sandbox-app-launcher handle use cases when you download or create a file, but you want to open it with another app later? Or when an app wants to open another app? I assume you intend this to work without modifying the apps themselves.

There is a world-writable directory, /shared, you can use to share files across sandboxes. Access to this directory can be configured by the permissions (read-only, read-write, or none at all).

That currently won’t work if the other app is sandboxed too. You’d need to open both apps separately.

That’s going to break a lot of apps that like to open other apps, like for example opening help in the web browser. Or apps that execute other programs to work.

5 posts were split to a new topic: Porting Whonix to Void Linux

Sorry for the late out of context reply, but I just saw this nice thread and want to specifically question the statement that Debian is a massive issue. I should note that I don’t personally use Debian and am not attached to it in any way.
It is well known that Debian stable is (intentionally) very much behind in general software updates, but is the situation really the same for security updates?
It’s worth noting that Debian also has the Testing and Unstable versions that get updates much faster.

More generally, is there available data on the response time to security issues of various Linux distros?
I know of no such resource, but I would think that since Debian is so popular and has a lot of developers and corporate users (for example Google uses Debian as the desktop OS for most engineers),
it can’t be much behind other distros.

I think you made a lot of good points in this post and the previous one. Namely, I agree that isolating applications from one another and the system (especially network facing ones) is the biggest issue to tackle (which, as mentioned above, is “on the roadmap” of Whonix).
I’d just like to comment regarding xpra/X11: although I’m not very knowledgeable about it, I don’t think it’s the same as the X security extensions that failed. Specifically, it runs a separate rootless X server for each client, which means it should be fully transparent to the clients, making it less likely to break any programs. The main issue I foresee is clipboard sharing, though this will be a usability issue and shouldn’t break any programs. To mitigate this, it may be possible to give every program write only access to the global clipboard, and provide a way for them to give the programs read access that is fully transparent to the programs.
Wayland seems like a better long term solution, but it also suffers from some usability issues.

Debian (and others like Ubuntu, etc.) freezes packages for a long time and only backports security fixes that receive a CVE which misses the majority of them. Most fixes don’t receive CVEs because either the developer doesn’t care or because it’s not obvious whether a bug is exploitable at first.

Debian maintainers cannot analyze every single commit perfectly and backport every security fix. They have to rely on CVEs which people don’t use properly.

For example, the Linux kernel is extremely bad at this:

presentation-cve-is-dead/cve-linux-kernel.pdf at master · gregkh/presentation-cve-is-dead · GitHub

Freezing packages is never a good approach. Debian is a major issue and I really think we should switch.

1 Like

A good post on this: Musl as default instead of glibc · Issue #90147 · NixOS/nixpkgs · GitHub

In that case, I guess you could also use Debian unstable?

No, there is no sane Debian version. Debian unstable is potentially even worse since the Debian security team only work on stable.

Madaiadan, appreciate your efforts to harden Whonix, but I didn’t understand what was the suggested base OS if any?