A big +1. Agree with Jim H. I am also very eager to see what has already been done and understand how we can leverage this integration and capability going forward!
g -- Glenn Brunette Distinguished Engineer Director, GSS Security Office Sun Microsystems, Inc. james hughes wrote: > Hi all. > > +2 (+1 for me and Glenn Faden who is unavailable at the moment). > > This is indeed a valuable project that has the potential for adding > significant security capabilities to the OpenSolaris. The interactions > of this technology with the existing Trusted Extensions feature is an > interesting possibility. > > James Hughes > Glenn Faden > > > > > On Feb 14, 2008, at 10:02 AM, Stephen Smalley wrote: > >> -- OPENSOLARIS PROJECT PROPOSAL -- >> >> Project Short Name: fmac >> >> Project Descriptive Name: Flexible Mandatory Access Control (FMAC) >> >> Project Synopsis: Flask/Type Enforcement in OpenSolaris >> >> Project Purpose: >> >> This project proposes to add the Flux Advanced Security Kernel (Flask) >> architecture and Type Enforcement (TE) to OpenSolaris. Flask and TE >> provide a flexible form of mandatory access control (MAC) that has >> been >> gaining popularity since its introduction in SELinux, SEBSD, and >> SEDarwin. Flask/TE has also been integrated into the Xen hypervisor >> and >> has been applied to applications such as the X server, D-BUS, and >> PostgreSQL. >> >> The goal of this research project is to enhance and complement >> existing >> OpenSolaris security mechanisms with Flask and TE technologies. >> >> The Flask architecture provides flexible support for a wide range of >> security policies. Flexibility is provided at two levels: one can >> plug >> and play different security servers (policy engines) behind a >> well-defined abstract security interface without needing to modify the >> rest of the system at all, and one can configure the example security >> server included in the reference implementation of Flask to achieve a >> wide range of security goals via its flexible TE and constraint-based >> models. The specific policy enforced by the kernel is dictated by the >> security server, and the example security server is driven by security >> policy configuration files which can include a diverse set of policy >> rules (e.g., type enforcement, role-based access control, and >> multi-level security). The flexibility of the system allows the policy >> to be modified and extended to customize the security policy as >> required >> for any given installation. >> >> Type enforcement is the central security model implemented by the >> example security server in the reference Flask implementation; the >> other >> security models leverage it as a building block. Like traditional MAC >> schemes such as BLP or Biba, TE makes decisions based on security >> labels >> on processes and objects, enforces access rules defined by >> administrators and/or organization, is able to confine malicious and >> flawed software, and is able to enforce system-wide security >> requirements. However, TE was designed to address the limitations of >> traditional mandatory mechanisms, such as providing protection and >> confinement of "trusted" subjects, expressing a wide range of security >> goals (confidentiality, integrity, least privilege, separation of >> duty, >> assured pipelines), taking the program/code being executed into >> account >> in security decisions in terms of its function and trustworthiness, >> and >> separating policy from enforcement. TE is a self-contained model, >> i.e. >> there is no external privilege mechanism on which it depends and >> analysis of its rule set is sufficient to understand the full >> ramifications of what is possible in the system, modulo bugs in the >> kernel. >> >> A project goal will be to preserve existing user-level APIs and only >> add >> new APIs to support additional functionality. This will ensure >> compatibility with existing OpenSolaris executables. >> >> The project will be based on a Flask source version that is compatible >> with licensing terms for the OpenSolaris ON (OS/Net) consolidation. >> >> An early proof of concept (POC) has been developed to demonstrate the >> viability of the project. The majority of the POC was accomplished >> in 3 >> weeks based on OpenSolaris build 72 thus demonstrating the portability >> of the Flask architecture and the adaptability of OpenSolaris. >> >> We expect source and BFU images to be available shortly after the >> project is approved to foster early community participation. >> >> The project will initially be staffed jointly by the United States >> National Security Agency and Sun Microsystems, Inc. Participation from >> the OpenSolaris community is highly encouraged. >> >> Proposed Sponsors: Security >> >> Initial set of proposed project leads: >> >> Stephen Smalley (United States National Security Agency) [O.S. id: >> sds] >> >> John Weeks (Sun Microsystems, Inc.) [O.S. id: jweeks] >> >> Project Needs: >> Project space (fmac) and a separate mailing list (fmac-discuss) for >> project discussions. >> >> Other interested participants: please speak up, or join the project >> list >> once we have it running. Contributions of both code and review time >> are >> obviously quite welcome; there's a lot of work to be done here. >> >> External Resources >> Flask http://www.flux.utah.edu/flux/flask >> SELinux http://www.nsa.gov/selinux >> SEBSD http://www.trustedbsd.org/sebsd.html >> SEDarwin http://sedarwin.org >> Xen Security Modules (XSM) & Flask port http://xen.org - in Xen 3.2 >> X Access Control Extension (XACE) & XSELinux http://x.org - in the >> trunk, targeted for xserver 1.5 >> SE-PostgreSQL http://code.google.com/p/sepgsql/ >> >> -- >> Stephen Smalley >> National Security Agency >> >> _______________________________________________ >> security-discuss mailing list >> security-discuss at opensolaris.org > > _______________________________________________ > security-discuss mailing list > security-discuss at opensolaris.org
