Sebuah daemon lokal berprivilege menerima request melalui socket AF_UNIX dan perlu memutuskan apakah pengirim boleh menjalankan suatu operasi. Mempercayai UID, PID, atau nama akun yang dikodekan di dalam request hanya berarti mempercayai data yang diberikan client. Linux menyediakan kanal identitas berbeda: kernel dapat mengekspos kredensial yang terkait dengan peer atau dengan satu pesan tertentu.
SO_PEERCRED dan SCM_CREDENTIALS sama-sama membawa struct ucred, tetapi keduanya menggambarkan momen berbeda dalam relasi IPC. Menganggap keduanya setara dapat mengubah batas otorisasi lokal yang kuat menjadi asumsi identitas yang sudah stale.
SO_PEERCRED menangkap kredensial saat koneksi dibentuk
Untuk UNIX stream socket yang terhubung, getsockopt(fd, SOL_SOCKET, SO_PEERCRED, ...) mengembalikan kredensial peer. Linux mencatat kredensial hasil dari titik pembentukan koneksi yang relevan: connect(), listen(), atau socketpair() sesuai susunan socket.
Struktur tersebut berisi PID, UID, dan GID. Nilai itu datang melalui interface socket kernel, bukan dari byte payload aplikasi. Karakter ini membuat SO_PEERCRED sesuai bagi daemon yang menetapkan konteks otorisasi pada koneksi lokal yang baru diterima.
struct ucred cred;
socklen_t len = sizeof(cred);
if (getsockopt(fd, SOL_SOCKET, SO_PEERCRED, &cred, &len) == -1)
/* reject connection */;Snapshot tersebut bukan monitor kredensial berkelanjutan. Jika peer kemudian mengubah kredensial, nilai yang diperoleh melalui SO_PEERCRED tidak berubah menjadi tampilan live atas state berikutnya. Protokol yang mengotorisasi seluruh koneksi berdasarkan identitas peer awal karena itu membuat keputusan kebijakan sesi secara eksplisit.
SCM_CREDENTIALS menempelkan identitas pada pesan yang diterima
Linux juga dapat mengirim kredensial sebagai ancillary data. Saat SO_PASSCRED diaktifkan pada UNIX socket penerima, pesan yang diterima berikutnya membawa control message SCM_CREDENTIALS. Jika pengirim tidak memberikan kredensial secara eksplisit, kernel memasok nilai default yang berisi PID pengirim, real UID, dan real GID.
Model berorientasi pesan ini berguna saat otorisasi melekat pada datagram atau pesan individual, bukan pada koneksi berumur panjang. Penerima harus memakai recvmsg() dan memeriksa rantai control message; pemanggilan recv() biasa tidak mengekspos ancillary credentials kepada kode aplikasi.
Pengirim dapat memberikan SCM_CREDENTIALS secara eksplisit, tetapi field tersebut bukan klaim bebas yang tidak tepercaya. Linux memeriksa nilai yang diberikan. Tanpa capability yang relevan, pengirim dibatasi pada nilai PID, UID, dan GID yang diizinkan dari kredensial prosesnya sendiri. Pengirim berprivilege memiliki aturan substitusi lebih luas, sehingga threat model penerima tetap perlu memperhitungkan proses lokal berprivilege.
Identitas koneksi dan identitas pesan menjawab kebutuhan berbeda
SO_PEERCRED selaras dengan batas sesi stream: daemon menerima peer, memperoleh snapshot kredensial dari kernel, lalu mengaitkan state kebijakan dengan koneksi tersebut. SCM_CREDENTIALS selaras dengan provenance pesan: setiap pesan yang diterima dapat membawa kredensial yang diperiksa atau dipasok kernel.
Perbedaan ini penting ketika kredensial berubah. Service yang sengaja mengizinkan peer terhubung mengganti UID setelah koneksi mungkin tetap ingin otorisasi tetap terikat pada identitas saat sesi dibentuk. Dalam kasus itu, SO_PEERCRED sesuai dengan kebijakan. Broker datagram yang menerima pesan dari beberapa proses memerlukan provenance per pesan; snapshot waktu koneksi tidak dapat mewakili seluruh pengirim.
Kedua mekanisme tidak menentukan aturan otorisasi. Keduanya menyediakan input identitas. Daemon tetap memutuskan apakah UID, GID, PID, security label, path socket, atau properti lain relevan bagi operasi yang diminta.
Permission pathname socket dan kredensial peer melindungi batas berbeda
Permission filesystem pada UNIX socket berbasis pathname dapat membatasi proses yang dapat mencapai endpoint berdasarkan aturan filesystem Linux. Kredensial peer menjawab pertanyaan terpisah setelah komunikasi tersedia: identitas proses mana yang terkait dengan koneksi atau pesan ini.
Hanya mengandalkan permission file socket dapat tidak memadai ketika beberapa principal secara sah berbagi akses endpoint tetapi memperoleh privilege berbeda di dalam protokol. Sebaliknya, pemeriksaan kredensial peer tidak membuat penempatan endpoint menjadi tidak relevan. Permission directory dan socket dapat mengurangi pihak yang dapat memulai traffic, sedangkan pemeriksaan kredensial dapat memperhalus otorisasi setelah acceptance.
UNIX socket pada abstract namespace tidak memakai permission pathname filesystem dengan cara yang sama. Desain pada namespace tersebut tidak boleh memindahkan asumsi ownership pathname dan mode bit ke endpoint abstrak.
Nilai PID tetap merupakan identifier yang terikat namespace
PID di dalam struct ucred berguna untuk korelasi, tetapi tidak otomatis menjadi handle proses yang tahan lama. PID numerik dapat digunakan ulang setelah proses keluar, dan relasi PID namespace memengaruhi nilai yang terlihat melintasi batas proses.
Jika daemon perlu menjalankan operasi pembawa otoritas pada proses yang sama di waktu berikutnya, PID numerik yang disalin dari kredensial tidak setara dengan referensi proses kernel yang stabil. Catatan kredensial menetapkan provenance bagi event socket; catatan itu tidak membekukan masa hidup proses atau mengubah PID menjadi capability permanen.
Nilai UID dan GID juga memerlukan konteks kebijakan. UID numerik dapat ditafsirkan melalui user namespace, dan otorisasi berbasis identitas host dapat memerlukan asumsi eksplisit tentang susunan namespace daemon dan client. Pengiriman oleh kernel mencegah pemalsuan payload dalam aturan yang terdokumentasi, tetapi tidak memilih domain kebijakan tempat angka tersebut harus ditafsirkan.
Truncation kredensial adalah kegagalan parsing, bukan peer anonim
Ancillary data memiliki kebutuhan buffer. Jika control buffer untuk recvmsg() terlalu kecil, control message dapat terpotong dan MSG_CTRUNC dilaporkan. Receiver yang sensitif terhadap keamanan perlu memperlakukan kredensial yang hilang atau terpotong sebagai kegagalan akuisisi identitas, bukan diam-diam melanjutkan melalui jalur parsing dengan privilege lebih rendah yang tetap menjalankan pekerjaan sensitif.
Prinsip yang sama berlaku pada traversal control message yang malformed. Aplikasi harus memverifikasi tipe message, level, dan ukuran payload yang diharapkan sebelum memakai struct ucred. Metadata yang berasal dari kernel tetap tiba melalui batas parsing userspace.
Identitas yang diamati kernel adalah primitive autentikasi lokal yang sempit
Peer credentials menghapus ambiguitas tertentu dari IPC lokal: client tidak perlu menyatakan identitas prosesnya sendiri di dalam data request biasa. Kernel dapat mengikat metadata identitas pada pembentukan koneksi atau penerimaan pesan dan menerapkan aturan substitusi yang terdokumentasi.
Properti itu tidak mengautentikasi intent aplikasi, provenance executable, kepemilikan akun di luar kredensial yang direpresentasikan, atau kebenaran request itu sendiri. Mekanisme tersebut juga tidak menggantikan discretionary atau mandatory access control yang mengelilingi proses dan socket.
Protokol lokal yang kuat karena itu menjaga batas tetap eksplisit. SO_PEERCRED dapat menetapkan snapshot identitas per koneksi; SCM_CREDENTIALS dapat menyediakan provenance per pesan; permission endpoint dapat membatasi reachability; dan kebijakan aplikasi dapat memetakan fakta yang diamati kernel tersebut ke operasi yang diizinkan. Nilai keamanan muncul dari pemisahan peran tersebut, bukan dari memperlakukan satu field kredensial sebagai autentikasi lokal yang lengkap.