Thoughts on security of Kicksecure (debian based linux distribution)??

mrket

argante I remember that it was pointed out once that Red Hat has the copyright to coreutils and can block distribution of these programs.

coreutils is free software, they can't block distribution even if they did hold the copyright to every single line of code (which they don't, GNU coreutils is, unsurprisingly, a GNU project).
Even if someone managed to obtain the copyright to every line of code in coreutils and subsequently relicensed it under a non-free license, previous versions will still be distributable under a free license (a good example of this is the relicensing of Elasticsearch and the creation of the OpenSearch fork as a consequence).

argante

mrket I agree with what you wrote. I just wrote that there was such a discussion a long time ago. An even better example is the Redis drama. Forks were simply created and life went on. Will anyone trust Redis again now? They don't think so, because why would they?

avaluedcustomer

TGOS My personal opinion on this: the guy that forked X11 is the hostile one, not those that don't want to use it.

mushix99

GrapheneOS Neither Kicksecure or Whonix is trustworthy and the fact that Whonix gets so frequently naively promoted is problematic. Whonix should be completely replaced by a serious project with developers who understand and care about security.

These are quite hard accusations - could you elaborate? I am not biased, but would like to understand the reasoning behind.

For the record, I never have used both OS so far. In particular I was interested in secureblue and stumbled on this thread.

It seems Kicksecure has similar kernel hardening features as secureblue.
SELinux in general probably is a more flexible and stricter MAC than AppArmor, with policies being added in a more consistent way throughout whole Fedora system, whereas AppArmor profiles are provided only for several apps.
Both projects are conscious about and have overlaps in various topics like setuid, permissions, capabilities.
There is a section in above link about, why hardened_malloc has been abandoned by Kicksecure.
Trivalent seems to be a great Chromum-based hardened browser, similar to Vanadium. It is known, that Chromium outperforms Firefox sandbox in terms of security, but not all use cases demand browser usage.

For sure Debian has weakened security with default settings. But I'd assume hardening options like applied from Kicksecure (or manually) can make it more comparable to distributions like Fedora or secureblue?

ryrona

mushix99 In my opinion, the two greatest security and privacy improvements done by SecureBlue is 1) implementing an app sandbox, Flatpak, and 2) providing an actual secure and private web browser. KickSecure is criticized heavily for claiming to be a secure and private operating system, while at the same time running almost all apps entirely uncontainerized with read-write access to all your files, app data of other apps, and hardware like microphone and webcam, and while also providing a web browser by default that has invasive telemetry enabled and questionable security settings, Firefox. KickSecure has not expressed any interest in implementing any app sandbox, which seems extremely negligent to security and privacy. They said Flathub apps are often not packaged by trustworthy members or in auditable ways, and prefer Debian's reproducibly build package repository, and used this to motivate why not sandboxing apps. They said they would implement a web browser choice app, where you get to pick which web browser you want, but when I questioned the main developer if this app will offer actually security and privacy focused web browsers like Trivalent or LibreWolf, I didn't get any response.

GrapheneOS

mushix99

Secureblue has been around for a tiny fraction of the time Kicksecure but has done far more and has a roadmap of doing much more than they already do. Kicksecure removed most of the hardening they provided, is based on a distribution that's a terrible starting point for it and does not have the privacy or expertise expertise to do much. The person who was adding most of the hardening to Kicksecure left and isn't going to be active in the project again. The lead developer of Kicksecure has views and methods incompatible with providing good privacy or security. It's a stagnant project not doing anything significant. It would be easy for someone to make a Whonix replacement with drastically better security using a better base and actual hardening.

It seems Kicksecure has similar kernel hardening features as secureblue.

It doesn't provide any significant kernel hardening. Sysctl configuration can barely do any hardening at all. Enabling hardening requires building the kernel with a different configuration to enable the upstream hardening features such as CFI and adding patches for stuff that's not upstream. This is not an area where secureblue does much yet according to their documentation, although that might be outdated, but it doesn't mean they won't.

https://www.synacktiv.com/en/publications/exploring-grapheneos-secure-allocator-hardened-malloc is good coverage of hardened_malloc. It should be noted that what the Kicksecure developer did is send off a bunch of requests to use hardened_malloc to various projects without explaining it or why it would be useful, then he used the negative response to unexplained feature requests by developers expecting someone to tell them why this would be useful as an attack on hardened_malloc. The situation demonstrates their dishonesty, manipulation and overall highly untrustworthy behavior.

https://www.synacktiv.com/en/publications/exploring-grapheneos-secure-allocator-hardened-malloc is a good article explaining hardened_malloc beyond a couple minor things: it misses the write-after-free check for non-MTE and doesn't properly explain the difference between Scudo's 16-bit CRC32 inline metadata checksums vs. hardened_malloc having 8 byte random canaries with a zero leading byte for the non-MTE case. The canaries in hardened_malloc are simply padding between allocations which is random per slab because it can be and has a zero leading byte to block C string overflows. In Scudo, it's a CRC32 checksum to protect the inline metadata which incorporates a global secret and the address. hardened_malloc could use a calculation to combine the address or slot number into each canary but it would be fairly pointless. The canaries are mostly only checked on free, which is often too late to stop an exploit from a linear overflow anyway vs. MTE catching it immediately and deterministically with how hardened_malloc uses it.

The mistake in Whonix making these attacks on GrapheneOS is that

SELinux in general probably is a more flexible and stricter MAC than AppArmor, with policies being added in a more consistent way throughout whole Fedora system, whereas AppArmor profiles are provided only for several apps.

AppArmor is barely used to do anything.

Both projects are conscious about and have overlaps in various topics like setuid, permissions, capabilities.

Kicksecure barely does anything about any of this.

There is a section in above link about, why hardened_malloc has been abandoned by Kicksecure.

The reason they did this was because they were called out about their behavior by GrapheneOS after repeated attacks on us. Kicksecure spreads a bunch of misinformation on their website and began spreading misinformation about GrapheneOS after dropping it. Dropping an important security feature and denying it worked properly or was useful because they're angry at us shows a lot about the project. They also could have avoided repeatedly attacking and spreading misinformation about GrapheneOS. They did that over and over, then seemed shocked we were angry with them. You can find them doing this on their site.

Trivalent seems to be a great Chromum-based hardened browser, similar to Vanadium. It is known, that Chromium outperforms Firefox sandbox in terms of security, but not all use cases demand browser usage.

Firefox is a very bad choice as a starting point but particularly if it's not going to be improved at all.

For sure Debian has weakened security with default settings. But I'd assume hardening options like applied from Kicksecure (or manually) can make it more comparable to distributions like Fedora or secureblue?

Debian's poor security largely comes from the very poor updates and immense amount of trusted packagers. It's a complete disaster in terms of getting privacy/security patches and supply chain security. There are an extremely large number of people who are highly trusted. Many of those people have extremely untrustworthy behavior and actively do things which are very problematic with their power. There are endless political battles internally but people aren't really pushed out because of it, so they stay around holding grudges and even actively trying to sabotage other work. Look into how many people are trusted and the endless internal turmoil about things like systemd.

mushix99

GrapheneOS It doesn't provide any significant kernel hardening. Sysctl configuration can barely do any hardening at all. Enabling hardening requires building the kernel with a different configuration to enable the upstream hardening features such as CFI and adding patches for stuff that's not upstream.

If not mistaken, Kicksecure does compile the kernel with custom config parameters, hence doing hardening beyond syctl. They seem to provide a variant hardened-vm-kernel, which ad-hoc compiles the kernel on local machine for unique kernel pointers, and reduces hardware options to a minimum for faster compile time and better security.

GrapheneOS Firefox is a very bad choice as a starting point but particularly if it's not going to be improved at all.

Maybe that is due to Kicksecure's interdependence with Whonix incl. Tor Browser, which prioritizes anonymity/privacy over security. Tor browser has its own place in terms of anonymity and can't be easily substituted by Chromium-based browser - browser fingerprinting is such a difficult topic on its own. Chrome is a terrible privacy choice, Chromium still has quite a few Google dependencies - iirc that is why Ungoogled Chromium exists. I think to have encountered rare tracking connections (Google) even with Vanadium in the past, but that might have been solved by recent versions. It would be interesting to know, how secureblue's Chromium browser behaves with in this regard. But yes, you're are right, Chromium is the better choice from pure security perspective.

GrapheneOS Debian's poor security largely comes from the very poor updates and immense amount of trusted packagers. It's a complete disaster in terms of getting privacy/security patches and supply chain security. There are an extremely large number of people who are highly trusted. Many of those people have extremely untrustworthy behavior and actively do things which are very problematic with their power.

Interesting point, actually never heard of this perspective . But doesn't Flatpak, which is advocated by secureblue as primary installation method, have a similar issue, with need to trust many individual developers? Debian at least is one responsible organization unit.

ryrona SecureBlue is 1) implementing an app sandbox, Flatpak

But so can Kicksecure, it's even installed as default? Flatpak internally uses bubblewrap sandbox, so to harden Debian repo packages for Debian/Kicksecure I am wondering, if it makes better sense to directly use bubblewrap - or other sandboxes like systemd hardening options, firejail which all make use of linux namespaces, seccomp, capabilities or cgroups to more or less extend. Advantage of secureblue is, it comes with secure defaults, which makes it very convenient to use.

ryrona web browser by default that has invasive telemetry enabled and questionable security settings, Firefox

I wish they would use Librewolf as substitute for Firefox, to make up for Firefox telemetry and ad connections. As stated above, it depends on chromium build at hand, how privacy-friendly this browser behaves. I gladly would take Chromium with ad blockers like U-Block Origin for security and privacy, but Google actively works against all blockers (Addon policy etc.).

ryrona KickSecure has not expressed any interest in implementing any app sandbox, which seems extremely negligent to security and privacy.

At least there seem to be incentives to work on it? https://www.kicksecure.com/wiki/Sandbox-app-launcher

ryrona

GrapheneOS Debian's poor security largely comes from the very poor updates and immense amount of trusted packagers. It's a complete disaster in terms of getting privacy/security patches and supply chain security. There are an extremely large number of people who are highly trusted.

I think you are being a little bit unfair here. Any operating system including GrapheneOS is built using source code committed by a extremely large number of people. Packagers in Debian is also only writing source code, they don't provide any compiled binaries, only source files with build instructions. I don't think any other operating system based on an open source ecosystem is going to be in a much better situation with regard to risk of supply chain attacks. And calling out Debian's poor track record of getting security fixes out, while Google is providing information to attackers about Android vulnerabilities 3-4 months before publishing security patches to fix the vulnerabilities seems a bit unfair. Even before Google's recent changes, security patches had commit dates of at average 2 months prior to release. At least Debian gets out fixes for many high and critical severity vulnerabilities within days of the vulnerability being discovered, even if their coverage may be argued to be somewhat lacking.

I don't think there are much reasons to call out on bad security track record in one project, when there isn't really any project with a good track record. I think it is better to focus on what security features are implemented to compensate for the fact not all source code and build instructions can be considered trusted, and not all security vulnerabilities being patched in a timely manner. And here GrapheneOS is doing a lot, and SecureBlue is also doing more than KickSecure: Sandboxing apps and hardening against memory vulnerabilities.

argante

ryrona I think you are being a little bit unfair here. Any operating system including GrapheneOS is built using source code committed by a extremely large number of people. Packagers in Debian is also only writing source code

I agree with your opinion. There wouldn't be Ubuntu and other clones if it weren't for Debian. Similarly, Google greatly benefits from Gentoo's legacy, as their entire package build system is (or was) based on Portage. Debian has had its share of missteps, but it's important to be clear that Debian is not a security-focused distribution and never has been. Debian seeks its values in open source, and that's their goal.

The problem with this discussion is when someone tries to present Kicksecure as a secure Linux distribution. Kicksecure is based on Debian, which isn't inherently security-focused. Furthermore, the decisions they make tend to increase risk, as users trust their marketing rather than whether something actually works. The abandonment of hardened_malloc is a perfect example of this.

I really like Solar Designer's approach. He initiated the Openwall project and developed Owl, a secure distribution for servers. Years after Owl was discontinued, he still maintains packages for Rocky Linux that port Openwall projects (and also the hardened_malloc from GOS) to this Red Hat clone.

GrapheneOS

ryrona Debian adds an extremely large number of people, many of whom have demonstrated themselves to be highly unethical and untrustworthy. They're not just writing source code since what they write is trusted to obtain and build the packages. Not doing the builds themselves doesn't mean they can't include and ship binaries themselves. Many Debian packagers participating in things like stalking and harassment heavily draws into question trusting the software. It is a much different situation than most community or corporate projects. It's a huge number of people who are trusted and there's nearly nothing done to make sure that group of people is trustworthy or to address people demonstrating they're untrustworthy.

And calling out Debian's poor track record of getting security fixes out, while Google is providing information to attackers about Android vulnerabilities 3-4 months before publishing security patches to fix the vulnerabilities seems a bit unfair.

Debian packages a lot of software regularly having long embargoes. That includes but is far from limited to software covered by the Android embargoes. There are regularly embargoes for the Linux kernel and many other projects, and some are quite long. These are regularly breached and patches sometimes get shipped early by some projects after that happens.

At least Debian gets out fixes for many high and critical severity vulnerabilities within days of the vulnerability being discovered,

That's not the case at all. They frequently go weeks or months without patches for the browser, etc.

I don't think there are much reasons to call out on bad security track record in one project, when there isn't really any project with a good track record.

Debian has a much worse track when it comes to updates and introducing downstream vulnerabilities than most other mainstream Linux distributions.

wuseman

mushix99

At least there seem to be incentives to work on it? https://www.kicksecure.com/wiki/Sandbox-app-launcher

Yeah well, it's been saying that for literally ages now with little to no progress being made.

The last message on the dedicated topic is from January 2023. Almost 3 years ago.
https://forums.whonix.org/t/system-wide-sandboxing-framework-sandbox-app-launcher/9008/375

Remember, that Kicksecure is the project that removed hardened malloc support because "it was too difficult" to get it to work. Meanwhile, it's used on Secureblue just fine. They also supported Firejail by default once upon a time but removed it instead of hardening it or anything like that. The replacement was seemingly to use SECCOMP on everything but that also lead nowhere.

GrapheneOS

mushix99

If not mistaken, Kicksecure does compile the kernel with custom config parameters, hence doing hardening beyond syctl. They seem to provide a variant hardened-vm-kernel, which ad-hoc compiles the kernel on local machine for unique kernel pointers, and reduces hardware options to a minimum for faster compile time and better security.

You've linked an outdated page from when madaidan was involved in the project. Kicksecure is now hostile towards GrapheneOS, secureblue and linux-hardened.

Maybe that is due to Kicksecure's interdependence with Whonix incl. Tor Browser, which prioritizes anonymity/privacy over security. Tor browser has its own place in terms of anonymity and can't be easily substituted by Chromium-based browser - browser fingerprinting is such a difficult topic on its own. Chrome is a terrible privacy choice, Chromium still has quite a few Google dependencies - iirc that is why Ungoogled Chromium exists. I think to have encountered rare tracking connections (Google) even with Vanadium in the past, but that might have been solved by recent versions. It would be interesting to know, how secureblue's Chromium browser behaves with in this regard. But yes, you're are right, Chromium is the better choice from pure security perspective.

No, these claims are highly inaccurate and misleading. Firefox has much worse privacy and security, and it would be dramatically harder to reach the same point obtained with minor changes to Chromium.

Interesting point, actually never heard of this perspective . But doesn't Flatpak, which is advocated by secureblue as primary installation method, have a similar issue, with need to trust many individual developers? Debian at least is one responsible organization unit.

No, Debian has a massive amount of people who are trusted with nearly zero vetting or oversight. Many have demonstrated they're highly untrustworthy. Many have actively abused their positions. Debian trusts not only the upstream developers but also this large group of additional people, who are much less trustworthy overall than the upstream open source developers based on their actions and statements. Flatpak does not provide a proper app sandbox or permission model but it's at least substantial progress towards it.

But so can Kicksecure, it's even installed as default? Flatpak internally uses bubblewrap sandbox, so to harden Debian repo packages for Debian/Kicksecure I am wondering, if it makes better sense to directly use bubblewrap - or other sandboxes like systemd hardening options, firejail which all make use of linux namespaces, seccomp, capabilities or cgroups to more or less extend. Advantage of secureblue is, it comes with secure defaults, which makes it very convenient to use.

No, this is completely wrong. You cannot simply use these things to contain desktop applications. The applications need to be made to work within a sandbox. You're describing individual security features or controls rather than an app sandbox. Firejail also has a history of extraordinarily poor security and does not do what it's supposed to do.

I wish they would use Librewolf as substitute for Firefox, to make up for Firefox telemetry and ad connections. As stated above, it depends on chromium build at hand, how privacy-friendly this browser behaves. I gladly would take Chromium with ad blockers like U-Block Origin for security and privacy, but Google actively works against all blockers (Addon policy etc.).

This comes with significant privacy/security disadvantages rather than only advantages.

At least there seem to be incentives to work on it? https://www.kicksecure.com/wiki/Sandbox-app-launcher

You're referring to a bunch of out-of-date content from madaidan who is no longer working on Whonix or Kicksecure. Most of his changes were reverted and removed, not only hardened_malloc.

GrapheneOS

wuseman The person who was working on the hardening for Whonix and Kicksecure for the kernel, hardened_malloc, MAC policies and everything else they were doing at one point is no longer part of the project. Most of their work was removed and isn't being worked on anymore. Secureblue is the successor to that and Whonix needs to be replaced rather than improved. The lead developer of Whonix heavily spreads misinformation about privacy/security. He's not trustworthy and neither is the project. It should be outright avoided based on these actions alone.

GrapheneOS

argante

There wouldn't be Ubuntu and other clones if it weren't for Debian.

None of these are good choices for privacy or security. Fedora, Arch, NixOS, Alpine, etc. are all much better options.

The problem with this discussion is when someone tries to present Kicksecure as a secure Linux distribution. Kicksecure is based on Debian, which isn't inherently security-focused. Furthermore, the decisions they make tend to increase risk, as users trust their marketing rather than whether something actually works. The abandonment of hardened_malloc is a perfect example of this.

Nearly all of the content on their wiki about hardening was from when madaidan was involved as a Whonix and Kicksecure developer. That's no longer the case and nearly all his work was abandoned. Most was removed or will end up removed.

Similarly, Google greatly benefits from Gentoo's legacy, as their entire package build system is (or was) based on Portage.

There's a lot less substance to this than people claim.

I really like Solar Designer's approach. He initiated the Openwall project and developed Owl, a secure distribution for servers. Years after Owl was discontinued, he still maintains packages for Rocky Linux that port Openwall projects (and also the hardened_malloc from GOS) to this Red Hat clone.

RHEL and clones of it such as Rocky Linux have similar issues to Debian when it comes to incomplete backports though. It's very similar to continuing to use an old Android release via the Android Security Bulletin backports such as still using Android 13, but for a much longer period of time. For the goal of securing RHEL or a RHEL clone while retaining compatibility for companies insisting on using it, it's a very sensible approach to starting on hardening it but it doesn't change the issues associated with using ancient software via RHEL, old Android releases, Debian, etc. Backports are increasingly incomplete over time and major privacy/security advances are missed. Projects prioritizing privacy and security are improving those substantially over time rather than just introducing more and more attack surface, bugs, etc. and not making progress on making things better via safer programming languages, sanitizers, fuzzing, other tools, sandboxing, more secure architectures, exploit protections and much more. Android gets very clearly more secure with each major release, even if most other projects do not generally do that such as the upstream Linux kernel.

ryrona

GrapheneOS It is a much different situation than most community or corporate projects. It's a huge number of people who are trusted and there's nearly nothing done to make sure that group of people is trustworthy or to address people demonstrating they're untrustworthy.

Believe me, there are a lot of users and downstream projects that are auditing Debian. If the "anyone can submit packages to Debian" approach constituted a significant risk, we would have seen that by now. The biggest problem with Debian isn't in and of itself this, but that no noticeable security or privacy improvements have been implemented at all since like 2011. Debian has increasingly become obsolete as a project, and unsuitable to build security and privacy focused projects on. While Fedora for example has many running projects to improve security and privacy, projects that are delivering.

GrapheneOS Debian packages a lot of software regularly having long embargoes. That includes but is far from limited to software covered by the Android embargoes. There are regularly embargoes for the Linux kernel and many other projects, and some are quite long. These are regularly breached and patches sometimes get shipped early by some projects after that happens.

My point was that in AOSP all security vulnerabilities are disclosed 3-4 months before fixes are allowed to be published. There are embargoes in other open source projects too, but not in most. I have seen Debian having fixes out for high and critical severity vulnerabilities within 3 days of a vulnerability being discovered on many occasions. We will never see that in AOSP. Other projects are releasing patches to fix vulnerabilities quickly, but aren't allowed to disclose information about what the vulnerability is beyond the patch fixing it. In fact, that is the most common kind of embargo I see in open source projects. And that makes way more sense than what AOSP is doing.

I just wanted to say your statement is a bit unfair. I am not saying Debian has a good track record at all of getting fixes out, I very much know they don't. But AOSP is also terrible in this regard, and you know it.

argante

GrapheneOS RHEL and clones of it such as Rocky Linux have similar issues to Debian when it comes to incomplete backports though.

I completely agree. All corporations, including Microsoft, are struggling with this problem. They might not patch a vulnerability for months because it could break client-side compatibility. On the other hand, they strive to create increasingly complex solutions, thus only expanding the surface of possible attacks.

GrapheneOS Firefox has much worse privacy and security, and it would be dramatically harder to reach the same point obtained with minor changes to Chromium.

Firefox - this project has been destroyed.

The Mozilla Foundation was co-founded by Brendan Eich, the creator of JavaScript. During his tenure as CTO and CEO, Firefox experienced rapid growth. Of course, Chrome competed, but IE was the main loser here, while Firefox was less affected. Eich introduced numerous innovations. During his tenure, Mozilla pioneered the Rust language and planned to use Servo as the new engine for Firefox. Firefox was to be completely rebuilt from scratch – this time using a new, secure language developed by Mozilla. Eich was forced out of Mozilla (2014) because he was too conservative and not progressive enough (in the ideological sense). And so, the technical person was replaced with a white-collar job. Since then, Mozilla has been coming out with increasingly stupid projects. They got rid of Rust, abandoned Servo (Mozilla's employees layoff in August 2020), and Firefox development has stalled. However, this hasn't stopped the CEO from receiving a multi-million-dollar salary (Mitchell Baker: 2018: $2.46 million, 2020: >$3 million, 2021: >$5.5 million, 2022: >$6.9 million). Meanwhile, Firefox has ended up with a 2-3% market share (when Eich was still CEO, it was around 18%?). After leaving Mozilla, Eich co-founded Brave (2015), and that browser is doing much better than Firefox. Currently, Mozilla doesn't have the resources to rebuild Firefox, so as far as I'm concerned, the project is dead. Their latest idea for Mozilla was even a contradiction of the values that should have guided it: they changed the Terms of Use, which gave them the ability to sell user data. They withdrew from this after protests, but it shows what is in the minds of the people currently behind Firefox.

You can easily verify all the information I have provided yourself.

mushix99

GrapheneOS You cannot simply use these things to contain desktop applications. The applications need to be made to work within a sandbox. You're describing individual security features or controls rather than an app sandbox.

Not sure, if I understand your point here. In general an app sandbox should enforce restrictions to apps, not the other way round, relying on apps to support sandboxes.

Also I asked about using systemd hardening directives or bubblewrap as sandbox, not re-inventing the wheel and using single security features on their own. Are you saying, that systemd options and bubblewrap are not effective sandboxes for desktop and server apps?

I am including server use case here, as secureblue explicitly is promoted for servers and Debian, which Kicksecure is based on, makes a popular server OS. Note that above guide marks systemd as insecure, but those referenced links are nearly a decade old - any hints about its current security state are welcomed.

Thanks anyway for mentioning, that Kicksecure does not use kernel hardening config anymore and docs are outdated, wasn't aware of this.

crunched

GrapheneOS I am curious on what you would recommend instead of Whonix for accessing Tor? Would love to see a better project come to fill this space.

mushix99

mushix99 Are you saying, that systemd options and bubblewrap are not effective sandboxes for desktop and server apps?

... also assuming, kernel hardening - if possible - and proper app MAC policies (AppArmor, SELinux) are part of the sandbox.

GrapheneOS

mushix99

Also I asked about using systemd hardening directives or bubblewrap as sandbox, not re-inventing the wheel and using single security features on their own. Are you saying, that systemd options and bubblewrap are not effective sandboxes for desktop and server apps?

Those cannot sandbox desktop applications on their own rather than being tools used as part of an actual sandbox. The systemd hardening features are mostly requests for features which are not necessarily available and will not cause the service to not run when they can't be used for one reason or another. Only a few of the options are treated as mandatory. They're meant for enhancing uid/gid based isolation of services. Most will not work in a user session and most of those features will silently fail to do anything in that environment.

mrket

mushix99 In general an app sandbox should enforce restrictions to apps, not the other way round, relying on apps to support sandboxes.

To effectively sandbox an app while keeping it functional you need the app to know how to operate within a sandbox, and to have systems designed to allow apps to access what they need outside the sandbox in a secure way.

On desktop Linux some Flatpak apps use portals to access resources which are only available outside the sandbox, for example, but not all apps support portals and portals are still not able to provide access to every resource which apps may require (see for example how any Flatpak app which needs access to controllers has full access to /dev AFAIK).

If you just use bubblewrap or some other tool to sandbox a random app you will either have to figure out how to let it access portals if it even supports them (by exposing D-Bus to the sandbox, preferably using xdg-dbus-proxy, though some portals require more than just access to D-Bus), and/or allow it to access resources it needs outside the sandbox by specifying them before the app runs.

You will also need to handle things like filtering system calls with seccomp (not a trivial thing to do effectively even though bubblewrap can load seccomp filters); some programs like Chrome and OpenSSH restrict their own usage of system calls with seccomp.

ryrona

crunched I am curious on what you would recommend instead of Whonix for accessing Tor? Would love to see a better project come to fill this space.

Please note that the critique discussed in this thread has been against KickSecure, not Whonix.

Although Whonix is based on KickSecure, Whonix does implement many very strong protections and makes very much sense as a security and privacy focused project. Whonix runs the gateway and workstation in separate virtual machines, basically preventing all risks of the workstation being able to bypass Tor or fetch information that can deanonymize you such as which Tor guards you use, your public or local IP address, your MAC address or other hardware identifiers, and so on. Even in the case where the workstation has been completely compromised by an attacker. Whonix by design also encourages separating your anonymous activity from other activity, by only using Whonix for anonymous activity, thus encouraging the user to apply a kind of security domain isolation, which is a very good model of usage. You can even spin up a separate workstation for each use case.

KickSecure on the other hand is just a regular desktop Linux system, and does not implement any isolation that makes sense, and does not encourage the user to use it in a secure way. KickSecure is an improvement over Debian, but a rather mild improvement, whereas SecureBlue is a much bigger improvement. But for the use case of anonymous web browsing, Whonix is unrivaled and an excellent project. Only Tails comes close.

« Previous Page Next Page »