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

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.

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.

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.

PrivateLoop

ryrona

Could Whonix's level of isolation also be achieved on GrapheneOS, along with using a separate device as a router? Such as https://github.com/radio24/TorBox?

Or maybe it's even better than Whonix, because it is isolated physically?

Just wondering

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

ryrona Believe me, there are a lot of users and downstream projects that are auditing Debian.

I believe you! I'd be more at ease if they didn't do their security audits. This is just one example, but I should add that a Debian developer previously asked on the openssl list if he could remove those two useless lines of code :)

ryrona 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.

The most interesting Debian-based distribution I remember was Adamantix. Unfortunately, the project didn't survive.

GrapheneOS

ryrona

Believe me, there are a lot of users and downstream projects that are auditing Debian.

Not nearly as much as you're implying and it doesn't work as well as you're implying either.

If the "anyone can submit packages to Debian" approach constituted a significant risk, we would have seen that by now.

It's a huge risk and severe vulnerabilities are regularly introduced by Debian packages. It often doesn't get much attention after it happens. We have some past posts about several cases of this happening. Updates are also often delayed far more than just based on freezing packages indefinitely. AOSP has issues with freezing packages too, but Debian is much worse at this than AOSP and Debian is what's being portrayed as doing better than it is here and elsewhere.

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.

Fedora doesn't have modern exploit protections, widespread use of memory safe languages, etc. It's not enabling many standard Linux kernel exploit protections. They still haven't deployed stuff like CFI and are nowhere close to doing basic allocator hardening or advanced features like MTE. There's very little use of sandboxing and SELinux MAC policies are very basic and barely used to do anything, especially for a desktop. Debian is much worse but privacy and security are very stagnant for that ecosystem as a whole.

My point was that in AOSP all security vulnerabilities are disclosed 3-4 months before fixes are allowed to be published.

No, they're allowed to be published right away which we're doing. The source code released is delayed due to a misguided idea that it helps attackers more than it actually does. That being very misguided doesn't mean it is actually forced to be delayed for 3 months. Also, based on what we've seen so far, it's 3 months for most patches and then a steady stream of additions up to 1 month ahead so it's 1-3 months but mostly 3. There's also the time period before they fix and disclose them this way, so that can add 1 or more months on top of the widely disclosed patches to OEMs which are allowed to be shipped early now. The old approach was 1 month early access without being allowed to ship early, now it's mostly 3 months (but to a lesser extent 1-2 months for a smaller portion) but with OEMs allowed to ship as soon as they want. In practice, most OEMs aren't taking advantage of it, but we've noticed Samsung has been doing it throughout this year with a small portion of the patches which will likely grow. Pixel stock OS appears to be doing the same, but not listing the CVEs they fix early despite it being implied in their docs that it must be done. They definitely shipped at least 1 December 2025 patch in the Pixel October monthly update.

I have seen Debian having fixes out for high and critical severity vulnerabilities within 3 days of a vulnerability being discovered on many occasions.

They typically go years without shipping important patches unless a CVE is assigned, which it often isn't. If a CVE assigned, it might be shipped quickly but often isn't. They're also notorious for introducing downstream security vulnerabilities, far beyond the most well known examples like the Debian weak key issue.

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.

GrapheneOS is not AOSP or the stock Pixel OS.

aqua-ghostly

TGOS

Besides from using Kali to pull documents off unencrypted windows PCs Secureblue is my first distro. I'm still somewhat handicapped when it comes to installing stuff but most of my work is done in browser anyway so that is not a problem.

DeletedUser499

If Kicksecure came in Gnome, I would use it in preference to Debian.
I use Fedora and Debian in equal measures. I can't decide which to stick with so I constantly swap from one to the other.
If I go to my online bank I use tails.
I use them, live from USB, without hard drives in my laptops. I get any problems, throw the USB in the bin, download and repeat.

Watermelon

I'm distrusting Kicksecure/Whonix based on just this:
https://www.kicksecure.com/wiki/Mobile_Operating_System_Comparison#GrapheneOS

Edit: And the lead developer said somewhere (I think in a GitHub issue, but not sure) that he only knows scripting, and isn't a programmer. What kind of lead developer of a software project wouldn't know programming? It's bad to trust them to deliver a secure product.

user539

And after all of this endless debate.. What should a man choose as a linux daily drive, silver blue?

Eirikr70

user539 I suppose SecureBlue if you are a security addict, but it comes with severe inconveniences.

user539

Eirikr70 what are those?

KCne

Eirikr70 I suppose SecureBlue if you are a security addict,

secureblue is not intended for security maximalists, their website says

secureblue is for those whose first priority is using Linux, and second priority is security. secureblue does not claim to be the most secure option available on the desktop. We are limited in that regard by the current state of desktop Linux standardization, tooling, and upstream security development. What we aim for instead is to be the most secure option for those who already intend to use Linux. As such, if security is your first priority, secureblue may not be the best option for you.

@GrapheneOS has made clear Linux's unideal security state, especially in this thread. There are already plenty of other threads in this forum discussing OSs that maximize privacy and security, and I have expressed my belief that GrapheneOS itself does a solid job.

GrapheneOS qualifies as a Linux distro, but it is far more private and secure than traditional distros or MacOS. Once Android QPR1 releases for GrapheneOS and there are improvements to Desktop Mode, I believe that will be ideal in privacy and security for many desktop needs

Eirikr70

user539 I don't remember much, but I can recall two of them

you cannot be root in the same session as a standard user,
you can use only half of your processing power.

I suppose that others can give you more precise answers.

p-marg

Eirikr70

you can use only half of your processing power.

https://secureblue.dev/faq#smt

p-marg

I would strongly recommend SecureBlue over Kicksecure. Kicksecure’s hole philosophy and website is a disorganized mess compared to SecureBlue.

I’ve been running SecureBlue on an i5-9400 with 8 GB of RAM for the past two months, with the only issue being FreeCAD not working with HardeMalloc, but honestly, FreeCAD is a mess on its own.

Eirikr70

KCne The question was indeed "What should a man choose as a linux daily drive, silver blue?" Your excerpt confirms my answer.

ryrona

PrivateLoop Could Whonix's level of isolation also be achieved on GrapheneOS, along with using a separate device as a router? Such as https://github.com/radio24/TorBox?

Generally, it is never a good idea to do your own thing if you need security or privacy, unless you really know what you are doing. Whonix has the advantage that competent developers has created it, and many users who depend on its security properties has reviewed both the design, and in some cases even some critical details of the actual implementation. The design is thus likely to be solid, and there is unlikely to exist any obvious leaks that aren't already well-known or documented.

If you were to make your own solution based on GrapheneOS and a separate Tor router, it is solely up to you to ensure the system is secure, and if it isn't and something bad happens, it is solely your own fault. Neither the operating system itself nor the app sandbox runs in any kind of virtualized environment on GrapheneOS, which means hardware details might leak. One has to check very carefully so apps cannot access MAC addresses on the GrapheneOS device. I imagine that this will run over Wifi between the GrapheneOS device and the router, so one has to check that apps cannot access the SSID or MAC address of the router too, since anyone within Wifi radio distance from you can log those with geographical position (think the Google car that used to drive everywhere to build their database over all existing Wifi networks), and that the router does not leak its identity in any other way to apps, and that the transparent proxying on the router cannot be bypassed in any way by the connected GrapheneOS device.

PrivateLoop Or maybe it's even better than Whonix, because it is isolated physically?

Whonix uses virtualization to prevent compromise of the workstation from spreading or bypassing gateway. On GrapheneOS, you would instead rely on the app sandbox for this. The app sandbox is a weaker protection with a much bigger attack surface than virtualization provides. If the attacker can break out of the app sandbox, they can change your Wifi or cellular settings and it is game over.

So no, in best case where you get everything right, it will still be less secure than Whonix.

PrivateLoop

ryrona

Interesting, thanks

I was under the impression, from this post, that GrapheneOS would be more secure than Whonix.

If I favor pseudo anonymity over anonymity (that is, I’m ok with the adversary knowing my hardware details), do you still think it’s a big risk?

But you’re right. The fact that GrapheneOS doesn’t virtualize means that any breakthrough would be able to leak, say, my local Wi-Fi networks or worse.

So virtualization is safer than any exploit protection that GrapheneOS provides (memory tagging, hardened malloc, etc.)?

Also, technically, if an exploit breaks through virtualization, Whonix can still leak Wifi networks from the host machine, right?

Apps AFAIK can’t read MAC addresses from Android 10, but im sure about SSIDs.

Would Ethernet at all mitigate some possible issues?

There’s also https://github.com/GrapheneOS/os-issue-tracker/issues/5081 which seems interesting

argante

ryrona Generally, it is never a good idea to do your own thing if you need security or privacy, unless you really know what you are doing.

Everyone's trying to build something like this on Linux. It's a failure even at the concept stage. Linux and distributions based on it simply have too many security flaws. Even GOS has CVE restrictions, so how could someone on their own do something like this based on Linux?

There are interesting projects, such as Blue-Merle, but Mudi is based on the OpenWRT, so firstly, there are security issues and secondly, the source code for Mudi is probably not even published.

It's safer to simply use TorVPN on a Pixel running GOS. Accessing the network is a bit of a challenge, but if you're at home, you can use something like a PC Engines APU2, but with OpenBSD, which is much more secure as a router base. If you want to avoid WiFi, you can connect your phone via Hagibis (I confirm that it works well with GOS).

« Previous Page Next Page »