<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Kontrol Akses on Nalar</title>
    <link>https://nalar.dev/id/tags/kontrol-akses/</link>
    <description>Recent content in Kontrol Akses on Nalar</description>
    <generator>Hugo</generator>
    <language>id-id</language>
    <lastBuildDate>Fri, 18 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/id/tags/kontrol-akses/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Event Permission Fanotify Menempatkan Akses File di Balik Keputusan Userspace</title>
      <link>https://nalar.dev/id/event-permission-fanotify-menempatkan-akses-file-di-balik-keputusan-userspace/</link>
      <pubDate>Fri, 18 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/event-permission-fanotify-menempatkan-akses-file-di-balik-keputusan-userspace/</guid>
      <description>&lt;p&gt;Sebuah proses memanggil &lt;code&gt;execve()&lt;/code&gt; untuk binary pada filesystem yang dipantau, tetapi kernel tidak langsung menyelesaikan execution open. Sebuah grup fanotify meminta &lt;code&gt;FAN_OPEN_EXEC_PERM&lt;/code&gt;, sehingga akses menunggu ketika listener userspace menerima event lalu mengembalikan &lt;code&gt;FAN_ALLOW&lt;/code&gt; atau &lt;code&gt;FAN_DENY&lt;/code&gt;. Mekanisme ini menyisipkan keputusan userspace sinkron ke dalam operasi filesystem yang semestinya berjalan setelah pemeriksaan permission kernel biasa.&lt;/p&gt;&#xA;&lt;p&gt;Titik intersepsi tersebut berguna bagi policy engine yang memerlukan informasi di luar permission inode biasa, tetapi juga membentuk batas enforcement tersendiri. Availability kini bergantung pada responder userspace, cakupan event bergantung pada mark dan kelas event fanotify yang dipilih, dan mekanisme ini tidak mengubah setiap bentuk penggunaan file menjadi operasi yang dimediasi.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Idmapped Mount Memetakan Ulang Kepemilikan File Tanpa Menulis Ulang Inode</title>
      <link>https://nalar.dev/id/idmapped-mount-memetakan-ulang-kepemilikan-file-tanpa-menulis-ulang-inode/</link>
      <pubDate>Fri, 18 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/idmapped-mount-memetakan-ulang-kepemilikan-file-tanpa-menulis-ulang-inode/</guid>
      <description>&lt;h1 id=&#34;idmapped-mount-memetakan-ulang-kepemilikan-file-tanpa-menulis-ulang-inode&#34;&gt;Idmapped Mount Memetakan Ulang Kepemilikan File Tanpa Menulis Ulang Inode&lt;/h1&gt;&#xA;&lt;p&gt;Sebuah container memerlukan akses baca-tulis ke direktori yang file-nya memiliki nilai kepemilikan host yang tidak selaras dengan user namespace container. Perubahan kepemilikan secara rekursif dapat membuat direktori tersebut dapat digunakan, tetapi tindakan itu juga mengubah metadata inode persisten dan dapat mengganggu setiap tampilan lain dari filesystem yang sama. Idmapped mount Linux menyediakan mekanisme yang lebih sempit: satu mount dapat menerapkan pemetaan identitas berbeda sementara kepemilikan yang tersimpan tetap utuh.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Kredensial Tersimpan OverlayFS Memisahkan Akses Overlay dari Akses Filesystem Dasar</title>
      <link>https://nalar.dev/id/kredensial-tersimpan-overlayfs-memisahkan-akses-overlay-dari-filesystem-dasar/</link>
      <pubDate>Fri, 18 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/kredensial-tersimpan-overlayfs-memisahkan-akses-overlay-dari-filesystem-dasar/</guid>
      <description>&lt;h1 id=&#34;kredensial-tersimpan-overlayfs-memisahkan-akses-overlay-dari-akses-filesystem-dasar&#34;&gt;Kredensial Tersimpan OverlayFS Memisahkan Akses Overlay dari Akses Filesystem Dasar&lt;/h1&gt;&#xA;&lt;p&gt;Sebuah proses membuka path melalui mount OverlayFS dan tampak mengakses satu objek filesystem biasa. Kernel sebenarnya dapat mengacu ke layer atas, layer bawah, atau keduanya, sedangkan operasi tulis dapat memicu copy-up sebelum operasi yang diminta diteruskan. Indireksi ini membentuk persoalan otorisasi: pemanggil harus diizinkan memakai objek yang disajikan overlay, sementara akses internal ke filesystem dasar juga harus berjalan dengan identitas keamanan yang terdefinisi.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Landlock Menambahkan Lapisan Pembatasan Lokal Proses pada Kontrol Akses Linux</title>
      <link>https://nalar.dev/id/landlock-menambahkan-lapisan-pembatasan-lokal-proses-pada-kontrol-akses-linux/</link>
      <pubDate>Fri, 18 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/landlock-menambahkan-lapisan-pembatasan-lokal-proses-pada-kontrol-akses-linux/</guid>
      <description>&lt;p&gt;Sebuah service dapat dimulai dengan seluruh izin filesystem yang diberikan kepada identitas Unix-nya, tetapi hanya memerlukan sebagian kecil izin tersebut setelah inisialisasi. Mengganti akun service atau topologi mount dapat mengurangi otoritas itu, tetapi keduanya merupakan keputusan pada tingkat deployment. Linux Landlock menyediakan batas yang berbeda: proses dapat menambahkan pembatasan pada dirinya sendiri dan turunannya tanpa memperoleh privilege untuk memberikan akses baru.&lt;/p&gt;&#xA;&lt;p&gt;Landlock adalah Linux Security Module yang dapat ditumpuk. Aturannya menjadi constraint tambahan, bukan pengganti discretionary access control, capabilities, atau kebijakan LSM lain yang aktif. Aturan Landlock tidak dapat mengubah operasi yang ditolak menjadi diizinkan. Landlock hanya dapat menghapus otoritas yang sebelumnya dimiliki proses.&lt;/p&gt;</description>
    </item>
    <item>
      <title>SCM_RIGHTS Memindahkan Otoritas File Descriptor Melalui Unix Socket</title>
      <link>https://nalar.dev/id/scm-rights-memindahkan-otoritas-file-descriptor-melalui-unix-socket/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/scm-rights-memindahkan-otoritas-file-descriptor-melalui-unix-socket/</guid>
      <description>&lt;h1 id=&#34;scm_rights-memindahkan-otoritas-file-descriptor-melalui-unix-socket&#34;&gt;SCM_RIGHTS Memindahkan Otoritas File Descriptor Melalui Unix Socket&lt;/h1&gt;&#xA;&lt;p&gt;Sebuah layanan berprivilege dapat membuka file yang tidak dapat dibuka proses lain melalui pathname, lalu mengirim akses tersebut melalui Unix-domain socket. Proses penerima memperoleh file descriptor baru yang merujuk ke state open-file kernel yang sama. Tidak diperlukan lookup pathname kedua, dan kemampuan penerima untuk membuka path tersebut tidak dievaluasi ulang sebagai bagian dari transfer.&lt;/p&gt;&#xA;&lt;p&gt;Properti itu membuat &lt;code&gt;SCM_RIGHTS&lt;/code&gt; lebih dari sekadar fasilitas IPC. Mekanisme ini memindahkan capability kernel yang sudah terbentuk melewati batas proses. Keamanan bergantung pada kedua sisi pertukaran: pengirim harus membatasi descriptor yang boleh keluar dari domain otoritasnya, sedangkan penerima harus memperlakukan descriptor masuk sebagai objek berprivilege yang propertinya perlu divalidasi.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
