Java OS-Security Paper(Ieee Format)

Published on February 2017 | Categories: Documents | Downloads: 21 | Comments: 0 | Views: 131
of x
Download PDF   Embed   Report

Comments

Content

JAVA OS: Security
1

Dinesh Goyal, 2Kamlesh Lakhwani, 3Gaurav Indoria, 4Manoj Sharma

Assistant Professor, M.Tech, Suresh Gyan Vihar University Assistant Professor, M.Tech, Suresh Gyan Vihar University 3 Research Scholar, M.Tech, Suresh Gyan Vihar University 4 Research Scholar, M.Tech, Arya Institute of Engg. & Tech.
2
1 3

1

[email protected], 2 [email protected], [email protected], [email protected] Java was created to be exploited in highly distributed environments. The portability of the language meant that security had to be incorporated in the very first steps of Java application development. This way, application users could be assured that the code they obtained was secure and had not been tampered with during transmission. This section explains how to achieve that security. II. JNI AND SECURITY JNI offers application developers a way to bridge earlier code with Java code. Implementing applications with JNI is not trivial because JNI requires a considerable amount of effort to learn and to implement. When developing code that utilizes the functions that JNI provides, the user should consider the following points: _ Subtle errors in the JNI native code can destabilize the JVM. _ The JNI native code is outside the control of the Java Security mechanisms. _ Any malicious code written in JNI can circumvent Java 2 security, including access control policies. The use of JNI native code should be strictly controlled. Because it is executed outside the JVM, access restrictions should be enforced using the native system Security model. Java security as implemented by the JVM operates above the operating system security services, meaning that Java Security is actually implemented in the JVM run-time environment. The privileges to be given at the host operating system level to the Java applications execution streams are well established and fully controlled. In contrast, each new JNI native program brings a new set of functions that need to be controlled, with the exposure of leaving unwanted system privileges to the program. III. JAVA AND z/OS SECURITY

Abstract-In a little more than a decade since the inception of the Java language, the Java ecosystem has evolved into one that businesses around the world look to for secure, robust, and manageable web-based applications that serve the enterprise. Java was created to be exploited in highly distributed environments. The portability of the language meant that security had to be incorporated in the very first steps of Java application development. This way, application users could be assured that the code they obtained was secure and had not been tampered with during transmission. This paper explains how to achieve that security. This paper explores the integrated Java platform security that results from the synergy of these two worldclass environments. Java security as implemented by the JVM operates above the operating system security services, meaning that Java Security is actually implemented in the JVM run-time environment. The privileges to be given at the host operating system level to the Java applications execution streams are well established and fully controlled. The paper describes the Java security model as implemented in the z/OS JVM™, and explains the role of the major infrastructure components such as Security Manager, Access Controller, Class-Loader and Byte-Code Verifier. In this paper we are also comparing two Java OSs: z/OS and OS-2200 on the issue of their security. This paper will give the brief description of J2EE environment with respect to OS-2200 and z/OS. In this paper we are trying to integrate the JAVA security with the security of multiple Oss. This paper will explain about the authentication, authorization, auditing, data protection, data integrity as implemented in above named OSs. Keywords: Java, Java Security, JVM, z/OS, OS2200.

I.INTRODUCTION

As Figure 1 illustrates, the Java Virtual Machine (JVM) runs under the control of the host system security. It is granted, by a system administrator, whatever permissions it needs to access system resources. On z/OS, the JVM runs under the identity of the user that started that application. When running a stand-alone application, the privileges granted to this user might be sufficient. However, depending on the type of application and execution environment, additional privileges might be needed (like access to specific system libraries, files, and services). The underlying operating system security must be set up to allow proper privileges for the JVM. System file level access control is a crucial element for you to consider. The JVM libraries should be accessible in read-only mode for all users except for the system administrator who is in charge of installing and maintaining the JVM. This is intended to guarantee that JVM component integrity will not be exposed to compromise by other z/OS components or even by Java applications that would call external z/OS components. There are two main features of z/OS security that the JVM and application environments must abide by: _ Authorized Program Facility (APF) _ Program Control
Java Application Code Class Loader Byte Code Verifier J

to achieve because of a lack of information regarding the deployment of the application on z/OS. In any case, it requires a system security administrator to work jointly with the application developer to establish the proper setup of this part of the execution environment. IV. JAVA AUTHENTICATION AND AUTHORIZATION SERVICE Java Authentication and Authorization Service (JAAS) is part of the Java Security framework. JAAS augments Java Virtual Machine codebased security by adding a user-centric framework for implementing application security. JAAS version 1.0 was originally shipped separately from the Java Runtime Environment (JRE). It began shipping as part of the JRE ascof Version 1.4. Java applications can run on a wide variety of platforms. Java was created to be widely distributed. Security had to be integrated into the framework from the very beginning to allow application developers the ability to sent their code to a number of possibly insecure platforms over insecure protocols. For example, a Java application, called an applet, can be executed in a Web browser. Applets can be included on any Web page loaded into the browser and executed. In the Java 2 platform, the security framework was able to enforce Java resource access control on the basis of the Web location from which the application code was delivered. In addition, Java packages can be signed by the application programmer. Digital signing of a Java package guarantees users that the application code they are running came from the intended issuer and was not altered, either maliciously or by accident, during download. However, these security mechanisms are codecentric and do not provide finely-grained access control on the basis of who is invoking the code. Java Authentication and Authorization Service enhanced the framework by adding support for user-centric security, providing user authentication support and extending the authorization mechanism to enforce access control based on the authenticated identity. Providing information about creating a new JAAS LoginModule is beyond the scope of this book. For more information about that topic, refer to JAAS LoginModule Developers Guide: http://java.sun.com/javase/6/docs/technotes/guid es/security/jaas/JAASLMDevGuide.html When working with the Java platform's security framework, users should be aware of the

a

Security Manager J Access Controller
a

Permission Policies Protection Domain

Java Run Time Execution Engine

Java Platform Classes

Operating System & Resources Figure. 1: Java Security framework components

The requirements to use APF-authorized libraries or program-controlled libraries must be carefully determined. This can often be difficult

concepts, classes, and interfaces that are used throughout the platform. Figure 2-1 illustrates the framework components and their interactions. V. OVERVIEW OF JAVA SECURITY ADMINISTRATION Java Security Administration provides a Java interface to allow administration of users and groups in security repositories. It also provides a RACF-specific implementation. The support for z/OS version 1 release 9 and above includes the ability to query users and groups from z/OS RACF or other non-z/OS security mechanisms, or interface with Java programs, as a call or a check of security credentials. This support provides two components: _ A generic Java interface, which could be used with any security provider _ A RACF-specific implementation
Java Appl icati on JSec API J V M J N D I TCP/ IP z/OS LDAP Server SDBM backend Users Groups

precious assets. The ClearPath OS 2200 environment provides a nearly impenetrable fortress to protect these assets, as illustrated in Figure 3. Immediately surrounding the database files is a layer of OS 2200 Exec file security, which can use powerful access control records for data access authorization. Wrapped around that is a security layer provided by Universal Database System (UDS). Around that lies the transactional security traditionally provided by the transaction interface package (TIP). When Java EE transactions are added to the mix, they have not only the security defined by the Java platform, but also the underlying OS 2200 platform security. Above the transactional layer are the controls providing a “gated entrance” to the OS 2200 server; and above that lie other firewalls and security measures in the corporate network. Furthermore, the Java EE Connector Architecture-compliant resource adapters provided by Unisys supply access to the highly secure mainframe databases using the OS 2200 network/communications security protocols. Taken together, this is a security system second to none for mission-critical Java applications. VII. AUTHENTICATION Java platform and OS 2200 security integration includes login modules that comply with Java Authentication and Authorization Services and provide user-id/password authentication: • The OS 2200 ClearTextLoginModule uses an OS 2200 user-id/password for authentication. (Note that although the module name includes “ClearText,” the user interface may use encryption when obtaining the user-id and password.) The authentication process compares the user-id/password that is input by the user to the user-id/password contained in the OS 2200 user record. • The OS2200Krb5LoginModule uses a network user-id/password for authentication via Kerberos. The OS2200Krb5LoginModule “wraps” the Sun Krb5LoginModule. The authentication process is performed in two steps. First, the network userid/password that is input by the user is authenticated by accessing the Kerberos Key Distribution Center through the Sun Krb5LoginModule. Then the Krb5LoginModule compares the principal name obtained from the Kerberos ticket to the principal name (network user-id) contained in the OS 2200 user record to

Figure 2: Java Application accessing an active RACF instance

Figure 2 illustrates how a Java application accesses an active instance of RACF. The Java application uses the JSec API that is running in a JVM and using JNDI to communicate over TCP/IP to an LDAP server, with the SDBM back-end active, in the z/OS image hosting the RACF instance. VI. CLEARPATH OS 2200 DATA SECURITY
Corporate Network Firewalls 2200 gated entrance Tip & Java EE Transaction security 2200 Universal Database security 2200 Exec file security Corporate Data

DMS

RDMS

BIS

Figure 3: OS 2200 Protects Corporate Database

One of the most compelling reasons to run Java applications on ClearPath OS 2200 is the added security that OS 2200 customers have come to expect and even take for granted. A corporation’s databases are one of its most

determine the user’s authenticated OS 2200 userid. • The OS 2200 JBoss Application Server login module provides authentication for users of secure web and Enterprise JavaBeans (EJB) applications. The OS 2200 JBoss Application Server login module provides a wrapper around the OS 2200 ClearTextLoginModule or OS2200Krb5LoginModule. Therefore, its authentication mechanism is either OS 2200 user-id/passwords or network user-id/passwords. • The JBoss security model is role-based. You grant permissions (e.g., for file or code access) to JBoss defined roles. To accomplish this task, the OS 2200 login modules map OS 2200 group names to JBoss role names The ClearTextLoginModule and OS2200Krb5LoginModule obtain OS 2200 group names from the OS 2200 user record and store them with the principal object (authenticated user-id) that is associated with the user. VIII. AUTHORIZATION Java EE role-based and OS 2200 security models are also integrated for authorization. The Java EE container controls access to container objects, methods, etc. OS 2200 controls Java platform access to applications, transactions, database components, and other system resources. IX. AUDITING The login modules supplied by Unisys support an optional configuration parameter for audit control. The user application can choose to log successful logins, failures, or logouts. Furthermore, OS 2200 database software audits all accesses to the database and can determine when the changes were made and by whom. X. DATA PROTACTION Access controls at the database level (such as database procedures, grant/revoke privileges, and access control lists) protect data objects. A misbehaving or incorrect EJB can change the database only in the ways in which it is allowed to do so. In addition, the Java database connector for the Relational Database Server (RDMS) provides a simple, yet effective, way to protect data from unauthorized reading or updating by Java clients. It evaluates the OS 2200 user-id of

the Java user against an Access Control Record for the database application group to grant or deny access to RDMS. XI. DATA INTEGRITY Even if something is changed incorrectly, the OS 2200 audit and recovery systems provide easy ways to restore the data to any point in time. XII. CONCLUSION AND FUTURE WORK The development of an OS using JAVA as platform would be the best thing. JAVA has vast security features with number of tools. Developing OS in JAVA will provide number of flexibility, modularity, robustness to the applications. We can also use z/OS, OS 2000 as pre-model to our project. In future work I will try to develop different-different functionalities of OS like scheduling, memory-management, I/O management, Deadlock-management and others. ClearPath OS 2200 systems have evolved with security at their very core. Applications running in the ClearPath OS 2200 Java EE environment enjoy enterprise-class security. XIII. REFERENCES http://www-128.ibm.com/developerworks/edu/jdw-javajni-i.html http://www.03.ibm.com/servers/eserver/zseries/s oftware/java/jrio/overview.html/ http://www-03.ibm.com/systems/z/zaap/ http://www03.ibm.com/servers/eserver/zseries/software/java http://www.ibm.com/developerworks/java/jdk/se curity/60/secguides/JaasDocs/api.html http://www03.ibm.com/servers/eserver/zseries/software/java /j5security.html http://unisys.com/cp/ecommunity

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close