Omarchy: Eksploitasi Eskalasi Root lewat Grup Docker pada Konfigurasi Default

Sebuah temuan keamanan baru-baru ini mengungkap bahwa konfigurasi default dari Omarchy, distribusi Linux berbasis Arch yang dirancang untuk desktop, memiliki masalah serius: hampir semua program yang berjalan di session user bisa melakukan eskalasi ke root tanpa password, tanpa sudo, dan tanpa prompt privilege. Akar masalahnya sederhana, user default menjadi anggota grup docker.

TL;DR

• Konfigurasi default Omarchy, distribusi Linux berbasis Arch untuk desktop, menempatkan user sebagai anggota grup docker sehingga hampir semua program di session user bisa eskalasi ke root tanpa password dan tanpa sudo.
• Grup docker memberikan akses setara root karena daemon Docker berjalan sebagai root dan anggota grup dapat mengirim perintah ke socket /var/run/docker.sock, termasuk menjalankan container dengan filesystem host yang dipasang ke dalamnya.
• Supplementary group di Linux diwariskan ke proses anak, sehingga semua proses di bawah user session, termasuk browser dan aplikasi desktop, memiliki akses grup docker, dan satu aplikasi terkompromi cukup untuk mengambil alih seluruh sistem.
• Kerentanan dilaporkan secara privat melalui responsible disclosure dan perbaikan sudah tersedia di Omarchy versi 4.0.1, sementara pengguna yang belum memperbarui tetap berisiko karena detail eksploitasi sudah dipublikasikan.
• Langkah mitigasi meliputi memperbarui ke versi 4.0.1, mengeluarkan user dari grup docker dengan sudo gpasswd -d $USER docker, serta mempertimbangkan rootless Docker atau Podman.

Artikel ini membahas detail kerentanan tersebut, mengapa keanggotaan grup docker pada dasarnya setara dengan akses root, bagaimana proof of concept-nya bekerja, dan langkah-langkah yang bisa diambil untuk mengamankan sistem.

Kronologi Penemuan

Kerentanan ini dilaporkan secara privat melalui proses responsible disclosure ke proyek Omarchy. Setelah dilaporkan, konfigurasi yang bermasalah berhasil diperbaiki, dan sekarang tersedia versi 4.0.1 yang mengatasi masalah tersebut. Setelah patch dirilis, detail teknis dipublikasikan agar pengguna memahami apa yang terjadi dan segera memperbarui sistem mereka.

Pola ini adalah contoh yang baik dari alur penanganan kerentanan: peneliti menemukan masalah, melaporkan secara privat, pengembang memperbaiki, lalu informasi dibuka untuk publik setelah patch tersedia. Pengguna yang belum memperbarui tetap berisiko, karena detail eksploitasi sekarang sudah diketahui umum.

Akar Masalah: Grup Docker

Masalahnya dimulai dari konfigurasi default Omarchy yang menempatkan user sebagai anggota grup docker. Pada Arch Linux, daemon Docker berjalan sebagai root dan mendengarkan di socket /var/run/docker.sock. Anggota grup docker dapat berkomunikasi dengan socket tersebut tanpa perlu mengetik sudo.

Docker sendiri sudah memperingatkan sejak lama bahwa grup docker memberikan hak setara root kepada penggunanya. Alasannya jelas: dengan akses ke socket Docker, seseorang bisa meminta daemon untuk menjalankan container sebagai root, memasang bagian mana pun dari filesystem host ke dalam container, dan menjalankan kode sebagai root di dalamnya.

Pada sistem yang terdampak, ini berarti user default dan semua proses yang berjalan di session user memiliki akses ke root. Ini bukan bug di Docker, tetapi konsekuensi dari konfigurasi yang menempatkan user di grup yang memang didesain untuk memberikan akses istimewa.

Proof of Concept

Untuk membuktikan masalah ini, peneliti menunjukkan langkah-langkah berikut pada instalasi Omarchy yang baru. Pertama, mencoba membaca file sensitif sebagai user biasa:

$ cat /etc/shadow
cat: /etc/shadow: Permission denied

Seperti yang diharapkan, user biasa tidak bisa membaca file tersebut. Selanjutnya, memeriksa keanggotaan grup:

$ id
uid=1000(tester) gid=1000(tester)
groups=1000(tester),967(docker),992(input),998(wheel)

Terlihat bahwa user berada dalam grup docker. Sekarang, membaca file yang sama dengan bantuan Docker yang berjalan sebagai root:

$ docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow
root:$6$... bin:!*:... daemon:!*:...

Perintah ini dijalankan oleh proses user biasa, tetapi akses filesystem sebenarnya dilakukan melalui daemon yang berjalan sebagai root. Hasilnya, konten /etc/shadow bisa dibaca tanpa password apa pun.

Mengapa Ini Berbahaya

Bahaya dari kerentanan ini tidak terbatas pada kemampuan membaca /etc/shadow. Akses ke socket Docker berarti kemampuan untuk melakukan apa pun sebagai root, termasuk:

• Membaca, memodifikasi, atau menghapus file apa pun di host dengan memasang filesystem ke dalam container.
• Menjalankan kode berbahaya sebagai root di dalam container.
• Memasang backdoor yang bertahan setelah reboot.
• Mencuri kredensial dari proses lain yang berjalan di sistem.
• Mengubah konfigurasi sistem dan menonaktifkan keamanan.

Yang lebih mengkhawatirkan: supplementary group di Linux diwariskan ke proses anak. Artinya, dampaknya tidak terbatas pada shell interaktif. Semua proses yang berjalan di bawah user session, termasuk aplikasi desktop, browser, dan layanan latar belakang, juga memiliki akses grup docker. Proses tree di bawah systemd --user menunjukkan bahwa grup docker hadir di hampir semua proses normal.

Dalam praktiknya, ini berarti satu aplikasi yang terkompromi, misalnya browser yang kena eksploitasi, sudah cukup untuk mengambil alih seluruh sistem.

Kenapa Grup Docker Setara dengan Root

Banyak pengguna tidak menyadari seberapa besar kekuatan yang diberikan oleh grup docker. Logika dasarnya begini: daemon Docker berjalan sebagai root, dan socket-nya memungkinkan siapa pun yang bisa mengaksesnya untuk mengirim perintah. Salah satu perintah yang bisa dikirim adalah menjalankan container dengan volume yang dipasang dari host.

Dengan menjalankan container seperti ini:

docker run -v /:/host -it alpine sh

Seseorang mendapatkan shell di dalam container yang memiliki akses penuh ke seluruh filesystem host. Karena proses di dalam container dijalankan oleh daemon yang berjalan sebagai root, maka operasi file pun dilakukan dengan hak root. Tidak ada mekanisme yang membatasi ini; Docker memang dirancang seperti itu.

Inilah mengapa dokumentasi Docker menegaskan bahwa menambahkan user ke grup docker sebaiknya dihindari kecuali benar-benar diperlukan, dan bahkan saat diperlukan, penggunanya harus dipercaya penuh seperti pengguna root.

Langkah Mitigasi

Bagi pengguna Omarchy, langkah pertama dan paling penting adalah memperbarui ke versi 4.0.1 yang sudah memasukkan perbaikan konfigurasi. Setelah itu, periksa apakah user masih berada di grup docker:

groups

Kalau user masih terdaftar di grup docker dan tidak benar-benar membutuhkannya, keluarkan user dari grup tersebut:

sudo gpasswd -d $USER docker

Untuk pengguna yang memang membutuhkan akses Docker secara rutin, pertimbangkan alternatif yang lebih aman:

• Gunakan rootless Docker, yang menjalankan daemon dan container tanpa hak root.
• Batasi akses ke socket Docker dengan mekanisme seperti docker context yang terisolasi.
• Jalankan container hanya melalui pipeline CI yang sudah dikontrol, bukan dari session user biasa.
• Gunakan Podman sebagai alternatif yang mendukung rootless secara native.

Prinsip umumnya: jangan pernah memberikan akses grup docker kepada user yang tidak sepenuhnya dipercaya, karena itu sama saja dengan memberikan akses root.

Pelajaran untuk Distribusi dan Pengguna

Kerentanan ini adalah pengingat bahwa konfigurasi default memiliki dampak keamanan yang besar. Apa yang terlihat seperti kemudahan, menempatkan user di grup docker agar tidak perlu sudo setiap kali menjalankan container, sebenarnya membuka pintu lebar untuk eskalasi privilege.

Bagi pengguna Linux pada umumnya, ada beberapa pelajaran yang bisa diambil:

• Periksa keanggotaan grup secara berkala, terutama grup yang memberikan hak istimewa seperti docker, wheel, dan sudo.
• Jangan pernah menambahkan user ke grup istimewa tanpa alasan yang jelas dan tanpa memahami risikonya.
• Ikuti proses responsible disclosure: laporkan masalah secara privat dan tunggu patch sebelum memublikasikan detail.
• Perbarui sistem secara rutin, karena patch keamanan sering kali menjadi satu-satunya pertahanan terhadap eksploitasi yang sudah dipublikasikan.

Perbandingan dengan Eskalasi Root Konvensional

Eksploitasi privilege escalation biasanya dibayangkan sebagai rangkaian teknik rumit: buffer overflow, race condition, atau chain CVE yang panjang. Kerentanan Omarchy menunjukkan sisi lain dari spektrum: kadang-kadang celah paling berbahaya bukan di kernel, tetapi di konfigurasi default yang salah.

Perbedaan pentingnya, eksploitasi teknis biasanya butuh kondisi tertentu dan sering kali gagal, sedangkan celah konfigurasi seperti ini bekerja seratus persen setiap saat. Tidak ada race condition yang harus dimenangkan, tidak ada mitigasi kernel yang harus dilewati. Cukup satu perintah docker, dan akses root didapat. Ini membuat risiko yang ditimbulkan jauh lebih dapat diprediksi dan lebih mudah dieksploitasi oleh siapa pun, termasuk attacker dengan keahlian rendah.

Dari sudut pandang pertahanan, celah konfigurasi juga lebih sulit dideteksi oleh tool otomatis. Scanner kerentanan biasanya mencari versi package yang rentan atau pola eksploitasi yang dikenal, bukan mengevaluasi apakah user seharusnya berada di grup docker. Karena itu, audit manual terhadap keanggotaan grup dan hak istimewa user tetap menjadi bagian penting dari praktik keamanan.

Membangun Kebiasaan Audit Hak Istimewa

Insiden seperti ini adalah pengingat untuk membangun kebiasaan audit sederhana yang bisa dilakukan secara rutin. Beberapa perintah dan praktik yang berguna:

• Periksa keanggotaan grup user secara berkala dengan groups dan id.
• Tinjau file /etc/group untuk melihat siapa saja yang masuk grup istimewa seperti docker, sudo, dan wheel.
• Gunakan rootless container runtime untuk workload yang tidak membutuhkan akses penuh host.
• Batasi akses ke socket Docker dengan memastikan socket hanya bisa diakses oleh proses yang memang membutuhkannya.
• Dokumentasikan alasan setiap user diberikan akses istimewa, dan cabut akses begitu alasan itu tidak berlaku.

Kebiasaan audit ini tidak memakan waktu lama, tetapi bisa mencegah insiden yang biayanya jauh lebih besar. Dalam keamanan, pencegahan yang murah selalu lebih baik daripada respons yang mahal.

Perbandingan Eskalasi Root Konvensional vs Celah Konfigurasi Grup Dock

Aspek	Eskalasi Root Konvensional	Celah Konfigurasi Omarchy
Teknik	Buffer overflow, race condition, chain CVE	Keanggotaan grup docker pada konfigurasi default
Tingkat keberhasilan	Butuh kondisi tertentu dan sering gagal	Bekerja seratus persen setiap saat
Kompleksitas	Rangkaian teknik rumit	Cukup satu perintah docker
Deteksi tool otomatis	Scanner mencari versi package rentan	Sulit terdeteksi, perlu audit manual
Ketersediaan perbaikan	Patch kernel dari vendor	Perbaikan tersedia di Omarchy 4.0.1

Bagi pengguna Omarchy secara khusus, insiden ini juga menjadi momen untuk mengevaluasi kembali asumsi tentang konfigurasi default. Distribusi desktop sering kali memilih kemudahan daripada keamanan, dan dalam banyak kasus itu keputusan yang wajar. Tetapi untuk hak istimewa tingkat root, trade-off seperti itu tidak bisa dibenarkan. Kemudahan menjalankan docker tanpa sudo tidak sebanding dengan risiko kehilangan kendali atas seluruh sistem, dan alternatif seperti rootless Docker sudah tersedia untuk menutup jarak antara kemudahan dan keamanan. Ini juga pengingat bahwa dokumentasi resmi sering kali memuat peringatan yang sebaiknya tidak diabaikan: peringatan Docker tentang grup docker bukan sekadar formalitas, tetapi peringatan keamanan yang didasarkan pada cara kerja sistem yang sebenarnya.

Kalau ada satu pesan yang bisa dibawa pulang dari insiden ini, itu adalah: periksa hak istimewa yang dimiliki setiap user dan setiap proses di sistem Anda hari ini, bukan minggu depan. Satu perintah id dan satu menit membaca outputnya sudah cukup untuk menemukan masalah seperti ini sebelum orang lain menemukannya untuk Anda.

Dalam dunia keamanan, insiden seperti ini sering disebut sebagai low-hanging fruit: celah yang sederhana, murah untuk dieksploitasi, dan berdampak besar. Justru karena sederhana, celah seperti ini paling sering terlewat, dan justru karena itu juga paling mudah ditutup begitu diketahui. Tidak ada alasan untuk menunda.

Kesimpulan

Kerentanan Omarchy menunjukkan bahwa eskalasi root tidak selalu membutuhkan eksploitasi kernel yang rumit. Kadang-kadang, konfigurasi default yang tampak sepele, seperti keanggotaan grup docker, sudah cukup untuk memberikan akses penuh ke sistem.

Kabarnya, perbaikan sudah tersedia di versi 4.0.1, dan pengguna disarankan untuk segera memperbarui. Untuk semua pengguna Linux, ini juga menjadi pengingat untuk selalu memeriksa hak istimewa yang dimiliki user dan proses yang berjalan di sistem, karena dalam keamanan, asumsi yang salah bisa berujung pada kehilangan kendali penuh atas mesin.

Keamanan bukan tentang menambah fitur, tetapi tentang mengurangi permukaan serangan. Mengeluarkan user dari grup yang tidak dibutuhkan adalah salah satu langkah paling sederhana dan paling efektif yang bisa dilakukan hari ini.

Rekomendasi Tools & Layanan

Beberapa layanan yang dipake di panduan ini: free trial Alibaba Cloud (coba gratis, sesuaikan kebutuhan), dan halaman promo terbaru buat cek diskon yang lagi jalan bulan ini.

FAQ

Mengapa keanggotaan grup docker dianggap setara dengan akses root?

Karena daemon Docker berjalan sebagai root dan anggota grup docker dapat berkomunikasi dengan socket /var/run/docker.sock tanpa sudo. Dengan akses itu, seseorang bisa menjalankan container sebagai root, memasang bagian mana pun dari filesystem host, dan menjalankan kode dengan hak root.

Bagaimana proof of concept eskalasi root pada Omarchy bekerja?

Peneliti menunjukkan bahwa user biasa yang gagal membaca /etc/shadow bisa membacanya lewat perintah docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow. Akses filesystem sebenarnya dilakukan oleh daemon Docker yang berjalan sebagai root, sehingga konten /etc/shadow terbaca tanpa password.

Versi Omarchy mana yang sudah memperbaiki masalah ini?

Perbaikan sudah tersedia di Omarchy versi 4.0.1 setelah kerentanan dilaporkan secara privat melalui proses responsible disclosure. Pengguna yang belum memperbarui tetap berisiko karena detail eksploitasi sudah diketahui umum.

Apa langkah mitigasi bagi pengguna yang masih berada di grup docker?

Pengguna bisa mengeluarkan diri dari grup dengan perintah sudo gpasswd -d $USER docker jika tidak benar-benar membutuhkannya. Alternatif yang lebih aman termasuk rootless Docker, membatasi akses ke socket Docker, menjalankan container melalui pipeline CI yang dikontrol, atau menggunakan Podman yang mendukung rootless secara native.

Mengapa celah konfigurasi seperti ini dianggap lebih mudah dieksploitasi dibanding eksploitasi kernel?

Celah konfigurasi bekerja seratus persen setiap saat tanpa perlu memenangkan race condition atau melewati mitigasi kernel, cukup satu perintah docker untuk mendapat akses root. Selain itu, scanner kerentanan otomatis biasanya tidak mengevaluasi keanggotaan grup, sehingga celah seperti ini sulit dideteksi dan audit manual tetap penting.

Sumber & Referensi

Rujukan resmi yang dipakai untuk memverifikasi klaim di artikel ini:

• Docker daemon attack surface
• Arch Wiki halaman Docker
• Situs resmi Omarchy
• Repositori GitHub Omarchy
• Dokumentasi resmi Podman