Why are you still going to use dhcpcanon, unmaintained software recommended against by its own devs?
1 Like
written in python
Source please. If it was dead it would be removed from Debian.
What alternatives do you suggest?
1 Like
Just because python is memory safe doesn’t mean you can’t write any bugs in it. There can still be plenty of bugs unrelated to memory unsafety.
I sent it above.
Debian contains tons of dead software.
I don’t know any alternatives.
1 Like
Because that threat model is too high a standard for Whonix. The only maintainable way is: if it’s in Debian = good enough. Otherwise trying to judge software from Debian by its code quality, last release and other factors will open endless, insurmountable discussions.
See also:
sudo apt install debian-security-support
sudo check-support-status
If you wish to discuss this further please open a separate forum thread.
WIP, still not recommended for end users. Testers welcomed.
See TODO
That doesn’t sound very discouraging. That todo file is missing just some features.
(WIP) integrate with Network Manager
listen in several interfaces
implement IPv6
Not security relevant.
1 Like
One of the authors is DrWhax a Tails dev who I trust has his stuff together.
The WIP list is here:
I don’t see some obvious deal breaker and the network manager part seems to have happened upstream. For kicksecure VM at least this isn’t a problem.
Or feature complete. I see no reason for projects that keep adding gigantic changes full of cruft and bugs.
We have to have something to make Kicksecure KVM a viable project at all.
1 Like
Debian contains thousands of packages. Them being in Debian doesn’t make them secure.
Dead projects aren’t looking for bugs either so you won’t know if that’s the only issues with it.
Yet you aren’t trusting the authors’ recommendation not to use it.
1 Like
Similarly a lot software are used in production by thousands of people for years, yet the software calls itself alpha or has some 0.x version number.
A few years ago we had some discussions “replace X (from Debian) with Y (from Debian) because X is more secure than Y”. It’s insurmountable. Even for existing packages used by Whonix. There would be a lot bikeshedding, a lot of theorizing and zero to little input from people who actually have experience/capability to review the code in question / producing vulnerabilities. As long as there is no authoritative source that makes statements about the security of X vs Y, this is not something the Whonix project can fix.
Therefore if software is considered insecure, abandoned, etc. it would be best to report this to Debian since Debian regularly removes packages where that is the case. That’s also why VirtualBox is Unavailable in Debian stable and backports due to Debian Stable Security Maintenance Issues. Just mentioning to dispel possible assumptions that this never happens.
That might be a case of “A said B”, “C understood D”.
There are many reasons to recommend against it such as reliability. But there is no statement by the author “don’t use it because there are likely remote exploitable security vulnerabilities”.
Please ask upstream (Debian package maintainer and upstream author) explicitly rather than making implicit assumptions.
Maybe but Debian was the best base distribution that I could find that time to build on top overall (many criteria…). Until there is something better, usable as base distribution, some distribution that wouldn’t allow unmaintained/insecure software, there is nothing realistically that can be done about this.
Probably same for tons of other packages that Whonix Depends: on directly or their dependencies do.
2 Likes
But how many of those are network-facing and anonymity-critical like dhcpcanon? We shouldn’t pile on dead software just because there’s a few unmaintained programs already somewhere.
1 Like
Great!
That’s a great question! Not only network facing applications. Also any library dependency which is involved in processing untrusted data originating from remote locations. …which makes this a complex problem to analyze. Please feel free to come up with a concept how to create and a list of packages considered network facing and/or anonymity-critical.
The current approach that I described “in Debian = good enough” isn’t great indeed. I don’t like it myself. It’s just something surmountable.
We can’t just only pick on individual applications and then be opinionated about it.
There needs to be some objective criteria. Potentially:
check-support-statusdiscourages it- upstream author thinks it is insecure
- Debian package maintainer thinks it is insecure
- expert opinions (but then also people disagree which makes this not useful either)
- past number of CVE’s of
$TYPEinYtime considered OK or too much - unfixed CVE’s of
$TYPEinY - last upstream release was X time ago
- last Debian package release was X time ago
- Debian package is X releases behind
- last time upstream author commented on the software was X time ago
- security-focused Linux distribution does X
- security-focused Linux distribution says Y
- could be point / threshold based
- this is just a random list without much thought spend on it yet.
Somehow formalized. Similar to Whonix Default Application Policy
Please feel free to work on such criteria too. (Such as: the criteria, why it is a good criteria, why other criteria is unsuitable.)
If we had list of packages considered network facing and/or anonymity-critical and then objective criteria how to judge them it might be even possible to replace X with Y without endless stream of new arguments back and forth for X vs Y. Then it might be possible to see if that is an surmountable task.
For example in theory if we had a rule that said “Debian package wasn’t updated X years compared to upstream” then the number of packages affected by this rule might be so big that there could be no Whonix anymore since there are no replacements that fulfill all of these rules.
2 Likes
I guess the only reliable way is listing all packages installed on the system and reviewing each one. This would be very difficult though. On my Whonix Gateway VM (mostly unmodified), there are 871 installed packages.
Then we should read all arguments and form our own conclusion.
CVEs aren’t that reliable. A project that cares more for security will put more work into finding and fixing vulnerabilities which will make it have more CVEs than a project that doesn’t care for security at all and thus doesn’t attempt to find vulnerabilities.
CVEs can sometimes be useful though as in the case of for example, firejail, it’s evident of a major architectural issue.
More potential criteria:
- memory safety - safe languages such as python, rust, go etc. should be preferred over unsafe languages such as C/C++
- attack surface of the program - can be measured via code practices, lines of code (although this can sometimes be unreliable), if it processes untrusted input etc.
- The Rule of 2
- the program’s track record of security
- the developers - programs created by respected experts are far more likely to be secure than programs created by random people
- exploit mitigations - for example, chromium has support for mitigations such as clang CFI which is very rare on Linux
1 Like
madaidan via Whonix Forum:
I guess the only reliable way is listing all packages installed on the system and reviewing each one. This would be very difficult though. On my Whonix Gateway VM (mostly unmodified), there are 871 installed packages.
That’s it. There’s too many of them. It’s also kinda whack a mole since
dependencies change over time. With that number of packages the process
would have to be at least partially automated.
Then we should read all arguments and form our own conclusion.
Often it doesn’t just require reading all arguments but also outreach,
contacting various people for clarification and/or to trying to make
them talk to each other.
The problem could be reframed. Debian isn’t (a | the most)
security-focused Linux distribution. Under some threat models, Debian is
judged insecure. Issues with Debian then would have to be considered
deeper than technical, i.e. architectural, organizational, ideological
issues. To put it another way (a lot | many | most) (?) Debian
Developers don’t prioritize security over everything else readily
compromising other things such as package availability, features,
usability, etc. That shouldn’t come to a surprise. Debian slogan is “the
universal operating system”. Not “attempting to be the most secure
operating system” and therefore Debian didn’t attract that mindset.
Debian consists of mostly volunteers that need to attend to day jobs
which might arguably not be the best for security either.
Then also upstream distributions can mostly only package available
upstream software but not re-write most. Though, a lot upstream software
was created with priorities and not necessarily highest security in
mind. A lot required functionality is only available through “legacy”
software written in memory-unsafe programming languages. The whole Open
Source software ecosystem was never primarily focused on security to
begin with.
I don’t think these deeper Debian issues can be fixed through technical
solutions at the Whonix level. The solution would instead be to rebase
Whonix on Linux distribution that is actually security-focused. I.e. as
distribution that has these security properties and at the same time no
other issues making it unsuitable. Such as distribution didn’t exist at
the time Whonix was created and might no be existing at this time
either, see:
You might want to become founder of a Linux distribution that is similar
to Debian but explicitly security-focused.
CVEs aren’t that reliable. A project that cares more for security will put more work into finding and fixing vulnerabilities which will make it have more CVEs than a project that doesn’t care for security at all and thus doesn’t attempt to find vulnerabilities.
Agreed. Good to add to wiki.
CVEs can sometimes be useful though as in the case of for example, firejail, it’s evident of a major architectural issue.
More potential criteria:
Good points to explore.
- exploit mitigations - for example, chromium has support for mitigations such as clang CFI which is very rare on Linux
https://www.youtube.com/watch?v=31xA9p3pYE4 didn’t sound promising on
security improvements overall. Quoting freely. “More and more companies
(such as google chrome to pick one example among a trend) move to an
approach where security bug reports are disregarded unless a proof of
concept exploit is being provided. Mitigation methods for bad,
potentially exploitable code are preferred over actual security bug
fixes because there is too much source code, complexity is too high and
the total number of bugs is unmanageable.”
1 Like
Desktop Linux in general has plenty of architectural issues which makes it insecure. It lacks any proper security model, all applications have access to each other’s data, most things are written in memory unsafe languages, the kernel is lacking in exploit mitigations and has ever-increasing attack surface etc. We can fix some of these in Whonix (see apparmor-profile-everything, sandboxing, hardened-kernel etc.)
Debian in particular has issues as packages don’t receive all security fixes. Take the kernel for example where Debian only backports fixes with a CVE yet kernel devs rarely give CVEs to security bugs resulting in kernels shipping with known vulnerabilities.
I’m not aware of a distribution like that.
That’d be a lot of work and I’d lack the resources. Maybe in the far future.
That sounds very promising to me (I haven’t watched the video, just going by the quote). What would you prefer? A single bug fix or an exploit mitigation to kill entire classes of vulnerabilities?
1 Like
Mitigation might make previously exploitable bugs non-exploitable or harder to exploit. However, mitigations might in future be circumvented. See these quotes related to mitigations: Quotes and testimonies | Is OpenBSD secure?
Mitigation don’t fix the root cause that is bad, potentially exploitable source code. It’s a messy attitude “we are aware of the mess, but don’t want to fix these issues but rather but a patch on top”. Mitigation are great (for yet unknown potentially exploitable bad code, hardening) but the root issues should be fixed nonetheless.
1 Like
And new bugs of the same class can be found or bug fixes can be faulty.
Those are related to OpenBSD’s mitigations which aren’t exactly the best, not mitigations in general.
The true root cause is usually lack of memory safety which nobody is going to fix (everyone is obsessed with C). It’s impossible to fix all bugs so mitigations are necessary. It’s far better to focus on mitigations that kill entire classes of vulnerabilities than singular bug fixes.
This is one of the main problems of the Linux kernel: they focus on fixing individual bugs more than on exploit mitigations. Spender has written on this a lot of times before https://grsecurity.net/~spender/interview_notes.txt
Kees Cook (founder of the KSPP) has also talked about this before https://outflux.net/slides/2016/lss/kspp.pdf
Sure, bugs should be fixed, but fixing bug classes is more important.
1 Like
Got a response on the dhcpcanon issue.
Seems like the only issue would be usability, not security.
2 Likes
What about dbus? Is dbus a security risk? Realistic to pick applications that don’t require dbus?
1 Like
D-Bus is a security risk but it’s the IPC mechanism everything uses. If we were to get rid of D-Bus, we’d be getting rid of half of desktop Linux along with it.
The security issues with D-Bus are mostly solved with sandbox-app-launcher anyway. The app can’t access the system bus and can only access their own session bus (which doesn’t yet exist).
1 Like
Maybe at least we could get rid of d-bus requirement for applications started by users such as ristretto?
I don’t think ristretto’s use of d-bus is essential. Looked into source code. Something to do with poppler. Many applications (image viewer, video player, …) could be simple enough to not require d-bus. …if that helps.
1 Like
4 posts were merged into an existing topic: System-wide sandboxing framework
What’s the security issue with dbus more specifically?
It’s mere existence increasing attack surface? I.e. even if running in a sandbox if any application parses untrusted input then there are more chances to exploit something in dbus?
Or is it that dbus can result in instructions given to other programs that circumvent confinement (MAC)?
1 Like