Creating and packaging a new policy module

[Dominick Grift]

On Tue, 2013-08-20 at 10:51 +0000, Juan Orti Alcaine wrote:
> El 2013-08-19 13:27, Dominick Grift escribió:
> > On Sun, 2013-08-18 at 20:10 +0200, Juan Orti Alcaine wrote:
> >> Hello, I'm the package mantainer of gogoc, and I'm creating my first 
> >> policy
> >> module for it following the instructions of this draft in the wiki 
> >> [1].
> >> 
> >> It says you must build your module for three policies: mls, scritct 
> >> and
> >> targeted, but I don't see any strict policy, is this information still
> >> correct? Must I build it also for minimum?
> > 
> > Yes strict no longer exists, so remove any reference to it
> 
> And what about the minimum policy?

Probably should ignore minimal as well. Since that policy model aims to
be minimal

> Also, I see some packages dropping their policies to 
> /usr/share/selinux/packages/ and others to 
> /usr/share/selinux/{targeted,mls}. What's better?

Not sure but probably the latter

> 
> > 
> >> 
> >> Also I have doubts if the module will always live in the gogoc package 
> >> or it
> >> will be migrated sometime to the main selinux-policy-targeted package.
> >> 
> >> If you can take a look at the policy to find any possible error it 
> >> would be
> >> great. It's already in the git repository of gogoc [2]
> >> 
> > 
> > You policy should have no require{} in the .te file, everything should
> > have an api that you can use instead
> > 
> > Only type transition on what you need to type transition on, instead of
> > everything (you type transition on everything)
> > 
> > corecmd_bin_entry_type(gogoc_t) <- this doesnt make sense as you do not
> > domain type transition on bin_t anywhere
> > 
> > radvd_admin(gogoc_t, system_r) <- this one isnt appropriate here
> > 
> > systemd_exec_systemctl(gogoc_t)  <- why is this needed?
> > 
> > allow gogoc_t radvd_exec_t:file { read execute open execute_no_trans };
> > <-- depending on why gogoc runs dadvd you may want to run radvd with a
> > domain transition instead. If it turns out that you should have ran
> > radvd with a domain transition ,then it is encouraged you start over
> > with your policy because, one should always take care of type
> > transitions first before adding any other rules. because type
> > transitions can greatly impact access your process needs
> > 
> > There are duplicate rules in your policy
> > 
> > For example:
> > sysnet_dns_name_resolve(gogoc_t)
> > and
> > files_read_etc_files(gogoc_t)
> > 
> > are already enclosed with:
> > auth_use_nsswitch(gogoc_t)
> > 
> > Theres probably a bit moreroom for improvement other than above but 
> > this
> > is a start
> 
> Thank you for your comments, I'm newbie at policy writing.
> 
> What gogoc does is to negotiate the tunnel and execute a shell script to 
> configure the tun interface and launch the radvd with a custom config to 
> advertise the prefix in the net.
> 
> I'm rewriting the policy and have doubts about how to transition to the 
> radvd_t domain. I miss a interface like radvd_domtrans(gogoc_t), which I 
> think it's the way to do the transition, another way I'm thinking it's 
> adding a section require{ type radvd_exec_t;} and grant access to 
> execute and domain transition. Which api function should I use?

upstream will probably only accept it with the use of a dadvd_domtrans()
but for your solution for now you could do something like this:

optional_policy(`
gen_require(`
	type radvd_exec_t, radvd_t;
')
domtrans_pattern(gogoc_t, radvd_exec_t, radvd_t)
')

> 
> Regards,
> Juan.