[Security_sig] Dept print/file collaboration server use case

Mary Edie Meredith maryedie at osdl.org
Fri Aug 12 16:13:51 PDT 2005

Here is the final Security Use Case, posted here:
(FYI, I took out the clause that I questioned in my previous email to
the SIG).

Use Case:
Departmental File / Print / Collaboration Server
Version 0.1 (DRAFT)
Last Modified Date: 8/12/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

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.

* 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.

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.

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
(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.

[1] Security discussions can be found in the archives of the
Security SIG:

[2] Intrusion Detection Systems (IDS)on Linux Resources:

More information about the security_sig mailing list