-------------------------------- Use Case: Departmental File / Print / Collaboration Server --------------------------------- Version 0.1 (DRAFT) Last Modified Date: 8/18/05 Copyright (c) 2005 by The Open Source Development Lab, Inc. Verbatim copying and distribution of this document is permitted in any medium, provided this notice is preserved. Draft copies of this document may not be posted publicly without indicating the draft status. --------------------------------- Table of Contents --------------------------------- Description 1 Target Acceptance 2 Participants/Roles 2 Scenarios 3 Implementation Notes 5 References 5 --------------------------------- --------------------------------- Description --------------------------------- This use case describes what we call a “Departmental File / Print / Collaboration Server” found in a Data Center. The purpose of creating this description is so that the OSDL Security Special Interest Group (SIG) can use this description to evaluate the security needs for such a Server. The goal is to determine the operating system capabilities (the kernel and above) needed so that managers of these servers can create a secure environment. The assumptions need to be clearly defined to do that analysis. Once identified, the capabilities needed can be compared to what is available on any OS platform to identify possible gaps. This is one of a series of server usage profiles, which will be used to distinguish between security capabilities that are of general use, and those that have particular applicability to certain deployment scenarios. In particular, the environmental assumptions surrounding each scenario differ, and so the types of security capabilities each requires differ, too. Although the initial effort in creating server usage profiles is targeted at security, we intend this description to be good enough for other use cases to reference when they refer to server types, in this case a ”Departmental File / Print / Collaboration Server”. In other words, we want the description to be useful for discussions beyond the topic of security. --------------------------------- Target Acceptance --------------------------------- This document is intended to help drive acceptance of any missing features into the mainline Linux kernel or any utilities that are impacted. Test cases for newly developed or modified features can be designed with this use case in mind. --------------------------------- Participants/Roles --------------------------------- --- * Systems Administrator * Operations Staff --- Special class of user that has special privileges on a given system. This is a role held by an individual that acts as the administrator for the system or by an individual that might have a specific role within the administration role, for example responsibility for system backup. --- * Application Administrator --- Special class of user that has special privileges for a given application or service. This is a role held by an individual that acts as the administrator for all aspects of an application. Administrative duties among the various application administrators should be clearly separated. --- * User --- Any user on the system. This is a role that is held by all individuals using a system. The user can interact with the system through the processes associated with applications they are using. Root Users are users who have root privileges. They are typically the system administrator. Privileged users have some of the root user privileges, but not all. They are typically and operations staff member. --------------------------------- Scenarios --------------------------------- These “Departmental File / Print / Collaboration Server “systems, though normally deployed throughout the organization near the work groups and departments they generally serve, have begun to appear more often in centralized data center environments as the result of server consolidation and Virtual Network Computing (VNC) deployments providing user productivity solutions to non-Windows client machines. Increasing network bandwidth and reliability has reduced the need to place such servers physically near their users, and putting them near professional operations staff makes backup and recovery, as well as routine scheduled maintenance, more easily handled as they are in the data center. Because of the large number of concurrent users of such systems (1000 or more file system connections are not uncommon), system stability and reliable performance are critical operational objectives. Resource reservations, particularly for disk quotas, are common. The ability to back up user files while they're still open by network connection is important, even if most backup operations can be performed over-night when usage is less. It's common for there to be separate network interfaces on such systems dedicated to handling backup traffic to dedicated backup servers, and the use of shared storage arrays (SANs) is also becoming routine. Print queue services, when used, require access by users (with authority to cancel or restart their own jobs) as well as by departmental and centralized system administrators (to create new queues, modify queue characteristics, and to cancel aberrant jobs. There is a question as to whether, or when, mandatory access controls for document handling, printing and mailing is useful in general practice or not. Without extending controls to workstations where users manipulate the documents, controls will be weak, or require the use of network partitioning and gateways to monitor information flows (which is labor intensive and intrusive to many business practices). However, the ability to differentiate between internal and external communication (documents and messages), to be able to contain departmental or project documents and correspondence is becoming increasingly important. Support for labeled security protections for stored files and network connections is a growing need. . Hostile attackers are expected and are usually internal, typically not external attackers. There is a wide variance in the ways access control policies are formed.  Policies are expected to fall under a site-wide security policy, but is likely managed as a local server and may have differing policy control.  Other servers typically regard departmental servers as potentially hostile, due to occasional security policy mishandling on the part of departmental server administration or local policy decisions. Much depends upon the strength/influence of the corporate security group. Where centralized services (name, directory, authentication, VPN, etc.) are managed by a centralized group of experts (very common for distributed directories like Active Directory and eDirectory), it's common that there be enterprise-defined policies that bound the range of accesses allowed on subordinate / departmental servers. For instance, control of who may change what tree or global namespace a departmental server resides in is usually NOT left to the local administrators. Similarly, and for similar reasons, it's unusual for local administrators to have permission to split their local namespace into two or more partitions, or to join them together. Such namespace topology changing operations are generally reserved to a select group of network administrators because of the adverse effects that can happen if the namespace gets "broken". This comment is written from the perspective that large organizations are likely to have such a centralized network support group who's job it is to keep the enterprise services (and departmental servers) talking to each other and recognizing each others defined users. Also, both Active Directory and eDirectory have ways to limit, or filter, permissions inheritance at leaf nodes of the tree, so as to create greater local autonomy when that's desired. So, we don't assume that NIS (the old Yellowpages) or NT/Domains (the old LANMAN technology) is the most common deployed administrative model. We look instead to the modern enterprise distributed directory environments for guidance along these lines. They are what Microsoft and Novell customers (amoung others in the enterprise departmental server markets) deliver. Contrasting to this enterprise case is that of small to medium sized businesses. They can not carry the overhead associated with running these sorts of administrative infrastructures. Separation of administrative duties such as file/print administration might be needed, but in practice is rarely used. The need for security auditing varies widely, depending upon the sensitivity of the information present on, or processed by the server. Highly sensitive data-handling servers require much more monitoring/auditing than a server used for general purpose work. "Departmental server" covers a wide range of uses. Most will not require extraordinary monitoring. An NSA departmental server may, for example. Security auditing could be needed for: (1) system and application/service login attempts, both successful and failed, (2) security changes made by the system administrator or application administrator, (3) anything else important to the site policy, in particular, Departmental Servers may contain sensitive documents with restrictive ACLs whose access should be audited.  (4) IDS style auditing of things like network traffic analysis, or binary/configuration file checksum intrusion detection.   Although the above items might be important to audit, local policy makers or system administrators may not understand the need for auditing or may not have an audit administrator. --------------------------------- Implementation Notes --------------------------------- There are currently no implementation notes for implementing security on Departmental Servers. --------------------------------- References --------------------------------- [1] Security discussions can be found in the archives of the Security SIG: http://lists.osdl.org/pipermail/security_sig/ [2] Intrusion Detection Systems (IDS)on Linux Resources: http://www.linuxsecuritycentral.com/resources.php?title=Intrusion+Detection