Kredensial Peer Unix Socket Mengikat Identitas ke Koneksi Lokal

Sebuah layanan lokal berprivilege sering menerima permintaan dari proses yang berbagi host tetapi tidak berbagi otoritas. Pathname pada Unix domain socket dapat mengendalikan pihak yang mencapai listener, tetapi koneksi yang berhasil tidak dengan sendirinya memberi tahu layanan proses mana yang berada di ujung lain. Linux menyediakan batas kedua: SO_PEERCRED membuat Unix socket yang terhubung dapat mengekspos kredensial peer yang dipasok kernel.

Kredensial tersebut berguna karena peer tidak menserialisasikannya ke dalam pesan aplikasi. Kernel memperoleh record kredensial untuk koneksi, sehingga client tidak dapat mengganti UID yang dilaporkan dengan angka arbitrer hanya dengan mengubah byte permintaan. Properti ini membuat kredensial peer cocok sebagai input untuk otorisasi lokal, tetapi bukan sebagai sistem otorisasi lengkap.

Record kredensial melekat pada relasi socket

Di Linux, getsockopt() dengan SOL_SOCKET dan SO_PEERCRED mengembalikan struct ucred yang berisi PID, UID, dan GID peer dari socket AF_UNIX yang terhubung. Interface ini juga berlaku pada socket pair.

Batas pentingnya adalah bahwa nilai tersebut berasal dari state socket yang dipelihara kernel. Nilai itu tidak setara dengan client yang mengirim field seperti uid=1000 dalam frame protokol. Data aplikasi tetap dikendalikan pihak yang tidak tepercaya; kredensial peer merupakan metadata terpisah yang diperoleh melalui API socket.

Untuk layanan yang perlu membedakan pemanggil lokal, model kepercayaannya menjadi:

byte permintaan ------------------> parse sebagai input tidak tepercaya
Unix socket terhubung
        |
        +---- SO_PEERCRED ---------> identitas peer dari kernel

Layanan dapat mengikat permintaan ke identitas yang terkait dengan koneksi, alih-alih memercayai klaim identitas di dalam permintaan tersebut.

Waktu pengambilan kredensial menghasilkan snapshot, bukan feed identitas live

Linux mendokumentasikan kredensial yang dikembalikan sebagai kredensial yang berlaku saat peer melakukan koneksi, saat listen() dipanggil untuk listening socket, atau saat socket pair dibuat. Waktu ini penting untuk koneksi berumur panjang.

Sebuah proses dapat mengubah sebagian state kredensialnya setelah koneksi terbentuk, dengan tetap tunduk pada aturan izin kernel. SO_PEERCRED bukan langganan atas setiap transisi identitas berikutnya. Desain otorisasi yang memerlukan state proses terkini tidak dapat menganggap pembacaan opsi berulang kali mengubah kredensial koneksi awal menjadi monitor proses live.

Properti snapshot ini dapat memang diinginkan. Daemon dapat secara sengaja mengotorisasi principal yang membentuk channel dan mempertahankan keputusan tersebut selama umur channel. Namun cakupan itu dapat terlalu luas jika privilege, role, atau keanggotaan aplikasi diperkirakan berubah saat koneksi tetap terbuka. Dalam kondisi tersebut, identitas koneksi dan state otorisasi terkini perlu ditangani secara terpisah.

PID berguna sebagai konteks tetapi rapuh sebagai principal jangka panjang

Field PID dapat mengidentifikasi proses peer dalam tampilan PID namespace yang relevan, tetapi PID numerik dapat digunakan kembali. Setelah sebuah proses keluar, angka yang sama kelak dapat merujuk proses lain.

Karena itu PID merupakan bahan yang buruk untuk record otorisasi persisten. Layanan sebaiknya tidak menyimpan PID numerik lalu menganggap proses yang kelak memakai angka itu sebagai peer semula. Jika desain memerlukan referensi kernel yang stabil ke proses setelah pemeriksaan kredensial langsung, pidfd Linux menyediakan mekanisme berbeda dengan semantik lifecycle yang terikat pada objek proses.

UID dan GID juga memerlukan interpretasi kebijakan. Keduanya mengidentifikasi kredensial kernel, bukan akun aplikasi, tenant ID, role organisasi, atau izin bisnis. Pemetaan UID lokal ke otoritas aplikasi merupakan kebijakan deployment dan dapat tepat pada satu model layanan tetapi keliru pada model lain.

User namespace mengubah makna identitas numerik

User namespace Linux memungkinkan ID kredensial dipetakan di antara tampilan namespace. Akibatnya, UID numerik memiliki makna relatif terhadap konteks namespace, bukan sebagai label identitas host yang universal.

Layanan yang memakai kredensial peer melintasi batas container atau namespace perlu memperhitungkan susunan namespace tempat socket dan proses beroperasi. Menganggap integer yang terlihat sebagai identitas global yang sudah jelas dapat melebur domain identitas berbeda ke dalam satu keputusan kebijakan.

Batas ini bersifat arsitektural, bukan cacat pada SO_PEERCRED. Kernel memasok kredensial sesuai semantik namespace Linux. Aplikasi tetap menentukan apakah kredensial tersebut mewakili principal yang diizinkan dalam model deployment-nya.

Untuk layanan host yang diekspos ke container, hal ini sangat penting. Keterjangkauan socket, pemetaan user namespace, permission filesystem pada node socket, dan tabel otorisasi layanan membentuk satu batas gabungan. Kredensial peer menyumbang metadata kernel yang tepercaya, tetapi tidak menetapkan kebijakan yang mengonsumsinya.

Permission pathname socket dan identitas peer menangani masalah berbeda

Permission filesystem pada Unix socket berbasis pathname dapat membatasi proses yang dapat terhubung. Kredensial peer menjawab pertanyaan berbeda setelah koneksi tersedia.

Hanya mengandalkan pathname dapat tidak memadai ketika beberapa principal memang diizinkan mencapai satu endpoint tetapi memperoleh otoritas berbeda. Sebaliknya, pemeriksaan kredensial peer tidak membuat eksposur socket yang ceroboh menjadi aman. Mengurangi keterjangkauan membatasi beban dan attack surface sebelum parsing protokol dimulai.

Abstract Unix socket di Linux tidak memakai pathname filesystem untuk access control dengan cara yang sama seperti pathname socket. Deployment yang memakainya tidak dapat menganggap permission direktori dan node socket menyediakan batas penerimaan yang sama.

Layanan lokal yang kokoh dapat menggabungkan beberapa lapisan: membatasi keterjangkauan endpoint bila memungkinkan, mengambil kredensial peer kernel pada koneksi yang diterima, memetakan kredensial itu ke kebijakan layanan eksplisit, lalu tetap memvalidasi seluruh isi permintaan secara independen.

Pemeriksaan kredensial tidak mengautentikasi intent yang didelegasikan

Proses dengan UID yang diizinkan dapat berupa broker, desktop agent, job runner, atau perantara lain yang bertindak untuk pemanggil dengan privilege lebih rendah. SO_PEERCRED mengidentifikasi proses pada batas socket; interface ini tidak mengungkap seluruh rantai delegasi yang membuat proses tersebut mengirim permintaan.

Perbedaan ini menjadi penting ketika komponen lokal tepercaya menerima input tidak tepercaya lalu meneruskan operasi berprivilege. Daemon penerima melihat perantara tepercaya sebagai peer-nya. Jika kebijakan memerlukan pemanggil awal, protokol memerlukan mekanisme delegasi dengan aturan integritas dan otorisasinya sendiri. Kredensial peer kernel tidak dapat merekonstruksi provenance yang berada di luar peer socket langsung.

Batas yang sama berlaku pada proses yang telah dikompromikan. Pemeriksaan kredensial dapat menetapkan bahwa permintaan tiba melalui koneksi yang dikaitkan dengan UID yang diizinkan. Pemeriksaan itu tidak dapat menetapkan bahwa proses berperilaku sesuai logika aplikasi yang dimaksud.

Kredensial pesan merupakan mekanisme terpisah

Linux juga mendukung data ancillary kredensial melalui SCM_CREDENTIALS ketika opsi socket dan alur pesan yang relevan digunakan. Mekanisme tersebut menautkan kredensial ke pesan dan memiliki aturan yang berbeda dari SO_PEERCRED.

Kedua interface tidak semestinya diperlakukan sebagai dua nama untuk satu fitur yang sama. SO_PEERCRED ditanyakan dari relasi socket terhubung. Control message kredensial ikut dalam pengiriman pesan dan berguna ketika provenance per pesan penting, termasuk pada desain berorientasi datagram.

Pemilihannya mengikuti batas protokol. Layanan stream yang mengotorisasi peer saat pembentukan koneksi dapat cocok dengan SO_PEERCRED. Desain yang memerlukan kredensial terkait pesan individual dapat memerlukan ancillary credentials dan penanganan cermat terhadap semantik terdokumentasinya.

Identitas lokal tetap memerlukan otorisasi eksplisit

Kredensial peer yang dipasok kernel menghapus satu ambiguitas berbahaya: layanan tidak perlu memercayai klaim UID dari client untuk peer Unix socket langsung. Keputusan lain tetap berada di atas mekanisme tersebut.

Daemon tetap memerlukan kebijakan untuk UID atau GID yang diizinkan, pemetaan namespace, umur koneksi, pemanggil terdelegasi, dan operasi yang diizinkan bagi setiap principal. Daemon juga tetap memerlukan pertahanan protokol biasa untuk panjang data, object identifier, transisi state, dan konsumsi resource.

SO_PEERCRED dengan demikian merupakan primitive identitas sempit dengan properti kepercayaan yang berguna. Interface ini mengikat metadata kredensial kernel ke relasi socket lokal. Keamanan berasal dari mempertahankan cakupan properti itu: pakai untuk mengidentifikasi peer langsung pada batas tempat kernel dapat membuktikan fakta tersebut, dan jangan memperluasnya menjadi klaim tentang role aplikasi, state proses terkini, atau intent terdelegasi yang tidak dipasok interface ini.