package review?

[Michael Thomas]

Paul Howarth wrote:
> On Fri, 2006-07-21 at 12:25 -0700, Michael Thomas wrote:
> 
>>Paul Howarth wrote:
>>>I don't see any domain transition to crossfire_t in your policy; how
>>>does it get into that domain?
>>
>>It should be there in crossfire.if, no?
> 
> 
> That's the interface used to transition to crossfire_t from some other
> domain. So if you wanted it to run confined when just started by a
> regular unconfined user, you'd need:
> 
> crossfire_domtrans(unconfined_t)
> 
> in a rules (.te) file. Interfaces are used so that rules and types
> defined for one domain can be used from another domain, so that
> everything relating to each domain can kept together. So if your policy
> was to get merged into upstream policy, this domain transition would go
> in the unconfined.te module.
> 
> However, if you're providing a standalone module, it probably makes
> sense to include this in your own crossfire.te file.

Yes, I'd like to avoid the need for modifications in the global policies
if at all possible.

> You should check that the transition has happened by running ps with the
> "-Z" option to show the process context when you're running the
> application.

It shows up as crossfire_exec_t because...

> Note that most things running confined under targeted policy are started
> from initscripts and there is no transition from unconfined_t needed (or
> wanted). That's not the case here though.

...it is started from an init script.  Normal (unconfined) users should
not be starting this by hand.  Instead, normal users will run the client
application which connects to this server.  In this case, it sounds like
I don't need the rule to transition from unconfined_t.

>>Some things that would be nice to clarify:
>>
>>Should selinux be added as a subpackage or automatically included in the
>>base package?
> 
> 
> I don't have a strong opinion either way on this. I've tended to stick
> to keeping everything together because I find it easier to manage that
> way. As long as the SELinux bits don't get in the way of people not
> using them, I don't think it's a problem.

I think I would prefer to use a separate package (not integrated with
the base package), so that the policy can be turned on and off by simply
installing/uninstalling the -selinux package.

>>If selinux is added as a subpackage, what should its Requires: look like
>>(or should there even be any?)
> 
> 
> I think that could depend on the particular relationship between the
> policy and the main package. For instance, if in your package you
> patched out the need for temp files and you didn't allow it to use them
> in the SELinux policy, the policy package would want to conflict with
> any version of the main package prior to the addition of the patch. I
> favour Conflicts: for these rather than Requires: because I can see
> reasons why people would want to install both parts independently of the
> other (non-SELinux users would want the main package without the policy,
> and people wanting to learn about SELinux might want the policy package
> without the main one).

I think I would prefer if they were separate packages, whether they are
part of the same spec file or not.  Your argument for using Conflicts:
vs. Requires: makes a lot of sense.

>>Is a single targetted policy enough, or is it necessary to build for all
>>selinux variants (mls, strict, targeted)?
> 
> 
> If the built module is the same for all policies (which it will be if
> there's nothing policy-specific in it), you could just build one module
> and load it for all policies.

Ok.

>>>An example of the way I'm currently doing SELinux module packaging can
>>>be found here:
>>>
>>>http://www.city-fan.org/~paul/extras/mod_fcgid/mod_fcgid.spec
>>
>>/me runs screaming from the %defines :)
> 
> 
> Understandable. I like to maintain one spec per package rather than
> separate ones for each branch. If you're happy to maintain separate
> specs for each branch, most of the defines can be hard-coded into the
> spec.

Yeah, I think I'll do that.  :)

--Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20060721/a555013d/attachment.bin>