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
http://www.tresys.com | oss.tresys.com
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
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
http://www.tresys.com | oss.tresys.com
-----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-----
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
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
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
http://www.tresys.com | oss.tresys.com