SAP Cloud Platform Neo Environment allows development of Java Applications. When deployed, Java Application will be run on a separate virtual machine. That way a strong isolation between different applications is achieved.
Every Java Application works within Java Virtual Machine (Java VM). The operating system (OS) process of the Java Virtual Machine runs with a dedicated non-privilege system user. Application is restricted to OS permissions that this user has on the virtual machine. They are enough for the application to work smoothly and on the other hand are limited in a way that application could not elevate local permissions and endanger virtual machine processing.
Mentioned security measures should be enough to ensure needed isolation. That’s true, but not for the best class enterprise application environment. There is an additional security measure – Java VM process is running also within an AppArmor. AppArmor proactively protects the OS and applications from various threats, even 0-day attacks. Its security policy completely defines what system resources could an application access and with what privileges.
Bringing all together we could visualize in the following way:
Java Application Sandboxing in SAP CP Neo Environment
Java Applications are put into cage with three rows of solid grids, restricting them from interfering with the other applications or critical cloud services. Customers decide what to put into the cage – it could be simple hello world example, rich enterprise application or even some “dangerous” code. As far as the cage around the application is in place, what is running inside does not matter as it could not break any other application or cloud system service.
Security isolation model explained above enforces restrictions on applications. It eliminates many security risks and mitigates others to acceptable level. Let’s look at security measures and covered security risks:
- Separate Virtual Machine per Java Application: having no applications running on the same virtual machine eliminates all risks connected with any possible interference between them. Risks for takeover of another application via 0-day exploit into the operating system or into the containers isolation are eliminated. Additionally, on network level direct connections between applications are forbidden and even in case of local privilege escalation it is not possible for applications to reach each other.
- Java VM runs with non-privilege OS user: Together with the application, on the same virtual machine, are running few cloud agents responsible for lifecycle of the application and automation of different tasks (e.g. reporting monitoring data, collecting logs, etc.). Using a dedicated non-privilege OS user for application Java VM eliminates all security risks for interference with mentioned agents. That way an application could not disturb the work of system services and agents running on the same virtual machine.
- AppArmor: Using AppArmor sandboxing is an additional security hardening measure. AppArmor profile is easily manageable supporting only whitelisting rules. All permissions currently granted to Java Applications are already assessed and approved from the SAP CP security experts. AppArmor profile is configured in a way that every process started from the application will inherit the application’s restrictions. Even in case of OS 0-day privilege escalation and possibility for Java Application to escape from the dedicated OS-user restrictions, it will still be running within the AppArmor profile constraints.
Enterprise Java Applications usually need only Java VM runtime to run. Sometimes this is not enough and an additional flexibility is needed. Let’s look what is supported from SAP CP Neo Environment:
- File system write access: Java Application could write at its home folder. There are many scenarios when this is needed – e.g. keep some application specific configuration on the file system, a file on the file system used from third-party library, etc.
- OS process execution: Yes, Java Application could execute OS programs. Even few OS commands are accessible and could be directly executed from the application (e.g. using java.lang.Runtime.exec(…) method). All these executed processes inherit the application’s AppArmor profile and will be executed with the same restrictions as the application.
- Access to some system configuration files: There are several OS configuration files accessible from a Java Application in read only mode. Most of them are needed for the Java VM to run smoothly and some are required from third-party libraries that could be used from the applications. All these configuration files are whitelisted within the AppArmor application profile.
SAP Cloud Platform Neo Environment offers great flexibility for deployed Java Applications. They could write to their home folder, execute other processes or read system configurations. All this flexibility is kept within a triple protected secure sandbox achieving first class application isolation and system services protection.
At the end let’s look to answers of few frequently asked questions connected with SAP CP Neo Java Application sandboxing. Knowing all details above, the answers will not surprise you.
Q: Is it possible to execute binaries and even open a shell from Java Application at SAP CP Neo environment?
A: Yes. SAP Cloud Platform is a development platform. Customers can deploy applications. They have flexibility to execute binaries from their applications, including an OS command shell.
Q: The potential to open OS command shell makes lots of attacks possible. Is the security compromised?
A: A developer can harm his own application. This is something that couldn’t be prevented in a development platform. With all security measures in place SAP Cloud Platform efficiently protects the system and applications deployed by other SAP customers.
Q: Java Application can access operating system files. Is this a security problem?
A: No. Only files in one VM can be accessed. This VM belongs to one customer and in fact a customer can access his own files. All accessible files don’t contain any shared credentials or secrets.