policy for mock - put in mock package or selinux-policy-targeted?

[Matt Domsch]

What's the right place to put application-specific policy modules,
such as the mock policy outlined here:
http://fedoraproject.org/wiki/Extras/MockTricks

Should those files get compiled into modules, and installed, using
mock's SRPM, or should they go into selinux-policy-targeted?

Seth Vidal wants to push out a new mock build soonish, and this is
something I'd like cleared up before that if possible.

Thanks,
Matt

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

[Jeremy Katz]

On Thu, 2006-06-01 at 13:51 -0500, Matt Domsch wrote:
>  Should those files get compiled into modules, and installed, using
>  mock's SRPM, or should they go into selinux-policy-targeted? 
Right now, they should go into the main policy package.  Work is
underway to allow reasonable packaging of policy within other packages,
but there are some dependencies there which need to be handled first.

Also, I'm not 100% convinced that relaxing what mock is allowed to do
unconditionally like is described there is the best approach.  Not that
anything better is immediately coming to mind at the moment :-/

Jeremy.

[Paul Howarth]

On Sun, 2006-06-04 at 15:18 -0400, Jeremy Katz wrote:
>  On Thu, 2006-06-01 at 13:51 -0500, Matt Domsch wrote:
>  > Should those files get compiled into modules, and installed, using
>  > mock's SRPM, or should they go into selinux-policy-targeted?
>  
>  Right now, they should go into the main policy package.  Work is
>  underway to allow reasonable packaging of policy within other packages,
>  but there are some dependencies there which need to be handled first. 
I tend to agree, Whilst there are already a few packages in Extras with
custom policy hacks (semanage calls mainly, though pureftpd has a custom
module), there isn't yet a definitive way to do this nice and cleanly
(see the "SELinux Module Packaging in FC5" thread).

>  Also, I'm not 100% convinced that relaxing what mock is allowed
> to do
>  unconditionally like is described there is the best approach.  Not that
>  anything better is immediately coming to mind at the moment :-/ 
Major problems that need to be overcome in order to do something better
include:

1. Mock itself loads a dummy libselinux, which makes everything that
happens under its control believe that SELinux is disabled.

2. The entire default file context tree in policy (and add-on modules,
semanage-ed custom policy tweaks etc.) would need to be duplicated for
each chroot.

Paul.

[Jeremy Katz]

On Sun, 2006-06-04 at 21:11 +0100, Paul Howarth wrote:
>  On Sun, 2006-06-04 at 15:18 -0400, Jeremy Katz wrote:
>  > On Thu, 2006-06-01 at 13:51 -0500, Matt Domsch wrote:
>  > > Should those files get compiled into modules, and installed, using
>  > > mock's SRPM, or should they go into selinux-policy-targeted?
>  > 
>  > Right now, they should go into the main policy package.  Work is
>  > underway to allow reasonable packaging of policy within other packages,
>  > but there are some dependencies there which need to be handled first.
>  
>  I tend to agree, Whilst there are already a few packages in Extras with
>  custom policy hacks (semanage calls mainly, though pureftpd has a custom
>  module), there isn't yet a definitive way to do this nice and cleanly
>  (see the "SELinux Module Packaging in FC5" thread). 
Yeah -- I was involved in the discussion on the main SELinux list.  I've
had to generally avoid fedora-selinux-list of late just so that I can
keep up with my flood of mail :)

>  > Also, I'm not 100% convinced that relaxing what mock is
> allowed to do
>  > unconditionally like is described there is the best approach.  Not that
>  > anything better is immediately coming to mind at the moment :-/
>  
>  Major problems that need to be overcome in order to do something better
>  include:
>  
>  1. Mock itself loads a dummy libselinux, which makes everything that
>  happens under its control believe that SELinux is disabled. 
*nod*  That was done as the simple and easy way of handling things at
the time (right before FC3 was released).  It may well make more sense
to have awareness in the chroots of SELinux being enabled now and
handling things accordingly.  It should be easy enough to investigate if
someone wants to try.

>  2. The entire default file context tree in policy (and add-on
> modules,
>  semanage-ed custom policy tweaks etc.) would need to be duplicated for
>  each chroot. 
Yeah, this is where things start to give me the heebie-jeebies :)

Jeremy