Mod-security (mlogc) problem

[Arthur Dent]

Hello all,

I believe in a multi-layered approach towards security, so as well as
SELinux I use Mod-Security to protect the web server on my F11 machine.

Recently I started using the ModSecurity Community Console to analyse
the mod-security denials. This requires using the mlogc logging
application that comes bundled with the mod_security-2.5.12-1.fc11.i586
package.

Now every time a mod-security denial is triggered I get 3 SEL AVCs
(currently in permissive mode while I sort this out). They say:

SELinux has denied the mlogc access to potentially mislabeled files /var/run/pcscd.pid.
This means that SELinux will not allow httpd to use these files. Many third party apps
install html files in directories that SELinux policy cannot predict. These directories
have to be labeled with a file context which httpd can access.
If you want to change the file context of /var/run/pcscd.pid so that the
httpd daemon can access it, you need to execute it using chcon -t
httpd_sys_content_t '/var/run/pcscd.pid'.

A similar one for /var/run/pcsd.pub

and then one for:
SELinux is preventing the mlogc from using potentially mislabeled files
636F6F6C6B6579706B313173452D47617465203020302D30 (auth_cache_t). 

(Actual AVCs below)

If I try doing the chcon -t httpd_sys_content_t '/var/run/pcscd.xxx' as
recommended by sealert I only get the one with the strange filename each
time I get a mod-sec alert. However, now of course I get this:

SELinux denied access requested by certwatch. /var/run/pcscd.pub may be a mislabeled.
/var/run/pcscd.pub default SELinux type is pcscd_var_run_t, but its current type is
httpd_sys_content_t. Changing this file back to the default type, may fix your problem.
(and another one for .pid)

So I need to put the file context back to what it was using
restorecon....

Audit2allow suggests this:

require {
	type auth_cache_t;
	type httpd_t;
	type pcscd_var_run_t;
	class file { read write getattr open };
}

#============= httpd_t ==============
allow httpd_t auth_cache_t:file { read write };
allow httpd_t pcscd_var_run_t:file { read getattr open };

What do you think is the best solution to this problem?

Thanks in advance for any help or suggestions...

Mark

AVCs
====

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270480904.700:37928): avc: denied { read } for
pid=9674 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
tclass=file 
node=troodos.org.uk type=AVC msg=audit(1270480904.700:37928): avc: denied { open } for
pid=9674 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270480904.700:37928): arch=40000003 syscall=5
success=yes exit=10 a0=d348ea a1=0 a2=1b6 a3=d348e8 items=0 ppid=9643 pid=9674
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270488357.977:38184): avc: denied { getattr } for
pid=10531 comm="mlogc" path="/var/run/pcscd.pub" dev=sda5 ino=362221
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270488357.977:38184): arch=40000003
syscall=195 success=yes exit=0 a0=d345ab a1=b64279ac a2=d1eff4 a3=3 items=0 ppid=9643
pid=10531 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270488685.640:38200): avc: denied { read write }
for pid=10661 comm="mlogc" name=636F6F6C6B6579706B313173452D47617465203020302D30
dev=sda5 ino=372384 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=system_u:object_r:auth_cache_t:s0 tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270488685.640:38200): arch=40000003 syscall=5
success=yes exit=12 a0=b5830dc0 a1=20002 a2=180 a3=b5830da8 items=0 ppid=10644 pid=10661
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:httpd_t:s0 key=(null)

[Dominick Grift]

On Wed, Apr 07, 2010 at 03:23:55PM +0100, Arthur Dent wrote:
>  Hello all,
>  
>  I believe in a multi-layered approach towards security, so as well as
>  SELinux I use Mod-Security to protect the web server on my F11 machine.
>  
>  Recently I started using the ModSecurity Community Console to analyse
>  the mod-security denials. This requires using the mlogc logging
>  application that comes bundled with the mod_security-2.5.12-1.fc11.i586
>  package.
>  
>  Now every time a mod-security denial is triggered I get 3 SEL AVCs
>  (currently in permissive mode while I sort this out). They say:
>  
>  SELinux has denied the mlogc access to potentially mislabeled files /var/run/pcscd.pid.
> This means that SELinux will not allow httpd to use these files. Many third party apps
> install html files in directories that SELinux policy cannot predict. These directories
> have to be labeled with a file context which httpd can access.
>  If you want to change the file context of /var/run/pcscd.pid so that the
>  httpd daemon can access it, you need to execute it using chcon -t
>  httpd_sys_content_t '/var/run/pcscd.pid'.
>  
>  A similar one for /var/run/pcsd.pub
>  
>  and then one for:
>  SELinux is preventing the mlogc from using potentially mislabeled files
>  636F6F6C6B6579706B313173452D47617465203020302D30 (auth_cache_t). 
>  
>  (Actual AVCs below)
>  
>  If I try doing the chcon -t httpd_sys_content_t '/var/run/pcscd.xxx' as
>  recommended by sealert I only get the one with the strange filename each
>  time I get a mod-sec alert. However, now of course I get this:
>  
>  SELinux denied access requested by certwatch. /var/run/pcscd.pub may be a mislabeled.
> /var/run/pcscd.pub default SELinux type is pcscd_var_run_t, but its current type is
> httpd_sys_content_t. Changing this file back to the default type, may fix your problem.
>  (and another one for .pid)
>  
>  So I need to put the file context back to what it was using
>  restorecon....
>  
>  Audit2allow suggests this:
>  
>  require {
>  	type auth_cache_t;
>  	type httpd_t;
>  	type pcscd_var_run_t;
>  	class file { read write getattr open };
>  }
>  
>  #============= httpd_t ==============
>  allow httpd_t auth_cache_t:file { read write };
>  allow httpd_t pcscd_var_run_t:file { read getattr open };
>  
>  What do you think is the best solution to this problem? 
Does it work when you allow those access vectors? Eitherway i would set up
a domain transition from apache to a new clogd domain and allow this clogd domain the
access it requires.
I prefer this over extending the httpd_t domain to allow this access.

>  
>  Thanks in advance for any help or suggestions...
>  
>  Mark
>  
>  AVCs
>  ====
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270480904.700:37928): avc: denied { read } for
> pid=9674 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
> tclass=file 
>  node=troodos.org.uk type=AVC msg=audit(1270480904.700:37928): avc: denied { open } for
> pid=9674 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
> tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270480904.700:37928): arch=40000003 syscall=5
> success=yes exit=10 a0=d348ea a1=0 a2=1b6 a3=d348e8 items=0 ppid=9643 pid=9674
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270488357.977:38184): avc: denied { getattr } for
> pid=10531 comm="mlogc" path="/var/run/pcscd.pub" dev=sda5 ino=362221
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
> tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270488357.977:38184): arch=40000003
> syscall=195 success=yes exit=0 a0=d345ab a1=b64279ac a2=d1eff4 a3=3 items=0 ppid=9643
> pid=10531 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270488685.640:38200): avc: denied { read write }
> for pid=10661 comm="mlogc" name=636F6F6C6B6579706B313173452D47617465203020302D30
> dev=sda5 ino=372384 scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=system_u:object_r:auth_cache_t:s0 tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270488685.640:38200): arch=40000003 syscall=5
> success=yes exit=12 a0=b5830dc0 a1=20002 a2=180 a3=b5830da8 items=0 ppid=10644 pid=10661
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>   


>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Dominick Grift]

On Wed, Apr 07, 2010 at 03:23:55PM +0100, Arthur Dent wrote:
>  Hello all,
>  
>  I believe in a multi-layered approach towards security, so as well as
>  SELinux I use Mod-Security to protect the web server on my F11 machine.
>  
>  Recently I started using the ModSecurity Community Console to analyse
>  the mod-security denials. This requires using the mlogc logging
>  application that comes bundled with the mod_security-2.5.12-1.fc11.i586
>  package.
>  
>  Now every time a mod-security denial is triggered I get 3 SEL AVCs
>  (currently in permissive mode while I sort this out). They say:
>  
>  SELinux has denied the mlogc access to potentially mislabeled files /var/run/pcscd.pid.
> This means that SELinux will not allow httpd to use these files. Many third party apps
> install html files in directories that SELinux policy cannot predict. These directories
> have to be labeled with a file context which httpd can access.
>  If you want to change the file context of /var/run/pcscd.pid so that the
>  httpd daemon can access it, you need to execute it using chcon -t
>  httpd_sys_content_t '/var/run/pcscd.pid'.
>  
>  A similar one for /var/run/pcsd.pub
>  
>  and then one for:
>  SELinux is preventing the mlogc from using potentially mislabeled files
>  636F6F6C6B6579706B313173452D47617465203020302D30 (auth_cache_t). 
>  
>  (Actual AVCs below)
>  
>  If I try doing the chcon -t httpd_sys_content_t '/var/run/pcscd.xxx' as
>  recommended by sealert I only get the one with the strange filename each
>  time I get a mod-sec alert. However, now of course I get this:
>  
>  SELinux denied access requested by certwatch. /var/run/pcscd.pub may be a mislabeled.
> /var/run/pcscd.pub default SELinux type is pcscd_var_run_t, but its current type is
> httpd_sys_content_t. Changing this file back to the default type, may fix your problem.
>  (and another one for .pid)
>  
>  So I need to put the file context back to what it was using
>  restorecon....
>  
>  Audit2allow suggests this:
>  
>  require {
>  	type auth_cache_t;
>  	type httpd_t;
>  	type pcscd_var_run_t;
>  	class file { read write getattr open };
>  }
>  
>  #============= httpd_t ==============
>  allow httpd_t auth_cache_t:file { read write };
>  allow httpd_t pcscd_var_run_t:file { read getattr open };
>  
>  What do you think is the best solution to this problem?
>  
>  Thanks in advance for any help or suggestions... 
To create a new policy module for mlogc:

Create a work directory (~/mywork) and go there to do your work: cd ~/mywork
touch 3 files that will be our mlogc source policy module (touch mlogc.te mlogc.if
mlogc.fc)
The .te file is for policy local to mlogc, the .if file has policy that other parties can
call when they want to interact with mlogc, and the .fc file has file context
specifications for mlogc.

So lets start why declaring some types for mlogc, make those types usable and specify and
file contexts that we know are required.

Declare a new policy module in mlogc.te:

policy_module(mlogc, 1.0.0)

New we need to declare a type for the mlogc process and a type for the mlogc executable
file. We make those types a usable application domain by calling the application_domain
interface in mlogc.te:

type mlogc_t;
type mlogc_exec_t;
application_domain(mlogc_t, mlogc_exec_t)

Now lets specify the file context for the mlogc executable file in mlogc.fc:

/usr/bin/mlogc -- gen_context(system_u:object_r:mlogc_exec_t, s0)

Next we should define some policy that facilitates interaction with mlogc for other
domains. httpd_t executes the mlogc executable file and we could facilitate policy that
allows in this case apache to domain transition to our mlogc_t domain. We do this in the
mlogc.if.

We call these shared policy blocks interfaces and they are heavily commented. These
comments can be parsed. for example: make html. The comments describe the functionality of
the policy, and how it should be called.

First we add a description to the mlogc.if file:

## <summary>The ModSecurity Log Collector</summary>

Next we add the shared policy that can be called if other domain want to domain transition
to mlogc_t in mlogc.if:

########################################
## <summary>
##	Execute MLOGC in the MLOGC domain.
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`mlogc_domtrans',`
	gen_require(`
		type mlogc_t, mlogc_exec_t;
	')

	corecmd_search_bin($1)
	domtrans_pattern($1, mlogc_exec_t, mlogc_t)
')

Now we have a solid foundation for our new mlogc policy.

Now httpd_t should call the mlogc_domtrans interface so that it can domain transition when
it runs mlogc.
Since we are not working in the main policy package we should create a patch (custom
module the extends the apache module) so that we can call this interface for httpd_t.

touch a file myapache.te and add the following:

policy_module(myapache, 1.0.0)
optional_policy(`
	gen_require(`
		type httpd_t;
	')

	mlogc_domtrans(httpd_t)
')

The optional_policy tag makes it so that this module does not depend on either the apache
module and our mlogc module. The gen_require tag borrows a type that we use and that is
not local to our module. The httpd_t type is not delcared in our myapache.te file. We
borrow it from the existing apache module.

Now we have two source policy modules: mlogc and myapache.

There are a couple more things we need to take care of. In mlogc.te we should append the
following:

role system_r types mlogc_t;

Apache is a system service. System services use the system_r role. Roles are used for RBAC
or role based access control. Without going into details we just allowed the system_r role
to be used with the mlogc_t domain.

Since our policy module does not actually have much policy yet it must be tested first. We
can make our new clogd_t domain permissive (exempted from SELinux enforcement but SELinux
will still log any access mlogc_t requires and that is currently not allowed) in mlogc.te
append the following:

permissive mlogc_t;

We must remove this line once we are done testing and refining our module.

Now we can try to build binary representations of our two new modules by running the
following command:

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

if all goes well , then two files with the .pp extension are created: myapache.pp and
mlogc.pp

We should now load these two binary policies with the following command:

sudo semodule -i *.pp

Next we must run the restorecon command on /usr/bin/mlogc. So that our new file context
specification for this location can we applied. We can use the -v option to make it
verbose.

sudo restorecon -v /usr/bin/mlogc

Now when you list its attirbutes (ls -alZ /usr/bin/mlogc) you should see our type
mlogc_exec_t.

Time for testing. httpd_t should be allowed to run mlogc in the mlogc_t domain and
currently mlogc_t is a permissive domain, thus mlogc_t should be able to have any access
wrt to SELinux. Any "would be denials" are logged to /var/log/audit/audit.log.
We can use these denials to extend our mlogc_t domain.

So test the app a couple times and collect AVC denials. If you run the AVC denials through
audit2allow with the -R option , then audit2allow with try to find suitable interfaces to
call where applicable. If you use audit2allow without the -R option , then audit2allow
will only translate AVC denials into human readible policy.

Proper policy requires that you only use interface calls in your policy except when the
target in an particular interaction is local to the module (if the target type is declared
in the module)

But this goes beyond the scope of this explanation. You can just paste the output of
audit2allow -R into the mlogc.te file and rebuild the source, then reinstall the
module(s)

make -f /usr/share/selinux/devel/Makefile
sudo semodule -i *.pp

After a few runs when no more AVC denials appear in audit.log for mlogc_t, then you can
remove the permissive declaration from the mlogc.te file (permissive mlogc_t;)

Then rebuild and reinstall the module.

By now mlogc should be confined and working.

 
Disclaimer: I might have missed some important parts. I might have made mistakes. Try at
your own risk
To undo the policy modules:

sudo semodule -r mlocg myapache
restorecon -v /usr/bin/mlogc

hth

>  
>  Mark
>  
>  AVCs
>  ====
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270480904.700:37928): avc: denied { read } for
> pid=9674 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
> tclass=file 
>  node=troodos.org.uk type=AVC msg=audit(1270480904.700:37928): avc: denied { open } for
> pid=9674 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
> tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270480904.700:37928): arch=40000003 syscall=5
> success=yes exit=10 a0=d348ea a1=0 a2=1b6 a3=d348e8 items=0 ppid=9643 pid=9674
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270488357.977:38184): avc: denied { getattr } for
> pid=10531 comm="mlogc" path="/var/run/pcscd.pub" dev=sda5 ino=362221
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
> tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270488357.977:38184): arch=40000003
> syscall=195 success=yes exit=0 a0=d345ab a1=b64279ac a2=d1eff4 a3=3 items=0 ppid=9643
> pid=10531 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270488685.640:38200): avc: denied { read write }
> for pid=10661 comm="mlogc" name=636F6F6C6B6579706B313173452D47617465203020302D30
> dev=sda5 ino=372384 scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=system_u:object_r:auth_cache_t:s0 tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270488685.640:38200): arch=40000003 syscall=5
> success=yes exit=12 a0=b5830dc0 a1=20002 a2=180 a3=b5830da8 items=0 ppid=10644 pid=10661
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>   


>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Arthur Dent]

On Wed, 2010-04-07 at 18:45 +0200, Dominick Grift wrote:
>  On Wed, Apr 07, 2010 at 03:23:55PM +0100, Arthur Dent wrote:
>  > Hello all,
>  > 
>  > I believe in a multi-layered approach towards security, so as well as
>  > SELinux I use Mod-Security to protect the web server on my F11 machine.
>  > 
>  > Recently I started using the ModSecurity Community Console to analyse
>  > the mod-security denials. This requires using the mlogc logging
>  > application that comes bundled with the mod_security-2.5.12-1.fc11.i586
>  > package.
>  > 
>  > Now every time a mod-security denial is triggered I get 3 SEL AVCs
>  > (currently in permissive mode while I sort this out). They say:
>  > 
>  > SELinux has denied the mlogc access to potentially mislabeled files
> /var/run/pcscd.pid. This means that SELinux will not allow httpd to use these files. Many
> third party apps install html files in directories that SELinux policy cannot predict.
> These directories have to be labeled with a file context which httpd can access.
>  > If you want to change the file context of /var/run/pcscd.pid so that the
>  > httpd daemon can access it, you need to execute it using chcon -t
>  > httpd_sys_content_t '/var/run/pcscd.pid'.
>  > 
>  > A similar one for /var/run/pcsd.pub
>  > 
>  > and then one for:
>  > SELinux is preventing the mlogc from using potentially mislabeled files
>  > 636F6F6C6B6579706B313173452D47617465203020302D30 (auth_cache_t). 
>  > 
>  > (Actual AVCs below)
>  > 
>  > If I try doing the chcon -t httpd_sys_content_t '/var/run/pcscd.xxx' as
>  > recommended by sealert I only get the one with the strange filename each
>  > time I get a mod-sec alert. However, now of course I get this:
>  > 
>  > SELinux denied access requested by certwatch. /var/run/pcscd.pub may be a
> mislabeled. /var/run/pcscd.pub default SELinux type is pcscd_var_run_t, but its current
> type is httpd_sys_content_t. Changing this file back to the default type, may fix your
> problem.
>  > (and another one for .pid)
>  > 
>  > So I need to put the file context back to what it was using
>  > restorecon....
>  > 
>  > Audit2allow suggests this:
>  > 
>  > require {
>  > 	type auth_cache_t;
>  > 	type httpd_t;
>  > 	type pcscd_var_run_t;
>  > 	class file { read write getattr open };
>  > }
>  > 
>  > #============= httpd_t ==============
>  > allow httpd_t auth_cache_t:file { read write };
>  > allow httpd_t pcscd_var_run_t:file { read getattr open };
>  > 
>  > What do you think is the best solution to this problem?
>  > 
>  > Thanks in advance for any help or suggestions...
>  
>  To create a new policy module for mlogc:
>  
>  Create a work directory (~/mywork) and go there to do your work: cd ~/mywork
>  touch 3 files that will be our mlogc source policy module (touch mlogc.te mlogc.if
> mlogc.fc)
>  The .te file is for policy local to mlogc, the .if file has policy that other parties can
> call when they want to interact with mlogc, and the .fc file has file context
> specifications for mlogc.
>  
>  So lets start why declaring some types for mlogc, make those types usable and specify and
> file contexts that we know are required.
>  
>  Declare a new policy module in mlogc.te:
>  
>  policy_module(mlogc, 1.0.0)
>  
>  New we need to declare a type for the mlogc process and a type for the mlogc executable
> file. We make those types a usable application domain by calling the application_domain
> interface in mlogc.te:
>  
>  type mlogc_t;
>  type mlogc_exec_t;
>  application_domain(mlogc_t, mlogc_exec_t)
>  
>  Now lets specify the file context for the mlogc executable file in mlogc.fc:
>  
>  /usr/bin/mlogc -- gen_context(system_u:object_r:mlogc_exec_t, s0)
>  
>  Next we should define some policy that facilitates interaction with mlogc for other
> domains. httpd_t executes the mlogc executable file and we could facilitate policy that
> allows in this case apache to domain transition to our mlogc_t domain. We do this in the
> mlogc.if.
>  
>  We call these shared policy blocks interfaces and they are heavily commented. These
> comments can be parsed. for example: make html. The comments describe the functionality of
> the policy, and how it should be called.
>  
>  First we add a description to the mlogc.if file:
>  
>  ## <summary>The ModSecurity Log Collector</summary>
>  
>  Next we add the shared policy that can be called if other domain want to domain
> transition to mlogc_t in mlogc.if:
>  
>  ########################################
>  ## <summary>
>  ##	Execute MLOGC in the MLOGC domain.
>  ## </summary>
>  ## <param name="domain">
>  ##	<summary>
>  ##	Domain allowed access.
>  ##	</summary>
>  ## </param>
>  #
>  interface(`mlogc_domtrans',`
>  	gen_require(`
>  		type mlogc_t, mlogc_exec_t;
>  	')
>  
>  	corecmd_search_bin($1)
>  	domtrans_pattern($1, mlogc_exec_t, mlogc_t)
>  ')
>  
>  Now we have a solid foundation for our new mlogc policy.
>  
>  Now httpd_t should call the mlogc_domtrans interface so that it can domain transition
> when it runs mlogc.
>  Since we are not working in the main policy package we should create a patch (custom
> module the extends the apache module) so that we can call this interface for httpd_t.
>  
>  touch a file myapache.te and add the following:
>  
>  policy_module(myapache, 1.0.0)
>  optional_policy(`
>  	gen_require(`
>  		type httpd_t;
>  	')
>  
>  	mlogc_domtrans(httpd_t)
>  ')
>  
>  The optional_policy tag makes it so that this module does not depend on either the apache
> module and our mlogc module. The gen_require tag borrows a type that we use and that is
> not local to our module. The httpd_t type is not delcared in our myapache.te file. We
> borrow it from the existing apache module.
>  
>  Now we have two source policy modules: mlogc and myapache.
>  
>  There are a couple more things we need to take care of. In mlogc.te we should append the
> following:
>  
>  role system_r types mlogc_t;
>  
>  Apache is a system service. System services use the system_r role. Roles are used for
> RBAC or role based access control. Without going into details we just allowed the system_r
> role to be used with the mlogc_t domain.
>  
>  Since our policy module does not actually have much policy yet it must be tested first.
> We can make our new clogd_t domain permissive (exempted from SELinux enforcement but
> SELinux will still log any access mlogc_t requires and that is currently not allowed) in
> mlogc.te append the following:
>  
>  permissive mlogc_t;
>  
>  We must remove this line once we are done testing and refining our module.
>  
>  Now we can try to build binary representations of our two new modules by running the
> following command:
>  
>  make -f /usr/share/selinux/devel/Makefile
>  
>  if all goes well , then two files with the .pp extension are created: myapache.pp and
> mlogc.pp
>  
>  We should now load these two binary policies with the following command:
>  
>  sudo semodule -i *.pp
>  
>  Next we must run the restorecon command on /usr/bin/mlogc. So that our new file context
> specification for this location can we applied. We can use the -v option to make it
> verbose.
>  
>  sudo restorecon -v /usr/bin/mlogc
>  
>  Now when you list its attirbutes (ls -alZ /usr/bin/mlogc) you should see our type
> mlogc_exec_t.
>  
>  Time for testing. httpd_t should be allowed to run mlogc in the mlogc_t domain and
> currently mlogc_t is a permissive domain, thus mlogc_t should be able to have any access
> wrt to SELinux. Any "would be denials" are logged to /var/log/audit/audit.log.
> We can use these denials to extend our mlogc_t domain.
>  
>  So test the app a couple times and collect AVC denials. If you run the AVC denials
> through audit2allow with the -R option , then audit2allow with try to find suitable
> interfaces to call where applicable. If you use audit2allow without the -R option , then
> audit2allow will only translate AVC denials into human readible policy.
>  
>  Proper policy requires that you only use interface calls in your policy except when the
> target in an particular interaction is local to the module (if the target type is declared
> in the module)
>  
>  But this goes beyond the scope of this explanation. You can just paste the output of
> audit2allow -R into the mlogc.te file and rebuild the source, then reinstall the
> module(s)
>  
>  make -f /usr/share/selinux/devel/Makefile
>  sudo semodule -i *.pp
>  
>  After a few runs when no more AVC denials appear in audit.log for mlogc_t, then you can
> remove the permissive declaration from the mlogc.te file (permissive mlogc_t;)
>  
>  Then rebuild and reinstall the module.
>  
>  By now mlogc should be confined and working.
>  
>   
>  Disclaimer: I might have missed some important parts. I might have made mistakes. Try at
> your own risk
>  To undo the policy modules:
>  
>  sudo semodule -r mlocg myapache
>  restorecon -v /usr/bin/mlogc
>  
>  hth 
WOW! That is so helpful - Thank you! After your first message I was just
googling to try to find out how to create a domain transition - just
about to give up and ask when this post came in... Thanks for going to
so much trouble.

I followed your instructions exactly and everything seemed to work as
intended.

I have to say however that on testing I get 3 AVCs (see below), just as
before!...

Have I missed something or misunderstood something?

Based on these 3 AVCs audit2allow -R produces the following:

######################################
require {
	type httpd_t;
}

#============= httpd_t ==============
pcscd_read_pub_files(httpd_t)

######################################

Is that what you would expect?


Thanks again for your help...

Mark


Most recent AVCs
================

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270666306.338:44518): avc: denied { getattr } for
pid=32012 comm="mlogc" path="/var/run/pcscd.pub" dev=sda5 ino=362221
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270666306.338:44518): arch=40000003
syscall=195 success=yes exit=0 a0=1fc5ab a1=b643f9ac a2=d1eff4 a3=3 items=0 ppid=29448
pid=32012 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270666306.342:44519): avc: denied { read } for
pid=32012 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
tclass=file 
node=troodos.org.uk type=AVC msg=audit(1270666306.342:44519): avc: denied { open } for
pid=32012 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270666306.342:44519): arch=40000003 syscall=5
success=yes exit=13 a0=1fc8ea a1=0 a2=1b6 a3=1fc8e8 items=0 ppid=29448 pid=32012
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270666306.342:44519): avc: denied { read } for
pid=32012 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
tclass=file 
node=troodos.org.uk type=AVC msg=audit(1270666306.342:44519): avc: denied { open } for
pid=32012 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270666306.342:44519): arch=40000003 syscall=5
success=yes exit=13 a0=1fc8ea a1=0 a2=1b6 a3=1fc8e8 items=0 ppid=29448 pid=32012
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:httpd_t:s0 key=(null)

[Dominick Grift]

On Wed, Apr 07, 2010 at 08:02:21PM +0100, Arthur Dent wrote:
>  On Wed, 2010-04-07 at 18:45 +0200, Dominick Grift wrote:
>  > On Wed, Apr 07, 2010 at 03:23:55PM +0100, Arthur Dent wrote:
>  > > Hello all,
>  > > 
>  > > I believe in a multi-layered approach towards security, so as well as
>  > > SELinux I use Mod-Security to protect the web server on my F11 machine.
>  > > 
>  > > Recently I started using the ModSecurity Community Console to analyse
>  > > the mod-security denials. This requires using the mlogc logging
>  > > application that comes bundled with the mod_security-2.5.12-1.fc11.i586
>  > > package.
>  > > 
>  > > Now every time a mod-security denial is triggered I get 3 SEL AVCs
>  > > (currently in permissive mode while I sort this out). They say:
>  > > 
>  > > SELinux has denied the mlogc access to potentially mislabeled files
> /var/run/pcscd.pid. This means that SELinux will not allow httpd to use these files. Many
> third party apps install html files in directories that SELinux policy cannot predict.
> These directories have to be labeled with a file context which httpd can access.
>  > > If you want to change the file context of /var/run/pcscd.pid so that the
>  > > httpd daemon can access it, you need to execute it using chcon -t
>  > > httpd_sys_content_t '/var/run/pcscd.pid'.
>  > > 
>  > > A similar one for /var/run/pcsd.pub
>  > > 
>  > > and then one for:
>  > > SELinux is preventing the mlogc from using potentially mislabeled files
>  > > 636F6F6C6B6579706B313173452D47617465203020302D30 (auth_cache_t). 
>  > > 
>  > > (Actual AVCs below)
>  > > 
>  > > If I try doing the chcon -t httpd_sys_content_t '/var/run/pcscd.xxx'
> as
>  > > recommended by sealert I only get the one with the strange filename each
>  > > time I get a mod-sec alert. However, now of course I get this:
>  > > 
>  > > SELinux denied access requested by certwatch. /var/run/pcscd.pub may be a
> mislabeled. /var/run/pcscd.pub default SELinux type is pcscd_var_run_t, but its current
> type is httpd_sys_content_t. Changing this file back to the default type, may fix your
> problem.
>  > > (and another one for .pid)
>  > > 
>  > > So I need to put the file context back to what it was using
>  > > restorecon....
>  > > 
>  > > Audit2allow suggests this:
>  > > 
>  > > require {
>  > > 	type auth_cache_t;
>  > > 	type httpd_t;
>  > > 	type pcscd_var_run_t;
>  > > 	class file { read write getattr open };
>  > > }
>  > > 
>  > > #============= httpd_t ==============
>  > > allow httpd_t auth_cache_t:file { read write };
>  > > allow httpd_t pcscd_var_run_t:file { read getattr open };
>  > > 
>  > > What do you think is the best solution to this problem?
>  > > 
>  > > Thanks in advance for any help or suggestions...
>  > 
>  > To create a new policy module for mlogc:
>  > 
>  > Create a work directory (~/mywork) and go there to do your work: cd ~/mywork
>  > touch 3 files that will be our mlogc source policy module (touch mlogc.te mlogc.if
> mlogc.fc)
>  > The .te file is for policy local to mlogc, the .if file has policy that other
> parties can call when they want to interact with mlogc, and the .fc file has file context
> specifications for mlogc.
>  > 
>  > So lets start why declaring some types for mlogc, make those types usable and
> specify and file contexts that we know are required.
>  > 
>  > Declare a new policy module in mlogc.te:
>  > 
>  > policy_module(mlogc, 1.0.0)
>  > 
>  > New we need to declare a type for the mlogc process and a type for the mlogc
> executable file. We make those types a usable application domain by calling the
> application_domain interface in mlogc.te:
>  > 
>  > type mlogc_t;
>  > type mlogc_exec_t;
>  > application_domain(mlogc_t, mlogc_exec_t)
>  > 
>  > Now lets specify the file context for the mlogc executable file in mlogc.fc:
>  > 
>  > /usr/bin/mlogc -- gen_context(system_u:object_r:mlogc_exec_t, s0)
>  > 
>  > Next we should define some policy that facilitates interaction with mlogc for other
> domains. httpd_t executes the mlogc executable file and we could facilitate policy that
> allows in this case apache to domain transition to our mlogc_t domain. We do this in the
> mlogc.if.
>  > 
>  > We call these shared policy blocks interfaces and they are heavily commented. These
> comments can be parsed. for example: make html. The comments describe the functionality of
> the policy, and how it should be called.
>  > 
>  > First we add a description to the mlogc.if file:
>  > 
>  > ## <summary>The ModSecurity Log Collector</summary>
>  > 
>  > Next we add the shared policy that can be called if other domain want to domain
> transition to mlogc_t in mlogc.if:
>  > 
>  > ########################################
>  > ## <summary>
>  > ##	Execute MLOGC in the MLOGC domain.
>  > ## </summary>
>  > ## <param name="domain">
>  > ##	<summary>
>  > ##	Domain allowed access.
>  > ##	</summary>
>  > ## </param>
>  > #
>  > interface(`mlogc_domtrans',`
>  > 	gen_require(`
>  > 		type mlogc_t, mlogc_exec_t;
>  > 	')
>  > 
>  > 	corecmd_search_bin($1)
>  > 	domtrans_pattern($1, mlogc_exec_t, mlogc_t)
>  > ')
>  > 
>  > Now we have a solid foundation for our new mlogc policy.
>  > 
>  > Now httpd_t should call the mlogc_domtrans interface so that it can domain
> transition when it runs mlogc.
>  > Since we are not working in the main policy package we should create a patch (custom
> module the extends the apache module) so that we can call this interface for httpd_t.
>  > 
>  > touch a file myapache.te and add the following:
>  > 
>  > policy_module(myapache, 1.0.0)
>  > optional_policy(`
>  > 	gen_require(`
>  > 		type httpd_t;
>  > 	')
>  > 
>  > 	mlogc_domtrans(httpd_t)
>  > ')
>  > 
>  > The optional_policy tag makes it so that this module does not depend on either the
> apache module and our mlogc module. The gen_require tag borrows a type that we use and
> that is not local to our module. The httpd_t type is not delcared in our myapache.te file.
> We borrow it from the existing apache module.
>  > 
>  > Now we have two source policy modules: mlogc and myapache.
>  > 
>  > There are a couple more things we need to take care of. In mlogc.te we should append
> the following:
>  > 
>  > role system_r types mlogc_t;
>  > 
>  > Apache is a system service. System services use the system_r role. Roles are used
> for RBAC or role based access control. Without going into details we just allowed the
> system_r role to be used with the mlogc_t domain.
>  > 
>  > Since our policy module does not actually have much policy yet it must be tested
> first. We can make our new clogd_t domain permissive (exempted from SELinux enforcement
> but SELinux will still log any access mlogc_t requires and that is currently not allowed)
> in mlogc.te append the following:
>  > 
>  > permissive mlogc_t;
>  > 
>  > We must remove this line once we are done testing and refining our module.
>  > 
>  > Now we can try to build binary representations of our two new modules by running the
> following command:
>  > 
>  > make -f /usr/share/selinux/devel/Makefile
>  > 
>  > if all goes well , then two files with the .pp extension are created: myapache.pp
> and mlogc.pp
>  > 
>  > We should now load these two binary policies with the following command:
>  > 
>  > sudo semodule -i *.pp
>  > 
>  > Next we must run the restorecon command on /usr/bin/mlogc. So that our new file
> context specification for this location can we applied. We can use the -v option to make
> it verbose.
>  > 
>  > sudo restorecon -v /usr/bin/mlogc
>  > 
>  > Now when you list its attirbutes (ls -alZ /usr/bin/mlogc) you should see our type
> mlogc_exec_t.
>  > 
>  > Time for testing. httpd_t should be allowed to run mlogc in the mlogc_t domain and
> currently mlogc_t is a permissive domain, thus mlogc_t should be able to have any access
> wrt to SELinux. Any "would be denials" are logged to /var/log/audit/audit.log.
> We can use these denials to extend our mlogc_t domain.
>  > 
>  > So test the app a couple times and collect AVC denials. If you run the AVC denials
> through audit2allow with the -R option , then audit2allow with try to find suitable
> interfaces to call where applicable. If you use audit2allow without the -R option , then
> audit2allow will only translate AVC denials into human readible policy.
>  > 
>  > Proper policy requires that you only use interface calls in your policy except when
> the target in an particular interaction is local to the module (if the target type is
> declared in the module)
>  > 
>  > But this goes beyond the scope of this explanation. You can just paste the output of
> audit2allow -R into the mlogc.te file and rebuild the source, then reinstall the
> module(s)
>  > 
>  > make -f /usr/share/selinux/devel/Makefile
>  > sudo semodule -i *.pp
>  > 
>  > After a few runs when no more AVC denials appear in audit.log for mlogc_t, then you
> can remove the permissive declaration from the mlogc.te file (permissive mlogc_t;)
>  > 
>  > Then rebuild and reinstall the module.
>  > 
>  > By now mlogc should be confined and working.
>  > 
>  >  
>  > Disclaimer: I might have missed some important parts. I might have made mistakes.
> Try at your own risk
>  > To undo the policy modules:
>  > 
>  > sudo semodule -r mlocg myapache
>  > restorecon -v /usr/bin/mlogc
>  > 
>  > hth
>  
>  WOW! That is so helpful - Thank you! After your first message I was just
>  googling to try to find out how to create a domain transition - just
>  about to give up and ask when this post came in... Thanks for going to
>  so much trouble.
>  
>  I followed your instructions exactly and everything seemed to work as
>  intended.
>  
>  I have to say however that on testing I get 3 AVCs (see below), just as
>  before!...
>  
>  Have I missed something or misunderstood something? 
Yes it seems that the domain transition did not happen. are the modules installed:

semodule -l | grep myapache
semodule -l | grep mlogc

Is the context of mlogc executable file proper?

ls -alZ /usr/bin/mlogc

Something seems to have gone not as planned

>  
>  Based on these 3 AVCs audit2allow -R produces the following:
>  
>  ######################################
>  require {
>  	type httpd_t;
>  }
>  
>  #============= httpd_t ==============
>  pcscd_read_pub_files(httpd_t)
>  
>  ######################################
>  
>  Is that what you would expect?
>  
>  
>  Thanks again for your help...
>  
>  Mark
>  
>  
>  Most recent AVCs
>  ================
>  
>  Raw Audit Messages : 
l> 
>  node=troodos.org.uk type=AVC msg=audit(1270666306.338:44518): avc:
> denied { getattr } for pid=32012 comm="mlogc"
> path="/var/run/pcscd.pub" dev=sda5 ino=362221
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
> tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270666306.338:44518): arch=40000003
> syscall=195 success=yes exit=0 a0=1fc5ab a1=b643f9ac a2=d1eff4 a3=3 items=0 ppid=29448
> pid=32012 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270666306.342:44519): avc: denied { read } for
> pid=32012 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
> tclass=file 
>  node=troodos.org.uk type=AVC msg=audit(1270666306.342:44519): avc: denied { open } for
> pid=32012 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
> tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270666306.342:44519): arch=40000003 syscall=5
> success=yes exit=13 a0=1fc8ea a1=0 a2=1b6 a3=1fc8e8 items=0 ppid=29448 pid=32012
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270666306.342:44519): avc: denied { read } for
> pid=32012 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
> tclass=file 
>  node=troodos.org.uk type=AVC msg=audit(1270666306.342:44519): avc: denied { open } for
> pid=32012 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
> tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270666306.342:44519): arch=40000003 syscall=5
> success=yes exit=13 a0=1fc8ea a1=0 a2=1b6 a3=1fc8e8 items=0 ppid=29448 pid=32012
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null)
>  
>   


>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Arthur Dent]

On Wed, 2010-04-07 at 22:26 +0200, Dominick Grift wrote:
>  On Wed, Apr 07, 2010 at 08:02:21PM +0100, Arthur Dent wrote:
>  > On Wed, 2010-04-07 at 18:45 +0200, Dominick Grift wrote:
>  > > On Wed, Apr 07, 2010 at 03:23:55PM +0100, Arthur Dent wrote:
>  > > > Hello all,
>  > > > 
>  > > > 
>  > Have I missed something or misunderstood something?
>  
>  Yes it seems that the domain transition did not happen. are the modules installed:
>  
>  semodule -l | grep myapache
>  semodule -l | grep mlogc 
# semodule -l | grep myapache
myapache	1.0.0

# semodule -l | grep mlogc
mlogc	1.0.0


>  Is the context of mlogc executable file proper?
>  
>  ls -alZ /usr/bin/mlogc 
# ls -alZ /usr/bin/mlogc
-rwxr-xr-x. root root system_u:object_r:mlogc_exec_t:s0 /usr/bin/mlogc

>  Something seems to have gone not as planned 
Well all of that seems OK - I'm not sure why it's not working?

Thanks for your help so far though - it's much appreciated...

Mark

[Dominick Grift]

On Wed, Apr 07, 2010 at 09:51:24PM +0100, Arthur Dent wrote:
>  On Wed, 2010-04-07 at 22:26 +0200, Dominick Grift wrote:
>  > On Wed, Apr 07, 2010 at 08:02:21PM +0100, Arthur Dent wrote:
>  > > On Wed, 2010-04-07 at 18:45 +0200, Dominick Grift wrote:
>  > > > On Wed, Apr 07, 2010 at 03:23:55PM +0100, Arthur Dent wrote:
>  > > > > Hello all,
>  > > > > 
>  > > > > 
>  > > Have I missed something or misunderstood something?
>  > 
>  > Yes it seems that the domain transition did not happen. are the modules installed:
>  > 
>  > semodule -l | grep myapache
>  > semodule -l | grep mlogc
>  
>  # semodule -l | grep myapache
>  myapache	1.0.0
>  
>  # semodule -l | grep mlogc
>  mlogc	1.0.0
>  
>  
>  > Is the context of mlogc executable file proper?
>  > 
>  > ls -alZ /usr/bin/mlogc
>  
>  # ls -alZ /usr/bin/mlogc
>  -rwxr-xr-x. root root system_u:object_r:mlogc_exec_t:s0 /usr/bin/mlogc
>  
>  > Something seems to have gone not as planned
>  
>  Well all of that seems OK - I'm not sure why it's not working?
>  
>  Thanks for your help so far though - it's much appreciated... 
You could try to remove the optional_policy(` tag and its closing ') tag, that might
expose any errors if you build without those.

can you paste you modules? so that i can review them?



>  
>  Mark
>   


>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Arthur Dent]

On Wed, 2010-04-07 at 23:01 +0200, Dominick Grift wrote:
>  On Wed, Apr 07, 2010 at 09:51:24PM +0100, Arthur Dent wrote:
>  > On Wed, 2010-04-07 at 22:26 +0200, Dominick Grift wrote:
>  > > On Wed, Apr 07, 2010 at 08:02:21PM +0100, Arthur Dent wrote:
>  > > > On Wed, 2010-04-07 at 18:45 +0200, Dominick Grift wrote:
>  > > > > On Wed, Apr 07, 2010 at 03:23:55PM +0100, Arthur Dent wrote:
>  > > > > > Hello all,
>  > > > > > 
>  > > > > > 
>  > > > Have I missed something or misunderstood something?
>  > > 
>  > > Yes it seems that the domain transition did not happen. are the modules
> installed:
>  > > 
>  > > semodule -l | grep myapache
>  > > semodule -l | grep mlogc
>  > 
>  > # semodule -l | grep myapache
>  > myapache	1.0.0
>  > 
>  > # semodule -l | grep mlogc
>  > mlogc	1.0.0
>  > 
>  > 
>  > > Is the context of mlogc executable file proper?
>  > > 
>  > > ls -alZ /usr/bin/mlogc
>  > 
>  > # ls -alZ /usr/bin/mlogc
>  > -rwxr-xr-x. root root system_u:object_r:mlogc_exec_t:s0 /usr/bin/mlogc
>  > 
>  > > Something seems to have gone not as planned
>  > 
>  > Well all of that seems OK - I'm not sure why it's not working?
>  > 
>  > Thanks for your help so far though - it's much appreciated...
>  
>  You could try to remove the optional_policy(` tag and its closing ') tag, that might
> expose any errors if you build without those.
>  
>  can you paste you modules? so that i can review them? 
# cat mlogc.te 
policy_module(mlogc, 1.0.0)

type mlogc_t;
type mlogc_exec_t;
application_domain(mlogc_t, mlogc_exec_t)

role system_r types mlogc_t;
permissive mlogc_t;

####################################################################

# cat mlogc.fc 
/usr/bin/mlogc -- gen_context(system_u:object_r:mlogc_exec_t, s0)


####################################################################

# cat mlogc.if 
## <summary>The ModSecurity Log Collector</summary>

########################################
## <summary>
##      Execute MLOGC in the MLOGC domain.
## </summary>
## <param name="domain">
##      <summary>
##      Domain allowed access.
##      </summary>
## </param>
#
interface(`mlogc_domtrans',`
        gen_require(`
                type mlogc_t, mlogc_exec_t;
        ')

        corecmd_search_bin($1)
        domtrans_pattern($1, mlogc_exec_t, mlogc_t)
')

####################################################################

# cat myapche.te 
policy_module(myapache, 1.0.0)
optional_policy(`
        gen_require(`
                type httpd_t;
        ')

        mlogc_domtrans(httpd_t)
')

####################################################################


Is that right?

Thank again. I do appreciate your help.


Mark

[Dominick Grift]

On Wed, Apr 07, 2010 at 10:23:24PM +0100, Arthur Dent wrote:
>  On Wed, 2010-04-07 at 23:01 +0200, Dominick Grift wrote:
>  > On Wed, Apr 07, 2010 at 09:51:24PM +0100, Arthur Dent wrote:
>  > > On Wed, 2010-04-07 at 22:26 +0200, Dominick Grift wrote:
>  > > > On Wed, Apr 07, 2010 at 08:02:21PM +0100, Arthur Dent wrote:
>  > > > > On Wed, 2010-04-07 at 18:45 +0200, Dominick Grift wrote:
>  > > > > > On Wed, Apr 07, 2010 at 03:23:55PM +0100, Arthur Dent wrote:
>  > > > > > > Hello all,
>  > > > > > > 
>  > > > > > > 
>  > > > > Have I missed something or misunderstood something?
>  > > > 
>  > > > Yes it seems that the domain transition did not happen. are the modules
> installed:
>  > > > 
>  > > > semodule -l | grep myapache
>  > > > semodule -l | grep mlogc
>  > > 
>  > > # semodule -l | grep myapache
>  > > myapache	1.0.0
>  > > 
>  > > # semodule -l | grep mlogc
>  > > mlogc	1.0.0
>  > > 
>  > > 
>  > > > Is the context of mlogc executable file proper?
>  > > > 
>  > > > ls -alZ /usr/bin/mlogc
>  > > 
>  > > # ls -alZ /usr/bin/mlogc
>  > > -rwxr-xr-x. root root system_u:object_r:mlogc_exec_t:s0 /usr/bin/mlogc
>  > > 
>  > > > Something seems to have gone not as planned
>  > > 
>  > > Well all of that seems OK - I'm not sure why it's not working?
>  > > 
>  > > Thanks for your help so far though - it's much appreciated...
>  > 
>  > You could try to remove the optional_policy(` tag and its closing ') tag, that
> might expose any errors if you build without those.
>  > 
>  > can you paste you modules? so that i can review them?
>  
>  # cat mlogc.te 
>  policy_module(mlogc, 1.0.0)
>  
>  type mlogc_t;
>  type mlogc_exec_t;
>  application_domain(mlogc_t, mlogc_exec_t)
>  
>  role system_r types mlogc_t;
>  permissive mlogc_t;
>  
>  ####################################################################
>  
>  # cat mlogc.fc 
>  /usr/bin/mlogc -- gen_context(system_u:object_r:mlogc_exec_t, s0)
>  
>  
>  ####################################################################
>  
>  # cat mlogc.if 
>  ## <summary>The ModSecurity Log Collector</summary>
>  
>  ########################################
>  ## <summary>
>  ##      Execute MLOGC in the MLOGC domain.
>  ## </summary>
>  ## <param name="domain">
>  ##      <summary>
>  ##      Domain allowed access.
>  ##      </summary>
>  ## </param>
>  #
>  interface(`mlogc_domtrans',`
>          gen_require(`
>                  type mlogc_t, mlogc_exec_t;
>          ')
>  
>          corecmd_search_bin($1)
>          domtrans_pattern($1, mlogc_exec_t, mlogc_t)
>  ')
>  
>  ####################################################################
>  
>  # cat myapche.te 
>  policy_module(myapache, 1.0.0)
>  optional_policy(`
>          gen_require(`
>                  type httpd_t;
>          ')
>  
>          mlogc_domtrans(httpd_t)
>  ')
>  
>  ####################################################################
>  
>  
>  Is that right?
>  
>  Thank again. I do appreciate your help.
>  
>  
>  Mark
>   
Yes looks fine. try the following myapache.te instead:

policy_module(myapache, 1.0.0)
gen_require(`
type httpd_t;
')
mlogc_domtrans(httpd_t)

build, install

make -f /usr/share/selinux/devel/Makefile
sudo semodule -i *.pp

>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Arthur Dent]

On Wed, 2010-04-07 at 23:35 +0200, Dominick Grift wrote:

>  
>  Yes looks fine. try the following myapache.te instead:
>  
>  policy_module(myapache, 1.0.0)
>  gen_require(`
>  type httpd_t;
>  ')
>  mlogc_domtrans(httpd_t)
>  
>  build, install
>  
>  make -f /usr/share/selinux/devel/Makefile
>  sudo semodule -i *.pp 
OK - Caused a mere 16 AVCs (admittedly in permissive mode):

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { write } for
pid=952 comm="mlogc" name="mlogc" dev=sda5 ino=578025
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:httpd_log_t:s0
tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { add_name } for
pid=952 comm="mlogc" name="mlogc-queue.log.new"
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:httpd_log_t:s0
tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { create } for
pid=952 comm="mlogc" name="mlogc-queue.log.new"
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:object_r:httpd_log_t:s0
tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270677188.477:44957): arch=40000003 syscall=5
success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { write } for
pid=952 comm="mlogc" name="mlogc" dev=sda5 ino=578025
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:httpd_log_t:s0
tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { add_name } for
pid=952 comm="mlogc" name="mlogc-queue.log.new"
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:httpd_log_t:s0
tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { create } for
pid=952 comm="mlogc" name="mlogc-queue.log.new"
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:object_r:httpd_log_t:s0
tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270677188.477:44957): arch=40000003 syscall=5
success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { write } for
pid=952 comm="mlogc" name="mlogc" dev=sda5 ino=578025
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:httpd_log_t:s0
tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { add_name } for
pid=952 comm="mlogc" name="mlogc-queue.log.new"
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:httpd_log_t:s0
tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { create } for
pid=952 comm="mlogc" name="mlogc-queue.log.new"
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:object_r:httpd_log_t:s0
tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270677188.477:44957): arch=40000003 syscall=5
success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 


Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270677188.484:44958): avc: denied { remove_name }
for pid=952 comm="mlogc" name="mlogc-queue.log" dev=sda5 ino=578431
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:httpd_log_t:s0
tclass=dir 
node=troodos.org.uk type=SYSCALL msg=audit(1270677188.484:44958): arch=40000003 syscall=38
success=yes exit=0 a0=84c01e8 a1=b76fd070 a2=7581e4 a3=0 items=0 ppid=937 pid=952
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null)

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270677188.494:44959): avc: denied { rename } for
pid=952 comm="mlogc" name="mlogc-queue.log.new" dev=sda5 ino=578432
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:object_r:httpd_log_t:s0
tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270677188.494:44959): arch=40000003 syscall=38
success=yes exit=0 a0=b76fd170 a1=84c01e8 a2=7581e4 a3=0 items=0 ppid=937 pid=952
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270677188.497:44960): avc: denied { write } for
pid=952 comm="mlogc" name="mlogc-transaction.log" dev=sda5 ino=578031
scontext=unconfined_u:system_r:mlogc_t:s0
tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270677188.497:44960): arch=40000003
syscall=194 success=yes exit=0 a0=5 a1=0 a2=0 a3=84c05c0 items=0 ppid=937 pid=952
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 


Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270677208.496:44961): avc: denied { unlink } for
pid=952 comm="mlogc" name="mlogc-queue.log.old" dev=sda5 ino=578432
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:object_r:httpd_log_t:s0
tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270677208.496:44961): arch=40000003 syscall=10
success=yes exit=0 a0=b76fd070 a1=84c01e8 a2=7581e4 a3=0 items=0 ppid=937 pid=952
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 


Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270677254.661:44966): avc: denied { create } for
pid=944 comm="httpd" name="20100407-2254"
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_log_t:s0
tclass=dir 
node=troodos.org.uk type=SYSCALL msg=audit(1270677254.661:44966): arch=40000003 syscall=39
success=yes exit=0 a0=24e17a8 a1=1e8 a2=80a1e4 a3=24e1748 items=0 ppid=937 pid=944
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 


Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270677254.673:44967): avc: denied { write } for
pid=944 comm="httpd" name="20100407-225414-S7z-BlIrkOUAAAOwOYMAAAAB"
dev=sda5 ino=658630 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:httpd_log_t:s0 tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270677254.673:44967): arch=40000003 syscall=5
success=yes exit=19 a0=24e1748 a1=8241 a2=1a0 a3=836 items=0 ppid=937 pid=944
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 


Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270677254.679:44968): avc: denied { setopt } for
pid=1412 comm="mlogc" laddr=127.0.0.1 lport=56280 faddr=127.0.0.1 fport=8888
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0
tclass=tcp_socket 
node=troodos.org.uk type=SYSCALL msg=audit(1270677254.679:44968): arch=40000003
syscall=102 success=yes exit=0 a0=e a1=b62fa5d0 a2=3ff8550 a3=b62fa640 items=0 ppid=937
pid=1412 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270677254.682:44969): avc: denied { write } for
pid=1412 comm="mlogc" laddr=127.0.0.1 lport=56280 faddr=127.0.0.1 fport=8888
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0
tclass=tcp_socket 
node=troodos.org.uk type=SYSCALL msg=audit(1270677254.682:44969): arch=40000003
syscall=102 success=yes exit=37 a0=9 a1=b62fa560 a2=3ff8550 a3=0 items=0 ppid=937 pid=1412
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270677254.684:44970): avc: denied { create } for
pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0
tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=udp_socket 
node=troodos.org.uk type=SYSCALL msg=audit(1270677254.684:44970): arch=40000003
syscall=102 success=yes exit=7 a0=1 a1=b62fa5c0 a2=4cb9a8 a3=b577c630 items=0 ppid=937
pid=1412 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270677254.685:44971): avc: denied { create } for
pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0
tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=netlink_route_socket 
node=troodos.org.uk type=SYSCALL msg=audit(1270677254.685:44971): arch=40000003
syscall=102 success=yes exit=7 a0=1 a1=b62fa400 a2=d1eff4 a3=b62fa5e8 items=0 ppid=937
pid=1412 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270677254.685:44972): avc: denied { bind } for
pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0
tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=netlink_route_socket 
node=troodos.org.uk type=SYSCALL msg=audit(1270677254.685:44972): arch=40000003
syscall=102 success=yes exit=0 a0=2 a1=b62fa400 a2=d1eff4 a3=7 items=0 ppid=937 pid=1412
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270677254.686:44973): avc: denied { getattr } for
pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0
tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=netlink_route_socket 
node=troodos.org.uk type=SYSCALL msg=audit(1270677254.686:44973): arch=40000003
syscall=102 success=yes exit=0 a0=6 a1=b62fa400 a2=d1eff4 a3=7 items=0 ppid=937 pid=1412
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270677254.686:44974): avc: denied { write } for
pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0
tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=netlink_route_socket 
node=troodos.org.uk type=AVC msg=audit(1270677254.686:44974): avc: denied { nlmsg_read }
for pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0
tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=netlink_route_socket 
node=troodos.org.uk type=SYSCALL msg=audit(1270677254.686:44974): arch=40000003
syscall=102 success=yes exit=20 a0=b a1=b62f9330 a2=d1eff4 a3=0 items=0 ppid=937 pid=1412
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null)

[Dominick Grift]

On Wed, Apr 07, 2010 at 11:01:53PM +0100, Arthur Dent wrote:
>  On Wed, 2010-04-07 at 23:35 +0200, Dominick Grift wrote:
>  
>  > 
>  > Yes looks fine. try the following myapache.te instead:
>  > 
>  > policy_module(myapache, 1.0.0)
>  > gen_require(`
>  > type httpd_t;
>  > ')
>  > mlogc_domtrans(httpd_t)
>  > 
>  > build, install
>  > 
>  > make -f /usr/share/selinux/devel/Makefile
>  > sudo semodule -i *.pp
>  
>  OK - Caused a mere 16 AVCs (admittedly in permissive mode): 
Alright we are on the right track now. the mlogc process runs in its own mlogc domain.
Now to add some more policy to mlogc.te

see comments below:

>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { write } for
> pid=952 comm="mlogc" name="mlogc" dev=sda5 ino=578025
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:httpd_log_t:s0
> tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { add_name }
> for pid=952 comm="mlogc" name="mlogc-queue.log.new"
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:httpd_log_t:s0
> tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { create } for
> pid=952 comm="mlogc" name="mlogc-queue.log.new"
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:object_r:httpd_log_t:s0
> tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270677188.477:44957): arch=40000003 syscall=5
> success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { write } for
> pid=952 comm="mlogc" name="mlogc" dev=sda5 ino=578025
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:httpd_log_t:s0
> tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { add_name }
> for pid=952 comm="mlogc" name="mlogc-queue.log.new"
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:httpd_log_t:s0
> tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { create } for
> pid=952 comm="mlogc" name="mlogc-queue.log.new"
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:object_r:httpd_log_t:s0
> tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270677188.477:44957): arch=40000003 syscall=5
> success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { write } for
> pid=952 comm="mlogc" name="mlogc" dev=sda5 ino=578025
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:httpd_log_t:s0
> tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { add_name }
> for pid=952 comm="mlogc" name="mlogc-queue.log.new"
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:httpd_log_t:s0
> tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { create } for
> pid=952 comm="mlogc" name="mlogc-queue.log.new"
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:object_r:httpd_log_t:s0
> tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270677188.477:44957): arch=40000003 syscall=5
> success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270677188.484:44958): avc: denied { remove_name }
> for pid=952 comm="mlogc" name="mlogc-queue.log" dev=sda5 ino=578431
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:httpd_log_t:s0
> tclass=dir 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270677188.484:44958): arch=40000003
> syscall=38 success=yes exit=0 a0=84c01e8 a1=b76fd070 a2=7581e4 a3=0 items=0 ppid=937
> pid=952 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null)
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270677188.494:44959): avc: denied { rename } for
> pid=952 comm="mlogc" name="mlogc-queue.log.new" dev=sda5 ino=578432
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:object_r:httpd_log_t:s0
> tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270677188.494:44959): arch=40000003
> syscall=38 success=yes exit=0 a0=b76fd170 a1=84c01e8 a2=7581e4 a3=0 items=0 ppid=937
> pid=952 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null)  
The above access vectors should all be allowed if you add the following to your mlogc.te
file:

apache_manage_log(mlogc_t)

>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270677188.497:44960): avc: denied { write } for
> pid=952 comm="mlogc" name="mlogc-transaction.log" dev=sda5 ino=578031
> scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270677188.497:44960): arch=40000003
> syscall=194 success=yes exit=0 a0=5 a1=0 a2=0 a3=84c05c0 items=0 ppid=937 pid=952
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
The file mlogc-transaction.log at inode 57803 seems mislabeled. use restorecon on the file
to fix its context.
 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270677208.496:44961): avc: denied { unlink } for
> pid=952 comm="mlogc" name="mlogc-queue.log.old" dev=sda5 ino=578432
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:object_r:httpd_log_t:s0
> tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270677208.496:44961): arch=40000003
> syscall=10 success=yes exit=0 a0=b76fd070 a1=84c01e8 a2=7581e4 a3=0 items=0 ppid=937
> pid=952 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>   
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270677254.661:44966): avc: denied { create } for
> pid=944 comm="httpd" name="20100407-2254"
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_log_t:s0
> tclass=dir 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270677254.661:44966): arch=40000003
> syscall=39 success=yes exit=0 a0=24e17a8 a1=1e8 a2=80a1e4 a3=24e1748 items=0 ppid=937
> pid=944 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48
> tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270677254.673:44967): avc: denied { write } for
> pid=944 comm="httpd" name="20100407-225414-S7z-BlIrkOUAAAOwOYMAAAAB"
> dev=sda5 ino=658630 scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:httpd_log_t:s0 tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270677254.673:44967): arch=40000003 syscall=5
> success=yes exit=19 a0=24e1748 a1=8241 a2=1a0 a3=836 items=0 ppid=937 pid=944
> auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
> ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>   
The access vectors above were allowed when we added apache_manage_log(mlogc_t) to our
mlogc.te file.

>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270677254.679:44968): avc: denied { setopt } for
> pid=1412 comm="mlogc" laddr=127.0.0.1 lport=56280 faddr=127.0.0.1 fport=8888
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0
> tclass=tcp_socket 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270677254.679:44968): arch=40000003
> syscall=102 success=yes exit=0 a0=e a1=b62fa5d0 a2=3ff8550 a3=b62fa640 items=0 ppid=937
> pid=1412 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270677254.682:44969): avc: denied { write } for
> pid=1412 comm="mlogc" laddr=127.0.0.1 lport=56280 faddr=127.0.0.1 fport=8888
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0
> tclass=tcp_socket 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270677254.682:44969): arch=40000003
> syscall=102 success=yes exit=37 a0=9 a1=b62fa560 a2=3ff8550 a3=0 items=0 ppid=937 pid=1412
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
The above can be allowed by adding the following to you mlogc.te file:

allow mlogc_t self:tcp_socket create_socket_perms;
 
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270677254.684:44970): avc: denied { create } for
> pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=udp_socket 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270677254.684:44970): arch=40000003
> syscall=102 success=yes exit=7 a0=1 a1=b62fa5c0 a2=4cb9a8 a3=b577c630 items=0 ppid=937
> pid=1412 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>   

The above can be allowed by adding the following to your mlogc.te file:

allow mlogc_t self:udp_socket create_socket_perms;

>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(127067725d4.685:44971): avc: denied { create } for
> pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=netlink_route_socket 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270677254.685:44971): arch=40000003
> syscall=102 success=yes exit=7 a0=1 a1=b62fa400 a2=d1eff4 a3=b62fa5e8 items=0 ppid=937
> pid=1412 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270677254.685:44972): avc: denied { bind } for
> pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=netlink_route_socket 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270677254.685:44972): arch=40000003
> syscall=102 success=yes exit=0 a0=2 a1=b62fa400 a2=d1eff4 a3=7 items=0 ppid=937 pid=1412
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270677254.686:44973): avc: denied { getattr } for
> pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=netlink_route_socket 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270677254.686:44973): arch=40000003
> syscall=102 success=yes exit=0 a0=6 a1=b62fa400 a2=d1eff4 a3=7 items=0 ppid=937 pid=1412
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270677254.686:44974): avc: denied { write } for
> pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=netlink_route_socket 
>  node=troodos.org.uk type=AVC msg=audit(1270677254.686:44974): avc: denied { nlmsg_read }
> for pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=netlink_route_socket 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270677254.686:44974): arch=40000003
> syscall=102 success=yes exit=20 a0=b a1=b62f9330 a2=d1eff4 a3=0 items=0 ppid=937 pid=1412
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>   
The above can be allowed by adding the following to your mlogc.te file:

allow mlogc_t self:netlink_route_socket create_netlink_socket_perms;


I did this quickly off the top of my head, so might be some syntax errors.

It is getting late and i am tired. I will respond to any emails tomorrow morning.

we are on the right track.

>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Arthur Dent]

On Thu, 2010-04-08 at 00:20 +0200, Dominick Grift wrote:

>  Alright we are on the right track now. the mlogc process runs in its
> own mlogc domain.
>  Now to add some more policy to mlogc.te
>  
>  see comments below: 
[snip]

>  I did this quickly off the top of my head, so might be some syntax
> errors.
>  
>  It is getting late and i am tired. I will respond to any emails tomorrow morning. 
It's 11:30pm here... I really appreciate your help - Thanks!

>  we are on the right track. 
Yes.

A half-dozen AVCs sinc that last update to policy:

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270679719.656:45083): avc: denied { create } for
pid=949 comm="httpd" name="20100407-2335"
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_log_t:s0
tclass=dir 
node=troodos.org.uk type=SYSCALL msg=audit(1270679719.656:45083): arch=40000003 syscall=39
success=yes exit=0 a0=24e17a8 a1=1e8 a2=80a1e4 a3=24e1748 items=0 ppid=937 pid=949
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270679719.705:45084): avc: denied { write } for
pid=949 comm="httpd" name="20100407-233519-S70IpVIrkOUAAAO1OuQAAAAF"
dev=sda5 ino=658634 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:httpd_log_t:s0 tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270679719.705:45084): arch=40000003 syscall=5
success=yes exit=19 a0=24e1748 a1=8241 a2=1a0 a3=836 items=0 ppid=937 pid=949
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270679720.128:45085): avc: denied { name_connect }
for pid=1869 comm="mlogc" dest=8888 scontext=unconfined_u:system_r:mlogc_t:s0
tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket 
node=troodos.org.uk type=SYSCALL msg=audit(1270679720.128:45085): arch=40000003
syscall=102 success=no exit=-115 a0=3 a1=b62fa910 a2=4cb9a8 a3=0 items=0 ppid=937 pid=1869
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270679720.298:45086): avc: denied { getattr } for
pid=1869 comm="mlogc" path="/var/run/pcscd.pub" dev=sda5 ino=362221
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270679720.298:45086): arch=40000003
syscall=195 success=yes exit=0 a0=1c85ab a1=b62f89ac a2=d1eff4 a3=3 items=0 ppid=937
pid=1869 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270679720.301:45087): avc: denied { read } for
pid=1869 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
tclass=file 
node=troodos.org.uk type=AVC msg=audit(1270679720.301:45087): avc: denied { open } for
pid=1869 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270679720.301:45087): arch=40000003 syscall=5
success=yes exit=13 a0=1c88ea a1=0 a2=1b6 a3=1c88e8 items=0 ppid=937 pid=1869
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270679720.301:45087): avc: denied { read } for
pid=1869 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
tclass=file 
node=troodos.org.uk type=AVC msg=audit(1270679720.301:45087): avc: denied { open } for
pid=1869 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270679720.301:45087): arch=40000003 syscall=5
success=yes exit=13 a0=1c88ea a1=0 a2=1b6 a3=1c88e8 items=0 ppid=937 pid=1869
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 


And as I was copying the above, this one came in...

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270680011.472:45102): avc: denied { dac_override }
for pid=952 comm="mlogc" capability=1 scontext=unconfined_u:system_r:mlogc_t:s0
tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=capability 
node=troodos.org.uk type=SYSCALL msg=audit(1270680011.472:45102): arch=40000003 syscall=5
success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null)

[Dominick Grift]

On Wed, Apr 07, 2010 at 11:42:47PM +0100, Arthur Dent wrote:
>  On Thu, 2010-04-08 at 00:20 +0200, Dominick Grift wrote:
>  
>  > Alright we are on the right track now. the mlogc process runs in its own mlogc
> domain.
>  > Now to add some more policy to mlogc.te
>  > 
>  > see comments below:
>  
>  [snip]
>  
>  > I did this quickly off the top of my head, so might be some syntax errors.
>  > 
>  > It is getting late and i am tired. I will respond to any emails tomorrow morning.
>  
>  It's 11:30pm here... I really appreciate your help - Thanks!
>  
>  > we are on the right track.
>  
>  Yes. 
Comments below:

>  
>  A half-dozen AVCs sinc that last update to policy:
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270679719.656:45083): avc: denied { create } for
> pid=949 comm="httpd" name="20100407-2335"
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_log_t:s0
> tclass=dir 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270679719.656:45083): arch=40000003
> syscall=39 success=yes exit=0 a0=24e17a8 a1=1e8 a2=80a1e4 a3=24e1748 items=0 ppid=937
> pid=949 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48
> tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270679719.705:45084): avc: denied { write } for
> pid=949 comm="httpd" name="20100407-233519-S70IpVIrkOUAAAO1OuQAAAAF"
> dev=sda5 ino=658634 scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:httpd_log_t:s0 tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270679719.705:45084): arch=40000003 syscall=5
> success=yes exit=19 a0=24e1748 a1=8241 a2=1a0 a3=836 items=0 ppid=937 pid=949
> auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
> ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>   
I gather that these access vectors denials are caused by the actual mod_security module.
Since the source in the interaction is the httpd programs.

This brings us to a security issue need to consider and deal with.

As you can see: httpd_t is not allowed to create directories with type httpd_log_t and is
not allowed to write to files with type httpd_log_t. This is because normally it does not
need this permissions.

Httpd_t writing to its log file is a bad idea. Consider for example a cracker compromizing
the web server trying to erase his audit trail by removing entries from the httpd log
files.

So how can we deal with this? Well there are something we should investigate.

Can we configure mod_security to use a custom location for its log files?
Maybe we do not have to:

Can you tell me which directories in /var/log/httpd are owned by mod_security?

I am think about creating a file type transition from the generic log files type or httpd
log files type to a mlogc log files type to be created by us.
This will benefit security as:

1. Hopefully mlogc_t will no longer need to manage files with type httpd_log_t.
2. httpd_t (mod_security) will no longer need to create directories wuth type httpd_log_t
and will no longer need to write to files with type httpd_log_t.

We must try to find the best solution to the above securities issue so again: two
questions:

1. does mod_security (mayve its configuration file) allow us to specify a location to
store mod_security log files?
2. if the answer to 1. is no, then can you tell me which directories in /var/log/httpd are
used (owned) by mod_security for logging?


>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270679720.128:45085): avc: denied { name_connect
> } for pid=1869 comm="mlogc" dest=8888 scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270679720.128:45085): arch=40000003
> syscall=102 success=no exit=-115 a0=3 a1=b62fa910 a2=4cb9a8 a3=0 items=0 ppid=937 pid=1869
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null)  
The mlogc program tries to tcp network connect to port 8888, which currently is labeled
with a generic port type.

1. Why is it connecting to the network?
2. What is listening on tcp:8888 on the other side?

We have to find some answers before we can start implementing a proper solution.

>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270679720.298:45086): avc: denied { getattr } for
> pid=1869 comm="mlogc" path="/var/run/pcscd.pub" dev=sda5 ino=362221
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
> tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270679720.298:45086): arch=40000003
> syscall=195 success=yes exit=0 a0=1c85ab a1=b62f89ac a2=d1eff4 a3=3 items=0 ppid=937
> pid=1869 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>   
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270679720.301:45087): avc: denied { read } for
> pid=1869 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
> tclass=file 
>  node=troodos.org.uk type=AVC msg=audit(1270679720.301:45087): avc: denied { open } for
> pid=1869 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
> tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270679720.301:45087): arch=40000003 syscall=5
> success=yes exit=13 a0=1c88ea a1=0 a2=1b6 a3=1c88e8 items=0 ppid=937 pid=1869
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270679720.301:45087): avc: denied { read } for
> pid=1869 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
> tclass=file 
>  node=troodos.org.uk type=AVC msg=audit(1270679720.301:45087): avc: denied { open } for
> pid=1869 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0
> tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270679720.301:45087): arch=40000003 syscall=5
> success=yes exit=13 a0=1c88ea a1=0 a2=1b6 a3=1c88e8 items=0 ppid=937 pid=1869
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null)  
The above denials were what actually caused your issue in the first place. The only
difference now is that instead of httpd_t, now mlogc_t need the access.

Add the following to your mlogc.te file:

pcscd_read_pub_files(mlogc_t)

That should allow mlogc_t to read pcscd pid files.

>  
>  
>  And as I was copying the above, this one came in...
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270680011.472:45102): avc: denied { dac_override
> } for pid=952 comm="mlogc" capability=1
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0
> tclass=capability 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270680011.472:45102): arch=40000003 syscall=5
> success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>   
The above means that root/mlogc is overriding traditional security. For example accessing
a location not owned by root. We should figure out which location it is that mlogc tries
to access that is not owned by root. Once we determine this, we can make the right
security decision.


Now we are getting into the harder aspect of writing policy. 
Writing a template for a new domain and just allowing access is not so hard. 
What is harder is: making solid security decisions. 


What is it doing
why is it doing it
who is doing it to who
Is this a threat
why is it a threat
how can we neutralize it?

fun!

>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Arthur Dent]

On Thu, 2010-04-08 at 08:42 +0200, Dominick Grift wrote:

[snip]
>  
>  I gather that these access vectors denials are caused by the actual mod_security module.
> Since the source in the interaction is the httpd programs.
>  
>  This brings us to a security issue need to consider and deal with.
>  
>  As you can see: httpd_t is not allowed to create directories with type httpd_log_t and is
> not allowed to write to files with type httpd_log_t. This is because normally it does not
> need this permissions.
>  
>  Httpd_t writing to its log file is a bad idea. Consider for example a cracker
> compromizing the web server trying to erase his audit trail by removing entries from the
> httpd log files.
>  
>  So how can we deal with this? Well there are something we should investigate.
>  
>  Can we configure mod_security to use a custom location for its log files?
>  Maybe we do not have to:
>  
>  Can you tell me which directories in /var/log/httpd are owned by mod_security? 
OK - Here is the story:

I have been using mod-security for some time now with none of theses
shenanigans...

Normally mod-security writes its logs to /var/log/httpd/ (the same place
as the apache logs) and there are only 2 files:
/var/log/httpd/modsec_audit.log
/var/log/httpd/modsec_debug.log

The audit log being the main workhorse where each individual mod-sec
action was recorded.
 
All of that was fine. mlogc was not involved.

Recently, I decided to start using the Mod-Security Community Console, a
(java-based I think) web app for viewing, and giving more user-friendly
detail of, all the alerts produced by mod-sec.

This requires a different approach to logging and this is where mlogc
comes in.

Mod-security has two logging modes, serial and concurrent. "Serial"
places all alerts in the above mod-sec.audit.log. "Concurrent" logging,
on the other hand, places log files in separate directories
corresponding to the time that the log was generated. This is what is
required by the Console app.

This is configured from
the /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf file with
the following directives:

For Concurrent logging:-
SecAuditLogType Concurrent #(sets logging type)
SecDataDir /var/log/httpd/modsec_data # Sets log location
SecAuditLogStorageDir /var/log/httpd/mlogc/data # Location for for detailed logs
SecAuditLog "|/usr/bin/mlogc /etc/mlogc.conf" # Pipes the alerts to mlogc

For Serial Logging:-
#SecAuditLogType Serial
#SecAuditLog logs/modsec_audit.log

Mlogc has its own configuration:
/etc/mlogc.conf

I reproduce it in full here:


# cat /etc/mlogc.conf
##########################################################################
# Required configuration
#   At a minimum, the items in this section will need to be adjusted to
#   fit your environment.  The remaining options are optional.
##########################################################################

# Points to the root of the installation. All relative
# paths will be resolved with the help of this path.
CollectorRoot       "/var/log/httpd/mlogc"

# ModSecurity Console receiving URI. You can change the host
# and the port parts but leave everything else as is.
ConsoleURI          "https://127.0.0.1:8888/rpc/auditLogReceiver"

# Sensor credentials
SensorUsername      "MCS"
SensorPassword      "mypassword"

# Base directory where the audit logs are stored.  This can be specified
# as a path relative to the CollectorRoot, or a full path.
LogStorageDir       "data"

# Transaction log will contain the information on all log collector
# activities that happen between checkpoints. The transaction log
# is used to recover data in case of a crash (or if Apache kills
# the process).
TransactionLog      "mlogc-transaction.log"

# The file where the pending audit log entry data is kept. This file
# is updated on every checkpoint.
QueuePath           "mlogc-queue.log"

# The location of the error log.
ErrorLog            "mlogc-error.log"

# The location of the lock file.
LockFile            "mlogc.lck"

# Keep audit log entries after sending? (0=false 1=true)
# NOTE: This is required to be set in SecAuditLog mlogc config if you
# are going to use a secondary console via SecAuditLog2.
KeepEntries         0


##########################################################################
# Optional configuration
##########################################################################

# The error log level controls how much detail there
# will be in the error log. The levels are as follows:
#   0 - NONE
#   1 - ERROR
#   2 - WARNING
#   3 - NOTICE
#   4 - DEBUG
#   5 - DEBUG2
#
ErrorLogLevel       3

# How many concurrent connections to the server
# are we allowed to open at the same time? Log collector uses
# multiple connections in order to speed up audit log transfer.
# This is especially needed when the communication takes place
# over a slow link (e.g. not over a LAN).
MaxConnections      10

# How many requests a worker will process before recycling itself.
# This is to help prevent problems due to any memory leaks that may
# exists.  If this is set to 0, then no maximum is imposed. The default
# is 1000 requests per worker (the number of workers is controlled by
the
# MaxConnections limit).
MaxWorkerRequests   1000

# The time each connection will sit idle before being reused,
# in milliseconds. Increase if you don't want ModSecurity Console
# to be hit with too many log collector requests.
TransactionDelay    50

# The time to wait before initialization on startup in milliseconds.
# Increase if mlogc is starting faster then termination when the
# sensor is reloaded.
StartupDelay        5000

# How often is the pending audit log entry data going to be written
# to a file. The default is 15 seconds.
CheckpointInterval  15

# If the server fails all threads will back down until the
# problem is sorted. The management thread will periodically
# launch a thread to test the server. The default is to test
# once in 60 seconds.
ServerErrorTimeout  60

# The following two parameters are not used yet, but
# reserved for future expansion.
# KeepAlive         150
# KeepAliveTimeout  300

#################################################################################

I think most of that is self-explanatory. Note especially the ConsoleURI
"https://127.0.0.1:8888/rpc/auditLogReceiver" directive. This punts the
alerts into the Console which listens on port 8888, and this is the
answer to one of your later questions.

Note however that I am also experimenting with another Console app (also
Java based, which does exactly the same thing in the same way) but in
this case listens on port 8443.

>  
>  I am think about creating a file type transition from the generic log files type or httpd
> log files type to a mlogc log files type to be created by us.
>  This will benefit security as:
>  
>  1. Hopefully mlogc_t will no longer need to manage files with type httpd_log_t.
>  2. httpd_t (mod_security) will no longer need to create directories wuth type httpd_log_t
> and will no longer need to write to files with type httpd_log_t.
>  
>  We must try to find the best solution to the above securities issue so again: two
> questions:
>  
>  1. does mod_security (mayve its configuration file) allow us to specify a location to
> store mod_security log files?
>  2. if the answer to 1. is no, then can you tell me which directories in /var/log/httpd
> are used (owned) by mod_security for logging? 
The answer to 1 is yes as you can see above.
>  
>  > Raw Audit Messages :
>  > 
>  > node=troodos.org.uk type=AVC msg=audit(1270679720.128:45085): avc: denied {
> name_connect } for pid=1869 comm="mlogc" dest=8888
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:port_t:s0
> tclass=tcp_socket 
>  > node=troodos.org.uk type=SYSCALL msg=audit(1270679720.128:45085): arch=40000003
> syscall=102 success=no exit=-115 a0=3 a1=b62fa910 a2=4cb9a8 a3=0 items=0 ppid=937 pid=1869
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  The mlogc program tries to tcp network connect to port 8888, which currently is labeled
> with a generic port type.
>  
>  1. Why is it connecting to the network?
>  2. What is listening on tcp:8888 on the other side? 
That's the Console app as described above.

>  
>  We have to find some answers before we can start implementing a proper solution. 
[snip]

>  The above denials were what actually caused your issue in the first
> place. The only difference now is that instead of httpd_t, now mlogc_t need the access.
>  
>  Add the following to your mlogc.te file:
>  
>  pcscd_read_pub_files(mlogc_t)
>  
>  That should allow mlogc_t to read pcscd pid files. 
Done that - thanks..

>  
>  > 
>  > 
>  > And as I was copying the above, this one came in...
>  > 
>  > Raw Audit Messages :
>  > 
>  > node=troodos.org.uk type=AVC msg=audit(1270680011.472:45102): avc: denied {
> dac_override } for pid=952 comm="mlogc" capability=1
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0
> tclass=capability 
>  > node=troodos.org.uk type=SYSCALL msg=audit(1270680011.472:45102): arch=40000003
> syscall=5 success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  > 
>  > 
>  
>  The above means that root/mlogc is overriding traditional security. For example accessing
> a location not owned by root. We should figure out which location it is that mlogc tries
> to access that is not owned by root. Once we determine this, we can make the right
> security decision.
>  
>  
>  Now we are getting into the harder aspect of writing policy. 
>  Writing a template for a new domain and just allowing access is not so hard. 
>  What is harder is: making solid security decisions. 
>  
>  
>  What is it doing
>  why is it doing it
>  who is doing it to who
>  Is this a threat
>  why is it a threat
>  how can we neutralize it?
>  
>  fun! 
For you maybe ;)

OK - I hope the above helps...

By the way since my last message I have had another 71 AVcs - too many
to post, and doubtless many duplicates, but here is what audit2allow has
to say about them:

# ausearch -m AVC -ts today | audit2allow -R

require {
	type mlogc_t;
	type httpd_t;
	class capability { sys_nice dac_override };
	class process { setsched signal getsched };
	class sem { read write create unix_write destroy };
}

#============= httpd_t ==============
allow httpd_t mlogc_t:process signal;

#============= mlogc_t ==============
allow mlogc_t self:capability { sys_nice dac_override };
allow mlogc_t self:process { setsched getsched };
allow mlogc_t self:sem { read write create unix_write destroy };
files_rw_etc_files(mlogc_t)
miscfiles_rw_localization(mlogc_t)



Thanks again for all your help!

Cheers

Mark

[Dominick Grift]

On Thu, Apr 08, 2010 at 09:40:41AM +0100, Arthur Dent wrote:
>  On Thu, 2010-04-08 at 08:42 +0200, Dominick Grift wrote:
>  
>  [snip]
>  > 
>  > I gather that these access vectors denials are caused by the actual mod_security
> module. Since the source in the interaction is the httpd programs.
>  > 
>  > This brings us to a security issue need to consider and deal with.
>  > 
>  > As you can see: httpd_t is not allowed to create directories with type httpd_log_t
> and is not allowed to write to files with type httpd_log_t. This is because normally it
> does not need this permissions.
>  > 
>  > Httpd_t writing to its log file is a bad idea. Consider for example a cracker
> compromizing the web server trying to erase his audit trail by removing entries from the
> httpd log files.
>  > 
>  > So how can we deal with this? Well there are something we should investigate.
>  > 
>  > Can we configure mod_security to use a custom location for its log files?
>  > Maybe we do not have to:
>  > 
>  > Can you tell me which directories in /var/log/httpd are owned by mod_security?
>  
>  OK - Here is the story:
>  
>  I have been using mod-security for some time now with none of theses
>  shenanigans...
>  
>  Normally mod-security writes its logs to /var/log/httpd/ (the same place
>  as the apache logs) and there are only 2 files:
>  /var/log/httpd/modsec_audit.log
>  /var/log/httpd/modsec_debug.log
>  
>  The audit log being the main workhorse where each individual mod-sec
>  action was recorded.
>   
>  All of that was fine. mlogc was not involved.
>  
>  Recently, I decided to start using the Mod-Security Community Console, a
>  (java-based I think) web app for viewing, and giving more user-friendly
>  detail of, all the alerts produced by mod-sec.
>  
>  This requires a different approach to logging and this is where mlogc
>  comes in.
>  
>  Mod-security has two logging modes, serial and concurrent. "Serial"
>  places all alerts in the above mod-sec.audit.log. "Concurrent" logging,
>  on the other hand, places log files in separate directories
>  corresponding to the time that the log was generated. This is what is
>  required by the Console app.
>  
>  This is configured from
>  the /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf file with
>  the following directives:
>  
>  For Concurrent logging:-
>  SecAuditLogType Concurrent #(sets logging type)
>  SecDataDir /var/log/httpd/modsec_data # Sets log location
>  SecAuditLogStorageDir /var/log/httpd/mlogc/data # Location for for detailed logs
>  SecAuditLog "|/usr/bin/mlogc /etc/mlogc.conf" # Pipes the alerts to mlogc
>  
>  For Serial Logging:-
>  #SecAuditLogType Serial
>  #SecAuditLog logs/modsec_audit.log
>  
>  Mlogc has its own configuration:
>  /etc/mlogc.conf
>  
>  I reproduce it in full here:
>  
>  
>  # cat /etc/mlogc.conf
>  ##########################################################################
>  # Required configuration
>  #   At a minimum, the items in this section will need to be adjusted to
>  #   fit your environment.  The remaining options are optional.
>  ##########################################################################
>  
>  # Points to the root of the installation. All relative
>  # paths will be resolved with the help of this path.
>  CollectorRoot       "/var/log/httpd/mlogc"
>  
>  # ModSecurity Console receiving URI. You can change the host
>  # and the port parts but leave everything else as is.
>  ConsoleURI          "https://127.0.0.1:8888/rpc/auditLogReceiver"
>  
>  # Sensor credentials
>  SensorUsername      "MCS"
>  SensorPassword      "mypassword"
>  
>  # Base directory where the audit logs are stored.  This can be specified
>  # as a path relative to the CollectorRoot, or a full path.
>  LogStorageDir       "data"
>  
>  # Transaction log will contain the information on all log collector
>  # activities that happen between checkpoints. The transaction log
>  # is used to recover data in case of a crash (or if Apache kills
>  # the process).
>  TransactionLog      "mlogc-transaction.log"
>  
>  # The file where the pending audit log entry data is kept. This file
>  # is updated on every checkpoint.
>  QueuePath           "mlogc-queue.log"
>  
>  # The location of the error log.
>  ErrorLog            "mlogc-error.log"
>  
>  # The location of the lock file.
>  LockFile            "mlogc.lck"
>  
>  # Keep audit log entries after sending? (0=false 1=true)
>  # NOTE: This is required to be set in SecAuditLog mlogc config if you
>  # are going to use a secondary console via SecAuditLog2.
>  KeepEntries         0
>  
>  
>  ##########################################################################
>  # Optional configuration
>  ##########################################################################
>  
>  # The error log level controls how much detail there
>  # will be in the error log. The levels are as follows:
>  #   0 - NONE
>  #   1 - ERROR
>  #   2 - WARNING
>  #   3 - NOTICE
>  #   4 - DEBUG
>  #   5 - DEBUG2
>  #
>  ErrorLogLevel       3
>  
>  # How many concurrent connections to the server
>  # are we allowed to open at the same time? Log collector uses
>  # multiple connections in order to speed up audit log transfer.
>  # This is especially needed when the communication takes place
>  # over a slow link (e.g. not over a LAN).
>  MaxConnections      10
>  
>  # How many requests a worker will process before recycling itself.
>  # This is to help prevent problems due to any memory leaks that may
>  # exists.  If this is set to 0, then no maximum is imposed. The default
>  # is 1000 requests per worker (the number of workers is controlled by
>  the
>  # MaxConnections limit).
>  MaxWorkerRequests   1000
>  
>  # The time each connection will sit idle before being reused,
>  # in milliseconds. Increase if you don't want ModSecurity Console
>  # to be hit with too many log collector requests.
>  TransactionDelay    50
>  
>  # The time to wait before initialization on startup in milliseconds.
>  # Increase if mlogc is starting faster then termination when the
>  # sensor is reloaded.
>  StartupDelay        5000
>  
>  # How often is the pending audit log entry data going to be written
>  # to a file. The default is 15 seconds.
>  CheckpointInterval  15
>  
>  # If the server fails all threads will back down until the
>  # problem is sorted. The management thread will periodically
>  # launch a thread to test the server. The default is to test
>  # once in 60 seconds.
>  ServerErrorTimeout  60
>  
>  # The following two parameters are not used yet, but
>  # reserved for future expansion.
>  # KeepAlive         150
>  # KeepAliveTimeout  300
>  
>  ################################################################################# 

Alright. I wonder why they put that location in httpd's log location. From a SELinux
perspective it would makes things a bit simpler if they just set:

SecAuditLogStorageDir /var/log/mlogc/data
CollectorRoot       "/var/log/mlogc"
LogStorageDir       "data"

Then we can easily create a new log file type for mlogc log content in /var/log and set up
a file type transition:

mlogc.te:

# declare a type and make the type usable for mlogc log content
type mlogc_var_log_t;
logging_log_file(mlogc_var_log_t;

# allow mlogc to manage and create content in /var/log with type mlogc_var_log_t:
manage_dirs_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
manage_files_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
logging_log_filetrans(mlogc_t, mlogc_var_log_t, { dir file })

Next we add a file context specification for this in mlogc.fc:

/var/log/mlogc(/.*)? gen_context(system_u:object_r:mlogc_var_log_t, s0)

We should for now comment out or remove the "apache_manage_log(mlogc_t)" in
mlogc.te that we added earlier for the time being.

>  
>  I think most of that is self-explanatory. Note especially the ConsoleURI
>  "https://127.0.0.1:8888/rpc/auditLogReceiver" directive. This punts the
>  alerts into the Console which listens on port 8888, and this is the
>  answer to one of your later questions. 
I think we should also confine this "server". Which package includes this? what
is the name/location of the executable file for this service?

>  
>  Note however that I am also experimenting with another Console app (also
>  Java based, which does exactly the same thing in the same way) but in
>  this case listens on port 8443.
>  
>  > 
>  > I am think about creating a file type transition from the generic log files type or
> httpd log files type to a mlogc log files type to be created by us.
>  > This will benefit security as:
>  > 
>  > 1. Hopefully mlogc_t will no longer need to manage files with type httpd_log_t.
>  > 2. httpd_t (mod_security) will no longer need to create directories wuth type
> httpd_log_t and will no longer need to write to files with type httpd_log_t.
>  > 
>  > We must try to find the best solution to the above securities issue so again: two
> questions:
>  > 
>  > 1. does mod_security (mayve its configuration file) allow us to specify a location
> to store mod_security log files?
>  > 2. if the answer to 1. is no, then can you tell me which directories in
> /var/log/httpd are used (owned) by mod_security for logging?
>  
>  The answer to 1 is yes as you can see above.
>  > 
>  > > Raw Audit Messages :
>  > > 
>  > > node=troodos.org.uk type=AVC msg=audit(1270679720.128:45085): avc: denied {
> name_connect } for pid=1869 comm="mlogc" dest=8888
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:port_t:s0
> tclass=tcp_socket 
>  > > node=troodos.org.uk type=SYSCALL msg=audit(1270679720.128:45085): arch=40000003
> syscall=102 success=no exit=-115 a0=3 a1=b62fa910 a2=4cb9a8 a3=0 items=0 ppid=937 pid=1869
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  > 
>  > The mlogc program tries to tcp network connect to port 8888, which currently is
> labeled with a generic port type.
>  > 
>  > 1. Why is it connecting to the network?
>  > 2. What is listening on tcp:8888 on the other side?
>  
>  That's the Console app as described above.
>  
>  > 
>  > We have to find some answers before we can start implementing a proper solution.
>  
>  [snip]
>  
>  > The above denials were what actually caused your issue in the first place. The only
> difference now is that instead of httpd_t, now mlogc_t need the access.
>  > 
>  > Add the following to your mlogc.te file:
>  > 
>  > pcscd_read_pub_files(mlogc_t)
>  > 
>  > That should allow mlogc_t to read pcscd pid files.
>  
>  Done that - thanks..
>  
>  > 
>  > > 
>  > > 
>  > > And as I was copying the above, this one came in...
>  > > 
>  > > Raw Audit Messages :
>  > > 
>  > > node=troodos.org.uk type=AVC msg=audit(1270680011.472:45102): avc: denied {
> dac_override } for pid=952 comm="mlogc" capability=1
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0
> tclass=capability 
>  > > node=troodos.org.uk type=SYSCALL msg=audit(1270680011.472:45102): arch=40000003
> syscall=5 success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  > > 
>  > > 
>  > 
>  > The above means that root/mlogc is overriding traditional security. For example
> accessing a location not owned by root. We should figure out which location it is that
> mlogc tries to access that is not owned by root. Once we determine this, we can make the
> right security decision.
>  > 
>  > 
>  > Now we are getting into the harder aspect of writing policy. 
>  > Writing a template for a new domain and just allowing access is not so hard. 
>  > What is harder is: making solid security decisions. 
>  > 
>  > 
>  > What is it doing
>  > why is it doing it
>  > who is doing it to who
>  > Is this a threat
>  > why is it a threat
>  > how can we neutralize it?
>  > 
>  > fun!
>  
>  For you maybe ;)
>  
>  OK - I hope the above helps...
>  
>  By the way since my last message I have had another 71 AVcs - too many
>  to post, and doubtless many duplicates, but here is what audit2allow has
>  to say about them:
>  
>  # ausearch -m AVC -ts today | audit2allow -R
>  
>  require {
>  	type mlogc_t;
>  	type httpd_t;
>  	class capability { sys_nice dac_override };
>  	class process { setsched signal getsched };
>  	class sem { read write create unix_write destroy };
>  }
>  
>  #============= httpd_t ==============
>  allow httpd_t mlogc_t:process signal; 
Ignore this for now, we might add it later.

>  
>  #============= mlogc_t ==============
>  allow mlogc_t self:capability { sys_nice dac_override }; 
Did you figure out which location not owned by root mlogc is trying to access?
For the moment lets ignore these. 

>  allow mlogc_t self:process { setsched getsched }; 
The above can be added to mlogc.te

>  allow mlogc_t self:sem { read write create unix_write destroy };
Ignore for now

>  files_rw_etc_files(mlogc_t) 
I suspect that mlogc_t is writing to its own configuration file but i cannot be sure until
i see the avc denials
related to this:

ausearch -m avc -ts today | grep mlogc_t | grep etc_t | grep write


>  miscfiles_rw_localization(mlogc_t) 
This is a misinterpretation by the audit2allow -R command (bug)

Add the following instead to mlogc.te to allow this access:

miscfiles_read_localization(mlogc_t)



>  
>  
>  
>  Thanks again for all your help!
>  
>  Cheers
>  
>  Mark 


>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Arthur Dent]

On Thu, 2010-04-08 at 11:35 +0200, Dominick Grift wrote:
>  On Thu, Apr 08, 2010 at 09:40:41AM +0100, Arthur Dent wrote:
>  > On Thu, 2010-04-08 at 08:42 +0200, Dominick Grift wrote:
>  > 
>  > [snip]
>  > > 
>  > > I gather that these access vectors denials are caused by the actual
> mod_security module. Since the source in the interaction is the httpd programs.
>  > > 
>  > > This brings us to a security issue need to consider and deal with.
>  > > 
>  > > As you can see: httpd_t is not allowed to create directories with type
> httpd_log_t and is not allowed to write to files with type httpd_log_t. This is because
> normally it does not need this permissions.
>  > > 
>  > > Httpd_t writing to its log file is a bad idea. Consider for example a cracker
> compromizing the web server trying to erase his audit trail by removing entries from the
> httpd log files.
>  > > 
>  > > So how can we deal with this? Well there are something we should investigate.
>  > > 
>  > > Can we configure mod_security to use a custom location for its log files?
>  > > Maybe we do not have to:
>  > > 
>  > > Can you tell me which directories in /var/log/httpd are owned by mod_security?
>  > 
>  > OK - Here is the story:
>  > 
>  > I have been using mod-security for some time now with none of theses
>  > shenanigans...
>  > 
>  > Normally mod-security writes its logs to /var/log/httpd/ (the same place
>  > as the apache logs) and there are only 2 files:
>  > /var/log/httpd/modsec_audit.log
>  > /var/log/httpd/modsec_debug.log
>  > 
>  > The audit log being the main workhorse where each individual mod-sec
>  > action was recorded.
>  >  
>  > All of that was fine. mlogc was not involved.
>  > 
>  > Recently, I decided to start using the Mod-Security Community Console, a
>  > (java-based I think) web app for viewing, and giving more user-friendly
>  > detail of, all the alerts produced by mod-sec.
>  > 
>  > This requires a different approach to logging and this is where mlogc
>  > comes in.
>  > 
>  > Mod-security has two logging modes, serial and concurrent. "Serial"
>  > places all alerts in the above mod-sec.audit.log. "Concurrent" logging,
>  > on the other hand, places log files in separate directories
>  > corresponding to the time that the log was generated. This is what is
>  > required by the Console app.
>  > 
>  > This is configured from
>  > the /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf file with
>  > the following directives:
>  > 
>  > For Concurrent logging:-
>  > SecAuditLogType Concurrent #(sets logging type)
>  > SecDataDir /var/log/httpd/modsec_data # Sets log location
>  > SecAuditLogStorageDir /var/log/httpd/mlogc/data # Location for for detailed logs
>  > SecAuditLog "|/usr/bin/mlogc /etc/mlogc.conf" # Pipes the alerts to mlogc
>  > 
>  > For Serial Logging:-
>  > #SecAuditLogType Serial
>  > #SecAuditLog logs/modsec_audit.log
>  > 
>  > Mlogc has its own configuration:
>  > /etc/mlogc.conf
>  > 
>  > I reproduce it in full here:
>  > 
>  > 
>  > # cat /etc/mlogc.conf
>  > ##########################################################################
>  > # Required configuration
>  > #   At a minimum, the items in this section will need to be adjusted to
>  > #   fit your environment.  The remaining options are optional.
>  > ##########################################################################
>  > 
>  > # Points to the root of the installation. All relative
>  > # paths will be resolved with the help of this path.
>  > CollectorRoot       "/var/log/httpd/mlogc"
>  > 
>  > # ModSecurity Console receiving URI. You can change the host
>  > # and the port parts but leave everything else as is.
>  > ConsoleURI          "https://127.0.0.1:8888/rpc/auditLogReceiver"
>  > 
>  > # Sensor credentials
>  > SensorUsername      "MCS"
>  > SensorPassword      "mypassword"
>  > 
>  > # Base directory where the audit logs are stored.  This can be specified
>  > # as a path relative to the CollectorRoot, or a full path.
>  > LogStorageDir       "data"
>  > 
>  > # Transaction log will contain the information on all log collector
>  > # activities that happen between checkpoints. The transaction log
>  > # is used to recover data in case of a crash (or if Apache kills
>  > # the process).
>  > TransactionLog      "mlogc-transaction.log"
>  > 
>  > # The file where the pending audit log entry data is kept. This file
>  > # is updated on every checkpoint.
>  > QueuePath           "mlogc-queue.log"
>  > 
>  > # The location of the error log.
>  > ErrorLog            "mlogc-error.log"
>  > 
>  > # The location of the lock file.
>  > LockFile            "mlogc.lck"
>  > 
>  > # Keep audit log entries after sending? (0=false 1=true)
>  > # NOTE: This is required to be set in SecAuditLog mlogc config if you
>  > # are going to use a secondary console via SecAuditLog2.
>  > KeepEntries         0
>  > 
>  > 
>  > ##########################################################################
>  > # Optional configuration
>  > ##########################################################################
>  > 
>  > # The error log level controls how much detail there
>  > # will be in the error log. The levels are as follows:
>  > #   0 - NONE
>  > #   1 - ERROR
>  > #   2 - WARNING
>  > #   3 - NOTICE
>  > #   4 - DEBUG
>  > #   5 - DEBUG2
>  > #
>  > ErrorLogLevel       3
>  > 
>  > # How many concurrent connections to the server
>  > # are we allowed to open at the same time? Log collector uses
>  > # multiple connections in order to speed up audit log transfer.
>  > # This is especially needed when the communication takes place
>  > # over a slow link (e.g. not over a LAN).
>  > MaxConnections      10
>  > 
>  > # How many requests a worker will process before recycling itself.
>  > # This is to help prevent problems due to any memory leaks that may
>  > # exists.  If this is set to 0, then no maximum is imposed. The default
>  > # is 1000 requests per worker (the number of workers is controlled by
>  > the
>  > # MaxConnections limit).
>  > MaxWorkerRequests   1000
>  > 
>  > # The time each connection will sit idle before being reused,
>  > # in milliseconds. Increase if you don't want ModSecurity Console
>  > # to be hit with too many log collector requests.
>  > TransactionDelay    50
>  > 
>  > # The time to wait before initialization on startup in milliseconds.
>  > # Increase if mlogc is starting faster then termination when the
>  > # sensor is reloaded.
>  > StartupDelay        5000
>  > 
>  > # How often is the pending audit log entry data going to be written
>  > # to a file. The default is 15 seconds.
>  > CheckpointInterval  15
>  > 
>  > # If the server fails all threads will back down until the
>  > # problem is sorted. The management thread will periodically
>  > # launch a thread to test the server. The default is to test
>  > # once in 60 seconds.
>  > ServerErrorTimeout  60
>  > 
>  > # The following two parameters are not used yet, but
>  > # reserved for future expansion.
>  > # KeepAlive         150
>  > # KeepAliveTimeout  300
>  > 
>  > #################################################################################
>  
>  
>  Alright. I wonder why they put that location in httpd's log location. From a SELinux
>  perspective it would makes things a bit simpler if they just set:
>  
>  SecAuditLogStorageDir /var/log/mlogc/data
>  CollectorRoot       "/var/log/mlogc"
>  LogStorageDir       "data" 
Ermmm... Sorry - That was my fault. It WAS in var/log/mlog/ I thought
(that since it was all to do with httpd) it would be better (and cause
fewr SEL AVCs) if I moved it to /var/log/http/mlogc (cringe... sorry...
don't hit me...!).

OK - I'll move it back...


>  
>  Then we can easily create a new log file type for mlogc log content in /var/log and set
> up a file type transition:
>  
>  mlogc.te:
>  
>  # declare a type and make the type usable for mlogc log content
>  type mlogc_var_log_t;
>  logging_log_file(mlogc_var_log_t;
>  
>  # allow mlogc to manage and create content in /var/log with type mlogc_var_log_t:
>  manage_dirs_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
>  manage_files_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
>  logging_log_filetrans(mlogc_t, mlogc_var_log_t, { dir file })
>  
>  Next we add a file context specification for this in mlogc.fc:
>  
>  /var/log/mlogc(/.*)? gen_context(system_u:object_r:mlogc_var_log_t, s0)
>  
>  We should for now comment out or remove the "apache_manage_log(mlogc_t)" in
> mlogc.te that we added earlier for the time being. 
Done all that...

>  > I think most of that is self-explanatory. Note especially the
> ConsoleURI
>  > "https://127.0.0.1:8888/rpc/auditLogReceiver" directive. This punts the
>  > alerts into the Console which listens on port 8888, and this is the
>  > answer to one of your later questions.
>  
>  I think we should also confine this "server". Which package includes this? what
> is the name/location of the executable file for this service? 
OK - It's called modsecurity-console and it's located in /usr/local/bin
- but it's actually linked to /opt

# ll /usr/local/bin/modsecurity-console 
lrwxrwxrwx. 1 root root 44 2010-04-04 11:23 /usr/local/bin/modsecurity-console ->
/opt/modsecurity-console/modsecurity-console

>  > 
>  > Note however that I am also experimenting with another Console app (also
>  > Java based, which does exactly the same thing in the same way) but in
>  > this case listens on port 8443.
>  > 
>  > > 
>  > > I am think about creating a file type transition from the generic log files
> type or httpd log files type to a mlogc log files type to be created by us.
>  > > This will benefit security as:
>  > > 
>  > > 1. Hopefully mlogc_t will no longer need to manage files with type
> httpd_log_t.
>  > > 2. httpd_t (mod_security) will no longer need to create directories wuth type
> httpd_log_t and will no longer need to write to files with type httpd_log_t.
>  > > 
>  > > We must try to find the best solution to the above securities issue so again:
> two questions:
>  > > 
>  > > 1. does mod_security (mayve its configuration file) allow us to specify a
> location to store mod_security log files?
>  > > 2. if the answer to 1. is no, then can you tell me which directories in
> /var/log/httpd are used (owned) by mod_security for logging?
>  > 
>  > The answer to 1 is yes as you can see above.
>  > > 
>  > > > Raw Audit Messages :
>  > > > 
>  > > > node=troodos.org.uk type=AVC msg=audit(1270679720.128:45085): avc: denied
> { name_connect } for pid=1869 comm="mlogc" dest=8888
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:port_t:s0
> tclass=tcp_socket 
>  > > > node=troodos.org.uk type=SYSCALL msg=audit(1270679720.128:45085):
> arch=40000003 syscall=102 success=no exit=-115 a0=3 a1=b62fa910 a2=4cb9a8 a3=0 items=0
> ppid=937 pid=1869 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  > > 
>  > > The mlogc program tries to tcp network connect to port 8888, which currently is
> labeled with a generic port type.
>  > > 
>  > > 1. Why is it connecting to the network?
>  > > 2. What is listening on tcp:8888 on the other side?
>  > 
>  > That's the Console app as described above.
>  > 
>  > > 
>  > > We have to find some answers before we can start implementing a proper
> solution.
>  > 
>  > [snip]
>  > 
>  > > The above denials were what actually caused your issue in the first place. The
> only difference now is that instead of httpd_t, now mlogc_t need the access.
>  > > 
>  > > Add the following to your mlogc.te file:
>  > > 
>  > > pcscd_read_pub_files(mlogc_t)
>  > > 
>  > > That should allow mlogc_t to read pcscd pid files.
>  > 
>  > Done that - thanks..
>  > 
>  > > 
>  > > > 
>  > > > 
>  > > > And as I was copying the above, this one came in...
>  > > > 
>  > > > Raw Audit Messages :
>  > > > 
>  > > > node=troodos.org.uk type=AVC msg=audit(1270680011.472:45102): avc: denied
> { dac_override } for pid=952 comm="mlogc" capability=1
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0
> tclass=capability 
>  > > > node=troodos.org.uk type=SYSCALL msg=audit(1270680011.472:45102):
> arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0
> ppid=937 pid=952 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  > > > 
>  > > > 
>  > > 
>  > > The above means that root/mlogc is overriding traditional security. For example
> accessing a location not owned by root. We should figure out which location it is that
> mlogc tries to access that is not owned by root. Once we determine this, we can make the
> right security decision.
>  > > 
>  > > 
>  > > Now we are getting into the harder aspect of writing policy. 
>  > > Writing a template for a new domain and just allowing access is not so hard. 
>  > > What is harder is: making solid security decisions. 
>  > > 
>  > > 
>  > > What is it doing
>  > > why is it doing it
>  > > who is doing it to who
>  > > Is this a threat
>  > > why is it a threat
>  > > how can we neutralize it?
>  > > 
>  > > fun!
>  > 
>  > For you maybe ;)
>  > 
>  > OK - I hope the above helps...
>  > 
>  > By the way since my last message I have had another 71 AVcs - too many
>  > to post, and doubtless many duplicates, but here is what audit2allow has
>  > to say about them:
>  > 
>  > # ausearch -m AVC -ts today | audit2allow -R
>  > 
>  > require {
>  > 	type mlogc_t;
>  > 	type httpd_t;
>  > 	class capability { sys_nice dac_override };
>  > 	class process { setsched signal getsched };
>  > 	class sem { read write create unix_write destroy };
>  > }
>  > 
>  > #============= httpd_t ==============
>  > allow httpd_t mlogc_t:process signal;
>  
>  Ignore this for now, we might add it later.
>  
>  > 
>  > #============= mlogc_t ==============
>  > allow mlogc_t self:capability { sys_nice dac_override };
>  
>  Did you figure out which location not owned by root mlogc is trying to access?
>  For the moment lets ignore these. 
>  
>  > allow mlogc_t self:process { setsched getsched };
>  
>  The above can be added to mlogc.te
>  
>  > allow mlogc_t self:sem { read write create unix_write destroy };
>  
>  Ignore for now
>  
>  > files_rw_etc_files(mlogc_t) 
Done those...

>  I suspect that mlogc_t is writing to its own configuration file but i
> cannot be sure until i see the avc denials
>  related to this:
>  
>  ausearch -m avc -ts today | grep mlogc_t | grep etc_t | grep write 
That produced nothing:

# ausearch -m avc -ts today | grep mlogc_t | grep etc_t
type=AVC msg=audit(1270692897.579:45613): avc:  denied  { open } for  pid=6645
comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233394
scontext=system_u:system_r:mlogc_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0
tclass=file
type=AVC msg=audit(1270692897.579:45613): avc:  denied  { read } for  pid=6645
comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233394
scontext=system_u:system_r:mlogc_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0
tclass=file
type=AVC msg=audit(1270728056.690:46895): avc:  denied  { open } for  pid=10851
comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233510
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
type=AVC msg=audit(1270728056.690:46895): avc:  denied  { read } for  pid=10851
comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233510
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file


>  
>  
>  > miscfiles_rw_localization(mlogc_t)
>  
>  This is a misinterpretation by the audit2allow -R command (bug)
>  
>  Add the following instead to mlogc.te to allow this access:
>  
>  miscfiles_read_localization(mlogc_t) 
Done that...

Having done all that (including moving mlogc back to /var/log/mlogc)
these are the current AVCs (18 of them) since making the above changes:

# ausearch -m AVC -ts recent | audit2allow -R

require {
	type var_log_t;
	type httpd_log_t;
	type pcscd_t;
	type httpd_t;
	type mlogc_t;
	class capability dac_override;
	class unix_stream_socket connectto;
	class sem { read write unix_write };
	class file { write rename unlink };
	class dir create;
}

#============= httpd_t ==============
allow httpd_t httpd_log_t:file write;
allow httpd_t var_log_t:dir create;

#============= mlogc_t ==============
allow mlogc_t httpd_log_t:file { rename unlink };
allow mlogc_t pcscd_t:unix_stream_socket connectto;
allow mlogc_t self:capability dac_override;
allow mlogc_t self:sem { read write unix_write };
corenet_tcp_connect_generic_port(mlogc_t)
dev_read_urand(mlogc_t)
files_list_tmp(mlogc_t)
files_read_usr_symlinks(mlogc_t)
files_rw_etc_files(mlogc_t)
miscfiles_read_certs(mlogc_t)
pcscd_stream_connect(mlogc_t)

Phew!

Are we getting closer?

Thanks - yet again!

Mark

[Dominick Grift]

On Thu, Apr 08, 2010 at 02:27:02PM +0100, Arthur Dent wrote:
>  On Thu, 2010-04-08 at 11:35 +0200, Dominick Grift wrote:
>  > On Thu, Apr 08, 2010 at 09:40:41AM +0100, Arthur Dent wrote:
>  > > On Thu, 2010-04-08 at 08:42 +0200, Dominick Grift wrote:
>  > > 
>  > > [snip]
>  > > > 
>  > > > I gather that these access vectors denials are caused by the actual
> mod_security module. Since the source in the interaction is the httpd programs.
>  > > > 
>  > > > This brings us to a security issue need to consider and deal with.
>  > > > 
>  > > > As you can see: httpd_t is not allowed to create directories with type
> httpd_log_t and is not allowed to write to files with type httpd_log_t. This is because
> normally it does not need this permissions.
>  > > > 
>  > > > Httpd_t writing to its log file is a bad idea. Consider for example a
> cracker compromizing the web server trying to erase his audit trail by removing entries
> from the httpd log files.
>  > > > 
>  > > > So how can we deal with this? Well there are something we should
> investigate.
>  > > > 
>  > > > Can we configure mod_security to use a custom location for its log files?
>  > > > Maybe we do not have to:
>  > > > 
>  > > > Can you tell me which directories in /var/log/httpd are owned by
> mod_security?
>  > > 
>  > > OK - Here is the story:
>  > > 
>  > > I have been using mod-security for some time now with none of theses
>  > > shenanigans...
>  > > 
>  > > Normally mod-security writes its logs to /var/log/httpd/ (the same place
>  > > as the apache logs) and there are only 2 files:
>  > > /var/log/httpd/modsec_audit.log
>  > > /var/log/httpd/modsec_debug.log
>  > > 
>  > > The audit log being the main workhorse where each individual mod-sec
>  > > action was recorded.
>  > >  
>  > > All of that was fine. mlogc was not involved.
>  > > 
>  > > Recently, I decided to start using the Mod-Security Community Console, a
>  > > (java-based I think) web app for viewing, and giving more user-friendly
>  > > detail of, all the alerts produced by mod-sec.
>  > > 
>  > > This requires a different approach to logging and this is where mlogc
>  > > comes in.
>  > > 
>  > > Mod-security has two logging modes, serial and concurrent. "Serial"
>  > > places all alerts in the above mod-sec.audit.log. "Concurrent"
> logging,
>  > > on the other hand, places log files in separate directories
>  > > corresponding to the time that the log was generated. This is what is
>  > > required by the Console app.
>  > > 
>  > > This is configured from
>  > > the /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf file with
>  > > the following directives:
>  > > 
>  > > For Concurrent logging:-
>  > > SecAuditLogType Concurrent #(sets logging type)
>  > > SecDataDir /var/log/httpd/modsec_data # Sets log location
>  > > SecAuditLogStorageDir /var/log/httpd/mlogc/data # Location for for detailed
> logs
>  > > SecAuditLog "|/usr/bin/mlogc /etc/mlogc.conf" # Pipes the alerts to
> mlogc
>  > > 
>  > > For Serial Logging:-
>  > > #SecAuditLogType Serial
>  > > #SecAuditLog logs/modsec_audit.log
>  > > 
>  > > Mlogc has its own configuration:
>  > > /etc/mlogc.conf
>  > > 
>  > > I reproduce it in full here:
>  > > 
>  > > 
>  > > # cat /etc/mlogc.conf
>  > > ##########################################################################
>  > > # Required configuration
>  > > #   At a minimum, the items in this section will need to be adjusted to
>  > > #   fit your environment.  The remaining options are optional.
>  > > ##########################################################################
>  > > 
>  > > # Points to the root of the installation. All relative
>  > > # paths will be resolved with the help of this path.
>  > > CollectorRoot       "/var/log/httpd/mlogc"
>  > > 
>  > > # ModSecurity Console receiving URI. You can change the host
>  > > # and the port parts but leave everything else as is.
>  > > ConsoleURI          "https://127.0.0.1:8888/rpc/auditLogReceiver"
>  > > 
>  > > # Sensor credentials
>  > > SensorUsername      "MCS"
>  > > SensorPassword      "mypassword"
>  > > 
>  > > # Base directory where the audit logs are stored.  This can be specified
>  > > # as a path relative to the CollectorRoot, or a full path.
>  > > LogStorageDir       "data"
>  > > 
>  > > # Transaction log will contain the information on all log collector
>  > > # activities that happen between checkpoints. The transaction log
>  > > # is used to recover data in case of a crash (or if Apache kills
>  > > # the process).
>  > > TransactionLog      "mlogc-transaction.log"
>  > > 
>  > > # The file where the pending audit log entry data is kept. This file
>  > > # is updated on every checkpoint.
>  > > QueuePath           "mlogc-queue.log"
>  > > 
>  > > # The location of the error log.
>  > > ErrorLog            "mlogc-error.log"
>  > > 
>  > > # The location of the lock file.
>  > > LockFile            "mlogc.lck"
>  > > 
>  > > # Keep audit log entries after sending? (0=false 1=true)
>  > > # NOTE: This is required to be set in SecAuditLog mlogc config if you
>  > > # are going to use a secondary console via SecAuditLog2.
>  > > KeepEntries         0
>  > > 
>  > > 
>  > > ##########################################################################
>  > > # Optional configuration
>  > > ##########################################################################
>  > > 
>  > > # The error log level controls how much detail there
>  > > # will be in the error log. The levels are as follows:
>  > > #   0 - NONE
>  > > #   1 - ERROR
>  > > #   2 - WARNING
>  > > #   3 - NOTICE
>  > > #   4 - DEBUG
>  > > #   5 - DEBUG2
>  > > #
>  > > ErrorLogLevel       3
>  > > 
>  > > # How many concurrent connections to the server
>  > > # are we allowed to open at the same time? Log collector uses
>  > > # multiple connections in order to speed up audit log transfer.
>  > > # This is especially needed when the communication takes place
>  > > # over a slow link (e.g. not over a LAN).
>  > > MaxConnections      10
>  > > 
>  > > # How many requests a worker will process before recycling itself.
>  > > # This is to help prevent problems due to any memory leaks that may
>  > > # exists.  If this is set to 0, then no maximum is imposed. The default
>  > > # is 1000 requests per worker (the number of workers is controlled by
>  > > the
>  > > # MaxConnections limit).
>  > > MaxWorkerRequests   1000
>  > > 
>  > > # The time each connection will sit idle before being reused,
>  > > # in milliseconds. Increase if you don't want ModSecurity Console
>  > > # to be hit with too many log collector requests.
>  > > TransactionDelay    50
>  > > 
>  > > # The time to wait before initialization on startup in milliseconds.
>  > > # Increase if mlogc is starting faster then termination when the
>  > > # sensor is reloaded.
>  > > StartupDelay        5000
>  > > 
>  > > # How often is the pending audit log entry data going to be written
>  > > # to a file. The default is 15 seconds.
>  > > CheckpointInterval  15
>  > > 
>  > > # If the server fails all threads will back down until the
>  > > # problem is sorted. The management thread will periodically
>  > > # launch a thread to test the server. The default is to test
>  > > # once in 60 seconds.
>  > > ServerErrorTimeout  60
>  > > 
>  > > # The following two parameters are not used yet, but
>  > > # reserved for future expansion.
>  > > # KeepAlive         150
>  > > # KeepAliveTimeout  300
>  > > 
>  > >
> #################################################################################
>  > 
>  > 
>  > Alright. I wonder why they put that location in httpd's log location. From a
> SELinux
>  > perspective it would makes things a bit simpler if they just set:
>  > 
>  > SecAuditLogStorageDir /var/log/mlogc/data
>  > CollectorRoot       "/var/log/mlogc"
>  > LogStorageDir       "data"
>  
>  Ermmm... Sorry - That was my fault. It WAS in var/log/mlog/ I thought
>  (that since it was all to do with httpd) it would be better (and cause
>  fewr SEL AVCs) if I moved it to /var/log/http/mlogc (cringe... sorry...
>  don't hit me...!).
>  
>  OK - I'll move it back...
>  
>  
>  > 
>  > Then we can easily create a new log file type for mlogc log content in /var/log and
> set up a file type transition:
>  > 
>  > mlogc.te:
>  > 
>  > # declare a type and make the type usable for mlogc log content
>  > type mlogc_var_log_t;
>  > logging_log_file(mlogc_var_log_t;
>  > 
>  > # allow mlogc to manage and create content in /var/log with type mlogc_var_log_t:
>  > manage_dirs_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
>  > manage_files_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
>  > logging_log_filetrans(mlogc_t, mlogc_var_log_t, { dir file })
>  > 
>  > Next we add a file context specification for this in mlogc.fc:
>  > 
>  > /var/log/mlogc(/.*)? gen_context(system_u:object_r:mlogc_var_log_t, s0)
>  > 
>  > We should for now comment out or remove the "apache_manage_log(mlogc_t)"
> in mlogc.te that we added earlier for the time being.
>  
>  Done all that... 
I hope you noticed the typo i made here:

was:
logging_log_file(mlogc_var_log_t;

should be:
logging_log_file(mlogc_var_log_t)

>  
>  > > I think most of that is self-explanatory. Note especially the ConsoleURI
>  > > "https://127.0.0.1:8888/rpc/auditLogReceiver" directive. This punts
> the
>  > > alerts into the Console which listens on port 8888, and this is the
>  > > answer to one of your later questions.
>  > 
>  > I think we should also confine this "server". Which package includes this?
> what is the name/location of the executable file for this service?
>  
>  OK - It's called modsecurity-console and it's located in /usr/local/bin
>  - but it's actually linked to /opt 
What runs it? You the user or is it an init daemon.

Since it is using odd paths i asume there is no redhat rpm?

>  
>  # ll /usr/local/bin/modsecurity-console 
>  lrwxrwxrwx. 1 root root 44 2010-04-04 11:23 /usr/local/bin/modsecurity-console ->
> /opt/modsecurity-console/modsecurity-console
>  
>  > > 
>  > > Note however that I am also experimenting with another Console app (also
>  > > Java based, which does exactly the same thing in the same way) but in
>  > > this case listens on port 8443.
>  > > 
>  > > > 
>  > > > I am think about creating a file type transition from the generic log
> files type or httpd log files type to a mlogc log files type to be created by us.
>  > > > This will benefit security as:
>  > > > 
>  > > > 1. Hopefully mlogc_t will no longer need to manage files with type
> httpd_log_t.
>  > > > 2. httpd_t (mod_security) will no longer need to create directories wuth
> type httpd_log_t and will no longer need to write to files with type httpd_log_t.
>  > > > 
>  > > > We must try to find the best solution to the above securities issue so
> again: two questions:
>  > > > 
>  > > > 1. does mod_security (mayve its configuration file) allow us to specify a
> location to store mod_security log files?
>  > > > 2. if the answer to 1. is no, then can you tell me which directories in
> /var/log/httpd are used (owned) by mod_security for logging?
>  > > 
>  > > The answer to 1 is yes as you can see above.
>  > > > 
>  > > > > Raw Audit Messages :
>  > > > > 
>  > > > > node=troodos.org.uk type=AVC msg=audit(1270679720.128:45085): avc:
> denied { name_connect } for pid=1869 comm="mlogc" dest=8888
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:port_t:s0
> tclass=tcp_socket 
>  > > > > node=troodos.org.uk type=SYSCALL msg=audit(1270679720.128:45085):
> arch=40000003 syscall=102 success=no exit=-115 a0=3 a1=b62fa910 a2=4cb9a8 a3=0 items=0
> ppid=937 pid=1869 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  > > > 
>  > > > The mlogc program tries to tcp network connect to port 8888, which
> currently is labeled with a generic port type.
>  > > > 
>  > > > 1. Why is it connecting to the network?
>  > > > 2. What is listening on tcp:8888 on the other side?
>  > > 
>  > > That's the Console app as described above.
>  > > 
>  > > > 
>  > > > We have to find some answers before we can start implementing a proper
> solution.
>  > > 
>  > > [snip]
>  > > 
>  > > > The above denials were what actually caused your issue in the first place.
> The only difference now is that instead of httpd_t, now mlogc_t need the access.
>  > > > 
>  > > > Add the following to your mlogc.te file:
>  > > > 
>  > > > pcscd_read_pub_files(mlogc_t)
>  > > > 
>  > > > That should allow mlogc_t to read pcscd pid files.
>  > > 
>  > > Done that - thanks..
>  > > 
>  > > > 
>  > > > > 
>  > > > > 
>  > > > > And as I was copying the above, this one came in...
>  > > > > 
>  > > > > Raw Audit Messages :
>  > > > > 
>  > > > > node=troodos.org.uk type=AVC msg=audit(1270680011.472:45102): avc:
> denied { dac_override } for pid=952 comm="mlogc" capability=1
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0
> tclass=capability 
>  > > > > node=troodos.org.uk type=SYSCALL msg=audit(1270680011.472:45102):
> arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0
> ppid=937 pid=952 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  > > > > 
>  > > > > 
>  > > > 
>  > > > The above means that root/mlogc is overriding traditional security. For
> example accessing a location not owned by root. We should figure out which location it is
> that mlogc tries to access that is not owned by root. Once we determine this, we can make
> the right security decision.
>  > > > 
>  > > > 
>  > > > Now we are getting into the harder aspect of writing policy. 
>  > > > Writing a template for a new domain and just allowing access is not so
> hard. 
>  > > > What is harder is: making solid security decisions. 
>  > > > 
>  > > > 
>  > > > What is it doing
>  > > > why is it doing it
>  > > > who is doing it to who
>  > > > Is this a threat
>  > > > why is it a threat
>  > > > how can we neutralize it?
>  > > > 
>  > > > fun!
>  > > 
>  > > For you maybe ;)
>  > > 
>  > > OK - I hope the above helps...
>  > > 
>  > > By the way since my last message I have had another 71 AVcs - too many
>  > > to post, and doubtless many duplicates, but here is what audit2allow has
>  > > to say about them:
>  > > 
>  > > # ausearch -m AVC -ts today | audit2allow -R
>  > > 
>  > > require {
>  > > 	type mlogc_t;
>  > > 	type httpd_t;
>  > > 	class capability { sys_nice dac_override };
>  > > 	class process { setsched signal getsched };
>  > > 	class sem { read write create unix_write destroy };
>  > > }
>  > > 
>  > > #============= httpd_t ==============
>  > > allow httpd_t mlogc_t:process signal;
>  > 
>  > Ignore this for now, we might add it later.
>  > 
>  > > 
>  > > #============= mlogc_t ==============
>  > > allow mlogc_t self:capability { sys_nice dac_override };
>  > 
>  > Did you figure out which location not owned by root mlogc is trying to access?
>  > For the moment lets ignore these. 
>  > 
>  > > allow mlogc_t self:process { setsched getsched };
>  > 
>  > The above can be added to mlogc.te
>  > 
>  > > allow mlogc_t self:sem { read write create unix_write destroy };
>  > 
>  > Ignore for now
>  > 
>  > > files_rw_etc_files(mlogc_t) 
The files_rw_etc_files(mlogc_t) is bad, if you added it, please remove it

instead add the following to mlogc.te:

type mlogc_etc_t;
files_config_file(mlogc_etc_t)

read_files_pattern(mlogc_t, mlogc_etc_t, mlogc_etc_t)
files_search_etc(mlogc_t)

And add to mlogc.fc:

/etc/mlogc.conf -- gen_context(system_u:object_r:mlogc_etc_t, s0)

>  Done those...
>  
>  > I suspect that mlogc_t is writing to its own configuration file but i cannot be sure
> until i see the avc denials
>  > related to this:
>  > 
>  > ausearch -m avc -ts today | grep mlogc_t | grep etc_t | grep write
>  
>  That produced nothing:
>  
>  # ausearch -m avc -ts today | grep mlogc_t | grep etc_t
>  type=AVC msg=audit(1270692897.579:45613): avc:  denied  { open } for  pid=6645
> comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233394
> scontext=system_u:system_r:mlogc_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0
> tclass=file
>  type=AVC msg=audit(1270692897.579:45613): avc:  denied  { read } for  pid=6645
> comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233394
> scontext=system_u:system_r:mlogc_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0
> tclass=file
>  type=AVC msg=audit(1270728056.690:46895): avc:  denied  { open } for  pid=10851
> comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233510
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
>  type=AVC msg=audit(1270728056.690:46895): avc:  denied  { read } for  pid=10851
> comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233510
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
>  
>  
>  > 
>  > 
>  > > miscfiles_rw_localization(mlogc_t)
>  > 
>  > This is a misinterpretation by the audit2allow -R command (bug)
>  > 
>  > Add the following instead to mlogc.te to allow this access:
>  > 
>  > miscfiles_read_localization(mlogc_t)
>  
>  Done that...
>  
>  Having done all that (including moving mlogc back to /var/log/mlogc)
>  these are the current AVCs (18 of them) since making the above changes:
>  
>  # ausearch -m AVC -ts recent | audit2allow -R
>  
>  require {
>  	type var_log_t;
>  	type httpd_log_t;
>  	type pcscd_t;
>  	type httpd_t;
>  	type mlogc_t;
>  	class capability dac_override;
>  	class unix_stream_socket connectto;
>  	class sem { read write unix_write };
>  	class file { write rename unlink };
>  	class dir create;
>  }
>  
>  #============= httpd_t ==============
>  allow httpd_t httpd_log_t:file write;
>  allow httpd_t var_log_t:dir create; 
ignore above for now

>  
>  #============= mlogc_t ==============
>  allow mlogc_t httpd_log_t:file { rename unlink };
>  allow mlogc_t pcscd_t:unix_stream_socket connectto;
>  allow mlogc_t self:capability dac_override;
>  allow mlogc_t self:sem { read write unix_write };
>  corenet_tcp_connect_generic_port(mlogc_t) 
ignore above for now.

>  dev_read_urand(mlogc_t) 
add above to mlogc.te

>  files_list_tmp(mlogc_t) 
ignore above for now. need to figure out why its listing tmp, what is it hoping to list?

>  files_read_usr_symlinks(mlogc_t) 
not sure why it wants the above but its harmless, so can add it to mlogc.te for now

>  files_rw_etc_files(mlogc_t) 
This is a bug in audit2allow. We added proper rules above so ignore this.

>  miscfiles_read_certs(mlogc_t)
>  pcscd_stream_connect(mlogc_t) 
The above can be added to mlogc.te

We need to figure out how to deal with that console app. need to figure out what runs it
and what files it owns.

>  
>  Phew!
>  
>  Are we getting closer? 
Well closer i do not know. we are advancing.

>  
>  Thanks - yet again!
>  
>  Mark
>  
>  
>   


>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Dominick Grift]

On Thu, Apr 08, 2010 at 02:27:02PM +0100, Arthur Dent wrote:
>  On Thu, 2010-04-08 at 11:35 +0200, Dominick Grift wrote:
>  > On Thu, Apr 08, 2010 at 09:40:41AM +0100, Arthur Dent wrote:
>  > > On Thu, 2010-04-08 at 08:42 +0200, Dominick Grift wrote:
>  > > 
>  > > [snip]
>  > > > 
>  > > > I gather that these access vectors denials are caused by the actual
> mod_security module. Since the source in the interaction is the httpd programs.
>  > > > 
>  > > > This brings us to a security issue need to consider and deal with.
>  > > > 
>  > > > As you can see: httpd_t is not allowed to create directories with type
> httpd_log_t and is not allowed to write to files with type httpd_log_t. This is because
> normally it does not need this permissions.
>  > > > 
>  > > > Httpd_t writing to its log file is a bad idea. Consider for example a
> cracker compromizing the web server trying to erase his audit trail by removing entries
> from the httpd log files.
>  > > > 
>  > > > So how can we deal with this? Well there are something we should
> investigate.
>  > > > 
>  > > > Can we configure mod_security to use a custom location for its log files?
>  > > > Maybe we do not have to:
>  > > > 
>  > > > Can you tell me which directories in /var/log/httpd are owned by
> mod_security?
>  > > 
>  > > OK - Here is the story:
>  > > 
>  > > I have been using mod-security for some time now with none of theses
>  > > shenanigans...
>  > > 
>  > > Normally mod-security writes its logs to /var/log/httpd/ (the same place
>  > > as the apache logs) and there are only 2 files:
>  > > /var/log/httpd/modsec_audit.log
>  > > /var/log/httpd/modsec_debug.log
>  > > 
>  > > The audit log being the main workhorse where each individual mod-sec
>  > > action was recorded.
>  > >  
>  > > All of that was fine. mlogc was not involved.
>  > > 
>  > > Recently, I decided to start using the Mod-Security Community Console, a
>  > > (java-based I think) web app for viewing, and giving more user-friendly
>  > > detail of, all the alerts produced by mod-sec.
>  > > 
>  > > This requires a different approach to logging and this is where mlogc
>  > > comes in.
>  > > 
>  > > Mod-security has two logging modes, serial and concurrent. "Serial"
>  > > places all alerts in the above mod-sec.audit.log. "Concurrent"
> logging,
>  > > on the other hand, places log files in separate directories
>  > > corresponding to the time that the log was generated. This is what is
>  > > required by the Console app.
>  > > 
>  > > This is configured from
>  > > the /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf file with
>  > > the following directives:
>  > > 
>  > > For Concurrent logging:-
>  > > SecAuditLogType Concurrent #(sets logging type)
>  > > SecDataDir /var/log/httpd/modsec_data # Sets log location
>  > > SecAuditLogStorageDir /var/log/httpd/mlogc/data # Location for for detailed
> logs
>  > > SecAuditLog "|/usr/bin/mlogc /etc/mlogc.conf" # Pipes the alerts to
> mlogc
>  > > 
>  > > For Serial Logging:-
>  > > #SecAuditLogType Serial
>  > > #SecAuditLog logs/modsec_audit.log
>  > > 
>  > > Mlogc has its own configuration:
>  > > /etc/mlogc.conf
>  > > 
>  > > I reproduce it in full here:
>  > > 
>  > > 
>  > > # cat /etc/mlogc.conf
>  > > ##########################################################################
>  > > # Required configuration
>  > > #   At a minimum, the items in this section will need to be adjusted to
>  > > #   fit your environment.  The remaining options are optional.
>  > > ##########################################################################
>  > > 
>  > > # Points to the root of the installation. All relative
>  > > # paths will be resolved with the help of this path.
>  > > CollectorRoot       "/var/log/httpd/mlogc"
>  > > 
>  > > # ModSecurity Console receiving URI. You can change the host
>  > > # and the port parts but leave everything else as is.
>  > > ConsoleURI          "https://127.0.0.1:8888/rpc/auditLogReceiver"
>  > > 
>  > > # Sensor credentials
>  > > SensorUsername      "MCS"
>  > > SensorPassword      "mypassword"
>  > > 
>  > > # Base directory where the audit logs are stored.  This can be specified
>  > > # as a path relative to the CollectorRoot, or a full path.
>  > > LogStorageDir       "data"
>  > > 
>  > > # Transaction log will contain the information on all log collector
>  > > # activities that happen between checkpoints. The transaction log
>  > > # is used to recover data in case of a crash (or if Apache kills
>  > > # the process).
>  > > TransactionLog      "mlogc-transaction.log"
>  > > 
>  > > # The file where the pending audit log entry data is kept. This file
>  > > # is updated on every checkpoint.
>  > > QueuePath           "mlogc-queue.log"
>  > > 
>  > > # The location of the error log.
>  > > ErrorLog            "mlogc-error.log"
>  > > 
>  > > # The location of the lock file.
>  > > LockFile            "mlogc.lck"
>  > > 
>  > > # Keep audit log entries after sending? (0=false 1=true)
>  > > # NOTE: This is required to be set in SecAuditLog mlogc config if you
>  > > # are going to use a secondary console via SecAuditLog2.
>  > > KeepEntries         0
>  > > 
>  > > 
>  > > ##########################################################################
>  > > # Optional configuration
>  > > ##########################################################################
>  > > 
>  > > # The error log level controls how much detail there
>  > > # will be in the error log. The levels are as follows:
>  > > #   0 - NONE
>  > > #   1 - ERROR
>  > > #   2 - WARNING
>  > > #   3 - NOTICE
>  > > #   4 - DEBUG
>  > > #   5 - DEBUG2
>  > > #
>  > > ErrorLogLevel       3
>  > > 
>  > > # How many concurrent connections to the server
>  > > # are we allowed to open at the same time? Log collector uses
>  > > # multiple connections in order to speed up audit log transfer.
>  > > # This is especially needed when the communication takes place
>  > > # over a slow link (e.g. not over a LAN).
>  > > MaxConnections      10
>  > > 
>  > > # How many requests a worker will process before recycling itself.
>  > > # This is to help prevent problems due to any memory leaks that may
>  > > # exists.  If this is set to 0, then no maximum is imposed. The default
>  > > # is 1000 requests per worker (the number of workers is controlled by
>  > > the
>  > > # MaxConnections limit).
>  > > MaxWorkerRequests   1000
>  > > 
>  > > # The time each connection will sit idle before being reused,
>  > > # in milliseconds. Increase if you don't want ModSecurity Console
>  > > # to be hit with too many log collector requests.
>  > > TransactionDelay    50
>  > > 
>  > > # The time to wait before initialization on startup in milliseconds.
>  > > # Increase if mlogc is starting faster then termination when the
>  > > # sensor is reloaded.
>  > > StartupDelay        5000
>  > > 
>  > > # How often is the pending audit log entry data going to be written
>  > > # to a file. The default is 15 seconds.
>  > > CheckpointInterval  15
>  > > 
>  > > # If the server fails all threads will back down until the
>  > > # problem is sorted. The management thread will periodically
>  > > # launch a thread to test the server. The default is to test
>  > > # once in 60 seconds.
>  > > ServerErrorTimeout  60
>  > > 
>  > > # The following two parameters are not used yet, but
>  > > # reserved for future expansion.
>  > > # KeepAlive         150
>  > > # KeepAliveTimeout  300
>  > > 
>  > >
> #################################################################################
>  > 
>  > 
>  > Alright. I wonder why they put that location in httpd's log location. From a
> SELinux
>  > perspective it would makes things a bit simpler if they just set:
>  > 
>  > SecAuditLogStorageDir /var/log/mlogc/data
>  > CollectorRoot       "/var/log/mlogc"
>  > LogStorageDir       "data"
>  
>  Ermmm... Sorry - That was my fault. It WAS in var/log/mlog/ I thought
>  (that since it was all to do with httpd) it would be better (and cause
>  fewr SEL AVCs) if I moved it to /var/log/http/mlogc (cringe... sorry...
>  don't hit me...!).
>  
>  OK - I'll move it back...
>  
>  
>  > 
>  > Then we can easily create a new log file type for mlogc log content in /var/log and
> set up a file type transition:
>  > 
>  > mlogc.te:
>  > 
>  > # declare a type and make the type usable for mlogc log content
>  > type mlogc_var_log_t;
>  > logging_log_file(mlogc_var_log_t;
>  > 
>  > # allow mlogc to manage and create content in /var/log with type mlogc_var_log_t:
>  > manage_dirs_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
>  > manage_files_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
>  > logging_log_filetrans(mlogc_t, mlogc_var_log_t, { dir file })
>  > 
>  > Next we add a file context specification for this in mlogc.fc:
>  > 
>  > /var/log/mlogc(/.*)? gen_context(system_u:object_r:mlogc_var_log_t, s0)
>  > 
>  > We should for now comment out or remove the "apache_manage_log(mlogc_t)"
> in mlogc.te that we added earlier for the time being.
>  
>  Done all that...
>  
>  > > I think most of that is self-explanatory. Note especially the ConsoleURI
>  > > "https://127.0.0.1:8888/rpc/auditLogReceiver" directive. This punts
> the
>  > > alerts into the Console which listens on port 8888, and this is the
>  > > answer to one of your later questions.
>  > 
>  > I think we should also confine this "server". Which package includes this?
> what is the name/location of the executable file for this service?
>  
>  OK - It's called modsecurity-console and it's located in /usr/local/bin
>  - but it's actually linked to /opt
>  
>  # ll /usr/local/bin/modsecurity-console 
>  lrwxrwxrwx. 1 root root 44 2010-04-04 11:23 /usr/local/bin/modsecurity-console ->
> /opt/modsecurity-console/modsecurity-console
>  
>  > > 
>  > > Note however that I am also experimenting with another Console app (also
>  > > Java based, which does exactly the same thing in the same way) but in
>  > > this case listens on port 8443.
>  > > 
>  > > > 
>  > > > I am think about creating a file type transition from the generic log
> files type or httpd log files type to a mlogc log files type to be created by us.
>  > > > This will benefit security as:
>  > > > 
>  > > > 1. Hopefully mlogc_t will no longer need to manage files with type
> httpd_log_t.
>  > > > 2. httpd_t (mod_security) will no longer need to create directories wuth
> type httpd_log_t and will no longer need to write to files with type httpd_log_t.
>  > > > 
>  > > > We must try to find the best solution to the above securities issue so
> again: two questions:
>  > > > 
>  > > > 1. does mod_security (mayve its configuration file) allow us to specify a
> location to store mod_security log files?
>  > > > 2. if the answer to 1. is no, then can you tell me which directories in
> /var/log/httpd are used (owned) by mod_security for logging?
>  > > 
>  > > The answer to 1 is yes as you can see above.
>  > > > 
>  > > > > Raw Audit Messages :
>  > > > > 
>  > > > > node=troodos.org.uk type=AVC msg=audit(1270679720.128:45085): avc:
> denied { name_connect } for pid=1869 comm="mlogc" dest=8888
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:port_t:s0
> tclass=tcp_socket 
>  > > > > node=troodos.org.uk type=SYSCALL msg=audit(1270679720.128:45085):
> arch=40000003 syscall=102 success=no exit=-115 a0=3 a1=b62fa910 a2=4cb9a8 a3=0 items=0
> ppid=937 pid=1869 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  > > > 
>  > > > The mlogc program tries to tcp network connect to port 8888, which
> currently is labeled with a generic port type.
>  > > > 
>  > > > 1. Why is it connecting to the network?
>  > > > 2. What is listening on tcp:8888 on the other side?
>  > > 
>  > > That's the Console app as described above.
>  > > 
>  > > > 
>  > > > We have to find some answers before we can start implementing a proper
> solution.
>  > > 
>  > > [snip]
>  > > 
>  > > > The above denials were what actually caused your issue in the first place.
> The only difference now is that instead of httpd_t, now mlogc_t need the access.
>  > > > 
>  > > > Add the following to your mlogc.te file:
>  > > > 
>  > > > pcscd_read_pub_files(mlogc_t)
>  > > > 
>  > > > That should allow mlogc_t to read pcscd pid files.
>  > > 
>  > > Done that - thanks..
>  > > 
>  > > > 
>  > > > > 
>  > > > > 
>  > > > > And as I was copying the above, this one came in...
>  > > > > 
>  > > > > Raw Audit Messages :
>  > > > > 
>  > > > > node=troodos.org.uk type=AVC msg=audit(1270680011.472:45102): avc:
> denied { dac_override } for pid=952 comm="mlogc" capability=1
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0
> tclass=capability 
>  > > > > node=troodos.org.uk type=SYSCALL msg=audit(1270680011.472:45102):
> arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0
> ppid=937 pid=952 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  > > > > 
>  > > > > 
>  > > > 
>  > > > The above means that root/mlogc is overriding traditional security. For
> example accessing a location not owned by root. We should figure out which location it is
> that mlogc tries to access that is not owned by root. Once we determine this, we can make
> the right security decision.
>  > > > 
>  > > > 
>  > > > Now we are getting into the harder aspect of writing policy. 
>  > > > Writing a template for a new domain and just allowing access is not so
> hard. 
>  > > > What is harder is: making solid security decisions. 
>  > > > 
>  > > > 
>  > > > What is it doing
>  > > > why is it doing it
>  > > > who is doing it to who
>  > > > Is this a threat
>  > > > why is it a threat
>  > > > how can we neutralize it?
>  > > > 
>  > > > fun!
>  > > 
>  > > For you maybe ;)
>  > > 
>  > > OK - I hope the above helps...
>  > > 
>  > > By the way since my last message I have had another 71 AVcs - too many
>  > > to post, and doubtless many duplicates, but here is what audit2allow has
>  > > to say about them:
>  > > 
>  > > # ausearch -m AVC -ts today | audit2allow -R
>  > > 
>  > > require {
>  > > 	type mlogc_t;
>  > > 	type httpd_t;
>  > > 	class capability { sys_nice dac_override };
>  > > 	class process { setsched signal getsched };
>  > > 	class sem { read write create unix_write destroy };
>  > > }
>  > > 
>  > > #============= httpd_t ==============
>  > > allow httpd_t mlogc_t:process signal;
>  > 
>  > Ignore this for now, we might add it later.
>  > 
>  > > 
>  > > #============= mlogc_t ==============
>  > > allow mlogc_t self:capability { sys_nice dac_override };
>  > 
>  > Did you figure out which location not owned by root mlogc is trying to access?
>  > For the moment lets ignore these. 
>  > 
>  > > allow mlogc_t self:process { setsched getsched };
>  > 
>  > The above can be added to mlogc.te
>  > 
>  > > allow mlogc_t self:sem { read write create unix_write destroy };
>  > 
>  > Ignore for now
>  > 
>  > > files_rw_etc_files(mlogc_t)
>  
>  Done those...
>  
>  > I suspect that mlogc_t is writing to its own configuration file but i cannot be sure
> until i see the avc denials
>  > related to this:
>  > 
>  > ausearch -m avc -ts today | grep mlogc_t | grep etc_t | grep write
>  
>  That produced nothing:
>  
>  # ausearch -m avc -ts today | grep mlogc_t | grep etc_t
>  type=AVC msg=audit(1270692897.579:45613): avc:  denied  { open } for  pid=6645
> comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233394
> scontext=system_u:system_r:mlogc_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0
> tclass=file
>  type=AVC msg=audit(1270692897.579:45613): avc:  denied  { read } for  pid=6645
> comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233394
> scontext=system_u:system_r:mlogc_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0
> tclass=file
>  type=AVC msg=audit(1270728056.690:46895): avc:  denied  { open } for  pid=10851
> comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233510
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
>  type=AVC msg=audit(1270728056.690:46895): avc:  denied  { read } for  pid=10851
> comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233510
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
>  
>  
>  > 
>  > 
>  > > miscfiles_rw_localization(mlogc_t)
>  > 
>  > This is a misinterpretation by the audit2allow -R command (bug)
>  > 
>  > Add the following instead to mlogc.te to allow this access:
>  > 
>  > miscfiles_read_localization(mlogc_t)
>  
>  Done that...
>  
>  Having done all that (including moving mlogc back to /var/log/mlogc)
>  these are the current AVCs (18 of them) since making the above changes:
>  
>  # ausearch -m AVC -ts recent | audit2allow -R
>  
>  require {
>  	type var_log_t;
>  	type httpd_log_t;
>  	type pcscd_t;
>  	type httpd_t;
>  	type mlogc_t;
>  	class capability dac_override;
>  	class unix_stream_socket connectto;
>  	class sem { read write unix_write };
>  	class file { write rename unlink };
>  	class dir create;
>  }
>  
>  #============= httpd_t ==============
>  allow httpd_t httpd_log_t:file write;
>  allow httpd_t var_log_t:dir create; 
As for above. Make sure that file in question is labelled properly. Again httpd_t should
not need to write to its log files. Neither should mod_security. I also have mod_security
running on a server and it does not need to
write to log files (only append)

So we may end up silencing that denial.

As for httpd_t creating a dir in /var/log: I would like to see the denial. I was expecting
mlogc to create 
/var/log/mlogc.

>  
>  #============= mlogc_t ==============
>  allow mlogc_t httpd_log_t:file { rename unlink };
>  allow mlogc_t pcscd_t:unix_stream_socket connectto;
>  allow mlogc_t self:capability dac_override;
>  allow mlogc_t self:sem { read write unix_write }; 
>  corenet_tcp_connect_generic_port(mlogc_t) 
Alright, well i assume the "console app" is a user app that is started by you,
the unconfined user.
I guess in that case we must allow mlogc to connect to any generic port. A bit coarse for
my taste but so be it.

Add the following to all mlogc to connect to generic tcp ports in mlogc.te:

corenet_all_recvfrom_netlabel(mlogc_t)
corenet_all_recvfrom_unlabeled(mlogc_t)
corenet_tcp_sendrecv_generic_if(mlogc_t)
corenet_tcp_sendrecv_generic_node(mlogc_t)
corenet_tcp_sendrecv_generic_port(mlogc_t)
corenet_tcp_bind_generic_node(mlogc_t)
corenet_sendrecv_generic_client_packets(mlogc_t)
corenet_tcp_connect_generic_port(mlogc_t)

>  dev_read_urand(mlogc_t)
>  files_list_tmp(mlogc_t)
>  files_read_usr_symlinks(mlogc_t)
>  files_rw_etc_files(mlogc_t)
>  miscfiles_read_certs(mlogc_t)
>  pcscd_stream_connect(mlogc_t)
>  
>  Phew!
>  
>  Are we getting closer?
>  
>  Thanks - yet again!
>  
>  Mark
>  
>  
>   


>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Arthur Dent]

On Thu, 2010-04-08 at 16:09 +0200, Dominick Grift wrote:

>  > Done all that...
>  
>  I hope you noticed the typo i made here:
>  
>  was:
>  logging_log_file(mlogc_var_log_t;
>  
>  should be:
>  logging_log_file(mlogc_var_log_t) 
Yes, I caught that one. By the way, is a semicolon required after every
line?

>  
>  > 
>  > > > I think most of that is self-explanatory. Note especially the ConsoleURI
>  > > > "https://127.0.0.1:8888/rpc/auditLogReceiver" directive. This
> punts the
>  > > > alerts into the Console which listens on port 8888, and this is the
>  > > > answer to one of your later questions.
>  > > 
>  > > I think we should also confine this "server". Which package includes
> this? what is the name/location of the executable file for this service?
>  > 
>  > OK - It's called modsecurity-console and it's located in /usr/local/bin
>  > - but it's actually linked to /opt
>  
>  What runs it? You the user or is it an init daemon. 
Yes, at the moment I start it manually or with a cron job
(@reboot /usr/local/bin/modsecurity-console start) although i was
planning to make an init.d script for it given time..
 
>  
>  Since it is using odd paths i asume there is no redhat rpm? 
No, This is an RPM, but from Breach Security - the authors. I also
installed it from source previously.

>  > 
>  > # ll /usr/local/bin/modsecurity-console 
>  > lrwxrwxrwx. 1 root root 44 2010-04-04 11:23 /usr/local/bin/modsecurity-console ->
> /opt/modsecurity-console/modsecurity-console
>  > 
>  > > > 
>  > > > Note however that I am also experimenting with another Console app (also
>  > > > Java based, which does exactly the same thing in the same way) but in
>  > > > this case listens on port 8443.
>  > > > 
>  > > > > 
>  > > > > I am think about creating a file type transition from the generic log
> files type or httpd log files type to a mlogc log files type to be created by us.
>  > > > > This will benefit security as:
>  > > > > 
>  > > > > 1. Hopefully mlogc_t will no longer need to manage files with type
> httpd_log_t.
>  > > > > 2. httpd_t (mod_security) will no longer need to create directories
> wuth type httpd_log_t and will no longer need to write to files with type httpd_log_t.
>  > > > > 
>  > > > > We must try to find the best solution to the above securities issue
> so again: two questions:
>  > > > > 
>  > > > > 1. does mod_security (mayve its configuration file) allow us to
> specify a location to store mod_security log files?
>  > > > > 2. if the answer to 1. is no, then can you tell me which directories
> in /var/log/httpd are used (owned) by mod_security for logging?
>  > > > 
>  > > > The answer to 1 is yes as you can see above.
>  > > > > 
>  > > > > > Raw Audit Messages :
>  > > > > > 
>  > > > > > node=troodos.org.uk type=AVC msg=audit(1270679720.128:45085):
> avc: denied { name_connect } for pid=1869 comm="mlogc" dest=8888
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:port_t:s0
> tclass=tcp_socket 
>  > > > > > node=troodos.org.uk type=SYSCALL
> msg=audit(1270679720.128:45085): arch=40000003 syscall=102 success=no exit=-115 a0=3
> a1=b62fa910 a2=4cb9a8 a3=0 items=0 ppid=937 pid=1869 auid=4294967295 uid=0 gid=0 euid=0
> suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc"
> exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  > > > > 
>  > > > > The mlogc program tries to tcp network connect to port 8888, which
> currently is labeled with a generic port type.
>  > > > > 
>  > > > > 1. Why is it connecting to the network?
>  > > > > 2. What is listening on tcp:8888 on the other side?
>  > > > 
>  > > > That's the Console app as described above.
>  > > > 
>  > > > > 
>  > > > > We have to find some answers before we can start implementing a
> proper solution.
>  > > > 
>  > > > [snip]
>  > > > 
>  > > > > The above denials were what actually caused your issue in the first
> place. The only difference now is that instead of httpd_t, now mlogc_t need the access.
>  > > > > 
>  > > > > Add the following to your mlogc.te file:
>  > > > > 
>  > > > > pcscd_read_pub_files(mlogc_t)
>  > > > > 
>  > > > > That should allow mlogc_t to read pcscd pid files.
>  > > > 
>  > > > Done that - thanks..
>  > > > 
>  > > > > 
>  > > > > > 
>  > > > > > 
>  > > > > > And as I was copying the above, this one came in...
>  > > > > > 
>  > > > > > Raw Audit Messages :
>  > > > > > 
>  > > > > > node=troodos.org.uk type=AVC msg=audit(1270680011.472:45102):
> avc: denied { dac_override } for pid=952 comm="mlogc" capability=1
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0
> tclass=capability 
>  > > > > > node=troodos.org.uk type=SYSCALL
> msg=audit(1270680011.472:45102): arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170
> a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952 auid=4294967295 uid=0 gid=0 euid=0 suid=0
> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc"
> exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  > > > > > 
>  > > > > > 
>  > > > > 
>  > > > > The above means that root/mlogc is overriding traditional security.
> For example accessing a location not owned by root. We should figure out which location it
> is that mlogc tries to access that is not owned by root. Once we determine this, we can
> make the right security decision.
>  > > > > 
>  > > > > 
>  > > > > Now we are getting into the harder aspect of writing policy. 
>  > > > > Writing a template for a new domain and just allowing access is not
> so hard. 
>  > > > > What is harder is: making solid security decisions. 
>  > > > > 
>  > > > > 
>  > > > > What is it doing
>  > > > > why is it doing it
>  > > > > who is doing it to who
>  > > > > Is this a threat
>  > > > > why is it a threat
>  > > > > how can we neutralize it?
>  > > > > 
>  > > > > fun!
>  > > > 
>  > > > For you maybe ;)
>  > > > 
>  > > > OK - I hope the above helps...
>  > > > 
>  > > > By the way since my last message I have had another 71 AVcs - too many
>  > > > to post, and doubtless many duplicates, but here is what audit2allow has
>  > > > to say about them:
>  > > > 
>  > > > # ausearch -m AVC -ts today | audit2allow -R
>  > > > 
>  > > > require {
>  > > > 	type mlogc_t;
>  > > > 	type httpd_t;
>  > > > 	class capability { sys_nice dac_override };
>  > > > 	class process { setsched signal getsched };
>  > > > 	class sem { read write create unix_write destroy };
>  > > > }
>  > > > 
>  > > > #============= httpd_t ==============
>  > > > allow httpd_t mlogc_t:process signal;
>  > > 
>  > > Ignore this for now, we might add it later.
>  > > 
>  > > > 
>  > > > #============= mlogc_t ==============
>  > > > allow mlogc_t self:capability { sys_nice dac_override };
>  > > 
>  > > Did you figure out which location not owned by root mlogc is trying to access?
>  > > For the moment lets ignore these. 
>  > > 
>  > > > allow mlogc_t self:process { setsched getsched };
>  > > 
>  > > The above can be added to mlogc.te
>  > > 
>  > > > allow mlogc_t self:sem { read write create unix_write destroy };
>  > > 
>  > > Ignore for now
>  > > 
>  > > > files_rw_etc_files(mlogc_t)
>  
>  The files_rw_etc_files(mlogc_t) is bad, if you added it, please remove it 
Nope. You didn't tell me to add it so I didn't. I only do what I'm
told ;)

>  
>  instead add the following to mlogc.te:
>  
>  type mlogc_etc_t;
>  files_config_file(mlogc_etc_t)
>  read_files_pattern(mlogc_t, mlogc_etc_t, mlogc_etc_t)
>  files_search_etc(mlogc_t) 
Done.

>  And add to mlogc.fc:
>  
>  /etc/mlogc.conf -- gen_context(system_u:object_r:mlogc_etc_t, s0) 
Done.


>  > Having done all that (including moving mlogc back to
> /var/log/mlogc)
>  > these are the current AVCs (18 of them) since making the above changes:
>  > 
>  > # ausearch -m AVC -ts recent | audit2allow -R
>  > 
>  > require {
>  > 	type var_log_t;
>  > 	type httpd_log_t;
>  > 	type pcscd_t;
>  > 	type httpd_t;
>  > 	type mlogc_t;
>  > 	class capability dac_override;
>  > 	class unix_stream_socket connectto;
>  > 	class sem { read write unix_write };
>  > 	class file { write rename unlink };
>  > 	class dir create;
>  > }
>  > 
>  > #============= httpd_t ==============
>  > allow httpd_t httpd_log_t:file write;
>  > allow httpd_t var_log_t:dir create;
>  
>  ignore above for now
>  
>  > 
>  > #============= mlogc_t ==============
>  > allow mlogc_t httpd_log_t:file { rename unlink };
>  > allow mlogc_t pcscd_t:unix_stream_socket connectto;
>  > allow mlogc_t self:capability dac_override;
>  > allow mlogc_t self:sem { read write unix_write };
>  > corenet_tcp_connect_generic_port(mlogc_t)
>  
>  ignore above for now.
>  
>  > dev_read_urand(mlogc_t)
>  
>  add above to mlogc.te 
Done.

>  > files_list_tmp(mlogc_t)
>  
>  ignore above for now. need to figure out why its listing tmp, what is it hoping to list?
>  
>  > files_read_usr_symlinks(mlogc_t)
>  
>  not sure why it wants the above but its harmless, so can add it to mlogc.te for now
Done.

>  > files_rw_etc_files(mlogc_t)
>  
>  This is a bug in audit2allow. We added proper rules above so ignore this.
>  
>  > miscfiles_read_certs(mlogc_t)
>  > pcscd_stream_connect(mlogc_t)
>  
>  The above can be added to mlogc.te 
Done.


OK - Let's see what that brings...

Oops:
# make -f /usr/share/selinux/devel/Makefile
Compiling targeted mlogc module
/usr/bin/checkmodule:  loading policy configuration from tmp/mlogc.tmp
mlogc.te":16:ERROR 'unknown type mlogc_etc_t' at token ';' on line
3828:
	typeattribute mlogc_etc_t etcfile;
#line 16
/usr/bin/checkmodule:  error(s) encountered while parsing configuration
make: *** [tmp/mlogc.mod] Error 1

Is this the problem?
read_files_pattern(mlogc_t, mlogc_etc_t, mlogc_etc_t)
2 x mlogc_etc_t ? Should that be something else or just 1 x ?

Here is the current mlogc.te

# cat mlogc.te 
policy_module(mlogc, 1.0.3)

type mlogc_t;
type mlogc_exec_t;
type mlogc_var_log_t;

logging_log_file(mlogc_var_log_t);
logging_log_filetrans(mlogc_t, mlogc_var_log_t, { dir file })
application_domain(mlogc_t, mlogc_exec_t);
role system_r types mlogc_t;
permissive mlogc_t;
manage_dirs_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
manage_files_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
read_files_pattern(mlogc_t, mlogc_etc_t, mlogc_etc_t)
files_search_etc(mlogc_t)
files_config_file(mlogc_etc_t)
files_read_usr_symlinks(mlogc_t)
pcscd_read_pub_files(mlogc_t);
pcscd_stream_connect(mlogc_t)
miscfiles_read_localization(mlogc_t)
miscfiles_read_certs(mlogc_t)
dev_read_urand(mlogc_t)
#apache_manage_log(mlogc_t);

allow mlogc_t self:tcp_socket create_socket_perms;
allow mlogc_t self:udp_socket create_socket_perms;
allow mlogc_t self:netlink_route_socket create_netlink_socket_perms;
allow mlogc_t self:process { setsched getsched };

[Dominick Grift]

On Thu, Apr 08, 2010 at 03:50:17PM +0100, Arthur Dent wrote:
>  On Thu, 2010-04-08 at 16:09 +0200, Dominick Grift wrote:
>  
>  > > Done all that...
>  > 
>  > I hope you noticed the typo i made here:
>  > 
>  > was:
>  > logging_log_file(mlogc_var_log_t;
>  > 
>  > should be:
>  > logging_log_file(mlogc_var_log_t)
>  
>  Yes, I caught that one. By the way, is a semicolon required after every
>  line? 
Yes pretty much, unless it end with a ) like logging_log_file(mlogc_var_log_t)
>  
>  > 
>  > > 
>  > > > > I think most of that is self-explanatory. Note especially the
> ConsoleURI
>  > > > > "https://127.0.0.1:8888/rpc/auditLogReceiver" directive.
> This punts the
>  > > > > alerts into the Console which listens on port 8888, and this is the
>  > > > > answer to one of your later questions.
>  > > > 
>  > > > I think we should also confine this "server". Which package
> includes this? what is the name/location of the executable file for this service?
>  > > 
>  > > OK - It's called modsecurity-console and it's located in
> /usr/local/bin
>  > > - but it's actually linked to /opt
>  > 
>  > What runs it? You the user or is it an init daemon.
>  
>  Yes, at the moment I start it manually or with a cron job
>  (@reboot /usr/local/bin/modsecurity-console start) although i was
>  planning to make an init.d script for it given time..
>   
>  > 
>  > Since it is using odd paths i asume there is no redhat rpm?
>  
>  No, This is an RPM, but from Breach Security - the authors. I also
>  installed it from source previously. 
That explains the odd paths

>  
>  > > 
>  > > # ll /usr/local/bin/modsecurity-console 
>  > > lrwxrwxrwx. 1 root root 44 2010-04-04 11:23 /usr/local/bin/modsecurity-console
> -> /opt/modsecurity-console/modsecurity-console
>  > > 
>  > > > > 
>  > > > > Note however that I am also experimenting with another Console app
> (also
>  > > > > Java based, which does exactly the same thing in the same way) but
> in
>  > > > > this case listens on port 8443.
>  > > > > 
>  > > > > > 
>  > > > > > I am think about creating a file type transition from the
> generic log files type or httpd log files type to a mlogc log files type to be created by
> us.
>  > > > > > This will benefit security as:
>  > > > > > 
>  > > > > > 1. Hopefully mlogc_t will no longer need to manage files with
> type httpd_log_t.
>  > > > > > 2. httpd_t (mod_security) will no longer need to create
> directories wuth type httpd_log_t and will no longer need to write to files with type
> httpd_log_t.
>  > > > > > 
>  > > > > > We must try to find the best solution to the above securities
> issue so again: two questions:
>  > > > > > 
>  > > > > > 1. does mod_security (mayve its configuration file) allow us to
> specify a location to store mod_security log files?
>  > > > > > 2. if the answer to 1. is no, then can you tell me which
> directories in /var/log/httpd are used (owned) by mod_security for logging?
>  > > > > 
>  > > > > The answer to 1 is yes as you can see above.
>  > > > > > 
>  > > > > > > Raw Audit Messages :
>  > > > > > > 
>  > > > > > > node=troodos.org.uk type=AVC
> msg=audit(1270679720.128:45085): avc: denied { name_connect } for pid=1869
> comm="mlogc" dest=8888 scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket 
>  > > > > > > node=troodos.org.uk type=SYSCALL
> msg=audit(1270679720.128:45085): arch=40000003 syscall=102 success=no exit=-115 a0=3
> a1=b62fa910 a2=4cb9a8 a3=0 items=0 ppid=937 pid=1869 auid=4294967295 uid=0 gid=0 euid=0
> suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc"
> exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  > > > > > 
>  > > > > > The mlogc program tries to tcp network connect to port 8888,
> which currently is labeled with a generic port type.
>  > > > > > 
>  > > > > > 1. Why is it connecting to the network?
>  > > > > > 2. What is listening on tcp:8888 on the other side?
>  > > > > 
>  > > > > That's the Console app as described above.
>  > > > > 
>  > > > > > 
>  > > > > > We have to find some answers before we can start implementing a
> proper solution.
>  > > > > 
>  > > > > [snip]
>  > > > > 
>  > > > > > The above denials were what actually caused your issue in the
> first place. The only difference now is that instead of httpd_t, now mlogc_t need the
> access.
>  > > > > > 
>  > > > > > Add the following to your mlogc.te file:
>  > > > > > 
>  > > > > > pcscd_read_pub_files(mlogc_t)
>  > > > > > 
>  > > > > > That should allow mlogc_t to read pcscd pid files.
>  > > > > 
>  > > > > Done that - thanks..
>  > > > > 
>  > > > > > 
>  > > > > > > 
>  > > > > > > 
>  > > > > > > And as I was copying the above, this one came in...
>  > > > > > > 
>  > > > > > > Raw Audit Messages :
>  > > > > > > 
>  > > > > > > node=troodos.org.uk type=AVC
> msg=audit(1270680011.472:45102): avc: denied { dac_override } for pid=952
> comm="mlogc" capability=1 scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=capability 
>  > > > > > > node=troodos.org.uk type=SYSCALL
> msg=audit(1270680011.472:45102): arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170
> a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952 auid=4294967295 uid=0 gid=0 euid=0 suid=0
> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc"
> exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  > > > > > > 
>  > > > > > > 
>  > > > > > 
>  > > > > > The above means that root/mlogc is overriding traditional
> security. For example accessing a location not owned by root. We should figure out which
> location it is that mlogc tries to access that is not owned by root. Once we determine
> this, we can make the right security decision.
>  > > > > > 
>  > > > > > 
>  > > > > > Now we are getting into the harder aspect of writing policy. 
>  > > > > > Writing a template for a new domain and just allowing access is
> not so hard. 
>  > > > > > What is harder is: making solid security decisions. 
>  > > > > > 
>  > > > > > 
>  > > > > > What is it doing
>  > > > > > why is it doing it
>  > > > > > who is doing it to who
>  > > > > > Is this a threat
>  > > > > > why is it a threat
>  > > > > > how can we neutralize it?
>  > > > > > 
>  > > > > > fun!
>  > > > > 
>  > > > > For you maybe ;)
>  > > > > 
>  > > > > OK - I hope the above helps...
>  > > > > 
>  > > > > By the way since my last message I have had another 71 AVcs - too
> many
>  > > > > to post, and doubtless many duplicates, but here is what audit2allow
> has
>  > > > > to say about them:
>  > > > > 
>  > > > > # ausearch -m AVC -ts today | audit2allow -R
>  > > > > 
>  > > > > require {
>  > > > > 	type mlogc_t;
>  > > > > 	type httpd_t;
>  > > > > 	class capability { sys_nice dac_override };
>  > > > > 	class process { setsched signal getsched };
>  > > > > 	class sem { read write create unix_write destroy };
>  > > > > }
>  > > > > 
>  > > > > #============= httpd_t ==============
>  > > > > allow httpd_t mlogc_t:process signal;
>  > > > 
>  > > > Ignore this for now, we might add it later.
>  > > > 
>  > > > > 
>  > > > > #============= mlogc_t ==============
>  > > > > allow mlogc_t self:capability { sys_nice dac_override };
>  > > > 
>  > > > Did you figure out which location not owned by root mlogc is trying to
> access?
>  > > > For the moment lets ignore these. 
>  > > > 
>  > > > > allow mlogc_t self:process { setsched getsched };
>  > > > 
>  > > > The above can be added to mlogc.te
>  > > > 
>  > > > > allow mlogc_t self:sem { read write create unix_write destroy };
>  > > > 
>  > > > Ignore for now
>  > > > 
>  > > > > files_rw_etc_files(mlogc_t)
>  > 
>  > The files_rw_etc_files(mlogc_t) is bad, if you added it, please remove it
>  
>  Nope. You didn't tell me to add it so I didn't. I only do what I'm
>  told ;)
>  
>  > 
>  > instead add the following to mlogc.te:
>  > 
>  > type mlogc_etc_t;
>  > files_config_file(mlogc_etc_t)
>  > read_files_pattern(mlogc_t, mlogc_etc_t, mlogc_etc_t)
>  > files_search_etc(mlogc_t)
>  
>  Done.
>  
>  > And add to mlogc.fc:
>  > 
>  > /etc/mlogc.conf -- gen_context(system_u:object_r:mlogc_etc_t, s0)
>  
>  Done.
>  
>  
>  > > Having done all that (including moving mlogc back to /var/log/mlogc)
>  > > these are the current AVCs (18 of them) since making the above changes:
>  > > 
>  > > # ausearch -m AVC -ts recent | audit2allow -R
>  > > 
>  > > require {
>  > > 	type var_log_t;
>  > > 	type httpd_log_t;
>  > > 	type pcscd_t;
>  > > 	type httpd_t;
>  > > 	type mlogc_t;
>  > > 	class capability dac_override;
>  > > 	class unix_stream_socket connectto;
>  > > 	class sem { read write unix_write };
>  > > 	class file { write rename unlink };
>  > > 	class dir create;
>  > > }
>  > > 
>  > > #============= httpd_t ==============
>  > > allow httpd_t httpd_log_t:file write;
>  > > allow httpd_t var_log_t:dir create;
>  > 
>  > ignore above for now
>  > 
>  > > 
>  > > #============= mlogc_t ==============
>  > > allow mlogc_t httpd_log_t:file { rename unlink };
>  > > allow mlogc_t pcscd_t:unix_stream_socket connectto;
>  > > allow mlogc_t self:capability dac_override;
>  > > allow mlogc_t self:sem { read write unix_write };
>  > > corenet_tcp_connect_generic_port(mlogc_t)
>  > 
>  > ignore above for now.
>  > 
>  > > dev_read_urand(mlogc_t)
>  > 
>  > add above to mlogc.te
>  
>  Done.
>  
>  > > files_list_tmp(mlogc_t)
>  > 
>  > ignore above for now. need to figure out why its listing tmp, what is it hoping to
> list?
>  > 
>  > > files_read_usr_symlinks(mlogc_t)
>  > 
>  > not sure why it wants the above but its harmless, so can add it to mlogc.te for now
>  
>  Done.
>  
>  > > files_rw_etc_files(mlogc_t)
>  > 
>  > This is a bug in audit2allow. We added proper rules above so ignore this.
>  > 
>  > > miscfiles_read_certs(mlogc_t)
>  > > pcscd_stream_connect(mlogc_t)
>  > 
>  > The above can be added to mlogc.te
>  
>  Done.
>  
>  
>  OK - Let's see what that brings...
>  
>  Oops:
>  # make -f /usr/share/selinux/devel/Makefile
>  Compiling targeted mlogc module
>  /usr/bin/checkmodule:  loading policy configuration from tmp/mlogc.tmp
>  mlogc.te":16:ERROR 'unknown type mlogc_etc_t' at token ';' on line
> 3828:
>  	typeattribute mlogc_etc_t etcfile;
>  #line 16
>  /usr/bin/checkmodule:  error(s) encountered while parsing configuration
>  make: *** [tmp/mlogc.mod] Error 1
>   
no, you forgot to declare "type mlogc_etc_t;" in mlogc.te

>  Is this the problem?
>  read_files_pattern(mlogc_t, mlogc_etc_t, mlogc_etc_t)
>  2 x mlogc_etc_t ? Should that be something else or just 1 x ?
>  
>  Here is the current mlogc.te
>  
>  # cat mlogc.te 
>  policy_module(mlogc, 1.0.3)
>  
>  type mlogc_t;
>  type mlogc_exec_t;
>  type mlogc_var_log_t;
>  
>  logging_log_file(mlogc_var_log_t);
>  logging_log_filetrans(mlogc_t, mlogc_var_log_t, { dir file })
>  application_domain(mlogc_t, mlogc_exec_t);
>  role system_r types mlogc_t;
>  permissive mlogc_t;
>  manage_dirs_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
>  manage_files_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
>  read_files_pattern(mlogc_t, mlogc_etc_t, mlogc_etc_t)
>  files_search_etc(mlogc_t)
>  files_config_file(mlogc_etc_t)
>  files_read_usr_symlinks(mlogc_t)
>  pcscd_read_pub_files(mlogc_t);
>  pcscd_stream_connect(mlogc_t)
>  miscfiles_read_localization(mlogc_t)
>  miscfiles_read_certs(mlogc_t)
>  dev_read_urand(mlogc_t)
>  #apache_manage_log(mlogc_t);
>  
>  allow mlogc_t self:tcp_socket create_socket_perms;
>  allow mlogc_t self:udp_socket create_socket_perms;
>  allow mlogc_t self:netlink_route_socket create_netlink_socket_perms;
>  allow mlogc_t self:process { setsched getsched };
>  
>  
>  
>  
>   


>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Dominick Grift]

On Thu, Apr 08, 2010 at 03:50:17PM +0100, Arthur Dent wrote:
>  On Thu, 2010-04-08 at 16:09 +0200, Dominick Grift wrote:
>  
>  > > Done all that...
>  > 
>  > I hope you noticed the typo i made here:
>  > 
>  > was:
>  > logging_log_file(mlogc_var_log_t;
>  > 
>  > should be:
>  > logging_log_file(mlogc_var_log_t)
>  
>  Yes, I caught that one. By the way, is a semicolon required after every
>  line?
>  
>  > 
>  > > 
>  > > > > I think most of that is self-explanatory. Note especially the
> ConsoleURI
>  > > > > "https://127.0.0.1:8888/rpc/auditLogReceiver" directive.
> This punts the
>  > > > > alerts into the Console which listens on port 8888, and this is the
>  > > > > answer to one of your later questions.
>  > > > 
>  > > > I think we should also confine this "server". Which package
> includes this? what is the name/location of the executable file for this service?
>  > > 
>  > > OK - It's called modsecurity-console and it's located in
> /usr/local/bin
>  > > - but it's actually linked to /opt
>  > 
>  > What runs it? You the user or is it an init daemon.
>  
>  Yes, at the moment I start it manually or with a cron job
>  (@reboot /usr/local/bin/modsecurity-console start) although i was
>  planning to make an init.d script for it given time.. 
We should (in time) figure out a proper solution. In your configuration, you may be able
to bind tcp sockets to ports but in a strictly enforced SELinux environment users may not
do that, thus it would not be allowed to listen on those  ports unless policy was written
for it that allows it.

But i do not want to overwhelm you at this moment and so in my previous message i added
policy that allows mlogc_t to connect to any generic tcp port types.

>   
>  > 
>  > Since it is using odd paths i asume there is no redhat rpm?
>  
>  No, This is an RPM, but from Breach Security - the authors. I also
>  installed it from source previously.
>  
>  > > 
>  > > # ll /usr/local/bin/modsecurity-console 
>  > > lrwxrwxrwx. 1 root root 44 2010-04-04 11:23 /usr/local/bin/modsecurity-console
> -> /opt/modsecurity-console/modsecurity-console
>  > > 
>  > > > > 
>  > > > > Note however that I am also experimenting with another Console app
> (also
>  > > > > Java based, which does exactly the same thing in the same way) but
> in
>  > > > > this case listens on port 8443.
>  > > > > 
>  > > > > > 
>  > > > > > I am think about creating a file type transition from the
> generic log files type or httpd log files type to a mlogc log files type to be created by
> us.
>  > > > > > This will benefit security as:
>  > > > > > 
>  > > > > > 1. Hopefully mlogc_t will no longer need to manage files with
> type httpd_log_t.
>  > > > > > 2. httpd_t (mod_security) will no longer need to create
> directories wuth type httpd_log_t and will no longer need to write to files with type
> httpd_log_t.
>  > > > > > 
>  > > > > > We must try to find the best solution to the above securities
> issue so again: two questions:
>  > > > > > 
>  > > > > > 1. does mod_security (mayve its configuration file) allow us to
> specify a location to store mod_security log files?
>  > > > > > 2. if the answer to 1. is no, then can you tell me which
> directories in /var/log/httpd are used (owned) by mod_security for logging?
>  > > > > 
>  > > > > The answer to 1 is yes as you can see above.
>  > > > > > 
>  > > > > > > Raw Audit Messages :
>  > > > > > > 
>  > > > > > > node=troodos.org.uk type=AVC
> msg=audit(1270679720.128:45085): avc: denied { name_connect } for pid=1869
> comm="mlogc" dest=8888 scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket 
>  > > > > > > node=troodos.org.uk type=SYSCALL
> msg=audit(1270679720.128:45085): arch=40000003 syscall=102 success=no exit=-115 a0=3
> a1=b62fa910 a2=4cb9a8 a3=0 items=0 ppid=937 pid=1869 auid=4294967295 uid=0 gid=0 euid=0
> suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc"
> exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  > > > > > 
>  > > > > > The mlogc program tries to tcp network connect to port 8888,
> which currently is labeled with a generic port type.
>  > > > > > 
>  > > > > > 1. Why is it connecting to the network?
>  > > > > > 2. What is listening on tcp:8888 on the other side?
>  > > > > 
>  > > > > That's the Console app as described above.
>  > > > > 
>  > > > > > 
>  > > > > > We have to find some answers before we can start implementing a
> proper solution.
>  > > > > 
>  > > > > [snip]
>  > > > > 
>  > > > > > The above denials were what actually caused your issue in the
> first place. The only difference now is that instead of httpd_t, now mlogc_t need the
> access.
>  > > > > > 
>  > > > > > Add the following to your mlogc.te file:
>  > > > > > 
>  > > > > > pcscd_read_pub_files(mlogc_t)
>  > > > > > 
>  > > > > > That should allow mlogc_t to read pcscd pid files.
>  > > > > 
>  > > > > Done that - thanks..
>  > > > > 
>  > > > > > 
>  > > > > > > 
>  > > > > > > 
>  > > > > > > And as I was copying the above, this one came in...
>  > > > > > > 
>  > > > > > > Raw Audit Messages :
>  > > > > > > 
>  > > > > > > node=troodos.org.uk type=AVC
> msg=audit(1270680011.472:45102): avc: denied { dac_override } for pid=952
> comm="mlogc" capability=1 scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=capability 
>  > > > > > > node=troodos.org.uk type=SYSCALL
> msg=audit(1270680011.472:45102): arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170
> a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952 auid=4294967295 uid=0 gid=0 euid=0 suid=0
> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc"
> exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  > > > > > > 
>  > > > > > > 
>  > > > > > 
>  > > > > > The above means that root/mlogc is overriding traditional
> security. For example accessing a location not owned by root. We should figure out which
> location it is that mlogc tries to access that is not owned by root. Once we determine
> this, we can make the right security decision.
>  > > > > > 
>  > > > > > 
>  > > > > > Now we are getting into the harder aspect of writing policy. 
>  > > > > > Writing a template for a new domain and just allowing access is
> not so hard. 
>  > > > > > What is harder is: making solid security decisions. 
>  > > > > > 
>  > > > > > 
>  > > > > > What is it doing
>  > > > > > why is it doing it
>  > > > > > who is doing it to who
>  > > > > > Is this a threat
>  > > > > > why is it a threat
>  > > > > > how can we neutralize it?
>  > > > > > 
>  > > > > > fun!
>  > > > > 
>  > > > > For you maybe ;)
>  > > > > 
>  > > > > OK - I hope the above helps...
>  > > > > 
>  > > > > By the way since my last message I have had another 71 AVcs - too
> many
>  > > > > to post, and doubtless many duplicates, but here is what audit2allow
> has
>  > > > > to say about them:
>  > > > > 
>  > > > > # ausearch -m AVC -ts today | audit2allow -R
>  > > > > 
>  > > > > require {
>  > > > > 	type mlogc_t;
>  > > > > 	type httpd_t;
>  > > > > 	class capability { sys_nice dac_override };
>  > > > > 	class process { setsched signal getsched };
>  > > > > 	class sem { read write create unix_write destroy };
>  > > > > }
>  > > > > 
>  > > > > #============= httpd_t ==============
>  > > > > allow httpd_t mlogc_t:process signal;
>  > > > 
>  > > > Ignore this for now, we might add it later.
>  > > > 
>  > > > > 
>  > > > > #============= mlogc_t ==============
>  > > > > allow mlogc_t self:capability { sys_nice dac_override };
>  > > > 
>  > > > Did you figure out which location not owned by root mlogc is trying to
> access?
>  > > > For the moment lets ignore these. 
>  > > > 
>  > > > > allow mlogc_t self:process { setsched getsched };
>  > > > 
>  > > > The above can be added to mlogc.te
>  > > > 
>  > > > > allow mlogc_t self:sem { read write create unix_write destroy };
>  > > > 
>  > > > Ignore for now
>  > > > 
>  > > > > files_rw_etc_files(mlogc_t)
>  > 
>  > The files_rw_etc_files(mlogc_t) is bad, if you added it, please remove it
>  
>  Nope. You didn't tell me to add it so I didn't. I only do what I'm
>  told ;)
>  
>  > 
>  > instead add the following to mlogc.te:
>  > 
>  > type mlogc_etc_t;
>  > files_config_file(mlogc_etc_t)
>  > read_files_pattern(mlogc_t, mlogc_etc_t, mlogc_etc_t)
>  > files_search_etc(mlogc_t)
>  
>  Done.
>  
>  > And add to mlogc.fc:
>  > 
>  > /etc/mlogc.conf -- gen_context(system_u:object_r:mlogc_etc_t, s0)
>  
>  Done.
>  
>  
>  > > Having done all that (including moving mlogc back to /var/log/mlogc)
>  > > these are the current AVCs (18 of them) since making the above changes:
>  > > 
>  > > # ausearch -m AVC -ts recent | audit2allow -R
>  > > 
>  > > require {
>  > > 	type var_log_t;
>  > > 	type httpd_log_t;
>  > > 	type pcscd_t;
>  > > 	type httpd_t;
>  > > 	type mlogc_t;
>  > > 	class capability dac_override;
>  > > 	class unix_stream_socket connectto;
>  > > 	class sem { read write unix_write };
>  > > 	class file { write rename unlink };
>  > > 	class dir create;
>  > > }
>  > > 
>  > > #============= httpd_t ==============
>  > > allow httpd_t httpd_log_t:file write;
>  > > allow httpd_t var_log_t:dir create;
>  > 
>  > ignore above for now
>  > 
>  > > 
>  > > #============= mlogc_t ==============
>  > > allow mlogc_t httpd_log_t:file { rename unlink };
>  > > allow mlogc_t pcscd_t:unix_stream_socket connectto;
>  > > allow mlogc_t self:capability dac_override;
>  > > allow mlogc_t self:sem { read write unix_write };
>  > > corenet_tcp_connect_generic_port(mlogc_t)
>  > 
>  > ignore above for now.
>  > 
>  > > dev_read_urand(mlogc_t)
>  > 
>  > add above to mlogc.te
>  
>  Done.
>  
>  > > files_list_tmp(mlogc_t)
>  > 
>  > ignore above for now. need to figure out why its listing tmp, what is it hoping to
> list?
>  > 
>  > > files_read_usr_symlinks(mlogc_t)
>  > 
>  > not sure why it wants the above but its harmless, so can add it to mlogc.te for now
>  
>  Done.
>  
>  > > files_rw_etc_files(mlogc_t)
>  > 
>  > This is a bug in audit2allow. We added proper rules above so ignore this.
>  > 
>  > > miscfiles_read_certs(mlogc_t)
>  > > pcscd_stream_connect(mlogc_t)
>  > 
>  > The above can be added to mlogc.te
>  
>  Done.
>  
>  
>  OK - Let's see what that brings...
>  
>  Oops:
>  # make -f /usr/share/selinux/devel/Makefile
>  Compiling targeted mlogc module
>  /usr/bin/checkmodule:  loading policy configuration from tmp/mlogc.tmp
>  mlogc.te":16:ERROR 'unknown type mlogc_etc_t' at token ';' on line
> 3828:
>  	typeattribute mlogc_etc_t etcfile;
>  #line 16
>  /usr/bin/checkmodule:  error(s) encountered while parsing configuration
>  make: *** [tmp/mlogc.mod] Error 1
>  
>  Is this the problem?
>  read_files_pattern(mlogc_t, mlogc_etc_t, mlogc_etc_t)
>  2 x mlogc_etc_t ? Should that be something else or just 1 x ?
>  
>  Here is the current mlogc.te
>  
>  # cat mlogc.te 
>  policy_module(mlogc, 1.0.3)
>  
>  type mlogc_t;
>  type mlogc_exec_t;
>  type mlogc_var_log_t;
>  
>  logging_log_file(mlogc_var_log_t);
>  logging_log_filetrans(mlogc_t, mlogc_var_log_t, { dir file })
>  application_domain(mlogc_t, mlogc_exec_t);
>  role system_r types mlogc_t;
>  permissive mlogc_t;
>  manage_dirs_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
>  manage_files_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
>  read_files_pattern(mlogc_t, mlogc_etc_t, mlogc_etc_t)
>  files_search_etc(mlogc_t)
>  files_config_file(mlogc_etc_t)
>  files_read_usr_symlinks(mlogc_t)
>  pcscd_read_pub_files(mlogc_t);
>  pcscd_stream_connect(mlogc_t)
>  miscfiles_read_localization(mlogc_t)
>  miscfiles_read_certs(mlogc_t)
>  dev_read_urand(mlogc_t)
>  #apache_manage_log(mlogc_t);
>  
>  allow mlogc_t self:tcp_socket create_socket_perms;
>  allow mlogc_t self:udp_socket create_socket_perms;
>  allow mlogc_t self:netlink_route_socket create_netlink_socket_perms;
>  allow mlogc_t self:process { setsched getsched };
>  
>  
>  
>  
>   


>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Arthur Dent]

On Thu, 2010-04-08 at 16:41 +0200, Dominick Grift wrote:

>  > 
>  > Having done all that (including moving mlogc back to /var/log/mlogc)
>  > these are the current AVCs (18 of them) since making the above 
changes:
>  > 
>  > # ausearch -m AVC -ts recent | audit2allow -R
>  > 
>  > require {
>  >     type var_log_t;
>  >     type httpd_log_t;
>  >     type pcscd_t;
>  >     type httpd_t;
>  >     type mlogc_t;
>  >     class capability dac_override;
>  >     class unix_stream_socket connectto;
>  >     class sem { read write unix_write };
>  >     class file { write rename unlink };
>  >     class dir create;
>  > }
>  > 
>  > #============= httpd_t ==============
>  > allow httpd_t httpd_log_t:file write;
>  > allow httpd_t var_log_t:dir create;
>  
>  As for above. Make sure that file in question is labelled properly. 
Again httpd_t
should not need to write to its log files. Neither should
mod_security. I also have mod_security running on a server and it does
not need to
>  write to log files (only append)
>  
>  So we may end up silencing that denial.
>  
>  As for httpd_t creating a dir in /var/log: I would like to see the 
denial. I was
expecting mlogc to create 
>  /var/log/mlogc. 

I think it's this one:

node=troodos.org.uk type=AVC msg=audit(1270732811.767:47066): avc: denied { create } for
pid=10875 comm="httpd" name="20100408"
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0
tclass=dir 
node=troodos.org.uk type=SYSCALL msg=audit(1270732811.767:47066): arch=40000003 syscall=39
success=yes exit=0 a0=2d01a70 a1=1e8 a2=84a1e4 a3=2 items=0 ppid=10852 pid=10875
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 

But if that's related to a labelling issue I just done a restorecon
on /var/log/ and I got a ton of these:

# restorecon -Rv /var/log/
restorecon reset /var/log/mlogc context
unconfined_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0
restorecon reset /var/log/mlogc/data context
unconfined_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0
restorecon reset /var/log/mlogc/data/20100321 context
unconfined_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0
... Hundreds more
restorecon reset /var/log/mlogc/data/20100326/20100326-1322 context
unconfined_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0
restorecon reset /var/log/mlogc/mlogc-error.log context
system_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0
restorecon reset /var/log/mlogc/mlogc-transaction.log context
system_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0
restorecon reset /var/log/fail2ban.log.1 context
system_u:object_r:fail2ban_log_t:s0->system_u:object_r:var_log_t:s0

When I switched back to /var/log/ I forgot to redo the restorecon.
Sorry. Is that the reason?

[Dominick Grift]

On Thu, Apr 08, 2010 at 04:08:46PM +0100, Arthur Dent wrote:
>  On Thu, 2010-04-08 at 16:41 +0200, Dominick Grift wrote:
>  
>  > > 
>  > > Having done all that (including moving mlogc back to /var/log/mlogc)
>  > > these are the current AVCs (18 of them) since making the above
>  changes:
>  > > 
>  > > # ausearch -m AVC -ts recent | audit2allow -R
>  > > 
>  > > require {
>  > >     type var_log_t;
>  > >     type httpd_log_t;
>  > >     type pcscd_t;
>  > >     type httpd_t;
>  > >     type mlogc_t;
>  > >     class capability dac_override;
>  > >     class unix_stream_socket connectto;
>  > >     class sem { read write unix_write };
>  > >     class file { write rename unlink };
>  > >     class dir create;
>  > > }
>  > > 
>  > > #============= httpd_t ==============
>  > > allow httpd_t httpd_log_t:file write;
>  > > allow httpd_t var_log_t:dir create;
>  > 
>  > As for above. Make sure that file in question is labelled properly.
>  Again httpd_t should not need to write to its log files. Neither should
>  mod_security. I also have mod_security running on a server and it does
>  not need to
>  > write to log files (only append)
>  > 
>  > So we may end up silencing that denial.
>  > 
>  > As for httpd_t creating a dir in /var/log: I would like to see the
>  denial. I was expecting mlogc to create 
>  > /var/log/mlogc.
>  
>  
>  I think it's this one:
>  
>  node=troodos.org.uk type=AVC msg=audit(1270732811.767:47066): avc: denied { create } for
> pid=10875 comm="httpd" name="20100408"
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0
> tclass=dir 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270732811.767:47066): arch=40000003
> syscall=39 success=yes exit=0 a0=2d01a70 a1=1e8 a2=84a1e4 a3=2 items=0 ppid=10852
> pid=10875 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48
> tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  But if that's related to a labelling issue I just done a restorecon
>  on /var/log/ and I got a ton of these:
>  
>  # restorecon -Rv /var/log/
>  restorecon reset /var/log/mlogc context
> unconfined_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0
>  restorecon reset /var/log/mlogc/data context
> unconfined_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0
>  restorecon reset /var/log/mlogc/data/20100321 context
> unconfined_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0
>  ... Hundreds more
>  restorecon reset /var/log/mlogc/data/20100326/20100326-1322 context
> unconfined_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0
>  restorecon reset /var/log/mlogc/mlogc-error.log context
> system_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0
>  restorecon reset /var/log/mlogc/mlogc-transaction.log context
> system_u:object_r:var_log_t:s0->system_u:object_r:mlogc_var_log_t:s0
>  restorecon reset /var/log/fail2ban.log.1 context
> system_u:object_r:fail2ban_log_t:s0->system_u:object_r:var_log_t:s0
>  
>  When I switched back to /var/log/ I forgot to redo the restorecon.
>  Sorry. Is that the reason? 
May well be , yes .
see if you can reproduce.
also restorecon /etc/mlogc.conf

>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Arthur Dent]

On Thu, 2010-04-08 at 17:24 +0200, Dominick Grift wrote:

>  > When I switched back to /var/log/ I forgot to redo the
> restorecon.
>  > Sorry. Is that the reason?
>  
>  May well be , yes .
>  see if you can reproduce.
>  also restorecon /etc/mlogc.conf 
OK - With all that done, here are the latest AVCs:

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270740296.844:47355): avc: denied { dac_override }
for pid=10883 comm="mlogc" capability=1
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0
tclass=capability 
node=troodos.org.uk type=SYSCALL msg=audit(1270740296.844:47355): arch=40000003 syscall=5
success=yes exit=6 a0=b772f170 a1=82c1 a2=1b6 a3=856 items=0 ppid=10852 pid=10883
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270740436.982:47360): avc: denied { unix_write }
for pid=10883 comm="mlogc" key=0 scontext=unconfined_u:system_r:mlogc_t:s0
tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=sem 
node=troodos.org.uk type=AVC msg=audit(1270740436.982:47360): avc: denied { read write }
for pid=10883 comm="mlogc" key=0 scontext=unconfined_u:system_r:mlogc_t:s0
tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=sem 
node=troodos.org.uk type=SYSCALL msg=audit(1270740436.982:47360): arch=40000003
syscall=117 success=yes exit=0 a0=1 a1=698012 a2=1 a3=0 items=0 ppid=10852 pid=10883
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270740436.982:47360): avc: denied { unix_write }
for pid=10883 comm="mlogc" key=0 scontext=unconfined_u:system_r:mlogc_t:s0
tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=sem 
node=troodos.org.uk type=AVC msg=audit(1270740436.982:47360): avc: denied { read write }
for pid=10883 comm="mlogc" key=0 scontext=unconfined_u:system_r:mlogc_t:s0
tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=sem 
node=troodos.org.uk type=SYSCALL msg=audit(1270740436.982:47360): arch=40000003
syscall=117 success=yes exit=0 a0=1 a1=698012 a2=1 a3=0 items=0 ppid=10852 pid=10883
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { write } for
pid=10876 comm="httpd" name="20100408" dev=sda5 ino=492622
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:mlogc_var_log_t:s0
tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { add_name } for
pid=10876 comm="httpd" name="20100408-1630"
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:mlogc_var_log_t:s0
tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { create } for
pid=10876 comm="httpd" name="20100408-1630"
scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
node=troodos.org.uk type=SYSCALL msg=audit(1270740627.436:47371): arch=40000003 syscall=39
success=yes exit=0 a0=2d01a18 a1=1e8 a2=84a1e4 a3=2d019c0 items=0 ppid=10852 pid=10876
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { write } for
pid=10876 comm="httpd" name="20100408" dev=sda5 ino=492622
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:mlogc_var_log_t:s0
tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { add_name } for
pid=10876 comm="httpd" name="20100408-1630"
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:mlogc_var_log_t:s0
tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { create } for
pid=10876 comm="httpd" name="20100408-1630"
scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
node=troodos.org.uk type=SYSCALL msg=audit(1270740627.436:47371): arch=40000003 syscall=39
success=yes exit=0 a0=2d01a18 a1=1e8 a2=84a1e4 a3=2d019c0 items=0 ppid=10852 pid=10876
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { write } for
pid=10876 comm="httpd" name="20100408" dev=sda5 ino=492622
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:mlogc_var_log_t:s0
tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { add_name } for
pid=10876 comm="httpd" name="20100408-1630"
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:mlogc_var_log_t:s0
tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { create } for
pid=10876 comm="httpd" name="20100408-1630"
scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
node=troodos.org.uk type=SYSCALL msg=audit(1270740627.436:47371): arch=40000003 syscall=39
success=yes exit=0 a0=2d01a18 a1=1e8 a2=84a1e4 a3=2d019c0 items=0 ppid=10852 pid=10876
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { write } for
pid=10876 comm="httpd" name="20100408-1630" dev=sda5 ino=496009
scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { add_name } for
pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { create } for
pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=file 
node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { write } for
pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
dev=sda5 ino=496011 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270740627.461:47372): arch=40000003 syscall=5
success=yes exit=19 a0=2d019c0 a1=8241 a2=1a0 a3=836 items=0 ppid=10852 pid=10876
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { write } for
pid=10876 comm="httpd" name="20100408-1630" dev=sda5 ino=496009
scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { add_name } for
pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { create } for
pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=file 
node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { write } for
pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
dev=sda5 ino=496011 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270740627.461:47372): arch=40000003 syscall=5
success=yes exit=19 a0=2d019c0 a1=8241 a2=1a0 a3=836 items=0 ppid=10852 pid=10876
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { write } for
pid=10876 comm="httpd" name="20100408-1630" dev=sda5 ino=496009
scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { add_name } for
pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { create } for
pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=file 
node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { write } for
pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
dev=sda5 ino=496011 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270740627.461:47372): arch=40000003 syscall=5
success=yes exit=19 a0=2d019c0 a1=8241 a2=1a0 a3=836 items=0 ppid=10852 pid=10876
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 


Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { write } for
pid=10876 comm="httpd" name="20100408-1630" dev=sda5 ino=496009
scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { add_name } for
pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { create } for
pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=file 
node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { write } for
pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
dev=sda5 ino=496011 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1270740627.461:47372): arch=40000003 syscall=5
success=yes exit=19 a0=2d019c0 a1=8241 a2=1a0 a3=836 items=0 ppid=10852 pid=10876
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 


# ausearch -m AVC -ts recent | audit2allow -R

require {
	type mlogc_var_log_t;
	type mlogc_t;
	type httpd_t;
	class capability dac_override;
	class sem { read write unix_write };
	class dir { write create add_name };
	class file { write create };
}

#============= httpd_t ==============
allow httpd_t mlogc_var_log_t:dir { write create add_name };
allow httpd_t mlogc_var_log_t:file { write create };

#============= mlogc_t ==============
allow mlogc_t self:capability dac_override;
allow mlogc_t self:sem { read write unix_write };
[root@troodos mlogc]# restorecon /etc/mlogc.conf

[Dominick Grift]

On Thu, Apr 08, 2010 at 04:53:59PM +0100, Arthur Dent wrote:
>  On Thu, 2010-04-08 at 17:24 +0200, Dominick Grift wrote:
>  
>  > > When I switched back to /var/log/ I forgot to redo the restorecon.
>  > > Sorry. Is that the reason?
>  > 
>  > May well be , yes .
>  > see if you can reproduce.
>  > also restorecon /etc/mlogc.conf
>  
>  OK - With all that done, here are the latest AVCs:
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270740296.844:47355): avc: denied { dac_override
> } for pid=10883 comm="mlogc" capability=1
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0
> tclass=capability 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270740296.844:47355): arch=40000003 syscall=5
> success=yes exit=6 a0=b772f170 a1=82c1 a2=1b6 a3=856 items=0 ppid=10852 pid=10883
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270740436.982:47360): avc: denied { unix_write }
> for pid=10883 comm="mlogc" key=0 scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=sem 
>  node=troodos.org.uk type=AVC msg=audit(1270740436.982:47360): avc: denied { read write }
> for pid=10883 comm="mlogc" key=0 scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=sem 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270740436.982:47360): arch=40000003
> syscall=117 success=yes exit=0 a0=1 a1=698012 a2=1 a3=0 items=0 ppid=10852 pid=10883
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270740436.982:47360): avc: denied { unix_write }
> for pid=10883 comm="mlogc" key=0 scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=sem 
>  node=troodos.org.uk type=AVC msg=audit(1270740436.982:47360): avc: denied { read write }
> for pid=10883 comm="mlogc" key=0 scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=sem 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270740436.982:47360): arch=40000003
> syscall=117 success=yes exit=0 a0=1 a1=698012 a2=1 a3=0 items=0 ppid=10852 pid=10883
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { write } for
> pid=10876 comm="httpd" name="20100408" dev=sda5 ino=492622
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:mlogc_var_log_t:s0
> tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { add_name }
> for pid=10876 comm="httpd" name="20100408-1630"
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:mlogc_var_log_t:s0
> tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { create } for
> pid=10876 comm="httpd" name="20100408-1630"
> scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270740627.436:47371): arch=40000003
> syscall=39 success=yes exit=0 a0=2d01a18 a1=1e8 a2=84a1e4 a3=2d019c0 items=0 ppid=10852
> pid=10876 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48
> tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { write } for
> pid=10876 comm="httpd" name="20100408" dev=sda5 ino=492622
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:mlogc_var_log_t:s0
> tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { add_name }
> for pid=10876 comm="httpd" name="20100408-1630"
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:mlogc_var_log_t:s0
> tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { create } for
> pid=10876 comm="httpd" name="20100408-1630"
> scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270740627.436:47371): arch=40000003
> syscall=39 success=yes exit=0 a0=2d01a18 a1=1e8 a2=84a1e4 a3=2d019c0 items=0 ppid=10852
> pid=10876 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48
> tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { write } for
> pid=10876 comm="httpd" name="20100408" dev=sda5 ino=492622
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:mlogc_var_log_t:s0
> tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { add_name }
> for pid=10876 comm="httpd" name="20100408-1630"
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:mlogc_var_log_t:s0
> tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.436:47371): avc: denied { create } for
> pid=10876 comm="httpd" name="20100408-1630"
> scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270740627.436:47371): arch=40000003
> syscall=39 success=yes exit=0 a0=2d01a18 a1=1e8 a2=84a1e4 a3=2d019c0 items=0 ppid=10852
> pid=10876 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48
> tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { write } for
> pid=10876 comm="httpd" name="20100408-1630" dev=sda5 ino=496009
> scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { add_name }
> for pid=10876 comm="httpd"
> name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
> scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { create } for
> pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
> scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=file 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { write } for
> pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
> dev=sda5 ino=496011 scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270740627.461:47372): arch=40000003 syscall=5
> success=yes exit=19 a0=2d019c0 a1=8241 a2=1a0 a3=836 items=0 ppid=10852 pid=10876
> auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
> ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { write } for
> pid=10876 comm="httpd" name="20100408-1630" dev=sda5 ino=496009
> scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { add_name }
> for pid=10876 comm="httpd"
> name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
> scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { create } for
> pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
> scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=file 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { write } for
> pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
> dev=sda5 ino=496011 scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270740627.461:47372): arch=40000003 syscall=5
> success=yes exit=19 a0=2d019c0 a1=8241 a2=1a0 a3=836 items=0 ppid=10852 pid=10876
> auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
> ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { write } for
> pid=10876 comm="httpd" name="20100408-1630" dev=sda5 ino=496009
> scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { add_name }
> for pid=10876 comm="httpd"
> name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
> scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { create } for
> pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
> scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=file 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { write } for
> pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
> dev=sda5 ino=496011 scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270740627.461:47372): arch=40000003 syscall=5
> success=yes exit=19 a0=2d019c0 a1=8241 a2=1a0 a3=836 items=0 ppid=10852 pid=10876
> auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
> ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { write } for
> pid=10876 comm="httpd" name="20100408-1630" dev=sda5 ino=496009
> scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { add_name }
> for pid=10876 comm="httpd"
> name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
> scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { create } for
> pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
> scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=file 
>  node=troodos.org.uk type=AVC msg=audit(1270740627.461:47372): avc: denied { write } for
> pid=10876 comm="httpd" name="20100408-163027-S732jFIrkOUAACp8YkEAAAAB"
> dev=sda5 ino=496011 scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:mlogc_var_log_t:s0 tclass=file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270740627.461:47372): arch=40000003 syscall=5
> success=yes exit=19 a0=2d019c0 a1=8241 a2=1a0 a3=836 items=0 ppid=10852 pid=10876
> auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
> ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  
>  # ausearch -m AVC -ts recent | audit2allow -R
>  
>  require {
>  	type mlogc_var_log_t;
>  	type mlogc_t;
>  	type httpd_t;
>  	class capability dac_override;
>  	class sem { read write unix_write };
>  	class dir { write create add_name };
>  	class file { write create };
>  }
>  
>  #============= httpd_t ==============
>  allow httpd_t mlogc_var_log_t:dir { write create add_name };
>  allow httpd_t mlogc_var_log_t:file { write create }; 
Alright lets try and wrap this up. So heat mod_security(httpd_t) wants to manage mlogc log
files.
We (mlogc) should facilitate this interaction.

That means we should create an "mlogc_manage_log" interface in our mlogc.if
file, and call that interface for httpd_t in our myapache.te file.

I am going to ignore the fact that it is writing to the logfile. This might be a bug in
mod_security or mlogc but we'll just allow it.

Add this to mlogc.if:

########################################
## <summary>
##	Manage mlogc log content.
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`mlogc_manage_log',`
	gen_require(`
		type mlogc_var_log_t;
	')

	logging_search_logs($1)
	manage_dirs_pattern($1, mlogc_var_log_t, mlogc_var_log_t)
	manage_files_pattern($1, mlogc_var_log_t, mlogc_var_log_t)
	read_lnk_files_pattern($1, mlogc_var_log_t, mlogc_var_log_t)
')

Next: in myapache.te call the interface for httpd_t:

mlogc_manage_log(httpd_t)

>  
>  #============= mlogc_t ==============
>  allow mlogc_t self:capability dac_override;
>  allow mlogc_t self:sem { read write unix_write }; 
Add the following to mlogc.te:

allow mlogc_t self:capability { sys_nice dac_override };
allow mlogc_t self:sem rw_sem_perms;

>  [root@troodos mlogc]# restorecon /etc/mlogc.conf
>  
>   
We still havent figured out why it needs dac_override but oh well..
Also seems it does not want to list /tmp anymore?



>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Arthur Dent]

On Thu, 2010-04-08 at 18:10 +0200, Dominick Grift wrote:

>  Alright lets try and wrap this up.  
[snipped lots of stuff to wrap things up]

Well Dominick, I triggered a Mod-Sec alert nearly 20 minutes ago and so
far (touching wood here) there are no reported AVCs!

Thank you so much for all the effort you put into this. I realise that
this in in addition to your daily workload so I am full of gratitude.

Feeling guilty that I have consumed so much of your time rather
selfishly, I was wondering if this work could be used by other than just
me?

Although the ModSecurity-Console is is not from a Fedora RPM, a large
part of what we (you) dealt with is the interaction between mod-security
and mlogc, which (in my case at least) were installed from Fedora RPMs.

I don't know if the package maintainer for that RPM is on this list, but
could this policy be applied to that package? Or could some of this find
its way into general SEL policy?

Anyhow...

I guess the only thing remaining (if it all stays quiet) is to remove
the "permissive mlogc_t;" directive from mlogc.te and put the system
back into Enforcing mode?

Thanks again?

I'm not even sure what time zone you're in, but if you're ever in London
I'll buy you a pint!

Cheers!

Mark

[Dominick Grift]

On Thu, Apr 08, 2010 at 06:15:37PM +0100, Arthur Dent wrote:
>  On Thu, 2010-04-08 at 18:10 +0200, Dominick Grift wrote:
>  
>  > Alright lets try and wrap this up. 
>  
>  [snipped lots of stuff to wrap things up]
>  
>  Well Dominick, I triggered a Mod-Sec alert nearly 20 minutes ago and so
>  far (touching wood here) there are no reported AVCs!
>  
>  Thank you so much for all the effort you put into this. I realise that
>  this in in addition to your daily workload so I am full of gratitude.
>  
>  Feeling guilty that I have consumed so much of your time rather
>  selfishly, I was wondering if this work could be used by other than just
>  me?
>  
>  Although the ModSecurity-Console is is not from a Fedora RPM, a large
>  part of what we (you) dealt with is the interaction between mod-security
>  and mlogc, which (in my case at least) were installed from Fedora RPMs.
>  
>  I don't know if the package maintainer for that RPM is on this list, but
>  could this policy be applied to that package? Or could some of this find
>  its way into general SEL policy? 
I am not sure if submitting this upstream will result in adoption.

But this thread serves as an example for other to gain some insight in policy development
fundamentals in the maillist archives. So other then that i was able to help you it was
also worth my while from that point of view.

Besides i like doing this, and so i enjoyed it.

SELinux is a framework and policy is configuration data. Writing policy could be like
maintaining an iptables configuration albeit a bit more complex.

So policy is often a matter of personal preference and often there is no one size fits
all.

So i will leave the decision about whether or not to share the policy forward or submit it
upstream to you.
>  
>  Anyhow...
>  
>  I guess the only thing remaining (if it all stays quiet) is to remove
>  the "permissive mlogc_t;" directive from mlogc.te and put the system
>  back into Enforcing mode?
>  
>  Thanks again?
>  
>  I'm not even sure what time zone you're in, but if you're ever in London
>  I'll buy you a pint! 
I am in Netherlands, but i will drink one on our success. Cheers!
>  
>  Cheers!
>  
>  Mark
>  
>   


>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Arthur Dent]

On Thu, 2010-04-08 at 19:35 +0200, Dominick Grift wrote:
>  On Thu, Apr 08, 2010 at 06:15:37PM +0100, Arthur Dent wrote:
>  > On Thu, 2010-04-08 at 18:10 +0200, Dominick Grift wrote:
>  > 
>  > > Alright lets try and wrap this up. 
>  > 
>  > [snipped lots of stuff to wrap things up]
>  > 
>  > Well Dominick, I triggered a Mod-Sec alert nearly 20 minutes ago and so
>  > far (touching wood here) there are no reported AVCs!
>  >  
Spoke too soon!...

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270750990.203:47741): avc: denied { signal } for
pid=10852 comm="httpd" scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=process 
node=troodos.org.uk type=SYSCALL msg=audit(1270750990.203:47741): arch=40000003 syscall=37
success=yes exit=0 a0=ffffd59c a1=f a2=9b6ff4 a3=1 items=0 ppid=1 pid=10852
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270750996.408:47742): avc: denied { destroy } for
pid=10884 comm="mlogc" key=0 scontext=unconfined_u:system_r:mlogc_t:s0
tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=sem 
node=troodos.org.uk type=SYSCALL msg=audit(1270750996.408:47742): arch=40000003
syscall=117 success=yes exit=0 a0=3 a1=698012 a2=0 a3=100 items=0 ppid=10852 pid=10884
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 


Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270751004.197:47743): avc: denied { read write }
for pid=14112 comm="mlogc" name="1" dev=devpts ino=4
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0
tclass=chr_file 
node=troodos.org.uk type=SYSCALL msg=audit(1270751004.197:47743): arch=40000003 syscall=11
success=yes exit=0 a0=9dd3288 a1=9dd32b8 a2=9dd2900 a3=9dd32b8 items=0 ppid=14111
pid=14112 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270751009.399:47744): avc: denied { create } for
pid=14112 comm="mlogc" key=0 scontext=unconfined_u:system_r:mlogc_t:s0
tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=sem 
node=troodos.org.uk type=SYSCALL msg=audit(1270751009.399:47744): arch=40000003
syscall=117 success=yes exit=7143448 a0=2 a1=0 a2=1 a3=380 items=0 ppid=1 pid=14112
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null)

[Dominick Grift]

On Thu, Apr 08, 2010 at 07:30:04PM +0100, Arthur Dent wrote:
>  On Thu, 2010-04-08 at 19:35 +0200, Dominick Grift wrote:
>  > On Thu, Apr 08, 2010 at 06:15:37PM +0100, Arthur Dent wrote:
>  > > On Thu, 2010-04-08 at 18:10 +0200, Dominick Grift wrote:
>  > > 
>  > > > Alright lets try and wrap this up. 
>  > > 
>  > > [snipped lots of stuff to wrap things up]
>  > > 
>  > > Well Dominick, I triggered a Mod-Sec alert nearly 20 minutes ago and so
>  > > far (touching wood here) there are no reported AVCs!
>  > > 
>  
>  Spoke too soon!...
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270750990.203:47741): avc: denied { signal } for
> pid=10852 comm="httpd" scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=process 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270750990.203:47741): arch=40000003
> syscall=37 success=yes exit=0 a0=ffffd59c a1=f a2=9b6ff4 a3=1 items=0 ppid=1 pid=10852
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null)  
in mlogc.if:

#######################################
## <summary>
##	Send a generic signal to MLOGC.
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`mlogc_signal',`
	gen_require(`
		type mlogc_t;
	')

	allow $1 mlogc_t:process signal;
')

in myapache.te:

mlogc_signal(httpd_t)

>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270750996.408:47742): avc: denied { destroy } for
> pid=10884 comm="mlogc" key=0 scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=sem 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270750996.408:47742): arch=40000003
> syscall=117 success=yes exit=0 a0=3 a1=698012 a2=0 a3=100 items=0 ppid=10852 pid=10884
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null)  
mlogc.te:

instead of rw_sem_perms use create_sem_perms.

>  
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270751004.197:47743): avc: denied { read write }
> for pid=14112 comm="mlogc" name="1" dev=devpts ino=4
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0
> tclass=chr_file 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270751004.197:47743): arch=40000003
> syscall=11 success=yes exit=0 a0=9dd3288 a1=9dd32b8 a2=9dd2900 a3=9dd32b8 items=0
> ppid=14111 pid=14112 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> fsgid=0 tty=pts1 ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null)  
mlogc.te:

userdom_use_user_terminals(mlogc_t)

>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270751009.399:47744): avc: denied { create } for
> pid=14112 comm="mlogc" key=0 scontext=unconfined_u:system_r:mlogc_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=sem 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270751009.399:47744): arch=40000003
> syscall=117 success=yes exit=7143448 a0=2 a1=0 a2=1 a3=380 items=0 ppid=1 pid=14112
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>   
mlogc.te:

instead of rw_sem_perms use create_sem_perms.


>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Arthur Dent]

Hi Dominick,

Still not quite there yet...

(Apologies if there are duplicates here):

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270762877.688:48174): avc: denied { signal } for
pid=14587 comm="httpd" scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=process 
node=troodos.org.uk type=SYSCALL msg=audit(1270762877.688:48174): arch=40000003 syscall=37
success=yes exit=0 a0=ffffc705 a1=f a2=2b9ff4 a3=1 items=0 ppid=1 pid=14587
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270762931.148:48179): avc: denied { getattr } for
pid=15736 comm="mlogc" path="/etc/passwd" dev=sda5 ino=1233517
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file

node=troodos.org.uk type=SYSCALL msg=audit(1270762931.148:48179): arch=40000003
syscall=195 success=yes exit=0 a0=8c43fe a1=b64133dc a2=d1eff4 a3=3 items=0 ppid=15707
pid=15736 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270762931.150:48180): avc: denied { read } for
pid=15736 comm="mlogc" name="passwd" dev=sda5 ino=1233517
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file

node=troodos.org.uk type=AVC msg=audit(1270762931.150:48180): avc: denied { open } for
pid=15736 comm="mlogc" name="passwd" dev=sda5 ino=1233517
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file

node=troodos.org.uk type=SYSCALL msg=audit(1270762931.150:48180): arch=40000003 syscall=5
success=yes exit=8 a0=8c43fe a1=0 a2=1b6 a3=8d15aa items=0 ppid=15707 pid=15736
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270762931.150:48180): avc: denied { read } for
pid=15736 comm="mlogc" name="passwd" dev=sda5 ino=1233517
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file

node=troodos.org.uk type=AVC msg=audit(1270762931.150:48180): avc: denied { open } for
pid=15736 comm="mlogc" name="passwd" dev=sda5 ino=1233517
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file

node=troodos.org.uk type=SYSCALL msg=audit(1270762931.150:48180): arch=40000003 syscall=5
success=yes exit=8 a0=8c43fe a1=0 a2=1b6 a3=8d15aa items=0 ppid=15707 pid=15736
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270762931.153:48181): avc: denied { read } for
pid=15736 comm="mlogc" name="tmp" dev=sda5 ino=820801
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270762931.153:48181): avc: denied { open } for
pid=15736 comm="mlogc" name="tmp" dev=sda5 ino=820801
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir 
node=troodos.org.uk type=SYSCALL msg=audit(1270762931.153:48181): arch=40000003 syscall=5
success=yes exit=8 a0=8c4437 a1=0 a2=1b6 a3=8d15aa items=0 ppid=15707 pid=15736
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270762931.153:48181): avc: denied { read } for
pid=15736 comm="mlogc" name="tmp" dev=sda5 ino=820801
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270762931.153:48181): avc: denied { open } for
pid=15736 comm="mlogc" name="tmp" dev=sda5 ino=820801
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir 
node=troodos.org.uk type=SYSCALL msg=audit(1270762931.153:48181): arch=40000003 syscall=5
success=yes exit=8 a0=8c4437 a1=0 a2=1b6 a3=8d15aa items=0 ppid=15707 pid=15736
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270763183.873:48186): avc: denied { signal } for
pid=15707 comm="httpd" scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=process 
node=troodos.org.uk type=SYSCALL msg=audit(1270763183.873:48186): arch=40000003 syscall=37
success=yes exit=0 a0=ffffc2a5 a1=f a2=7ddff4 a3=1 items=0 ppid=1 pid=15707
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 


Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270763457.339:48197): avc: denied { signal } for
pid=15806 comm="httpd" scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=process 
node=troodos.org.uk type=SYSCALL msg=audit(1270763457.339:48197): arch=40000003 syscall=37
success=yes exit=0 a0=ffffc242 a1=f a2=5bdff4 a3=1 items=0 ppid=1 pid=15806
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=unconfined_u:system_r:httpd_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270763495.89:48202): avc: denied { getattr } for
pid=15903 comm="mlogc" path="/etc/passwd" dev=sda5 ino=1233517
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file

node=troodos.org.uk type=SYSCALL msg=audit(1270763495.89:48202): arch=40000003 syscall=195
success=yes exit=0 a0=aee3fe a1=b63bb3dc a2=27bff4 a3=3 items=0 ppid=15881 pid=15903
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270763495.104:48203): avc: denied { read } for
pid=15903 comm="mlogc" name="passwd" dev=sda5 ino=1233517
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file

node=troodos.org.uk type=AVC msg=audit(1270763495.104:48203): avc: denied { open } for
pid=15903 comm="mlogc" name="passwd" dev=sda5 ino=1233517
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file

node=troodos.org.uk type=SYSCALL msg=audit(1270763495.104:48203): arch=40000003 syscall=5
success=yes exit=8 a0=aee3fe a1=0 a2=1b6 a3=afb5aa items=0 ppid=15881 pid=15903
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270763495.104:48203): avc: denied { read } for
pid=15903 comm="mlogc" name="passwd" dev=sda5 ino=1233517
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file

node=troodos.org.uk type=AVC msg=audit(1270763495.104:48203): avc: denied { open } for
pid=15903 comm="mlogc" name="passwd" dev=sda5 ino=1233517
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file

node=troodos.org.uk type=SYSCALL msg=audit(1270763495.104:48203): arch=40000003 syscall=5
success=yes exit=8 a0=aee3fe a1=0 a2=1b6 a3=afb5aa items=0 ppid=15881 pid=15903
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270763495.107:48204): avc: denied { read } for
pid=15903 comm="mlogc" name="tmp" dev=sda5 ino=820801
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270763495.107:48204): avc: denied { open } for
pid=15903 comm="mlogc" name="tmp" dev=sda5 ino=820801
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir 
node=troodos.org.uk type=SYSCALL msg=audit(1270763495.107:48204): arch=40000003 syscall=5
success=yes exit=8 a0=aee437 a1=0 a2=1b6 a3=afb5aa items=0 ppid=15881 pid=15903
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270763495.107:48204): avc: denied { read } for
pid=15903 comm="mlogc" name="tmp" dev=sda5 ino=820801
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir 
node=troodos.org.uk type=AVC msg=audit(1270763495.107:48204): avc: denied { open } for
pid=15903 comm="mlogc" name="tmp" dev=sda5 ino=820801
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir 
node=troodos.org.uk type=SYSCALL msg=audit(1270763495.107:48204): arch=40000003 syscall=5
success=yes exit=8 a0=aee437 a1=0 a2=1b6 a3=afb5aa items=0 ppid=15881 pid=15903
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270780538.4:48826): avc: denied { signal } for
pid=24426 comm="httpd" scontext=system_u:system_r:httpd_t:s0-s0:c0.c1023
tcontext=system_u:system_r:mlogc_t:s0-s0:c0.c1023 tclass=process 
node=troodos.org.uk type=SYSCALL msg=audit(1270780538.4:48826): arch=40000003 syscall=37
success=yes exit=0 a0=5f6c a1=f a2=3851e4 a3=13ea018 items=0 ppid=24425 pid=24426 auid=0
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3072
comm="httpd" exe="/usr/sbin/httpd"
subj=system_u:system_r:httpd_t:s0-s0:c0.c1023 key=(null) 

# cat avcs | audit2allow -R

require {
	type httpd_t;
	type mlogc_t;
	class process signal;
}

#============= httpd_t ==============
allow httpd_t mlogc_t:process signal;

#============= mlogc_t ==============
files_list_tmp(mlogc_t)
files_rw_etc_files(mlogc_t)

[Dominick Grift]

On Fri, Apr 09, 2010 at 08:13:41AM +0100, Arthur Dent wrote:
>  Hi Dominick,
>  
>  Still not quite there yet...
>  
>  (Apologies if there are duplicates here):
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270762877.688:48174): avc: denied { signal } for
> pid=14587 comm="httpd" scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=process 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270762877.688:48174): arch=40000003
> syscall=37 success=yes exit=0 a0=ffffc705 a1=f a2=2b9ff4 a3=1 items=0 ppid=1 pid=14587
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270762931.148:48179): avc: denied { getattr } for
> pid=15736 comm="mlogc" path="/etc/passwd" dev=sda5 ino=1233517
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
>
>  node=troodos.org.uk type=SYSCALL msg=audit(1270762931.148:48179): arch=40000003
> syscall=195 success=yes exit=0 a0=8c43fe a1=b64133dc a2=d1eff4 a3=3 items=0 ppid=15707
> pid=15736 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270762931.150:48180): avc: denied { read } for
> pid=15736 comm="mlogc" name="passwd" dev=sda5 ino=1233517
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
>
>  node=troodos.org.uk type=AVC msg=audit(1270762931.150:48180): avc: denied { open } for
> pid=15736 comm="mlogc" name="passwd" dev=sda5 ino=1233517
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
>
>  node=troodos.org.uk type=SYSCALL msg=audit(1270762931.150:48180): arch=40000003 syscall=5
> success=yes exit=8 a0=8c43fe a1=0 a2=1b6 a3=8d15aa items=0 ppid=15707 pid=15736
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270762931.150:48180): avc: denied { read } for
> pid=15736 comm="mlogc" name="passwd" dev=sda5 ino=1233517
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
>
>  node=troodos.org.uk type=AVC msg=audit(1270762931.150:48180): avc: denied { open } for
> pid=15736 comm="mlogc" name="passwd" dev=sda5 ino=1233517
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
>
>  node=troodos.org.uk type=SYSCALL msg=audit(1270762931.150:48180): arch=40000003 syscall=5
> success=yes exit=8 a0=8c43fe a1=0 a2=1b6 a3=8d15aa items=0 ppid=15707 pid=15736
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270762931.153:48181): avc: denied { read } for
> pid=15736 comm="mlogc" name="tmp" dev=sda5 ino=820801
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270762931.153:48181): avc: denied { open } for
> pid=15736 comm="mlogc" name="tmp" dev=sda5 ino=820801
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270762931.153:48181): arch=40000003 syscall=5
> success=yes exit=8 a0=8c4437 a1=0 a2=1b6 a3=8d15aa items=0 ppid=15707 pid=15736
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270762931.153:48181): avc: denied { read } for
> pid=15736 comm="mlogc" name="tmp" dev=sda5 ino=820801
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270762931.153:48181): avc: denied { open } for
> pid=15736 comm="mlogc" name="tmp" dev=sda5 ino=820801
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270762931.153:48181): arch=40000003 syscall=5
> success=yes exit=8 a0=8c4437 a1=0 a2=1b6 a3=8d15aa items=0 ppid=15707 pid=15736
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270763183.873:48186): avc: denied { signal } for
> pid=15707 comm="httpd" scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=process 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270763183.873:48186): arch=40000003
> syscall=37 success=yes exit=0 a0=ffffc2a5 a1=f a2=7ddff4 a3=1 items=0 ppid=1 pid=15707
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270763457.339:48197): avc: denied { signal } for
> pid=15806 comm="httpd" scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=process 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270763457.339:48197): arch=40000003
> syscall=37 success=yes exit=0 a0=ffffc242 a1=f a2=5bdff4 a3=1 items=0 ppid=1 pid=15806
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270763495.89:48202): avc: denied { getattr } for
> pid=15903 comm="mlogc" path="/etc/passwd" dev=sda5 ino=1233517
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
>
>  node=troodos.org.uk type=SYSCALL msg=audit(1270763495.89:48202): arch=40000003
> syscall=195 success=yes exit=0 a0=aee3fe a1=b63bb3dc a2=27bff4 a3=3 items=0 ppid=15881
> pid=15903 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270763495.104:48203): avc: denied { read } for
> pid=15903 comm="mlogc" name="passwd" dev=sda5 ino=1233517
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
>
>  node=troodos.org.uk type=AVC msg=audit(1270763495.104:48203): avc: denied { open } for
> pid=15903 comm="mlogc" name="passwd" dev=sda5 ino=1233517
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
>
>  node=troodos.org.uk type=SYSCALL msg=audit(1270763495.104:48203): arch=40000003 syscall=5
> success=yes exit=8 a0=aee3fe a1=0 a2=1b6 a3=afb5aa items=0 ppid=15881 pid=15903
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270763495.104:48203): avc: denied { read } for
> pid=15903 comm="mlogc" name="passwd" dev=sda5 ino=1233517
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
>
>  node=troodos.org.uk type=AVC msg=audit(1270763495.104:48203): avc: denied { open } for
> pid=15903 comm="mlogc" name="passwd" dev=sda5 ino=1233517
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
>
>  node=troodos.org.uk type=SYSCALL msg=audit(1270763495.104:48203): arch=40000003 syscall=5
> success=yes exit=8 a0=aee3fe a1=0 a2=1b6 a3=afb5aa items=0 ppid=15881 pid=15903
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270763495.107:48204): avc: denied { read } for
> pid=15903 comm="mlogc" name="tmp" dev=sda5 ino=820801
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270763495.107:48204): avc: denied { open } for
> pid=15903 comm="mlogc" name="tmp" dev=sda5 ino=820801
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270763495.107:48204): arch=40000003 syscall=5
> success=yes exit=8 a0=aee437 a1=0 a2=1b6 a3=afb5aa items=0 ppid=15881 pid=15903
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270763495.107:48204): avc: denied { read } for
> pid=15903 comm="mlogc" name="tmp" dev=sda5 ino=820801
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir 
>  node=troodos.org.uk type=AVC msg=audit(1270763495.107:48204): avc: denied { open } for
> pid=15903 comm="mlogc" name="tmp" dev=sda5 ino=820801
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270763495.107:48204): arch=40000003 syscall=5
> success=yes exit=8 a0=aee437 a1=0 a2=1b6 a3=afb5aa items=0 ppid=15881 pid=15903
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270780538.4:48826): avc: denied { signal } for
> pid=24426 comm="httpd" scontext=system_u:system_r:httpd_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:mlogc_t:s0-s0:c0.c1023 tclass=process 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270780538.4:48826): arch=40000003 syscall=37
> success=yes exit=0 a0=5f6c a1=f a2=3851e4 a3=13ea018 items=0 ppid=24425 pid=24426 auid=0
> uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3072
> comm="httpd" exe="/usr/sbin/httpd"
> subj=system_u:system_r:httpd_t:s0-s0:c0.c1023 key=(null) 
>  
>  # cat avcs | audit2allow -R
>  
>  require {
>  	type httpd_t;
>  	type mlogc_t;
>  	class process signal;
>  }
>  
>  #============= httpd_t ==============
>  allow httpd_t mlogc_t:process signal; 
This should have been allowed when we created mlogc_signal() in mlogc.if, and called
mlogc_signal(httpd_t) in myapache.te  as i suggested in my previous message.

Make sure that after you 've added this policy, that you rebuild and reinstall both
myapache and mlogc modules:

make -f /usr/share/selinux/devel/Makefile
sudo semodule -i *.pp

>  
>  #============= mlogc_t ==============
>  files_list_tmp(mlogc_t) 
Above can be added.

>  files_rw_etc_files(mlogc_t) 
This is a bug in audit2allow -R: mlogc_t want to read /etc/passwd.
Add the following to your mlogc.te to allow it:

files_read_etc_files(mlogc_t)

>  
>   


>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Arthur Dent]

Hi Dominick,

I'm sorry to bother you again, but everything seems to be going just
fine since the last lot of policy updates, so I decided to move into the
next phase of my project.

You're going to hate me for this...

What I have is a Mod-Sec rule that detects a particular kind of attack;
when detected it identifies the IP address of the attacker and (using
the modsec "exec" function) passes this to a script.

During our recent exchange I was using this rule for testing, but for
now all the script does is write the IP address into a file. (This
worked by the way).

Now for the next part. Instead of writing it to a file I want to ban the
IP in iptables using a feature of the fail2ban application which I also
have running on this machine.

The script uses the following command:
fail2ban-client set modsec banip $IP
touch -c /var/log/httpd/modsec_audit.log

where $IP is the IP address passes from mod-sec, the "banip" is a
argument of the fail2ban-client app which initiates a manual banning of
the IP and "modsec" is the name of the "jail" (in fail2ban parlance)
to
be activated for this IP.

The "touch" command is necessary to trick fail2ban into thinking that
the log file it is monitoring has been updated and thus needs to wake
itself and take action.

Putting all this together now gives me this (single) avc when testing:

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270821681.36:50303): avc: denied { search } for
pid=30224 comm="fail2ban-client" name="fail2ban" dev=sda5 ino=476186
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:fail2ban_var_run_t:s0
tclass=dir 
node=troodos.org.uk type=SYSCALL msg=audit(1270821681.36:50303): arch=40000003 syscall=102
success=no exit=-13 a0=3 a1=bfa9b0e0 a2=b6810c a3=b76fb2c8 items=0 ppid=30222 pid=30224
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
ses=4294967295 comm="fail2ban-client" exe="/usr/bin/python"
subj=unconfined_u:system_r:httpd_t:s0 key=(null)

How best to handle this?

I am writing this from behind the sofa, out of range of beer bottles
hurled from the Netherlands.

Thanks!

Mark

[Dominick Grift]

On Fri, Apr 09, 2010 at 03:23:34PM +0100, Arthur Dent wrote:
>  Hi Dominick,
>  
>  I'm sorry to bother you again, but everything seems to be going just
>  fine since the last lot of policy updates, so I decided to move into the
>  next phase of my project.
>  
>  You're going to hate me for this...
>  
>  What I have is a Mod-Sec rule that detects a particular kind of attack;
>  when detected it identifies the IP address of the attacker and (using
>  the modsec "exec" function) passes this to a script.
>  
>  During our recent exchange I was using this rule for testing, but for
>  now all the script does is write the IP address into a file. (This
>  worked by the way).
>  
>  Now for the next part. Instead of writing it to a file I want to ban the
>  IP in iptables using a feature of the fail2ban application which I also
>  have running on this machine.
>  
>  The script uses the following command:
>  fail2ban-client set modsec banip $IP
>  touch -c /var/log/httpd/modsec_audit.log
>  
>  where $IP is the IP address passes from mod-sec, the "banip" is a
>  argument of the fail2ban-client app which initiates a manual banning of
>  the IP and "modsec" is the name of the "jail" (in fail2ban parlance)
> to
>  be activated for this IP.
>  
>  The "touch" command is necessary to trick fail2ban into thinking that
>  the log file it is monitoring has been updated and thus needs to wake
>  itself and take action.
>  
>  Putting all this together now gives me this (single) avc when testing:
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1270821681.36:50303): avc: denied { search } for
> pid=30224 comm="fail2ban-client" name="fail2ban" dev=sda5 ino=476186
> scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:fail2ban_var_run_t:s0
> tclass=dir 
>  node=troodos.org.uk type=SYSCALL msg=audit(1270821681.36:50303): arch=40000003
> syscall=102 success=no exit=-13 a0=3 a1=bfa9b0e0 a2=b6810c a3=b76fb2c8 items=0 ppid=30222
> pid=30224 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48
> tty=(none) ses=4294967295 comm="fail2ban-client" exe="/usr/bin/python"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null)
>  
>  How best to handle this? 
I am not sure if i understand how that goes. From the avc denials above i can tell that
fail2ban-client runs in the httpd_t domain. That means mlogc is not running it but some
process in the httpd_t domain.

What runs the script?


>  
>  I am writing this from behind the sofa, out of range of beer bottles
>  hurled from the Netherlands.
>  
>  Thanks!
>  
>  Mark
>  
>  
>  
>   


>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Arthur Dent]

On Fri, 2010-04-09 at 17:10 +0200, Dominick Grift wrote:
>  On Fri, Apr 09, 2010 at 03:23:34PM +0100, Arthur Dent wrote:
>  > Hi Dominick,
>  > 
>  > I'm sorry to bother you again, but everything seems to be going just
>  > fine since the last lot of policy updates, so I decided to move into the
>  > next phase of my project.
>  > 
>  > You're going to hate me for this...
>  > 
>  > What I have is a Mod-Sec rule that detects a particular kind of attack;
>  > when detected it identifies the IP address of the attacker and (using
>  > the modsec "exec" function) passes this to a script.
>  > 
>  > During our recent exchange I was using this rule for testing, but for
>  > now all the script does is write the IP address into a file. (This
>  > worked by the way).
>  > 
>  > Now for the next part. Instead of writing it to a file I want to ban the
>  > IP in iptables using a feature of the fail2ban application which I also
>  > have running on this machine.
>  > 
>  > The script uses the following command:
>  > fail2ban-client set modsec banip $IP
>  > touch -c /var/log/httpd/modsec_audit.log
>  > 
>  > where $IP is the IP address passes from mod-sec, the "banip" is a
>  > argument of the fail2ban-client app which initiates a manual banning of
>  > the IP and "modsec" is the name of the "jail" (in fail2ban
> parlance) to
>  > be activated for this IP.
>  > 
>  > The "touch" command is necessary to trick fail2ban into thinking that
>  > the log file it is monitoring has been updated and thus needs to wake
>  > itself and take action.
>  > 
>  > Putting all this together now gives me this (single) avc when testing:
>  > 
>  > Raw Audit Messages :
>  > 
>  > node=troodos.org.uk type=AVC msg=audit(1270821681.36:50303): avc: denied { search }
> for pid=30224 comm="fail2ban-client" name="fail2ban" dev=sda5
> ino=476186 scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir 
>  > node=troodos.org.uk type=SYSCALL msg=audit(1270821681.36:50303): arch=40000003
> syscall=102 success=no exit=-13 a0=3 a1=bfa9b0e0 a2=b6810c a3=b76fb2c8 items=0 ppid=30222
> pid=30224 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48
> tty=(none) ses=4294967295 comm="fail2ban-client" exe="/usr/bin/python"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null)
>  > 
>  > How best to handle this?
>  
>  I am not sure if i understand how that goes. From the avc denials above i can tell that
> fail2ban-client runs in the httpd_t domain. That means mlogc is not running it but some
> process in the httpd_t domain.
>  
>  What runs the script? 
I guess it must be mod-security itself.

I have a rule in modsec as follows:

SecRule REQUEST_URI_RAW "(?:wantsfly|w00tw00t)"
"phase:1,t:lowercase,deny,log,status:403, setenv:REMOTEIP=%{REMOTE_ADDR},
exec:/usr/local/bin/banip2.sh"

This means that if someone tries to probe my webserver with a typical
signature (in this case "wantsfly") Mod-Security will execute the
script /usr/local/bin/banip2.sh within which "fail2ban-client" is called
to block the IP address in iptables.

Does that make sense?

Thanks

Mark

[Dominick Grift]

On Fri, Apr 09, 2010 at 04:26:05PM +0100, Arthur Dent wrote:
>  On Fri, 2010-04-09 at 17:10 +0200, Dominick Grift wrote:
>  > On Fri, Apr 09, 2010 at 03:23:34PM +0100, Arthur Dent wrote:
>  > > Hi Dominick,
>  > > 
>  > > I'm sorry to bother you again, but everything seems to be going just
>  > > fine since the last lot of policy updates, so I decided to move into the
>  > > next phase of my project.
>  > > 
>  > > You're going to hate me for this...
>  > > 
>  > > What I have is a Mod-Sec rule that detects a particular kind of attack;
>  > > when detected it identifies the IP address of the attacker and (using
>  > > the modsec "exec" function) passes this to a script.
>  > > 
>  > > During our recent exchange I was using this rule for testing, but for
>  > > now all the script does is write the IP address into a file. (This
>  > > worked by the way).
>  > > 
>  > > Now for the next part. Instead of writing it to a file I want to ban the
>  > > IP in iptables using a feature of the fail2ban application which I also
>  > > have running on this machine.
>  > > 
>  > > The script uses the following command:
>  > > fail2ban-client set modsec banip $IP
>  > > touch -c /var/log/httpd/modsec_audit.log
>  > > 
>  > > where $IP is the IP address passes from mod-sec, the "banip" is a
>  > > argument of the fail2ban-client app which initiates a manual banning of
>  > > the IP and "modsec" is the name of the "jail" (in fail2ban
> parlance) to
>  > > be activated for this IP.
>  > > 
>  > > The "touch" command is necessary to trick fail2ban into thinking
> that
>  > > the log file it is monitoring has been updated and thus needs to wake
>  > > itself and take action.
>  > > 
>  > > Putting all this together now gives me this (single) avc when testing:
>  > > 
>  > > Raw Audit Messages :
>  > > 
>  > > node=troodos.org.uk type=AVC msg=audit(1270821681.36:50303): avc: denied {
> search } for pid=30224 comm="fail2ban-client" name="fail2ban" dev=sda5
> ino=476186 scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir 
>  > > node=troodos.org.uk type=SYSCALL msg=audit(1270821681.36:50303): arch=40000003
> syscall=102 success=no exit=-13 a0=3 a1=bfa9b0e0 a2=b6810c a3=b76fb2c8 items=0 ppid=30222
> pid=30224 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48
> tty=(none) ses=4294967295 comm="fail2ban-client" exe="/usr/bin/python"
> subj=unconfined_u:system_r:httpd_t:s0 key=(null)
>  > > 
>  > > How best to handle this?
>  > 
>  > I am not sure if i understand how that goes. From the avc denials above i can tell
> that fail2ban-client runs in the httpd_t domain. That means mlogc is not running it but
> some process in the httpd_t domain.
>  > 
>  > What runs the script?
>  
>  I guess it must be mod-security itself.
>  
>  I have a rule in modsec as follows:
>  
>  SecRule REQUEST_URI_RAW "(?:wantsfly|w00tw00t)"
> "phase:1,t:lowercase,deny,log,status:403, setenv:REMOTEIP=%{REMOTE_ADDR},
> exec:/usr/local/bin/banip2.sh"
>  
>  This means that if someone tries to probe my webserver with a typical
>  signature (in this case "wantsfly") Mod-Security will execute the
>  script /usr/local/bin/banip2.sh within which "fail2ban-client" is called
>  to block the IP address in iptables.
>  
>  Does that make sense? 
Yes. I guess i would confine /usr/local/bin/banip2.sh and set
up a transition from httpd_t to a new banip2_t domain

Basically pretty much similar to what we did with mlogc

It would be a good exercise if you would try that. Basically follow the steps described in
previous messages.
only this time you do not have to create a new myapache module you can just extend the
existing with interface calls to your new banip2 module.

>  
>  Thanks
>  
>  Mark
>  
>  
>   


>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Arthur Dent]

On Fri, 2010-04-09 at 17:44 +0200, Dominick Grift wrote:
>  On Fri, Apr 09, 2010 at 04:26:05PM +0100, Arthur Dent wrote:
>  > On Fri, 2010-04-09 at 17:10 +0200, Dominick Grift wrote:
>  > > On Fri, Apr 09, 2010 at 03:23:34PM +0100, Arthur Dent wrote:
>  > > > Hi Dominick,
>  > > >  
[snip]

>  > Does that make sense?
>  Yes. I guess i would confine /usr/local/bin/banip2.sh and set up a transition from
> httpd_t to a new banip2_t domain
>  
>  Basically pretty much similar to what we did with mlogc
>  
>  It would be a good exercise if you would try that. Basically follow the steps described
> in previous messages.
>  only this time you do not have to create a new myapache module you can just extend the
> existing with interface calls to your new banip2 module. 
I just thought I would give a quick update on this...

I was quite up for the challenge of writing my own policy for this, but
realised that I had to get the script working properly first. Although
the script worked fine when executed from the command line, it did not
when run in the normal environment. I realised that the fail2ban-client
app called from within the script needs to run as root. After much
messing around, trying (and failing) with sudo and su- commands, editing
sudoers and much other wasted effort I was stuck. Then, in a rare (for
me) moment of clear-thinking I realised that the way fail2ban works, and
is designed to work, is by monitoring log files for new entries and then
banning the IP if the entry matches a regex. So all I had to do was to
get the script to write the IP into a "log file" (which it already was)
together with a timestamp, and set fail2ban to monitor that log file...

Simple!

And not an AVC in sight!

So thanks for all your help.

I think I am now ready to remove the  "permissive mlogc_t;" directive
from mlogc.te and put the system back into Enforcing mode.

Cheers!

Mark

[Arthur Dent]

Hello Dominick,

I don't know if you remember all the painful details of the thread where
you helped me solve my mlogc problems but, after running for a couple of
weeks in enforcing mode I occasionally get these AVCs when my
ModSecurity rule triggers a block which is reported in mlogc:

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1271810736.442:85299): avc: denied { read } for
pid=30941 comm="mlogc" name="stat" dev=proc ino=4026531985
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file

node=troodos.org.uk type=SYSCALL msg=audit(1271810736.442:85299): arch=40000003 syscall=5
success=no exit=-13 a0=ceeb6e a1=80000 a2=0 a3=2000 items=0 ppid=32219 pid=30941
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 


Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1271810736.446:85300): avc: denied { read } for
pid=30941 comm="mlogc" name="cpuinfo" dev=proc ino=4026531980
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file

node=troodos.org.uk type=SYSCALL msg=audit(1271810736.446:85300): arch=40000003 syscall=5
success=no exit=-13 a0=ceeb79 a1=80000 a2=0 a3=2000 items=0 ppid=32219 pid=30941
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1272206914.57:99302): avc: denied { read } for
pid=2650 comm="mlogc" name="stat" dev=proc ino=4026531985
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file

node=troodos.org.uk type=SYSCALL msg=audit(1272206914.57:99302): arch=40000003 syscall=5
success=no exit=-13 a0=24bb6e a1=80000 a2=0 a3=2000 items=0 ppid=32219 pid=2650
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1272206914.61:99303): avc: denied { read } for
pid=2650 comm="mlogc" name="cpuinfo" dev=proc ino=4026531980
scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file

node=troodos.org.uk type=SYSCALL msg=audit(1272206914.61:99303): arch=40000003 syscall=5
success=no exit=-13 a0=24bb79 a1=80000 a2=0 a3=2000 items=0 ppid=32219 pid=2650
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 


Audit2allow suggests:

require {
	type mlogc_t;
	type proc_t;
	class file read;
}

#============= mlogc_t ==============
allow mlogc_t proc_t:file read;

But when I try to add that to my mlogc.te it chokes during the build
process...

I should point out that, as far as I can tell, everything still works
despite the AVC denial...

Thanks yet again for your patient help!

Mark

[Dominick Grift]

On Sun, Apr 25, 2010 at 07:20:12PM +0100, Arthur Dent wrote:
>  Hello Dominick,
>  
>  I don't know if you remember all the painful details of the thread where
>  you helped me solve my mlogc problems but, after running for a couple of
>  weeks in enforcing mode I occasionally get these AVCs when my
>  ModSecurity rule triggers a block which is reported in mlogc:
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1271810736.442:85299): avc: denied { read } for
> pid=30941 comm="mlogc" name="stat" dev=proc ino=4026531985
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
>
>  node=troodos.org.uk type=SYSCALL msg=audit(1271810736.442:85299): arch=40000003 syscall=5
> success=no exit=-13 a0=ceeb6e a1=80000 a2=0 a3=2000 items=0 ppid=32219 pid=30941
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1271810736.446:85300): avc: denied { read } for
> pid=30941 comm="mlogc" name="cpuinfo" dev=proc ino=4026531980
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
>
>  node=troodos.org.uk type=SYSCALL msg=audit(1271810736.446:85300): arch=40000003 syscall=5
> success=no exit=-13 a0=ceeb79 a1=80000 a2=0 a3=2000 items=0 ppid=32219 pid=30941
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1272206914.57:99302): avc: denied { read } for
> pid=2650 comm="mlogc" name="stat" dev=proc ino=4026531985
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
>
>  node=troodos.org.uk type=SYSCALL msg=audit(1272206914.57:99302): arch=40000003 syscall=5
> success=no exit=-13 a0=24bb6e a1=80000 a2=0 a3=2000 items=0 ppid=32219 pid=2650
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1272206914.61:99303): avc: denied { read } for
> pid=2650 comm="mlogc" name="cpuinfo" dev=proc ino=4026531980
> scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
>
>  node=troodos.org.uk type=SYSCALL msg=audit(1272206914.61:99303): arch=40000003 syscall=5
> success=no exit=-13 a0=24bb79 a1=80000 a2=0 a3=2000 items=0 ppid=32219 pid=2650
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc"
> subj=unconfined_u:system_r:mlogc_t:s0 key=(null) 
>  
>  
>  Audit2allow suggests:
>  
>  require {
>  	type mlogc_t;
>  	type proc_t;
>  	class file read;
>  }
>  
>  #============= mlogc_t ==============
>  allow mlogc_t proc_t:file read;
>  
>  But when I try to add that to my mlogc.te it chokes during the build
>  process... 
Chokes? what exactly gets printed to the screen?

try adding "kernel_read_system_state(mlogc_t) to your mlogc.te file and rebuild,
reinstall.

>  
>  I should point out that, as far as I can tell, everything still works
>  despite the AVC denial...
>  
>  Thanks yet again for your patient help!
>  
>  Mark
>    


>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

Access to /root/.[rs]hosts

[Göran Uddeborg]

I tried to set up root ssh access between a couple of (carefully
selected) hosts.  For root the standard /etc/hosts.equiv and
/etc/ssh/shosts.equiv isn't recoginzed, so I created an /root/.shosts.

But it turns out that sshd isn't allowed to read this file.  The
complete AVC:s below.  Is this an intentional restriction?  That
hostbased root access via ssh is not allowed in the standard policy?
Or is it a bug I could report in bugzilla?

time->Sun May  2 19:57:09 2010
type=SYSCALL msg=audit(1272823029.521:20484): arch=c000003e syscall=4 success=no exit=-13
a0=7fff2fb22cb0 a1=7fff2fb22c20 a2=7fff2fb22c20 a3=fffffff9 items=0 ppid=2920 pid=2922
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="sshd" exe="/usr/sbin/sshd"
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1272823029.521:20484): avc:  denied  { getattr } for  pid=2922
comm="sshd" path="/root/.shosts" dev=sda2 ino=7031802
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:admin_home_t:s0 tclass=file
----
time->Sun May  2 19:57:09 2010
type=SYSCALL msg=audit(1272823029.533:20485): arch=c000003e syscall=4 success=no exit=-13
a0=7fff2fb22cb0 a1=7fff2fb22c20 a2=7fff2fb22c20 a3=fffffff9 items=0 ppid=2920 pid=2922
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="sshd" exe="/usr/sbin/sshd"
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1272823029.533:20485): avc:  denied  { getattr } for  pid=2922
comm="sshd" path="/root/.shosts" dev=sda2 ino=7031802
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:admin_home_t:s0 tclass=file
----
time->Sun May  2 19:57:09 2010
type=SYSCALL msg=audit(1272823029.536:20487): arch=c000003e syscall=4 success=no exit=-13
a0=7fff2fb22cb0 a1=7fff2fb22c20 a2=7fff2fb22c20 a3=fffffff9 items=0 ppid=2920 pid=2922
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="sshd" exe="/usr/sbin/sshd"
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1272823029.536:20487): avc:  denied  { getattr } for  pid=2922
comm="sshd" path="/root/.shosts" dev=sda2 ino=7031802
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:admin_home_t:s0 tclass=file
----
time->Sun May  2 19:57:09 2010
type=SYSCALL msg=audit(1272823029.539:20488): arch=c000003e syscall=4 success=no exit=-13
a0=7fff2fb22cb0 a1=7fff2fb22c20 a2=7fff2fb22c20 a3=fffffff9 items=0 ppid=2920 pid=2922
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="sshd" exe="/usr/sbin/sshd"
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1272823029.539:20488): avc:  denied  { getattr } for  pid=2922
comm="sshd" path="/root/.shosts" dev=sda2 ino=7031802
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:admin_home_t:s0 tclass=file

Access to /root/.[rs]hosts

[Paul Howarth]

On Sun, 2 May 2010 20:13:22 +0200
"Göran Uddeborg" <goeran(a)uddeborg.se&gt; wrote:

>  I tried to set up root ssh access between a couple of (carefully
>  selected) hosts.  For root the standard /etc/hosts.equiv and
>  /etc/ssh/shosts.equiv isn't recoginzed, so I created an /root/.shosts.
>  
>  But it turns out that sshd isn't allowed to read this file.  The
>  complete AVC:s below.  Is this an intentional restriction?  That
>  hostbased root access via ssh is not allowed in the standard policy?
>  Or is it a bug I could report in bugzilla? 
Try labelling /root/.shosts as home_ssh_t and see if that helps.

Cheers, Paul.

Access to /root/.[rs]hosts

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/02/2010 02:13 PM, Göran Uddeborg wrote:
>  I tried to set up root ssh access between a couple of (carefully
>  selected) hosts.  For root the standard /etc/hosts.equiv and
>  /etc/ssh/shosts.equiv isn't recoginzed, so I created an /root/.shosts.
>  
>  But it turns out that sshd isn't allowed to read this file.  The
>  complete AVC:s below.  Is this an intentional restriction?  That
>  hostbased root access via ssh is not allowed in the standard policy?
>  Or is it a bug I could report in bugzilla?
>  
>  time->Sun May  2 19:57:09 2010
>  type=SYSCALL msg=audit(1272823029.521:20484): arch=c000003e syscall=4 success=no exit=-13
> a0=7fff2fb22cb0 a1=7fff2fb22c20 a2=7fff2fb22c20 a3=fffffff9 items=0 ppid=2920 pid=2922
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="sshd" exe="/usr/sbin/sshd"
> subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
>  type=AVC msg=audit(1272823029.521:20484): avc:  denied  { getattr } for  pid=2922
> comm="sshd" path="/root/.shosts" dev=sda2 ino=7031802
> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:admin_home_t:s0 tclass=file
>  ----
>  time->Sun May  2 19:57:09 2010
>  type=SYSCALL msg=audit(1272823029.533:20485): arch=c000003e syscall=4 success=no exit=-13
> a0=7fff2fb22cb0 a1=7fff2fb22c20 a2=7fff2fb22c20 a3=fffffff9 items=0 ppid=2920 pid=2922
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="sshd" exe="/usr/sbin/sshd"
> subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
>  type=AVC msg=audit(1272823029.533:20485): avc:  denied  { getattr } for  pid=2922
> comm="sshd" path="/root/.shosts" dev=sda2 ino=7031802
> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:admin_home_t:s0 tclass=file
>  ----
>  time->Sun May  2 19:57:09 2010
>  type=SYSCALL msg=audit(1272823029.536:20487): arch=c000003e syscall=4 success=no exit=-13
> a0=7fff2fb22cb0 a1=7fff2fb22c20 a2=7fff2fb22c20 a3=fffffff9 items=0 ppid=2920 pid=2922
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="sshd" exe="/usr/sbin/sshd"
> subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
>  type=AVC msg=audit(1272823029.536:20487): avc:  denied  { getattr } for  pid=2922
> comm="sshd" path="/root/.shosts" dev=sda2 ino=7031802
> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:admin_home_t:s0 tclass=file
>  ----
>  time->Sun May  2 19:57:09 2010
>  type=SYSCALL msg=audit(1272823029.539:20488): arch=c000003e syscall=4 success=no exit=-13
> a0=7fff2fb22cb0 a1=7fff2fb22c20 a2=7fff2fb22c20 a3=fffffff9 items=0 ppid=2920 pid=2922
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="sshd" exe="/usr/sbin/sshd"
> subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
>  type=AVC msg=audit(1272823029.539:20488): avc:  denied  { getattr } for  pid=2922
> comm="sshd" path="/root/.shosts" dev=sda2 ino=7031802
> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:admin_home_t:s0 tclass=file
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>  
>   
I did not even know this file exists.

chcon -t home_ssh_t /root/.shost

Should fix the problem.  I will add this as default labeling in F13 and F12.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkveymoACgkQrlYvE4MpobPllACgiW/oLW7TC5a8yrHn5AlSC0Je
> /hUAnjO2W2c1GpNeKUPcLgyOdqF8F9e5
> =7H0C
> -----END PGP SIGNATURE-----

Access to /root/.[rs]hosts

[Göran Uddeborg]

Paul Howarth:
>  Try labelling /root/.shosts as home_ssh_t and see if that helps.
It does indeed.

Daniel Walsh:
>  I will add this as default labeling in F13 and F12. 
I take it that it wasn't intended, but there is no need for me to file
a bugzilla. :-)

Access to /root/.[rs]hosts

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/03/2010 10:45 AM, Göran Uddeborg wrote:
>  Paul Howarth:
> > Try labelling /root/.shosts as home_ssh_t and see if that helps.
>  
>  It does indeed.
>  
>  Daniel Walsh:
> > I will add this as default labeling in F13 and F12.
>  
>  I take it that it wasn't intended, but there is no need for me to file
>  a bugzilla. :-)
>  
>  
>  
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux 
Yes no need.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkve6J0ACgkQrlYvE4MpobNqvgCfSGZHLn77/ZGK/xwlHsuFWZD1
> 8yAAoL2PKInGJeqJHW+e4yRIVVPK9Dv0
> =U1xF
> -----END PGP SIGNATURE-----