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@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/selinux
Attachment:
pgpR8OxLC5STE.pgp
Description: PGP signature
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
