Part Five

Protection and Security

Mekanisme perlindungan mengendalikan akses ke sistem dengan membatasi jenis akses file yang
diperbolehkan bagi pengguna. Selain itu, perlindungan harus memastikan bahwa hanya proses yang
telah mendapatkan otorisasi yang tepat dari sistem operasi dapat beroperasi pada segmen memori,
CPU, dan sumber daya lainnya.

Perlindungan disediakan melalui mekanisme yang mengontrol akses program, proses, atau pengguna
ke sumber daya yang ditentukan oleh sistem komputer. Mekanisme ini harus memberikan cara untuk
menentukan kontrol yang akan diberlakukan, bersama dengan cara untuk menegakkannya.

Keamanan memastikan otentikasi pengguna sistem untuk melindungi integritas informasi yang
disimpan di dalam sistem (baik data maupun kode), serta sumber daya fisik dari sistem komputer.
Sistem keamanan mencegah akses yang tidak sah, penghancuran atau perubahan data yang jahat,
dan pengenalan inkonsistensi yang tidak disengaja.

Protection

Proses dalam sistem operasi harus dilindungi dari aktivitas satu sama lain. Untuk memberikan
perlindungan tersebut, kita dapat menggunakan berbagai mekanisme untuk memastikan bahwa
hanya proses yang telah mendapatkan otorisasi yang tepat dari sistem operasi dapat beroperasi pada
file, segmen memori, CPU, dan sumber daya lainnya dalam sistem.

Perlindungan mengacu pada mekanisme untuk mengendalikan akses program, proses, atau
pengguna ke sumber daya yang ditentukan oleh sistem komputer. Mekanisme ini harus menyediakan
cara untuk menentukan kontrol yang akan diberlakukan, bersama dengan cara penegakan. Kami
membedakan antara perlindungan dan keamanan, yang merupakan ukuran keyakinan bahwa
integritas sistem dan datanya akan terjaga. Dalam bab ini, kami fokus pada perlindungan. Jaminan
keamanan adalah topik yang lebih luas, dan kami membahasnya dalam Bab 15.

TUJUAN BAB

• Membahas tujuan dan prinsip perlindungan dalam sistem komputer modern.

• Menjelaskan bagaimana domain perlindungan, yang dikombinasikan dengan matriks akses,

digunakan untuk menentukan sumber daya yang dapat diakses oleh sebuah proses.

• Meninjau sistem perlindungan berbasis kapabilitas dan bahasa.

14.1 Tujuan Perlindungan

Seiring dengan perkembangan sistem komputer yang semakin canggih dan luas dalam aplikasinya,
kebutuhan untuk melindungi integritasnya juga meningkat. Perlindungan awalnya dikonsepkan
sebagai bagian tambahan dari sistem operasi multiprogram, sehingga pengguna yang tidak dapat
dipercayai dapat berbagi ruang nama logis yang umum, seperti direktori file, atau berbagi ruang
nama fisik yang umum, seperti memori. Konsep perlindungan modern telah berkembang untuk
meningkatkan kehandalan dari sistem kompleks mana pun yang menggunakan sumber daya
bersama.

Kita perlu memberikan perlindungan dengan beberapa alasan. Yang paling jelas adalah kebutuhan
untuk mencegah pelanggaran akses yang disengaja oleh pengguna yang nakal. Namun, yang lebih
penting secara umum adalah kebutuhan untuk memastikan bahwa setiap komponen program yang
aktif dalam suatu sistem menggunakan sumber daya sistem hanya sesuai dengan kebijakan yang
telah ditetapkan. Persyaratan ini sangat penting untuk sistem yang dapat diandalkan.

Perlindungan dapat meningkatkan kehandalan dengan mendeteksi kesalahan laten di antarmuka

antara subsistem komponen. Deteksi dini kesalahan antarmuka seringkali dapat mencegah
kontaminasi subsistem yang sehat oleh subsistem yang bermasalah. Selain itu, sumber daya yang
tidak dilindungi tidak dapat membela diri dari penggunaan (atau penyalahgunaan) oleh pengguna
yang tidak berizin atau tidak kompeten. Sistem yang berorientasi pada perlindungan menyediakan
cara untuk membedakan penggunaan yang diizinkan dan yang tidak diizinkan.

Peran perlindungan dalam sistem komputer adalah menyediakan mekanisme untuk menegakkan
kebijakan yang mengatur penggunaan sumber daya. Kebijakan ini dapat ditetapkan dalam berbagai
cara. Beberapa diantaranya telah ditentukan dalam desain sistem, sementara yang lain
diformulasikan oleh manajemen sistem. Ada juga kebijakan yang ditentukan oleh pengguna individu
untuk melindungi file dan program mereka sendiri. Sistem perlindungan harus memiliki fleksibilitas
untuk menegakkan berbagai kebijakan.

Kebijakan penggunaan sumber daya dapat bervariasi berdasarkan aplikasi, dan mereka dapat
berubah seiring waktu. Oleh karena itu, perlindungan tidak lagi hanya menjadi perhatian perancang
sistem operasi. Programmer aplikasi juga perlu menggunakan mekanisme perlindungan untuk
melindungi sumber daya yang dibuat dan didukung oleh subsistem aplikasi. Dalam bab ini, kami
menjelaskan mekanisme perlindungan yang seharusnya disediakan oleh sistem operasi, tetapi
perancang aplikasi juga dapat menggunakannya dalam merancang perangkat lunak perlindungan
mereka sendiri.

Perlu dicatat bahwa mekanisme berbeda dari kebijakan. Mekanisme menentukan bagaimana sesuatu
akan dilakukan; kebijakan menentukan apa yang akan dilakukan. Pemisahan kebijakan dan
mekanisme penting untuk fleksibilitas. Kebijakan kemungkinan akan berubah dari satu tempat ke
tempat atau dari waktu ke waktu. Dalam kasus terburuk, setiap perubahan kebijakan akan
memerlukan perubahan dalam mekanisme yang mendasarinya. Menggunakan mekanisme umum
memungkinkan kita untuk menghindari situasi tersebut.
14.2 Prinsip Perlindungan

Seringkali, sebuah prinsip panduan dapat digunakan sepanjang suatu proyek, seperti

desain sistem operasi. Mengikuti prinsip ini mempermudah keputusan desain dan menjaga sistem
tetap konsisten dan mudah dipahami. Prinsip panduan yang telah diuji waktu dan kunci dalam
perlindungan adalah prinsip hak terkecil. Ini menentukan bahwa program, pengguna, dan bahkan
sistem diberikan hak yang cukup untuk melakukan tugas mereka.

Pertimbangkan analogi seorang penjaga keamanan dengan kunci akses. Jika kunci ini hanya
memungkinkan penjaga untuk masuk ke area publik yang dia jaga, maka penyalahgunaan kunci
tersebut akan mengakibatkan kerusakan minimal. Namun, jika kunci akses memungkinkan akses ke
semua area, maka kerusakan akibat hilang, dicuri, disalahgunakan, disalin, atau ditembus akan jauh
lebih besar.

Sistem operasi yang mengikuti prinsip hak terkecil mengimplementasikan fiturnya, program,
panggilan sistem, dan struktur data sehingga kegagalan atau kompromi komponen tersebut
menyebabkan kerusakan minimal dan memungkinkan kerusakan minimal yang dapat terjadi. Sebagai
contoh, overflow dari buffer dalam suatu daemon sistem mungkin akan menyebabkan proses
daemon gagal, tetapi seharusnya tidak memungkinkan eksekusi kode dari tumpukan proses daemon
yang akan memungkinkan pengguna jarak jauh mendapatkan hak akses maksimum dan akses ke
seluruh sistem (seperti yang sering terjadi saat ini).

Sistem operasi seperti itu juga menyediakan panggilan sistem dan layanan yang memungkinkan
aplikasi ditulis dengan kontrol akses yang sangat halus. Ini menyediakan mekanisme untuk
mengaktifkan hak akses saat diperlukan dan menonaktifkannya saat tidak diperlukan. Juga
bermanfaat adalah penciptaan jejak audit untuk semua akses fungsi yang berhak. Jejak audit
memungkinkan programmer, administrator sistem, atau petugas penegak hukum untuk melacak
semua aktivitas perlindungan dan keamanan di sistem.

Mengelola pengguna dengan prinsip hak terkecil melibatkan pembuatan akun terpisah untuk setiap
pengguna, dengan hak akses yang sesuai dengan kebutuhan pengguna. Seorang operator yang perlu
memasang pita dan mencadangkan file di sistem hanya memiliki akses kepada perintah dan file yang
diperlukan untuk menyelesaikan pekerjaan tersebut. Beberapa sistem mengimplementasikan kontrol
akses berbasis peran (RBAC) untuk menyediakan fungsionalitas ini.

Komputer yang diimplementasikan di fasilitas komputasi dengan prinsip hak terkecil dapat dibatasi
untuk menjalankan layanan tertentu, mengakses host jarak jauh tertentu melalui layanan tertentu,
dan melakukannya selama waktu tertentu. Biasanya, pembatasan-pembatasan ini diimplementasikan
melalui mengaktifkan atau menonaktifkan setiap layanan dan dengan menggunakan daftar kontrol
akses, seperti yang dijelaskan di Bagian 11.6.2 dan Bagian 14.6.
Prinsip hak terkecil dapat membantu menciptakan lingkungan komputasi yang lebih aman. Namun,
sayangnya, seringkali tidak demikian. Sebagai contoh, Windows 2000 memiliki skema perlindungan
yang kompleks di intinya namun memiliki banyak celah keamanan. Sebagai perbandingan, Solaris
dianggap relatif aman, meskipun merupakan varian UNIX yang secara historis dirancang dengan
perlindungan yang minim. Salah satu alasan perbedaannya mungkin adalah bahwa Windows 2000
memiliki lebih banyak baris kode dan lebih banyak layanan daripada Solaris, sehingga memiliki lebih
banyak yang harus diamankan dan dilindungi. Alasan lain bisa jadi adalah skema perlindungan dalam
Windows 2000 tidak lengkap atau melindungi aspek yang salah dari sistem operasi, sehingga
meninggalkan area-area lain yang rentan.

14.3 Domain Perlindungan

Sebuah sistem komputer adalah kumpulan proses dan objek. Dengan objek, kami maksud baik objek
perangkat keras (seperti CPU, segmen memori, printer, disk, dan pita penggerak) maupun objek
perangkat lunak (seperti file, program, dan semafor). Setiap objek memiliki nama unik yang
membedakannya dari semua objek lain dalam sistem, dan setiap objek hanya dapat diakses melalui
operasi yang telah ditentukan dengan jelas dan bermakna. Objek pada dasarnya adalah jenis data
abstrak.

Operasi yang mungkin tergantung pada objeknya. Sebagai contoh, pada CPU, kita hanya dapat
menjalankannya. Segmen memori dapat dibaca dan ditulis, sedangkan CD-ROM atau DVD-ROM
hanya dapat dibaca. Pita penggerak dapat dibaca, ditulis, dan dikembalikan. File-data dapat dibuat,
dibuka, dibaca, ditulis, ditutup, dan dihapus; file program dapat dibaca, ditulis, dieksekusi, dan
dihapus.

Sebuah proses seharusnya diizinkan untuk mengakses hanya sumber daya yang telah diotorisasi
untuknya. Selain itu, pada setiap saat, seorang proses seharusnya hanya dapat mengakses sumber
daya yang saat ini diperlukan untuk menyelesaikan tugasnya. Persyaratan kedua ini, yang sering
disebut sebagai prinsip perlu-tahu, berguna untuk membatasi jumlah kerusakan yang dapat
disebabkan oleh proses yang bermasalah dalam sistem. Sebagai contoh, ketika proses p memanggil
prosedur A(), prosedur tersebut harus diizinkan untuk mengakses hanya variabel-variabelnya sendiri
dan parameter-parameter formal yang dilewatkan padanya; itu seharusnya tidak dapat mengakses
semua variabel proses p. Demikian pula, pertimbangkan kasus di mana proses p memanggil kompiler
untuk mengkompilasi file tertentu. Kompiler seharusnya tidak dapat mengakses file-file sembarangan
tetapi seharusnya hanya memiliki akses ke subset file yang telah ditentukan dengan baik (seperti file
sumber, file daftar, dan sebagainya) yang terkait dengan file yang akan dikompilasi. Sebaliknya,
kompiler mungkin memiliki file-file pribadi yang digunakan untuk tujuan akuntansi atau optimisasi
yang seharusnya tidak dapat diakses oleh proses p. Prinsip perlu-tahu mirip dengan prinsip hak
terkecil yang dibahas di Bagian 14.2, karena tujuan perlindungan adalah untuk meminimalkan risiko
pelanggaran keamanan yang mungkin terjadi.

14.3.1 Struktur Domain

Untuk memudahkan skema yang baru saja dijelaskan, sebuah proses beroperasi dalam suatu domain
perlindungan, yang menentukan sumber daya yang dapat diakses oleh proses tersebut. Setiap
domain mendefinisikan sekumpulan objek dan jenis operasi yang dapat dipanggil pada setiap objek.
Kemampuan untuk menjalankan operasi pada objek adalah hak akses. Sebuah domain adalah
kumpulan hak akses, masing-masing berbentuk pasangan terurut <nama-objek, himpunan-hak>.
Sebagai contoh, jika domain D memiliki hak akses <file F, {baca, tulis}>, maka proses yang dieksekusi
dalam domain D dapat membaca dan menulis file F. Namun, proses tersebut tidak dapat melakukan
operasi lain pada objek tersebut.

Domain-domain dapat berbagi hak akses. Sebagai contoh, dalam Gambar 14.1, kita memiliki tiga
domain: D1, D2, dan D3. Hak akses <O4, {cetak}> dibagikan oleh D2 dan D3, yang berarti bahwa
proses yang dieksekusi dalam salah satu dari dua domain ini dapat mencetak objek O4. Perlu dicatat
bahwa sebuah proses harus dieksekusi dalam domain D1 untuk membaca dan menulis objek O1,
sedangkan hanya proses dalam domain D3 yang dapat menjalankan objek O1.

Asosiasi antara proses dan domain dapat bersifat statis, jika kumpulan sumber daya yang tersedia
untuk proses tetap selama seluruh masa hidup proses, atau bersifat dinamis. Seperti yang dapat
diharapkan, menetapkan domain perlindungan yang dinamis lebih rumit daripada menetapkan
domain perlindungan yang statis.

Jika asosiasi antara proses dan domain bersifat tetap, dan kita ingin mematuhi prinsip perlu-tahu,
maka mekanisme harus tersedia untuk mengubah konten domain. Hal ini disebabkan oleh kenyataan
bahwa suatu proses mungkin menjalankan dua fase yang berbeda dan mungkin, misalnya,
memerlukan akses baca dalam satu fase dan akses tulis dalam fase lainnya. Jika sebuah domain
bersifat statis, kita harus mendefinisikan domain tersebut untuk mencakup baik akses baca maupun
akses tulis. Namun, pengaturan ini memberikan lebih banyak hak akses daripada yang dibutuhkan
dalam masing-masing dua fase, karena kita memiliki akses baca dalam fase di mana kita hanya
memerlukan akses tulis, dan sebaliknya.

Dengan demikian, prinsip perlu-tahu dilanggar. Kita harus memungkinkan isi dari suatu domain dapat
diubah sehingga domain selalu mencerminkan hak akses yang minimal yang diperlukan.

Jika asosiasi bersifat dinamis, mekanisme tersedia untuk mengizinkan perpindahan domain, yang
memungkinkan proses untuk beralih dari satu domain ke domain lainnya. Kita juga mungkin ingin
mengizinkan perubahan konten domain. Jika kita tidak dapat mengubah konten domain, kita dapat
memberikan efek yang sama dengan membuat domain baru dengan konten yang berubah dan
beralih ke domain baru tersebut ketika kita ingin mengubah konten domain.
Sebuah domain dapat diwujudkan dalam berbagai cara:

• Setiap pengguna dapat menjadi sebuah domain. Dalam hal ini, himpunan objek yang dapat diakses
bergantung pada identitas pengguna. Perpindahan domain terjadi ketika pengguna berubah -
umumnya ketika satu pengguna keluar dan pengguna lain masuk.

• Setiap proses dapat menjadi sebuah domain. Dalam hal ini, himpunan objek yang dapat diakses
bergantung pada identitas proses. Perpindahan domain terjadi ketika satu proses mengirim pesan ke
proses lain dan kemudian menunggu respons.

• Setiap prosedur dapat menjadi sebuah domain. Dalam hal ini, himpunan objek yang dapat diakses
sesuai dengan variabel lokal yang didefinisikan dalam prosedur tersebut. Perpindahan domain terjadi
ketika pemanggilan prosedur dilakukan.

Kami akan membahas perpindahan domain dengan lebih rinci dalam Bagian 14.4.

Pertimbangkan model dual-mode standar (mode monitor-mode pengguna) dalam eksekusi sistem
operasi. Ketika suatu proses dieksekusi dalam mode monitor, ia dapat menjalankan instruksi yang
memiliki hak istimewa dan dengan demikian mendapatkan kendali penuh atas sistem komputer.
Sebaliknya, ketika suatu proses dieksekusi dalam mode pengguna, ia hanya dapat memanggil
instruksi yang tidak memiliki hak istimewa. Akibatnya, ia hanya dapat mengeksekusi dalam ruang
memori yang telah ditentukan sebelumnya. Dua mode ini melindungi sistem operasi (yang dieksekusi
dalam domain monitor) dari proses pengguna (yang dieksekusi dalam domain pengguna). Dalam
sistem operasi multiprogram, dua domain perlindungan tidak cukup, karena pengguna juga ingin
dilindungi dari satu sama lain. Oleh karena itu, diperlukan skema yang lebih rumit. Kami
mengilustrasikan skema tersebut dengan memeriksa dua sistem operasi berpengaruh - UNIX dan
MULTICS - untuk melihat bagaimana mereka mengimplementasikan konsep-konsep ini.

14.3.2 Contoh: UNIX

Dalam sistem operasi UNIX, domain terkait dengan pengguna. Menukar

domain sesuai dengan mengubah identifikasi pengguna secara sementara.

Perubahan ini dilakukan melalui sistem berkas sebagai berikut. Identifikasi pemilik

dan bit domain (dikenal sebagai bit setuid) terkait dengan

setiap berkas. Ketika bit setuid aktif, dan seorang pengguna menjalankan berkas tersebut, userID
akan

diatur menjadi milik pemilik berkas tersebut. Namun, ketika bit dimatikan, userID

tidak berubah. Misalnya, ketika seorang pengguna A (yaitu, seorang pengguna dengan userID =

A) mulai menjalankan berkas yang dimiliki oleh B, yang bit domain terkaitnya dimatikan, userID dari
proses tersebut diatur menjadi A. Ketika bit setuid aktif, userID diatur menjadi milik pemilik berkas:
B. Ketika proses tersebut selesai, perubahan userID sementara ini berakhir.

Metode lain digunakan untuk mengubah domain di sistem operasi di mana

userID digunakan untuk mendefinisikan domain, karena hampir semua sistem memerlukan
untuk menyediakan mekanisme tersebut. Mekanisme ini digunakan ketika fasilitas yang seharusnya

berhak membutuhkan untuk dibuat tersedia bagi populasi pengguna umum.

Misalnya, mungkin diinginkan untuk memungkinkan pengguna mengakses jaringan tanpa

mengizinkan mereka menulis program jaringan mereka sendiri. Dalam kasus seperti itu, pada sistem
UNIX, bit setuid pada program jaringan akan diatur, menyebabkan

userID berubah ketika program dijalankan. UserID akan berubah menjadi

milik pengguna dengan hak akses jaringan (seperti root, userID yang paling kuat).

Satu masalah dengan metode ini adalah jika seorang pengguna berhasil membuat berkas

dengan userID root dan dengan bit setuid aktif, pengguna tersebut dapat menjadi root dan

melakukan apa saja di sistem. Mekanisme setuid dibahas

lebih lanjut di Lampiran A.

Alternatif dari metode ini yang digunakan dalam beberapa sistem operasi lain adalah

menempatkan program berhak istimewa dalam direktori khusus. Sistem operasi ini

dirancang untuk mengubah userID dari setiap program yang dijalankan dari direktori ini, baik

menjadi setara dengan root atau menjadi userID pemilik direktori tersebut. Hal ini

menghilangkan satu masalah keamanan, yang terjadi ketika penyusup membuat program

untuk memanipulasi fitur setuid dan menyembunyikan program-program tersebut di sistem untuk
digunakan nanti

(menggunakan nama berkas atau direktori yang tidak jelas). Namun, metode ini kurang fleksibel
daripada

yang digunakan dalam UNIX.

Lebih pembatasan, dan dengan demikian lebih protektif, adalah sistem yang sederhana

tidak memperbolehkan perubahan userID. Dalam kasus seperti ini, teknik khusus harus

digunakan untuk memungkinkan pengguna mengakses fasilitas yang berhak. Misalnya, proses demon

dapat dimulai saat boot dan dijalankan sebagai userID khusus. Pengguna kemudian

menjalankan program terpisah, yang mengirim permintaan kepada proses ini kapan saja mereka

perlu menggunakan fasilitas tersebut. Metode ini digunakan oleh sistem operasi TOPS-20.

Dalam semua sistem ini, harus dilakukan dengan hati-hati dalam menulis program berhak istimewa.

Setiap kelalaian dapat mengakibatkan kurangnya perlindungan total di sistem.

Secara umum, program-program ini adalah yang pertama diserang oleh orang yang mencoba

meretas sistem. Sayangnya, serangan tersebut sering berhasil.

Sebagai contoh, keamanan telah dilanggar di banyak sistem UNIX karena fitur setuid. Kami akan
membahas keamanan dalam Bab 15.

14.3.3 Contoh: MULTICS

Dalam sistem MULTICS, domain perlindungan diorganisir secara hierarkis

ke dalam struktur cincin. Setiap cincin sesuai dengan satu domain (Gambar 14.2).

Cincin-cincin tersebut diberi nomor dari 0 hingga 7. Biarkan Di dan Dj menjadi dua cincin domain apa
pun.

Jika j < i, maka Di adalah sub himpunan dari Dj . Artinya, suatu proses yang dieksekusi di dalam
domain Dj

memiliki lebih banyak hak istimewa daripada suatu proses yang dieksekusi di dalam domain Di .
Suatu proses

yang dieksekusi di dalam domain D0 memiliki hak istimewa paling banyak. Jika hanya ada dua cincin,
skema ini setara dengan mode pemantauan-pengguna dalam pelaksanaan, di mana mode
pemantauan

sesuai dengan D0 dan mode pengguna sesuai dengan D1.

MULTICS memiliki ruang alamat yang tersegmentasi; setiap segmen adalah berkas, dan setiap

segmen terkait dengan salah satu cincin. Deskripsi segmen mencakup

entri yang mengidentifikasi nomor cincin. Selain itu, itu mencakup tiga bit akses untuk mengontrol
pembacaan, penulisan, dan eksekusi. Hubungan antara segmen-segmen

dan cincin-cincin adalah keputusan kebijakan yang tidak menjadi perhatian kami di sini.

Sebuah penghitung nomor cincin saat ini terkait dengan setiap proses, mengidentifikasi cincin di
mana proses sedang dieksekusi saat ini. Ketika suatu proses sedang

dieksekusi di dalam cincin i, ia tidak dapat mengakses segmen yang terkait dengan cincin j (j < i).
Namun, ia

dapat mengakses segmen yang terkait dengan cincin k (k ≥ i). Namun, jenis aksesnya

dibatasi sesuai dengan bit akses yang terkait dengan segmen tersebut.

Peralihan domain dalam MULTICS terjadi ketika suatu proses berpindah dari satu cincin

ke cincin lain dengan memanggil suatu prosedur di dalam cincin yang berbeda. Jelas, peralihan ini
harus

dilakukan dengan terkendali; jika tidak, suatu proses dapat mulai dieksekusi di dalam

cincin 0, dan tidak akan ada perlindungan yang diberikan. Untuk mengizinkan peralihan domain yang
terkendali, kita memodifikasi bidang cincin dari deskripsi segmen untuk mencakup hal berikut:

• Tanda akses. Pasangan bilangan bulat, b1 dan b2, sehingga b1 ≤ b2.

• Batas. Sebuah bilangan bulat b3 sehingga b3 > b2.

• Daftar gerbang. Mengidentifikasi titik masuk (atau gerbang) di mana segmen-segmen

dapat dipanggil.

Jika suatu proses yang dieksekusi di dalam cincin i memanggil suatu prosedur (atau segmen) dengan
tanda akses

(b1, b2), maka panggilan tersebut diizinkan jika b1 ≤ i ≤ b2, dan nomor cincin saat ini dari

proses tetap i. Jika tidak, terjadi perangkap ke sistem operasi, dan

situasinya ditangani sebagai berikut:

• Jika i < b1, maka panggilan tersebut diizinkan untuk terjadi, karena terjadi perpindahan ke cincin
(atau domain) dengan hak istimewa yang lebih sedikit. Namun, jika parameter yang dilewatkan

yang merujuk ke segmen di cincin yang lebih rendah (yaitu, segmen yang tidak dapat diakses oleh

prosedur yang dipanggil), maka segmen-segmen ini harus disalin ke area

yang dapat diakses oleh prosedur yang dipanggil.

• Jika i > b2, maka panggilan tersebut diizinkan untuk terjadi hanya jika b3 lebih besar atau sama

dengan i dan panggilan telah diarahkan ke salah satu titik masuk yang ditentukan dalam daftar
gerbang. Skema ini memungkinkan proses dengan hak akses terbatas untuk

memanggil prosedur di dalam cincin yang lebih rendah yang memiliki hak akses lebih besar, tetapi
hanya dengan

dalam pengendalian yang hati-hati.

Kelemahan utama dari struktur cincin (atau hierarkis) adalah bahwa ini

tidak memungkinkan kita untuk menegakkan prinsip perlu untuk tahu (need-to-know). Khususnya,
jika suatu objek

harus dapat diakses di dalam domain Dj tetapi tidak dapat diakses di dalam domain Di , maka kita
harus

memiliki j < i. Tetapi persyaratan ini berarti bahwa setiap segmen yang dapat diakses di Di juga dapat
diakses di Dj .

Sistem perlindungan MULTICS secara umum lebih kompleks dan kurang efisien

daripada yang digunakan dalam sistem operasi saat ini. Jika perlindungan mengganggu

kemudahan penggunaan sistem atau signifikan mengurangi kinerja sistem,

maka penggunaannya harus dipertimbangkan dengan hati-hati sesuai dengan tujuan sistem tersebut.
Misalnya, kita ingin memiliki sistem perlindungan yang kompleks pada komputer
yang digunakan oleh sebuah universitas untuk memproses nilai mahasiswa dan juga digunakan oleh
mahasiswa untuk tugas-tugas kuliah. Sistem perlindungan serupa tidak cocok untuk komputer yang
digunakan untuk penghitungan besar, di mana kinerja adalah yang paling penting. Kita

lebih suka untuk memisahkan mekanisme dari kebijakan perlindungan, memungkinkan

sistem yang sama memiliki perlindungan yang kompleks atau sederhana tergantung pada kebutuhan

penggunanya. Untuk memisahkan mekanisme dari kebijakan, kita memerlukan model perlindungan
yang lebih umum.

14.4 Matriks Akses

Model perlindungan umum kami dapat dilihat secara abstrak sebagai matriks, yang disebut

matriks akses. Baris-baris matriks akses mewakili domain, dan

kolom-kolom mewakili objek. Setiap entri dalam matriks terdiri dari seperangkat hak akses. Karena
kolom mendefinisikan objek secara eksplisit, kita dapat menghilangkan nama objek dari hak akses.
Entri akses(i,j) mendefinisikan seperangkat operasi

yang dapat dilakukan oleh suatu proses yang berjalan di dalam domain Di pada objek Oj.

Untuk mengilustrasikan konsep-konsep ini, kita pertimbangkan matriks akses yang ditunjukkan dalam
Gambar

14.3. Ada empat domain dan empat objek—tiga berkas (F1, F2, F3) dan satu

printer laser. Proses yang berjalan di dalam domain D1 dapat membaca berkas F1 dan F3. Proses
yang berjalan di dalam domain D4 memiliki hak istimewa yang sama dengan proses yang berjalan di
dalam domain D1; namun, tambahan haknya adalah menulis ke berkas F1 dan F3. Printer laser hanya
dapat diakses oleh proses yang berjalan di dalam domain D2.

Skema matriks akses memberikan kami mekanisme untuk menentukan

berbagai kebijakan. Mekanisme ini melibatkan pelaksanaan matriks akses

dan memastikan bahwa properti semantik yang telah kami jelaskan terpenuhi.

Secara lebih spesifik, kami harus memastikan bahwa proses yang berjalan di dalam domain Di hanya
dapat

mengakses objek-objek yang ditentukan di baris i, dan itu hanya diizinkan oleh

entri matriks akses.

Matriks akses dapat mengimplementasikan keputusan kebijakan tentang perlindungan.

Keputusan kebijakan melibatkan hak mana yang harus dimasukkan dalam entri (i, j).
Kita juga harus memutuskan dalam domain mana setiap proses berjalan. Kebijakan terakhir ini
biasanya ditentukan oleh sistem operasi.

Biasanya pengguna yang menentukan isi entri matriks akses. Ketika

seorang pengguna membuat objek baru Oj , kolom Oj ditambahkan ke dalam matriks akses

dengan entri-inisialisasi yang sesuai, sesuai dengan keinginan pembuatnya. Pengguna

dapat memutuskan untuk memasukkan beberapa hak dalam beberapa entri di kolom j dan hak lain

di entri lain, sesuai kebutuhan.

Matriks akses menyediakan mekanisme yang sesuai untuk mendefinisikan dan

mengimplementasikan pengendalian ketat baik untuk asosiasi statis maupun dinamis antara

proses dan domain. Ketika kita beralih dari satu domain ke domain lain, kita sedang menjalankan
operasi (bantuan) pada suatu objek (domain). Kita dapat

mengendalikan perpindahan domain dengan memasukkan domain dalam objek-objek dari

matriks akses. Demikian pula, ketika kita mengubah konten matriks akses,

kita sedang melakukan operasi pada objek: matriks akses itu sendiri. Sekali lagi, kita

dapat mengendalikan perubahan-perubahan ini dengan memasukkan matriks akses itu sendiri
sebagai objek.

Sebenarnya, karena setiap entri dalam matriks akses dapat diubah secara individual,

kita harus mempertimbangkan setiap entri dalam matriks akses sebagai objek yang harus dilindungi.

Sekarang, kita perlu mempertimbangkan hanya operasi-operasi yang mungkin dilakukan pada objek-
objek baru ini

(domain dan matriks akses) dan memutuskan bagaimana kita ingin agar proses dapat

melakukan operasi-operasi ini.

Proses harus dapat beralih dari satu domain ke domain lain. Beralih

dari domain Di ke domain Dj diperbolehkan jika dan hanya jika hak akses beralih

∈ akses(i, j). Dengan demikian, dalam Gambar 14.4, proses yang berjalan di dalam domain D2 dapat
beralih ke domain D3 atau ke domain D4. Proses di dalam domain D4 dapat beralih ke D1, dan

yang di dalam domain D1 dapat beralih ke D2.

Memungkinkan perubahan yang dikendalikan dalam isi entri matriks akses

memerlukan tiga operasi tambahan: salin, pemilik, dan kontrol. Kami akan memeriksa

operasi-operasi ini selanjutnya.

Kemampuan untuk menyalin hak akses dari satu domain (atau baris) matriks akses

ke domain lain ditandai dengan tanda asterisk (*) yang ditambahkan pada hak akses.

Hak salin memungkinkan hak akses untuk disalin hanya dalam kolom

(yaitu, untuk objek) di mana hak tersebut didefinisikan. Sebagai contoh, dalam Gambar

14.5(a), proses yang berjalan di dalam domain D2 dapat menyalin operasi baca ke dalam entri
manapun

yang terkait dengan berkas F2. Oleh karena itu, matriks akses pada Gambar 14.5(a) dapat diubah
menjadi matriks akses yang ditunjukkan dalam Gambar 14.5(b).

Skema ini memiliki dua variasi tambahan:

1. Hak disalin dari akses(i, j) ke akses(k, j); kemudian dihapus dari

akses(i, j). Tindakan ini merupakan pengalihan hak, bukan salinan.

2. Penyebaran hak salinan dapat dibatasi. Artinya, ketika hak R∗ disalin dari akses(i, j) ke akses(k, j),
hanya hak R (bukan R∗)

yang diciptakan. Proses yang berjalan di dalam domain Dk tidak dapat lagi menyalin hak R.

Sebuah sistem dapat memilih salah satu dari tiga hak salinan ini, atau dapat menyediakan

ketiganya dengan mengidentifikasinya sebagai hak terpisah: salin, transfer, dan salinan terbatas.

Kita juga memerlukan mekanisme untuk mengizinkan penambahan hak baru dan penghapusan

beberapa hak. Hak pemilik mengendalikan operasi-operasi ini. Jika akses(i, j) mencakup

hak pemilik, maka proses yang berjalan di dalam domain Di dapat menambahkan dan menghapus
hak apa pun dalam setiap entri dalam kolom j. Sebagai contoh, dalam Gambar 14.6(a), domain D1

adalah pemilik F1 dan oleh karena itu dapat menambahkan dan menghapus hak yang valid dalam
kolom F1.

Demikian pula, domain D2 adalah pemilik F2 dan F3 dan oleh karena itu dapat menambahkan dan
menghapus hak yang valid dalam kedua kolom ini. Dengan demikian, matriks akses pada Gambar
14.6(a) dapat diubah menjadi matriks akses yang ditunjukkan dalam Gambar 14.6(b).

Hak salin dan hak pemilik memungkinkan suatu proses untuk mengubah entri-entri dalam suatu

kolom. Kita juga memerlukan mekanisme untuk mengubah entri-entri dalam suatu baris. Hak kontrol
hanya berlaku untuk objek domain.

Jika akses(i, j) mencakup hak kontrol, maka proses yang berjalan di dalam domain Di dapat
menghapus hak akses apa pun dari baris j. Sebagai contoh, misalkan dalam Gambar 14.4, kita
sertakan hak kontrol dalam akses(D2, D4). Kemudian, proses yang berjalan di dalam domain D2
dapat mengubah domain D4, seperti yang ditunjukkan dalam Gambar 14.7.

Hak salin dan hak pemilik memberikan kami mekanisme untuk membatasi penyebaran hak akses.
Namun, mereka tidak memberi kami alat yang sesuai

untuk mencegah penyebaran (atau pengungkapan) informasi. Masalahnya adalah

menjamin bahwa tidak ada informasi yang awalnya ada dalam suatu objek dapat bermigrasi ke luar

lingkungan eksekusinya disebut sebagai masalah isolasi (confinement). Masalah ini

secara umum tidak dapat diselesaikan (lihat catatan bibliografi di akhir bab).

Operasi-operasi pada domain dan matriks akses ini bukanlah hal yang penting, tetapi mereka
mengilustrasikan kemampuan model matriks akses untuk

mengizinkan kami mengimplementasikan dan mengendalikan kebutuhan perlindungan dinamis.

Objek-objek baru dan domain baru dapat dibuat secara dinamis dan dimasukkan dalam model
matriks akses. Namun, kami hanya menunjukkan bahwa mekanisme dasarnya

ada. Para perancang sistem dan pengguna harus membuat keputusan kebijakan mengenai

domain mana yang akan memiliki akses ke objek mana dengan cara apa.

14.5 Implementasi Matriks Akses

Bagaimana matriks akses dapat diimplementasikan secara efektif? Secara umum, matriks ini

akan bersifat sparse; artinya, sebagian besar entri akan kosong. Meskipun teknik struktur data

tersedia untuk merepresentasikan matriks yang sparse, mereka tidak terlalu berguna untuk aplikasi
ini,

karena cara fasilitas perlindungan digunakan. Di sini, pertama-tama kami akan menjelaskan beberapa
metode

implementasi matriks akses dan kemudian membandingkan metode-metode tersebut.

14.5.1 Tabel Global

Implementasi paling sederhana dari matriks akses adalah tabel global yang terdiri

dari sejumlah triplet terurut <domain, objek, hak-set>. Setiap kali operasi M dijalankan pada objek Oj
dalam domain Di, tabel global

dicari untuk triplet <Di, Oj, Rk>, dengan M ∈ Rk. Jika triplet ini ditemukan, operasi tersebut

diperbolehkan untuk dilanjutkan; jika tidak, kondisi pengecualian (atau kesalahan) akan muncul.

Implementasi ini memiliki beberapa kelemahan. Tabelnya biasanya

besar dan oleh karena itu tidak dapat ditempatkan dalam memori utama, sehingga memerlukan I/O
tambahan.
Teknik memori virtual sering digunakan untuk mengelola tabel ini. Selain itu, sulit untuk
memanfaatkan

pengelompokan khusus objek atau domain. Sebagai contoh, jika semua orang dapat membaca suatu
objek tertentu, objek ini harus memiliki

entri terpisah dalam setiap domain.

14.5.2 Daftar Akses untuk Objek

Setiap kolom dalam matriks akses dapat diimplementasikan sebagai daftar akses untuk

satu objek, seperti yang dijelaskan dalam Bagian 11.6.2. Tentu saja, entri-entri yang kosong dapat

dibuang. Daftar yang dihasilkan untuk setiap objek terdiri dari pasangan terurut <domain,

hak-set>, yang mendefinisikan semua domain dengan set hak akses yang tidak kosong

untuk objek tersebut.

Pendekatan ini dapat dengan mudah diperluas untuk mendefinisikan daftar ditambah

kumpulan hak akses default. Ketika operasi M pada objek Oj dicoba dalam domain Di, kita mencari
daftar akses untuk objek Oj, mencari entri <Di, Rk> dengan

M ∈ Rk. Jika entri tersebut ditemukan, kita mengizinkan operasi; jika tidak, kita periksa

set default. Jika M ada dalam set default, kita mengizinkan akses. Jika tidak, akses

ditolak, dan kondisi pengecualian terjadi. Untuk efisiensi, kita mungkin memeriksa

set default terlebih dahulu dan kemudian mencari daftar akses.

14.5.3 Daftar Kemampuan untuk Domain

Daripada mengaitkan kolom matriks akses dengan objek sebagai daftar akses, kita dapat mengaitkan
setiap baris dengan domainnya. Daftar kemampuan untuk

suatu domain adalah daftar objek beserta operasi yang diizinkan pada objek-objek tersebut. Objek
sering kali direpresentasikan dengan nama fisik atau alamatnya, yang disebut sebagai kemampuan.
Untuk menjalankan operasi M pada objek Oj, proses menjalankan

operasi M, dengan menentukan kemampuan (atau penunjuk) untuk objek Oj sebagai parameter.
Hanya dengan memiliki kemampuan, akses diperbolehkan.

Daftar kemampuan terkait dengan suatu domain, tetapi tidak pernah dapat diakses langsung oleh
proses yang berjalan dalam domain tersebut. Sebaliknya, daftar kemampuan itu sendiri adalah objek
yang dilindungi, yang dikelola oleh sistem operasi dan diakses oleh pengguna hanya secara tidak
langsung. Perlindungan berbasis kemampuan bergantung pada kenyataan bahwa kemampuan tidak
pernah diperbolehkan bermigrasi ke dalam ruang alamat yang dapat diakses langsung oleh proses
pengguna (di mana mereka dapat dimodifikasi). Jika semua kemampuan aman, objek yang mereka
lindungi juga aman dari akses yang tidak sah.

Kemampuan awalnya diusulkan sebagai jenis penunjuk yang aman, untuk memenuhi kebutuhan
perlindungan sumber daya yang diprediksi akan muncul ketika sistem komputer multiprogram mulai
berkembang. Ide tentang penunjuk yang secara alamiah dilindungi menyediakan dasar perlindungan
yang dapat diperluas hingga ke tingkat aplikasi.

Untuk memberikan perlindungan yang alamiah, kita harus membedakan kemampuan dari jenis objek
lainnya, dan mereka harus diinterpretasikan oleh mesin abstrak di mana program tingkat lebih tinggi
berjalan. Kemampuan biasanya dibedakan dari data lain dengan salah satu dari dua cara:

• Setiap objek memiliki tag untuk menunjukkan apakah itu adalah kemampuan atau data yang dapat
diakses. Tag-tag tersebut sendiri tidak boleh dapat diakses langsung oleh program aplikasi. Dukungan
perangkat keras atau firmware dapat digunakan untuk menegakkan pembatasan ini. Meskipun hanya
satu bit yang diperlukan untuk membedakan kemampuan dan objek lain, seringkali digunakan lebih
banyak bit. Perluasan ini memungkinkan semua objek ditandai dengan jenisnya oleh perangkat keras.
Dengan demikian, perangkat keras dapat membedakan bilangan bulat, bilangan pecahan, penunjuk,
Booleans, karakter, instruksi, kemampuan, dan nilai yang belum diinisialisasi berdasarkan tag mereka.

• Sebagai alternatif, ruang alamat yang terkait dengan program dapat dibagi menjadi dua bagian.
Salah satu bagian dapat diakses oleh program dan berisi data dan instruksi normal program. Bagian
lainnya, yang berisi daftar kemampuan, hanya dapat diakses oleh sistem operasi. Ruang alamat yang
tersegmentasi (Bagian 8.4) berguna untuk mendukung pendekatan ini.

Beberapa sistem perlindungan berbasis kemampuan telah dikembangkan; kami akan menjelaskannya
secara singkat dalam Bagian 14.8. Sistem operasi Mach juga menggunakan versi perlindungan
berbasis kemampuan; ini dijelaskan dalam Lampiran B.

14.5.4 Mekanisme Kunci-Gembok

Skema kunci-gembok adalah kompromi antara daftar akses dan daftar kemampuan. Setiap objek
memiliki daftar pola bit unik, disebut sebagai kunci gembok. Demikian pula, setiap domain memiliki
daftar pola bit unik, disebut sebagai kunci. Sebuah proses yang berjalan dalam suatu domain hanya
dapat mengakses suatu objek jika domain tersebut memiliki sebuah kunci yang cocok dengan salah
satu kunci gembok objek.

Seperti halnya dengan daftar kemampuan, daftar kunci untuk suatu domain harus dikelola oleh
sistem operasi atas nama domain tersebut. Pengguna tidak diizinkan untuk memeriksa atau
mengubah daftar kunci (atau kunci gembok) secara langsung.

14.5.5 Perbandingan
Seperti yang dapat diharapkan, memilih teknik untuk mengimplementasikan matriks akses
melibatkan berbagai pertimbangan. Menggunakan tabel global sederhana; namun, tabel tersebut
bisa cukup besar dan seringkali tidak dapat memanfaatkan pengelompokan khusus objek atau
domain. Daftar akses sesuai langsung dengan kebutuhan pengguna. Ketika seorang pengguna
membuat sebuah objek, dia dapat menentukan domain mana yang dapat mengakses objek, serta
operasi apa yang diizinkan. Namun, karena informasi hak akses untuk suatu domain tertentu tidak
terlokalisasi, menentukan kumpulan hak akses untuk setiap domain sulit. Selain itu, setiap akses ke
objek harus diperiksa, memerlukan pencarian dalam daftar akses. Dalam sistem besar dengan daftar
akses yang panjang, pencarian ini dapat memakan waktu.

Daftar kemampuan tidak sesuai langsung dengan kebutuhan pengguna, tetapi bermanfaat untuk
melokalisasi informasi untuk proses tertentu. Proses yang mencoba mengakses harus menyajikan
kemampuan untuk akses tersebut. Kemudian, sistem perlindungan hanya perlu memverifikasi bahwa
kemampuan tersebut sah. Pencabutan kemampuan, bagaimanapun, mungkin tidak efisien (Bagian
14.7).

Mekanisme kunci-gembok, seperti yang disebutkan, adalah suatu kompromi antara daftar akses dan
daftar kemampuan. Mekanisme ini dapat efektif dan fleksibel, tergantung pada panjang kunci-kunci
tersebut. Kunci-kunci tersebut dapat berpindah bebas dari domain ke domain. Selain itu, hak akses
dapat dicabut dengan efektif dengan teknik sederhana yaitu dengan mengubah beberapa kunci
gembok yang terkait dengan objek (Bagian 14.7).

Sebagian besar sistem menggunakan kombinasi dari daftar akses dan kemampuan. Ketika suatu
proses pertama kali mencoba mengakses suatu objek, daftar akses akan dicari. Jika akses ditolak,
maka akan terjadi kondisi pengecualian. Sebaliknya, sebuah kemampuan akan dibuat dan
dilampirkan pada proses tersebut. Referensi tambahan menggunakan kemampuan untuk dengan
cepat menunjukkan bahwa akses diizinkan. Setelah akses terakhir, kemampuan tersebut
dihancurkan. Strategi ini digunakan dalam sistem MULTICS dan dalam sistem CAL.

Sebagai contoh tentang bagaimana strategi semacam itu bekerja, pertimbangkan suatu sistem berkas
di mana setiap berkas memiliki daftar akses yang terkait. Ketika suatu proses membuka suatu berkas,
struktur direktori dicari untuk menemukan berkas tersebut, izin akses diperiksa, dan buffer
dialokasikan. Semua informasi ini dicatat dalam entri baru dalam tabel berkas yang terkait dengan
proses. Operasi ini mengembalikan indeks ke dalam tabel ini untuk berkas yang baru dibuka. Semua
operasi pada berkas dilakukan dengan menspesifikasikan indeks ke dalam tabel berkas. Entri dalam
tabel berkas kemudian menunjuk ke berkas dan buffer-buffernya. Ketika berkas ditutup, entri tabel
berkas dihapus. Karena tabel berkas dikelola oleh sistem operasi, pengguna tidak dapat dengan tidak
sengaja merusaknya. Dengan demikian, pengguna hanya dapat mengakses berkas yang telah dibuka.

Karena akses diperiksa ketika berkas dibuka, perlindungan terjamin. Strategi ini digunakan dalam
sistem UNIX.

Hak akses masih harus diperiksa pada setiap akses, dan entri tabel berkas memiliki kemampuan
hanya untuk operasi yang diizinkan. Jika sebuah berkas dibuka untuk dibaca, maka kemampuan
untuk akses baca ditempatkan dalam entri tabel berkas. Jika ada upaya untuk menulis ke berkas,
sistem mengidentifikasi pelanggaran perlindungan ini dengan membandingkan operasi yang diminta
dengan kemampuan dalam entri tabel berkas.

14.6 Kontrol Akses

Pada Bagian 11.6.2, kami menjelaskan bagaimana kontrol akses dapat digunakan pada berkas dalam
sistem berkas. Setiap berkas dan direktori diberi pemilik, kelompok, atau mungkin daftar pengguna,
dan untuk masing-masing entitas tersebut, informasi kontrol akses ditetapkan. Fungsi serupa dapat
ditambahkan ke aspek-aspek lain dari sistem komputer. Contoh bagusnya terdapat dalam Solaris 10.

Solaris 10 meningkatkan perlindungan yang tersedia dalam sistem operasi dengan secara eksplisit
menambahkan prinsip hak akses berbasis peran (RBAC). Fasilitas ini berkaitan dengan hak istimewa.
Hak istimewa adalah hak untuk menjalankan pemanggilan sistem atau untuk menggunakan opsi
dalam pemanggilan sistem tersebut (seperti membuka berkas dengan akses tulis). Hak istimewa
dapat diberikan kepada proses, membatasi mereka hanya untuk akses yang diperlukan untuk
melakukan pekerjaan mereka. Hak istimewa dan program juga dapat diberikan kepada peran.
Pengguna diberikan peran atau dapat mengambil peran berdasarkan kata sandi peran. Dengan cara
ini, seorang pengguna dapat mengambil peran yang mengaktifkan hak istimewa, memungkinkan
pengguna untuk menjalankan program untuk menyelesaikan tugas tertentu, seperti yang
digambarkan dalam Gambar 14.8. Implementasi hak istimewa ini mengurangi risiko keamanan yang
terkait dengan superuser dan program setuid.

Perhatikan bahwa fasilitas ini mirip dengan matriks akses yang dijelaskan dalam Bagian 14.4.
Hubungan ini lebih jauh dieksplorasi dalam latihan di akhir bab.

Dalam sistem perlindungan dinamis, terkadang kita perlu mencabut hak akses ke objek yang
dibagikan oleh berbagai pengguna. Berbagai pertanyaan tentang pencabutan hak akses dapat
muncul:

- Langsung versus tertunda. Apakah pencabutan terjadi secara langsung atau tertunda? Jika
pencabutan tertunda, bisakah kita mengetahui kapan hal tersebut akan terjadi?

- Selektif versus umum. Ketika hak akses ke objek dicabut, apakah ini memengaruhi semua pengguna
yang memiliki hak akses ke objek tersebut, atau bisakah kita menentukan kelompok pengguna
tertentu yang hak aksesnya harus dicabut?

- Sebagian versus keseluruhan. Bisakah sebagian dari hak yang terkait dengan objek dicabut, atau
kita harus mencabut semua hak akses untuk objek ini?

- Sementara versus permanen. Bisakah akses dicabut secara permanen (artinya hak akses yang
dicabut tidak akan pernah lagi tersedia), atau bisakah akses dicabut dan kemudian diperoleh
kembali?
Dalam skema daftar akses, pencabutan mudah dilakukan. Daftar akses dicari untuk hak akses yang
akan dicabut, dan mereka dihapus dari daftar. Pencabutan bersifat langsung dan dapat bersifat
umum atau selektif, total atau sebagian, dan permanen atau sementara.

Namun, kemampuan (capabilities) mempresentasikan masalah pencabutan yang jauh lebih sulit,
seperti yang disebutkan sebelumnya. Karena kemampuan tersebar di seluruh sistem, kita harus
menemukannya sebelum kita bisa mencabutnya. Skema yang mengimplementasikan pencabutan
untuk kemampuan meliputi berikut ini:

- Reakuisisi. Secara berkala, kemampuan dihapus dari setiap domain. Jika suatu proses ingin
menggunakan kemampuan, mungkin ia menemukan bahwa kemampuan tersebut telah dihapus.
Proses tersebut kemudian dapat mencoba untuk merebut kemampuan tersebut. Jika akses telah
dicabut, proses tidak akan bisa merebut kemampuan tersebut.

- Penunjuk mundur. Daftar penunjuk dijaga bersama setiap objek, menunjuk pada semua
kemampuan yang terkait dengan objek tersebut. Ketika pencabutan diperlukan, kita dapat mengikuti
penunjuk ini, mengubah kemampuan sesuai kebutuhan. Skema ini diadopsi dalam sistem MULTICS.
Ini sangat umum, tetapi implementasinya mahal.

- Indireksi. Kemampuan menunjuk secara tidak langsung, bukan langsung, ke objek. Setiap
kemampuan menunjuk ke entri unik dalam tabel global, yang pada gilirannya menunjuk ke objek.
Kami mengimplementasikan pencabutan dengan mencari entri global yang diinginkan dan
menghapusnya. Kemudian, saat sebuah akses diusahakan, kemampuan ditemukan menunjuk ke entri
tabel ilegal. Entri tabel dapat digunakan kembali untuk kemampuan lain tanpa kesulitan, karena baik
kemampuan maupun entri tabel berisi nama unik objek tersebut. Objek untuk kemampuan dan entri
tabelnya harus cocok. Skema ini diadopsi dalam sistem CAL. Ini tidak memungkinkan pencabutan
yang selektif.

- Kunci. Sebuah kunci adalah pola bit unik yang dapat terkait dengan sebuah kemampuan. Kunci ini
didefinisikan saat kemampuan dibuat, dan tidak dapat dimodifikasi atau diperiksa oleh proses yang
memiliki kemampuan. Sebuah kunci master terkait dengan setiap objek; dapat didefinisikan atau
diganti dengan operasi set-key. Ketika kemampuan dibuat, nilai saat ini dari kunci master terkait
dengan kemampuan. Saat kemampuan digunakan, kuncinya dibandingkan dengan kunci master. Jika
kunci cocok, operasi diizinkan untuk dilanjutkan; jika tidak, kondisi pengecualian dibuat. Pencabutan
menggantikan kunci master dengan nilai baru melalui operasi set-key, yang membuat semua
kemampuan sebelumnya untuk objek ini tidak berlaku. Skema ini tidak memungkinkan pencabutan
yang selektif, karena hanya satu kunci master yang terkait dengan setiap objek. Jika kita mengaitkan
daftar kunci dengan setiap objek, maka pencabutan yang selektif dapat diimplementasikan. Akhirnya,
kita dapat mengelompokkan semua kunci ke dalam satu tabel global kunci. Sebuah kemampuan valid
hanya jika kuncinya cocok dengan beberapa kunci di tabel global. Kami mengimplementasikan
pencabutan dengan menghapus kunci yang cocok dari tabel. Dengan skema ini, sebuah kunci dapat
dihubungkan dengan beberapa objek, dan beberapa kunci dapat dihubungkan dengan setiap objek,
memberikan fleksibilitas maksimum.

Dalam skema berbasis kunci, operasi-definisi kunci, menyisipkannya ke dalam daftar, dan
menghapusnya dari daftar seharusnya tidak tersedia untuk semua pengguna. Terutama, masuk akal
untuk hanya membiarkan pemilik suatu objek mengatur kunci-kunci untuk objek tersebut. Namun,
pilihan ini adalah keputusan kebijakan yang sistem perlindungan dapat mengimplementasikan tetapi
seharusnya tidak mendefinisikan.

Pada bagian ini, kami mengulas dua sistem perlindungan berbasis kemampuan. Sistem-sistem ini
berbeda dalam kompleksitas mereka dan dalam jenis kebijakan yang dapat diimplementasikan pada
mereka. Tidak ada satu pun sistem ini banyak digunakan, tetapi keduanya menyediakan lingkungan
pengujian yang menarik untuk teori perlindungan.

14.8.1 Contoh: Hydra

Hydra adalah sistem perlindungan berbasis kemampuan yang memberikan fleksibilitas yang
signifikan. Sistem ini mengimplementasikan seperangkat hak akses yang mungkin, termasuk bentuk
dasar akses seperti hak untuk membaca, menulis, atau menjalankan segmen memori. Selain itu,
pengguna (sistem perlindungan) dapat mendeklarasikan hak akses lain. Interpretasi hak akses yang
didefinisikan oleh pengguna dilakukan semata-mata oleh program pengguna, tetapi sistem
memberikan perlindungan akses untuk penggunaan hak-hak ini, serta untuk penggunaan hak-hak
yang didefinisikan oleh sistem. Fasilitas ini merupakan perkembangan signifikan dalam teknologi
perlindungan.

Operasi pada objek didefinisikan secara prosedural. Prosedur-prosedur yang mengimplementasikan

operasi semacam ini sendiri merupakan bentuk objek, dan mereka diakses secara tidak langsung
melalui kemampuan. Nama-nama prosedur yang didefinisikan oleh pengguna harus diidentifikasi
kepada sistem perlindungan jika sistem akan berurusan dengan objek tipe yang didefinisikan oleh
pengguna. Ketika definisi objek diketahui oleh Hydra, nama-nama operasi pada tipe tersebut menjadi
hak tambahan. Hak tambahan dapat dijelaskan dalam sebuah kemampuan untuk sebuah contoh dari
tipe tersebut. Untuk sebuah proses menjalankan operasi pada objek yang tipe, kemampuan yang
dipegang oleh proses untuk objek tersebut harus mengandung nama operasi yang diinvokasi di
antara hak tambahannya. Pembatasan ini memungkinkan diskriminasi hak akses dilakukan pada basis
per-instan dan per-proses.

Hydra juga menyediakan amplifikasi hak akses. Skema ini memungkinkan suatu prosedur disertifikasi
sebagai tepercaya untuk bertindak pada parameter formal dari tipe tertentu atas nama setiap proses
yang memiliki hak untuk menjalankan prosedur tersebut. Hak-hak yang dipegang oleh prosedur yang
tepercaya independen dari dan dapat melampaui hak-hak yang dipegang oleh proses yang
memanggil. Namun, prosedur semacam ini tidak boleh dianggap sebagai tepercaya secara universal
(prosedur tidak diizinkan untuk bertindak pada tipe lain, misalnya), dan kepercayaan tidak boleh
diperluas ke prosedur atau segmen program lain yang mungkin dijalankan oleh proses. Amplifikasi
memungkinkan prosedur implementasi akses ke variabel-variabel representasi dari tipe data abstrak.
Jika suatu proses memiliki kemampuan ke objek dengan tipe A, misalnya, kemampuan tersebut
dapat mencakup hak tambahan untuk memanggil operasi P tetapi tidak mencakup hak-hak inti yang
disebut kernel rights, seperti membaca, menulis, atau menjalankan, pada segmen yang mewakili A.
Kemampuan semacam ini memberikan proses sarana akses tidak langsung (melalui operasi P) ke
representasi dari A, tetapi hanya untuk tujuan tertentu.
Ketika suatu proses memanggil operasi P pada objek A, kemampuan untuk akses ke A dapat di-
amplifikasi ketika kendali berpindah ke tubuh kode P. Amplifikasi ini mungkin perlu untuk
memberikan hak kepada P untuk mengakses segmen penyimpanan yang mewakili A sehingga dapat
mengimplementasikan operasi yang didefinisikan oleh P pada tipe data abstrak. Tubuh kode P
mungkin diizinkan untuk membaca atau menulis langsung ke segmen A, meskipun proses pemanggil
tidak dapat. Saat kembali dari P, kemampuan untuk A dipulihkan ke kondisi semula yang tidak di-
amplifikasi. Ini adalah contoh yang khas di mana hak akses yang dipegang oleh proses untuk akses ke
segmen yang dilindungi harus berubah secara dinamis, tergantung pada tugas yang harus dilakukan.
Penyesuaian dinamis hak akses dilakukan untuk menjamin konsistensi abstraksi yang didefinisikan
oleh pemrogram. Amplifikasi hak dapat dinyatakan secara eksplisit dalam deklarasi tipe abstrak ke
sistem operasi Hydra.

Ketika seorang pengguna meneruskan objek sebagai argumen ke suatu prosedur, kami mungkin perlu
memastikan bahwa prosedur tersebut tidak dapat mengubah objek tersebut. Kami dapat
mengimplementasikan pembatasan ini dengan mudah dengan meneruskan hak akses yang tidak
memiliki hak modifikasi (tulis). Namun, jika amplifikasi mungkin terjadi, hak untuk memodifikasi
mungkin diaktifkan kembali. Dengan demikian, persyaratan perlindungan pengguna dapat dihindari.
Pada umumnya, tentu saja, seorang pengguna mungkin mempercayai bahwa suatu prosedur
melakukan tugasnya dengan benar. Namun, asumsi ini tidak selalu benar, terutama karena kesalahan
perangkat keras atau perangkat lunak. Hydra menyelesaikan masalah ini dengan membatasi
amplifikasi. Mekanisme panggilan prosedur Hydra dirancang sebagai solusi langsung untuk masalah
sub-sistem yang saling curiga. Masalah ini didefinisikan sebagai berikut. Misalkan bahwa suatu
program dapat dijalankan sebagai layanan oleh beberapa pengguna yang berbeda (misalnya,
rutinitas pengurutan, kompilator, permainan). Ketika pengguna mengundang program layanan ini,
mereka mengambil risiko bahwa program tersebut akan berfungsi buruk dan akan merusak data
yang diberikan atau akan tetap memiliki hak akses ke data yang akan digunakan (tanpa izin) nanti.
Demikian pula, program layanan tersebut mungkin memiliki beberapa file pribadi (untuk tujuan
akuntansi, misalnya) yang seharusnya tidak diakses secara langsung oleh program pengguna yang
memanggil. Hydra menyediakan mekanisme untuk langsung menangani masalah ini. Sebuah sub-
sistem Hydra dibangun di atas kernel perlindungannya sendiri dan mungkin memerlukan
perlindungan bagi kompon

ennya sendiri. Sebuah sub-sistem berinteraksi dengan kernel melalui panggilan pada kumpulan
primitif yang didefinisikan oleh kernel yang mendefinisikan hak akses ke sumber daya yang
didefinisikan oleh sub-sistem. Perancang sub-sistem dapat mendefinisikan kebijakan penggunaan
sumber daya ini oleh proses pengguna, tetapi kebijakan ini ditegakkan dengan menggunakan
perlindungan akses standar yang disediakan oleh sistem kemampuan. Programmer dapat dengan
langsung menggunakan sistem perlindungan setelah memahami fitur-fiturnya dalam manual
referensi yang sesuai. Hydra menyediakan perpustakaan besar prosedur yang didefinisikan oleh
sistem yang dapat dipanggil oleh program pengguna. Programmer dapat dengan eksplisit
menggabungkan panggilan pada prosedur-prosedur sistem ini ke dalam kode program mereka atau
dapat menggunakan translator program yang telah diintegrasikan dengan Hydra.
Pendekatan yang berbeda terhadap perlindungan berbasis kemampuan telah diambil dalam desain
sistem CAP Cambridge. Sistem kemampuan CAP sederhana dan secara permukaan kurang kuat
daripada Hydra. Namun, pemeriksaan lebih dekat menunjukkan bahwa CAP juga dapat digunakan
untuk menyediakan perlindungan yang aman terhadap objek yang didefinisikan oleh pengguna. CAP
memiliki dua jenis kemampuan. Jenis biasa disebut sebagai kemampuan data. Ini dapat digunakan
untuk memberikan akses ke objek, tetapi hak yang diberikan hanya berupa hak baca, tulis, dan
jalankan standar pada segmen penyimpanan individu yang terkait dengan objek. Kemampuan data
diinterpretasikan oleh kode mikro dalam mesin CAP.

Jenis kedua kemampuan adalah yang disebut sebagai kemampuan perangkat lunak, yang dilindungi,
tetapi tidak diinterpretasikan oleh kode mikro CAP. Ini diinterpretasikan oleh prosedur yang
dilindungi (yaitu, berhak istimewa), yang dapat ditulis oleh seorang programmer aplikasi sebagai
bagian dari sebuah subsistem. Jenis tertentu dari amplifikasi hak terkait dengan prosedur yang
dilindungi. Saat menjalankan tubuh kode prosedur semacam itu, proses sementara memperoleh hak
untuk membaca atau menulis konten dari kemampuan perangkat lunak itu sendiri. Jenis amplifikasi
hak tertentu ini sesuai dengan implementasi operasi segel dan buka pada kemampuan. Tentu saja,
hak ini masih tunduk pada verifikasi tipe untuk memastikan bahwa hanya kemampuan perangkat
lunak untuk tipe abstrak tertentu yang dilewatkan ke prosedur semacam itu. Kepercayaan universal
tidak ditempatkan pada kode lain selain kode mikro CAP mesin. (Lihat catatan bibliografi di akhir bab
untuk referensi.)

Interpretasi dari kemampuan perangkat lunak sepenuhnya ditentukan oleh subsistem, melalui
prosedur yang dilindungi yang berisikan kemampuan perangkat lunak itu. Skema ini memungkinkan
berbagai kebijakan perlindungan diimplementasikan. Meskipun programmer dapat mendefinisikan
prosedur yang dilindungi mereka sendiri (salah satunya mungkin tidak benar), keamanan sistem
secara keseluruhan tidak dapat dikompromikan. Sistem perlindungan dasar tidak akan mengizinkan
prosedur yang dilindungi yang didefinisikan oleh pengguna yang belum diverifikasi akses ke segmen
penyimpanan (atau kemampuan) yang tidak milik dalam lingkungan perlindungan di mana ia berada.
Konsekuensi paling serius dari prosedur yang dilindungi yang tidak aman adalah terjadinya gangguan
perlindungan dari subsistem yang bertanggung jawab atas prosedur tersebut.

Perancang sistem CAP telah mencatat bahwa penggunaan kemampuan perangkat lunak
memungkinkan mereka untuk mencapai efisiensi yang signifikan dalam merumuskan dan
mengimplementasikan kebijakan perlindungan yang sesuai dengan persyaratan sumber daya abstrak.
Namun, perancang subsistem yang ingin menggunakan fasilitas ini tidak bisa hanya mempelajari
manual referensi, seperti yang terjadi dengan Hydra. Sebaliknya, mereka harus memahami prinsip-
prinsip dan teknik perlindungan, karena sistem tidak memberikan mereka perpustakaan prosedur-
prosedur.

Pada tingkat di mana perlindungan disediakan dalam sistem komputer yang ada, biasanya dicapai
melalui kernel sistem operasi, yang bertindak sebagai agen keamanan untuk memeriksa dan
memvalidasi setiap upaya mengakses sumber daya yang dilindungi. Karena validasi akses
komprehensif dapat menjadi sumber overhead yang cukup besar, kita harus memberikannya
dukungan perangkat keras untuk mengurangi biaya validasi setiap kali, atau kita harus mengizinkan
perancang sistem untuk mengorbankan tujuan perlindungan. Memenuhi semua tujuan ini sulit jika
fleksibilitas dalam mengimplementasikan kebijakan perlindungan dibatasi oleh mekanisme dukungan
yang disediakan atau jika lingkungan perlindungan dibuat lebih besar dari yang diperlukan untuk
mengamankan efisiensi operasional yang lebih besar.

Seiring dengan semakin kompleksnya sistem operasi, dan khususnya ketika mereka mencoba
menyediakan antarmuka pengguna tingkat lebih tinggi, tujuan perlindungan telah menjadi lebih
terperinci. Para perancang sistem perlindungan sangat mengandalkan ide-ide yang berasal dari
bahasa pemrograman dan terutama pada konsep tipe data abstrak dan objek. Sistem perlindungan
sekarang peduli tidak hanya dengan identitas sumber daya yang ingin diakses, tetapi juga dengan
sifat fungsional dari akses tersebut. Dalam sistem perlindungan terbaru, perhatian terhadap fungsi
yang akan dijalankan meluas ke luar kumpulan fungsi yang ditentukan oleh sistem, seperti metode
akses file standar, hingga mencakup fungsi yang mungkin juga didefinisikan oleh pengguna.

Kebijakan penggunaan sumber daya juga dapat bervariasi, tergantung pada aplikasinya, dan dapat
berubah seiring waktu. Oleh karena itu, perlindungan tidak dapat lagi dianggap hanya menjadi
masalah yang relevan bagi perancang sistem operasi. Ini juga harus tersedia sebagai alat yang dapat
digunakan oleh perancang aplikasi, sehingga sumber daya dari subsistem aplikasi dapat dijaga agar
tidak disusupi atau terpengaruh oleh kesalahan.

14.9.1 Penegakan Melalui Kompilator

Pada titik ini, bahasa pemrograman masuk ke dalam gambaran. Menentukan kontrol akses yang
diinginkan terhadap sumber daya bersama dalam suatu sistem adalah pernyataan deklaratif tentang
sumber daya tersebut. Jenis pernyataan semacam ini dapat diintegrasikan ke dalam bahasa dengan
perluasan fasilitas tipenya. Ketika perlindungan dinyatakan bersamaan dengan tipedata, perancang
dari setiap subsistem dapat menentukan kebutuhan perlindungannya, serta kebutuhan akan
penggunaan sumber daya lain dalam suatu sistem. Spesifikasi semacam ini seharusnya diberikan
langsung saat program disusun, dan dalam bahasa yang digunakan untuk menyusun program itu
sendiri. Pendekatan ini memiliki beberapa keunggulan penting:

1. Kebutuhan perlindungan hanya dinyatakan, bukan diprogram sebagai rangkaian pemanggilan

prosedur-prosedur sistem operasi.

2. Kebutuhan perlindungan dapat dinyatakan secara independen dari fasilitas yang disediakan oleh
sistem operasi tertentu.

3. Sarana penegakan tidak harus disediakan oleh perancang suatu subsistem.

4. Notasi deklaratif alamiah karena hak akses erat terkait dengan konsep linguistik tipe data.
Sejumlah teknik dapat disediakan oleh implementasi bahasa pemrograman untuk menegakkan
perlindungan, tetapi semua teknik ini harus bergantung pada dukungan dari mesin yang
mendasarinya dan sistem operasi. Sebagai contoh, anggaplah suatu bahasa digunakan untuk
menghasilkan kode yang akan dijalankan pada sistem CAP Cambridge. Pada sistem ini, setiap
referensi penyimpanan yang dibuat pada perangkat keras dasar terjadi secara tidak langsung melalui
suatu kemampuan. Pembatasan ini mencegah proses manapun untuk mengakses sumber daya di
luar lingkungan perlindungannya kapan pun. Namun, sebuah program dapat memberlakukan
pembatasan sembarangan terhadap bagaimana suatu sumber daya dapat digunakan selama eksekusi
segmen kode tertentu.

Pembatasan semacam ini dapat diimplementasikan dengan lebih mudah dengan menggunakan
kemampuan perangkat lunak yang disediakan oleh CAP. Implementasi bahasa dapat menyediakan
prosedur perlindungan standar untuk menginterpretasikan kemampuan perangkat lunak yang akan
mewujudkan kebijakan perlindungan yang bisa dijelaskan dalam bahasa tersebut. Skema ini
menempatkan spesifikasi kebijakan dalam kendali para pemrogram, sambil membebaskan mereka
dari implementasinya.

Bahkan jika suatu sistem tidak menyediakan kernel perlindungan sekuat Hydra atau CAP, mekanisme
tetap tersedia untuk mengimplementasikan spesifikasi perlindungan yang diberikan dalam bahasa
pemrograman. Perbedaan utamanya adalah bahwa keamanan perlindungan ini tidak akan sebaik
yang didukung oleh kernel perlindungan, karena mekanisme ini harus bergantung pada lebih banyak
asumsi tentang status operasional sistem. Sebuah kompilator dapat memisahkan referensi untuk
yang mana ia dapat menjamin bahwa tidak akan terjadi pelanggaran perlindungan dari yang mungkin
terjadi pelanggaran, dan memperlakukannya secara berbeda. Keamanan yang disediakan oleh jenis
perlindungan ini bergantung pada asumsi bahwa kode yang dihasilkan oleh kompilator tidak akan
dimodifikasi sebelum atau selama pelaksanaannya.

Jadi, apa saja kelebihan relatif penegakan berdasarkan kernel, dibandingkan dengan penegakan yang
sebagian besar disediakan oleh kompilator?

- Keamanan. Penegakan oleh kernel memberikan tingkat keamanan perlindungan yang lebih tinggi
daripada pembuatan kode pemeriksaan perlindungan oleh kompilator. Dalam skema yang didukung
oleh kompilator, keamanan bergantung pada kebenaran penerjemah, pada beberapa mekanisme
dasar pengelolaan penyimpanan yang melindungi segmen-segmen dari mana kode yang telah
dikompilasi dijalankan, dan pada keamanan file dari mana program dimuat. Beberapa pertimbangan
ini juga berlaku untuk kernel perlindungan yang didukung perangkat lunak, tetapi dalam tingkat yang
lebih rendah, karena kernel dapat berada dalam segmen penyimpanan fisik yang tetap dan hanya
dimuat dari file yang ditunjuk. Dengan sistem kemampuan berlabel, di mana semua komputasi
alamat dilakukan baik oleh perangkat keras atau oleh mikroprogram yang tetap, keamanan yang
lebih besar juga dapat dicapai. Perlindungan yang didukung perangkat keras juga relatif kebal
terhadap pelanggaran perlindungan yang mungkin terjadi sebagai akibat dari kerusakan perangkat
keras atau perangkat lunak sistem.

- Fleksibilitas. Ada batasan pada fleksibilitas kernel perlindungan dalam mengimplementasikan

kebijakan yang didefinisikan pengguna, meskipun kernel mungkin menyediakan fasilitas yang
memadai bagi sistem untuk memberlakukan kebijakan mereka sendiri. Dengan bahasa
pemrograman, kebijakan perlindungan dapat dinyatakan dan penegakan diberikan sesuai dengan
kebutuhan oleh suatu implementasi. Jika suatu bahasa tidak memberikan fleksibilitas yang memadai,
maka bisa di perluas atau digantikan dengan gangguan lebih sedikit dibandingkan dengan modifikasi
kernel sistem operasi.

- Efisiensi. Efisiensi tertinggi diperoleh ketika penegakan perlindungan didukung langsung oleh
perangkat keras (atau mikrokode). Sejauh dukungan perangkat lunak diperlukan, penegakan berbasis
bahasa memiliki keunggulan bahwa penerapan penegakan akses statis dapat diverifikasi secara
offline saat waktu kompilasi. Selain itu, karena kompilator cerdas dapat menyesuaikan mekanisme
penegakan untuk memenuhi kebutuhan yang ditentukan, biaya tetap panggilan kernel seringkali
dapat dihindari.

Secara ringkas, spesifikasi perlindungan dalam bahasa pemrograman memungkinkan deskripsi

tingkat tinggi untuk kebijakan alokasi dan penggunaan sumber daya. Implementasi bahasa dapat
menyediakan perangkat lunak untuk penegakan perlindungan ketika pemeriksaan yang didukung
oleh perangkat keras tidak tersedia. Selain itu, implementasi bahasa dapat menginterpretasikan
spesifikasi perlindungan untuk menghasilkan pemanggilan pada sistem perlindungan yang disediakan
oleh perangkat keras dan sistem operasi.

Salah satu cara membuat perlindungan tersedia bagi program aplikasi adalah melalui penggunaan
kemampuan perangkat lunak yang dapat digunakan sebagai objek komputasi. Dalam konsep ini, ada
ide bahwa komponen program tertentu mungkin memiliki hak istimewa untuk membuat atau
memeriksa kemampuan perangkat lunak ini. Program yang membuat kemampuan tersebut dapat
menjalankan operasi primitif yang akan "menyegel" struktur data, sehingga kontennya tidak dapat
diakses oleh komponen program apa pun yang tidak memegang hak istimewa penyegelan atau
pembukaan. Komponen-komponen tersebut mungkin dapat menyalin struktur data atau
meneruskan alamatnya ke komponen program lain, tetapi mereka tidak dapat mengakses kontennya.
Alasan memperkenalkan kemampuan perangkat lunak semacam ini adalah untuk membawa
mekanisme perlindungan ke dalam bahasa pemrograman. Satu-satunya masalah dengan konsep
yang diusulkan adalah penggunaan operasi penyegelan dan pembukaan yang mengambil pendekatan
prosedural untuk menentukan perlindungan. Notasi nonprosedural atau deklaratif tampak menjadi
cara yang lebih baik untuk membuat perlindungan tersedia bagi pemrogram aplikasi.

Yang diperlukan adalah mekanisme kontrol akses yang aman dan dinamis untuk mendistribusikan
kemampuan ke sumber daya sistem di antara proses pengguna. Untuk berkontribusi pada keandalan
keseluruhan sistem, mekanisme kontrol akses harus aman digunakan. Untuk menjadi bermanfaat
dalam praktik, mekanisme tersebut juga sebaiknya cukup efisien. Persyaratan ini telah mendorong
pengembangan sejumlah konstruksi bahasa yang memungkinkan pemrogram untuk mendeklarasikan
berbagai pembatasan terhadap penggunaan sumber daya yang dikelola. (Lihat catatan bibliografi
untuk referensi yang sesuai.) Konstruksi-konstruksi ini menyediakan mekanisme untuk tiga fungsi:

1. Mendistribusikan kemampuan dengan aman dan efisien di antara proses pelanggan. Khususnya,
mekanisme memastikan bahwa proses pengguna akan menggunakan sumber daya yang dikelola
hanya jika diberikan kemampuan untuk sumber daya tersebut.
2. Menentukan jenis operasi yang dapat dipanggil oleh suatu proses tertentu pada sumber daya yang
dialokasikan (misalnya, seorang pembaca file hanya diizinkan untuk membaca file, sementara penulis
harus dapat membaca dan menulis). Tidak perlu memberikan kumpulan hak yang sama kepada
setiap proses pengguna, dan tidak boleh memungkinkan suatu proses memperluas hak aksesnya,
kecuali dengan izin mekanisme pengendalian akses.

3. Menentukan urutan di mana suatu proses tertentu dapat memanggil berbagai operasi sumber
daya (misalnya, sebuah file harus dibuka sebelum bisa dibaca). Harus memungkinkan memberikan
dua proses pembatasan yang berbeda pada urutan di mana mereka dapat memanggil operasi
sumber daya yang dialokasikan.

Penggabungan konsep perlindungan ke dalam bahasa pemrograman, sebagai alat praktis untuk
perancangan sistem, masih dalam tahap awal. Perlindungan kemungkinan akan menjadi perhatian
yang lebih besar bagi perancang sistem baru dengan arsitektur terdistribusi dan persyaratan
keamanan data yang semakin ketat. Kemudian, pentingnya notasi bahasa yang sesuai untuk
menyatakan persyaratan perlindungan akan diakui secara lebih luas.

14.9.2 Perlindungan dalam Java

Karena Java dirancang untuk berjalan dalam lingkungan terdistribusi, mesin virtual Java - atau JVM -
memiliki banyak mekanisme perlindungan bawaan. Program-program Java terdiri dari kelas-kelas,
masing-masing adalah kumpulan bidang data dan fungsi-fungsi (yang disebut metode) yang
beroperasi pada bidang-bidang tersebut. JVM memuat suatu kelas sebagai respons terhadap
permintaan untuk membuat instance (atau objek) dari kelas tersebut. Salah satu fitur paling inovatif
dan berguna dari Java adalah dukungannya untuk memuat dinamis kelas-kelas yang tidak dapat
dipercaya melalui jaringan dan mengeksekusi kelas-kelas yang saling tidak percaya dalam JVM yang
sama.

Karena kemampuan ini, perlindungan adalah perhatian utama. Kelas-kelas yang berjalan dalam JVM
yang sama mungkin berasal dari sumber yang berbeda dan mungkin tidak memiliki tingkat
kepercayaan yang sama. Akibatnya, menegakkan perlindungan pada tingkat proses JVM saja tidak
mencukupi. Intuitif, apakah permintaan untuk membuka file seharusnya diizinkan akan bergantung
pada kelas mana yang meminta pembukaan. Sistem operasi tidak memiliki pengetahuan ini.

Oleh karena itu, keputusan-keputusan perlindungan seperti itu ditangani dalam JVM. Ketika JVM
memuat suatu kelas, kelas tersebut diberikan kepada suatu domain perlindungan yang memberikan
izin-izin dari kelas tersebut. Domain perlindungan ke mana kelas tersebut diberikan bergantung pada
URL dari mana kelas tersebut dimuat dan tanda tangan digital pada file kelas tersebut.
Sebuah file kebijakan yang dapat dikonfigurasi menentukan izin-izin yang diberikan kepada domain
perlindungan tersebut (dan kelas-kelasnya). Sebagai contoh, kelas-kelas yang dimuat dari server yang
dapat dipercaya mungkin ditempatkan dalam domain perlindungan yang memungkinkan mereka
mengakses file-file di direktori pengguna, sedangkan kelas-kelas yang dimuat dari server yang tidak
dapat dipercaya mungkin tidak memiliki izin akses file sama sekali.

Dalam JVM, menentukan kelas yang bertanggung jawab atas permintaan untuk mengakses sumber
daya yang dilindungi bisa menjadi hal yang rumit. Akses sering dilakukan secara tidak langsung,
melalui pustaka sistem atau kelas-kelas lain. Sebagai contoh, pertimbangkan sebuah kelas yang tidak
diizinkan untuk membuka koneksi jaringan. Kelas tersebut bisa memanggil sebuah pustaka sistem
untuk meminta muatan dari suatu URL. JVM harus memutuskan apakah akan membuka koneksi
jaringan untuk permintaan ini. Namun, kelas mana yang harus digunakan untuk menentukan apakah
koneksi tersebut diizinkan, aplikasi atau pustaka sistem?

Filosofi yang diadopsi dalam Java adalah menuntut agar kelas pustaka secara eksplisit mengizinkan
koneksi jaringan. Secara lebih umum, untuk mengakses sumber daya yang dilindungi, suatu metode
dalam urutan panggilan yang menghasilkan permintaan harus secara eksplisit mengklaim hak akses
ke sumber daya tersebut. Dengan demikian, metode ini bertanggung jawab atas permintaan
tersebut. Diharapkan, metode tersebut juga akan melakukan pemeriksaan yang diperlukan untuk
memastikan keamanan permintaan tersebut. Tentu saja, tidak setiap metode diizinkan untuk
mengklaim hak akses; sebuah metode dapat mengklaim hak akses hanya jika kelasnya berada dalam
domain perlindungan yang diizinkan untuk menggunakan hak akses tersebut.

Pendekatan implementasi ini disebut sebagai inspeksi tumpukan (stack inspection). Setiap utas
dalam JVM memiliki tumpukan yang terkait dengan panggilan metode yang sedang berlangsung.
Ketika pemanggil tidak dapat dipercaya, suatu metode menjalankan permintaan akses dalam blok
doPrivileged untuk melakukan akses ke sumber daya yang dilindungi secara langsung atau tidak
langsung. doPrivileged() adalah metode statis dalam kelas AccessController yang menerima kelas
dengan metode run() untuk dijalankan. Ketika blok doPrivileged dimasuki, bingkai tumpukan untuk
metode ini diberi anotasi untuk menunjukkan hal ini. Kemudian, isi blok dijalankan. Ketika suatu
akses ke sumber daya yang dilindungi diminta kemudian, baik oleh metode ini atau metode yang
dipanggilnya, pemanggilan checkPermissions() digunakan untuk menjalankan inspeksi tumpukan
untuk menentukan apakah permintaan tersebut harus diizinkan. Inspeksi tersebut memeriksa bingkai
tumpukan pada tumpukan utas yang melakukan panggilan, dimulai dari bingkai yang paling baru
ditambahkan dan menuju ke yang paling lama. Jika bingkai tumpukan pertama yang ditemukan
memiliki anotasi doPrivileged(), maka checkPermissions() akan mengembalikan izin segera dan tanpa
suara, memungkinkan akses. Jika bingkai tumpukan pertama yang ditemukan melarang akses
berdasarkan domain perlindungan kelas metodenya, maka checkPermissions() akan menimbulkan
AccessControlException. Jika inspeksi tumpukan menghabiskan seluruh tumpukan tanpa
menemukan bingkai tumpukan jenis apa pun, maka apakah akses diizinkan akan tergantung pada
implementasinya (misalnya, beberapa implementasi JVM mungkin mengizinkan akses, sementara
implementasi lainnya mungkin tidak).
Inspeksi tumpukan diilustrasikan dalam Gambar 14.9. Di sini, metode gui() dari sebuah kelas dalam
domain perlindungan applet yang tidak dipercaya menjalankan dua operasi, pertama get() dan
kemudian open(). Yang pertama adalah panggilan metode get() dari kelas dalam domain
perlindungan pemuat URL, yang diizinkan untuk membuka sesi ke situs di domain lucent.com,
khususnya server proxy proxy.lucent.com untuk mengambil URL. Oleh karena itu, panggilan get()
applet yang tidak dipercaya akan berhasil: pemanggilan checkPermissions() dalam pustaka jaringan
menemui bingkai tumpukan metode get(), yang menjalankan open() dalam blok doPrivileged.
Namun, panggilan open() applet yang tidak dipercaya akan menghasilkan pengecualian, karena
pemanggilan checkPermissions() tidak menemukan anotasi doPrivileged sebelum menemui bingkai
tumpukan metode gui().

Untuk memastikan inspeksi tumpukan berfungsi, sebuah program harus tidak dapat mengubah
anotasi pada bingkai tumpukannya sendiri atau melakukan manipulasi lain terhadap inspeksi
tumpukan. Ini adalah salah satu perbedaan paling penting antara Java dan banyak bahasa lain
(termasuk C++). Sebuah program Java tidak dapat mengakses memori secara langsung; ia hanya
dapat memanipulasi objek yang memiliki referensi kepadanya. Referensi tidak dapat dipalsukan, dan
manipulasi dilakukan hanya melalui antarmuka yang terdefinisi dengan baik. Kepatuhan ditegakkan
melalui koleksi pemeriksaan pada saat pemuatan (load-time) dan saat berjalan (run-time). Sebagai
hasilnya, sebuah objek tidak dapat memanipulasi tumpukannya sendiri, karena tidak dapat
mendapatkan referensi ke tumpukan atau komponen perlindungan sistem lainnya.

Secara umum, pemeriksaan pada saat pemuatan dan saat berjalan Java menegakkan keamanan tipe
kelas Java. Keamanan tipe memastikan bahwa kelas-kelas tidak dapat memperlakukan bilangan bulat
sebagai pointer, menulis melewati akhir larik, atau mengakses memori secara sembarangan.
Sebaliknya, sebuah program dapat mengakses objek hanya melalui metode-metode yang
didefinisikan pada objek tersebut oleh kelasnya. Ini adalah dasar dari perlindungan Java, karena ini
memungkinkan suatu kelas untuk secara efektif mengemas dan melindungi data dan metodenya dari
kelas-kelas lain yang dimuat dalam JVM yang sama. Sebagai contoh, sebuah variabel dapat
didefinisikan sebagai private sehingga hanya kelas yang mengandungnya yang dapat mengaksesnya,
atau sebagai protected sehingga hanya dapat diakses oleh kelas yang mengandungnya, subkelas dari
kelas tersebut, atau kelas-kelas dalam paket yang sama. Keamanan tipe memastikan bahwa
pembatasan-pembatasan ini dapat ditegakkan.
14.10 Ringkasan:

Sistem komputer mengandung banyak objek yang perlu dilindungi dari penyalahgunaan. Objek-objek
tersebut bisa berupa perangkat keras (seperti memori, waktu CPU, dan perangkat I/O) atau
perangkat lunak (seperti file, program, dan semafor). Hak akses adalah izin untuk melakukan operasi
pada suatu objek. Domain adalah kumpulan hak akses. Proses berjalan dalam domain dan dapat
menggunakan salah satu hak akses dalam domain tersebut untuk mengakses dan memanipulasi
objek. Selama masa hidupnya, sebuah proses dapat terikat pada suatu domain perlindungan atau
diizinkan untuk beralih dari satu domain ke domain lain.

Matriks akses adalah model umum perlindungan yang menyediakan

mekanisme perlindungan tanpa memberlakukan kebijakan perlindungan tertentu pada

sistem atau pengguna-pengguna sistem tersebut. Pemisahan antara kebijakan dan mekanisme

merupakan sifat desain yang penting.

Matriks akses ini cenderung jarang diisi. Biasanya diimplementasikan sebagai daftar akses

yang terkait dengan setiap objek atau sebagai daftar kemampuan yang terkait dengan setiap domain.

Kita dapat menyertakan perlindungan dinamis dalam model matriks akses ini dengan
mempertimbangkan

domain dan matriks akses itu sendiri sebagai objek-objek. Pembatalan hak akses dalam

model perlindungan dinamis ini biasanya lebih mudah diimplementasikan dengan skema daftar akses

daripada dengan daftar kemampuan.

Sistem nyata jauh lebih terbatas dibandingkan dengan model umum tersebut dan cenderung

menyediakan perlindungan hanya untuk file-file. UNIX adalah contoh yang mewakili, menyediakan
perlindungan

baca, tulis, dan eksekusi secara terpisah untuk pemilik, grup, dan masyarakat umum

pada setiap file. MULTICS menggunakan struktur cincin selain dari akses file. Hydra, sistem CAP
Cambridge,

dan Mach adalah sistem-sistem kemampuan yang memperluas perlindungan

ke objek-objek perangkat lunak yang didefinisikan oleh pengguna. Solaris 10 mengimplementasikan

prinsip hak

privilege terkecil melalui kontrol akses berbasis peran, sebuah bentuk dari matriks akses.

Perlindungan berbasis bahasa memberikan pengaturan permintaan dan hak akses yang lebih halus
daripada yang dapat

disediakan oleh sistem operasi. Sebagai contoh, JVM Java tunggal dapat menjalankan beberapa
thread, masing-masing dalam kelas perlindungan yang berbeda. Ini
mengenakan permintaan sumber daya melalui pemeriksaan stack yang canggih dan melalui
keselamatan tipe bahasa.