Download to read offline
![most cases. (In fact, we have so far not encountered a situation where a new method must be created.) • Extension of security checks to all Java programs, including applications as well as applets. There is no longer a built-in concept that all local code is trusted. Instead, local code (e.g., non-system code, application packages installed on the local file system) is subjected to the same security control as applets, although it is possible, if desired, to declare that the policy on local code (or remote code) be the most liberal, thus enabling such code to effectively run as totally trusted. The same principle applies to signed applets and any Java application. Finally, an implicit goal is to make internal adjustment to the design of security classes (including the SecurityManager and ClassLoader classes) to reduce the risks of creating subtle security holes in future programming. Protection Mechanisms – Overview of Basic Concepts We now go over, in some detail, the new protection architecture and give a brief explanation of its functionality. We start with an overview of the basic concepts behind the new architecture. We then introduce the major new classes in a natural order, starting with permission specifications, going on to the policy and related features, followed by access control and its usage, and then covering secure class loading and resolution. A fundamental concept and important building block of system security is the protection domain [Saltzer and Schroeder 75]. A domain can be scoped by the set of objects that are currently directly accessible by a principal, where a principal is an entity in the computer system to which permissions (and as a result, accountability) are granted. The sandbox utilized in JDK 1.0 is one example of a protection domain with a fixed boundary. The protection domain concept serves as a convenient mechanism for grouping and isolation between units of protection. For example, it is possible (but not yet provided as a built-in feature) to separate protection domains from interacting with each other so that any permitted interaction must be either through trusted system code or explicitly allowed by the domains concerned. Note that existing object accessibility rules remain valid under the new security architecture. Protection domains generally fall into two distinct categories: system domain and application domain. It is important that all protected external resources, such as the file system, the networking facility, and the screen and keyboard, be accessible only via system domains. Figure 1-8 illustrates the domain composition of a Java application environment. Figure 1-8 Domain Composition of a Java Application Environment system domain net I/O file I/O printer AWT App-1 App-2 App-n A domain conceptually encloses a set of classes whose instances are granted the same set of permissions. Protection domains are determined by the policy currently in effect. The Java application environment maintains a mapping from code (classes and instances) to their protection domains and then to their permissions, as illustrated in Figure 1-9. Chapter 1 Java SE Platform Security Architecture 1-23](https://image.slidesharecdn.com/18877224-250613072121-3ea25907/75/Java-Platform-Standard-Edition-Security-Developers-Guide-17th-Edition-Oracle-48-2048.jpg)
Java Platform Standard Edition Security Developers Guide 17th Edition Oracle
- 1. Java Platform StandardEdition Security Developers Guide 17th Edition Oracle download https://ebookbell.com/product/java-platform-standard-edition- security-developers-guide-17th-edition-oracle-37754448 Explore and download more ebooks at ebookbell.com
- 2. Here are somerecommended products that we believe you will be interested in. You can click the link to download. A Guide To Programming In Java Java 2 Platform Standard Edition 5 5th Fifth Edition Beth Brown https://ebookbell.com/product/a-guide-to-programming-in-java- java-2-platform-standard-edition-5-5th-fifth-edition-beth- brown-5060274 Enterprise Social For The Java Platform Shares Mashups Likes 1st Edition Werner Keil https://ebookbell.com/product/enterprise-social-for-the-java-platform- shares-mashups-likes-1st-edition-werner-keil-53558284 Jboss Weld Cdi For Java Platform Ken Finnigan https://ebookbell.com/product/jboss-weld-cdi-for-java-platform-ken- finnigan-5497412 Realtime Java Platform Programming 1st Peter C Dibble https://ebookbell.com/product/realtime-java-platform-programming-1st- peter-c-dibble-975086
- 3. Component Development ForThe Java Platform 1st Edition Stuart Dabbs Halloway https://ebookbell.com/product/component-development-for-the-java- platform-1st-edition-stuart-dabbs-halloway-1831254 Scjp Sun Certified Programmer For Java Platform Study Guide Se6 Exam Cx310065 1st Edition Richard F Raposa https://ebookbell.com/product/scjp-sun-certified-programmer-for-java- platform-study-guide-se6-exam-cx310065-1st-edition-richard-f- raposa-2177554 The Definitive Guide To Jython Python For The Java Platform Description Based On Print Version Record Covers Jython 25cover Includes Index Juneau https://ebookbell.com/product/the-definitive-guide-to-jython-python- for-the-java-platform-description-based-on-print-version-record- covers-jython-25cover-includes-index-juneau-22003002 Numeric Computation And Statistical Data Analysis On The Java Platform 1st Edition Sergei V Chekanov Auth https://ebookbell.com/product/numeric-computation-and-statistical- data-analysis-on-the-java-platform-1st-edition-sergei-v-chekanov- auth-5483326 Openjdk Cookbook Over 80 Recipes To Build And Extend Your Very Own Version Of Java Platform Using Openjdk Project Alex Kasko https://ebookbell.com/product/openjdk-cookbook-over-80-recipes-to- build-and-extend-your-very-own-version-of-java-platform-using-openjdk- project-alex-kasko-23131188
- 5. Java Platform, StandardEdition Security Developer’s Guide Release 17 F40863-01 September 2021
- 6. Java Platform, StandardEdition Security Developer’s Guide, Release 17 F40863-01 Copyright © 1993, 2021, Oracle and/or its affiliates. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract. The terms governing the U.S. Government’s use of Oracle cloud services are defined by the applicable contract for such services. No other rights are granted to the U.S. Government. This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications. Oracle, Java, and MySQL are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Intel and Intel Inside are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Epyc, and the AMD logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.
- 7. Contents Preface Audience xx Documentation Accessibilityxx Diversity and Inclusion xx Related Documents xx Conventions xxi 1 General Security Terms and Definitions 1-1 Java Security Overview 1-4 Introduction to Java Security 1-4 Java Language Security and Bytecode Verification 1-5 Basic Security Architecture 1-6 Security Providers 1-6 Java Cryptography 1-8 Public Key Infrastructure 1-9 Key and Certificate Storage 1-9 Public Key Infrastructure Tools 1-10 Authentication 1-11 Secure Communication 1-12 TLS and DTLS Protocols 1-12 Simple Authentication and Security Layer (SASL) 1-13 Generic Security Service API and Kerberos 1-13 Access Control 1-14 Permissions 1-14 Security Policy 1-15 Access Control Enforcement 1-15 XML Signature 1-18 Java API for XML Processing (JAXP) 1-18 Security Tools Summary 1-18 Built-In Providers 1-19 Java SE Platform Security Architecture 1-19 iii
- 8. Introduction 1-19 The OriginalSandbox Model 1-20 Evolving the Sandbox Model 1-21 Protection Mechanisms – Overview of Basic Concepts 1-23 Permissions and Security Policy 1-25 The Permission Classes 1-25 java.security.CodeSource 1-35 java.security.Policy 1-35 java.security.GeneralSecurityException 1-47 Access Control Mechanisms and Algorithms 1-48 java.security.ProtectionDomain 1-48 java.security.AccessController 1-48 Inheritance of Access Control Context 1-53 java.security.AccessControlContext 1-54 Secure Class Loading 1-55 Class Loader Class Hierarchies 1-56 The Primordial Class Loader 1-56 Class Loader Delegation 1-57 Class Resolution Algorithm 1-57 Security Management 1-58 Managing Applets and Applications 1-58 SecurityManager versus AccessController 1-59 Auxiliary Tools 1-59 GuardedObject and SignedObject 1-61 java.security.GuardedObject and java.security.Guard 1-61 java.security.SignedObject 1-62 Discussion and Future Directions 1-63 Resource Consumption Management 1-63 Arbitrary Grouping of Permissions 1-63 Object-Level Protection 1-63 Subdividing Protection Domains 1-64 Running Applets with Signed Content 1-64 Appendix A: API for Privileged Blocks 1-65 Using the doPrivileged API 1-65 What It Means to Have Privileged Code 1-70 Reflection 1-71 Appendix B: Acknowledgments 1-72 Appendix C: References 1-72 Standard Algorithm Names 1-73 Permissions in the JDK 1-73 Permission Descriptions and Risks 1-74 iv
- 9. Methods and thePermissions They Require 1-75 java.lang.SecurityManager Method Permission Checks 1-101 JDK Supported Permissions 1-106 Default Policy Implementation and Policy File Syntax 1-106 Default Policy Implementation 1-107 Default Policy File Locations 1-107 Modifying the Policy Implementation 1-109 Policy File Syntax 1-109 Policy File Examples 1-115 Property Expansion in Policy Files 1-117 Windows Systems, File Paths, and Property Expansion 1-119 General Expansion in Policy Files 1-120 Appendix A: FilePermission Path Name Canonicalization Disabled By Default 1-122 Troubleshooting Security 1-124 2 Java Cryptography Architecture (JCA) Reference Guide Introduction to Java Cryptography Architecture 2-1 JCA Design Principles 2-2 Provider Architecture 2-3 Cryptographic Service Providers 2-3 How Providers Are Actually Implemented 2-5 Keystores 2-6 Engine Classes and Algorithms 2-7 Core Classes and Interfaces 2-8 The Provider Class 2-9 How Provider Implementations Are Requested and Supplied 2-10 Installing Providers 2-12 Provider Class Methods 2-12 The Security Class 2-12 Managing Providers 2-14 Security Properties 2-15 The SecureRandom Class 2-15 Creating a SecureRandom Object 2-16 Seeding or Re-Seeding the SecureRandom Object 2-16 Using a SecureRandom Object 2-17 Generating Seed Bytes 2-17 The MessageDigest Class 2-17 Creating a MessageDigest Object 2-17 Updating a Message Digest Object 2-18 Computing the Digest 2-18 v
- 10. The Signature Class2-18 Signature Object States 2-19 Creating a Signature Object 2-20 Initializing a Signature Object 2-20 Signing with a Signature Object 2-20 Verifying with a Signature Object 2-21 The Cipher Class 2-21 Other Cipher-based Classes 2-30 The Cipher Stream Classes 2-30 The SealedObject Class 2-33 The Mac Class 2-34 Key Interfaces 2-36 The KeyPair Class 2-37 Key Specification Interfaces and Classes 2-37 The KeySpec Interface 2-38 The KeySpec Subinterfaces 2-38 The EncodedKeySpec Class 2-39 Generators and Factories 2-39 The KeyFactory Class 2-40 The SecretKeyFactory Class 2-41 The KeyPairGenerator Class 2-43 The KeyGenerator Class 2-45 The KeyAgreement Class 2-46 Key Management 2-48 The KeyStore Class 2-50 Algorithm Parameters Classes 2-53 The AlgorithmParameterSpec Interface 2-53 The AlgorithmParameters Class 2-54 The AlgorithmParameterGenerator Class 2-56 The CertificateFactory Class 2-57 How the JCA Might Be Used in a SSL/TLS Implementation 2-58 Cryptographic Strength Configuration 2-60 Jurisdiction Policy File Format 2-63 How to Make Applications Exempt from Cryptographic Restrictions 2-65 Standard Names 2-69 Packaging Your Application 2-70 Additional JCA Code Samples 2-70 Computing a MessageDigest Object 2-71 Generating a Pair of Keys 2-72 Generating and Verifying a Signature Using Generated Keys 2-73 Generating/Verifying Signatures Using Key Specifications and KeyFactory 2-74 vi
- 11. Generating Random Numbers2-76 Determining If Two Keys Are Equal 2-77 Reading Base64-Encoded Certificates 2-78 Parsing a Certificate Reply 2-78 Using Encryption 2-79 Using Password-Based Encryption 2-80 Sample Programs for Diffie-Hellman Key Exchange, AES/GCM, and HMAC-SHA256 2-81 Diffie-Hellman Key Exchange between Two Parties 2-81 Diffie-Hellman Key Exchange between Three Parties 2-85 AES/GCM Example 2-87 HMAC-SHA256 Example 2-88 3 How to Implement a Provider in the Java Cryptography Architecture Who Should Read This Document 3-1 Notes on Terminology 3-1 Introduction to Implementing Providers 3-1 Engine Classes and Corresponding Service Provider Interface Classes 3-2 Steps to Implement and Integrate a Provider 3-5 Step 1: Write your Service Implementation Code 3-5 Step 1.1: Consider Additional JCA Provider Requirements and Recommendations for Encryption Implementations 3-6 Step 2: Give your Provider a Name 3-7 Step 3: Write Your Master Class, a Subclass of Provider 3-7 Step 3.1: Create a Provider That Uses String Objects to Register Its Services 3-8 Step 3.2: Create a Provider That Uses Provider.Service 3-10 Step 3.3: Specify Additional Information for Cipher Implementations 3-12 Step 4: Create a Module Declaration for Your Provider 3-14 Step 5: Compile Your Code 3-15 Step 6: Place Your Provider in a JAR File 3-15 Step 7: Sign Your JAR File, If Necessary 3-16 Step 7.1: Get a Code-Signing Certificate 3-16 Step 7.2: Sign Your Provider 3-18 Step 8: Prepare for Testing 3-19 Step 8.1: Configure the Provider 3-19 Step 8.2: Set Provider Permissions 3-21 Step 9: Write and Compile Your Test Programs 3-22 Step 10: Run Your Test Programs 3-22 Step 11: Apply for U.S. Government Export Approval If Required 3-24 Step 12: Document Your Provider and Its Supported Services 3-25 Step 12.1: Indicate Whether Your Implementation is Cloneable for Message Digests and MACs 3-26 vii
- 12. Step 13: MakeYour Class Files and Documentation Available to Clients 3-27 Further Implementation Details and Requirements 3-27 Alias Names 3-28 Service Interdependencies 3-29 Default Initialization 3-31 Default Key Pair Generator Parameter Requirements 3-31 The Provider.Service Class 3-31 Signature Formats 3-33 DSA Interfaces and their Required Implementations 3-33 RSA Interfaces and their Required Implementations 3-35 Diffie-Hellman Interfaces and their Required Implementations 3-37 Interfaces for Other Algorithm Types 3-39 Algorithm Parameter Specification Interfaces and Classes 3-39 Key Specification Interfaces and Classes Required by Key Factories 3-42 Secret-Key Generation 3-47 Adding New Object Identifiers 3-48 Ensuring Exportability 3-49 Sample Code for MyProvider 3-50 4 JDK Providers Documentation Introduction to JDK Providers 4-1 Import Limits on Cryptographic Algorithms 4-2 Cipher Transformations 4-3 SecureRandom Implementations 4-3 The SunPKCS11 Provider 4-4 The SUN Provider 4-4 The SunRsaSign Provider 4-9 The SunJSSE Provider 4-10 The SunJCE Provider 4-17 The SunJGSS Provider 4-24 The SunSASL Provider 4-24 The XMLDSig Provider 4-24 The SunPCSC Provider 4-25 The SunMSCAPI Provider 4-26 The SunEC Provider 4-27 The Apple Provider 4-30 The JdkLDAP Provider 4-30 The JdkSASL Provider 4-30 viii
- 13. 5 PKCS#11 ReferenceGuide SunPKCS11 Provider 5-1 SunPKCS11 Requirements 5-2 SunPKCS11 Configuration 5-2 Accessing Network Security Services (NSS) 5-15 Troubleshooting PKCS#11 5-17 Disabling PKCS#11 Providers and/or Individual PKCS#11 Mechanisms 5-18 Application Developers 5-19 Token Login 5-19 Token Keys 5-20 Delayed Provider Selection 5-21 JAAS KeyStoreLoginModule 5-22 Tokens as JSSE Keystore and Trust Stores 5-23 Using keytool and jarsigner with PKCS#11 Tokens 5-23 Keystore Entry Syntax in Policy File 5-25 Provider Developers 5-25 Provider Services 5-26 Parameter Support 5-27 SunPKCS11 Provider Supported Algorithms 5-27 SunPKCS11 Provider KeyStore Requirements 5-32 Example Provider 5-34 6 Java Authentication and Authorization Service (JAAS) Java Authentication and Authorization Service (JAAS) Reference Guide 6-1 Who Should Read This Document 6-2 Related Documentation 6-2 Core Classes and Interfaces 6-2 Common Classes 6-2 Authentication Classes and Interfaces 6-8 Authorization Classes 6-11 JAAS Tutorials and Sample Programs 6-12 Appendix A: JAAS Settings in the java.security Security Properties File 6-13 Login Configuration Provider 6-14 Login Configuration URLs 6-14 Policy Provider 6-15 Policy File URLs 6-15 Appendix B: JAAS Login Configuration File 6-16 Login Configuration File Structure and Contents 6-16 Where to Specify Which Login Configuration File Should Be Used 6-18 JAAS Tutorials 6-19 ix
- 14. JAAS Authentication Tutorial6-19 The Authentication Tutorial Code 6-20 The Login Configuration 6-35 Running the Code 6-36 Running the Code with a Security Manager 6-37 JAAS Authorization Tutorial 6-41 What is JAAS Authorization? 6-41 How is JAAS Authorization Performed? 6-42 The Authorization Tutorial Code 6-44 The Login Configuration File for the JAAS Authorization Tutorial 6-49 The Policy File 6-49 Running the Authorization Tutorial Code 6-51 Java Authentication and Authorization Service (JAAS): LoginModule Developer's Guide 6-54 Introduction to LoginModule 6-55 Steps to Implement a LoginModule 6-56 Step 1: Understand the Authentication Technology 6-56 Step 2: Name the LoginModule Implementation 6-56 Step 3: Implement the LoginModule Interface 6-57 Step 4: Choose or Write a Sample Application 6-61 Step 5: Compile the LoginModule and Application 6-61 Step 6: Prepare for Testing 6-61 Step 7: Test Use of the LoginModule 6-63 Step 8: Document Your LoginModule Implementation 6-64 Step 9: Make LoginModule JAR File and Documents Available 6-64 7 Java Generic Security Services (Java GSS-API) Introduction to JAAS and Java GSS-API Tutorials 7-1 When to Use Java GSS-API Versus JSSE 7-2 Use of Java GSS-API for Secure Message Exchanges Without JAAS Programming 7-3 Overview of the Client and Server Applications 7-4 The SampleClient and SampleServer Code 7-5 Kerberos User and Service Principal Names 7-18 The Login Configuration File 7-20 The useSubjectCredsOnly System Property 7-21 Running the SampleClient and SampleServer Programs 7-21 JAAS Authentication 7-24 The Authentication Tutorial Code 7-25 The Login Configuration 7-27 Running the Code 7-27 Running the Code with a Security Manager 7-29 x
- 15. JAAS Authorization 7-31 Whatis JAAS Authorization? 7-32 How Is JAAS Authorization Performed? 7-32 The Authorization Tutorial Code 7-34 The Login Configuration File 7-36 The Policy File 7-36 Running the Authorization Tutorial Code 7-37 Use of JAAS Login Utility 7-39 What You Need to Know About the Login Utility 7-40 Application and Other File Requirements 7-40 The Sample Application Program 7-41 The Login Configuration File 7-42 The Policy File 7-42 Running the Sample Program with the Login Utility 7-43 Use of JAAS Login Utility and Java GSS-API for Secure Message Exchanges 7-46 Before You Start: Recommended Reading 7-46 Overview of the Client and Server Applications 7-47 Kerberos User and Service Principal Names 7-48 The Login Configuration File 7-49 The Policy Files 7-51 Running the SampleClient and SampleServer Programs 7-54 More Things You Can Do with Java GSS-API and JAAS 7-58 Executing Code on Behalf of the Client User 7-59 Using Credentials Delegated from the Client 7-65 Permission Required In Order to Delegate Credentials 7-66 Kerberos Requirements 7-66 Setting Properties to Indicate the Default Realm and KDC 7-67 Locating the krb5.conf Configuration File 7-67 Naming Conventions for Realm Names and Hostnames 7-68 Cross-Realm Authentication 7-68 Troubleshooting 7-69 Source Code for JAAS and Java GSS-API Tutorials 7-72 Related Documentation 7-94 Accessing Native GSS-API 7-94 Single Sign-on Using Kerberos in Java 7-98 Abstract 7-98 Introduction 7-98 Kerberos V5 7-99 Java Authentication and Authorization Service (JAAS) 7-99 Pluggable and Stackable Framework 7-99 Authentication and Authorization 7-99 xi
- 16. Subject 7-100 doAs anddoAsPrivileged 7-100 LoginContext 7-101 Callbacks 7-102 LoginModules 7-102 The Kerberos Login Module 7-102 Kerberos Classes 7-104 Authorization 7-104 Java Generic Security Service Application Program Interface (Java GSS-API) 7-104 Generic Security Service API (GSS-API) 7-104 Java GSS-API 7-105 The GSSName Interface 7-106 The GSSCredential Interface 7-107 The GSSContext Interface 7-108 Message Protection 7-111 Credential Delegation 7-112 Default Credential Acquisition Model 7-114 Exceptions to the Model 7-115 Security Risks 7-116 Credential Acquisition 7-117 Context Establishment 7-117 Credential Delegation 7-118 Conclusions 7-118 Acknowledgements 7-118 References 7-119 Advanced Security Programming in Java SE Authentication, Secure Communication and Single Sign-On 7-119 Part I : Secure Authentication using the Java Authentication and Authorization Service (JAAS) 7-120 Exercise 1: Using the JAAS API 7-120 Exercise 2: Configuring JAAS for Kerberos Authentication 7-122 Part II : Secure Communications using the Java SE Security API 7-123 Exercise 3: Using the Java Generic Security Service (GSS) API 7-124 Exercise 4: Using the Java SASL API 7-126 Exercise 5: Using the Java Secure Socket Extension with Kerberos 7-129 Part III : Deploying for Single Sign-On in a Kerberos Environment 7-131 Exercise 6: Deploying for Single Sign-On 7-131 Part IV : Secure Communications Using Stronger Encryption Algorithms 7-132 Exercise 7: Configuring to Use Stronger Encryption Algorithms in a Kerberos Environment, to Secure the Communication 7-132 Part V : Secure Authentication Using SPNEGO Java GSS Mechanism 7-134 Exercise 8: Using the Java Generic Security Services (GSS) API with SPNEGO 7-134 xii
- 17. Part VI: HTTP/SPNEGOAuthentication 7-136 Exercise 9: Using HTTP/SPNEGO Authentication 7-136 Source Code for Advanced Security Programming in Java SE Authentication, Secure Communication and Single Sign-On 7-141 Appendix A: Setting up Kerberos Accounts 7-175 The Kerberos 5 GSS-API Mechanism 7-175 8 Java Secure Socket Extension (JSSE) Reference Guide Introduction to JSSE 8-1 JSSE Features and Benefits 8-2 JSSE Standard API 8-2 SunJSSE Provider 8-3 JSSE Related Documentation 8-3 JSSE Classes and Interfaces 8-4 JSSE Core Classes and Interfaces 8-5 SocketFactory and ServerSocketFactory Classes 8-5 SSLSocketFactory and SSLServerSocketFactory Classes 8-5 Obtaining an SSLSocketFactory 8-6 SSLSocket and SSLServerSocket Classes 8-6 Obtaining an SSLSocket 8-7 Cipher Suite Choice and Remote Entity Verification 8-7 SSLEngine Class 8-7 SSLEngine Methods 8-9 Understanding SSLEngine Operation Statuses 8-11 SSLEngine for TLS Protocols 8-16 SSLEngine for DTLS Protocols 8-22 Dealing With Blocking Tasks 8-30 Shutting Down a TLS/DTLS Connection 8-30 SSLSession and ExtendedSSLSession 8-31 HttpsURLConnection Class 8-32 Setting the Assigned SSLSocketFactory 8-32 Setting the Assigned HostnameVerifier 8-33 Support Classes and Interfaces 8-33 SSLContext Class 8-34 TrustManager Interface 8-36 TrustManagerFactory Class 8-36 X509TrustManager Interface 8-40 X509ExtendedTrustManager Class 8-43 KeyManager Interface 8-46 KeyManagerFactory Class 8-47 X509KeyManager Interface 8-48 xiii
- 18. X509ExtendedKeyManager Class 8-48 RelationshipBetween a TrustManager and a KeyManager 8-49 Secondary Support Classes and Interfaces 8-49 SSLParameters Class 8-49 SSLSessionContext Interface 8-50 SSLSessionBindingListener Interface 8-50 SSLSessionBindingEvent Class 8-51 HandShakeCompletedListener Interface 8-51 HandShakeCompletedEvent Class 8-51 HostnameVerifier Interface 8-51 X509Certificate Class 8-52 AlgorithmConstraints Interface 8-52 StandardConstants Class 8-52 SNIServerName Class 8-52 SNIMatcher Class 8-53 SNIHostName Class 8-53 Customizing JSSE 8-54 How to Specify a java.lang.System Property 8-64 How to Specify a java.security.Security Property 8-64 Customizing the X509Certificate Implementation 8-65 Specifying Default Enabled Cipher Suites 8-65 Specifying an Alternative HTTPS Protocol Implementation 8-66 Customizing the Provider Implementation 8-67 Registering the Cryptographic Provider Statically 8-67 Registering the Cryptographic Service Provider Dynamically 8-67 Provider Configuration 8-68 Configuring the Preferred Provider for Specific Algorithms 8-68 Customizing the Default Keystores and Truststores, Store Types, and Store Passwords 8-69 Customizing the Default Key Managers and Trust Managers 8-71 Disabled and Restricted Cryptographic Algorithms 8-72 Legacy Cryptographic Algorithms 8-73 Customizing the Encryption Algorithm Providers 8-74 Customizing Size of Ephemeral Diffie-Hellman Keys 8-74 Customizing Maximum Fragment Length Negotiation (MFLN) Extension 8-75 Configuring the Maximum and Minimum Packet Size 8-76 Limiting Amount of Data Algorithms May Encrypt with a Set of Keys 8-76 Resuming Session Without Server-Side State 8-77 Specifying That close_notify Alert Is Sent When One Is Received 8-77 Enabling certificate_authorities Extension for Server Certificate Selection 8-78 Client-Driven OCSP and OCSP Stapling 8-78 Client-Driven OCSP and Certificate Revocation 8-79 xiv
- 19. OCSP Stapling andCertificate Revocation 8-80 OCSP Stapling Configuration Properties 8-82 Configuring Default Extensions 8-84 Hardware Acceleration and Smartcard Support 8-84 Configuring JSSE to Use Smartcards as Keystores and Truststores 8-84 Multiple and Dynamic Keystores 8-85 Additional Keystore Formats (PKCS12) 8-86 Server Name Indication (SNI) Extension 8-86 TLS Application Layer Protocol Negotiation 8-88 Setting up ALPN on the Client 8-89 Setting up Default ALPN on the Server 8-90 Setting up Custom ALPN on the Server 8-91 Determining Negotiated ALPN Value during Handshaking 8-93 Reading and Writing ALPN Values with the SunJSSE Provider 8-97 ALPN Related Classes and Methods 8-99 Troubleshooting JSSE 8-99 Configuration Problems 8-100 SSLHandshakeException: No Available Authentication Scheme, Handshake Failure 8-100 CertificateException While Handshaking 8-101 Runtime Exception: SSL Service Not Available 8-101 Runtime Exception: "No available certificate corresponding to the SSL cipher suites which are enabled" 8-101 Runtime Exception: No Cipher Suites in Common 8-102 Socket Disconnected After Sending ClientHello Message 8-103 SunJSSE Cannot Find a JCA Provider That Supports a Required Algorithm and Causes a NoSuchAlgorithmException 8-104 Exception Thrown When Obtaining Application Resources from a Virtual Host Web Server that Requires an SNI Extension 8-104 IllegalArgumentException When RC4 Cipher Suites are Configured for DTLS 8-105 Debugging Utilities 8-105 Debugging TLS Connections 8-107 Compatibility Risks and Known Issues 8-125 Code Examples 8-126 Converting an Unsecure Socket to a Secure Socket 8-126 Running the JSSE Sample Code 8-128 Creating a Keystore to Use with JSSE 8-136 Using the Server Name Indication (SNI) Extension 8-141 Typical Client-Side Usage Examples 8-141 Typical Server-Side Usage Examples 8-141 Working with Virtual Infrastructures 8-142 Standard Names 8-147 xv
- 20. Provider Pluggability 8-147 JAXPSecurity Processing 8-147 Transport Layer Security (TLS) Protocol Overview 8-151 How TLS Works 8-152 Cryptographic Processes 8-152 Secret-Key Cryptography 8-153 Public-Key Cryptography 8-153 Comparison Between Secret-Key and Public-Key Cryptography 8-154 Public Key Certificates 8-154 Cryptographic Hash Functions 8-155 Message Authentication Code 8-155 Digital Signatures 8-155 The TLS 1.3 Handshake 8-155 The TLS 1.3 Protocol 8-156 Session Resumption with a Pre-Shared Key 8-160 Post-Handshake Messages 8-162 Compatibility Risks and Known Issues 8-163 The TLS 1.2 Handshake 8-163 The TLS 1.2 Protocol 8-164 Datagram Transport Layer Security (DTLS) Protocol 8-167 The DTLS Handshake 8-167 9 Java PKI Programmer's Guide PKI Programmer's Guide Overview 9-1 Introduction to Public Key Certificates 9-2 X.509 Certificates and Certificate Revocation Lists (CRLs) 9-3 Core Classes and Interfaces 9-6 Basic Certification Path Classes 9-7 The CertPath Class 9-8 The CertificateFactory Class 9-9 The CertPathParameters Interface 9-11 Certification Path Validation Classes 9-11 The CertPathValidator Class 9-11 The CertPathValidatorResult Interface 9-12 Certification Path Building Classes 9-13 The CertPathBuilder Class 9-13 The CertPathBuilderResult Interface 9-14 Certificate/CRL Storage Classes 9-15 The CertStore Class 9-15 The CertStoreParameters Interface 9-17 xvi
- 21. The CertSelector andCRLSelector Interfaces 9-17 PKIX Classes 9-23 The TrustAnchor Class 9-23 The PKIXParameters Class 9-24 The PKIXCertPathValidatorResult Class 9-27 The PolicyNode Interface and PolicyQualifierInfo Class 9-27 The PKIXBuilderParameters Class 9-29 The PKIXCertPathBuilderResult Class 9-30 The PKIXCertPathChecker Class 9-31 Using PKIXCertPathChecker in Certificate Path Validation 9-36 Implementing a Service Provider 9-41 Steps to Implement and Integrate a Provider 9-41 Service Interdependencies 9-43 Certification Path Parameter Specification Interfaces 9-44 Certification Path Result Specification Interfaces 9-44 Certification Path Exception Classes 9-45 Appendix A: Standard Names 9-45 Appendix B: CertPath Implementation in SUN Provider 9-45 Appendix C: OCSP Support 9-48 Appendix D: CertPath Implementation in JdkLDAP Provider 9-51 Appendix E: Disabling Cryptographic Algorithms 9-52 10 Java SASL API Programming and Deployment Guide Java SASL API Overview 10-2 Creating the Mechanisms 10-2 Passing Input to the Mechanisms 10-3 Using the Mechanisms 10-3 Using the Negotiated Security Layer 10-5 How SASL Mechanisms are Installed and Selected 10-6 The SunSASL Provider 10-7 The SunSASL Provider Client Mechanisms 10-7 The SunSASL Provider Server Mechanisms 10-12 The JdkSASL Provider 10-14 The JdkSASL Provider Client Mechanism 10-14 The JdkSASL Provider Server Mechanism 10-15 Debugging and Monitoring 10-16 Implementing a SASL Security Provider 10-17 xvii
- 22. 11 XML DigitalSignature API Overview and Tutorial Package Hierarchy 11-1 Service Providers 11-2 Introduction to XML Signatures 11-3 Example of an XML Signature 11-3 XML Signature Secure Validation Mode 11-5 XML Digital Signature API Examples 11-5 Validate Example 11-5 Validating an XML Signature 11-9 Instantiating the Document that Contains the Signature 11-9 Specifying the Signature Element to be Validated 11-10 Creating a Validation Context 11-10 Unmarshalling the XML Signature 11-10 Validating the XML Signature 11-11 Using KeySelectors 11-11 GenEnveloped Example 11-13 Generating an XML Signature 11-16 Instantiating the Document to be Signed 11-17 Creating a Public Key Pair 11-17 Creating a Signing Context 11-17 Assembling the XML Signature 11-17 Generating the XML Signature 11-19 Printing or Displaying the Resulting Document 11-19 12 Java API for XML Processing (JAXP) Security Guide Potential Attacks During XML Processing 12-1 XML External Entity Injection Attack 12-1 External Resources Supported by XML, Schema, and XSLT Standards 12-1 Exponential Entity Expansion Attack 12-3 Feature for Secure Processing (FSP) 12-3 JAXP Properties for Processing Limits 12-4 JAXP Properties for External Access Restrictions 12-8 Scope and Order 12-10 Relationship with Security Manager 12-11 When to Use Processing Limits 12-11 When to Use External Access Restrictions 12-13 Using JAXP Properties 12-13 Handling Errors from JAXP Properties 12-16 Streaming API for XML and JAXP Properties 12-18 Extension Functions 12-18 xviii
- 23. Disabling DTD Processing12-19 Using Resolvers and Catalogs 12-20 Java XML Resolvers 12-20 Entity Resolvers for SAX and DOM 12-20 XMLResolver for StAX 12-21 URIResolver for javax.xml.transform 12-21 LSResourceResolver for javax.xml.validation 12-21 The Catalog API 12-22 Catalog Resolver 12-22 Enable Catalogs on JDK XML Processors 12-22 Third-Party Parsers 12-23 General Recommendations for JAXP Security 12-24 Appendix A: Glossary of Java API for XML Processing Terms and Definitions 12-24 Appendix B: Java and JDK XML Features and Properties Naming Convention 12-25 13 Security API Specification 14 Related Security Topics xix
- 24. Preface This guide providesinformation about the Java security technology, tools, and implementations of commonly used security algorithms, mechanisms, and protocols on the Java Platform, Standard Edition (Java SE). Audience This document is intended for experienced developers who build applications using the comprehensive Java security framework. It is also intended for the user or administrator with a a set of tools to securely manage applications. Documentation Accessibility For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup? ctx=acc&id=docacc. Access to Oracle Support Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/ lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired. Diversity and Inclusion Oracle is fully committed to diversity and inclusion. Oracle respects and values having a diverse workforce that increases thought leadership and innovation. As part of our initiative to build a more inclusive culture that positively impacts our employees, customers, and partners, we are working to remove insensitive terms from our products and documentation. We are also mindful of the necessity to maintain compatibility with our customers' existing technologies and the need to ensure continuity of service as Oracle's offerings and industry standards evolve. Because of these technical constraints, our effort to remove insensitive terms is ongoing and will take time and external cooperation. Related Documents See JDK 17 Documentation. Preface xx
- 25. Conventions The following textconventions are used in this document: Convention Meaning boldface Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary. italic Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values. monospace Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter. Preface xxi
- 26. 1 General Security Terms andDefinitions list commonly used cryptography terms and their definitions. Java Security Overview provides an overview of the motivation of major security features, an introduction to security classes and their usage, a discussion of the impact of the security architecture on code, and thoughts on writing security-sensitive code. Java SE Platform Security Architecture gives an overview of the motivation of the major security features implemented for the JDK. Java Security Standard Algorithm Names Specification describes the set of standard names for algorithms, certificate and keystore types that Java SE requires and uses. Permissions in the JDK describes the built-in JDK permission types and discusses the risks of granting each permission. Troubleshooting Security lists options for the java.security.debug system property that enable you to monitor security access. Terms and Definitions The following are commonly used cryptography terms and their definitions. authentication The process of confirming the identity of a party with whom one is communicating. certificate A digitally signed statement vouching for the identity and public key of an entity (person, company, and so on). Certificates can either be self-signed or issued by a Certificate Authority (CA) an entity that is trusted to issue valid certificates for other entities. Well-known CAs include Comodo, Entrust, and GoDaddy. X509 is a common certificate format that can be managed by the JDK's keytool. cipher suite A combination of cryptographic parameters that define the security algorithms and key sizes used for authentication, key agreement, encryption, and integrity protection. cryptographic hash function An algorithm that is used to produce a relatively small fixed-size string of bits (called a hash) from an arbitrary block of data. A cryptographic hash function is similar to a checksum and has three primary characteristics: it’s a one-way function, meaning that it is not possible to produce the original data from the hash; a small change in the original data produces a large change in the resulting hash; and it doesn’t require a cryptographic key. Cryptographic Service Provider (CSP) Sometimes referred to simply as providers for short, the Java Cryptography Architecture (JCA) defines it as a package (or set of packages) that implements one or more engine classes for specific cryptographic algorithms. An engine class defines a cryptographic service in an abstract fashion without a concrete implementation. 1-1
- 27. Datagram Transport LayerSecurity (DTLS) Protocol A protocol that manages client and server authentication, data integrity, and encrypted communication between the client and server based on an unreliable transport channel such as UDP. decryption See encryption/decryption. digital signature A digital equivalent of a handwritten signature. It is used to ensure that data transmitted over a network was sent by whoever claims to have sent it and that the data has not been modified in transit. For example, an RSA-based digital signature is calculated by first computing a cryptographic hash of the data and then encrypting the hash with the sender's private key. encryption/decryption Encryption is the process of using a complex algorithm to convert an original message (cleartext) to an encoded message (ciphertext) that is unintelligible unless it is decrypted. Decryption is the inverse process of producing cleartext from ciphertext. The algorithms used to encrypt and decrypt data typically come in two categories: secret key (symmetric) cryptography and public key (asymmetric) cryptography. endpoint identification An IPv4 or IPv6 address used to identify an endpoint on the network. Endpoint identification procedures are handled during SSL/TLS handshake. handshake protocol The negotiation phase during which the two socket peers agree to use a new or existing session. The handshake protocol is a series of messages exchanged over the record protocol. At the end of the handshake, new connection-specific encryption and integrity protection keys are generated based on the key agreement secrets in the session. java-home Variable placeholder used throughout this document to refer to the directory where the Java Development Kit (JDK) is installed. key agreement A method by which two parties cooperate to establish a common key. Each side generates some data, which is exchanged. These two pieces of data are then combined to generate a key. Only those holding the proper private initialization data can obtain the final key. Diffie-Hellman (DH) is the most common example of a key agreement algorithm. key exchange A method by which keys are exchanged. One side generates a private key and encrypts it using the peer's public key (typically RSA). The data is transmitted to the peer, who decrypts the key using the corresponding private key. key manager/trust manager Key managers and trust managers use keystores for their key material. A key manager manages a keystore and supplies public keys to others as needed (for example, for use in authenticating the user to others). A trust manager decides who to trust based on information in the truststore it manages. Chapter 1 Terms and Definitions 1-2
- 28. Keyed-Hash Message Code(HMAC) A specific type of message authentication code that involves a cryptographic hash function and a secret cryptographic key. Keyed-Hash Message Code (HMAC)-based Extract-and-Expand Key Derivation Function (HKDF) A function used for key generation and validation. keystore/truststore A keystore is a database of key material. Key material is used for a variety of purposes, including authentication and data integrity. Various types of keystores are available, including PKCS12 and Oracle's JKS. Generally speaking, keystore information can be grouped into two categories: key entries and trusted certificate entries. A key entry consists of an entity's identity and its private key, and can be used for a variety of cryptographic purposes. In contrast, a trusted certificate entry contains only a public key in addition to the entity's identity. Thus, a trusted certificate entry can’t be used where a private key is required, such as in a javax.net.ssl.KeyManager. In the JDK implementation of JKS, a keystore may contain both key entries and trusted certificate entries. A truststore is a keystore that is used when making decisions about what to trust. If you receive data from an entity that you already trust, and if you can verify that the entity is the one that it claims to be, then you can assume that the data really came from that entity. An entry should only be added to a truststore if the user trusts that entity. By either generating a key pair or by importing a certificate, the user gives trust to that entry. Any entry in the truststore is considered a trusted entry. It may be useful to have two different keystore files: one containing just your key entries, and the other containing your trusted certificate entries, including CA certificates. The former contains private information, whereas the latter does not. Using two files instead of a single keystore file provides a cleaner separation of the logical distinction between your own certificates (and corresponding private keys) and others' certificates. To provide more protection for your private keys, store them in a keystore with restricted access, and provide the trusted certificates in a more publicly accessible keystore if needed. message authentication code (MAC) Provides a way to check the integrity of information transmitted over or stored in an unreliable medium, based on a secret key. Typically, MACs are used between two parties that share a secret key in order to validate information transmitted between these parties. A MAC mechanism that is based on cryptographic hash functions is referred to as HMAC. HMAC can be used with any cryptographic hash function, such as Message Digest 5 (MD5) and the Secure Hash Algorithm (SHA-256), in combination with a secret shared key. HMAC is specified in RFC 2104. public-key cryptography A cryptographic system that uses an encryption algorithm in which two keys are produced. One key is made public, whereas the other is kept private. The public key and the private key are cryptographic inverses; what one key encrypts only the other key can decrypt. Public-key cryptography is also called asymmetric cryptography. Record Protocol A protocol that packages all data (whether application-level or as part of the handshake process) into discrete records of data much like a TCP stream socket converts an application byte stream into network packets. The individual records are then protected by the current encryption and integrity protection keys. Chapter 1 Terms and Definitions 1-3
- 29. secret-key cryptography A cryptographicsystem that uses an encryption algorithm in which the same key is used both to encrypt and decrypt the data. Secret-key cryptography is also called symmetric cryptography. Secure Sockets Layer (SSL) Protocol A protocol that manages client and server authentication, data integrity, and encrypted communication between the client and server. SSL has been renamed to Transport Layer Security (TLS). session A named collection of state information including authenticated peer identity, cipher suite, and key agreement secrets that are negotiated through a secure socket handshake and that can be shared among multiple secure socket instances. Transport Layer Security (TLS) Protocol A protocol that manages client and server authentication, data integrity, and encrypted communication between the client and server based on a reliable transport channel such as TCP. trust manager See key manager/trust manager. truststore See keystore/truststore. Java Security Overview Java security includes a large set of APIs, tools, and implementations of commonly- used security algorithms, mechanisms, and protocols. The Java security APIs span a wide range of areas, including cryptography, public key infrastructure, secure communication, authentication, and access control. Java security technology provides the developer with a comprehensive security framework for writing applications, and also provides the user or administrator with a set of tools to securely manage applications. Introduction to Java Security The JDK is designed with a strong emphasis on security. At its core, the Java language itself is type-safe and provides automatic garbage collection, enhancing the robustness of application code. A secure class loading and verification mechanism ensures that only legitimate Java code is executed. The Java security architecture includes a large set of application programming interfaces (APIs), tools, and implementations of commonly-used security algorithms, mechanisms, and protocols. The Java security APIs span a wide range of areas. Cryptographic and public key infrastructure (PKI) interfaces provide the underlying basis for developing secure applications. Interfaces for performing authentication and access control enable applications to guard against unauthorized access to protected resources. The APIs allow for multiple interoperable implementations of algorithms and other security services. Services are implemented in providers, which are plugged into the JDK through a standard interface that makes it easy for applications to obtain security services without having to know anything about their implementations. This allows Chapter 1 Java Security Overview 1-4
- 30. developers to focuson how to integrate security into their applications, rather than on how to actually implement complex security mechanisms. The JDK includes a number of providers that implement a core set of security services. It also allows for additional custom providers to be installed. This enables developers to extend the platform with new security mechanisms. The JDK is divided into modules. Modules that contain security APIs include the following: Table 1-1 Modules That Contain Security APIs Module Description java.base Defines the foundational APIs of Java SE; contained packages include java.security, javax.crypto, javax.net.ssl, and javax.security.auth java.security.jgss Defines the Java binding of the IETF Generic Security Services API (GSS-API). This module also contains GSS-API mechanisms including Kerberos v5 and SPNEGO java.security.sasl Defines Java support for the IETF Simple Authentication and Security Layer (SASL). This module also contains SASL mechanisms including DIGEST-MD5, CRAM-MD5, and NTLM java.smartcardio Defines the Java Smart Card I/O API java.xml.crypto Defines the API for XML cryptography jdk.jartool Defines APIs for signing jar files jdk.security.auth Provides implementations of the javax.security.auth.* interfaces and various authentication modules jdk.security.jgss Defines Java extensions to the GSS-API and an implementation of the SASL GSS-API mechanism Java Language Security and Bytecode Verification The Java language is designed to be type-safe and easy to use. It provides automatic memory management, garbage collection, and range-checking on arrays. This reduces the overall programming burden placed on developers, leading to fewer subtle programming errors and to safer, more robust code. A compiler translates Java programs into a machine-independent bytecode representation. A bytecode verifier is invoked to ensure that only legitimate bytecodes are executed in the Java runtime. It checks that the bytecodes conform to the Java Language Specification and do not violate Java language rules or namespace restrictions. The verifier also checks for memory management violations, stack underflows or overflows, and illegal data typecasts. Once bytecodes have been verified, the Java runtime prepares them for execution. In addition, the Java language defines different access modifiers that can be assigned to Java classes, methods, and fields, enabling developers to restrict access to their class implementations as appropriate. The language defines four distinct access levels: • private: Most restrictive modifier; access is not allowed outside the particular class in which the private member (a method, for example) is defined. • protected: Allows access to any subclass or to other classes within the same package. Chapter 1 Java Security Overview 1-5
- 31. • Package-private: Ifnot specified, then this is the default access level; allows access to classes within the same package. • public: No longer guarantees that the element is accessible everywhere; accessibility depends upon whether the package containing that element is exported by its defining module and whether that module is readable by the module containing the code that is attempting to access it. Basic Security Architecture The JDK defines a set of APIs spanning major security areas, including cryptography, public key infrastructure, authentication, secure communication, and access control. The APIs allow developers to easily integrate security into their application code. The APIs are designed around the following principles: Implementation independence Applications do not need to implement security themselves. Rather, they can request security services from the JDK. Security services are implemented in providers (see the section Security Providers), which are plugged into the JDK via a standard interface. An application may rely on multiple independent providers for security functionality. Implementation interoperability Providers are interoperable across applications. Specifically, an application is not bound to a specific provider if it does not rely on default values from the provider. Algorithm extensibility The JDK includes a number of built-in providers that implement a basic set of security services that are widely used today. However, some applications may rely on emerging standards not yet implemented, or on proprietary services. The JDK supports the installation of custom providers that implement such services. Security Providers The java.security.Provider class encapsulates the notion of a security provider in the Java platform. It specifies the provider's name and lists the security services it implements. Multiple providers may be configured at the same time and are listed in order of preference. When a security service is requested, the highest priority provider that implements that service is selected. Applications rely on the relevant getInstance method to request a security service from an underlying provider. For example, message digest creation represents one type of service available from providers. To request an implementation of a specific message digest algorithm, call the method java.security.MessageDigest.getInstance. The following statement requests a SHA-256 message digest implementation without specifying a provider name: MessageDigest md = MessageDigest.getInstance("SHA-256"); The following figure illustrates how this statement obtains a SHA-256 message digest implementation. The providers are searched in preference order, and the Chapter 1 Java Security Overview 1-6
- 32. implementation from thefirst provider supplying that particular algorithm, ProviderB, is returned. Figure 1-1 Request SHA-256 Message Digest Implementation Without Specifying Provider Application 1. ProviderA MessageDigest SHA-384 SHA-512 2. ProviderB MessageDigest SHA-256 SHA-384 3. ProviderC MessageDigest SHA-256 SHA-512 Provider Framework MessageDigest.getInstance (”SHA-256”) SHA-256 MessageDigest from ProviderB You can optionally request an implementation from a specific provider by specifying the provider's name. The following statement requests a SHA-256 message digest implementation from a specific provider, ProviderC: MessageDigest md = MessageDigest.getInstance("SHA-256", "ProviderC"); The following figure illustrates how this statement requests a SHA-256 message digest implementation from a specific provider, ProviderC. In this case, the implementation from that provider is returned, even though a provider with a higher preference order, ProviderB, also supplies a SHA-256 implementation. Chapter 1 Java Security Overview 1-7
- 33. Figure 1-2 RequestSHA-256 Message Digest Implementation from Specific Provider Application 1. ProviderA MessageDigest SHA-384 SHA-512 2. ProviderB MessageDigest SHA-256 SHA-384 3. ProviderC MessageDigest SHA-256 SHA-512 Provider Framework MessageDigest.getInstance (”SHA-256”, “ProviderC”) SHA-256 MessageDigest from ProviderC For more information about cryptographic services, such as message digest algorithms, see the section Java Cryptography. Oracle's implementation of the Java platform includes a number of built-in default providers that implement a basic set of security services that can be used by applications. Note that other vendor implementations of the Java platform may include different sets of providers that encapsulate vendor-specific sets of security services. The term built-in default providers refers to the providers available in Oracle's implementation. Java Cryptography The Java cryptography architecture is a framework for accessing and developing cryptographic functionality for the Java platform. It includes APIs for a large variety of cryptographic services, including the following: • Message digest algorithms • Digital signature algorithms • Symmetric bulk and stream encryption • Asymmetric encryption • Password-based encryption (PBE) • Elliptic Curve Cryptography (ECC) • Key agreement algorithms • Key generators Chapter 1 Java Security Overview 1-8
- 34. • Message AuthenticationCodes (MACs) • Secure Random Number Generators For historical (export control) reasons, the cryptography APIs are organized into two distinct packages: • The java.security and java.security.* packages contains classes that are not subject to export controls (like Signature and MessageDigest) • The javax.crypto package contains classes that are subject to export controls (like Cipher and KeyAgreement) The cryptographic interfaces are provider-based, allowing for multiple and interoperable cryptography implementations. Some providers may perform cryptographic operations in software; others may perform the operations on a hardware token (for example, on a smart card device or on a hardware cryptographic accelerator). Providers that implement export- controlled services must be digitally signed by a certificate issued by the Oracle JCE Certificate Authority. The Java platform includes built-in providers for many of the most commonly used cryptographic algorithms, including the RSA, DSA, and ECDSA signature algorithms, the AES encryption algorithm, the SHA-2 message digest algorithms, and the Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithms. Most of the built-in providers implement cryptographic algorithms in Java code. The Java platform also includes a built-in provider that acts as a bridge to a native PKCS#11 (v2.x) token. This provider, named SunPKCS11, allows Java applications to seamlessly access cryptographic services located on PKCS#11-compliant tokens. On Windows, the Java platform includes a built-in provider that acts as a bridge to the native Microsoft CryptoAPI. This provider, named SunMSCAPI, allows Java applications to seamlessly access cryptographic services on Windows through the CryptoAPI. Public Key Infrastructure Public Key Infrastructure (PKI) is a term used for a framework that enables secure exchange of information based on public key cryptography. It allows identities (of people, organizations, etc.) to be bound to digital certificates and provides a means of verifying the authenticity of certificates. PKI encompasses keys, certificates, public key encryption, and trusted Certification Authorities (CAs) who generate and digitally sign certificates. The Java platform includes APIs and provider support for X.509 digital certificates and Certificate Revocation Lists (CRLs), as well as PKIX-compliant certification path building and validation. The classes related to PKI are located in the java.security and java.security.cert packages. Key and Certificate Storage The Java platform provides for long-term persistent storage of cryptographic keys and certificates via key and certificate stores. Specifically, the java.security.KeyStore class represents a key store, a secure repository of cryptographic keys and/or trusted certificates (to be used, for example, during certification path validation), and the java.security.cert.CertStore class represents a certificate store, a public and potentially vast repository of unrelated and typically untrusted certificates. A CertStore may also store CRLs. Chapter 1 Java Security Overview 1-9
- 35. KeyStore and CertStoreimplementations are distinguished by types. The Java platform includes the standard PKCS11 and PKCS12 key store types (whose implementations are compliant with the corresponding PKCS specifications from RSA Security). It also contains a proprietary file-based key store type called JKS (which stands for Java Key Store), and a type called DKS (Domain Key Store) which is a collection of keystores that are presented as a single logical keystore. The Java platform includes a special built-in key store, cacerts, that contains a number of certificates for well-known, trusted CAs. The keytool utility is able to list the certificates included in cacerts. See keytool in Java Development Kit Tool Specifications. The SunPKCS11 provider mentioned in the section Java Cryptography includes a PKCS11 KeyStore implementation. This means that keys and certificates residing in secure hardware (such as a smart card) can be accessed and used by Java applications via the KeyStore API. Note that smart card keys may not be permitted to leave the device. In such cases, the java.security.Key object returned by the KeyStore API may simply be a reference to the key (that is, it would not contain the actual key material). Such a Key object can only be used to perform cryptographic operations on the device where the actual key resides. The Java platform also includes an LDAP certificate store type (for accessing certificates stored in an LDAP directory), as well as an in-memory Collection certificate store type (for accessing certificates managed in a java.util.Collection object). Public Key Infrastructure Tools There are two built-in tools for working with keys, certificates, and key stores: • keytool creates and manages key stores. Use it to perform the following tasks: – Create public/private key pairs – Display, import, and export X.509 v1, v2, and v3 certificates stored as files – Create X.509 certificates – Issue certificate (PKCS#10) requests to be sent to CAs – Create certificates based on certificate requests – Import certificate replies (obtained from the CAs sent certificate requests) – Designate public key certificates as trusted – Accept a password and store it securely as a secret key • jarsigner signs JAR files and verifies signatures on signed JAR files. The Java ARchive (JAR) file format enables the bundling of multiple files into a single file. Typically, a JAR file contains the class files and auxiliary resources associated with applets and applications. To digitally sign code, perform the following: 1. Use keytool to generate or import appropriate keys and certificates into your key store (if they are not there already). 2. Use the jar tool to package the code in a JAR file. 3. Use the jarsigner tool (or the jdk.security.jarsigner API) to sign the JAR file. The jarsigner tool accesses a key store to find any keys and certificates needed to sign a JAR file or to verify the signature of a signed JAR file. Chapter 1 Java Security Overview 1-10
- 36. Note: jarsigner can optionallygenerate signatures that include a timestamp. Systems that verify JAR file signatures can check the timestamp and accept a JAR file that was signed while the signing certificate was valid rather than requiring the certificate to be current. (Certificates typically expire annually, and it is not reasonable to expect JAR file creators to re-sign deployed JAR files annually.) See keytool and jarsigner in Java Development Kit Tool Specifications. Authentication Authentication is the process of determining the identity of a user. In the context of the Java runtime environment, it is the process of identifying the user of an executing Java program. In certain cases, this process may rely on the services described in the section Java Cryptography. The Java platform provides APIs that enable an application to perform user authentication via pluggable login modules. Applications call into the LoginContext class (in the javax.security.auth.login package), which in turn references a configuration. The configuration specifies which login module (an implementation of the javax.security.auth.spi.LoginModule interface) is to be used to perform the actual authentication. Since applications solely talk to the standard LoginContext API, they can remain independent from the underlying plug-in modules. New or updated modules can be plugged in for an application without having to modify the application itself. The following figure illustrates the independence between applications and underlying login modules: Figure 1-3 Authentication Login Modules Plugging into the Authentication Framework Application Smartcard Kerberos Username/ Password Authentication Framework Configuration Chapter 1 Java Security Overview 1-11
- 37. It is importantto note that although login modules are pluggable components that can be configured into the Java platform, they are not plugged in via security providers. Therefore, they do not follow the provider searching model as described in the section Security Providers. Instead, as is shown in Figure 1-3, login modules are administered by their own unique configuration. The Java platform provides the following built-in login modules, all in the com.sun.security.auth.module package: • Krb5LoginModule for authentication using Kerberos protocols • JndiLoginModule for username/password authentication using LDAP or NIS databases • KeyStoreLoginModule for logging into any type of key store, including a PKCS#11 token key store Authentication can also be achieved during the process of establishing a secure communication channel between two peers. The Java platform provides implementations of a number of standard communication protocols, which are discussed in the section Secure Communication. Secure Communication The data that travels across a network can be accessed by someone who is not the intended recipient. When the data includes private information, such as passwords and credit card numbers, steps must be taken to make the data unintelligible to unauthorized parties. It is also important to ensure that you are sending the data to the appropriate party, and that the data has not been modified, either intentionally or unintentionally, during transport. Cryptography forms the basis required for secure communication; see the section Java Cryptography. The Java platform also provides API support and provider implementations for a number of standard secure communication protocols. TLS and DTLS Protocols Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols which provide a secure channel between two communication peers. TLS uses a combination of cryptographic processes by providing authentication, confidentiality and integrity properties for communication over a untrusted or potential hostile network. TLS runs over a reliable, stream-oriented transport channel, typically Transport Control Protocol (TCP). TLS is application protocol independent. Higher-level protocols, for example Hypertext Transfer Protocol (HTTP), can layer on top of TLS transparently. The Datagram Transport Layer Security (DTLS) protocols are based on the stream- oriented TLS protocols and are intended to provider similar security properties for datagram transport, like User Datagram Protocol (UDP), which does not provide reliable or in-order delivery of data. The JDK provides APIs and an implementation of the SSL, TLS, and DTLS protocols that includes functionality for data encryption, message integrity, and server and client authentication. Applications can use (D)TLS to provide for the secure passage of data between two peers over any application protocol, such as HTTP on top of TCP/IP. Chapter 1 Java Security Overview 1-12
- 38. The javax.net.ssl.SSLSocket classrepresents a network socket that encapsulates TLS support on top of a normal stream socket (java.net.Socket). Some applications might want to use alternate data transport abstractions (for example, New-I/O); the javax.net.ssl.SSLEngine class is available to produce and consume TLS/DTLS packets. The JDK also includes APIs that support the notion of pluggable (provider-based) key managers and trust managers. A key manager is encapsulated by the javax.net.ssl.KeyManager class, and manages the keys used to perform authentication. A trust manager is encapsulated by the TrustManager class (in the same package), and makes decisions about who to trust based on certificates in the key store it manages. The JDK includes a built-in provider that implements the SSL/TLS/DTLS protocols: • SSL 3.0 • TLS 1.0 • TLS 1.1 • TLS 1.2 • TLS 1.3 • DTLS 1.0 • DTLS 1.2 Simple Authentication and Security Layer (SASL) Simple Authentication and Security Layer (SASL) is an Internet standard that specifies a protocol for authentication and optional establishment of a security layer between client and server applications. SASL defines how authentication data is to be exchanged, but does not itself specify the contents of that data. It is a framework into which specific authentication mechanisms that specify the contents and semantics of the authentication data can fit. There are a number of standard SASL mechanisms defined by the Internet community for various security levels and deployment scenarios. The Java SASL API, which is in the java.security.sasl module, defines classes and interfaces for applications that use SASL mechanisms. It is defined to be mechanism-neutral; an application that uses the API need not be hardwired into using any particular SASL mechanism. Applications can select the mechanism to use based on desired security features. The API supports both client and server applications. The javax.security.sasl.Sasl class is used to create SaslClient and SaslServer objects. SASL mechanism implementations are supplied in provider packages. Each provider may support one or more SASL mechanisms and is registered and invoked via the standard provider architecture. The Java platform includes a built-in provider that implements the following SASL mechanisms: • CRAM-MD5, DIGEST-MD5, EXTERNAL, GSSAPI, NTLM, and PLAIN client mechanisms • CRAM-MD5, DIGEST-MD5, GSSAPI, and NTLM server mechanisms Generic Security Service API and Kerberos The Java platform contains an API with the Java language bindings for the Generic Security Service Application Programming Interface (GSS-API), which is in the java.security.jgss module. Chapter 1 Java Security Overview 1-13
- 39. GSS-API offers applicationprogrammers uniform access to security services atop a variety of underlying security mechanisms. The Java GSS-API currently requires use of a Kerberos v5 mechanism, and the Java platform includes a built-in implementation of this mechanism. At this time, it is not possible to plug in additional mechanisms. Note: The Krb5LoginModule mentioned in the section Authentication can be used in conjunction with the GSS Kerberos mechanism. The Java platform also includes a built-in implementation of the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) GSS-API mechanism. Before two applications can use GSS-API to securely exchange messages between them, they must establish a joint security context. The context encapsulates shared state information that might include, for example, cryptographic keys. Both applications create and use an org.ietf.jgss.GSSContext object to establish and maintain the shared information that makes up the security context. Once a security context has been established, it can be used to prepare secure messages for exchange. The Java GSS APIs are in the org.ietf.jgss package. The Java platform also defines basic Kerberos classes, like KerberosPrincipal, KerberosTicket, KerberosKey, and KeyTab, which are located in the javax.security.auth.kerberos package. Access Control The access control architecture in the Java platform protects access to sensitive resources (for example, local files) or sensitive application code (for example, methods in a class). All access control decisions are mediated by a security manager, represented by the java.lang.SecurityManager class. A SecurityManager must be installed into the Java runtime in order to activate the access control checks. WARNING: The Security Manager and APIs related to it have been deprecated and are subject to removal in a future release. There is no replacement for the Security Manager. See JEP 411 for discussion and alternatives. Local applications executed via the java command are by default not run with a SecurityManager installed. In order to run local applications with a SecurityManager, either the application itself must programmatically set one via the setSecurityManager method (in the java.lang.System class), or java must be invoked with a - Djava.security.manager argument on the command line. Permissions A permission represents access to a system resource. In order for a resource access to be allowed for an applet (or an application running with a security manager), the corresponding permission must be explicitly granted to the code attempting the access. Chapter 1 Java Security Overview 1-14
- 40. When Java codeis loaded by a class loader into the Java runtime, the class loader automatically associates the following information with that code: • Where the code was loaded from • Who signed the code (if anyone) • Default permissions granted to the code This information is associated with the code regardless of whether the code is downloaded over an untrusted network (e.g., an applet) or loaded from the filesystem (e.g., a local application). The location from which the code was loaded is represented by a URL, the code signer is represented by the signer's certificate chain, and default permissions are represented by java.security.Permission objects. The default permissions automatically granted to downloaded code include the ability to make network connections back to the host from which it originated. The default permissions automatically granted to code loaded from the local filesystem include the ability to read files from the directory it came from, and also from subdirectories of that directory. Note that the identity of the user executing the code is not available at class loading time. It is the responsibility of application code to authenticate the end user if necessary (see the section Authentication). Once the user has been authenticated, the application can dynamically associate that user with executing code by invoking the doAs method in the javax.security.auth.Subject class. Security Policy A limited set of default permissions are granted to code by class loaders. Administrators have the ability to flexibly manage additional code permissions via a security policy. Java SE encapsulates the notion of a security policy in the java.security.Policy class. There is only one Policy object installed into the Java runtime at any given time. The basic responsibility of the Policy object is to determine whether access to a protected resource is permitted to code (characterized by where it was loaded from, who signed it, and who is executing it). How a Policy object makes this determination is implementation-dependent. For example, it may consult a database containing authorization data, or it may contact another service. Java SE includes a default Policy implementation that reads its authorization data from one or more ASCII (UTF-8) files configured in the security properties file. These policy files contain the exact sets of permissions granted to code: specifically, the exact sets of permissions granted to code loaded from particular locations, signed by particular entities, and executing as particular users. The policy entries in each file must conform to a documented proprietary syntax and may be composed via a simple text editor. Access Control Enforcement The Java runtime keeps track of the sequence of Java calls that are made as a program executes. When access to a protected resource is requested, the entire call stack, by default, is evaluated to determine whether the requested access is permitted. As mentioned previously, resources are protected by the SecurityManager. Security-sensitive code in the JDK and in applications protects access to resources via code like the following: SecurityManager sm = System.getSecurityManager(); if (sm != null) { Chapter 1 Java Security Overview 1-15
- 41. sm.checkPermission(perm); } The Permission objectperm corresponds to the requested access. For example, if an attempt is made to read the file /tmp/abc, the permission may be constructed as follows: Permission perm = new java.io.FilePermission("/tmp/abc", "read"); The default implementation of SecurityManager delegates its decision to the java.security.AccessController implementation. The AccessController traverses the call stack, passing to the installed security Policy each code element in the stack, along with the requested permission (for example, the FilePermission in the previous example). The Policy determines whether the requested access is granted, based on the permissions configured by the administrator. If access is not granted, the AccessController throws a java.lang.SecurityException. Figure 1-4 illustrates access control enforcement. In this particular example, there are initially two elements on the call stack, ClassA and ClassB. ClassA invokes a method in ClassB, which then attempts to access the file /tmp/abc by creating an instance of java.io.FileInputStream. The FileInputStream constructor creates a FilePermission, perm, as shown previously, and then passes perm to the SecurityManager class's checkPermission method. In this particular case, only the permissions for ClassA and ClassB need to be checked, because all classes in the java.base module, including FileInputStream, SecurityManager, and AccessController, automatically receives all permissions. In this example, ClassA and ClassB have different code characteristics – they come from different locations and have different signers. Each may have been granted a different set of permissions. The AccessController only grants access to the requested file if the Policy indicates that both classes have been granted the required FilePermission. Chapter 1 Java Security Overview 1-16
- 42. Figure 1-4 ControllingAccess to Resources ClassA ClassB FileInputStream SecurityManager AccessController Policy Who Signers Authorization Data Who Signers Location Location Permission perm = new java.io.FilePermission("/tmp/abc", "read"); /tmp/abc SecurityManager sm = System.getSecurityManager(); if (sm != null) { sm.checkPermission(perm); } Access granted or denied Chapter 1 Java Security Overview 1-17
- 43. XML Signature The JavaXML Digital Signature API is a standard Java API for generating and validating XML Signatures. XML Signatures can be applied to data of any type, XML or binary (see XML Signature Syntax and Processing). The resulting signature is represented in XML. An XML Signature can be used to secure your data and provide data integrity, message authentication, and signer authentication. The API is designed to support all of the required or recommended features of the W3C Recommendation for XML-Signature Syntax and Processing. The API is extensible and pluggable and is based on the Java Cryptography Service Provider Architecture. The Java XML Digital Signature API, which is in the java.xml.crypto module, consists of six packages: • javax.xml.crypto • javax.xml.crypto.dsig • javax.xml.crypto.dsig.keyinfo • javax.xml.crypto.dsig.spec • javax.xml.crypto.dom • javax.xml.crypto.dsig.dom Java API for XML Processing (JAXP) Java API for XML Processing (JAXP) is for processing XML data using Java applications. It includes support for Simple API for XML (SAX), Document Object Models (DOM) and Streaming API for XML (StAX) parsers, XML Schema Validation, and Extensible Stylesheet Language Transformations (XSLT). In addition, JAXP provides secure processing features that can help safeguard your applications and system from XML-related attacks. See Java API for XML Processing (JAXP) Security Guide. Note: Secure Coding Guidelines for Java SE contains additional recommendations that can help defend against XML-related attacks. Security Tools Summary The following tables describe Java security and Kerberos-related tools. Chapter 1 Java Security Overview 1-18
- 44. Table 1-2 JavaSecurity Tools Tool Usage jar Creates Java Archive (JAR) files jarsigner Signs and verifies signatures on JAR files keytool Creates and manages key stores There are also three Kerberos-related tools that are shipped with the JDK for Windows. Equivalent functionality is provided in tools of the same name that are automatically part of Linux and macOS. Table 1-3 Kerberos-related Tools Tool Usage kinit Obtains and caches Kerberos ticket-granting tickets klist Lists entries in the local Kerberos credentials cache and key table ktab Manages the names and service keys stored in the local Kerberos key table Built-In Providers The Java SE implementation from Oracle includes a number of built-in provider packages. See JDK Providers Documentation. Java SE Platform Security Architecture This document gives an overview of the motivation of the major security features implemented for the JDK, describes the classes that are part of the Java security architecture, discusses the impact of this architecture on existing code, and gives thoughts on writing security-sensitive code. WARNING: The Security Manager and APIs related to it have been deprecated and are subject to removal in a future release. There is no replacement for the Security Manager. See JEP 411 for discussion and alternatives. Introduction Since the inception of Java technology, there has been strong and growing interest around the security of the Java platform as well as new security issues raised by the deployment of Java technology. From a technology provider's point of view, Java security includes two aspects: Chapter 1 Java SE Platform Security Architecture 1-19
- 45. • Provide theJava platform as a secure, ready-built platform on which to run Java- enabled applications in a secure fashion. • Provide security tools and services implemented in the Java programming language that enable a wider range of security-sensitive applications, for example, in the enterprise world. This document discusses issues related to the first aspect, where the customers for such technologies include vendors that bundle or embed Java technology in their products (such as browsers and operating systems). The Original Sandbox Model The original security model provided by the Java platform is known as the sandbox model, which existed in order to provide a very restricted environment in which to run untrusted code obtained from the open network. The essence of the sandbox model is that local code is trusted to have full access to vital system resources (such as the file system) while downloaded remote code (an applet) is not trusted and can access only the limited resources provided inside the sandbox. This sandbox model is illustrated in Figure 1-5. Figure 1-5 Original Java Platform Security Model JVM sandbox valuable resources (files, etc.) local code remote code The sandbox model was deployed through the Java Development Kit (JDK), and was generally adopted by applications built with JDK 1.0, including Java-enabled web browsers. Overall security is enforced through a number of mechanisms. First of all, the language is designed to be type-safe and easy to use. The hope is that the burden on the programmer is such that the likelihood of making subtle mistakes is lessened compared with using other programming languages such as C or C++. Language features such as automatic memory management, garbage collection, and range checking on strings and arrays are examples of how the language helps the programmer to write safe code. Second, compilers and a bytecode verifier ensure that only legitimate Java bytecodes are executed. The bytecode verifier, together with the Java Virtual Machine, guarantees language safety at run time. Chapter 1 Java SE Platform Security Architecture 1-20
- 46. Moreover, a classloaderdefines a local name space, which can be used to ensure that an untrusted applet cannot interfere with the running of other programs. Finally, access to crucial system resources is mediated by the Java Virtual Machine and is checked in advance by a SecurityManager class that restricts the actions of a piece of untrusted code to the bare minimum. JDK 1.1 introduced the concept of a "signed applet", as illustrated in Figure 1-6. In that release, a correctly digitally signed applet is treated as if it is trusted local code if the signature key is recognized as trusted by the end system that receives the applet. Signed applets, together with their signatures, are delivered in the JAR (Java Archive) format. In JDK 1.1, unsigned applets still run in the sandbox. Figure 1-6 JDK 1.1 Security Model JVM sandbox valuable resources (files, etc.) local code remote code trusted Evolving the Sandbox Model The new Java SE Platform Security Architecture, illustrated in Figure 1-7, is introduced primarily for the following purposes. Chapter 1 Java SE Platform Security Architecture 1-21
- 47. Figure 1-7 JavaSE Security Architecture JVM input sandbox security policy class loader local or remote code (signed or not) valuable resources (files, etc.) codes run with different permissions, no built-in notion of trusted code • Fine-grained access control. This capability existed in the JDK from the beginning, but to use it, the application writer had to do substantial programming (e.g., by subclassing and customizing the SecurityManager and ClassLoader classes). The HotJava browser 1.0 is such an application, as it allows the browser user to choose from a small number of different security levels. However, such programming is extremely security-sensitive and requires sophisticated skills and in-depth knowledge of computer security. The new architecture will make this exercise simpler and safer. • Easily configurable security policy. Once again, this capability existed previously in the JDK but was not easy to use. Moreover, writing security code is not straightforward, so it is desirable to allow application builders and users to configure security policies without having to program. • Easily extensible access control structure. Up to JDK 1.1, in order to create a new access permission, you had to add a new check method to the SecurityManager class. The new architecture allows typed permissions (each representing an access to a system resource) and automatic handling of all permissions (including yet-to-be-defined permissions) of the correct type. No new method in the SecurityManager class needs to be created in Chapter 1 Java SE Platform Security Architecture 1-22
- 48. most cases. (Infact, we have so far not encountered a situation where a new method must be created.) • Extension of security checks to all Java programs, including applications as well as applets. There is no longer a built-in concept that all local code is trusted. Instead, local code (e.g., non-system code, application packages installed on the local file system) is subjected to the same security control as applets, although it is possible, if desired, to declare that the policy on local code (or remote code) be the most liberal, thus enabling such code to effectively run as totally trusted. The same principle applies to signed applets and any Java application. Finally, an implicit goal is to make internal adjustment to the design of security classes (including the SecurityManager and ClassLoader classes) to reduce the risks of creating subtle security holes in future programming. Protection Mechanisms – Overview of Basic Concepts We now go over, in some detail, the new protection architecture and give a brief explanation of its functionality. We start with an overview of the basic concepts behind the new architecture. We then introduce the major new classes in a natural order, starting with permission specifications, going on to the policy and related features, followed by access control and its usage, and then covering secure class loading and resolution. A fundamental concept and important building block of system security is the protection domain [Saltzer and Schroeder 75]. A domain can be scoped by the set of objects that are currently directly accessible by a principal, where a principal is an entity in the computer system to which permissions (and as a result, accountability) are granted. The sandbox utilized in JDK 1.0 is one example of a protection domain with a fixed boundary. The protection domain concept serves as a convenient mechanism for grouping and isolation between units of protection. For example, it is possible (but not yet provided as a built-in feature) to separate protection domains from interacting with each other so that any permitted interaction must be either through trusted system code or explicitly allowed by the domains concerned. Note that existing object accessibility rules remain valid under the new security architecture. Protection domains generally fall into two distinct categories: system domain and application domain. It is important that all protected external resources, such as the file system, the networking facility, and the screen and keyboard, be accessible only via system domains. Figure 1-8 illustrates the domain composition of a Java application environment. Figure 1-8 Domain Composition of a Java Application Environment system domain net I/O file I/O printer AWT App-1 App-2 App-n A domain conceptually encloses a set of classes whose instances are granted the same set of permissions. Protection domains are determined by the policy currently in effect. The Java application environment maintains a mapping from code (classes and instances) to their protection domains and then to their permissions, as illustrated in Figure 1-9. Chapter 1 Java SE Platform Security Architecture 1-23
- 49. Figure 1-9 Mappingfrom Code to Domains and to Permissions Class Domain Permissions classes in Java runtime e.class d.class c.class b.class a.class security policy domain A domain B permissions permissions A thread of execution (which is often, but not necessarily tied to, a single Java thread, which in turn is not necessarily tied to the thread concept of the underlying operation system) may occur completely within a single protection domain or may involve an application domain and also the system domain. For example, an application that prints a message out will have to interact with the system domain that is the only access point to an output stream. In this case, it is crucial that at any time the application domain does not gain additional permissions by calling the system domain. Otherwise, there can be serious security implications. In the reverse situation where a system domain invokes a method from an application domain, such as when the AWT system domain calls an applet's paint method to display the applet, it is again crucial that at any time the effective access rights are the same as current rights enabled in the application domain. In other words, a less "powerful" domain cannot gain additional permissions as a result of calling or being called by a more powerful domain. This discussion of one thread involving two protection domains naturally generalizes to a thread that traverses multiple protection domains. A simple and prudent rule of thumb for calculating permissions is the following: • The permission set of an execution thread is considered to be the intersection of the permissions of all protection domains traversed by the execution thread. • When a piece of code calls the doPrivileged method, the permission set of the execution thread is considered to include a permission if it is allowed by the said code's protection domain and by all protection domains that are called or entered directly or indirectly subsequently. As you can see, the doPrivileged method enables a piece of trusted code to temporarily enable access to more resources than are available directly to the application that called it. This is necessary in some situations. For example, an application may not be allowed direct access to files that contain fonts, but the system utility to display a document must obtain those fonts, on behalf of the user. We provide the doPrivileged method for the system domain to deal with this situation, and the method is in fact available to all domains. During execution, when access to a critical system resource (such as file I/O and network I/O) is requested, the resource-handling code directly or indirectly invokes a special AccessController class method that evaluates the request and decides if the request should be granted or denied. Chapter 1 Java SE Platform Security Architecture 1-24
- 50. Such an evaluationfollows and generalizes the "rule of thumb" given previously. The actual way in which the evaluation is conducted can vary between implementations. The basic principle is to examine the call history and the permissions granted to the relevant protection domains, and to return silently if the request is granted or throw a security exception if the request is denied. Finally, each domain (system or application) may also implement additional protection of its internal resources within its own domain boundary. For example, a banking application may need to support and protect internal concepts such as checking accounts, deposits and withdrawals. Because the semantics of such protection is unlikely to be predictable or enforceable by the JDK, the protection system at this level is best left to the system or application developers. Nevertheless, whenever appropriate, we provide helpful primitives to simplify developers' tasks. One such primitive is the SignedObject class, whose detail we will describe later. Permissions and Security Policy The Permission Classes The permission classes represent access to system resources. The java.security.Permission class is an abstract class and is subclassed, as appropriate, to represent specific accesses. As an example of a permission, the following code can be used to produce a permission to read the file named abc in the /tmp directory: perm = new java.io.FilePermission("/tmp/abc", "read"); New permissions are subclassed either from the Permission class or one of its subclasses, such as java.security.BasicPermission. Subclassed permissions (other than BasicPermission) generally belong to their own packages. Thus, FilePermission is found in the java.io package. A crucial abstract method that needs to be implemented for each new class of permission is the implies method. Basically, "a implies b" means that if one is granted permission "a", one is naturally granted permission "b". This is important when making access control decisions. Associated with the abstract class java.security.Permission are the abstract class named java.security.PermissionCollection and the final class java.security.Permissions. Class java.security.PermissionCollection represents a collection (i.e., a set that allows duplicates) of Permission objects for a single category (such as file permissions), for ease of grouping. In cases where permissions can be added to the PermissionCollection object in any order, such as for file permissions, it is crucial that the PermissionCollection object ensure that the correct semantics are followed when the implies method is called. Class java.security.Permissions represents a collection of collections of Permission objects, or in other words, a super collection of heterogeneous permissions. Applications are free to add new categories of permissions that the system supports. How to add such application-specific permissions is discussed later in this document. Now we describe the syntax and semantics of all built-in permissions. Chapter 1 Java SE Platform Security Architecture 1-25
- 51. java.security.Permission This abstract classis the ancestor of all permissions. It defines the essential functionalities required for all permissions. Each permission instance is typically generated by passing one or more string parameters to the constructor. In a common case with two parameters, the first parameter is usually "the name of the target" (such as the name of a file for which the permission is aimed), and the second parameter is the action (such as "read" action on a file). Generally, a set of actions can be specified together as a comma-separated composite string. java.security.PermissionCollection This class holds a homogeneous collection of permissions. In other words, each instance of the class holds only permissions of the same type. java.security.Permissions This class is designed to hold a heterogeneous collection of permissions. Basically, it is a collection of java.security.PermissionCollection objects. java.security.UnresolvedPermission Recall that the internal state of a security policy is normally expressed by the permission objects that are associated with each code source. Given the dynamic nature of Java technology, however, it is possible that when the policy is initialized the actual code that implements a particular permission class has not yet been loaded and defined in the Java application environment. For example, a referenced permission class may be in a JAR file that will later be loaded. The UnresolvedPermission class is used to hold such "unresolved" permissions. Similarly, the class java.security.UnresolvedPermissionCollection stores a collection of UnresolvedPermission permissions. During access control checking on a permission of a type that was previously unresolved, but whose class has since been loaded, the unresolved permission is "resolved" and the appropriate access control decision is made. That is, a new object of the appropriate class type is instantiated, if possible, based on the information in the UnresolvedPermission. This new object replaces the UnresolvedPermission, which is removed. If the permission is still unresolvable at this time, the permission is considered invalid, as if it is never granted in a security policy. java.io.FilePermission The targets for this class can be specified in the following ways, where directory and file names are strings that cannot contain white spaces. file directory (same as directory/) directory/file directory/* (all files in this directory) * (all files in the current directory) directory/- (all files in the file system under this directory) Chapter 1 Java SE Platform Security Architecture 1-26
- 52. - (all filesin the file system under the current directory) "<<ALL FILES>>" (all files in the file system) Note that <<ALL FILES>> is a special string denoting all files in the system. On Linux or macOS, this includes all files under the root directory. On Windows, this includes all files on all drives. The actions are: read, write, delete, and execute. Therefore, the following are valid code samples for creating file permissions: import java.io.FilePermission; FilePermission p = new FilePermission("myfile", "read,write"); FilePermission p = new FilePermission("/home/gong/", "read"); FilePermission p = new FilePermission("/tmp/mytmp", "read,delete"); FilePermission p = new FilePermission("/bin/*", "execute"); FilePermission p = new FilePermission("*", "read"); FilePermission p = new FilePermission("/-", "read,execute"); FilePermission p = new FilePermission("-", "read,execute"); FilePermission p = new FilePermission("<<ALL FILES>>", "read"); The implies method in this class correctly interprets the file system. For example, FilePermission("/-", "read,execute") implies FilePermission("/home/gong/ public_html/index.html", "read"), and FilePermission("bin/*", "execute") implies FilePermission("bin/emacs19.31", "execute"). Chapter 1 Java SE Platform Security Architecture 1-27
- 53. Note: Most of thesestrings are given in platform-dependent format. For example, to represent read access to the file named foo in the temp directory on the C drive of a Windows system, you would use FilePermission p = new FilePermission("c:tempfoo", "read"); The double backslashes are necessary to represent a single backslash because the strings are processed by a tokenizer (java.io.StreamTokenizer), which allows to be used as an escape string (e.g., n to indicate a new line) and which thus requires two backslashes to indicate a single backslash. After the tokenizer has processed the FilePermission target string, converting double backslashes to single backslashes, the end result is the actual path: "c:tempfoo" It is necessary that the strings be given in platform-dependent format until there is a universal file description language. Note also that the use of meta symbols such as * and - prevents the use of specific file names. We think this is a small limitation that can be tolerated for the moment. Finally, note that -/ and <<ALL FILES>> are the same target on Linux and macOS in that they both refer to the entire file system. (They can refer to multiple file systems if they are all available). The two targets are potentially different on other operating systems, such as Windows and macOS. Also note that a target name that specifies just a directory, with a "read" action, as in FilePermission p = new FilePermission("/home/gong/", "read"); means you are only giving permission to list the files in that directory, not read any of them. To allow read access to files, you must specify either an explicit file name, or an * or -, as in FilePermission p = new FilePermission("/home/gong/myfile", "read"); FilePermission p = new FilePermission("/home/gong/*", "read"); FilePermission p = new FilePermission("/home/gong/-", "read"); And finally, note that code always automatically has permission to read files from its same (URL) location, and subdirectories of that location; it does not need explicit permission to do so. Chapter 1 Java SE Platform Security Architecture 1-28
- 54. java.net.SocketPermission This class representsaccess to a network via sockets. The target for this class can be given as hostname:port_range, where hostname can be given in the following ways: hostname (a single host) IP address (a single host) localhost (the local machine) "" (equivalent to "localhost") hostname.domain (a single host within the domain) hostname.subdomain.domain *.domain (all hosts in the domain) *.subdomain.domain * (all hosts) That is, the host is expressed as a DNS name, as a numerical IP address, as "localhost" (for the local machine) or as "" (which is equivalent to specifying "localhost"). The wildcard * may be included once in a DNS name host specification. If it is included, it must be in the leftmost position, as in *.sun.com. The port_range can be given as follows: N (a single port) N- (all ports numbered N and above) -N (all ports numbered N and below) N1-N2 (all ports between N1 and N2, inclusive) Here N, N1, and N2 are non-negative integers ranging from 0 to 65535 (216-1). The actions on sockets are accept, connect, listen, and resolve (which is basically DNS lookup). Note that implicitly, the action "resolve" is implied by "accept", "connect", and "listen" – i.e., those who can listen or accept incoming connections from or initiate out-going connections to a host should be able to look up the name of the remote host. The following are some examples of socket permissions. import java.net.SocketPermission; SocketPermission p = new SocketPermission("java.example.com","accept"); p = new SocketPermission("192.0.2.99","accept"); p = new SocketPermission("*.com","connect"); p = new SocketPermission("*.example.com:80","accept"); p = new SocketPermission("*.example.com:-1023","accept"); p = new SocketPermission("*.example.com:1024-","connect"); p = new SocketPermission("java.example.com:8000-9000", "connect,accept"); p = new SocketPermission("localhost:1024-", "accept,connect,listen"); Chapter 1 Java SE Platform Security Architecture 1-29
- 55. Another Random ScribdDocument with Unrelated Content
- 56. The Tzirah orHornet of Scripture—Travellers driven away by Hornets—The Hornet used as a metaphor—Oriental symbolism—The Talmudical writers —Sting of the Hornet 613 THE ANT. The Ant of Scripture—Solomon's allusion to the Ant—Habit of laying up stores of food—A controversy respecting the Ant—The Ants of Palestine, and their habits—The Agricultural or Mound-making Ant—Preparing ground, sowing, tending, reaping, and storing the crop—Different habits of Ants—Development of the insect—The winged Ants—An Arab proverb 616 THE CRIMSON WORM. The scarlet or crimson of Scripture—Signification of the word Tolââth—The Coccus or Cochineal of Palestine compared with that of Mexico— Difference between the sexes—Mode of preparing the insect—The Arabic word Kermes 622 THE CLOTHES MOTH. The Moth of Scripture evidently the Clothes Moth—The Sâs and the 'Ash— Similitude between the Hebrew sâs and the Greek sês—Moths and garments—Accumulation of clothes in the East—Various uses of the hoarded robes—The Moths, the rust, and the thief 624 THE SILKWORM MOTH. Various passages wherein Silk is mentioned—The virtuous woman and her household—Probability that the Hebrews were acquainted with Silk— Present cultivation of the Silkworm—The Silk-farms of the Lebanon— Signification of the word Meshi—Silkworms and thunder—Luis of Grenada's sermon—The Hebrew word Gâzam, and its signification—The Palmer-worm of Scripture 627 FLIES. Flies of Scripture—Dead Flies and the apothecary's ointment—Gadflies and their attacks—Annoyance caused by the House-fly—Flies and ophthalmia —Signor Pierotti's account of the Flies—The sovereign remedy against Flies—Causes of their prevalence 632 GNATS.
- 57. The Gnat ofScripture—Straining out the Gnat and swallowing the camel, a typographical error—Probable identity of the Gnat and the mosquito 635 THE LOUSE. Insect parasites—The plague of Lice—Its effect on the magicians or priests —The Hebrew word Chinnim—Probability that it may be represented by "tick"—Habits of the ticks, their dwellings in dust, and their effects on man and beast 636 THE FLEA. Prevalence of the Flea in the East, and the annoyance caused by them to travellers—Fleas of the Lebanon—The Bey's bedfellows—The Pasha at the bath—Use of the word in Scripture 638 THE SCORPION. The Scorpions of Palestine—Signification of the word Akrabbim—Habits of the Scorpion—Dangers of mud walls—Venom of the Scorpion—Scorpions at sea—The Scorpion whip, and its use—The Scorpion Pass 640 THE SPIDER. Signification of the word Semamith—Various interpretations of a Scriptural passage—Talmudical opinions respecting the creature—The 'Akkabish and its web—Spiders of Palestine 643 THE WORM. Various words translated as "Worm"—Probable confusion of the words—The Rimmah and the Tole'ah—The Worm which destroyed Jonah's gourd—The Earthworm 644 THE HORSE LEECH. Signification of the word Alukah—The Arabic word—Leeches in Palestine— The horse and the Leech—Leeches in England 646 SPONGE AND CORAL. Use of the Sponge in Scripture—Probability that the ancient Jews were acquainted with it—Sponges of the Mediterranean—The Coral, and its value—Signification of the word Ramoth 647
- 59. LIST OF ILLUSTRATIONS. FULL-PAGEILLUSTRATIONS. PAGE The Ostrich and its Hunters. (Job xxxix. 18) Frontispiece. The Lion and his Den. (Ezek. xix. 2) 26 Dogs prowling at Night. (Psa. lix. 14) 48 The Badger and its Home. (Exod. xxvi. 14) 72 Bears descending from the Hills. (Prov. xxviii. 15) 76 Oxen bearing the Yoke. (Lam. iii. 27) 104 Sheep and their Shepherd and Fold. (Psa. xxiii. 2) 156 Goats wounded by Lion. (Amos iii. 12) 202 The Hind and her Young. (Job xxxix. 1) 212 Camels and their Burdens. (Isa. xxx. 6) 222 The War Horse going to Battle. (Job xxxix. 25) 250 Wild Asses and the Hunters. (Job xxxix. 5-8) 282 The Wild Boar in the Vineyard. (Psa. lxxx. 13) 300 Elephants in a Forest. (Ezek. xxvii. 15) 312 The Hippopotamus or Behemoth. (Job xl. 21) 324 Vultures and their Prey. (Matt. xxiv. 28) 352 The Eagle and its Nest. (Job xxxix. 27) 354 The Osprey and its Haunts. (Deut. xiv. 12) 356 The Owl among Ruins. (Job xxx. 29) 376
- 60. Peacocks. (1 Kingsx. 22) 426 The Bittern and its Home. (Isa. xiv. 23) 466 The Stork in the Fir-trees. (Psa. civ. 17) 482 The Crocodile or Leviathan. (Job xli. 7) 520 Locusts on the March. (Exod. x. 5) 600 ILLUSTRATIONS IN THE TEXT. PAGE The Rhesus and Entellus. (1 Kings x. 22) 3 The Wanderoo 6 Bats in their Cave. (Levit. xi. 19) 17 The Leopard by the Way. (Hos. xiii. 7) 30 The Wolf among the Sheep. (John x. 12) 51 Jackals and the Scapegoat. (Psa. lxiii. 10) 56 Hyænas and Vultures. (Ezek. xxix. 5) 65 The Hedgehog. (Isa. xxxiv. 11) 81 The Mole-Rat. (Levit. xi. 30) 87 Field-Mice among Corn. (1 Sam. vi. 5) 93 Syrian Hares. (Deut. xiv. 7) 97 Oxen Treading out Corn. (Deut. xxv. 4) 107 The Buffalo. (Amos vi. 12) 114 The Wild Bull, or Oryx. (Isa. li. 21) 119 The Unicorn, or Bison. (Job xxxix. 9) 132 Gazelles upon the Mountains. (Cant. ii. 8) 136 The Pygarg, or Addax. (Deut. xiv. 4) 142 The Fallow-Deer, or Bubale. (1 Kings iv. 23) 145 Sheep led to Pasture. (John x. 3) 154 The Ram's Horn Trumpet. (Josh. vi. 4) 175
- 61. The Place ofSacrifice on Mount Gerizim 181 The Chamois, or Aoudad. (Deut. xiv. 4, 5) 187 Goats divided from Sheep. (Matt. xxv. 52) 199 The Wild Goat, or Ibex. (Psa. cxiv. 18) 206 The Hind, or Fallow-Deer. (Cant. ii. 7) 209 The Dromedary and its Rider. (Jer. ii. 23) 231 The Camel and the "Needle's Eye." (Matt. xix. 24) 243 Bactrian Camels harnessed. (Isa. xxi. 7) 246 The War Chariot of Egypt. (Jer. xlvi. 9) 261 The State Chariot of Assyria. (Jer. xvii. 25) 262 Syrian Asses. (Prov. xxvi. 3) 269 Mules and their Driver. (Psa. xxxii. 9) 287 Conies among the Rocks. (Prov. xxx. 26) 313 The Hippopotamus in the River. (Job xl. 21) 325 The Hippopotamus and Trap. (Job xl. 24) 328 The Ossifrage, or Lämmergeier. (Deut. xiv. 12) 334 The Gier-Eagle, or Egyptian Vulture. (Deut. xiv. 17) 340 The Vulture, or Kite. (Job xxviii. 7) 358 The Glede, or Peregrine Falcon. (Deut. xiv. 13) 361 The Lanner Falcon 363 The Hawk, or Kestrel. (Job xxxix. 26) 366 The Little Owl. (Psa. cii. 6) 372 The Night-Hawk. (Deut. xiv. 15) 378 The Swallow and Swift. (Jer. viii. 7) 385 The Lapwing, or Hoopoe. (Levit. xi. 19) 393 The Sparrow, or Blue Thrush. (Psa. cii. 7) 399 The Sparrow, or Tree Sparrow. (Psa. lxxxiv. 3) 403 The Cuckoo. (Levit. xi. 16) 406
- 62. The Rock Dove.(Cant. ii. 14) 416 The Turtle Dove. (Cant. ii. 12) 420 Poultry. (Luke xiii. 34) 423 The Partridge on the Mountains. (1 Sam. xxvi. 20) 428 The Quail. (Psa. cv. 40) 431 The Raven. (Job xxxviii. 41) 441 The Ostrich and its Eggs. (Job xxxix. 14) 454 The Bittern. (Isa. xiv. 23) 463 The Heron. (Deut. xi. 19) 469 The Crane. (Isa. xxxviii. 14) 475 The Swan or Ibis, or Gallinule. (Deut. xiv. 16) 486 The Pelican of the Wilderness. (Psa. cii. 6) 496 The Tortoise and Dhubb. (Levit. xi. 29) 507 The Lizard, or Cyprius. (Levit. xi. 30) 530 The Chameleon and the Gecko. (Levit. xi. 30) 535 The Asp and the Adder, or the Cobra and the Cerastes. (Psa. lviii. 4; Gen. xlix. 17) 542 The Viper, or Toxicoa. (Job xx. 16) 553 The Frog. (Exod. viii. 3) 558 Fishes—Muræna, Barbel, and Sheat-fish. (Levit. xi. 10) 566 Fishes—Sucking-fish, Tunny, and Coryphene. (Levit. x. 9) 569 Fishes—Lates, Mullus, and Uranoscopus. (Numb. xi. 5) 582 The Pearl Oyster. (Matt. xiii. 45) 594 The Bee. (Isa. vii 19) 606 The Hornet. (Exod. xxiii. 28) 614 The Ant. (Prov. vi. 6) 621
- 63. The Crimson Worm,or Cochineal. (Isa. i. 18) 623 Butterflies and Caterpillars of Palestine. (Joel i. 4) 631 Flies. (Isa. vii. 18) 635 The Scorpion. (Rev. ix. 10) 641 The Coral. (Job xxviii. 18) 648
- 64. MAMMALIA. BIBLE ANIMALS. THE APE. TheMonkey tribe rarely mentioned in Scripture—Why the Ape was introduced into Palestine—Solomon's ships, and their cargo of Apes, peacocks, ivory and gold—Various species of Monkey that might have been imported—The Rhesus Monkey—The Hoonuman or Entellus—Habits of the Monkey, and reverence in which it is held by the natives—The Egyptians and their Baboon worship—Idols and memorials—The Wanderoo—its singular aspect—Reasons why it should be introduced into Palestine—General habits of the Wanderoo—its love of curiosities— Probability that Solomon had a menagerie—Various species of Monkey that maybe included in the term "Kophim"—The Satyr of Scripture— Babylon in its glory and fall—Fulfilment of prophecy—Judaic ideas of the Satyrs, or Seirim. Animals belonging to the monkey tribe are but sparingly mentioned in Holy Writ. If, as is possible, the Satyr of Scripture signifies some species of baboon, there are but three passages either in the Old or New Testament where these animals are mentioned. In 1 Kings x. 22, and the parallel passage 2 Chron. ix. 21, the sacred historian makes a passing allusion to apes as forming part of the valuable cargoes which were brought by Solomon's fleet to Tharshish, the remaining articles being gold, ivory, and peacocks. The remaining passage occurs in Is. xiii. 21, where the prophet foretells that on the site of Babylon satyrs shall dance.
- 65. The reason forthis reticence is simple enough. No monkey was indigenous to Palestine when the various writers of the Bible lived, and all their knowledge of such animals must have been derived either from the description of sailors, or from the sight of the few specimens that were brought as curiosities from foreign lands. Such specimens must have been extremely rare, or they would not have been mentioned as adjuncts to the wealth of Solomon, the wealthiest, as well as the wisest monarch of his time. To the mass of the people they must have been practically unknown, and therefore hold but a very inferior place in the Scriptures, which were addressed to all mankind. There is scarcely any familiar animal, bird, reptile or insect, which is not used in some metaphorical sense in the imagery which pervades the whole of the Scriptures. For example, the various carnivorous animals, such as the lion, wolf, and bear, are used as emblems of destruction in various ways; while the carnivorous birds, such as the eagle and hawk, and the destructive insects, such as the locust and the caterpillar, are all similarly employed in strengthening and illustrating the words of Holy Writ. But we never find any animal of the monkey tribe mentioned metaphorically, possibly because any monkeys that were imported into Palestine must only have been intended as objects of curiosity, just as the peacocks which accompanied them were objects of beauty, and the gold and ivory objects of value—all being employed in the decoration of the king's palace. The question that now comes before us is the species of monkey that is signified by the Hebrew word Kophim. In modern days, we distinguish this tribe of animals into three great sections, namely, the apes, the baboons, and the monkey; and according to this arrangement the ape, being without tails, must have been either the chimpanzee of Africa, the orang-outan of Sumatra, or one of the Gibbons. But there is no reason to imagine that the word Kophim was intended to represent any one of these animals, and it seems
- 66. evident that theword was applied to any species of monkey, whether it had a tail or not. Perhaps the best method of ascertaining approximately the particular species of monkey, is to notice the land from which the animals came. Accordingly, we find that the ships of Solomon brought gold, ivory, apes, and peacocks, and that they evidently brought their cargoes from the same country. Consequently, the country in question must produce gold, and must be inhabited by the monkey tribe, by the elephant, and by the peacock. If the peacock had not been thus casually mentioned, we should have been at a loss to identify the particular country to which reference is made; but the mention of that bird shows that some part of Asia must be signified. It is most probable that the vessels in question visited both India and Ceylon, although, owing to the very imperfect geographical knowledge of the period, it is not possible to assert absolutely that this is the case. In India, however, and the large island of Ceylon, gold, elephants, peacocks, and monkeys exist; and therefore we will endeavour to identify the animals which are mentioned under the general term Apes, or Kophim.
- 67. THE RHESUS ANDENTELLUS. "Bringing gold, and silver, ivory, and apes."—1 Kings x. 22. We are quite safe in suggesting that some of the apes in question must have belonged to the Macaques, and it is most likely that one of them was the Rhesus, or Bhunder, scientifically named Macacus Rhesus. This animal is very plentiful in India, and is one of the many creatures which are held sacred by the natives. Consequently, it takes up its quarters near human habitations, feeling sure that it will not be injured, and knowing that plenty of food is at hand. It is said that in some parts of India the natives always leave one-tenth of their grain-crops for the monkeys, and thus the animals content themselves with this offering, and refrain from devastating the fields, as they would otherwise do. This story may be true or not. It is certainly possible that in a long series of years the monkeys of that neighbourhood have come to look upon their tithe as a matter
- 68. belonging to theordinary course of things; but whether it be true or not, it illustrates the reverence entertained by the Hindoos for their monkeys. In many places where grain and fruit crops are cultivated, the monkeys get rather more than their share, plundering without scruple, and finding no hindrance from the rightful owners, who dare not drive them away, lest they should injure any of these sacred beings. However, being unmindful of the maxim, "qui facit per alium, facit per se," they are only too glad to avail themselves of the assistance of Europeans, who have no scruples on the subject. Still, although they are pleased to see the monkeys driven off, and their crops saved, they would rather lose all their harvest than allow a single monkey to be killed, and in the earlier years of our Indian colony, several riots took place between the natives and the English, because the latter had killed a monkey through ignorance of the reverence in which it was held. Another monkey which may probably have been brought to Palestine from India is the Hoonuman, Entellus, or Makur, which is more reverenced by the Hindoos than any other species. Its scientific title is Presbytes entellus. In some parts of India it is worshipped as a form of divinity, and in all it is reverenced and protected to such an extent that it becomes a positive nuisance to Europeans who are not influenced by the same superstitious ideas as those which are so prevalent in India. Being a very common species, it could easily be captured, especially if, as is likely to be the case, it was fearless of man through long immunity from harm. The sailors who manned Solomon's navy would not trouble themselves about the sacred character of the monkeys, but would take them without the least scruple wherever they could be found. The Hoonuman would also be valued by them on account of its docility when taken young, and the amusing tricks which it is fond of displaying in captivity as well as in a state of freedom. Moreover, it is rather a pretty creature, the general colour being yellowish, and the face black.
- 69. Perfectly aware ofthe impunity with which they are permitted to act, these monkeys prefer human habitations to the forests which form the natural home of their race, and crowd into the villages and temples, the latter being always swarming with the long-tailed host. As is the case with the Rhesus, the Hoonuman monkeys are much too fond of helping themselves from the shops and stalls, and if they can find a convenient roof, will sit there and watch for the arrival of the most dainty fruits. However, the natives, superstitious as they are, and unwilling to inflict personal injury on a monkey, have no scruple in making arrangements by which a monkey that trespasses on forbidden spots will inflict injury on itself. They may not shoot or wound in any way the monkeys which cluster on their roofs, and the animals are so perfectly aware of the fact, that they refuse to be driven away by shouts and menacing gestures. But, they contrive to make the roofs so uncomfortable by covering them with thorns, that the monkeys are obliged to quit their points of vantage, and to choose some spot where they can sit down without fear of hurting themselves. That the Hindoos should pay homage almost divine to a monkey, does seem equally absurd and contemptible. But, strange as this superstition may be, and the more strange because the intellectual powers of the educated Hindoos are peculiarly subtle and penetrating, it was shared by a greater, a mightier, and a still more intellectual race, now extinct as a nation. The ancient Egyptians worshipped the baboon, and ranked it among the most potent of their deities; and it can but strike us with wonder when we reflect that a people who could erect buildings perfectly unique in the history of the world, who held the foremost place in civilization, who perfected arts which we, at a distance of three thousand years, have only just learned, should pay divine honours to monkeys, bulls, and snakes. Such, however, was the case; and we find that the modern Hindoo shows as great reverence for the identical animals as did the Egyptian when Pharaoh was king, and Joseph his prime minister.
- 70. It is saidby some, that neither the Egyptian of the ancient times, nor the Hindoo of the present day, actually worshipped those creatures, but that they reverenced them as external signs of some attribute of God. Precisely the same remarks have been made as to the worship of idols, and it is likely enough that the highly educated among the worshippers did look upon a serpent merely as an emblem of divine wisdom, a bull as an image of divine strength, and a monkey as an external memorial of the promised incarnation of divinity. So with idols, which to the man of educated and enlarged mind were nothing but visible symbols employed for the purpose of directing the mind in worship. But, though this was the case with the educated and intellectual, the ignorant and uncultivated, who compose the great mass of a nation, did undoubtedly believe that both the living animal and the lifeless idol were themselves divine, and did worship them accordingly. THE WANDEROO.
- 71. There is onespecies of monkey, which is extremely likely to have been brought to Palestine, and used for the adornment of a luxurious monarch's palace. This is the Wanderoo, or Nil-Bhunder (Silenus veter). The Wanderoo, or Ouanderoo, as the name is sometimes spelled, is a very conspicuous animal, on account of the curious mane that covers its neck and head, and the peculiarly formed tail, which is rather long and tufted, like that of a baboon, and has caused it to be ranked among those animals by several writers, under the name of the Lion-tailed Baboon. That part of the hairy mass which rolls over the head is nearly black, but as it descends over the shoulders, it assumes a greyer tinge, and in some specimens is nearly white, reminding the observer of the huge wigs which were so prevalent in the time of Charles II, or of the scarcely less enormous head-dresses with which our judges are decorated. As is the case with many animals, the mane is not seen in the young specimens, and increases in size with age, only reaching its full dimensions when the animal has attained adult age. Moreover, the grey hue belongs exclusively to the elder monkeys, and only in the oldest specimens is the full, white, venerable, wig-like mane to be seen in perfection. In captivity, the general demeanour of this monkey corresponds with its grave and dignified aspect. It seems to be more sedate than the ordinary monkeys, to judge from the specimens which have lived in the Zoological Gardens, and sits peering with its shiny brown eyes out of the enormous mane, with as much gravity as if it were really a judge deciding an important case in law. Not that it will not condescend to the little tricks and playful sallies for which the monkeys are so celebrated; but it soon loses the vivacity of youth, and when full-grown, presents as great a contrast to its former vivacity, as does a staid full-grown cat sitting by the fire, to the restless, lively, playful kitten of three months old. During its growth, it can be taught to go through several amusing performances, but it has little of the quick, mercurial manner, which is generally found among the monkey tribe.
- 72. The docility ofthe Wanderoo often vanishes together with its youth. The same animal may be gentle, tractable, and teachable when young, and yet, when a few years have passed over its head and whitened its mane, may be totally obstinate and dull, refusing to perform the feats which it accomplished in its youth, or to learn others more suitable to its years. Consistent kind treatment will, however, have its effect upon the creature, but as a general rule, an old Wanderoo is apt to be a treacherous and spiteful animal. The natives of the country in which the Wanderoo lives, attribute to it the wisdom which its venerable aspect seems to imply, much as the ancient Athenians venerated the owl as the bird of wisdom, and the chosen companion of the learned Minerva. In many places, the Wanderoo is thought to be a sort of king among monkeys, and to enjoy the same supremacy over its maneless kinsfolk, that the king- vulture maintains over the other vultures which are destitute of the brilliant crest that marks its rank. I am induced to believe that the Wanderoo must have been one of the monkeys which were brought to Solomon, for two reasons. In the first place, it is a native both of India and Ceylon, and therefore might have formed an article of merchandise, together with the peacock, gold, and ivory. And if, as is extremely probable, the Tharshish of the Scripture is identical with Ceylon, it is almost certain that the Wanderoo would have been brought to Solomon, in order to increase the glories of his palace. Sir Emerson Tennant points out very forcibly, that in the Tamil language, the words for apes, ivory, and peacocks, are identical with the Hebrew names for the same objects, and thus gives a very strong reason for supposing that Ceylon was the country from which Solomon's fleet drew its supplies. Another reason for conjecturing that the Wanderoo would have been one of the animals sent to grace the palace of Solomon is this. In the days when that mighty sovereign lived, as indeed has been the case in all partially civilized countries, the kings and rulers have felt a
- 73. pride in collectingtogether the rarest objects which they could purchase, giving the preference to those which were in any way conspicuous, whether for intrinsic value, for size, for beauty, or for ugliness. Thus, giants, dwarfs, and deformed persons of either sex, and even idiots, were seen as regular attendants at the court, a custom which extended even into the modern history of this country, the "Fool" being an indispensable appendage to the train of every person of rank. Animals from foreign lands were also prized, and value was set upon them, not only for their variety, but for any external characteristic which would make them especially conspicuous. Ordinary sovereigns would make collections of such objects, simply because they were rare, and in accordance with the general custom; and in importing the "apes" and peacocks together with the gold and ivory, Solomon but followed the usual custom. He, however, on whom the gift of wisdom had been especially bestowed, would have another motive besides ostentation or curiosity. He was learned in the study of that science which we now call Natural History. It is, therefore, extremely probable, that he would not neglect any opportunities of procuring animals from distant lands, in order that he might study the products of countries which he had not personally visited, and it is not likely that so conspicuous an animal as the Wanderoo would have escaped the notice of those who provided the cargo for which so wealthy a king could pay, and for which they would demand a price proportionate to its variety. There is perhaps no monkey which is so conspicuous among its kin as the Wanderoo, and certainly no monkey or ape inhabiting those parts of the world to which the fleet of Solomon would have access. Its staid, sedate manners, its black body, lion-like tail, and huge white-edged mane, would distinguish it so boldly from its kinsfolk, that the sailors would use all their efforts to capture an animal for which they would be likely to obtain a high price. The peculiar and unique character of Solomon affords good reason for conjecture that, not only were several species of the monkey
- 74. tribe included underthe general word Kophim, but that the number of species must have been very large. An ordinary monarch would have been content with one or two species, and would probably have been perfectly satisfied if a number of monkeys had been brought from beyond seas, irrespective of distinction of species. But, if we consider the character of Solomon, we shall find that he would not have been content with such imperfect knowledge. We are told that he wrote largely of the various productions of the earth, and, to judge him by ourselves, it is certain that with such magnificent means at his command, he would have ransacked every country that his ships could visit, for the purpose of collecting materials for his works. It is therefore almost certain that under the word Kophim may be included all the most plentiful species of monkey which inhabit the countries to which his fleet had access, and that in his palace were collected together specimens of each monkey which has here been mentioned, besides many others of which no special notice need be taken, such as the Bonnet Monkeys, and other Macaques. We now come to the vexed question of the Satyrs, respecting which word great controversies have been raised. The Hebrew word Seirim merely signifies "hairy beings," and does not seem to be applied to any definite species of animal. Several scholars, therefore, translate the word by "wild goats," and instead of reading the passages (Is. xiii. 21, and xxxiv. 14) "Satyrs shall dance there," they read them, "The he-goats shall skip there." This is certainly an easier interpretation than that which is accepted in our translation, but whether it is more correct may be doubted. Moreover, the word "goat" would not convey the idea of utter desolation which the prophecy implied, and which has been so signally fulfilled in the Babylon of the present day. The vast palaces and temples have sunk into shapeless heaps of ruins, affording scarcely a trace by which the buildings can be identified. The many massive gates, for which the city was famous, have disappeared. The double lines of fortification are only to be distinguished by a few scattered mounds, while the
- 75. wonderful palace ofNebuchadnezzar has left but a few shattered walls as relics of an edifice whose fame spread over the world. What precise animal was meant by the word Seirim cannot be ascertained, nor is it even certain whether the word signified any particular species at all. The ancient commentators identified Seirim with the semi-human creatures of mythology, known as Satyrs, and strengthened this opinion by a reference to Lev. xvii. 7, where the Israelites are warned against worshipping Seirim, or "devils" according to our translation. In common with all the civilized world, they fully believed that Satyrs were veritable inhabitants of the woods and deserts, with forms half man half goat, with powers more than human, and with passions below humanity. Of course we cannot now accept such an interpretation, but must grant, either that a mere metaphor of desolation was intended, or that the prophecy alluded to various wild animals that inhabit deserted places. Accept which interpretation we will, it is impossible to identify any particular animal with the "Satyr" of Isaiah, and therefore it will be better to decline giving any opinion on a subject which cannot be definitely explained. THE BAT. The Bat mentioned always with abhorrence—Meaning of the Hebrew name —The prohibition against eating Bats—The edible species, their food and mode of life—The noisome character of the Bat, and the nature of its dwelling-place—Its hatred of light—Baruch and his prophecy— Appropriateness of the prophecy—Singular Mahommedan legend respecting the original creation of the Bat—The legend compared with the apocryphal gospels—The Bats of Palestine—Mr. Tristram's discoveries— Bats found in the quarries from which the stone of the Temple was hewn —Edible Bats in a cave near the centre of Palestine—Another species of long-tailed Bat captured in the rock caves where hermits had been buried —Other species which probably inhabit Palestine. Among the animals that are forbidden to be eaten by the Israelites we find the Bat prominently mentioned, and in one or two parts of Scripture the same creature is alluded to with evident abhorrence. In
- 76. Isaiah ii. 20,for example, it is prophesied that when the day of the Lord comes, the worshippers of idols will try to hide themselves from the presence of the Lord, and will cast their false gods to the bats and the moles, both animals being evidently used as emblems of darkness and ignorance, and associated together for a reason which will be given when treating of the mole. The Hebrew name of the Bat is expressive of its nocturnal habits, and literally signifies some being that flies by night, and it is a notable fact that the Greek and Latin names for the bat have also a similar derivation. In Lev. xi. 20, the words, "All fowls that creep, going upon all four, shall be an abomination unto you," are evidently intended to apply to the bat, which, as is now well known, is not a bird with wings, but a mammal with very long toes, and a well developed membrane between them. Like other mammals, the Bat crawls, or walks, on all four legs, though the movement is but a clumsy one, and greatly different from the graceful ease with which the creature urges its course through the evening air in search of food. Perhaps the prohibition to eat so unsightly an animal may seem almost needless; but it must be remembered that in several parts of the earth, certain species of Bat are used as food. These are chiefly the large species, that are called Kalongs, and which feed almost entirely on fruit, thus being to their insectivorous relatives what the fruit-loving bear is among the larger carnivora. These edible Bats have other habits not shared by the generality of their kin. Some of the species do not retire to caves and hollow trees for shelter during their hours of sleep, but suspend themselves by their hind legs from the topmost branches of the trees whose fruit affords them nourishment. In this position they have a most singular aspect, looking much as if they themselves were large bunches of fruit hanging from the boughs. Thus, they are cleanly animals, and are as little repulsive as bats can be expected to be. But the ordinary bats, such as are signified by the "night-fliers" of the Scriptures, are, when in a state of nature, exceedingly unpleasant creatures. Almost all animals are infested with parasitic
- 77. insects, but theBat absolutely swarms with them, so that it is impossible to handle a Bat recently dead without finding some of them on the hands. Also, the bats are in the habit of resorting to caverns, clefts in the rocks, deserted ruins, and similar dark places, wherein they pass the hours of daylight, and will frequent the same spots for a long series of years. In consequence of this habit, the spots which they select for their resting place become inconceivably noisome, and can scarcely be entered by human beings, so powerful is the odour with which they are imbued. Sometimes, when travellers have been exploring the chambers of ruined buildings, or have endeavoured to penetrate into the recesses of rocky caves, they have been repelled by the bats which had taken up their habitation therein. No sooner does the light of the torch or lamp shine upon the walls, than the clusters of bats detach themselves from the spots to which they had been clinging, and fly to the light like moths to a candle. No torch can withstand the multitude of wings that come flapping about it, sounding like the rushing of a strong wind, while the bats that do not crowd around the light, dash against the explorers, beating their leathery wings against their faces, and clinging in numbers to their dress. They would even settle on the face unless kept off by the hands, and sometimes they force the intruders to beat a retreat. They do not intend to attack, for they are quite incapable of doing any real damage; and, in point of fact, they are much more alarmed than those whom they annoy. Nocturnal in their habits, they cannot endure the light, which completely dazzles them, so that they dash about at random, and fly blindly towards the torches in their endeavours to escape. If, then, we keep in mind the habits of the bats, we shall comprehend that their habitations must be inexpressibly revolting to human beings, and shall the better understand the force of the prophecy that the idols shall be cast to the bats and the moles. There is another, and a very forcible passage, in which the Bat is mentioned. In the apocryphal book of Baruch, the Bat is used as a
- 78. lively image ofsomething peculiarly repulsive and hateful. Baruch was the secretary and faithful friend of Jeremiah the prophet, and Chapter VI. of the book of Baruch purports to be an epistle of Jeremiah to the captive Jews about to be led away to Babylon. After showing that they had brought their fate upon themselves by neglecting the worship of the true God, and prophesying that they would remain in captivity for seven generations, the writer proceeds, in a strain of scathing and sustained satire, to deride the idols which they had adored, and to censure the infamous ceremonies that formed part of the worship. After describing the idols, made splendid with silver and gold, whose hands hold sceptres, and axes, and wands, and yet cannot save themselves from robbers; whose tongues are polished by the workman and yet cannot speak a word; whose eyes are covered with dust which they cannot wipe off for themselves; he proceeds as follows: "Their hearts are gnawed upon by things creeping out of the earth; and when they eat them and their clothes they feel it not. Their faces are blacked through the smoke that cometh out of the Temple. Upon their bodies and heads sit bats, swallows and birds, and the cats also. By this ye may know that they are no gods; therefore fear them not." It is not to be expected that so strange looking an animal as the Bat would escape mention in the legends which are so plentiful in the East. Signor Pierotti, who has done such signal service in the investigation of the Holy Land, gives a most remarkable semi-Mahommedan and semi-Christian legend respecting the origin of the Bat. The Mahommedans, unlike the generality of Jews, have always respected the memory of our Lord Christ—the Prophet Isa, as they call Him— ranking Him as one of the greatest of God's prophets, though they deny His actual divinity. In this curious legend, they have confused the forty days fast in the wilderness with the enforced Mahommedan fast called Ramadhan, much as the writers of the apocryphal gospels attributed to the holy family and the apostles certain phrases and
- 79. acts of worshipwhich were not in existence until several centuries after the Christian era. Towards the west of Jericho, there is a mountain which is identified both by Christians and Mahommedans as being the spot to which our Lord retired during his passion, and which, in consequence of this supposition, is called Kuruntun, or Quarantine. The reader, while perusing the following legend, must bear in mind that the fast of Ramadhan lasts for a month, and that from sunrise to sunset an entire abstinence from all kinds of nourishment is imperative upon all good Mussulmans. Even such luxuries as smoking or inhaling perfumes are forbidden, and although washing is permitted, the head must not be plunged under water, lest a few drops might find their way through the nostrils. In consequence of this strict prohibition, the moments of daybreak and sunset are noted with the most scrupulous care, the tables being set, pipes lighted, coffee prepared, and every luxury being made ready just before sunset, so that as the orb disappears beneath the horizon, the fasting multitudes may not lose a moment in satisfying their wants. A similar anxiety marks the approach of daybreak, because, as the first beams of the sun break through the darkness, neither food nor drink may pass their lips. We will now proceed to the Mahommedan legend, as it is given by S. Pierotti: "In this wild spot the great prophet Isa retired with his disciples to keep the holy month of the Ramadhan, afar from the tumults of the world. As the view westward was obstructed by the mountains of Jerusalem, and, consequently, the sunset could not be seen, he made, by the permission of God, an image in clay representing a winged creature; and, after invoking the aid of the Eternal, breathed upon it. Immediately it flapped its large wings, and fled into one of the dark caverns in the mountains. This creature was the Khopash (bat), which lies hid so long as the sun shines upon the world, and comes forth from its retreat when it sets. Every night, at the Moghreb, i.e. at the moment of breaking the fast, this bat
- 80. fluttered round Isa,who then prepared himself with his disciples for prayer. "As soon as they had performed this sacred duty, the Merciful caused to descend from heaven a silver table, covered with a cloth whose brilliancy illumined the darkness, on which were placed a large roasted fish, five loaves, salt, vinegar, oil, pomegranates, dates, and fresh salad, gathered in the gardens of heaven. On these the Prophet supped, and the angels of heaven ministered at table." This curious legend bears a great resemblance to the tales which are told of our Lord's childhood in some of the spurious gospels. It shows that both emanated from the same class of mind. In both is seen a strange mixture of vivid imagination contrasted with unexpected and almost puerile lack of invention; and, in both is exhibited a total failure in apprehension of cause and effect. Indeed, it is evident that this legend was the work of a comparatively modern Mahommedan story-teller, who appropriated the forty days' fast of our Lord from the true gospels, and the making of a flying creature of clay from the false, and modified them both to suit the purposes of his tale. No particular species of Bat seems to be indicated by the Hebrew word Hatalleph, which is evidently used in a comprehensive sense, and signifies all and any species of Bat. Until very lately, the exact species of Bats which inhabit Palestine were not definitely ascertained, and could only be conjectured. But, Mr. Tristram, who travelled in the Holy Land for the express purpose of investigating its physical history, has set this point at rest, in his invaluable work, "The Land of Israel," to which frequent reference will be made in the course of the following pages. Almost every cavern which he entered was tenanted by bats, and he procured several species of these repulsive but interesting animals. While exploring the vast prairies in which the stone for the Temple was worked beneath the earth, so that no sound of tool was heard
- 81. during the building,numbers of bats were disturbed by the lights, and fluttered over the heads of the exploring party. On another occasion, he was exploring a cave near the centre of Palestine, when he succeeded in procuring some specimens, and therefore in identifying at least one species. "In climbing the rocks soon afterwards, to examine a cave, I heard a singular whining chatter within, and on creeping into its recesses, a stone thrown up roused from their roosting-places a colony of large bats, the soft waving flap of whose wings I could hear in the darkness. How to obtain one I knew not; but on vigorously plying my signal whistle, all the party soon gathered to my help. B. suggested smoking them, so a fire of brushwood was kindled, and soon two or three rushed out. Two fell to our shot, and I was delighted to find myself the possessor of a couple of large fox-headed bats of the genus Pteropus (Xantharpya ægyptiaca), and extending twenty and a half inches from wing to wing. As none of the bats of Palestine are yet known, this was a great prize, and another instance of the extension westward of the Indian fauna." These Bats belong to the fruit-eating tribe, and are closely allied to the Flying Foxes of Java, Australia, and Southern Africa. Therefore, this would be one of the species commonly used for food, and hence the necessity for the prohibition. The present species extends over the greater part of Northern Africa and into parts of Asia. The same traveller subsequently discovered several more species of bats. On one occasion, he was exploring some caves, near the site of the ancient Jericho. On the eastern face of the cliffs are a number of caves, arranged in regular tiers, and originally approached by steps cut out of the face of the rock. These staircases are, however, washed away by time and the rains, and in consequence the upper tiers were almost inaccessible. In some of these caves the walls were covered with brilliant, but mutilated frescoes; and in others, hermits had lived and died and been buried. Mr. Tristram and his companions had penetrated to the second tier, and there made a curious discovery.
- 82. "In the roofof this was a small hole, athwart which lay a stick. After many efforts, we got a string across it, and so hauled up a rope, by which, finding the stick strong enough, we climbed, and with a short exercise of the chimney-sweeper's art, we found ourselves in a third tier of cells, similar to the lower ones, and covered with the undisturbed dust of ages. Behind the chapel was a dark cave, with an entrance eighteen inches high. Having lighted our lantern, we crept in on our faces, and found the place full of human bones and skulls; with dust several inches deep. We were in the burying-place of the Anchorites. Their bones lay heaped, but in undisturbed order, probably as the corpses had been stretched soon after death, and as in the campo-santo of some Italian monasteries, had been desiccated, and in the dry atmosphere had gradually pulverized. The skeletons were laid west and east, awaiting the resurrection. After capturing two or three long-tailed bats, of a species new to us (Rhinopoma microphylla), the only living occupants, we crept out, with a feeling of religious awe, from this strange sepulchral cave." This bat is called the Egyptian Rhinopome, and the same species of Bat was found in considerable numbers in the cave at Es Sumrah. Three more species were found in the tombs of the kings, and it is probable that many other species inhabit Palestine. It is certain, at all events, that representatives of three more families of Bats inhabit Egypt, and therefore are most probably to be found in Palestine.
- 83. THE BAT. "The Lapwingand the Bat are unclean."—Lev. xi. 19. THE LION. Frequent mention of the Lion in the Scriptures—Probability that it was once a common animal, though now extinct—Reasons for its disappearance— The Lion employed as an emblem in the Bible—Similarity of the African and Asiatic species—The chief characteristics of the Lion—its strength, activity, and mode of seizing its prey—Various names of the Lion—its courage when roused—its roar and peculiar mode of utterance— Invisibility of the Lion at dusk—The Lion lying in wait—The dwelling-place of the Lion—Its restlessness at night—Passages illustrative of these characteristics—Modes of capturing the Lion—The pitfall and the net—
- 84. Lions kept ascuriosities—The Lion hunt as depicted, on the buildings of ancient Nineveh. Of all the undomesticated animals of Palestine, none is mentioned so frequently as the Lion. This may appear the more remarkable, because for many years the Lion has been extinct in Palestine. The leopard, the wolf, the jackal, and the hyæna, still retain their place in the land, although their numbers are comparatively few; but the Lion has vanished completely out of the land. The reason for this disappearance is twofold, first, the thicker population; and second, the introduction of firearms. No animal is less tolerant of human society than the Lion. In the first place, it dreads the very face of man, and as a rule, whenever it sees a man will slink away and hide itself. There are, of course, exceptional cases to this rule. Sometimes a Lion becomes so old and stiff, his teeth are so worn, and his endurance so slight, that he is unable to chase his usual prey, and is obliged to seek for other means of subsistence. In an unpopulated district, he would simply be starved to death, but when his lot is cast in the neighbourhood of human beings, he is perforce obliged to become a "man-eater." Even in that case, a Lion will seldom attack a man, unless he should be able to do so unseen, but will hang about the villages, pouncing on the women as they come to the wells for water, or upon the little children as they stray from their parents, and continually shifting his quarters lest he should be assailed during his sleep. The Lion requires a very large tract of country for his maintenance, and the consequence is, that in proportion as the land is populated does the number of Lions decrease. Firearms are the special dread of the Lion. In the first place, the Lion, like all wild beasts, cannot endure fire, and the flash of the gun terrifies him greatly. Then, there is the report, surpassing even his roar in resonance; and lastly, there is the unseen bullet, which seldom kills him at once, but mostly drives him to furious anger by the pain of his wound, yet which he does not dread nearly so much as the harmless flash and report. There is another cause of the Lions
- 85. banishment from theHoly Land. It is well known that to attract any wild beast or bird to some definite spot, all that is required is to provide them with a suitable and undisturbed home, and a certainty of food. Consequently, the surest method of driving them away is to deprive them of both these essentials. Then the Lion used to live in forests, which formerly stretched over large tracts of ground, but which have long since been cut down, thus depriving the Lion of its home, while the thick population and the general use of firearms have deprived him of his food. In fact, the Lion has been driven out of Palestine, just as the wolf has been extirpated from England. But, in the olden times, Lions must have been very plentiful. There is scarcely a book in the Bible, whether of the Old or New Testaments, whether historical or prophetical, that does not contain some mention of this terrible animal; sometimes describing the actions of individual Lions, but mostly using the word as an emblem of strength and force, whether used for a good purpose or abused for a bad one. There are several varieties of Lion, which may be reduced to two, namely, the African and the Asiatic Lion. It is almost certain, however, that these animals really are one and the same species, and that the trifling differences which exist between an African and an Asiatic Lion, are not sufficient to justify a naturalist in considering them to be distinct species. The habits of both are identical, modified, as is sure to be the case, by the difference of locality; but then, such variations in habit are continually seen in animals confessedly of the same species, which happen to be placed in different conditions of climate and locality. That it was once exceedingly plentiful in Palestine is evident, from a very cursory knowledge of the Holy Scriptures. It is every where mentioned as a well-known animal, equally familiar and dreaded. When the disobedient prophet was killed by the Lion near Bethel, the fact seemed not to have caused any surprise in the neighbourhood. When the people came out to rescue the body of the prophet, they wondered much because the Lion was standing by
- 86. the fallen man,but had not torn him, and had left the ass unhurt. But that a Lion should have killed a man seems to have been an event which was not sufficiently rare to be surprising. We will now proceed to those characteristics of the Lion which bear especial reference to the Scriptures. In the first place, size for size, the Lion is one of the strongest of beasts. Perhaps it is surpassed in point of sheer strength by the mole, but it possesses infinitely more activity than that animal. Moreover, the strength of the mole is concentrated in its fore- quarters, the hind limbs being comparatively feeble; whereas, the strength of the Lion is equally distributed over the body and limbs, giving to the animal an easy grace of movement which is rare except with such a structure. A full-grown Lion cannot only knock down and kill, but can carry away in its mouth, an ordinary ox; and one of these terrible animals has been known to pick up a heifer in its mouth, and to leap over a wide ditch still carrying its burden. Another Lion carried a two-year old heifer, and was chased for five hours by mounted farmers, so that it must have traversed a very considerable distance. Yet, in the whole of this long journey, the legs of the heifer had only two or three times touched the ground. It kills man, and comparatively small animals, such as deer and antelopes, with a blow of its terrible paw; and often needs to give no second blow to cause the death of its victim. The sharp talons are not needed to cause death, for the weight of the blow is sufficient for that purpose. When the hunter pursues it with dogs, after the usual fashion, there is often a great slaughter among them, especially among those that are inexperienced in the chase of the Lion. Urged by their instinctive antipathy, the dogs rush forward to the spot where the Lion awaits them, and old hounds bay at him from a safe distance, while the young and inexperienced among them are apt to convert the sham attack into a real one. Their valour meets with a poor reward, for a few blows from the Lion's terrible paws send his assailants flying in
- 87. all directions, theirbodies streaming with blood, and in most cases a fatal damage inflicted, while more than one unfortunate dog lies fairly crushed by the weight of a paw laid with apparent carelessness upon its body. There is before me a Lion's skin, a spoil of one of these animals shot by the celebrated sportsman, Gordon Cumming. Although the skin lies flat upon the floor, and the paws are nothing but the skin and talons, the weight of each paw is very considerable, and always surprises those who hear it fall on the floor. There are several Hebrew words which are used for the Lion, but that which signifies the animal in its adult state is derived from an Arabic word signifying strength; and therefore the Lion is called the Strong-one, just as the Bat is called the Night-flier. No epithet could be better deserved, for the Lion seems to be a very incarnation of strength, and, even when dead, gives as vivid an idea of concentrated power as when it was living. And, when the skin is stripped from the body, the tremendous muscular development never fails to create a sensation of awe. The muscles of the limbs, themselves so hard as to blunt the keen-edged knives employed by a dissecter, are enveloped in their glittering sheaths, playing upon each other like well-oiled machinery, and terminating in tendons seemingly strong as steel, and nearly as impervious to the knife. Not until the skin is removed can any one form a conception of the enormously powerful muscles of the neck, which enable the Lion to lift the weighty prey which it kills, and to convey it to a place of security. Although usually unwilling to attack an armed man, it is one of the most courageous animals in existence when it is driven to fight, and if its anger is excited, it cares little for the number of its foes, or the weapons with which they are armed. Even the dreaded firearms lose their terrors to an angry Lion, while a Lioness, who fears for the safety of her young, is simply the most terrible animal in existence. We know how even a hen will fight for her chickens, and how she has been known to beat off the fox and the hawk by the reckless fury of her attack. It may be easily imagined, therefore, that a
- 88. Welcome to ourwebsite – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com