[RFC] semodule policy

[RFC] semodule policy

[Christopher J. PeBenito]

So we have the start of a semodule policy [1] that needs some discussion
on its design.  Here are the relevant parts of the discussion:

On Tue, 2006-02-14 at 09:01 -0500, Daniel J Walsh wrote:
> Added semodule policy.  This still needs work.  semodule now wants to
> create lock files in /etc/selinux/TYPE/modules sub directory.  I would
> like to label this policy_config_t, problem is that all tools
> (setfiles, restorecon ...) need write access in order to create the
> lock file.  This is a serious problem.  I think we also need to
> label /usr/share/selinux/TYPE/*.pp files as policy_config_t.

On Tue, 2006-02-14 at 14:03 -0500, Joshua Brindle wrote: 
> setfiles nor restorecon link against libsemanage so they should not be 
> touching the store at all, the store is a private resource of libsemanage.
> 
> The module store labeling strategy should reflect what I did with the 
> access_check function, eg., making module/{active,previous} totally 
> inaccessible to anything except semodule_t, giving 
> module/semodule.read.LOCK and module/semodule.trans.LOCK different 
> labels so we can have legitimate "read only" domains.
> 
> Then, TYPE/contexts and TYPE/policy can have whatever labels they have 
> now with whatever access they have now and it should be fine. 
> Unfortunatly having the 'active' binary policy out of the store 
> eliminates some ability to encapsulate access to it but I suppose that 
> can be addressed some other time.

I agree with Joshua, my current idea would be a .fc like (abbreviated):

modules				-d	selinux_config_t
modules/(active|previous|tmp)(/.*)? 	semodule_store_t
modules/semanage.read.LOCK	--	semodule_read_lock_t
modules/semanage.trans.LOCK	--	semodule_trans_lock_t

Then semodule_t would have a dir type_transition on selinux_config_t.
Then the rest of semodule_t policy should hopefully fall in place.

As for /usr/share/selinux/$NAME/*.pp, I agree that they should have a
different label, but I'm not sure they should be policy_config_t.

[1] http://marc.theaimsgroup.com/?l=selinux&m=113992576831596&w=2

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: [RFC] semodule policy

[Stephen Smalley]

On Thu, 2006-02-16 at 14:28 -0500, Christopher J. PeBenito wrote:
> I agree with Joshua, my current idea would be a .fc like (abbreviated):
> 
> modules				-d	selinux_config_t
> modules/(active|previous|tmp)(/.*)? 	semodule_store_t
> modules/semanage.read.LOCK	--	semodule_read_lock_t
> modules/semanage.trans.LOCK	--	semodule_trans_lock_t

Will libsemanage be modified to set and preserve the type on the lock
files?  How will it obtain the correct type for the lock files in the
bootstrap case where there is no file_contexts yet?  It would be easier
if they lived in separate subdirectories so that we could just use
directory inheritance, as with the installed kernel binary policy file
and the installed file_contexts file.  Top-level files
in /etc/selinux/$SELINUXTYPE have the same issue, like seusers and
setrans.conf, if we ever want them individually typed.  selinux_config_t
tends to be widely readable.

> Then semodule_t would have a dir type_transition on selinux_config_t.
> Then the rest of semodule_t policy should hopefully fall in place.

Should the domain be semanage_t to reflect use of libsemanage, and put
all three of semodule, setsebool, and semanage into it?

> As for /usr/share/selinux/$NAME/*.pp, I agree that they should have a
> different label, but I'm not sure they should be policy_config_t.
> 
> [1] http://marc.theaimsgroup.com/?l=selinux&m=113992576831596&w=2

Likely should add a new type for them.  Then we can possibly create
pipelines from their type to the store files via the approved programs.

-- 
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: [RFC] semodule policy

[Joshua Brindle]

Stephen Smalley wrote:
> On Thu, 2006-02-16 at 14:28 -0500, Christopher J. PeBenito wrote:
>> I agree with Joshua, my current idea would be a .fc like (abbreviated):
>>
>> modules				-d	selinux_config_t
>> modules/(active|previous|tmp)(/.*)? 	semodule_store_t
>> modules/semanage.read.LOCK	--	semodule_read_lock_t
>> modules/semanage.trans.LOCK	--	semodule_trans_lock_t
> 
> Will libsemanage be modified to set and preserve the type on the lock
> files? 

Assuming that the semodule policy isn't present at initialization time 
(bootstrap) the module store will have to be relabeled anyway. I could 
add matchpathcon requests to create_store but I'm unsure if it will be 
helpful.

> How will it obtain the correct type for the lock files in the
> bootstrap case where there is no file_contexts yet? 

right, the problem I'm avoiding by not handling it in libsemanage :)

> It would be easier
> if they lived in separate subdirectories so that we could just use
> directory inheritance, as with the installed kernel binary policy file
> and the installed file_contexts file. 

the locks aren't ever deleted after creation (although if they are 
deleted it shouldn't cause problems), a single file per directory is 
kind of broken but I see why it might be helpful

> Top-level files
> in /etc/selinux/$SELINUXTYPE have the same issue, like seusers and
> setrans.conf, if we ever want them individually typed.  selinux_config_t
> tends to be widely readable.
> 
>> Then semodule_t would have a dir type_transition on selinux_config_t.
>> Then the rest of semodule_t policy should hopefully fall in place.
> 
> Should the domain be semanage_t to reflect use of libsemanage, and put
> all three of semodule, setsebool, and semanage into it?

probably. The other issue is that semanage/semodule/setsebool needs to 
run in the user context in the policy server case so that policy access 
control is done against their domain. I guess this will be a boolean/tunable

> 
>> As for /usr/share/selinux/$NAME/*.pp, I agree that they should have a
>> different label, but I'm not sure they should be policy_config_t.
>>
>> [1] http://marc.theaimsgroup.com/?l=selinux&m=113992576831596&w=2
> 
> Likely should add a new type for them.  Then we can possibly create
> pipelines from their type to the store files via the approved programs.
> 

sure.

--
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: [RFC] semodule policy

[Stephen Smalley]

On Thu, 2006-02-16 at 15:58 -0500, Stephen Smalley wrote:
> Should the domain be semanage_t to reflect use of libsemanage, and put
> all three of semodule, setsebool, and semanage into it?

Also chcat.  And genhomedircon will need read access.

BTW, as several of these are python scripts, the domain enforcement is
somewhat illusory.

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