|
|
|
Modern Operating Systems by Herbert Bos and Andrew S. Tanenb...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf
Showing 732-733 out of 1137
Modern Operating Systems by Herbert Bos and Andrew...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Modern Operating Systems by Herbert...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Page 732
SEC. 9.10
DEFENSES
701
Untrusted applet
Trusted applet
Web browser
Sandbox
Interpreter
Virtual address space
0xFFFFFFFF
0
Figure 9-39.
Applets can be interpreted by a Web browser.
also caught and interpreted. How these calls are handled is a matter of the security
policy. For example, if an applet is trusted (e.g., it came from the local disk), its
system calls could be carried out without question. However, if an applet is not
trusted (e.g., it came in over the Internet), it could be put in what is effectively a
sandbox to restrict its behavior.
High-level scripting languages can also be interpreted. Here no machine ad-
dresses are used, so there is no danger of a script trying to access memory in an
impermissible way. The downside of interpretation in general is that it is very slow
compared to running native compiled code.
9.10.7 Java Security
The Java programming language and accompanying run-time system were de-
signed to allow a program to be written and compiled once and then shipped over
the Internet in binary form and run on any machine supporting Java. Security was a
part of the Java design from the beginning. In this section we will describe how it
works.
Java is a type-safe language, meaning that the compiler will reject any attempt
to use a variable in a way not compatible with its type.
In contrast, consider the
following C code:
naughty
func( )
{
char
*
p;
p
=
rand( );
*
p = 0;
}
It generates a random number and stores it in the pointer
p
.
Then it stores a 0 byte
at the address contained in
p
, overwriting whatever was there, code or data.
In
Page 733
702
SECURITY
CHAP. 9
Java, constructions that mix types like this are forbidden by the grammar.
In addi-
tion, Java has no pointer variables, casts, or user-controlled storage allocation (such
as
malloc
and
free
), and all array references are checked at run time.
Java programs are compiled to an intermediate binary code called
JVM
(
Java
Virtual Machine
)
byte code
.
JVM has about 100 instructions, most of which
push objects of a specific type onto the stack, pop them from the stack, or combine
two items on the stack arithmetically. These JVM programs are typically inter-
preted, although in some cases they can be compiled into machine language for
faster execution. In the Java model, applets sent over the Internet are in JVM.
When an applet arrives, it is run through a JVM byte code verifier that checks
if the applet obeys certain rules.
A properly compiled applet will automatically
obey them, but there is nothing to prevent a malicious user from writing a JVM
applet in JVM assembly language. The checks include
1.
Does the applet attempt to forge pointers?
2.
Does it violate access restrictions on private-class members?
3.
Does it try to use a variable of one type as another type?
4.
Does it generate stack overflows or underflows?
5.
Does it illegally convert variables of one type to another?
If the applet passes all the tests, it can be safely run without fear that it will access
memory other than its own.
However, applets can still make system calls by calling Java methods (proce-
dures) provided for that purpose. The way Java deals with that has evolved over
time. In the first version of Java,
JDK
(
Java Development Kit
)
1.0
.
applets were
divided into two classes: trusted and untrusted. Applets fetched from the local disk
were trusted and allowed to make any system calls they wanted. In contrast, app-
lets fetched over the Internet were untrusted.
They were run in a sandbox, as
shown in Fig. 9-39, and allowed to do practically nothing.
After some experience with this model, Sun decided that it was too restrictive.
In JDK 1.1, code signing was employed. When an applet arrived over the Internet,
a check was made to see if it was signed by a person or organization the user trust-
ed (as defined by the user’s list of trusted signers).
If so, the applet was allowed to
do whatever it wanted. If not, it was run in a sandbox and severely restricted.
After more experience, this proved unsatisfactory as well, so the security
model was changed again. JDK 1.2 introduced a configurable fine-grain security
policy that applies to all applets, both local and remote. The security model is com-
plicated enough that an entire book has been written describing it (Gong, 1999), so
we will just briefly summarize some of the highlights.
Each applet is characterized by two things: where it came from and who signed
it. Where it came from is its URL; who signed it is which private key was used for
the signature. Each user can create a security policy consisting of a list of rules.
Ace your assessments! Get Better Grades
Browse thousands of Study Materials & Solutions from your Favorite Schools
Concordia University
Concordia_University
School:
Operating_Systems
Course:
Great resource for chem class. Had all the past labs and assignments
Leland P.
Santa Clara University
Introducing Study Plan
Using AI Tools to Help you understand and remember your course concepts better and faster than any other resource.
Find the best videos to learn every concept in that course from Youtube and Tiktok without searching.
Save All Relavent Videos & Materials and access anytime and anywhere
Prepare Smart and Guarantee better grades
Know more
Students also viewed documents
lab 18.docx
lab_18.docx
Course
Course
3
Module5QuizSTA2023.d...
Module5QuizSTA2023.docx.docx
Course
Course
10
Week 7 Test Math302....
Week_7_Test_Math302.docx.docx
Course
Course
30
Chapter 1 Assigment ...
Chapter_1_Assigment_Questions.docx.docx
Course
Course
5
Week 4 tests.docx.do...
Week_4_tests.docx.docx
Course
Course
23
Week 6 tests.docx.do...
Week_6_tests.docx.docx
Course
Course
106
