Security Requirements for the Deployment of the Linux Kernel in Enterprise Systems Trent Jaeger, David Safford, Hubertus Franke IBM T.J. Watson Research Center, Route 134, Yorktown Heights, NY 10598 Email: {jaegert,safford,frankeh}@watson.ibm.com The goal of this white paper is to establish an architecture for providing security services for Linux-based enterprise-level Internet servers. While Linux provides good security features, equivalent to other comparable operating systems, the emerging security threats require stronger security mechanisms in the Linux kernel. We present a design that will make Linux substantially more secure against modern threats while maintaining a high degree of compatibility for existing enterprise software. We organize this paper as follows. Initially, we state the goals that are associated with a secure system. We outline the common security threats that enterprise systems face on the Internet and argue that existing security mechanisms are inadequate to meet this challenge. We then derive functional requirements that achieve the desired security goals in the modern threat environment. We then outline a design that meets these requirements. As much as possible, we want to incorporate existing open source projects that already meet one or more of the necessary requirements. Some of the basic goals associated with security services are: Integrity: The ability to assert that the system and its data are authentic and have not been tampered with, intentionally (intruder) or unintentionally (software bug). S ecrec y: The ability to restrict access to data and applications based on an identity. Auditab i lity: Ability to log all or a subset of security related events and make them available for review. Robustness: The ability of the system to maintain service without interruption in the presence of faults and attacks. Manageability: Security services should be easy to configure and understand. The traditional paradigm for meeting these goals is a combination of authentication and authorization. The first step is to identify the party making a request. The second step is to determine whether that party is authorized to make that request. There are many specific