Model keamanan Windows untuk pengembang driver

Model keamanan Windows didasarkan pada objek yang dapat diamankan. Setiap komponen sistem operasi harus memastikan keamanan objek yang bertanggung jawab. Oleh karena itu, driver harus melindungi keamanan perangkat dan objek perangkat mereka.

Topik ini merangkum bagaimana model keamanan Windows berlaku untuk driver mode kernel.

Model keamanan Windows

Model keamanan Windows didasarkan terutama pada hak per objek, dengan sejumlah kecil hak istimewa di seluruh sistem. Objek yang dapat diamankan meliputi, —tetapi tidak terbatas pada, —proses, utas, peristiwa, dan objek sinkronisasi lainnya, serta file, direktori, dan perangkat.

Untuk setiap jenis objek, peta hak baca, tulis, dan eksekusi generik ke hak khusus objek terperinci. Misalnya, untuk file dan direktori, hak yang mungkin mencakup hak untuk membaca atau menulis file atau direktori, hak untuk membaca atau menulis atribut file yang diperluas, hak untuk melintasi direktori, dan hak untuk menulis deskriptor keamanan objek.

Model keamanan melibatkan konsep berikut:

• Pengidentifikasi keamanan (SID)
• Token akses
• Deskriptor keamanan
• Access Control Lists (ACL)
• Hak Istimewa

Pengidentifikasi Keamanan (SID)

Pengidentifikasi keamanan (SID, juga disebut prinsipal) mengidentifikasi pengguna, grup, atau sesi masuk. Setiap pengguna memiliki SID unik, yang diambil oleh sistem operasi saat masuk.

SID dikeluarkan oleh otoritas seperti sistem operasi atau server domain. Beberapa SID terkenal dan memiliki nama serta pengidentifikasi. Misalnya, SID S-1-1-0 mengidentifikasi Semua Orang (atau Dunia).

Token akses

Setiap proses memiliki token akses. Token akses menjelaskan konteks keamanan lengkap proses. Ini berisi SID pengguna, SID grup tempat pengguna berada, dan SID sesi masuk, serta daftar hak istimewa di seluruh sistem yang diberikan kepada pengguna.

Secara default, sistem menggunakan token akses utama untuk proses setiap kali utas proses berinteraksi dengan objek yang dapat diamankan. Namun, utas dapat meniru akun klien. Ketika utas meniru, ia memiliki token peniruan selain token utamanya sendiri. Token peniruan menjelaskan konteks keamanan akun pengguna yang ditiru oleh utas. Peniruan nama sangat umum dalam penanganan Panggilan Prosedur Jarak Jauh (RPC).

Token akses yang menjelaskan konteks keamanan terbatas untuk utas atau proses disebut token terbatas. SID dalam token terbatas hanya dapat diatur untuk menolak akses, bukan untuk mengizinkan akses, ke objek yang dapat diamankan. Selain itu, token dapat menggambarkan serangkaian hak istimewa di seluruh sistem yang terbatas. SID dan identitas pengguna tetap sama, tetapi hak akses pengguna dibatasi saat prosesnya menggunakan token terbatas. Fungsi CreateRestrictedToken membuat token terbatas.

Deskriptor keamanan

Setiap objek Windows bernama memiliki pendeskripsi keamanan; beberapa objek yang tidak disebutkan namanya juga melakukannya. Deskriptor keamanan menjelaskan pemilik dan SID grup untuk objek bersama dengan ACL-nya.

Deskriptor keamanan objek biasanya dibuat oleh fungsi yang membuat objek . Ketika driver memanggil rutinitas IoCreateDevice atau IoCreateDeviceSecure untuk membuat objek perangkat, sistem menerapkan deskriptor keamanan ke objek perangkat yang dibuat dan mengatur ACL untuk objek . Untuk sebagian besar perangkat, ACL ditentukan dalam file Informasi perangkat (INF).

Untuk informasi selengkapnya , Deskriptor Keamanan dalam dokumentasi driver kernel.

Daftar Kontrol Akses

Access Control Lists (ACL) memungkinkan kontrol halus atas akses ke objek. ACL adalah bagian dari deskriptor keamanan untuk setiap objek.

Setiap ACL berisi nol atau lebih Access Control Entri (ACE). Setiap ACE, pada gilirannya, berisi satu SID yang mengidentifikasi pengguna, grup, atau komputer dan daftar hak yang ditolak atau diizinkan untuk SID tersebut.

ACL untuk objek perangkat

ACL untuk objek perangkat dapat diatur dengan salah satu dari tiga cara:

• Atur di deskriptor keamanan default untuk jenis perangkatnya.
• Dibuat secara terprogram oleh fungsi RtlCreateSecurityDescriptor dan diatur oleh fungsi RtlSetDaclSecurityDescriptor .
• Ditentukan dalam Security Descriptor Definition Language (SDDL) dalam file INF perangkat atau dalam panggilan ke rutinitas IoCreateDeviceSecure .

Semua driver harus menggunakan SDDL dalam file INF untuk menentukan ACL untuk objek perangkat mereka.

SDDL adalah bahasa deskripsi yang dapat diperluas yang memungkinkan komponen membuat ACL dalam format string. SDDL digunakan oleh kode mode pengguna dan mode kernel. Gambar berikut menunjukkan format string SDDL untuk objek perangkat.

Nilai Akses menentukan jenis akses yang diizinkan. Nilai SID menentukan pengidentifikasi keamanan yang menentukan kepada siapa nilai Akses berlaku (misalnya, pengguna atau grup).

Misalnya, string SDDL berikut memungkinkan akses Sistem (SY) ke semuanya dan memungkinkan orang lain (WD) hanya membaca akses:

“D:P(A;;GA;;;SY)(A;;GR;;;WD)”

File header wdmsec.h juga menyertakan sekumpulan string SDDL yang telah ditentukan sebelumnya yang cocok untuk objek perangkat. Misalnya, file header mendefinisikan SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_RWX_RES_RWX sebagai berikut:

"D:P(A;;GA;;;SY)(A;;GRGWGX;;;BA)(A;;GRGWGX;;;WD)(A;;GRGWGX;;;RC)"

Segmen pertama dari string ini memungkinkan kernel dan sistem operasi (SY) kontrol penuh atas perangkat. Segmen kedua memungkinkan siapa pun di grup Administrator bawaan (BA) untuk mengakses seluruh perangkat, tetapi tidak mengubah ACL. Segmen ketiga memungkinkan semua orang (WD) untuk membaca atau menulis ke perangkat, dan segmen keempat memberikan hak yang sama untuk kode yang tidak tepercaya (RC). Driver dapat menggunakan string yang telah ditentukan sebelumnya apa adanya atau sebagai model untuk string khusus objek perangkat.

Semua objek perangkat dalam tumpukan harus memiliki ACL yang sama. Mengubah ACL pada satu objek perangkat di tumpukan mengubah ACL pada seluruh tumpukan perangkat.

Namun, menambahkan objek perangkat baru ke tumpukan tidak mengubah ACL apa pun, baik objek perangkat baru (jika memiliki ACL) atau objek perangkat yang ada di tumpukan. Ketika driver membuat objek perangkat baru dan melampirkannya ke bagian atas tumpukan, driver harus menyalin ACL untuk tumpukan ke objek perangkat baru dengan menyalin bidang DeviceObject.Characteristics dari driver bawah berikutnya.

Rutinitas IoCreateDeviceSecure mendukung subset string SDDL yang menggunakan SID yang telah ditentukan sebelumnya seperti WD dan SY. API mode pengguna dan file INF mendukung sintaks SDDL lengkap.

Pemeriksaan keamanan menggunakan ACL

Saat proses meminta akses ke objek, pemeriksaan keamanan membandingkan ACL untuk objek dengan SID dalam token akses pemanggil.

Sistem membandingkan ACE dalam urutan top-down yang ketat dan berhenti pada kecocokan pertama yang relevan. Oleh karena itu, saat membuat ACL, Anda harus selalu menempatkan ACE penolakan di atas ACE pemberian yang sesuai. Contoh berikut menunjukkan bagaimana perbandingan berlangsung.

Contoh 1: Membandingkan ACL dengan token akses

Contoh 1 menunjukkan bagaimana sistem membandingkan ACL dengan token akses untuk proses penelepon. Asumsikan bahwa pemanggil ingin membuka file yang memiliki ACL yang diperlihatkan dalam tabel berikut.

Contoh File ACL

Izin	SID	Access
Izinkan	Akuntansi	Menulis, menghapus
Izinkan	Sales	Append
Tolak	Hukum	Menambahkan, menulis, menghapus
Izinkan	Semua orang	Read

ACL ini memiliki empat ACL, yang berlaku khusus untuk grup Akuntansi, Penjualan, Hukum, dan Semua Orang.

Selanjutnya, asumsikan token akses untuk proses permintaan berisi SID untuk satu pengguna dan tiga grup, dalam urutan berikut:

Pengguna Jim (S-1-5-21...)

Akuntansi Grup (S-1-5-22...)

Hukum Grup (S-1-5-23...)

Kelompokkan Semua Orang (S-1-1-0)

Saat membandingkan file ACL dengan token akses, sistem pertama-tama mencari ACE untuk pengguna Jim di ACL file. Tidak ada yang muncul, jadi selanjutnya mencari ACE untuk grup Akuntansi. Seperti yang ditunjukkan pada tabel sebelumnya, ACE untuk grup Akuntansi muncul sebagai entri pertama dalam ACL file, sehingga proses Jim diberikan hak untuk menulis atau menghapus file dan perbandingan berhenti. Jika ACE untuk grup Hukum sebagai gantinya mendahului ACE untuk grup Akuntansi di ACL, prosesnya akan ditolak untuk menulis, menambahkan, dan menghapus akses ke file.

Contoh 2: Membandingkan ACL dengan token terbatas

Sistem membandingkan ACL dengan token terbatas dengan cara yang sama seperti membandingkannya dengan token yang tidak dibatasi. Namun, SID penolakan dalam token terbatas hanya dapat mencocokkan ACE Tolak dalam ACL.

Contoh 2 menunjukkan bagaimana sistem membandingkan ACL file dengan token terbatas. Asumsikan file memiliki ACL yang sama yang ditunjukkan pada tabel sebelumnya. Namun, dalam contoh ini, proses memiliki token terbatas yang berisi SID berikut:

Pengguna Jim (S-1-5-21...) Menyangkal

Akuntansi Grup (S-1-5-22...) Menyangkal

Hukum Grup (S-1-5-23...) Menyangkal

Kelompokkan Semua Orang (S-1-1-0)

ACL file tidak mencantumkan SID Jim, sehingga sistem melanjutkan ke SID grup Akuntansi. Meskipun ACL file memiliki ACE untuk grup Akuntansi, ACE ini memungkinkan akses; oleh karena itu, itu tidak cocok dengan SID dalam token terbatas proses, yang menolak akses. Akibatnya, sistem berlanjut ke SID grup Hukum. ACL untuk file berisi ACE untuk grup Legal yang menolak akses, sehingga proses tidak dapat menulis, menambahkan, atau menghapus file.

Hak Istimewa

Hak istimewa adalah hak bagi pengguna untuk melakukan operasi terkait sistem di komputer lokal, seperti memuat driver, mengubah waktu, atau mematikan sistem.

Hak istimewa berbeda dari hak akses karena berlaku untuk tugas dan sumber daya terkait sistem daripada objek, dan karena ditetapkan ke pengguna atau grup oleh administrator sistem, bukan oleh sistem operasi.

Token akses untuk setiap proses berisi daftar hak istimewa yang diberikan untuk proses. Hak istimewa harus diaktifkan secara khusus sebelum digunakan. Untuk informasi selengkapnya tentang hak istimewa, lihat Hak istimewa dalam dokumentasi driver kernel.

Skenario model keamanan Windows: Membuat file

Sistem menggunakan konstruksi keamanan yang dijelaskan dalam model keamanan Windows setiap kali proses membuat handel ke file atau objek.

Diagram berikut menunjukkan tindakan terkait keamanan yang dipicu saat proses mode pengguna mencoba membuat file.

Diagram sebelumnya menunjukkan bagaimana sistem merespons ketika aplikasi mode pengguna memanggil fungsi CreateFile . Catatan berikut mengacu pada angka yang dilingkari dalam gambar:

1. Aplikasi mode pengguna memanggil fungsi CreateFile , meneruskan nama file Microsoft Win32 yang valid.
2. Mode pengguna Kernel32.dll meneruskan permintaan ke Ntdll.dll, yang mengonversi nama Win32 menjadi nama file Microsoft Windows NT.
3. Ntdll.dll memanggil fungsi NtCreateFile dengan nama file Windows. Dalam Ntoskrnl.exe, Manajer I/O menangani NtCreateFile.
4. Manajer I/O mengemas ulang permintaan ke dalam panggilan Object Manager.
5. Object Manager menyelesaikan tautan simbolis dan memastikan bahwa pengguna memiliki hak traversal untuk jalur tempat file akan dibuat. Untuk informasi selengkapnya, lihat Pemeriksaan keamanan di Object Manager.
6. Object Manager memanggil komponen sistem yang memiliki jenis objek dasar yang terkait dengan permintaan. Untuk permintaan pembuatan file, komponen ini adalah Manajer I/O, yang memiliki objek perangkat.
7. Manajer I/O memeriksa pendeskripsi keamanan untuk objek perangkat terhadap token akses untuk proses pengguna untuk memastikan bahwa pengguna memiliki akses yang diperlukan ke perangkat. Untuk informasi selengkapnya, lihat Pemeriksaan keamanan di Manajer I/O.
8. Jika proses pengguna memiliki akses yang diperlukan, Manajer I/O membuat handel dan mengirim permintaan IRP_MJ_CREATE ke driver untuk perangkat atau sistem file.
9. Driver melakukan pemeriksaan keamanan tambahan sesuai kebutuhan. Misalnya, jika permintaan menentukan objek di namespace perangkat, driver harus memastikan bahwa pemanggil memiliki hak akses yang diperlukan. Untuk informasi selengkapnya, lihat Pemeriksaan keamanan di driver.

Pemeriksaan keamanan di Object Manager

Tanggung jawab untuk memeriksa hak akses milik komponen tingkat tertinggi yang dapat melakukan pemeriksaan tersebut. Jika Object Manager dapat memverifikasi hak akses penelepon, itu melakukannya. Jika tidak, Object Manager meneruskan permintaan ke komponen yang bertanggung jawab atas jenis objek yang mendasar. Komponen itu, pada gilirannya, memverifikasi akses, jika bisa; jika tidak dapat, itu meneruskan permintaan ke komponen yang masih lebih rendah, seperti driver.

Object Manager memeriksa ACL untuk jenis objek sederhana, seperti peristiwa dan kunci mutex. Untuk objek yang memiliki namespace, pemilik jenis melakukan pemeriksaan keamanan. Misalnya, Manajer I/O dianggap sebagai pemilik jenis untuk objek perangkat dan objek file. Jika Object Manager menemukan nama objek perangkat atau objek file saat mengurai nama, Object Manager menyerahkan nama ke Manajer I/O, seperti dalam skenario pembuatan file yang disajikan di atas. Manajer I/O kemudian memeriksa hak akses jika bisa. Jika nama menentukan objek dalam namespace perangkat, Manajer I/O yang mematikan nama ke driver perangkat (atau sistem file), dan driver tersebut bertanggung jawab untuk memvalidasi akses yang diminta.

Pemeriksaan keamanan di Manajer I/O

Ketika Manajer I/O membuat handel, ia memeriksa hak objek terhadap token akses proses dan kemudian menyimpan hak yang diberikan kepada pengguna bersama dengan handel. Ketika permintaan I/O nanti tiba, Manajer I/O memeriksa hak yang terkait dengan handel untuk memastikan bahwa proses tersebut memiliki hak untuk melakukan operasi I/O yang diminta. Misalnya, jika proses nanti meminta operasi tulis, Manajer I/O memeriksa hak yang terkait dengan handel untuk memastikan bahwa pemanggil memiliki akses tulis ke objek.

Jika handel diduplikasi, hak dapat dihapus dari salinan, tetapi tidak ditambahkan ke dalamnya.

Ketika Manajer I/O membuat objek, ia mengonversi mode akses Win32 generik ke hak khusus objek. Misalnya, hak berikut berlaku untuk file dan direktori:

Mode akses Win32	Hak khusus objek
GENERIC_READ	ReadData
GENERIC_WRITE	WriteData
GENERIC_EXECUTE	ReadAttributes
GENERIC_ALL	Semua

Untuk membuat file, proses harus memiliki hak traversal ke direktori induk di jalur target. Misalnya, untuk membuat \Device\CDROM0\Directory\File.txt, proses harus memiliki hak untuk melintasi \Device, \Device\CDROM0, dan \Device\CDROM0\Directory. Manajer I/O hanya memeriksa hak traversal untuk direktori ini.

Manajer I/O memeriksa hak traversal saat mengurai nama file. Jika nama file adalah tautan simbolis, Manajer I/O menyelesaikannya ke jalur lengkap lalu memeriksa hak traversal, dimulai dari akar. Misalnya, asumsikan tautan simbolis \DosDevices\D memetakan ke nama perangkat Windows NT \Device\CDROM0. Proses harus memiliki hak traversal ke direktori \Device.

Untuk informasi selengkapnya, lihat Penanganan Objek dan Keamanan Objek.

Pemeriksaan keamanan pada driver

Kernel sistem operasi memperlakukan setiap driver, berlaku, sebagai sistem file dengan namespace layanannya sendiri. Akibatnya, ketika penelepon mencoba membuat objek di namespace perangkat, Manajer I/O memeriksa bahwa proses tersebut memiliki hak traversal ke direktori di jalur.

Dengan driver WDM, Manajer I/O tidak melakukan pemeriksaan keamanan terhadap namespace, kecuali Objek Perangkat telah dibuat menentukan FILE_DEVICE_SECURE_OPEN. Ketika FILE_DEVICE_SECURE_OPEN tidak diatur, driver bertanggung jawab untuk memastikan keamanan namespace layanannya. Untuk informasi selengkapnya, lihat Mengontrol Akses Namespace Perangkat dan Mengamankan Objek Perangkat.

Untuk driver WDF, bendera FILE_DEVICE_SECURE_OPEN selalu diatur, sehingga akan ada pemeriksaan deskriptor keamanan perangkat sebelum mengizinkan aplikasi mengakses nama apa pun dalam namespace perangkat. Untuk informasi selengkapnya, lihat Mengontrol Akses Perangkat di Driver KMDF.

Batas keamanan Windows

Driver yang berkomunikasi satu sama lain dan ke pemanggil mode pengguna dari tingkat hak istimewa yang berbeda dapat dianggap melewati batas kepercayaan. Batas kepercayaan adalah jalur eksekusi kode apa pun yang melintasi dari proses hak istimewa yang lebih rendah ke dalam proses hak istimewa yang lebih tinggi.

Semakin tinggi perbedaan dalam tingkat hak istimewa, semakin menarik batasnya adalah untuk penyerang yang ingin melakukan serangan seperti serangan eskalasi hak istimewa terhadap pengemudi atau proses yang ditargetkan.

Bagian dari proses pembuatan model ancaman adalah memeriksa batas keamanan dan mencari jalur yang tidak dipantau. Untuk informasi selengkapnya, lihat Pemodelan ancaman untuk driver.

Data apa pun yang melintasi batas kepercayaan tidak tepercaya dan harus divalidasi.

Diagram ini menunjukkan tiga driver kernel, dan dua aplikasi, satu dalam kontainer aplikasi dan satu aplikasi yang berjalan dengan hak admin. Garis merah menunjukkan contoh batas kepercayaan.

Karena kontainer aplikasi dapat memberikan batasan tambahan, dan tidak berjalan di tingkat admin, jalur (1) adalah jalur risiko yang lebih tinggi untuk serangan eskalasi karena batas kepercayaan adalah antara kontainer aplikasi (proses hak istimewa yang sangat rendah) dan driver kernel.

Jalur (2) adalah jalur risiko yang lebih rendah, karena aplikasi berjalan dengan hak admin dan memanggil langsung ke driver kernel. Admin sudah menjadi hak istimewa yang cukup tinggi pada sistem sehingga permukaan serangan dari admin ke kernel kurang dari target yang menarik bagi penyerang, tetapi masih merupakan batas kepercayaan yang patut dicatat.

Jalur (3) adalah contoh jalur eksekusi kode yang melewati beberapa batas kepercayaan yang dapat dilewatkan jika model ancaman tidak dibuat. Dalam contoh ini, ada batas kepercayaan antara driver 1 dan driver 3, karena driver 1 mengambil input dari aplikasi mode pengguna dan meneruskannya langsung ke driver 3.

Semua input yang masuk ke driver dari mode pengguna tidak tepercaya dan harus divalidasi. Input yang berasal dari driver lain mungkin juga tidak tepercaya tergantung pada apakah driver sebelumnya hanya pass-through sederhana (misalnya data diterima oleh driver 1 dari aplikasi 1, driver 1 tidak melakukan validasi pada data dan hanya meneruskannya ke driver 3). Pastikan untuk mengidentifikasi semua permukaan serangan dan batas kepercayaan dan memvalidasi semua data yang melintasinya, dengan membuat model ancaman lengkap.

Rekomendasi Model Keamanan Windows

• Atur ACL default yang kuat dalam panggilan ke rutinitas IoCreateDeviceSecure .
• Tentukan ACL dalam file INF untuk setiap perangkat. ACL ini dapat melonggarkan ACL default yang ketat jika perlu.
• Atur karakteristik FILE_DEVICE_SECURE_OPEN untuk menerapkan pengaturan keamanan objek perangkat ke namespace perangkat.
• Jangan tentukan IOCTL yang mengizinkan FILE_ANY_ACCESS kecuali akses tersebut tidak dapat dieksploitasi dengan berbahaya.
• Gunakan rutinitas IoValidateDeviceIoControlAccess untuk memperketat keamanan pada IOCTLS yang ada yang memungkinkan FILE_ANY_ACCESS.
• Buat model ancaman untuk memeriksa batas keamanan dan mencari jalur yang tidak dipantau. Untuk informasi selengkapnya, lihat Pemodelan ancaman untuk driver.
• Lihat Daftar periksa keamanan driver untuk rekomendasi keamanan driver tambahan.

Lihat juga

Mengamankan Objek Perangkat

Daftar periksa keamanan driver