Can anyone try the recently discovered "Copy Fail" vulnerability on Droidspaces?
https://github.com/tgies/copy-fail-c/releases/tag/v0.2.0
Looks like I don't have a supported kernel.
What is expected is gaining root access inside the container or total container escape.
https://github.com/tgies/copy-fail-c/releases/tag/v0.2.0
Looks like I don't have a supported kernel.
What is expected is gaining root access inside the container or total container escape.
π©1
Droidspaces
Can anyone try the recently discovered "Copy Fail" vulnerability on Droidspaces? https://github.com/tgies/copy-fail-c/releases/tag/v0.2.0 Looks like I don't have a supported kernel. What is expected is gaining root access inside the container or total containerβ¦
It seems like Google saved all ya all asses by turning off the core Android kernel configuration necessary for this vulnerability:
But that doesnβt mean we are immune to this kind of attack since non-GKI kernels exist.
We still gotta block the necessary syscalls needed for this kind of attack using seccomp for the greater good.
CONFIG_CRYPTO_USER_API_AEAD=yBut that doesnβt mean we are immune to this kind of attack since non-GKI kernels exist.
We still gotta block the necessary syscalls needed for this kind of attack using seccomp for the greater good.
β€3π©1
Droidspaces
Can anyone try the recently discovered "Copy Fail" vulnerability on Droidspaces? https://github.com/tgies/copy-fail-c/releases/tag/v0.2.0 Looks like I don't have a supported kernel. What is expected is gaining root access inside the container or total containerβ¦
Well, you are vulnerable on Linux Desktop
What happened was a Local Privilege Escalation, not a container escape.
Therefore, this is a kernel issue rather than an issue with Droidspaces.
However, we will work on a fix from our side if possible β€οΈ
What happened was a Local Privilege Escalation, not a container escape.
Therefore, this is a kernel issue rather than an issue with Droidspaces.
However, we will work on a fix from our side if possible β€οΈ
π¨3π©1
Droidspaces
Well, you are vulnerable on Linux Desktop What happened was a Local Privilege Escalation, not a container escape. Therefore, this is a kernel issue rather than an issue with Droidspaces. However, we will work on a fix from our side if possible β€οΈ
okay. we are safe nowπΏ
π3β€2π2π©1
I know. Most users use hw-access by default, and you all want freedom.
But we have to admit this: if your rooting method is compromised, if
Our goal is to make devices real Linux servers that need real capabilities, not sandboxes.
But we have to admit this: if your rooting method is compromised, if
sudo, su, or the kernel is compromised, Droidspaces is compromised too. We can't prevent that.Our goal is to make devices real Linux servers that need real capabilities, not sandboxes.
β€9π©1
Droidspaces
I know. Most users use hw-access by default, and you all want freedom. But we have to admit this: if your rooting method is compromised, if sudo, su, or the kernel is compromised, Droidspaces is compromised too. We can't prevent that. Our goal is to makeβ¦
With great power comes great responsibility
πΏ7β€5π©1π1
I'm going to deprecate support for XFCE tarballs. Users have the full ability to manually install anything they want. Is this a good choice?
Or, you guys can contribute to https://github.com/ravindu644/Droidspaces-rootfs-builder to add support for your favorite distros and desktop environments.
Or, you guys can contribute to https://github.com/ravindu644/Droidspaces-rootfs-builder to add support for your favorite distros and desktop environments.
π8π©1
We reached 800 stars today :)
I hope we can reach 1K stars this month :)
https://github.com/ravindu644/Droidspaces-OSS
Thank you so much for your support!
I hope we can reach 1K stars this month :)
https://github.com/ravindu644/Droidspaces-OSS
Thank you so much for your support!
β€10π4π©1
DroidSpaces vs. Termux+LXC Duct Tape
Testing the limits of containerization on a literal potato:
Device:
Chipset:
The "Duct Tape" Method (Termux + LXC) π€‘
- Setup: 6,999,999 manual config changes, cgroup nightmares, and GPG errors.
- Boot Time: 732ms (Userspace)
- Status: Fragile. White logs. One RAM spike away from being killed by Android.
The Native Execution (DroidSpaces) πΏ
- Setup: Native integration, zero manual mounting.
- Boot Time: 423ms (Userspace) - Nearly 2x FASTER.
- Status: Clean Green [ OK ] logs. Running as a persistent system daemon.
- Pure Cgroupv2
The numbers don't lie. Even on a budget Dimensity chip, DroidSpaces hits
Testing the limits of containerization on a literal potato:
Device:
Galaxy A16 5GChipset:
MediaTek Dimensity 6100+The "Duct Tape" Method (Termux + LXC) π€‘
- Setup: 6,999,999 manual config changes, cgroup nightmares, and GPG errors.
- Boot Time: 732ms (Userspace)
- Status: Fragile. White logs. One RAM spike away from being killed by Android.
The Native Execution (DroidSpaces) πΏ
- Setup: Native integration, zero manual mounting.
- Boot Time: 423ms (Userspace) - Nearly 2x FASTER.
- Status: Clean Green [ OK ] logs. Running as a persistent system daemon.
- Pure Cgroupv2
The numbers don't lie. Even on a budget Dimensity chip, DroidSpaces hits
graphical.target in under half a second ππΏ7β€4π©1