example of a domain with transition policy

[Vadym Chepkov]

Hi,

Could somebody give me a working example of a policy module with transition, please. I am
trying to create a policy for a vendor product I have to use (Asset Insight). 
The basic idea is to create domains ai_exec_t, ai_t, proper transition rules for
initrc_exec_t -> initrc_t -> ai_exec_t -> ai_t. 
Then I want to ai_t be unconfined (for the moment) so probably make ai_t as an alias of
unconfined_t, since there is no "permissive domain" in Redhat5 yet, but I want
to be able to see what needs to be added to .te file to make it work. There is no much
documentation about writing policy in Redhat/Fedora, unfortunately, or maybe I am missing
some.
Thank you.

Sincerely yours,
  Vadym Chepkov

[Dominick Grift]

Lets assume we have an init script: /etc/rc.d/init.d/ai, a
executable: /usr/sbin/ai

first we create our file context file:

mkdir ~/ai; cd ~/ai;
echo "/etc/rc\.d/init\.d/ai --
gen_context(system_u:object_r:ai_initrc_exec_t, s0)" > ai.fc
echo "/usr/sbin/ai -- gen_context(system_u:object_r:ai_exec_t, s0)" >>
ai.fc

this will take care of our file contexts. Now lets declare our module
and some types to enforce:

echo "policy_module(ai, 0.0.1)" > ai.te
echo "type ai_initrc_exec_t;" >> ai.te
echo "init_script_file(ai_initrc_exec_t)" >> ai.te
echo "type ai_t;" >> ai.te
echo "type ai_exec_t;" >> ai.te
echo "init_daemon_domain(ai_t, ai_exec_t)" >> ai.te

Now lets compile our module:

make -f /usr/share/selinux/devel/Makefile

Now lets install our module:

sudo semodule -i ai.pp

Now lets restore the file context of our executable file and the init
script.

restorecon -v /etc/rc.d/init.d/ai
restorecon -v /usr/sbin/ai

Now we have to create actual policy. We do this by testing. Since EL5
does not support permissive domains, we will have to put the system into
permissive mode: setenforce 0

now lets start the daemon:

sudo service ai start

after some testing of the daemons functionility we stop the daemon:

sudo service ai stop

now we enforce selinux again: setenforce 1

..and we check for avc denials and pipe those into audit2allow to
translate raw avc denials to policy language:

ausearch -m avc -ts today | audit2allow -R

then we simply append the output to our ai.te file, recompile and
reinstall.

Thats about it in a nutshell.

Ofcourse this example is over simplified. there are only two files owned
by ai. in real life there are more files that need types (we would use
rpm -ql to find those, and we would inspect the output of audit2allow -R
to identify any file owned by ai that were created (like pid files ,
files in /tmp etc etc)

Also audit2allow -R's output is not optimal so we would try to find
optimal interfaces for the policy it may not have translated in a
optimal way.

If you have questions you can also join us on #fedora-selinux on
irc.freenode.org.

happy policy writing!

Dominick

On Thu, 2009-01-29 at 10:52 -0800, Vadym Chepkov wrote:
>  Hi,
>  
>  Could somebody give me a working example of a policy module with transition, please. I am
> trying to create a policy for a vendor product I have to use (Asset Insight). 
>  The basic idea is to create domains ai_exec_t, ai_t, proper transition rules for
> initrc_exec_t -> initrc_t -> ai_exec_t -> ai_t. 
>  Then I want to ai_t be unconfined (for the moment) so probably make ai_t as an alias of
> unconfined_t, since there is no "permissive domain" in Redhat5 yet, but I want
> to be able to see what needs to be added to .te file to make it work. There is no much
> documentation about writing policy in Redhat/Fedora, unfortunately, or maybe I am missing
> some.
>  Thank you.
>  
>  Sincerely yours,
>    Vadym Chepkov
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Vadym Chepkov]

Thank you so much.

Why do we need ai_initrc_exec_t though? All scripts in /etc/rc.d/init.d/ have context
initrc_exec_t and it seems a proper approach to me.

Sincerely yours,
  Vadym Chepkov

P.S. To my shame never used IRC in my life :(

--- On Thu, 1/29/09, Dominick Grift <domg472(a)gmail.com&gt; wrote:

>  From: Dominick Grift <domg472(a)gmail.com&gt;
>  Subject: Re: example of a domain with transition policy
>  To: "Vadym Chepkov" <chepkov(a)yahoo.com&gt;
>  Cc: fedora-selinux-list(a)redhat.com
>  Date: Thursday, January 29, 2009, 2:20 PM
>  Lets assume we have an init script: /etc/rc.d/init.d/ai, a
>  executable: /usr/sbin/ai
>  
>  first we create our file context file:
>  
>  mkdir ~/ai; cd ~/ai;
>  echo "/etc/rc\.d/init\.d/ai --
>  gen_context(system_u:object_r:ai_initrc_exec_t, s0)"
>  > ai.fc
>  echo "/usr/sbin/ai --
>  gen_context(system_u:object_r:ai_exec_t, s0)" >>
>  ai.fc
>  
>  this will take care of our file contexts. Now lets declare
>  our module
>  and some types to enforce:
>  
>  echo "policy_module(ai, 0.0.1)" > ai.te
>  echo "type ai_initrc_exec_t;" >> ai.te
>  echo "init_script_file(ai_initrc_exec_t)"
>  >> ai.te
>  echo "type ai_t;" >> ai.te
>  echo "type ai_exec_t;" >> ai.te
>  echo "init_daemon_domain(ai_t, ai_exec_t)"
>  >> ai.te
>  
>  Now lets compile our module:
>  
>  make -f /usr/share/selinux/devel/Makefile
>  
>  Now lets install our module:
>  
>  sudo semodule -i ai.pp
>  
>  Now lets restore the file context of our executable file
>  and the init
>  script.
>  
>  restorecon -v /etc/rc.d/init.d/ai
>  restorecon -v /usr/sbin/ai
>  
>  Now we have to create actual policy. We do this by testing.
>  Since EL5
>  does not support permissive domains, we will have to put
>  the system into
>  permissive mode: setenforce 0
>  
>  now lets start the daemon:
>  
>  sudo service ai start
>  
>  after some testing of the daemons functionility we stop the
>  daemon:
>  
>  sudo service ai stop
>  
>  now we enforce selinux again: setenforce 1
>  
>  ..and we check for avc denials and pipe those into
>  audit2allow to
>  translate raw avc denials to policy language:
>  
>  ausearch -m avc -ts today | audit2allow -R
>  
>  then we simply append the output to our ai.te file,
>  recompile and
>  reinstall.
>  
>  Thats about it in a nutshell.
>  
>  Ofcourse this example is over simplified. there are only
>  two files owned
>  by ai. in real life there are more files that need types
>  (we would use
>  rpm -ql to find those, and we would inspect the output of
>  audit2allow -R
>  to identify any file owned by ai that were created (like
>  pid files ,
>  files in /tmp etc etc)
>  
>  Also audit2allow -R's output is not optimal so we would
>  try to find
>  optimal interfaces for the policy it may not have
>  translated in a
>  optimal way.
>  
>  If you have questions you can also join us on
>  #fedora-selinux on
>  irc.freenode.org.
>  
>  happy policy writing!
>  
>  Dominick
>  
>  On Thu, 2009-01-29 at 10:52 -0800, Vadym Chepkov wrote:
>  > Hi,
>  > 
>  > Could somebody give me a working example of a policy
>  module with transition, please. I am trying to create a
>  policy for a vendor product I have to use (Asset Insight). 
>  > The basic idea is to create domains ai_exec_t, ai_t,
>  proper transition rules for initrc_exec_t -> initrc_t
>  -> ai_exec_t -> ai_t. 
>  > Then I want to ai_t be unconfined (for the moment) so
>  probably make ai_t as an alias of unconfined_t, since there
>  is no "permissive domain" in Redhat5 yet, but I
>  want to be able to see what needs to be added to .te file to
>  make it work. There is no much documentation about writing
>  policy in Redhat/Fedora, unfortunately, or maybe I am
>  missing some.
>  > Thank you.
>  > 
>  > Sincerely yours,
>  >   Vadym Chepkov
>  > 
>  > --
>  > fedora-selinux-list mailing list
>  > fedora-selinux-list(a)redhat.com
>  >
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Dominick Grift]

Well SELinux is about least privilege. we tend to use as much unique
types as reasonably possible.

there is one small correction though for EL5 and my example:

el5 uses init_script_type() instead of init_script_file() 

so:

init_script_type(ai_initrc_exec_t)

On Thu, 2009-01-29 at 11:35 -0800, Vadym Chepkov wrote:
>  Thank you so much.
>  
>  Why do we need ai_initrc_exec_t though? All scripts in /etc/rc.d/init.d/ have context
> initrc_exec_t and it seems a proper approach to me.
>  
>  Sincerely yours,
>    Vadym Chepkov
>  
>  P.S. To my shame never used IRC in my life :(
>  
>  --- On Thu, 1/29/09, Dominick Grift <domg472(a)gmail.com&gt; wrote:
>  
>  > From: Dominick Grift <domg472(a)gmail.com&gt;
>  > Subject: Re: example of a domain with transition policy
>  > To: "Vadym Chepkov" <chepkov(a)yahoo.com&gt;
>  > Cc: fedora-selinux-list(a)redhat.com
>  > Date: Thursday, January 29, 2009, 2:20 PM
>  > Lets assume we have an init script: /etc/rc.d/init.d/ai, a
>  > executable: /usr/sbin/ai
>  > 
>  > first we create our file context file:
>  > 
>  > mkdir ~/ai; cd ~/ai;
>  > echo "/etc/rc\.d/init\.d/ai --
>  > gen_context(system_u:object_r:ai_initrc_exec_t, s0)"
>  > > ai.fc
>  > echo "/usr/sbin/ai --
>  > gen_context(system_u:object_r:ai_exec_t, s0)" >>
>  > ai.fc
>  > 
>  > this will take care of our file contexts. Now lets declare
>  > our module
>  > and some types to enforce:
>  > 
>  > echo "policy_module(ai, 0.0.1)" > ai.te
>  > echo "type ai_initrc_exec_t;" >> ai.te
>  > echo "init_script_file(ai_initrc_exec_t)"
>  > >> ai.te
>  > echo "type ai_t;" >> ai.te
>  > echo "type ai_exec_t;" >> ai.te
>  > echo "init_daemon_domain(ai_t, ai_exec_t)"
>  > >> ai.te
>  > 
>  > Now lets compile our module:
>  > 
>  > make -f /usr/share/selinux/devel/Makefile
>  > 
>  > Now lets install our module:
>  > 
>  > sudo semodule -i ai.pp
>  > 
>  > Now lets restore the file context of our executable file
>  > and the init
>  > script.
>  > 
>  > restorecon -v /etc/rc.d/init.d/ai
>  > restorecon -v /usr/sbin/ai
>  > 
>  > Now we have to create actual policy. We do this by testing.
>  > Since EL5
>  > does not support permissive domains, we will have to put
>  > the system into
>  > permissive mode: setenforce 0
>  > 
>  > now lets start the daemon:
>  > 
>  > sudo service ai start
>  > 
>  > after some testing of the daemons functionility we stop the
>  > daemon:
>  > 
>  > sudo service ai stop
>  > 
>  > now we enforce selinux again: setenforce 1
>  > 
>  > ..and we check for avc denials and pipe those into
>  > audit2allow to
>  > translate raw avc denials to policy language:
>  > 
>  > ausearch -m avc -ts today | audit2allow -R
>  > 
>  > then we simply append the output to our ai.te file,
>  > recompile and
>  > reinstall.
>  > 
>  > Thats about it in a nutshell.
>  > 
>  > Ofcourse this example is over simplified. there are only
>  > two files owned
>  > by ai. in real life there are more files that need types
>  > (we would use
>  > rpm -ql to find those, and we would inspect the output of
>  > audit2allow -R
>  > to identify any file owned by ai that were created (like
>  > pid files ,
>  > files in /tmp etc etc)
>  > 
>  > Also audit2allow -R's output is not optimal so we would
>  > try to find
>  > optimal interfaces for the policy it may not have
>  > translated in a
>  > optimal way.
>  > 
>  > If you have questions you can also join us on
>  > #fedora-selinux on
>  > irc.freenode.org.
>  > 
>  > happy policy writing!
>  > 
>  > Dominick
>  > 
>  > On Thu, 2009-01-29 at 10:52 -0800, Vadym Chepkov wrote:
>  > > Hi,
>  > > 
>  > > Could somebody give me a working example of a policy
>  > module with transition, please. I am trying to create a
>  > policy for a vendor product I have to use (Asset Insight). 
>  > > The basic idea is to create domains ai_exec_t, ai_t,
>  > proper transition rules for initrc_exec_t -> initrc_t
>  > -> ai_exec_t -> ai_t. 
>  > > Then I want to ai_t be unconfined (for the moment) so
>  > probably make ai_t as an alias of unconfined_t, since there
>  > is no "permissive domain" in Redhat5 yet, but I
>  > want to be able to see what needs to be added to .te file to
>  > make it work. There is no much documentation about writing
>  > policy in Redhat/Fedora, unfortunately, or maybe I am
>  > missing some.
>  > > Thank you.
>  > > 
>  > > Sincerely yours,
>  > >   Vadym Chepkov
>  > > 
>  > > --
>  > > fedora-selinux-list mailing list
>  > > fedora-selinux-list(a)redhat.com
>  > >
>  > https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Vadym Chepkov]

Unfortunately, I have to allow for it to "work" now, but I don't want do
turn off selinux.

My first draft is this, by the way, and it's "working", so managers are off
my back.

ai.te:

policy_module(ai,0.0.1)

type ai_initrc_exec_t;
init_script_type(ai_initrc_exec_t);

type ai_exec_t;
userdom_executable_file(ai_exec_t);

unconfined_alias_domain(ai_t);

init_daemon_domain(ai_t,ai_exec_t)

type ai_log_t;
logging_log_file(ai_log_t)

manage_dirs_pattern(ai_t,ai_log_t,ai_log_t)
manage_files_pattern(ai_t,ai_log_t,ai_log_t)

ai.fc:

/etc/rc\.d/init\.d/ai   --      gen_context(system_u:object_r:ai_initrc_exec_t,s0)
/usr/r/bin/aiadmin      --      gen_context(system_u:object_r:ai_initrc_exec_t,s0)
/usr/r/bin/aiclient     --      gen_context(system_u:object_r:ai_exec_t,s0)
/usr/r/bin/aiagent      --      gen_context(system_u:object_r:ai_exec_t,s0)
/usr/r/logs(/.*)?               gen_context(system_u:object_r:ai_log_t,s0)

I just need to figure out what kind of auditallow statement to put in so it will log what
wasn't specifically allowed only.

The biggest challenge for me, so far, is to figure out all those macros from
/usr/share/selinux/devel/include, I can't find any document that would have them all.


Sincerely yours,
  Vadym Chepkov

[Dominick Grift]

The source policy has all the info and documentation / examples you
need. Eclipse-slide provides easy access.


On Thu, 2009-01-29 at 13:29 -0800, Vadym Chepkov wrote:
>  Unfortunately, I have to allow for it to "work" now, but I
> don't want do turn off selinux.
>  
>  My first draft is this, by the way, and it's "working", so managers are off
> my back.
>  
>  ai.te:
>  
>  policy_module(ai,0.0.1)
>  
>  type ai_initrc_exec_t;
>  init_script_type(ai_initrc_exec_t);
>  
>  type ai_exec_t;
>  userdom_executable_file(ai_exec_t);
>  
>  unconfined_alias_domain(ai_t);
>  
>  init_daemon_domain(ai_t,ai_exec_t)
>  
>  type ai_log_t;
>  logging_log_file(ai_log_t)
>  
>  manage_dirs_pattern(ai_t,ai_log_t,ai_log_t)
>  manage_files_pattern(ai_t,ai_log_t,ai_log_t)
>  
>  ai.fc:
>  
>  /etc/rc\.d/init\.d/ai   --      gen_context(system_u:object_r:ai_initrc_exec_t,s0)
>  /usr/r/bin/aiadmin      --      gen_context(system_u:object_r:ai_initrc_exec_t,s0)
>  /usr/r/bin/aiclient     --      gen_context(system_u:object_r:ai_exec_t,s0)
>  /usr/r/bin/aiagent      --      gen_context(system_u:object_r:ai_exec_t,s0)
>  /usr/r/logs(/.*)?               gen_context(system_u:object_r:ai_log_t,s0)
>  
>  I just need to figure out what kind of auditallow statement to put in so it will log what
> wasn't specifically allowed only.
>  
>  The biggest challenge for me, so far, is to figure out all those macros from
> /usr/share/selinux/devel/include, I can't find any document that would have them all.
>  
>  
>  Sincerely yours,
>    Vadym Chepkov
>

[Dominick Grift]

I don't see how the policy that you have pasted below could possibly
work because you did not even declare a domain type (type ai_t;)

Also there are a bunch of syntax errors there.

If you would have visited us on IRC, than chances are that you would
have a workable policy by now. 


On Thu, 2009-01-29 at 22:44 +0100, Dominick Grift wrote:
>  The source policy has all the info and documentation / examples you
>  need. Eclipse-slide provides easy access.
>  
>  
>  On Thu, 2009-01-29 at 13:29 -0800, Vadym Chepkov wrote:
>  > Unfortunately, I have to allow for it to "work" now, but I don't want
> do turn off selinux.
>  > 
>  > My first draft is this, by the way, and it's "working", so managers
> are off my back.
>  > 
>  > ai.te:
>  > 
>  > policy_module(ai,0.0.1)
>  > 
>  > type ai_initrc_exec_t;
>  > init_script_type(ai_initrc_exec_t);
>  > 
>  > type ai_exec_t;
>  > userdom_executable_file(ai_exec_t);
>  > 
>  > unconfined_alias_domain(ai_t);
>  > 
>  > init_daemon_domain(ai_t,ai_exec_t)
>  > 
>  > type ai_log_t;
>  > logging_log_file(ai_log_t)
>  > 
>  > manage_dirs_pattern(ai_t,ai_log_t,ai_log_t)
>  > manage_files_pattern(ai_t,ai_log_t,ai_log_t)
>  > 
>  > ai.fc:
>  > 
>  > /etc/rc\.d/init\.d/ai   --      gen_context(system_u:object_r:ai_initrc_exec_t,s0)
>  > /usr/r/bin/aiadmin      --      gen_context(system_u:object_r:ai_initrc_exec_t,s0)
>  > /usr/r/bin/aiclient     --      gen_context(system_u:object_r:ai_exec_t,s0)
>  > /usr/r/bin/aiagent      --      gen_context(system_u:object_r:ai_exec_t,s0)
>  > /usr/r/logs(/.*)?               gen_context(system_u:object_r:ai_log_t,s0)
>  > 
>  > I just need to figure out what kind of auditallow statement to put in so it will log
> what wasn't specifically allowed only.
>  > 
>  > The biggest challenge for me, so far, is to figure out all those macros from
> /usr/share/selinux/devel/include, I can't find any document that would have them all.
>  > 
>  > 
>  > Sincerely yours,
>  >   Vadym Chepkov
>  >

[Stephen Smalley]

On Thu, 2009-01-29 at 13:29 -0800, Vadym Chepkov wrote:
>  Unfortunately, I have to allow for it to "work" now, but I
> don't want do turn off selinux.
>  
>  My first draft is this, by the way, and it's "working", so managers are off
> my back.
>  
>  ai.te:
>  
>  policy_module(ai,0.0.1)
>  
>  type ai_initrc_exec_t;
>  init_script_type(ai_initrc_exec_t);
>  
>  type ai_exec_t;
>  userdom_executable_file(ai_exec_t);
>  
>  unconfined_alias_domain(ai_t); 
I don't think you want an alias (i.e. two names for the same domain) but
rather another domain that is unconfined as well.  Use
unconfined_domain().

>  init_daemon_domain(ai_t,ai_exec_t)
>  
>  type ai_log_t;
>  logging_log_file(ai_log_t)
>  
>  manage_dirs_pattern(ai_t,ai_log_t,ai_log_t)
>  manage_files_pattern(ai_t,ai_log_t,ai_log_t)
>  
>  ai.fc:
>  
>  /etc/rc\.d/init\.d/ai   --      gen_context(system_u:object_r:ai_initrc_exec_t,s0)
>  /usr/r/bin/aiadmin      --      gen_context(system_u:object_r:ai_initrc_exec_t,s0)
>  /usr/r/bin/aiclient     --      gen_context(system_u:object_r:ai_exec_t,s0)
>  /usr/r/bin/aiagent      --      gen_context(system_u:object_r:ai_exec_t,s0)
>  /usr/r/logs(/.*)?               gen_context(system_u:object_r:ai_log_t,s0)
>  
>  I just need to figure out what kind of auditallow statement to put in so it will log what
> wasn't specifically allowed only.
>  
>  The biggest challenge for me, so far, is to figure out all those macros from
> /usr/share/selinux/devel/include, I can't find any document that would have them all.
There used to be a /usr/share/doc/selinux-policy* directory that had the
HTML documentation for the policy - not sure where that is now in F10.

Latest interface docs are also online,
http://oss.tresys.com/docs/refpolicy/api/

Interesting question about auditallow; you might need a script to
generate the right set, maybe derived from audit2allow/sepolgen innards.
Watch out though - auditallow'ing everything will flood your system with
too many audit messages.

-- 
Stephen Smalley
National Security Agency

[Vadym Chepkov]

>  I don't see how the policy that you have pasted below
>  could possibly
>  work because you did not even declare a domain type (type
>  ai_t;) 
I swear to God it works and it is defined:
unconfined_alias_domain(ai_t)
I assume this macro takes care of the definition.

>  Also there are a bunch of syntax errors there. 
Compiler didn't find any error

>  If you would have visited us on IRC, than chances are that
>  you would
>  have a workable policy by now.  
And I am trying to find how to create an ID on IRC.
I have a trillian with IRC plugin, but I can't figure out how to create id yet, sorry
about that.

Sincerely yours,
  Vadym Chepkov

[Vadym Chepkov]

>  I don't think you want an alias (i.e. two names for the
>  same domain) but
>  rather another domain that is unconfined as well.  Use
>  unconfined_domain(). 
sshd_t is defined this way in Redhat policy, I learn from the masters :)

$ cd /home/vvc/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services
$ grep sshd_t ssh.te |grep domain
        unconfined_alias_domain(sshd_t)
        init_system_domain(sshd_t,sshd_exec_t)

>  
>  Interesting question about auditallow; you might need a
>  script to
>  generate the right set, maybe derived from
>  audit2allow/sepolgen innards.
>  Watch out though - auditallow'ing everything will flood
>  your system with
>  too many audit messages. 
Exactly, I want to avoid it.

[Stephen Smalley]

On Thu, 2009-01-29 at 14:43 -0800, Vadym Chepkov wrote:
>  > I don't think you want an alias (i.e. two names for the
>  > same domain) but
>  > rather another domain that is unconfined as well.  Use
>  > unconfined_domain().
>  
>  sshd_t is defined this way in Redhat policy, I learn from the masters :)
>  
>  $ cd /home/vvc/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services
>  $ grep sshd_t ssh.te |grep domain
>          unconfined_alias_domain(sshd_t)
>          init_system_domain(sshd_t,sshd_exec_t) 
That has changed in newer policies.  But regardless, if you want to be
able to see allows/denies on ai_t, you can't make it an alias - it needs
to be its own distinct type.  Aliases are just turned into the same
underlying type internally, so they will still show up as unconfined_t
in audit messages and ps -Z output.

>  > 
>  > Interesting question about auditallow; you might need a
>  > script to
>  > generate the right set, maybe derived from
>  > audit2allow/sepolgen innards.
>  > Watch out though - auditallow'ing everything will flood
>  > your system with
>  > too many audit messages.
>  
>  Exactly, I want to avoid it. 
-- 
Stephen Smalley
National Security Agency