Download - Notesvillage

RAJAGIRI SCHOOL OF
ENGINEERING & TECHNOLOGY
RAJAGIRI VALLEY, KAKKANAD, COCHIN – 682 039
DIVISION OF COMPUTING SCIENCES
SECURITY IN COMPUTING – MODULE IV
INDEX
1. Kerberos…………………………………………………..3
2. X.509………………………………………………………..5
3. Email Security…………………………………………….7
4. Secure Socket Layer…………………………………….9
5. IPSec………………………………………………………13
6. Firewalls…………………………………………………..16
7. Security Mechanisms in Java…………………………18
2
1. Kerberos
Kerberos is a secure method for authenticating a request for a service in a computer
network. Kerberos was developed in the Athena Project at the Massachusetts Institute of
Technology (MIT). The name is taken from Greek mythology; Kerberos was a threeheaded dog who guarded the gates of Hades. Kerberos lets a user request an encrypted
"ticket" from an authentication process that can then be used to request a particular
service from a server. The user's password does not have to pass through the network.
The three heads of Kerberos comprise the Key Distribution Center (KDC), the client user
and the server with the desired service to access. The KDC is installed as part of the
domain controller and performs two service functions: the Authentication Service (AS)
and the Ticket-Granting Service (TGS). As exemplified in Figure 1, three exchanges are
involved when the client initially accesses a server resource:
1. AS Exchange
2. TGS Exchange
3. Client Server(CS) Exchange
3
Source : www.microsoft.com
1.1 AS Exchange
When initially logging on to a network, users must negotiate access by providing a log-in
name and password in order to be verified by the AS portion of a KDC within their
domain. The KDC has access to Active Directory user account information. Once
successfully authenticated, the user is granted a Ticket to Get Tickets (TGT) that is valid
for the local domain. The TGT has a default lifetime of 10 hours and may be renewed
throughout the user's log-on session without requiring the user to re-enter his password.
The TGT is cached on the local machine in volatile memory space and used to request
sessions with services throughout the network.
1.2 TGS Exchange
The user presents the TGT to the TGS portion of the KDC when desiring access to a
server service. The TGS on the KDC authenticates the user's TGT and creates a ticket and
session key for both the client and the remote server. This information, known as the
service ticket, is then cached locally on the client machine.
The TGS receives the client's TGT and reads it using its own key. If the TGS approves of
the client's request, a service ticket is generated for both the client and the target server.
The client reads its portion using the TGS session key retrieved earlier from the AS reply.
The client presents the server portion of the TGS reply to the target server in the
client/server exchange coming next.
1.3 Client/Server Exchange
Once the client user has the client/server service ticket, he can establish the session with
the server service. The server can decrypt the information coming indirectly from the
TGS using its own long-term key with the KDC. The service ticket is then used to
4
authenticate the client user and establish a service session between the server and client.
After the ticket's lifetime is exceeded, the service ticket must be renewed to use the
service.
2. X.509
A public-key certificate is a digitally signed statement from one entity, saying that the
public key (and some other information) of another entity has some specific value. Now a
Certification Authority (CA) can act as a Trusted Third Party. CAs are entities that are
trusted to sign (issue) certificates for other entities. It is assumed that CAs will only
create valid and reliable certificates as they are bound by legal agreements. There are
many public Certification Authorities, such as VeriSign, Thawte, Entrust, and so on.
The main inputs to the certificate creation process are:
 Matched public and private keys, generated using some special tools.Only the
public key is ever shown to anyone else. The private key is used to sign data.
 We need to provide information about the entity being certified. This normally
includes information such as name and organizational address.
The X.509 standard defines what information can go into a certificate, and describes how
to write it down (the data format). All X.509 certificates have the following data, in
addition to the signature:
Version
5
This identifies which version of the X.509 standard applies to this certificate,
which affects what information can be specified in it. Thus far, three versions are
defined.
Serial Number
The entity that created the certificate is responsible for assigning it a serial
number to distinguish it from other certificates it issues. This information is used
in numerous ways, for example when a certificate is revoked its serial number is
placed in a Certificate Revocation List (CRL).
Signature Algorithm Identifier
This identifies the algorithm used by the CA to sign the certificate.
Issuer Name
The X.500 name of the entity that signed the certificate. This is normally a CA.
Using this certificate implies trusting the entity that signed this certificate.
Validity Period
Each certificate is valid only for a limited amount of time. This period is
described by a start date and time and an end date and time, and can be as short as
a few seconds or almost as long as a century. The validity period chosen depends
on a number of factors, such as the strength of the private key used to sign the
certificate or the amount one is willing to pay for a certificate. This is the
expected period that entities can rely on the public value, if the associated private
key has not been compromised.
Subject Name
The name of the entity whose public key the certificate identifies. This name uses
the X.500 standard, so it is intended to be unique across the Internet. This is the
Distinguished Name (DN) of the entity, for example,
CN=Java Duke, OU=Java Software Division, O=Sun Microsystems Inc, C=US
(These refer to the subject's Common Name, Organizational Unit, Organization,
and Country.)
Subject Public Key Information
This is the public key of the entity being named, together with an algorithm
identifier which specifies which public key crypto system this key belongs to and
any associated key parameters.
X.509 Version 1 has been available since 1988, is widely deployed, and is the most
generic.
X.509 Version 2 introduced the concept of subject and issuer unique identifiers to handle
the possibility of reuse of subject and/or issuer names over time. Most certificate profile
documents strongly recommend that names not be reused, and that certificates should not
make use of unique identifiers. Version 2 certificates are not widely used.
X.509 Version 3 is the most recent and supports the notion of extensions, whereby anyone
can define an extension and include it in the certificate
6
3. Email Security Enhancements
Following is the security enhancements for email
•confidentiality
–protection from disclosure
•authentication
–of sender of message
•message integrity
–protection from modification
•non-repudiation of origin
–protection from denial by sender
3.1 PGP
(For diagrams refer text book- William Stallings)
PGP is an official email security system. It was developed by Phil Zimmermann.PGP is
available on Unix, PC, Macintosh and Amiga systems. It is originally free, now have
commercial versions available also
7
3.1.1 How PGP works
Authentication
1.The sender creates a message
2.SHA-1 used to generate 160-bit hash code of message
3.The hash code is encrypted with RSA using the sender's private key, and result is
attached to message.
4.The receiver uses RSA or DSS with sender's public key to decrypt and recover hash
code
5.The receiver generates new hash code for message and compares with decrypted hash
code, if match, message is accepted as authentic
Confidentiality
1. The sender generates message and random 128-bit number to be used as session key
for this message only.
2.The message is encrypted, using CAST-128 / IDEA/3DES with session key.
3.The session key is encrypted using RSA with recipient's public key, then attached to
message.
4.The receiver uses RSA with its private key to decrypt and recover session key.
5.The session key is used to decrypt message.
Authentication & Confidentiality
1. Create signature & attach to message
2. Encrypt both message & signature
3. Attach RSA encrypted session key
Compression
By default PGP compresses message after signing but before encrypting and can store
uncompressed message & signature for later verification. It uses ZIP compression
algorithm.
Email- Compatibility
When using PGP we will have binary data to send (encrypted message etc).However
email was designed only for text. Hence PGP must encode raw binary data into printable
ASCII characters. For this it uses radix-64 algorithm, which maps 3 bytes to 4 printable
characters and also appends a CRC
3.2 S/MIME
S/MIME is the name given to Secure MIME or Secure encryption of attachments when
they are added to email messages. S/MIME requires a both a private and public key. The
public key is stored and made available to those who wish to send users an encrypted
message. So to send a message via S/MIME the sender must look up the public key in a
global directory or already have it available. Once the key has been found, the sender
must encrypt the message/attachment and forward it to the destination server.
8
In order for the message to be read, the encrypted message must be decoded by the mail
client or by the mail server. There are issues with either of these solutions:


Decryption by the mail client. At the current time, not many mail clients support
S/MIME decryption. Further there is the issue of configuring the mail client with
the correct private key so that decryption works OK. Since messages are stored
encrypted, if the key becomes compromised at any point in the future and must be
changed, there is the risk that the messages will become unavilable in the future.
Decryption by the mail server. This requires the server to hold both the
encryption and decryption key for each user. Clearly there will be additional load
on the server as it manages each message and messages are likley to be stored
unencrypted on the server itself (there is no point in them being encrypted since
the key is available on the server).
4. Secure Socket Layer
The Secure Sockets Layer protocol is a protocol layer which may be placed between a
reliable connection-oriented network layer protocol (e.g. TCP/IP) and the application
protocol layer (e.g. HTTP). SSL provides secure communication between client and
server by allowing mutual authentication, the use of digital signatures for integrity, and
encryption for privacy. The protocol is designed to support a range of choices for specific
algorithms used for cryptography, digests, and signatures. Choices are negotiated
between client and server at the start of establishing a protocol session.
Version: Source:
SSL
Vendor Standard
v2.0
(from Netscape
Corp.)
Description:
First SSL protocol for which implementations exists
SSL
v3.0
Revisions to prevent specific security attacks, add nonRSA ciphers, and support for certificate chains
TLS
v1.0
Expired Internet
Draft (from
Netscape Corp.)
Proposed Internet
Standard (from
Revision of SSL 3.0 to update the MAC layer to HMAC,
add block padding for block ciphers, message order
9
IETF)
standardization and more alert messages.
There are a number of versions of the SSL protocol, as shown. SSL 3.0 is the basis for
the Transport Layer Security protocol standard, currently in development by the Internet
Engineering Task Force (IETF).
4.1 Session Establishment
The SSL session is established by following a handshake sequence between client and
server. This sequence may vary, depending on whether the server is configured to
provide a server certificate or request a client certificate. Though cases exist where
additional handshake steps are required for management of cipher information, this
article summarizes one common scenario: see the SSL specification for the full range of
possibilities. Once an SSL session has been established it may be reused, thus avoiding
the performance penalty of repeating the many steps needed to start a session. For this the
server assigns each SSL session a unique session identifier which is cached in the server
and which the client can use on forthcoming connections to reduce the handshake.
The elements of the handshake sequence, as used by the client and server, are listed
below:
1.
2.
3.
4.
Negotiate the Cipher Suite to be used during data transfer
Establish and share a session key between client and server
Optionally authenticate the server to the client
Optionally authenticate the client to the server
10
The first step, Cipher Suite Negotiation, allows the client and server to choose a Cipher
Suite supportable by both of them. The SSL3.0 protocol specification defines 31 Cipher
Suites. A Cipher Suite is defined by the following components:



Key Exchange Method
Cipher for Data Transfer
Message Digest for creating the Message Authentication Code (MAC)
These three elements are described in the sections that follow.
4.2 Key Exchange Method
The key exchange method defines how the shared secret symmetric cryptography key
used for application data transfer will be agreed upon by client and server. SSL 2.0 uses
RSA key exchange only, while SSL 3.0 supports a choice of key exchange algorithms
including the RSA key exchange when certificates are used, and Diffie-Hellman key
exchange for exchanging keys without certificates and without prior communication
between client and server. One variable in the choice of key exchange methods is digital
signatures -- whether or not to use them, and if so, what kind of signatures to use.
4.3 Cipher for Data Transfer
SSL uses the conventional cryptography algorithm (symmetric cryptography) described
earlier for encrypting messages in a session. There are nine choices, including the choice
to perform no encryption:



No encryption
Stream Ciphers
o RC4 with 40-bit keys
o RC4 with 128-bit keys
CBC Block Ciphers
o RC2 with 40 bit key
o DES with 40 bit key
o DES with 54 bit key
o Triple-DES with 168 bit key
o Idea (128 bit key)
4.4 SSL Record Protocol - Architecture
HTTP
FTP
SMTP
11
SSL
handshake
protocol
SSL change
cipher spec
protocol
SSL alert
protocol
SSL Record Protocol
TCP
IP
SSL Record Protocol takes care of the data transmission. SSL Record Protocol provides
two services, confidentiality and integrity. Confidentiality uses symmetric encryption
with a shared secret key defined by Handshake Protocol and integrity uses a MAC with
shared secret key.SSL is used to transfer application and SSL Control data between the
client and server. It possibly fragments the data into smaller units, compress the data,
attach signatures and encrypt these units before transmitting them.
12
5. IPSec
IPSec is a group of protocols developed by IETF. The group includes the Authentication
Header (AH), which addresses authentication for IP traffic, and the Encapsulating
Security Payload (ESP), which defines encryption for IP data. AH ensures that the
packet has not been altered during transmission. It can be used in combination with ESP
or it simply just use to verify the authenticity of a regular IP packet. The AH also allows
the receiver to verify the identity of the sender. IPSec provides these at the IP layer and
its often nowadays build on the networks card from the beginning. IPSec can be used to
protect one or more data flows between a pair of hosts, gateways and between both
gateways and hosts.
Key management for IPsec: ISAKMP and IKE
ISAKMP (Internet Security Association and Key Protocol Management) is designed to
negotiate, establish, modify and delete security associations and their attributes.
ISAKMP is a generic framework which does not dependent on the mechanisms in favor
of which the negotiation takes place.
IKE is used to handle negotiation of protocols and algorithms that are based on local
policy that generate the encryption and the authentication. Some of these is DES,
MD5, AH and SHA. IKE provides a authentication of the IPSec peers and establishes the
IPSec key.
DES (The Data Encryption Standard) is used to encrypt the packet data. DES use cipher
block chaining to initialize a vector to start the encryption.
13
SHA (Secure Hash Algorithm) and MD5 (Message Digest 5) are hash algorithms and
these are used to authenticate the data.
ESP (Encapsulating Security Payload) is the protocol that handles encryption of IP data.
It uses symmetric, or secret key, cryptographic algorithms like Data Encryption Standard
(DES), and triples DES to encrypt the payload. The default method is 56-bit DES.
5.1 Encapsulating Security Payload
ESP includes several parts, the first of which is the control header that contains the SPI
and the sequence number field. The SPI and sequence number serve the same purpose as
in the AH. The SPI indicates which security algorithms and keys were used for a
particular connection, and the sequence number keeps track of the order in which packets
are transmitted. The payload data can be of any size because it's the actual data being
carried by the packet. Along with the payload data, the ESP also contains 0 bytes to 255
bytes of padding, which ensures the data, will be of the correct length for particular types
of encryption algorithms. This area of the ESP also includes the pad length, which tells
how much padding is in the payload, and the next header field, which gives information
about the data and the protocol used. Authentication data is the field that contains a
digital signature that has been applied to everything in the ESP except the authentication
data itself.
5.2 Authentication Header
14
Authentication Header is a security protocol that provides authentication and optional
replay-detection services. AH is embedded in the data to be protected AH can be used
either by itself or with Encryption Service Payload (ESP). The first field in the AH is the
next header field; this is an 8-bit field that tells which higher-level protocol (such as
UDP, TCP, or ESP) follows the AH. The payload length is an 8-bit value that indicates
the length of the authentication data field in 32-bit words. The Security Parameters Index
is a 32-bit number that tells the packet recipient which security protocols the sender is
using. This information includes which algorithms and keys are being applied by the
sending device. The sequence number tells how many packets with the same parameters
have been sent. This number acts as a counter and is incremented each time a packet with
the same SPI is bound for the same address. Authentication data is a digital signature for
the packet. To authenticate users, the AH can use either Message Digest 5 algorithm or
the Secure Hash Algorithm.
5.3 Operating modes
There are two different modes in IPsec, transport mode and tunnel mode.
In Transport mode, only the data from the upper-layer protocol and the data transported
by the IP datagrams are protected. This mode is usable only on final equipment.
In tunnel mode, the IP header is also protected (authentication, integrity and/or
confidentiality) and is replaced by a new header. This new header is used to transport the
packet to the end of the tunnel, where the original header is restored. Tunnel mode is
usable either on final equipment or on security gateways. This mode makes it possible to
ensure a more significant protection against traffic analysis.
15
6. Firewalls
A firewall is simply a group of components that collectively form a barrier between two
networks. A firewall is a piece of hardware and/or software which functions in a
networked environment to prevent some communications forbidden by the security
policy.
6.1 Terminologies
Bastion host.
A general-purpose computer used to control access between the internal (private)
network (intranet) and the Internet (or any other untrusted network).
Router.
A special purpose computer for connecting networks together. Routers also
handle certain functions, such as routing , or managing the traffic on the networks
they connect.
Access Control List (ACL).
Many routers now have the ability to selectively perform their duties, based on a
number of facts about a packet that comes to it. This includes things like
origination address, destination address, destination service port, and so on. These
can be employed to limit the sorts of packets that are allowed to come in and go
out of a given network.
Demilitarized Zone (DMZ).
The DMZ is a critical part of a firewall: it is a network that is neither part of the
untrusted network, nor part of the trusted network. But, this is a network that
connects the untrusted to the trusted. The importance of a DMZ is tremendous:
someone who breaks into your network from the Internet should have to get
16
through several layers in order to successfully do so. Those layers are provided by
various components within the DMZ.
Proxy.
This is the process of having one host act in behalf of another. A host that has the
ability to fetch documents from the Internet might be configured as a proxy
server, and host on the intranet might be configured to be proxy clients. All hosts
on the intranet are able to access resources on the Internet without having the
ability to direct talk to the Internet.
6.2 Types of Firewalls
Application Gateways
The first firewalls were application gateways, and are sometimes known as proxy
gateways. These are made up of bastion hosts that run special software to act as a proxy
server. This software runs at the Application Layer of the ISO/OSI Reference Model,
hence the name. Clients behind the firewall must be proxitized (that is, must know how to
use the proxy, and be configured to do so) in order to use Internet services. Traditionally,
these have been the most secure, because they don't allow anything to pass by default, but
need to have the programs written and turned on in order to begin passing traffic.
Packet Filtering
Packet filtering is a technique whereby routers have ACLs (Access Control Lists) turned
on. By default, a router will pass all traffic sent it, and will do so without any sort of
restrictions. Employing ACLs is a method for enforcing security policy with regard to
what sorts of access you allow the outside world to have to your internal network, and
vice versa. There is less overhead in packet filtering than with an application gateway,
because the feature of access control is performed at a lower ISO/OSI layer (typically, the
transport or session layer). Due to the lower overhead and the fact that packet filtering is
done with routers, which are specialized computers optimized for tasks related to
networking, a packet filtering gateway is often much faster than its application layer.
17
7. Security Mechanisms in Java Platform
Java applets are far more powerful than the usual HTML code served up on the Web.
When not restricted by applet-security measures, Java is a complete and powerful
programming language capable of sending information over the network; reading,
altering, or deleting files; using system resources; and so on. This is powerful stuff, and
in the hands of a malicious programmer. Java should restrict itself such that the full
power and potential of the Java language is not misused. Java applets we retrieve from
the Web have been written by someone else, we cannot trust them to perform with
integrity. Java downloaded from the Net is automatically considered untrusted code. In
order to ensure that untrusted code does nothing mischievous, it is important to limit what
that untrusted code can do.
Following are the basic categories of potential attacks Java applets could facilitate:
ATTACK
CLASS
EXPLANATION AND
CONSEQUENCES
JAVA
DEFENSE
System
Modification
The most severe class of attacks.
Applets that implement such attacks are
attack applets. Consequences of these
attacks: severe.
Strong
Invasion of
Privacy
If you value your privacy, this attack
class may be particularly odious. They
are implemented by malicious applets.
Include mail forging. Consequences of
these attacks: moderate.
Strong
18
Denial of
Service
Also serious but not severely so, these
attacks can bring a machine to a
standstill. Also implemented by
malicious applets. May require reboot.
Consequences of these attacks:
moderate.
Weak
Antagonism
Merely annoying, this attack class is the
most commonly encountered.
Implemented by malicious applets. May
require restart of browser.
Consequences of these attacks: light to
moderate.
Weak
7.1 Java Sandbox Architecture
The default sandbox is made of three interrelated parts: the Verifier, the Class Loader,
and the Security Manager. If any of the three parts breaks, the entire security system
breaks. The Verifier is built in to the VM and cannot be accessed by Java programmers or
Java users. In most Java implementations, when Java code arrives at the VM and is
formed into a Class by the Class Loader, the Verifier automatically examines it. The
Verifier checks byte code at a number of different levels. The simplest test makes sure
that the format of a code fragment is correct. If the Verifier discovers a problem with a
class file, it throws an exception, loading ceases, and the class file never executes. The
verification process, in concert with the security features built into the language and
checked at runtime, helps to establish a base set of security guarantees. The Verifier also
ensures that class files that refer to each other preserve binary compatibility. There are
rules of compatibility that govern the ability to change use of classes and methods
without breaking binary compatibility. For example, it is okay to add a method to a class
that is used by other classes, but not okay to delete methods from a class used by other
classes. The Verifier enforces compatibility rules. Once byte code passes through
verification, the following things are guaranteed:





The class file has the correct format
Stacks will not be overflowed or under flowed
Byte code instructions all have parameters of the correct type.
No illegal data conversions (casts) occur
Private, public, protected, and default accesses are legal
The Verifier acts as the primary gatekeeper in the Java security model. It ensures that
each piece of byte code downloaded from the outside plays by the rules. That way, the
19
Java VM can safely execute byte code that may not have been created by a Java
compiler. When the Verifier finds a problem in a class, it rejects the malformed class and
throws an exception. This is obviously a much more reasonable behavior than running
buggy or malicious code that crashes the VM.
All Java objects belong to classes. Class loaders determine when and how classes can be
added to a running Java environment. Part of their job is to make sure that important parts
of the Java runtime environment are not replaced by impostor code. Class loaders
perform two functions. First, when the VM needs to load the byte code for a particular
class, it asks a class loader to find the byte code. Each class loader can use its own
method for finding requested byte code files: It can load them from the local disk, fetch
them across the Net using any protocol, or it can just create the byte code on the spot.
This flexibility is not a security problem as long as the party who wrote the code that is
being loaded trusts the class loader. Second, class loaders define the namespaces seen by
different classes and how those namespaces relate to each other. Namespace is a set of
unique names of classes loaded by a particular Class Loader and a binding of each name
to a specific class object. Applet Class Loaders, which are typically supplied by the
browser vendor, load all applets and the classes they reference, usually getting the classes
from HTTP servers. When an applet loads across the network, its Applet Class Loader
receives the binary data and instantiates it as a new class. Under normal operation,
applets are forbidden to install a new Class Loader
Summary
Each Java class begins as source code. This is then compiled into byte code and
distributed to machines anywhere on the Net. A Java-enabled browser automatically
downloads a class when it encounters the <APPLET> tag in an HTML document. The
Verifier examines the byte code of a class file to ensure that it follows Java's strict safety
rules. The Java VM interprets byte code declared safe by the Verifier. The Java
specification allows classes to be unloaded when they are no longer needed, but few
current Java implementations unload classes.
Java's ability to dynamically load classes into a running Java environment is fraught with
security risks. The class-loading mechanisms mitigate these risks by providing separate
namespaces set up according to where mobile code originates. This capability ensures
that essential Java classes cannot be spoofed (replaced) by external, untrusted code. The
Applet Class Loader in particular is a key piece of the Java security model.
7.2 Security Manager
The third part of the base Java security model is the Security Manager. This part of the
security model restricts the ways an applet uses visible interfaces (Java API calls). The
Security Manager implements a good portion of the entire security model and is the part
of the security model most often encountered (in terms of a SecurityException) by Java
applet developers.
20
The job of the Security Manager is to keep track of who is allowed to do which
dangerous operations. A standard Security Manager will disallow most operations when
they are requested by untrusted code, and will allow trusted code to do whatever it wants.
The Security Manager is a single Java object that performs runtime checks on dangerous
methods. Code in the Java library consults the Security Manager whenever a potentially
dangerous operation is attempted. The Security Manager can veto the operation by
generating a SecurityException. Decisions made by the Security Manager take into
account the origin of the requesting class. Obviously, built-in classes are usually given
more privilege than classes loaded across the Net. The Security Manager makes the final
decision as to whether a particular operation is permitted or rejected. The Java API
provides all calls necessary to interface to the operating system, thus making isolation of
all required security checks possible within the API. When a dangerous call is made to
the Java library, the library queries the Security Manager. These queries use a set of
methods that check access.
Each VM can have only one Security Manager installed at a time, and once a Security
Manager has been installed it cannot be uninstalled (except by restarting the VM). Javaenabled applications such as Web browsers install a Security Manager as part of their
initialization, thus locking in the Security Manager before any potentially untrusted code
has a chance to run.
Source : www.securingjava.com
7.3 What the Security Manager Is Set Up to Do for Untrusted Applets
The Security Manager has the following duties:



Prevent installation of new class loaders. The job of class loaders is to keep the
namespaces properly organized. Because security checks are requested by classes
in the Java library, applets must be prevented from spoofing the library classes.
Protect threads and thread groups from each other.
Control the execution of other application programs.
21






Control the ability to shut down the VM.
Control access to other application processes.
Control access to system resources such as print queues, clipboards, event queues,
system properties, and windows.
Control file system operations such as read, write, and delete. Access to local files
is strictly controlled.
Control network socket operations such as connect and accept.
Control access to Java packages (or groups of classes), including access to
security enforcement classes.
22