SAKAI FOUNDATION SECURITY POLI
Consider bracketed text as notes to self only
NOTICE: If you uncover what you consider to be
vulnerability in Sakai please notify the Sakai Foundation immediately at
Sakai is an open-source software initiative that promotes knowledge sharing and information transparency. However, when dealing with security vulnerabilities the integrity of existing Sakai installations can be compromised
by the premature public disclosure of security threats before the Sakai Community has had time to analyze, develop and distribute countermeasures through
channels to institutions and organizations that have implemented Sakai software.
Recognizing this danger, the Sakai Foundation has developed a security policy that seeks to safeguard the security of existing Sakai installations as well as provide full public disclosure of Sakai security vulnerabilities in a timely manner.
REPORTING SECURITY ISSUES
Security vulnerabilities in Sakai should be reported immediately to the Sakai Foundation at firstname.lastname@example.org . Sakai Foundation staff and community developers, working with the original reporter of the vulnerability, will investigate the issue, determine versions affected, and, if necessary, develop and distribute a security update for the Sakai Community and general public.
Issues identified as security-related are prioritized and addressed differently than functionality or other issues classified as “bugs.” Access to issues flagged as security vulnerabilities in Sakai’s JIRA issue tracking system will be restricted to Sakai security contacts and members of the Sakai Security Work Group.
Discussion, analysis, code development and testing relevant to a reported security vulnerability will be limited to
a known group
of Sakai Community members
and will be treated as confidential information.
The Sakai Foundation will work with Sakai Community members to develop fixes for both vulnerable released versions and vulnerable branches (up to a particular date or release number). Code commits for security-related fixes will seek to mask the nature of the vulnerability. This usually takes one of two forms: (1) the commit is held until a patch can be tested, distributed and implemented in known sites or (2) in the case of a fix to a less significant threat the commit may be checked in with limited commentary.
During our QA and release cycles security-related issues will receive priority
. . . .
The Sakai Foundation will issue security advisories and security updates to the general public once existing Sakai installations have been notified and given time to patch their systems.
Whenever Sakai security vulnerabilities surface, the Sakai Foundation
a three-step security advisory protocol in order to alert (1) Sakai Foundation partners and designated security contacts associated with known Sakai implementations, (2) the wider Sakai Community, and (3) the public at large regarding security issues.
The first step in our protocol involves providing alerts to our partner institutions and organizations as well as to our security contacts throughout the Sakai Community via the use of private communication channels. We delay deliberately the issuance of community-wide and public security advisories in order to allow time for security updates to be devised, tested, distributed and, if necessary, applied to Sakai installations that are known to the Foundation. Once these systems are patched the wider Sakai Community is alerted and time provided for Sakai implementers unknown to the Foundation to identify themselves, designate security contacts, and patch their systems before we proceed to the third and final step in our security advisory protocol, the general public announcement.
The Sakai Foundation encourages institutions and organizations email@example.com
utilizing Sakai to
their Sakai installation(s) with the Foundation as well as designate one or more individuals to be added to the Foundation’s security contact list.
As noted above, Sakai security contacts receive security updates in advance of public release in order
their institution or organization
to patch their Sakai installation before a
Sakai security vulnerability becomes general knowledge. Designated security contacts are also provided access rights to view, comment and address issues flagged as security items in Sakai’s JIRA issue tracking application. Security-related JIRA issues are hidden from public view.
not grant access to these JIRA items lightly and we verify the identity and role of each person who is designated as a security contact.
SECURITY WORK GROUP
The Sakai Community has instituted
a security work group
composed of senior members of the community
that provides a core group of individuals available
to respond to reports of security vulnerabilities
[ADD MORE TEXT]
SECURITY THREAT LEVELS
Release documentation for s
will identify the Sakai version affected including code branches
by the threat level index listed below:
[THESE DEFINITIONS NEED REVIEW AND POSSIBLE EXPANSION]
A security vulnerability classified as critical involves the possible exposure of sensitive or private data to unauthorized disclosure or acquisition.
[NOTE: Client-side and command execution attacks such as content spoofing, cross-site scripting (XSS) or SQL injection that could result in session hijacking and user impersonation. Other classes of attack that can result in information disclosure include: insufficient authentication/authorization, brute force credential attacks, weak password recovery validation, credential/session prediction, insufficient session expiration, session fixation, directory indexing, information leakage, path traversal and predictable resource location.]
classified as high
logical attacks that could compromise the availability of Sakai or otherwise degrade system performance, disrupt or circumvent normal application flow control of Sakai tools and services or use Sakai as a platform for attacks on other systems.
[NOTE: logical attacks include: denial of service, abuse of functionality, insufficient anti-automation, insufficient process validation. Command execution attacks include: buffer overflow, format string attack, LDAP injection, OS commanding, SQL injection, SSI injection and XPath injection (requires user-supplied input).]
classified as moderate
is one wh
by modifying existing configurations
. . . .
All other security vulnerabilities are classified as
. Such security vulnerabilities are considered (1) difficult for attackers to exploit or (2), if exploited, are of minor consequence to the operation of Sakai installations.