Adding confinement to an EPEL package

[James Hogarth]

Hi all,

A while back my pull request to contribute a policy for sslh in Fedora was
accepted and indeed all users have been protected by having the daemon
confined if they use it since Fedora 23.

RHEL does not have the policy included so EPEL users aren't subject to the
same benefits of selinux of this network service.

I'd like to rectify this if possible (I'm going to ignore F22 given how
soon the EOL on it is and the change in behaviour that would result on
users).

The draft packaging guidelines for a policy in Fedora[1][2] are rather
archaic at this point but I figure I can base the changes to the spec on
this to an extent.

I have a few of questions/concerns though:

1) What is the consequence of someone having selinux disabled (common in
EL5 systems and to an extent EL6) with the semodule to install the .pp in
%post ? Will this prevent the package from being installed and if I
condition it based on getenforce output to avoid doing so on disabled
system if the admin then enables selinux will the module still be installed?
2) Is it better practice to have a separate -selinux package in the spec or
just do it in the one package? If a separate package what would be the best
way to ensure upgrading users get the policy? I see suggestions of a -core
package ... perhaps turn the main foo package into a dummy that requires
both -core and -selinux?
3) If the selinux maintainers in RHEL import the sslh policy from fedora
contrib at some point what affect would this have on my users? Would I need
to issue a new update without the .pp and uninstalling the module to allow
them to upgrade their selinux policy?

Cheers,

James


[1] https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft
[2] https://fedoraproject.org/wiki/PackagingDrafts/SELinux

[Miroslav Grepl]

On 03/30/2016 04:22 PM, James Hogarth wrote:
>  Hi all,
>  
>  A while back my pull request to contribute a policy for sslh in Fedora
>  was accepted and indeed all users have been protected by having the
>  daemon confined if they use it since Fedora 23.
>  
>  RHEL does not have the policy included so EPEL users aren't subject to
>  the same benefits of selinux of this network service.
>  
>  I'd like to rectify this if possible (I'm going to ignore F22 given how
>  soon the EOL on it is and the change in behaviour that would result on
>  users).
>  
>  The draft packaging guidelines for a policy in Fedora[1][2] are rather
>  archaic at this point but I figure I can base the changes to the spec on
>  this to an extent.
>  
>  I have a few of questions/concerns though:
>  
>  1) What is the consequence of someone having selinux disabled (common in
>  EL5 systems and to an extent EL6) with the semodule to install the .pp
>  in %post ? Will this prevent the package from being installed and if I
>  condition it based on getenforce output to avoid doing so on disabled
>  system if the admin then enables selinux will the module still be installed?
>  2) Is it better practice to have a separate -selinux package in the spec
>  or just do it in the one package? If a separate package what would be
>  the best way to ensure upgrading users get the policy? I see suggestions
>  of a -core package ... perhaps turn the main foo package into a dummy
>  that requires both -core and -selinux? 
Lukáš Vrabec wrote great blog posts about that

http://lvrabec-selinux.rhcloud.com/2015/07/07/how-to-create-selinux-produ...

See if you can get all answers. I believe you will get them.

>  3) If the selinux maintainers in RHEL import the sslh policy from
> fedora
>  contrib at some point what affect would this have on my users? Would I
>  need to issue a new update without the .pp and uninstalling the module
>  to allow them to upgrade their selinux policy? 
Yes, this is a problem. We would need to synchronize updates with
conflicts because you would fail with duplicate errors.

>  
>  Cheers,
>  
>  James
>  
>  
>  [1] https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft
>  [2] https://fedoraproject.org/wiki/PackagingDrafts/SELinux 
It should be definitely updated.

Thanks.

>  
>  
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  http://lists.fedoraproject.org/admin/lists/[e-mail]
>   

-- 
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.

[Lukas Vrabec]

On 03/31/2016 08:06 AM, Miroslav Grepl wrote:
>  On 03/30/2016 04:22 PM, James Hogarth wrote:
> > Hi all,
> >
> > A while back my pull request to contribute a policy for sslh in Fedora
> > was accepted and indeed all users have been protected by having the
> > daemon confined if they use it since Fedora 23.
> >
> > RHEL does not have the policy included so EPEL users aren't subject to
> > the same benefits of selinux of this network service.
> >
> > I'd like to rectify this if possible (I'm going to ignore F22 given how
> > soon the EOL on it is and the change in behaviour that would result on
> > users).
> >
> > The draft packaging guidelines for a policy in Fedora[1][2] are rather
> > archaic at this point but I figure I can base the changes to the spec on
> > this to an extent.
> >
> > I have a few of questions/concerns though:
> >
> > 1) What is the consequence of someone having selinux disabled (common in
> > EL5 systems and to an extent EL6) with the semodule to install the .pp
> > in %post ? Will this prevent the package from being installed and if I
> > condition it based on getenforce output to avoid doing so on disabled
> > system if the admin then enables selinux will the module still be installed?
> > 2) Is it better practice to have a separate -selinux package in the spec
> > or just do it in the one package? 
We prefer using separate subpackage -selinux.

If a separate package what would be
> > the best way to ensure upgrading users get the policy? I see
> suggestions
> > of a -core package ... perhaps turn the main foo package into a dummy
> > that requires both -core and -selinux?
>
>  Lukáš Vrabec wrote great blog posts about that
>
>  http://lvrabec-selinux.rhcloud.com/2015/07/07/how-to-create-selinux-produ...
>
>  See if you can get all answers. I believe you will get them.
>  
Feel free to contact me if you have any question.

> > 3) If the selinux maintainers in RHEL import the sslh policy from
> fedora
> > contrib at some point what affect would this have on my users? Would I
> > need to issue a new update without the .pp and uninstalling the module
> > to allow them to upgrade their selinux policy?
>
>  Yes, this is a problem. We would need to synchronize updates with
>  conflicts because you would fail with duplicate errors.
>
> >
> > Cheers,
> >
> > James
> >
> >
> > [1] https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft
> > [2] https://fedoraproject.org/wiki/PackagingDrafts/SELinux
>
>  It should be definitely updated.
>
>  Thanks.
>
> >
> >
> > --
> > selinux mailing list
> > selinux(a)lists.fedoraproject.org
> > http://lists.fedoraproject.org/admin/lists/[e-mail]
> >
>
>  

-- 
Lukas Vrabec
SELinux Solutions
Red Hat, Inc.