[refpolicy] optional_policy blocks

[refpolicy] optional_policy blocks

[Guido Trentalancia]

Hello !

I am trying to build and test a modified version of the git reference
policy. It is being built of type MCS and not monolithic.

Unfortunately, it seems that for some reason all of the
"optional_policy" blocks that are often used in TE files are not being
compiled in.

The modules that should trigger the optional_policy blocks are all being
compiled and loaded...

What should I do to enable the inclusion of such blocks in the policy ?

>From searching the mailing list, I could only find out that in the past,
the module on which the optional block depends used to be defined at the
beginning of the optional block... But this should be deprecated now.

The optional blocks usually contain just one or more interface calls,
such as:

optional_policy(`
        policykit_dbus_chat(system_dbusd_t)
        policykit_domtrans_auth(system_dbusd_t)
        policykit_search_lib(system_dbusd_t)
')

where the interface calls are defined in policykit.if. This is actually
an example from an existing part of the git reference policy.

Regards,

Guido

[refpolicy] optional_policy blocks

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/18/2011 03:39 PM, Guido Trentalancia wrote:
> Hello !
> 
> I am trying to build and test a modified version of the git reference
> policy. It is being built of type MCS and not monolithic.
> 
> Unfortunately, it seems that for some reason all of the
> "optional_policy" blocks that are often used in TE files are not being
> compiled in.

Because optional policy does not apply to monolithic policy. All modules
are in a single module (the base module), thus all dependencies are
installed.

optional policy is used for modular policy where many modules reside in
their own policy module. This enabled you to add and remove specific
modules and introduces the issue of dependencies.

the optional policy (policy in optional policy blocks) say's if this
policy is available then use it and if its not available then ignore it.

> The modules that should trigger the optional_policy blocks are all being
> compiled and loaded...
> 
> What should I do to enable the inclusion of such blocks in the policy ?
> 
>>From searching the mailing list, I could only find out that in the past,
> the module on which the optional block depends used to be defined at the
> beginning of the optional block... But this should be deprecated now.
> 
> The optional blocks usually contain just one or more interface calls,
> such as:
> 
> optional_policy(`
>         policykit_dbus_chat(system_dbusd_t)
>         policykit_domtrans_auth(system_dbusd_t)
>         policykit_search_lib(system_dbusd_t)
> ')
> 
> where the interface calls are defined in policykit.if. This is actually
> an example from an existing part of the git reference policy.
> 
> Regards,
> 
> Guido
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk01qowACgkQMlxVo39jgT/uRgCgugiE3hqmnrf8JbLPyYB/EAt/
9vQAni6MpxtYHWwUyj6blAdPpkQGpu5f
=KC5C
-----END PGP SIGNATURE-----

[refpolicy] optional_policy blocks

[Guido Trentalancia]

Hello Dominick !

Thanks very much for your reply.

On Tue, 18/01/2011 at 15.58 +0100, Dominick Grift wrote:
> On 01/18/2011 03:39 PM, Guido Trentalancia wrote:
> > Hello !
> > 
> > I am trying to build and test a modified version of the git reference
> > policy. It is being built of type MCS and not monolithic.
> > 
> > Unfortunately, it seems that for some reason all of the
> > "optional_policy" blocks that are often used in TE files are not being
> > compiled in.
> 
> Because optional policy does not apply to monolithic policy. All modules
> are in a single module (the base module), thus all dependencies are
> installed.

I am not building a monolithic policy (please see my original message
above).

In any case, even if I was building a monolithic policy then I should
have the optional blocks compiled in for those "modules" that have been
compiled in the base.

What do you say ?

Regards,

Guido

[refpolicy] optional_policy blocks

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/18/2011 04:53 PM, Guido Trentalancia wrote:
> Hello Dominick !
> 
> Thanks very much for your reply.
> 
> On Tue, 18/01/2011 at 15.58 +0100, Dominick Grift wrote:
>> On 01/18/2011 03:39 PM, Guido Trentalancia wrote:
>>> Hello !
>>>
>>> I am trying to build and test a modified version of the git reference
>>> policy. It is being built of type MCS and not monolithic.
>>>
>>> Unfortunately, it seems that for some reason all of the
>>> "optional_policy" blocks that are often used in TE files are not being
>>> compiled in.
>>
>> Because optional policy does not apply to monolithic policy. All modules
>> are in a single module (the base module), thus all dependencies are
>> installed.
> 
> I am not building a monolithic policy (please see my original message
> above).

Whoops misread that part, sorry.

> In any case, even if I was building a monolithic policy then I should
> have the optional blocks compiled in for those "modules" that have been
> compiled in the base.

Sounds strange indeed. Are you sure it is not including any of the
policy in optional policy block or just some?

If it is just incidental then it could be an error in the interface in
the optional policy block.

If this really applies to all optional policy then i guess something
else is going on.

> What do you say ?
> 
> Regards,
> 
> Guido
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk01ujAACgkQMlxVo39jgT9sAgCglDJgFAq97b3V1BvZxBHa1oCU
WiEAoIOTryxPqZbJEgJ9Sm65cFC6w3Ko
=yS5d
-----END PGP SIGNATURE-----

[refpolicy] optional_policy blocks

[Guido Trentalancia]

Hello again !

On Tue, 18/01/2011 at 15.58 +0100, Dominick Grift wrote:
> On 01/18/2011 03:39 PM, Guido Trentalancia wrote:
> > Hello !
> > 
> > I am trying to build and test a modified version of the git reference
> > policy. It is being built of type MCS and not monolithic.
> > 
> > Unfortunately, it seems that for some reason all of the
> > "optional_policy" blocks that are often used in TE files are not being
> > compiled in.
> 
> Because optional policy does not apply to monolithic policy. All modules
> are in a single module (the base module), thus all dependencies are
> installed.
> 
> optional policy is used for modular policy where many modules reside in
> their own policy module. This enabled you to add and remove specific
> modules and introduces the issue of dependencies.
> 
> the optional policy (policy in optional policy blocks) say's if this
> policy is available then use it and if its not available then ignore it.

This is my understanding. optional_policy() is a macro. Such macro
allows to optionally call one or more interfaces depending on whether a
module is included in the policy.

The optional_policy() support macro implements this capability
differently depending on whether a monolithic policy, base module, or
loadable module is being built.

However, the concept from a policy writer's perspective is the same. If
the module is being included in the build process, then the interfaces
defined within the optional_policy block are also called.

I believe that for modular policies it expands to an "optional" block,
while for monolithic policies it expands to an "ifdef" block, see for
example:

http://selinuxproject.org/page/NB_RefPolicy#optional_policy_Macro

http://www.nsa.gov/research/selinux/list-archive/0601/thread_body117.shtml

In any case, from the point of view of this discussion it doesn't really
matter whether the policy being built is monolithic or modular. The
point is that apparently the macro does not get expanded and built. I am
doing: make install-src ; make conf ; make policy ; make install ; make
load as described in the INSTALL file for the reference policy. And
again, as already mentioned, the relative modules appears to be built
and loaded (they appear in policy/modules.conf and also in the output of
semodule -l).

What am I missing then ?

> Sounds strange indeed. Are you sure it is not including any of the
> policy in optional policy block or just some?
>
> If it is just incidental then it could be an error in the interface in
> the optional policy block.
>
> If this really applies to all optional policy then i guess something
> else is going on.

Very strange. I have not checked every optional block in the policy. For
sure, it is not including those that I have created.

If there was an error in the interface definition, then the compiler
would complain !

It might well be the case that none of the optional_policy() blocks got
compiled in....

Regards,

Guido

[refpolicy] optional_policy blocks

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/18/2011 05:16 PM, Guido Trentalancia wrote:
> Hello again !
> 
> On Tue, 18/01/2011 at 15.58 +0100, Dominick Grift wrote:
>> On 01/18/2011 03:39 PM, Guido Trentalancia wrote:
>>> Hello !
>>>
>>> I am trying to build and test a modified version of the git reference
>>> policy. It is being built of type MCS and not monolithic.
>>>
>>> Unfortunately, it seems that for some reason all of the
>>> "optional_policy" blocks that are often used in TE files are not being
>>> compiled in.
>>
>> Because optional policy does not apply to monolithic policy. All modules
>> are in a single module (the base module), thus all dependencies are
>> installed.
>>
>> optional policy is used for modular policy where many modules reside in
>> their own policy module. This enabled you to add and remove specific
>> modules and introduces the issue of dependencies.
>>
>> the optional policy (policy in optional policy blocks) say's if this
>> policy is available then use it and if its not available then ignore it.
> 
> This is my understanding. optional_policy() is a macro. Such macro
> allows to optionally call one or more interfaces depending on whether a
> module is included in the policy.
> 
> The optional_policy() support macro implements this capability
> differently depending on whether a monolithic policy, base module, or
> loadable module is being built.
> 
> However, the concept from a policy writer's perspective is the same. If
> the module is being included in the build process, then the interfaces
> defined within the optional_policy block are also called.
> 
> I believe that for modular policies it expands to an "optional" block,
> while for monolithic policies it expands to an "ifdef" block, see for
> example:
> 
> http://selinuxproject.org/page/NB_RefPolicy#optional_policy_Macro
> 
> http://www.nsa.gov/research/selinux/list-archive/0601/thread_body117.shtml
> 
> In any case, from the point of view of this discussion it doesn't really
> matter whether the policy being built is monolithic or modular. The
> point is that apparently the macro does not get expanded and built. I am
> doing: make install-src ; make conf ; make policy ; make install ; make
> load as described in the INSTALL file for the reference policy. And
> again, as already mentioned, the relative modules appears to be built
> and loaded (they appear in policy/modules.conf and also in the output of
> semodule -l).
> 
> What am I missing then ?
> 
>> Sounds strange indeed. Are you sure it is not including any of the
>> policy in optional policy block or just some?
>>
>> If it is just incidental then it could be an error in the interface in
>> the optional policy block.
>>
>> If this really applies to all optional policy then i guess something
>> else is going on.
> 
> Very strange. I have not checked every optional block in the policy. For
> sure, it is not including those that I have created.
> 
> If there was an error in the interface definition, then the compiler
> would complain !

No not always. That is why i mention it.

For example if you require a type that does not exist in a interface,
Then it will build but the optional policy will not be included.

> It might well be the case that none of the optional_policy() blocks got
> compiled in....
> 
> Regards,
> 
> Guido
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk01v1QACgkQMlxVo39jgT9VBgCfW5kYzuX7gquhMkl+Si9bogWv
Kw8An0A9KLpMPtYFsmVk0af4yXptlezz
=5oXR
-----END PGP SIGNATURE-----

[refpolicy] optional_policy blocks

[Guido Trentalancia]

Hello again !

On Tue, 18/01/2011 at 17.05 +0100, Dominick Grift wrote:
> Sounds strange indeed. Are you sure it is not including any of the
> policy in optional policy block or just some?
> 
> If it is just incidental then it could be an error in the interface in
> the optional policy block.
> 
> If this really applies to all optional policy then i guess something
> else is going on.

Everything has been sorted out now. Maybe I was just getting confused by
the many denials...

Optional policy blocks get included in the build.

I shall post my patch to the git reference policy very soon. Should it
be posted with PATCH or RFC in the subject of the message ? I need
comments... How do you generally post patches that need comments here ?

It would be a patch that allows the latest reference policy to work on a
modern system with dbus and xserver...

I look forward to hearing from you.

Regards,

Guido

[refpolicy] optional_policy blocks

[Chris PeBenito]

On 1/18/2011 3:56 PM, Guido Trentalancia wrote:
> Hello again !
>
> On Tue, 18/01/2011 at 17.05 +0100, Dominick Grift wrote:
>> Sounds strange indeed. Are you sure it is not including any of the
>> policy in optional policy block or just some?
>>
>> If it is just incidental then it could be an error in the interface in
>> the optional policy block.
>>
>> If this really applies to all optional policy then i guess something
>> else is going on.
>
> Everything has been sorted out now. Maybe I was just getting confused by
> the many denials...
>
> Optional policy blocks get included in the build.
>
> I shall post my patch to the git reference policy very soon. Should it
> be posted with PATCH or RFC in the subject of the message ? I need
> comments... How do you generally post patches that need comments here ?
>
> It would be a patch that allows the latest reference policy to work on a
> modern system with dbus and xserver...
>
> I look forward to hearing from you.

Here's the info for contributing:

http://oss.tresys.com/projects/refpolicy/wiki/HowToContribute

-- 
Chris PeBenito
<pebenito@gentoo.org>
Developer,
Hardened Gentoo Linux