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 umum menjadi 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
- Daftar Kontrol Akses (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 utas. Peniruan identitas 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 deskriptor keamanan; beberapa objek yang tidak disebutkan namanya juga. 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
Daftar Kontrol Akses (ACL) memungkinkan kontrol halus atas akses ke objek. ACL adalah bagian dari deskriptor keamanan untuk setiap objek.
Setiap ACL berisi nol atau lebih Entri Kontrol Akses (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 dalam 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 menentukan 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 ACL 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 pemanggil. Asumsikan bahwa penelepon ingin membuka file yang memiliki ACL yang diperlihatkan dalam tabel berikut.
Contoh File ACL
| Izin | SID | Access |
|---|---|---|
| Izinkan | Akuntansi | Menulis, menghapus |
| Izinkan | Sales | Lampirkan |
| 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 dalam 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 Legal sebagai gantinya mendahului ACE untuk grup Akuntansi di ACL, prosesnya akan ditolak 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 dalam 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 pada 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 tersebut. 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:
- Aplikasi mode pengguna memanggil fungsi CreateFile , meneruskan nama file Microsoft Win32 yang valid.
- Mode pengguna Kernel32.dll meneruskan permintaan ke Ntdll.dll, yang mengonversi nama Win32 menjadi nama file Microsoft Windows NT.
- Ntdll.dll memanggil fungsi NtCreateFile dengan nama file Windows. Dalam Ntoskrnl.exe, Manajer I/O menangani NtCreateFile.
- Manajer I/O mengemas ulang permintaan ke dalam panggilan Object Manager.
- 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.
- 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.
- 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.
- 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.
- Driver melakukan pemeriksaan keamanan tambahan sesuai kebutuhan. Misalnya, jika permintaan menentukan objek di namespace layanan 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 pemanggil, 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 dapat; jika tidak dapat, ia 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, itu 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 di nonaktifkan 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 tiba, Manajer I/O memeriksa hak yang terkait dengan handel untuk memastikan bahwa proses 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.
Saat Manajer I/O membuat objek, I/O Manager 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 dan kemudian 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 namespacenya sendiri. Akibatnya, ketika pemanggil mencoba membuat objek di namespace perangkat, Manajer I/O memeriksa bahwa proses memiliki hak traversal ke direktori di jalur.
Dengan driver WDM, Manajer I/O tidak melakukan pemeriksaan keamanan terhadap namespace layanan, kecuali Objek Perangkat telah dibuat yang 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 memungkinkan aplikasi mengakses nama apa pun dalam namespace perangkat. Untuk informasi selengkapnya, lihat Mengontrol Akses Perangkat di Driver KMDF.
Batas keamanan Windows
Driver 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 dengan hak istimewa yang lebih rendah ke dalam proses istimewa yang lebih tinggi.
Semakin tinggi disparitas dalam tingkat hak istimewa, semakin menarik batasnya adalah untuk penyerang yang ingin melakukan serangan seperti serangan eskalasi hak istimewa terhadap driver 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.
Setiap data yang melewati batas kepercayaan tidak tepercaya dan harus divalidasi.
Diagram ini menunjukkan tiga driver kernel, dan dua aplikasi, satu di 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 pada tingkat admin, jalur (1) adalah jalur risiko yang lebih tinggi untuk serangan eskalasi karena batas kepercayaan 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 merupakan 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 tertandingi. Untuk informasi selengkapnya, lihat Pemodelan ancaman untuk driver.
- Lihat Daftar periksa keamanan driver untuk rekomendasi keamanan driver tambahan.