Evolusi sudo: Dari su Unix hingga Hak Akses Modern

Ini fakta yang mengejutkan bagi kebanyakan orang: saat kamu mengetik password ke sudo, tidak ada umpan balik sama sekali. Tidak ada bintang, tidak ada titik, tidak ada apa-apa. Kursor hanya diam. Keputusan desain ini dibuat pada tahun 1980-an dan sudah membingungkan pengguna selama lebih dari empat dekade. Orang-orang sering mengira terminalnya macet, mengetik password berkali-kali, atau menganggap ada yang rusak. Ubuntu akhirnya memutuskan menampilkan bintang secara default, sekaligus mengakhiri tradisi input password diam-diam selama 46 tahun.

Perubahan kecil ini menunjukkan sesuatu yang lebih besar: cara Linux menangani eskalasi hak akses adalah tambal sulam dari keputusan yang dibuat selama puluhan tahun, ada yang brilian, ada yang cukup dipertanyakan, dan semuanya membawa beban kompatibilitas ke belakang. Memahami bagaimana kita sampai di sini membantu kamu mengambil keputusan keamanan yang lebih baik hari ini.

Sebelum sudo: Dunia su

Alat eskalasi hak akses Unix yang pertama adalah su — singkatan dari "substitute user". Ia hanya melakukan satu hal: memindahkan seluruh sesi shell kamu ke pengguna lain, biasanya root. Kamu mengetik su, memasukkan password root, mengerjakan tugas admin, lalu keluar kembali ke akun biasa.

$ su
Password: [type root's password]
# whoami
root
# apt install nginx
# exit
$ whoami
normaluser

Masalah su makin terlihat ketika sistem Unix berkembang melampaui segelintir operator tepercaya. Semua orang yang butuh akses admin harus tahu password root. Saat ada yang keluar dari tim, kamu harus mengganti password root dan membagikannya ke semua orang lagi. Tidak ada jejak audit: begitu seseorang menjadi root, semua aksinya tercatat sebagai "root" tanpa catatan siapa sebenarnya yang menjalankan apa. Dan su memberimu shell root penuh, artinya satu salah ketik saja bisa menghancurkan sistem.

Kisah horor klasiknya: seorang admin bermaksud mengetik rm -rf /tmp/old_files, tapi tanpa sengaja menekan enter setelah rm -rf / terketik. Dengan shell root penuh, tidak ada yang menghentikan perintah itu untuk dieksekusi. su tidak membedakan antara "orang ini perlu me-restart nginx" dan "orang ini perlu akses tanpa batas ke seluruh sistem".

Bagaimana sudo Menyelesaikan Masalah Password Root

sudo ("superuser do") dibuat pada 1980 di SUNY Buffalo oleh Bob Coggeshall dan Cliff Spencer. Gagasan intinya sederhana tapi mengubah segalanya: alih-alih membagikan password root, biarkan setiap pengguna menjalankan perintah tertentu sebagai root menggunakan password mereka sendiri. Administrator sistem mengontrol siapa yang boleh menjalankan apa melalui file konfigurasi.

Ini sekaligus memecahkan beberapa masalah:

• Tidak ada password root bersama. Setiap pengguna melakukan autentikasi dengan kredensialnya sendiri. Saat ada yang keluar, kamu cukup mencabut akses sudo-nya. Tidak perlu rotasi password.
• Izin yang granular. Kamu bisa mengizinkan developer me-restart layanan tertentu tanpa memberinya akses root penuh.
• Jejak audit. Setiap perintah sudo tercatat beserta username pelakunya, apa yang dijalankan, dan kapan.
• Eskalasi sementara. Alih-alih shell root yang terbuka lebar, sudo hanya menjalankan satu perintah dengan hak istimewa lalu kembali ke mode normal.

# Run a single command as root
$ sudo apt install nginx
[sudo] password for priya:
# That's YOUR password, not root's
# The audit trail in /var/log/auth.log:
# Mar 20 14:23:01 web-03 sudo: priya : TTY=pts/0 ;
#   PWD=/home/priya ; USER=root ; COMMAND=/usr/bin/apt install nginx

File sudoers: Kuat tapi Berbahaya

Konfigurasi sudo ada di /etc/sudoers, dan sintaksnya memang salah satu yang paling membingungkan dalam administrasi Linux. Satu kesalahan sintaks saja bisa membuatmu terkunci dari sudo sepenuhnya, itulah sebabnya perintah visudo ada — ia memvalidasi file sebelum disimpan.

# /etc/sudoers syntax:
# WHO  WHERE = (AS_WHOM) WHAT
# Let priya run anything as root on any host
priya ALL=(ALL:ALL) ALL
# Let the 'webdev' group restart nginx only
%webdev ALL=(root) /usr/bin/systemctl restart nginx,\
/usr/bin/systemctl reload nginx
# Let deploy user run deploys without a password
deploy ALL=(root) NOPASSWD: /opt/deploy/run.sh
# DANGEROUS: This looks restrictive but isn't
bob ALL=(root) /usr/bin/vim
# Bob can now run: sudo vim, then :!bash to get a root shell

Contoh terakhir tadi — memberi seseorang akses sudo ke vim — adalah jebakan keamanan yang terus-menerus menjebak orang. Vim (dan banyak program lain) bisa menjalankan perintah shell. Jika pengguna bisa menjalankan sudo vim, mereka pada dasarnya punya akses root tanpa batas. Hal yang sama berlaku untuk less, man, awk, find, python, dan puluhan perintah lainnya. Proyek GTFOBins memelihara daftar lengkap binary yang bisa dipakai untuk keluar dari shell yang dibatasi.

Keanehan sudo dan Jebakan Keamanan

sudo telah mengumpulkan beberapa perilaku aneh selama lebih dari 40 tahun sejarahnya. Memahami keanehan ini penting untuk keamanan:

• Caching kredensial. Setelah kamu memasukkan password, sudo menyimpannya di cache selama 15 menit secara default. Selama jendela waktu itu, perintah sudo apa pun berjalan tanpa autentikasi. Jika kamu meninggalkan terminal yang sedang terbuka, siapa pun bisa menjalankan perintah sudo selama hingga 15 menit. Jalankan sudo -k untuk menghapus cache seketika.
• Pengaturan tty_tickets. Secara default, cache kredensial sudo bersifat per-terminal. Tapi di beberapa sistem, autentikasi di satu sesi terminal membuka kunci sudo di semua sesi. Periksa pengaturan Defaults kamu.
• Variabel lingkungan. sudo membersihkan sebagian besar variabel lingkungan, tapi tidak semuanya. LD_PRELOAD dan LD_LIBRARY_PATH dihapus, tapi jika env_keep salah konfigurasi, penyerang bisa menyisipkan path library berbahaya. Ini menjadi dasar beberapa exploit eskalasi hak akses sungguhan.
• Jebakan NOPASSWD. NOPASSWD memang praktis untuk otomasi, tapi berbahaya jika diterapkan terlalu luas. Aplikasi yang sudah disusupi dan berjalan sebagai pengguna dengan akses sudo NOPASSWD pada dasarnya sudah menjadi root, tanpa password yang perlu dibobol.

# Security hardening for sudoers:
# Require password every time (disable caching)
Defaults timestamp_timeout=0
# Or reduce cache to 1 minute
Defaults timestamp_timeout=1
# Ensure credential cache is per-terminal
Defaults tty_tickets
# Log all sudo I/O (records full terminal sessions)
Defaults log_input, log_output
Defaults iolog_dir=/var/log/sudo-io
# Require root password instead of user password
# (prevents compromised user accounts from sudo-ing)
Defaults rootpw
# Show asterisks when typing password
Defaults pwfeedback

Alternatif Modern: doas, polkit, dan run0

Kerumitan sudo melahirkan beberapa alternatif, masing-masing dengan filosofi yang berbeda.

doas: sudo Tanpa Kerumitan

doas dari OpenBSD ("dedicated OpenBSD application subexecutor") dibuat oleh Ted Unangst pada 2015 khusus karena sudo sudah terlalu rumit untuk diaudit. Seluruh konfigurasinya biasanya hanya 2-3 baris:

# /etc/doas.conf — the entire configuration
permit persist priya
permit nopass deploy as root cmd /opt/deploy/run.sh
# That's it. Compare this to a typical sudoers file.
# 'persist' is like sudo's credential caching
# 'nopass' is like NOPASSWD

Kode sumber doas sekitar 2.500 baris C. Milik sudo lebih dari 150.000. Untuk sistem yang tidak membutuhkan fitur lanjutan sudo (seperti pencocokan argumen per perintah atau integrasi LDAP), doas jauh lebih sederhana untuk dikonfigurasi, diaudit, dan diamankan. Saya sudah memakainya di server pribadi selama bertahun-tahun dan belum pernah merindukan sudo sekali pun.

polkit: Hak Akses Desktop yang Granular

PolicyKit (polkit) mengambil pendekatan yang sama sekali berbeda. Alih-alih membungkus perintah satu per satu, ia mendefinisikan action yang bisa diminta oleh aplikasi. Saat aplikasi desktop perlu mengubah pengaturan jaringan, ia meminta izin ke polkit, dan polkit memutuskan berdasarkan aturannya apakah akan memberi izin, menolak, atau meminta konfirmasi pengguna.

Begitulah desktop Linux kamu bisa memasang flashdisk USB tanpa password, tapi tetap meminta autentikasi untuk memasang software. Granularitasnya ada di level action, bukan level perintah, yang lebih cocok dengan cara pengguna desktop benar-benar berpikir tentang izin.

run0: Rombakan Radikal dari systemd

run0 dari systemd adalah pendatang terbaru, dan cara kerjanya berbeda secara fundamental dari sudo. Alih-alih menjalankan perintah sebagai root dari sesi yang sudah ada (yang membutuhkan setuid bit dan menimbulkan sakit kepala keamanan), run0 meminta service manager untuk membuat layanan baru yang berjalan sebagai root. Sesi pengguna kamu tidak pernah mendapatkan hak istimewa tambahan, karena proses privileged-nya benar-benar terpisah.

Ini menghindari seluruh kategori kerentanan sudo. Tidak ada binary setuid, tidak ada caching kredensial, tidak ada celah injeksi variabel lingkungan. Konsekuensinya, ia membutuhkan systemd, sehingga tidak cocok untuk sistem BSD maupun setup Linux minimal. Tapi untuk server berbasis systemd, ini bisa dibilang opsi paling aman yang tersedia.

Rekomendasi Praktis

Setelah bertahun-tahun mengelola server Linux dan menyelidiki insiden eskalasi hak akses, inilah yang benar-benar saya rekomendasikan:

1. Nonaktifkan login root sepenuhnya. Gunakan sudo atau doas untuk semuanya. Tidak boleh ada password root bersama.
2. Gunakan grup, bukan pengguna individual, di sudoers. Kelola akses lewat keanggotaan grup. Saat ada yang keluar, cukup keluarkan dia dari grup.
3. Jangan pernah memberi akses sudo ke interpreter atau editor. Jangan ada sudo vim, sudo python, sudo less. Jika perlu mengedit file milik root, gunakan sudoedit.
4. Minimalkan aturan NOPASSWD. Gunakan hanya untuk proses otomatis, dan hanya untuk perintah spesifik dengan path lengkap.
5. Aktifkan logging sudo. Minimal catat semua perintah sudo. Untuk sistem sensitif, aktifkan logging I/O penuh.
6. Pertimbangkan doas untuk sistem yang lebih sederhana. Jika kamu tidak membutuhkan integrasi LDAP atau aturan pencocokan yang kompleks, doas lebih mudah dikonfigurasi dengan benar.
7. Rotasi cache kredensial secara agresif. Turunkan timestamp_timeout menjadi 1-5 menit, atau nonaktifkan caching sepenuhnya di server produksi.

Mekanisme eskalasi hak akses terbaik adalah yang memberikan akses minimum yang dibutuhkan, untuk waktu minimum yang dibutuhkan, dengan jejak audit yang lengkap. Selebihnya hanyalah kompromi.

sudo tidak akan pergi ke mana-mana. Ia sudah terlalu tertanam di script, otomasi, dokumentasi, dan kebiasaan yang melekat, sehingga mustahil hilang begitu saja. Tapi lanskap alternatifnya sekarang lebih sehat dari sebelumnya. Entah kamu tetap memakai sudo (dengan pengerasan yang benar), pindah ke doas (demi kesederhanaan), atau mengadopsi run0 (untuk sistem kritis keamanan), yang penting adalah memahami apa yang sebenarnya dilakukan alat eskalasi hak aksesmu, karena celah antara apa yang orang kira dilakukan sudo dan apa yang sebenarnya dilakukannya adalah tempat sebagian besar insiden keamanan bersarang.