Droidspaces
1.22K subscribers
243 photos
26 videos
31 files
105 links
Download Telegram
Droidspaces
Photo
Implemented per-container resources dashboard πŸ˜‹
πŸ”₯8πŸ—Ώ2πŸ’©1
Lemme cook πŸ—Ώ
πŸ”₯11πŸ—Ώ6🀯1😱1πŸ’©1
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.
πŸ’©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:

CONFIG_CRYPTO_USER_API_AEAD=y

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.
❀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 ❀️
😨3πŸ’©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 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
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.
πŸ‘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!
❀10πŸŽ‰4πŸ’©1
LET HIM COOK

#meme
😭7😁5πŸ—Ώ5πŸ”₯2πŸ’©1
DroidSpaces vs. Termux+LXC Duct Tape

Testing the limits of containerization on a literal potato:

Device: Galaxy A16 5G
Chipset: 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