madaidan via Whonix Forum:
dm-verity would probably be the best approach.
That is good. Depends which one can be implemented.
It’s not fatalism. He’s just suggesting we rebase on something sane.
Which doesn’t exist. That’s why I call it fatalism.
That doesn’t make sense. Android is real open source.
That has literally nothing to do with android. It’s to do with other Google apps, not the OS.
That’s not true at all.
Well, they used to play games:
Linux and even the protocols used for HTTP/2 and HTTP/3 are developed by Google. Are we going to just move away from Linux and the web too?
Google only violates privacy with some of their services. AOSP itself doesn’t have any issues.
Building on top of google is risking to build on top of sand. Ask
Huawei. See:
https://onezero.medium.com/the-huawei-disaster-reveals-googles-iron-grip-on-android-b1ccee34504d
Business interest had overweight a solid technical design where such as
license removal wouldn’t lead in such as disaster for Huawei.
Linux and even the protocols used for HTTP/2 and HTTP/3 are developed
by Google. Are we going to just move away from Linux and the web too?
It’s colorful. Not black and white. Building on top of ASOP is risky,
dnless ready to maintain all oneself (or likely someone else doing that)
is risky.
I couldn’t fork/maintain if in theory Debian went evil but then I think
it’s likely others would be able to and do that.
With protocols such as HTTP/2 and HTTP/3 which are implemented by
browsers and web servers there’s now little power that Google could
abuse. Seems very different to me.
Google has already shown that they play games. Therefore I wouldn’t risk
to rebase on Android.
That criteria isn’t necessary.
Necessary no, but a justification for the workload.
Compare it to other inits.
Freedesktop Systemd : Security vulnerabilities, CVEs
Runit : Security vulnerabilities, CVEs
A single vulnerability in runit in 2006 vs 20 consistent vulnerabilities in systemd.
Would be more useful to compare runit to systemd core, pid 0 (init).
I am having difficulties finding any vulnerabilities in systemd core.
That list looks huge but for example “systemd-resolved through 233
allows remote attackers to cause a denial of service (daemon crash) via
a crafted DNS response with an empty question section.” That was a bug
in systemd-resolved, not systemd core. systemd-resolved wasn’t / isn’t
needed / used in Whonix.
Measuring only by CVEs also isn’t the best.
Lennart also won a pwnies award for lamest vendor response in 2017 https://pwnies.com/archive/2017/winners/
[1] This goes back to:
As per:
Those are trivially re-implemented with bubblewrap.
Seccomp:
--seccomp
Capabilities:--cap-add--cap-drop
Private-tmp:--tmpfs /tmp
Private devices:--dev /dev
Read-only directories:--ro-bind /dir /dirHaving some sandboxing features can’t make up for the large attack surface systemd adds.
systemd has excellent functionality. Whonix source code:
find . -type f -not -iwholename '*.git*' | grep systemd | wc -l shows
143 matches. Re-implementing that… Moving away from systemd isn’t
trivial at all and unrealistic with current project resources.
All of
systemd/src/core(which I assume is the main init part, hard to tell due to the way systemd is layed out) is 53,044 LOC compared to OpenRC’s 13,423 LOC. All of systemd is over 400,000 but that wouldn’t be a fair comparison.
Same as [1].
Other inits such as OpenRC, runit etc. are available in Debian.
But not well supported by packages because not the default init system.