Naive Qs about selinux modules

[Johnson, Richard]

Q:  Can any SELinux directive be put into a policy smodule, or are there
restrictions?

For example: suppose I wanted to:

allow snmpd_t apmd_t:process ptrace;

allow snmpd_t auditd_t:process ptrace;

allow snmpd_t automount_t:process ptrace;

[ ...and so on ]

so that snmpd could access mib .1.3.6.1.2.1.6. (advisability
notwithstanding) Could these directives be put into a policy module even
though the base policy already has an snmpd i/f?

Q.  Can a module define new booleans?  If so are they persistent if the
module is unloaded and reloaded?

For example; an snmpd policy module with an snmpd_can_ptrace boolean.
Are there namespace conventions?

Q. What happens if the base policy (or another policy modules) is
updated with overlapping statements.

Am I correct in believing that the set of allows is the union of the
base allows + all module allows?

--rich

[Daniel J Walsh]

Johnson, Richard wrote:
> Q:  Can any SELinux directive be put into a policy smodule, or are there
> restrictions?
>
> For example: suppose I wanted to:
>
> allow snmpd_t apmd_t:process ptrace;
>
> allow snmpd_t auditd_t:process ptrace;
>
> allow snmpd_t automount_t:process ptrace;
>
> [ ...and so on ]
>
> so that snmpd could access mib .1.3.6.1.2.1.6. (advisability
> notwithstanding) Could these directives be put into a policy module even
> though the base policy already has an snmpd i/f?

Yes although  watch out for name conflicts,  IE Don't name your module
the same as an existing module or you will replace it.

BTW the interface
domain_read_all_domains_state(snmpd_t)

Is probably what you want.
> Q.  Can a module define new booleans?  If so are they persistent if the
> module is unloaded and reloaded?

Yes and the booleans will be removed if you unload the policy.
> For example; an snmpd policy module with an snmpd_can_ptrace boolean.
> Are there namespace conventions?

Well we would prefer all booleans to be named with the name of the
module.  Although there are a lot of booleans that do not follow that
standard.  I would love to have aliasing for booleans so we could rename
them.
> Q. What happens if the base policy (or another policy modules) is
> updated with overlapping statements.

They are additive.
> Am I correct in believing that the set of allows is the union of the
> base allows + all module allows?

Yes
> --rich
>
> --
> fedora-selinux-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Daniel J Walsh]

Daniel J Walsh wrote:
> Johnson, Richard wrote:
> > Q:  Can any SELinux directive be put into a policy smodule, or are there
> > restrictions?
> >
> > For example: suppose I wanted to:
> >
> > allow snmpd_t apmd_t:process ptrace;
> >
> > allow snmpd_t auditd_t:process ptrace;
> >
> > allow snmpd_t automount_t:process ptrace;
> >
> > [ ...and so on ]
> >
> > so that snmpd could access mib .1.3.6.1.2.1.6. (advisability
> > notwithstanding) Could these directives be put into a policy module even
> > though the base policy already has an snmpd i/f?
>
> Yes although  watch out for name conflicts,  IE Don't name your module
> the same as an existing module or you will replace it.
>
> BTW the interface
> domain_read_all_domains_state(snmpd_t)
>
> Is probably what you want.
> > Q.  Can a module define new booleans?  If so are they persistent if the
> > module is unloaded and reloaded?
>
> Yes and the booleans will be removed if you unload the policy.
> > For example; an snmpd policy module with an snmpd_can_ptrace boolean.
> > Are there namespace conventions?
>
> Well we would prefer all booleans to be named with the name of the
> module.  Although there are a lot of booleans that do not follow that
> standard.  I would love to have aliasing for booleans so we could rename
> them.
> > Q. What happens if the base policy (or another policy modules) is
> > updated with overlapping statements.
>
> They are additive.
> > Am I correct in believing that the set of allows is the union of the
> > base allows + all module allows?
>
> Yes
> > --rich
> >
> > --
> > fedora-selinux-list mailing list
> > [e-mail]
> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
> --
> fedora-selinux-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Futher answered on

http://danwalsh.livejournal.com/23710.html

[Johnson, Richard]

Daniel J Walsh wrote: 
Johnson, Richard wrote:
> > Q:  Can any SELinux directive be put into a policy smodule, or are

there
> > restrictions?
> >
> > For example: suppose I wanted to:
> >
> > allow snmpd_t apmd_t:process ptrace; 
> >   allow snmpd_t auditd_t:process ptrace;
> >   allow snmpd_t automount_t:process ptrace;
> >  [ ...and so on ]
> >
> > so that snmpd could access mib .1.3.6.1.2.1.6. (advisability
> > notwithstanding) Could these directives be put into a policy module

even
> > though the base policy already has an snmpd i/f?
>
> Yes although  watch out for name conflicts,  IE Don't name your module
> the same as an existing module or you will replace it.
>
> BTW the interface
> domain_read_all_domains_state(snmpd_t)
>
> Is probably what you want.
> > Q.  Can a module define new booleans?  If so are they persistent if

the
> > module is unloaded and reloaded?
>
> Yes and the booleans will be removed if you unload the policy.
> > For example; an snmpd policy module with an snmpd_can_ptrace boolean.
> > Are there namespace conventions?
>
> Well we would prefer all booleans to be named with the name of the
> module.  Although there are a lot of booleans that do not follow that
> standard.  I would love to have aliasing for booleans so we could

rename
> them.
> > Q. What happens if the base policy (or another policy modules) is
> > updated with overlapping statements.
>
> They are additive.
> > Am I correct in believing that the set of allows is the union of the
> > base allows + all module allows?
>
> Yes

Thanks.  And thanks for the hint about domain_read_all_domains_state().