* [refpolicy] ANN: Reference Policy contrib repository
@ 2011-09-09 15:35 ` Christopher J. PeBenito
0 siblings, 0 replies; 11+ messages in thread
From: Christopher J. PeBenito @ 2011-09-09 15:35 UTC (permalink / raw)
To: refpolicy
The challenge of Reference Policy has always been balancing the needs of having a well reviewed policy against responding to fairly rapid application development and new user needs in Linux. If you are not familiar with the differences between the Reference Policy and Fedora policy, it is quite large. Since Fedora is the largest SELinux-enabled distribution, its development version, rawhide, is on the front lines of seeing new features in apps. Due to Dan and Miroslav's extensive work, the Fedora policy evolves rapidly. However, this has proven to be too fast for me to constantly review all the changes and integrate them upstream, resulting in the huge difference between the two policies.
To ameliorate this situation, additional contributors with commit access have been added for Reference Policy. To be specific, a large amount of the policy has been moved into a contrib layer (a git submodule), where these contributors may commit. The core policy modules will remain in the primary Reference Policy repository, for which I remain the maintainer. Due to its nature, the contrib repository will be faster moving and less reviewed than the core Reference Policy repository.
The core modules are critical modules on the system. This includes all of the kernel layer, most of the system and roles layers, some admin modules, such as bootloader, su, and sudo, and userspace object managers. It is possible to build a policy using only the core modules. It is important to ensure these modules are well reviewed to ensure quality, so Reference Policy can be used as a base for both general-purpose systems (e.g. Linux distributions) and custom systems. All remaining modules were moved to the contrib repository. An important thing to note is that in the future, modules may move between core and contrib as necessary.
For those that have a current checkout of the repository, you will need to do the following to get the new contrib submodule:
$ git pull
$ git submodule init
$ git submodule update
If you are looking to check out the repository for the first time, the instructions are at:
http://oss.tresys.com/projects/refpolicy/wiki/RepositoryCheckout
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ANN: Reference Policy contrib repository
2011-09-09 15:35 ` [refpolicy] " Christopher J. PeBenito
(?)
@ 2011-09-09 15:58 ` Robert Lee
2011-09-09 16:17 ` [refpolicy] " Christopher J. PeBenito
-1 siblings, 1 reply; 11+ messages in thread
From: Robert Lee @ 2011-09-09 15:58 UTC (permalink / raw)
To: Christopher J. PeBenito; +Cc: SELinux Mail List, Refpolicy Mail List
Will this change affect the overall quality of the reference policy from
a security/vetting standpoint?
On Fri, 2011-09-09 at 11:35 -0400, Christopher J. PeBenito wrote:
> The challenge of Reference Policy has always been balancing the needs of having a well reviewed policy against responding to fairly rapid application development and new user needs in Linux. If you are not familiar with the differences between the Reference Policy and Fedora policy, it is quite large. Since Fedora is the largest SELinux-enabled distribution, its development version, rawhide, is on the front lines of seeing new features in apps. Due to Dan and Miroslav's extensive work, the Fedora policy evolves rapidly. However, this has proven to be too fast for me to constantly review all the changes and integrate them upstream, resulting in the huge difference between the two policies.
>
> To ameliorate this situation, additional contributors with commit access have been added for Reference Policy. To be specific, a large amount of the policy has been moved into a contrib layer (a git submodule), where these contributors may commit. The core policy modules will remain in the primary Reference Policy repository, for which I remain the maintainer. Due to its nature, the contrib repository will be faster moving and less reviewed than the core Reference Policy repository.
>
> The core modules are critical modules on the system. This includes all of the kernel layer, most of the system and roles layers, some admin modules, such as bootloader, su, and sudo, and userspace object managers. It is possible to build a policy using only the core modules. It is important to ensure these modules are well reviewed to ensure quality, so Reference Policy can be used as a base for both general-purpose systems (e.g. Linux distributions) and custom systems. All remaining modules were moved to the contrib repository. An important thing to note is that in the future, modules may move between core and contrib as necessary.
>
> For those that have a current checkout of the repository, you will need to do the following to get the new contrib submodule:
>
> $ git pull
> $ git submodule init
> $ git submodule update
>
> If you are looking to check out the repository for the first time, the instructions are at:
> http://oss.tresys.com/projects/refpolicy/wiki/RepositoryCheckout
>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ANN: Reference Policy contrib repository
2011-09-09 15:58 ` Robert Lee
@ 2011-09-09 16:17 ` Christopher J. PeBenito
0 siblings, 0 replies; 11+ messages in thread
From: Christopher J. PeBenito @ 2011-09-09 16:17 UTC (permalink / raw)
To: Robert Lee; +Cc: SELinux Mail List, Refpolicy Mail List
On 09/09/11 11:58, Robert Lee wrote:
> Will this change affect the overall quality of the reference policy from
> a security/vetting standpoint?
I don't expect it to. The expectation of the committers is the same as it is for me. I'll still be looking through commits being made, and the committers should be looking at each other's commits too. Additionally, the way git submodules work (the same as svn externals, if you're familiar) means that the main Reference Policy repo will pin a particular revision of the contrib repo, so you should always get a known good state, not necessarily the current contrib repo state. Additionally, changes to the contrib modules are normally less/non controversial, since they're generally the best understood applications (eg apache, samba, etc).
> On Fri, 2011-09-09 at 11:35 -0400, Christopher J. PeBenito wrote:
>> The challenge of Reference Policy has always been balancing the needs of having a well reviewed policy against responding to fairly rapid application development and new user needs in Linux. If you are not familiar with the differences between the Reference Policy and Fedora policy, it is quite large. Since Fedora is the largest SELinux-enabled distribution, its development version, rawhide, is on the front lines of seeing new features in apps. Due to Dan and Miroslav's extensive work, the Fedora policy evolves rapidly. However, this has proven to be too fast for me to constantly review all the changes and integrate them upstream, resulting in the huge difference between the two policies.
>>
>> To ameliorate this situation, additional contributors with commit access have been added for Reference Policy. To be specific, a large amount of the policy has been moved into a contrib layer (a git submodule), where these contributors may commit. The core policy modules will remain in the primary Reference Policy repository, for which I remain the maintainer. Due to its nature, the contrib repository will be faster moving and less reviewed than the core Reference Policy repository.
>>
>> The core modules are critical modules on the system. This includes all of the kernel layer, most of the system and roles layers, some admin modules, such as bootloader, su, and sudo, and userspace object managers. It is possible to build a policy using only the core modules. It is important to ensure these modules are well reviewed to ensure quality, so Reference Policy can be used as a base for both general-purpose systems (e.g. Linux distributions) and custom systems. All remaining modules were moved to the contrib repository. An important thing to note is that in the future, modules may move between core and contrib as necessary.
>>
>> For those that have a current checkout of the repository, you will need to do the following to get the new contrib submodule:
>>
>> $ git pull
>> $ git submodule init
>> $ git submodule update
>>
>> If you are looking to check out the repository for the first time, the instructions are at:
>> http://oss.tresys.com/projects/refpolicy/wiki/RepositoryCheckout
>>
>
>
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] ANN: Reference Policy contrib repository
@ 2011-09-09 16:17 ` Christopher J. PeBenito
0 siblings, 0 replies; 11+ messages in thread
From: Christopher J. PeBenito @ 2011-09-09 16:17 UTC (permalink / raw)
To: refpolicy
On 09/09/11 11:58, Robert Lee wrote:
> Will this change affect the overall quality of the reference policy from
> a security/vetting standpoint?
I don't expect it to. The expectation of the committers is the same as it is for me. I'll still be looking through commits being made, and the committers should be looking at each other's commits too. Additionally, the way git submodules work (the same as svn externals, if you're familiar) means that the main Reference Policy repo will pin a particular revision of the contrib repo, so you should always get a known good state, not necessarily the current contrib repo state. Additionally, changes to the contrib modules are normally less/non controversial, since they're generally the best understood applications (eg apache, samba, etc).
> On Fri, 2011-09-09 at 11:35 -0400, Christopher J. PeBenito wrote:
>> The challenge of Reference Policy has always been balancing the needs of having a well reviewed policy against responding to fairly rapid application development and new user needs in Linux. If you are not familiar with the differences between the Reference Policy and Fedora policy, it is quite large. Since Fedora is the largest SELinux-enabled distribution, its development version, rawhide, is on the front lines of seeing new features in apps. Due to Dan and Miroslav's extensive work, the Fedora policy evolves rapidly. However, this has proven to be too fast for me to constantly review all the changes and integrate them upstream, resulting in the huge difference between the two policies.
>>
>> To ameliorate this situation, additional contributors with commit access have been added for Reference Policy. To be specific, a large amount of the policy has been moved into a contrib layer (a git submodule), where these contributors may commit. The core policy modules will remain in the primary Reference Policy repository, for which I remain the maintainer. Due to its nature, the contrib repository will be faster moving and less reviewed than the core Reference Policy repository.
>>
>> The core modules are critical modules on the system. This includes all of the kernel layer, most of the system and roles layers, some admin modules, such as bootloader, su, and sudo, and userspace object managers. It is possible to build a policy using only the core modules. It is important to ensure these modules are well reviewed to ensure quality, so Reference Policy can be used as a base for both general-purpose systems (e.g. Linux distributions) and custom systems. All remaining modules were moved to the contrib repository. An important thing to note is that in the future, modules may move between core and contrib as necessary.
>>
>> For those that have a current checkout of the repository, you will need to do the following to get the new contrib submodule:
>>
>> $ git pull
>> $ git submodule init
>> $ git submodule update
>>
>> If you are looking to check out the repository for the first time, the instructions are at:
>> http://oss.tresys.com/projects/refpolicy/wiki/RepositoryCheckout
>>
>
>
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] ANN: Reference Policy contrib repository
2011-09-09 15:35 ` [refpolicy] " Christopher J. PeBenito
(?)
(?)
@ 2011-09-09 16:22 ` Guido Trentalancia
2011-09-09 16:28 ` Christopher J. PeBenito
-1 siblings, 1 reply; 11+ messages in thread
From: Guido Trentalancia @ 2011-09-09 16:22 UTC (permalink / raw)
To: refpolicy
On Fri, 2011-09-09 at 11:35 -0400, Christopher J. PeBenito wrote:
> The challenge of Reference Policy has always been balancing the needs of having a well reviewed policy against responding to fairly rapid application development and new user needs in Linux. If you are not familiar with the differences between the Reference Policy and Fedora policy, it is quite large. Since Fedora is the largest SELinux-enabled distribution, its development version, rawhide, is on the front lines of seeing new features in apps. Due to Dan and Miroslav's extensive work, the Fedora policy evolves rapidly. However, this has proven to be too fast for me to constantly review all the changes and integrate them upstream, resulting in the huge difference between the two policies.
>
> To ameliorate this situation, additional contributors with commit access have been added for Reference Policy. To be specific, a large amount of the policy has been moved into a contrib layer (a git submodule), where these contributors may commit. The core policy modules will remain in the primary Reference Policy repository, for which I remain the maintainer. Due to its nature, the contrib repository will be faster moving and less reviewed than the core Reference Policy repository.
>
> The core modules are critical modules on the system. This includes all of the kernel layer, most of the system and roles layers, some admin modules, such as bootloader, su, and sudo, and userspace object managers. It is possible to build a policy using only the core modules. It is important to ensure these modules are well reviewed to ensure quality, so Reference Policy can be used as a base for both general-purpose systems (e.g. Linux distributions) and custom systems. All remaining modules were moved to the contrib repository. An important thing to note is that in the future, modules may move between core and contrib as necessary.
>
> For those that have a current checkout of the repository, you will need to do the following to get the new contrib submodule:
>
> $ git pull
> $ git submodule init
> $ git submodule update
Is such "contrib" submodule going to always remain optional ?
> If you are looking to check out the repository for the first time, the instructions are at:
> http://oss.tresys.com/projects/refpolicy/wiki/RepositoryCheckout
Regards,
Guido
^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] ANN: Reference Policy contrib repository
2011-09-09 16:22 ` Guido Trentalancia
@ 2011-09-09 16:28 ` Christopher J. PeBenito
2011-09-12 20:45 ` Daniel J Walsh
0 siblings, 1 reply; 11+ messages in thread
From: Christopher J. PeBenito @ 2011-09-09 16:28 UTC (permalink / raw)
To: refpolicy
On 09/09/11 12:22, Guido Trentalancia wrote:
> On Fri, 2011-09-09 at 11:35 -0400, Christopher J. PeBenito wrote:
>> The challenge of Reference Policy has always been balancing the needs of having a well reviewed policy against responding to fairly rapid application development and new user needs in Linux. If you are not familiar with the differences between the Reference Policy and Fedora policy, it is quite large. Since Fedora is the largest SELinux-enabled distribution, its development version, rawhide, is on the front lines of seeing new features in apps. Due to Dan and Miroslav's extensive work, the Fedora policy evolves rapidly. However, this has proven to be too fast for me to constantly review all the changes and integrate them upstream, resulting in the huge difference between the two policies.
>>
>> To ameliorate this situation, additional contributors with commit access have been added for Reference Policy. To be specific, a large amount of the policy has been moved into a contrib layer (a git submodule), where these contributors may commit. The core policy modules will remain in the primary Reference Policy repository, for which I remain the maintainer. Due to its nature, the contrib repository will be faster moving and less reviewed than the core Reference Policy repository.
>>
>> The core modules are critical modules on the system. This includes all of the kernel layer, most of the system and roles layers, some admin modules, such as bootloader, su, and sudo, and userspace object managers. It is possible to build a policy using only the core modules. It is important to ensure these modules are well reviewed to ensure quality, so Reference Policy can be used as a base for both general-purpose systems (e.g. Linux distributions) and custom systems. All remaining modules were moved to the contrib repository. An important thing to note is that in the future, modules may move between core and contrib as necessary.
>>
>> For those that have a current checkout of the repository, you will need to do the following to get the new contrib submodule:
>>
>> $ git pull
>> $ git submodule init
>> $ git submodule update
>
> Is such "contrib" submodule going to always remain optional ?
Its optional in the sense that you don't have to use any modules from it. The core modules do have some optionals that reference contrib modules, so you need to have the submodule checked out so that those interfaces can resolve. However, there should be no unconditional references from core modules to anything in contrib.
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] ANN: Reference Policy contrib repository
2011-09-09 16:28 ` Christopher J. PeBenito
@ 2011-09-12 20:45 ` Daniel J Walsh
2011-09-13 21:12 ` Dominick Grift
0 siblings, 1 reply; 11+ messages in thread
From: Daniel J Walsh @ 2011-09-12 20:45 UTC (permalink / raw)
To: refpolicy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/09/2011 12:28 PM, Christopher J. PeBenito wrote:
> On 09/09/11 12:22, Guido Trentalancia wrote:
>> On Fri, 2011-09-09 at 11:35 -0400, Christopher J. PeBenito
>> wrote:
>>> The challenge of Reference Policy has always been balancing the
>>> needs of having a well reviewed policy against responding to
>>> fairly rapid application development and new user needs in
>>> Linux. If you are not familiar with the differences between
>>> the Reference Policy and Fedora policy, it is quite large.
>>> Since Fedora is the largest SELinux-enabled distribution, its
>>> development version, rawhide, is on the front lines of seeing
>>> new features in apps. Due to Dan and Miroslav's extensive
>>> work, the Fedora policy evolves rapidly. However, this has
>>> proven to be too fast for me to constantly review all the
>>> changes and integrate them upstream, resulting in the huge
>>> difference between the two policies.
>>>
>>> To ameliorate this situation, additional contributors with
>>> commit access have been added for Reference Policy. To be
>>> specific, a large amount of the policy has been moved into a
>>> contrib layer (a git submodule), where these contributors may
>>> commit. The core policy modules will remain in the primary
>>> Reference Policy repository, for which I remain the maintainer.
>>> Due to its nature, the contrib repository will be faster moving
>>> and less reviewed than the core Reference Policy repository.
>>>
>>> The core modules are critical modules on the system. This
>>> includes all of the kernel layer, most of the system and roles
>>> layers, some admin modules, such as bootloader, su, and sudo,
>>> and userspace object managers. It is possible to build a
>>> policy using only the core modules. It is important to ensure
>>> these modules are well reviewed to ensure quality, so Reference
>>> Policy can be used as a base for both general-purpose systems
>>> (e.g. Linux distributions) and custom systems. All remaining
>>> modules were moved to the contrib repository. An important
>>> thing to note is that in the future, modules may move between
>>> core and contrib as necessary.
>>>
>>> For those that have a current checkout of the repository, you
>>> will need to do the following to get the new contrib
>>> submodule:
>>>
>>> $ git pull $ git submodule init $ git submodule update
>>
>> Is such "contrib" submodule going to always remain optional ?
>
> Its optional in the sense that you don't have to use any modules
> from it. The core modules do have some optionals that reference
> contrib modules, so you need to have the submodule checked out so
> that those interfaces can resolve. However, there should be no
> unconditional references from core modules to anything in contrib.
>
AS we move to this new format, I would suggest we require multiple at
least 2 ACKs to get a policy update. I don't think Fedora team should
just dump our policy into the contrib without having someone review it.
Dominick Grift has done a lot of work in this space and if he would be
willing to help that would be great.
Anyone else who would like to volunteer. I think Miroslav and I have
to work to get the Rawhide/F16 policy based off the new structure and
then make the Fedora policy available for others to begin acking.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5ub4EACgkQrlYvE4MpobNTBwCg6ECrXiE7l5WJ9lWiSNBOO+VO
yVIAniiCsuqld4N/7gxXSNMAYM9vvTur
=R+ab
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] ANN: Reference Policy contrib repository
2011-09-12 20:45 ` Daniel J Walsh
@ 2011-09-13 21:12 ` Dominick Grift
0 siblings, 0 replies; 11+ messages in thread
From: Dominick Grift @ 2011-09-13 21:12 UTC (permalink / raw)
To: refpolicy
Op 12-9-2011 22:45, Daniel J Walsh schreef:
>
> AS we move to this new format, I would suggest we require multiple at
> least 2 ACKs to get a policy update. I don't think Fedora team should
> just dump our policy into the contrib without having someone review it.
>
> Dominick Grift has done a lot of work in this space and if he would be
> willing to help that would be great.
>
> Anyone else who would like to volunteer. I think Miroslav and I have
> to work to get the Rawhide/F16 policy based off the new structure and
> then make the Fedora policy available for others to begin acking.
Sure, i will be willing to review patches. Where should they be sent to
for review? This list?
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110913/c35681ac/attachment.bin
^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] ANN: Reference Policy contrib repository
2011-09-09 15:35 ` [refpolicy] " Christopher J. PeBenito
` (2 preceding siblings ...)
(?)
@ 2011-09-13 21:31 ` Dominick Grift
2011-09-14 12:19 ` Christopher J. PeBenito
-1 siblings, 1 reply; 11+ messages in thread
From: Dominick Grift @ 2011-09-13 21:31 UTC (permalink / raw)
To: refpolicy
Op 9-9-2011 17:35, Christopher J. PeBenito schreef:
> The core modules are critical modules on the system. This includes all of the kernel layer, most of the system and roles layers, some admin modules, such as bootloader, su, and sudo, and userspace object managers. It is possible to build a policy using only the core modules. It is important to ensure these modules are well reviewed to ensure quality, so Reference Policy can be used as a base for both general-purpose systems (e.g. Linux distributions) and custom systems. All remaining modules were moved to the contrib repository. An important thing to note is that in the future, modules may move between core and contrib as necessary.
I like this, although i would prefer the core to be only the base
modules (kernel layer) but it will not build without atleast a user,
which is a pity.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110913/25218246/attachment.bin
^ permalink raw reply [flat|nested] 11+ messages in thread* [refpolicy] ANN: Reference Policy contrib repository
2011-09-13 21:31 ` Dominick Grift
@ 2011-09-14 12:19 ` Christopher J. PeBenito
0 siblings, 0 replies; 11+ messages in thread
From: Christopher J. PeBenito @ 2011-09-14 12:19 UTC (permalink / raw)
To: refpolicy
On 09/13/11 17:31, Dominick Grift wrote:
> Op 9-9-2011 17:35, Christopher J. PeBenito schreef:
>> The core modules are critical modules on the system. This includes all of the kernel layer, most of the system and roles layers, some admin modules, such as bootloader, su, and sudo, and userspace object managers. It is possible to build a policy using only the core modules. It is important to ensure these modules are well reviewed to ensure quality, so Reference Policy can be used as a base for both general-purpose systems (e.g. Linux distributions) and custom systems. All remaining modules were moved to the contrib repository. An important thing to note is that in the future, modules may move between core and contrib as necessary.
>
> I like this, although i would prefer the core to be only the base
> modules (kernel layer) but it will not build without atleast a user,
> which is a pity.
This split was chosen because very few systems, if any, build their policy starting with only the kernel layer.
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
^ permalink raw reply [flat|nested] 11+ messages in thread