search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
536 stars 48 forks source link

Segregation of duty for arbitrary applications #6576

Open 3hhh opened 3 years ago

3hhh commented 3 years ago

The problem you're addressing (if any)

Applications must be adapted to Qubes OS in order to use its "segregation of duty" model.

Examples: split-ssh, thunderbird add-on, qubes-tunnel, ...

Describe the solution you'd like

When I decide that some parts of an arbitrary application (that wasn't explicitly designed for Qubes OS) should be executed inside a different VM, I can configure Qubes OS to do that without programming knowledge.

Where is the value to a user, and who might that user be?

Applications may not only run inside a single VM, but parts of them in multiple whenever it is reasonable to do so from a security point of view.

Users can develop configurations for arbitrary applications (open source, closed source, self-written, ...) themselves and applications do not need to be explicitly ported to Qubes OS.

Think of SELinux with forwarding a configurable set of operations to other VMs.

Describe alternatives you've considered

Current situation with some effort to port applications to Qubes OS (if they are not supposed to run inside a single VM).

Implementation options

Additional context

This is just an idea that came up during https://github.com/Qubes-Community/Contents/issues/103

It might be something for kernel hackers or a PoC at GSOC or so.

Relevant documentation you've consulted

-

Related, non-duplicate issues

-

iamahuman commented 3 years ago

This is more of a reseach subject on virtualization/compartmentalization in general, and such solution's impact would likely be industry-wide. Would definitely need some sort of standardization or funding.

3hhh commented 3 years ago

Funnily enough, something similar was already done as a Bachelor thesis by a student in 2014.

Anyway I think there's more modern approaches available now:

If one would like to enforce the syscall redirection from dom0 (probably not the best approach for Qubes OS), one might want to look at libvmi and/or drakvuf. The so-called semantic problem could be an issue - dom0 does not necessarily know about the internal VM kernel structures.

To intercept syscalls from within a VM, SECCOMP_RET_USER_NOTIF looks promising to intercept syscalls. Firefox and Chrome apparently plan to use it. It has the advantage of being fast and already provides filtering mechanisms via BPF.

Alternatively one could start an application with a fake libc via LD_PRELOAD. That fake libc could then intercept calls to arbitrary libc methods.

Anyway I believe that the hardest part with whatever of the above approaches would be the issue of state: Syscalls may return e.g. pointers to memory areas which would have to be shared across VMs in some secure way. I guess that's why the initial 2014 paper only looked at stateless syscalls... ^^

Another issue might be performance as a user would likely not want to wait 10x as long for his application to respond to interaction.

iamahuman commented 3 years ago

How can one define interface boundaries (which system calls / library calls to be forwarded) without programming knowledge?

3hhh commented 3 years ago

How can one define interface boundaries (which system calls / library calls to be forwarded) without programming knowledge?

Hm well, the configuration would happen via e.g. BPF for the seccomp approach above. But yes, it's a non-trivial configuration-as-code-pattern and requires some basic understanding about syscalls.

However it would be a generic approach to port applications rather than starting from scratch for each one. Also, closed source applications could be ported.

iamahuman commented 3 years ago

So to make it clear, this issue is not about making it easier for users without any technical background to compartmentalize existing "non-aware" apps (or solving the halting problem, for that matter), but rather devising a general approach to ease segregation without modifications to the application binary (recompilation), right?

Except performance, system call segregation wouldn't be the hardest problem here--we already have PTRACE_EVENT_SECCOMP, or worst, we can use dynamic binary instrumentation/rewriting/JIT. The actual problem is twofold:

In general, I believe it's more efficient to operate on existing well-known protocols, such as PKCS#11 for cryptography.

3hhh commented 3 years ago

So to make it clear, this issue is not about making it easier for users without any technical background to compartmentalize existing "non-aware" apps (or solving the halting problem, for that matter), but rather devising a general approach to ease segregation without modifications to the application binary (recompilation), right?

Except performance, system call segregation wouldn't be the hardest problem here--we already have PTRACE_EVENT_SECCOMP, or worst, we can use dynamic binary instrumentation/rewriting/JIT. The actual problem is twofold:

  • How many existing apps can be usefully compartmentalized at the system call boundary? It's possible that the program performs critical operations without involving any system calls (or other easily recognizable in-profram interfaces), such as software cryptography.
  • if segregated, how much state should be shared between the two partitions? The semantic problem can be extended to not only memory sharing but also IPC, filesystems, network sockets, or some communication daemon (e.g. D-Bus) that relay packets between the two. The more state is to be shared, the more complex the system would be, increasing the attack surface in the process and making the problem worse.

True.

In general, I believe it's more efficient to operate on existing well-known protocols, such as PKCS#11 for cryptography.

I didn't understand that last sentence.