Guideline for RPM packages

Guideline for RPM packages

[KaiGai Kohei]

If I remember correctly, someone posted a guideline to make
a RPM package which contains binary security policy, several
weeks ago.

If you know the URL, would you tell me the location?

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
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.

Re: Guideline for RPM packages

[Stephen Smalley]

On Thu, 2007-06-07 at 23:32 +0900, KaiGai Kohei wrote:
> If I remember correctly, someone posted a guideline to make
> a RPM package which contains binary security policy, several
> weeks ago.
> 
> If you know the URL, would you tell me the location?

There is a draft guide at:
http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules

-- 
Stephen Smalley
National Security Agency


--
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.

Re: Guideline for RPM packages

[KaiGai Kohei]

Stephen Smalley wrote:
> On Thu, 2007-06-07 at 23:32 +0900, KaiGai Kohei wrote:
>> If I remember correctly, someone posted a guideline to make
>> a RPM package which contains binary security policy, several
>> weeks ago.
>>
>> If you know the URL, would you tell me the location?
> 
> There is a draft guide at:
> http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules

Thanks, so much!
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
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.

Re: Guideline for RPM packages

[KaiGai Kohei]

>>> If I remember correctly, someone posted a guideline to make
>>> a RPM package which contains binary security policy, several
>>> weeks ago.
>>>
>>> If you know the URL, would you tell me the location?
>> There is a draft guide at:
>> http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules
> 
> Thanks, so much!

I have a comment for the Policy Module Packaging Guideline.

The document says every *.pp files should be installed for any sort of policies
(targeted, strict, mls) in the %post section.
However, it can cause a problem when a part of policies are not installed yet.

When we try to install an application including policy package on the system
which has only targeted policy, installation of *.pp files for strict/mls will
be failed no need to say.
If we want to install selinux-policy-strict or -mls later, the oraphan *.pp files
are not linked automatically because "/usr/bin/semodule -i" is not invoked.
It will cause a simple problem, but a bit difficult to find out.

I have an idea that uses "%triggerin" to invoke "/use/bin/semodule -i" to link
orphan *.pp files on instllation of selinux-policy-* packages later, as follows:

----------------
  %triggerin -- selinux-policy-targeted
  if [ $0 -eq 1 ]; then
      /usr/sbin/semodule -s targeted -i %{_datadir}/selinux/targeted/mymodule.pp &> /dev/null || :
  fi
  %triggerin -- selinux-policy-strict
  if [ $0 -eq 1 ]; then
      /usr/sbin/semodule -s strict -i %{_datadir}/selinux/strict/mymodule.pp &> /dev/null || :
  fi
  %triggerin -- selinux-policy-mls
  if [ $0 -eq 1 ]; then
      /usr/sbin/semodule -s mls -i %{_datadir}/selinux/mls/mymodule.pp &> /dev/null || :
  fi
----------------

If the application is installed on the system which already has selinux-policy-strict,
"%triggerin -- selinux-policy-strict" will be invoked just when the application is
installed, so there is no degrading.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.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.

SE-PostgreSQL for Fedora (Re: Guideline for RPM packages)

[KaiGai Kohei]

By the way, I'm seeking sponsors who can review SE-PostgreSQL package.

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249522

If you can volunteer the reviewing process, please contact me.

Thanks,

>>>> If I remember correctly, someone posted a guideline to make
>>>> a RPM package which contains binary security policy, several
>>>> weeks ago.
>>>>
>>>> If you know the URL, would you tell me the location?
>>> There is a draft guide at:
>>> http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules
>> Thanks, so much!
> 
> I have a comment for the Policy Module Packaging Guideline.
> 
> The document says every *.pp files should be installed for any sort of policies
> (targeted, strict, mls) in the %post section.
> However, it can cause a problem when a part of policies are not installed yet.
> 
> When we try to install an application including policy package on the system
> which has only targeted policy, installation of *.pp files for strict/mls will
> be failed no need to say.
> If we want to install selinux-policy-strict or -mls later, the oraphan *.pp files
> are not linked automatically because "/usr/bin/semodule -i" is not invoked.
> It will cause a simple problem, but a bit difficult to find out.
> 
> I have an idea that uses "%triggerin" to invoke "/use/bin/semodule -i" to link
> orphan *.pp files on instllation of selinux-policy-* packages later, as follows:
> 
> ----------------
>   %triggerin -- selinux-policy-targeted
>   if [ $0 -eq 1 ]; then
>       /usr/sbin/semodule -s targeted -i %{_datadir}/selinux/targeted/mymodule.pp &> /dev/null || :
>   fi
>   %triggerin -- selinux-policy-strict
>   if [ $0 -eq 1 ]; then
>       /usr/sbin/semodule -s strict -i %{_datadir}/selinux/strict/mymodule.pp &> /dev/null || :
>   fi
>   %triggerin -- selinux-policy-mls
>   if [ $0 -eq 1 ]; then
>       /usr/sbin/semodule -s mls -i %{_datadir}/selinux/mls/mymodule.pp &> /dev/null || :
>   fi
> ----------------
> 
> If the application is installed on the system which already has selinux-policy-strict,
> "%triggerin -- selinux-policy-strict" will be invoked just when the application is
> installed, so there is no degrading.
> 
> Thanks,

--
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
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.

Re: SE-PostgreSQL for Fedora (Re: Guideline for RPM packages)

[Joshua Brindle]

KaiGai Kohei wrote:
> By the way, I'm seeking sponsors who can review SE-PostgreSQL package.
>
>   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249522
>
> If you can volunteer the reviewing process, please contact me.
>   

So, I tried grabbing the sepostgres srpm and building it (you didn't
provide an x86_64 rpm) and I get these compilation errors:

gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall
-Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -D
SECCLASS_DATABASE= -I../../../src/include -D_GNU_SOURCE -c -o
sepgsqlCore.o sepgsqlCore.c
sepgsqlCore.c: In function 'sepgsqlGetDatabaseContext':
sepgsqlCore.c:792: error: expected expression before ')' token
sepgsqlCore.c: In function 'sepgsqlInitialize':
sepgsqlCore.c:836: error: expected expression before ',' token
sepgsqlCore.c:854: error: expected expression before ',' token
make[3]: *** [sepgsqlCore.o] Error 1
make[3]: Leaving directory
`/usr/src/redhat/BUILD/postgresql-8.2.4/src/backend/security'
make[2]: *** [security-recursive] Error 2


As an aside to this, I notice that you tried to integrate policy
management into the RPM, and I had to modify my spec file to not do this
because I have my own custom policies on the system. I don't think this
is the best way, long term, to handle policy integration, though,
unfortunately, I don't have any better suggestions. This is something I
intend to look into soon though so I'll provide some feedback on the
previous thread when I have something useful to say :)


--
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.

Re: SE-PostgreSQL for Fedora (Re: Guideline for RPM packages)

[KaiGai Kohei]

Joshua Brindle wrote:
> KaiGai Kohei wrote:
>> By the way, I'm seeking sponsors who can review SE-PostgreSQL package.
>>
>>   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249522
>>
>> If you can volunteer the reviewing process, please contact me.
>>   
> 
> So, I tried grabbing the sepostgres srpm and building it (you didn't
> provide an x86_64 rpm) and I get these compilation errors:
> 
> gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall
> -Wmissing-prototypes -Wpointer-arith -Winline
> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -D
> SECCLASS_DATABASE= -I../../../src/include -D_GNU_SOURCE -c -o
> sepgsqlCore.o sepgsqlCore.c
> sepgsqlCore.c: In function 'sepgsqlGetDatabaseContext':
> sepgsqlCore.c:792: error: expected expression before ')' token
> sepgsqlCore.c: In function 'sepgsqlInitialize':
> sepgsqlCore.c:836: error: expected expression before ',' token
> sepgsqlCore.c:854: error: expected expression before ',' token
> make[3]: *** [sepgsqlCore.o] Error 1
> make[3]: Leaving directory
> `/usr/src/redhat/BUILD/postgresql-8.2.4/src/backend/security'
> make[2]: *** [security-recursive] Error 2

Joshua,

It seems to me that SECCLASS_DATABASE is defined as empty.

It is normally computed at %build section of the specfile as follows:

  SECCLASS_DATABASE=`grep ^define %{_datadir}/selinux/devel/include/support/all_perms.spt \
                         | cat -n | grep all_database_perms | awk '{print $1}'`
  make CUSTOM_COPT=" -D SECCLASS_DATABASE=${SECCLASS_DATABASE}" %{?_smp_mflags}

Thus, selinux-policy-devel-xxx-sepgsql have to be installed to build.

If SECCLASS_DATABASE is not defined, it's defined as 61 being next to SECCLASS_DCCP_SOCKET.
It is correct, if Fedora 6. But incorrect on the latest Fedora 7 and Rawhide.

As you mentioned, I also think this trick is not a good idea.
However, the number of object classes is not constant between policy versions,
so I had to handle the difference and to follow the version up.
I modified it by hand at first, but conditional definition for SECCLASS_DATABASE
got necessary, because the number of object classes got differ between Fedora core 6
and Fedora 7.

I think integration of these definitions into the base policy is the best way
to avoid such a ugly implementation. :)

Thanks,

> As an aside to this, I notice that you tried to integrate policy
> management into the RPM, and I had to modify my spec file to not do this
> because I have my own custom policies on the system. I don't think this
> is the best way, long term, to handle policy integration, though,
> unfortunately, I don't have any better suggestions. This is something I
> intend to look into soon though so I'll provide some feedback on the
> previous thread when I have something useful to say :)

--
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
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.

Re: SE-PostgreSQL for Fedora (Re: Guideline for RPM packages)

[Joshua Brindle]

KaiGai Kohei wrote:
> Joshua Brindle wrote:
>   
>> KaiGai Kohei wrote:
>>     
>>> By the way, I'm seeking sponsors who can review SE-PostgreSQL package.
>>>
>>>   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249522
>>>
>>> If you can volunteer the reviewing process, please contact me.
>>>   
>>>       
>> So, I tried grabbing the sepostgres srpm and building it (you didn't
>> provide an x86_64 rpm) and I get these compilation errors:
>>
>> gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
>> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall
>> -Wmissing-prototypes -Wpointer-arith -Winline
>> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -D
>> SECCLASS_DATABASE= -I../../../src/include -D_GNU_SOURCE -c -o
>> sepgsqlCore.o sepgsqlCore.c
>> sepgsqlCore.c: In function 'sepgsqlGetDatabaseContext':
>> sepgsqlCore.c:792: error: expected expression before ')' token
>> sepgsqlCore.c: In function 'sepgsqlInitialize':
>> sepgsqlCore.c:836: error: expected expression before ',' token
>> sepgsqlCore.c:854: error: expected expression before ',' token
>> make[3]: *** [sepgsqlCore.o] Error 1
>> make[3]: Leaving directory
>> `/usr/src/redhat/BUILD/postgresql-8.2.4/src/backend/security'
>> make[2]: *** [security-recursive] Error 2
>>     
>
> Joshua,
>
> It seems to me that SECCLASS_DATABASE is defined as empty.
>
> It is normally computed at %build section of the specfile as follows:
>
>   SECCLASS_DATABASE=`grep ^define %{_datadir}/selinux/devel/include/support/all_perms.spt \
>                          | cat -n | grep all_database_perms | awk '{print $1}'`
>   make CUSTOM_COPT=" -D SECCLASS_DATABASE=${SECCLASS_DATABASE}" %{?_smp_mflags}
>
> Thus, selinux-policy-devel-xxx-sepgsql have to be installed to build.
>
> If SECCLASS_DATABASE is not defined, it's defined as 61 being next to SECCLASS_DCCP_SOCKET.
> It is correct, if Fedora 6. But incorrect on the latest Fedora 7 and Rawhide.
>
>   

Err, I think you should be using the new userland discovery interface
for this, hardcoding at compile time is a very bad idea (it makes the
compiled binaries completely non-portable).

look at libselinux/checkAccess.c in the trunk version to see how it is
used, essentially something like:

dbase_class = string_to_security_class("database");
if (dbase_class == 0)
return 0;

That lets you discover the class offset at runtime. There are also
facilities for doing the same with permissions.

> As you mentioned, I also think this trick is not a good idea.
> However, the number of object classes is not constant between policy versions,
> so I had to handle the difference and to follow the version up.
> I modified it by hand at first, but conditional definition for SECCLASS_DATABASE
> got necessary, because the number of object classes got differ between Fedora core 6
> and Fedora 7.
>
> I think integration of these definitions into the base policy is the best way
> to avoid such a ugly implementation. :)
>
> Thanks,
>
>   
>> As an aside to this, I notice that you tried to integrate policy
>> management into the RPM, and I had to modify my spec file to not do this
>> because I have my own custom policies on the system. I don't think this
>> is the best way, long term, to handle policy integration, though,
>> unfortunately, I don't have any better suggestions. This is something I
>> intend to look into soon though so I'll provide some feedback on the
>> previous thread when I have something useful to say :)
>>     
>
> --
> KaiGai Kohei <kaigai@kaigai.gr.jp>
>
>   



--
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.

Re: SE-PostgreSQL for Fedora (Re: Guideline for RPM packages)

[KaiGai Kohei]

> Err, I think you should be using the new userland discovery interface
> for this, hardcoding at compile time is a very bad idea (it makes the
> compiled binaries completely non-portable).
> 
> look at libselinux/checkAccess.c in the trunk version to see how it is
> used, essentially something like:
> 
> dbase_class = string_to_security_class("database");
> if (dbase_class == 0)
> return 0;
> 
> That lets you discover the class offset at runtime. There are also
> facilities for doing the same with permissions.

SE-PostgreSQL can already use the userland discovert interdace, if the kernel
provides it. But it is available at the only latest kernel, now.
We have to be also able to apply hardcoded object class number for a while,
to work on the current kernel (2.6.22 or older).

Otherwise, we have to replace or modify the base policy to add definitions of
new object classes and access vectors related to database, so we want these
definitions are integrated into the base policy.

Thanks,

>> As you mentioned, I also think this trick is not a good idea.
>> However, the number of object classes is not constant between policy versions,
>> so I had to handle the difference and to follow the version up.
>> I modified it by hand at first, but conditional definition for SECCLASS_DATABASE
>> got necessary, because the number of object classes got differ between Fedora core 6
>> and Fedora 7.
>>
>> I think integration of these definitions into the base policy is the best way
>> to avoid such a ugly implementation. :)
>>
>> Thanks,
>>
>>   
>>> As an aside to this, I notice that you tried to integrate policy
>>> management into the RPM, and I had to modify my spec file to not do this
>>> because I have my own custom policies on the system. I don't think this
>>> is the best way, long term, to handle policy integration, though,
>>> unfortunately, I don't have any better suggestions. This is something I
>>> intend to look into soon though so I'll provide some feedback on the
>>> previous thread when I have something useful to say :)
>>>     
>> --
>> KaiGai Kohei <kaigai@kaigai.gr.jp>

-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
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.

Re: Guideline for RPM packages

[KaiGai Kohei]

Paul Howarth wrote:
> KaiGai Kohei wrote:
>>>>> If I remember correctly, someone posted a guideline to make
>>>>> a RPM package which contains binary security policy, several
>>>>> weeks ago.
>>>>>
>>>>> If you know the URL, would you tell me the location?
>>>> There is a draft guide at:
>>>> http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules
>>> Thanks, so much!
>> I have a comment for the Policy Module Packaging Guideline.
>>
>> The document says every *.pp files should be installed for any sort of policies
>> (targeted, strict, mls) in the %post section.
>> However, it can cause a problem when a part of policies are not installed yet.
>>
>> When we try to install an application including policy package on the system
>> which has only targeted policy, installation of *.pp files for strict/mls will
>> be failed no need to say.
>> If we want to install selinux-policy-strict or -mls later, the oraphan *.pp files
>> are not linked automatically because "/usr/bin/semodule -i" is not invoked.
>> It will cause a simple problem, but a bit difficult to find out.
>>
>> I have an idea that uses "%triggerin" to invoke "/use/bin/semodule -i" to link
>> orphan *.pp files on instllation of selinux-policy-* packages later, as follows:
>>
>> ----------------
>>   %triggerin -- selinux-policy-targeted
>>   if [ $0 -eq 1 ]; then
>>       /usr/sbin/semodule -s targeted -i %{_datadir}/selinux/targeted/mymodule.pp &> /dev/null || :
>>   fi
>>   %triggerin -- selinux-policy-strict
>>   if [ $0 -eq 1 ]; then
>>       /usr/sbin/semodule -s strict -i %{_datadir}/selinux/strict/mymodule.pp &> /dev/null || :
>>   fi
>>   %triggerin -- selinux-policy-mls
>>   if [ $0 -eq 1 ]; then
>>       /usr/sbin/semodule -s mls -i %{_datadir}/selinux/mls/mymodule.pp &> /dev/null || :
>>   fi
>> ----------------
>>
>> If the application is installed on the system which already has selinux-policy-strict,
>> "%triggerin -- selinux-policy-strict" will be invoked just when the application is
>> installed, so there is no degrading.
> 
> Looks sane to me though it would be nice if there was some way of
> expressing this once rather than duplicate it for each policy type.
> Can't think of any way of doing that though.

I tried to find a way to describe it once without a duplication,
but I could not get a good idea.

If we can describe them like as "%triggerin -- selinux-policy-*", it's better.
Please tell me, if anyone knows more appropriate way to describe.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
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.

Re: Guideline for RPM packages

[KaiGai Kohei]

Paul Howarth wrote:
> On Wed, 01 Aug 2007 10:19:32 +0900
> KaiGai Kohei <kaigai@ak.jp.nec.com> wrote:
> 
>> KaiGai Kohei wrote:
>>> Paul Howarth wrote:
>>>> KaiGai Kohei wrote:
>>>>>>>> If I remember correctly, someone posted a guideline to make
>>>>>>>> a RPM package which contains binary security policy, several
>>>>>>>> weeks ago.
>>>>>>>>
>>>>>>>> If you know the URL, would you tell me the location?
>>>>>>> There is a draft guide at:
>>>>>>> http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules
>>>>>> Thanks, so much!
>>>>> I have a comment for the Policy Module Packaging Guideline.
>>>>>
>>>>> The document says every *.pp files should be installed for any
>>>>> sort of policies (targeted, strict, mls) in the %post section.
>>>>> However, it can cause a problem when a part of policies are not
>>>>> installed yet.
>>>>>
>>>>> When we try to install an application including policy package on
>>>>> the system which has only targeted policy, installation of *.pp
>>>>> files for strict/mls will be failed no need to say.
>>>>> If we want to install selinux-policy-strict or -mls later, the
>>>>> oraphan *.pp files are not linked automatically because
>>>>> "/usr/bin/semodule -i" is not invoked. It will cause a simple
>>>>> problem, but a bit difficult to find out.
>>>>>
>>>>> I have an idea that uses "%triggerin" to invoke
>>>>> "/use/bin/semodule -i" to link orphan *.pp files on instllation
>>>>> of selinux-policy-* packages later, as follows:
>>>>>
>>>>> ----------------
>>>>>   %triggerin -- selinux-policy-targeted
>>>>>   if [ $0 -eq 1 ]; then
>>>>>       /usr/sbin/semodule -s targeted -i
>>>>> %{_datadir}/selinux/targeted/mymodule.pp &> /dev/null || : fi
>>>>>   %triggerin -- selinux-policy-strict
>>>>>   if [ $0 -eq 1 ]; then
>>>>>       /usr/sbin/semodule -s strict -i
>>>>> %{_datadir}/selinux/strict/mymodule.pp &> /dev/null || : fi
>>>>>   %triggerin -- selinux-policy-mls
>>>>>   if [ $0 -eq 1 ]; then
>>>>>       /usr/sbin/semodule -s mls -i
>>>>> %{_datadir}/selinux/mls/mymodule.pp &> /dev/null || : fi
>>>>> ----------------
>>>>>
>>>>> If the application is installed on the system which already has
>>>>> selinux-policy-strict, "%triggerin -- selinux-policy-strict" will
>>>>> be invoked just when the application is installed, so there is no
>>>>> degrading.
>>>> Looks sane to me though it would be nice if there was some way of
>>>> expressing this once rather than duplicate it for each policy type.
>>>> Can't think of any way of doing that though.
>>> I tried to find a way to describe it once without a duplication,
>>> but I could not get a good idea.
>>>
>>> If we can describe them like as "%triggerin -- selinux-policy-*",
>>> it's better. Please tell me, if anyone knows more appropriate way
>>> to describe.
> 
> An alternative approach could be to have a standard directory to drop
> policy modules packages, and then have the selinux-policy-* package
> link in all policy modules found in those directories when the
> selinux-policy-* is newly installed. It should only do that for new
> installs so as to give the admin the option of not using (semodule -r)
> particular modules from that point onwards, and not having to keep
> re-removing the modules at every policy update.
> 
> How about that?

Paul,

I can agree your idea.

You say *.pp files in /usr/share/selinux/mls are linked when
selinux-policy-mls is newly installed in, for example.
Is it correct, isn't it?

There is no need to write duplicate scripts.
However, it's necessary to modify %post section in the selinux-policy-*
packages instead of implicit invoking the script.

Is it possible?
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.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.