|
Replies:
8
-
Last Post:
Mar 7, 2008 12:42 AM
by: rlhamil
|
Threads:
[
Previous
|
Next
]
|
|
Posts:
5
From:
Registered:
1/7/08
|
|
|
|
Project Proposal: Flexible Mandatory Access Control (fmac)
Posted:
Feb 14, 2008 10:02 AM
|
|
-- 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 dot org
|
|
|
Posts:
50
From:
Palo Alto
Registered:
5/10/06
|
|
|
|
Re: Project Proposal: Flexible Mandatory Access Control (fmac)
Posted:
Feb 14, 2008 10:08 AM
in response to: sds
|
|
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 dot org
_______________________________________________
security-discuss mailing list
security-discuss at opensolaris dot org
|
|
|
|
|
Posts:
122
From:
US
Registered:
3/9/05
|
|
|
|
Re: Project Proposal: Flexible Mandatory Access Control (fmac)
Posted:
Feb 14, 2008 10:12 AM
in response to: hughejp
|
|
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 dot org
>
> _______________________________________________
> security-discuss mailing list
> security-discuss at opensolaris dot org
_______________________________________________
security-discuss mailing list
security-discuss at opensolaris dot org
|
|
|
|
|
Posts:
316
From:
US
Registered:
4/14/06
|
|
|
|
Re: Project Proposal: Flexible Mandatory Access Control (fmac)
Posted:
Feb 14, 2008 10:09 AM
in response to: sds
|
|
You have my endorsement.
--Glenn
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/
>
>
_______________________________________________
security-discuss mailing list
security-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,793
From:
GB
Registered:
3/9/05
|
|
|
|
Re: Project Proposal: Flexible Mandatory Access Control (fmac)
Posted:
Feb 14, 2008 10:14 AM
in response to: sds
|
|
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.
I think this is going to be a very interesting project for this
community and I fully support it being sponsored by this group.
+1 from me.
--
Darren J Moffat
_______________________________________________
security-discuss mailing list
security-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3
From:
US
Registered:
6/21/06
|
|
|
|
Re: Project Proposal: Flexible Mandatory Access Control (fmac)
Posted:
Feb 14, 2008 10:17 AM
in response to: sds
|
|
Hi Stephen and John,
I am very interested to support this effort. It is indeed a valuable
project for OpenSolaris and the security community.
Thank you for all your hard work!
Regards,
--John
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/
>
_______________________________________________
security-discuss mailing list
security-discuss at opensolaris dot org
|
|
|
|
|
Posts:
284
From:
US
Registered:
3/9/05
|
|
|
|
Re: Project Proposal: Flexible Mandatory Access Control (fmac)
Posted:
Feb 14, 2008 10:45 AM
in response to: sds
|
|
+1 (though the project has plenty of endorsements already)
I'm intrigued by the opportunity for synergy, rather than just
coexistence, between FMAC and the existing MAC mechanisms in OpenSolaris.
Scott
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/
>
_______________________________________________
security-discuss mailing list
security-discuss at opensolaris dot org
|
|
|
|
|
Posts:
5
From:
Registered:
1/7/08
|
|
|
|
Re: Project Proposal: Flexible Mandatory Access Control (fmac)
Posted:
Mar 5, 2008 1:06 PM
in response to: sds
|
|
On Thu, 2008-02-14 at 13:02 -0500, 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
The FMAC project is pleased to announce the availability of the project
page (http://www.opensolaris.org/os/project/fmac/) and discussion list
(fmac-discuss).
We are working on all the steps that are necessary to make materials
available for community participation and will announce progress on the
fmac-discuss list. If you are interested in the project, please join the
list to keep up to date with our activities.
We would also like to thank the OpenSolaris Security Community for their
support and endorsement of the project and we look forward to working
with them as we move forward.
Regards,
Stephen Smalley
John Weeks
_______________________________________________
security-discuss mailing list
security-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,580
From:
US
Registered:
6/14/05
|
|
|
|
Re: Project Proposal: Flexible Mandatory Access Control (fmac)
Posted:
Mar 7, 2008 12:42 AM
in response to: sds
To: Communities » security » discuss
|
|
> The FMAC project is pleased to announce the
> availability of the project
> page (http://www.opensolaris.org/os/project/fmac/)
> and discussion list
> (fmac-discuss).
>
> We are working on all the steps that are necessary to
> make materials
> available for community participation and will
> announce progress on the
> fmac-discuss list. If you are interested in the
> project, please join the
> list to keep up to date with our activities.
>
> We would also like to thank the OpenSolaris Security
> Community for their
> support and endorsement of the project and we look
> forward to working
> with them as we move forward.
>
> Regards,
>
> Stephen Smalley
> John Weeks
Please consider:
* adding a reading list to the project page, to help interested persons
get up to speed on the concepts and principles. Indeed, something
less than a course but more than _just_ a list of URLs might be helpful.
* adding the mailing list to the Jive forums, which for some people, may
be accessible under circumstances where a mailing list alone might not be.
* early posts in the discussion describing how fmac might usefully interact
with TSOL, FGAP, privileges(5), RBAC, POSIX-draft or NFSv4 style ACLs,
etc; i.e. all the considerable security features Solaris already possesses
over and above basic POSIX. It seems there was already interest expressed
in this; and it might be reasonable to expect that all should end up working
well together, without adverse interactions or obsoleting established
interfaces.
|
|
|
|
|
