Thomas Harold wrote:

I think that you have to have the setroubleshoot service running in order to get SELinux errors in /var/log/messages.

https://fedorahosted.org/setroubleshoot/wiki/SETroubleShoot%20User%20FAQ

Hmmm, I seem to have both setroubleshoot and setroubleshoot-server packages installed, but much of that package talks about turning on the setroubleshoot service; the file for that should be in /etc/rc.d/init.d/setroubleshoot, but I have no such file. Both packages verify as correct (rpm -V) and rpm -qil does not show any such file in the inventory. There is a file /usr/sbin/setroubleshootd which is what I would expect for the daemon, but no file in /etc/rc.d/init.d references it. Odd. And if I try to manually launch it, it runs briefly, leaves a zero-length log file in /var/log/setroubleshoot/setroubleshootd.log.

Note that I am *not* on a X11 desktop on this host. It is a server, and while it has X installed, it is in run level 3.

roland

Thomas Harold wrote:

You could try uninstalling and then reinstalling the setroubleshoot package. Specifically "setroubleshoot-server" package contains the daemon and init.d file and only depends on the -plugins package.

But it doesn't seem to include the init.d file, or is rpm -qil not telling me what I think it is telling me:

572 root> rpm -qil setroubleshoot-server | grep /etc /etc/audisp/plugins.d/sedispatch.conf /etc/dbus-1/system.d/org.fedoraproject.Setroubleshootd.conf /etc/logrotate.d/setroubleshoot /etc/setroubleshoot /etc/setroubleshoot/setroubleshoot.cfg

roland

Roland Roberts wrote:

Roland Roberts wrote:

...

Thomas Harold wrote:

...

You could try uninstalling and then reinstalling the setroubleshoot package. Specifically "setroubleshoot-server" package contains the daemon and init.d file and only depends on the -plugins package.

Oo-oo. I just discovered something *very* interesting. When I first set up this host, I set it up in parallel with the existing host it was replacing and it had a different host name. I find, in /var/lib/setroubleshoot/audit_listener_database.xml, the old host name. Perhaps that's why I'm not getting my messages. I'm going to try correcting the host name there. I'm not sure if I *need* to reboot, but I'm not sure what processes will need to be restarted if I don't.

Well, that by itself is not sufficient. But perhaps these two lines in syslog are a clue if only I could decipher them:

dbus: avc: received setenforce notice (enforcing=0) tycho dbus: Can't send to audit system: USER_AVC avc: received setenforce notice (enforcing=0)#012: exe="?" (sauid=81, hostname=?, addr=?, terminal=?)

roland

On 11/29/2009 12:49 AM, Roland Roberts wrote:

Thomas Harold wrote:

...

You could try uninstalling and then reinstalling the setroubleshoot package. Specifically "setroubleshoot-server" package contains the daemon and init.d file and only depends on the -plugins package.

But it doesn't seem to include the init.d file, or is rpm -qil not telling me what I think it is telling me:

572 root> rpm -qil setroubleshoot-server | grep /etc /etc/audisp/plugins.d/sedispatch.conf /etc/dbus-1/system.d/org.fedoraproject.Setroubleshootd.conf /etc/logrotate.d/setroubleshoot /etc/setroubleshoot /etc/setroubleshoot/setroubleshoot.cfg

Not sure, that's sounding more like a Fedora issue then an SELinux issue (and I'm not running Fedora, I'm running RHEL/CentOS). But a bit of google-fu turned up:

http://osdir.com/ml/fedora-selinux/2009-06/msg00053.html

(the linked message was posted by Daniel J Walsh)

Basically, they've restructured things back in June 2009. So you'll probably have to go digging in the audit.log file for the AVC messages.

# grep "AVC" /var/log/audit/audit.log

On Sun, 2009-11-29 at 01:11 -0500, Roland Roberts wrote:

Thomas Harold wrote:

...

On 11/29/2009 12:49 AM, Roland Roberts wrote:

...

But it doesn't seem to include the init.d file, or is rpm -qil not telling me what I think it is telling me:

572 root> rpm -qil setroubleshoot-server | grep /etc /etc/audisp/plugins.d/sedispatch.conf /etc/dbus-1/system.d/org.fedoraproject.Setroubleshootd.conf /etc/logrotate.d/setroubleshoot /etc/setroubleshoot /etc/setroubleshoot/setroubleshoot.cfg

Not sure, that's sounding more like a Fedora issue then an SELinux issue (and I'm not running Fedora, I'm running RHEL/CentOS). But a bit of google-fu turned up:

http://osdir.com/ml/fedora-selinux/2009-06/msg00053.html

(the linked message was posted by Daniel J Walsh)

Basically, they've restructured things back in June 2009. So you'll probably have to go digging in the audit.log file for the AVC messages.

# grep "AVC" /var/log/audit/audit.log

Thanks. Maybe I'll file a report with bugzilla. Not sure that my missing messages are a bug, but there is nothing in /var/log/audit/audit.log with "avc". In any event, it's past my bedtime here for today

g'nite.

roland

Just as a bit of advice for the future. You are better off using the ausearch command to find denials. You can narrow it down to just AVC denials by using ausearch -m AVC. After that you can restrict based on time using some of the other flags for the utility.

Dave

On 11/29/09 02:11, Sandro Janke wrote:

On 11/29/2009 06:29 AM, Roland Roberts wrote:

...

Thomas Harold wrote:

...

I think that you have to have the setroubleshoot service running in order to get SELinux errors in /var/log/messages.

https://fedorahosted.org/setroubleshoot/wiki/SETroubleShoot%20User%20FAQ

Hmmm, I seem to have both setroubleshoot and setroubleshoot-server packages installed, but much of that package talks about turning on the setroubleshoot service; the file for that should be in /etc/rc.d/init.d/setroubleshoot, but I have no such file. Both packages verify as correct (rpm -V) and rpm -qil does not show any such file in the inventory. There is a file /usr/sbin/setroubleshootd which is what I would expect for the daemon, but no file in /etc/rc.d/init.d references it. Odd. And if I try to manually launch it, it runs briefly, leaves a zero-length log file in /var/log/setroubleshoot/setroubleshootd.log.

Note that I am *not* on a X11 desktop on this host. It is a server, and while it has X installed, it is in run level 3.

Actually, you don't need to have any of the setroubleshoot packages installed to get AVC messages logged. What you need is auditd running and it will log AVC messages to /var/log/audit/audit.log

With setroubleshoot-server installed you can watch the logged messages using:

# sealert -a /var/log/audit/audit.log

The output will be long and in the style of setroubleshoot browser, so take your measures.

Another tool - from the audit package - that can prove very useful is ausearch. It will search the audit logs for messages matching the given criteria.

-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list

agree.. In my case I normaly just do: audit2allow -d > to_the_allow_rules audit2allow -i /var/log/*(and the rest of the log messages havng any left over avc's to define into the policy);

Justin P. Mattock

On Sun, 2009-11-29 at 20:46 -0500, Roland Roberts wrote:

On 11/29/2009 05:18 AM, Justin P. Mattock wrote:

...

In my case I normaly just do: audit2allow -d > to_the_allow_rules audit2allow -i /var/log/*(and the rest of the log messages havng any left over avc's to define into the policy);

Guys, you're driving me crazy :-/ I can't *find* a log entry to fix. There's nothing where it's supposed to be. So...if you agree that that looks like a bug, I'll just go on and file a bug. Otherwise I'm really stuck.

I see that my F12 policy has a rule that allows dovecot_t to talk to postgresql_port_t. Not certain if it is controlled by a boolean which is toggled wrong on your system or if you are having some other problem, so lets start by seeing the actual avc denial.

AVCs can end up either in /var/log/messages or /var/log/audit/audit.log (depending on the system setup.) Also in permissive move denials are only logged one time. So you won't see a denial every time it ~would~ have triggered. To flush the selinux cache I typically suggest you set the system enforcing and back permissive quickly. So lets do these steps.

setenforce 1 setenforce 0 reproduce problem (or what would be a problem) grep -i avc /var/log/messages grep -i avc /var/log/audit/audit.log

If both of those come up blank you likely are hitting a problem that is being 'dontaudit' I believe you said F11 (if not and it is old enough to not understand semodule -DB let me know as there are other ways to do this on older systems)? If so do these steps

semodule -DB setenforce 1 setenforce 0 reproduce problem (or what would be a problem) grep -i avc /var/log/messages /var/log/audit/audit.log semodule -B

Let us know the output this time. Hopefully we can get to the bottom of this.

-Eric

keep in mind this is running the latest git refpolicy and everything. You can use these tools(setools)although normally try to keep things as simple as possible, especially during development(that is until things get worked out);

Justin P. Mattock

On 11/29/2009 08:44 PM, Roland Roberts wrote:

On 11/29/2009 05:11 AM, Sandro Janke wrote:

...

Actually, you don't need to have any of the setroubleshoot packages installed to get AVC messages logged. What you need is auditd running and it will log AVC messages to /var/log/audit/audit.log

With setroubleshoot-server installed you can watch the logged messages using:

# sealert -a /var/log/audit/audit.log

The output will be long and in the style of setroubleshoot browser, so take your measures.

Another tool - from the audit package - that can prove very useful is ausearch. It will search the audit logs for messages matching the given criteria.

But I'm not getting any messages there. And changing enforcing mode fixes the problem, so it seems like it has to be SELinux, but with no log, I can't figure out what rule needs to be changed.

At the suggestion of Daniel Walsh, I ran

semodule -DB

then restarted dovecot and got my messages. I've used those to create policy, but can't load it.

I've configured dovecot to use a local socket connection to postgres. Here is what I for SELinux:

grep 'Dec 2.*dovecot-auth' /var/log/messages| audit2allow -m local > local.te 328 root> cat local.te

module local 1.0;

require { type dovecot_auth_t; type unlabeled_t; type postgresql_tmp_t; class sock_file write; class unix_stream_socket read; }

#============= dovecot_auth_t ============== allow dovecot_auth_t postgresql_tmp_t:sock_file write;

#============= unlabeled_t ============== allow unlabeled_t self:unix_stream_socket read; 329 root> make -f /usr/share/selinux/devel/Makefile local.pp Compiling targeted local module /usr/bin/checkmodule: loading policy configuration from tmp/local.tmp /usr/bin/checkmodule: policy configuration loaded /usr/bin/checkmodule: writing binary representation (version 10) to tmp/local.mod Creating targeted local.pp policy package rm tmp/local.mod.fc tmp/local.mod 330 root> semodule -i local.pp libsepol.print_missing_requirements: local's global requirements were not met: type/attribute dovecot_auth_t libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed!

I'm at a loss on what to do here. Suggestions on why it would tell me this?

roland

On 12/02/2009 03:22 PM, Roland Roberts wrote:

On 11/29/2009 08:44 PM, Roland Roberts wrote:

...

On 11/29/2009 05:11 AM, Sandro Janke wrote:

...

Actually, you don't need to have any of the setroubleshoot packages installed to get AVC messages logged. What you need is auditd running and it will log AVC messages to /var/log/audit/audit.log

With setroubleshoot-server installed you can watch the logged messages using:

# sealert -a /var/log/audit/audit.log

The output will be long and in the style of setroubleshoot browser, so take your measures.

Another tool - from the audit package - that can prove very useful is ausearch. It will search the audit logs for messages matching the given criteria.

But I'm not getting any messages there. And changing enforcing mode fixes the problem, so it seems like it has to be SELinux, but with no log, I can't figure out what rule needs to be changed.

At the suggestion of Daniel Walsh, I ran

semodule -DB

then restarted dovecot and got my messages. I've used those to create policy, but can't load it.

I've configured dovecot to use a local socket connection to postgres. Here is what I for SELinux:

grep 'Dec 2.*dovecot-auth' /var/log/messages| audit2allow -m local > local.te 328 root> cat local.te

module local 1.0;

require { type dovecot_auth_t; type unlabeled_t; type postgresql_tmp_t; class sock_file write; class unix_stream_socket read; }

#============= dovecot_auth_t ============== allow dovecot_auth_t postgresql_tmp_t:sock_file write;

#============= unlabeled_t ============== allow unlabeled_t self:unix_stream_socket read; 329 root> make -f /usr/share/selinux/devel/Makefile local.pp Compiling targeted local module /usr/bin/checkmodule: loading policy configuration from tmp/local.tmp /usr/bin/checkmodule: policy configuration loaded /usr/bin/checkmodule: writing binary representation (version 10) to tmp/local.mod Creating targeted local.pp policy package rm tmp/local.mod.fc tmp/local.mod 330 root> semodule -i local.pp libsepol.print_missing_requirements: local's global requirements were not met: type/attribute dovecot_auth_t libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed!

I'm at a loss on what to do here. Suggestions on why it would tell me this?

roland

Did you replace the dovecot.pp when you first tried this?

On 12/02/09 15:57, Roland Roberts wrote:

Roland Roberts wrote:

...

I'm running Fedora 11 x86_64 with the dovecot and dovecot-pgsql RPMs installed. I have a small user database set up for email authentication. The issue I'm having is that when I am in enforcing mode, dovecot can't connect to the database. Turning off enforcing mode lets it work. I'm having trouble diagnosing where the denial is taking place as I don't see any avc messages in /var/log/messages that relate to dovecot. The only messages I'm getting are in /var/log/maillog from dovecot like this:

Nov 28 22:23:11 fred dovecot: auth(default): pgsql: Connect failed to maildb: could not connect to server: Permission denied Nov 28 22:23:11 fred dovecot: auth(default): #011Is the server running on host "fred.flinstone.org" and accepting Nov 28 22:23:11 fred dovecot: auth(default): #011TCP/IP connections on port 5432?

The answer to the questions is "yes" it is running and accepting connections. Whether or not enforcing mode is on, when logged in, I can connect to the database via

$ psql -h fred.flinstone.org maildb

I *think* this is a result of updating on Nov 18. I have not changed the default selinux mode since the host was set up back in September. At that point, I set it to enforcing mode after working out a few issues. On Nov 18, a lot of things were updated, but among there were

Nov 18 10:00:02 Updated: kernel-firmware-2.6.30.9-96.fc11.noarch Nov 18 10:00:15 Updated: kernel-headers-2.6.30.9-96.fc11.x86_64 Nov 18 10:00:28 Installed: kernel-devel-2.6.30.9-96.fc11.x86_64 Nov 18 10:01:30 Installed: kernel-2.6.30.9-96.fc11.x86_64 Nov 18 10:02:01 Updated: selinux-policy-3.6.12-86.fc11.noarch Nov 18 10:02:46 Updated: selinux-policy-targeted-3.6.12-86.fc11.noarch

Today, I did another update, hoping it would cure the problem and got these revisions

Nov 28 10:57:33 Updated: selinux-policy-3.6.12-88.fc11.noarch Nov 28 10:57:47 Updated: selinux-policy-targeted-3.6.12-88.fc11.noarch

but the behavior is unchanged, I still have to turn off enforcing mode.

Any clues on what I need to do to get this to work? Or where to look for clues since, as I mentioned, I can't even find log entries that would clue me in.

roland

Okay, here's what I finally ended up with that have me running in enforcing mode. I have both dovecot and exim using PostgreSQL for authentication. I had originally had them connecting via tcp, but changed them to use the unix domain socket. The policies below allow either.

I also ran into a problem with httpd needing access to PostgreSQL since I'm running Drupal with PostgreSQL as the backend. And I have SquirrelMail running so httpd needs access to the imap/pop port. I don't think this is complete as I'm using the tcp port for PostgreSQL and the policy only allows that, not the unix domain socket (which I should probably configure instead). But at least I can now run in enforcing mode.

365 root> cat *.te

module dovecotauthfixes 1.0;

require { type dovecot_auth_t; type postgresql_port_t; type postgresql_tmp_t; type postgresql_t; class sock_file write; class tcp_socket name_connect; class unix_stream_socket connectto; }

#============= dovecot_auth_t ============== allow dovecot_auth_t postgresql_port_t:tcp_socket name_connect; allow dovecot_auth_t postgresql_t:unix_stream_socket connectto; allow dovecot_auth_t postgresql_tmp_t:sock_file write;

module eximfixes 1.0;

require { type postgresql_tmp_t; type exim_t; type postgresql_t; class sock_file write; class unix_stream_socket connectto; }

#============= exim_t ============== allow exim_t postgresql_t:unix_stream_socket connectto; allow exim_t postgresql_tmp_t:sock_file write;

module httpdfixes 1.0;

require { type postgresql_port_t; type httpd_t; type pop_port_t; class tcp_socket { name_bind name_connect }; }

#============= httpd_t ============== allow httpd_t pop_port_t:tcp_socket { name_bind name_connect }; allow httpd_t postgresql_port_t:tcp_socket name_connect;

roland

cool, so your up and running..

Justin P. Mattock

On 12/02/2009 06:57 PM, Roland Roberts wrote:

Okay, here's what I finally ended up with that have me running in enforcing mode. I have both dovecot and exim using PostgreSQL for authentication. I had originally had them connecting via tcp, but changed them to use the unix domain socket. The policies below allow either.

[...] module eximfixes 1.0;

require { type postgresql_tmp_t; type exim_t; type postgresql_t; class sock_file write; class unix_stream_socket connectto; }

#============= exim_t ============== allow exim_t postgresql_t:unix_stream_socket connectto; allow exim_t postgresql_tmp_t:sock_file write;

module httpdfixes 1.0;

require { type postgresql_port_t; type httpd_t; type pop_port_t; class tcp_socket { name_bind name_connect }; }

#============= httpd_t ============== allow httpd_t pop_port_t:tcp_socket { name_bind name_connect }; allow httpd_t postgresql_port_t:tcp_socket name_connect;

The above are not actually necessary; only the dovecot fix was needed. Daniel Walsh pointed out that there were booleans I could set for the other problems, namely

# setsebool -P httpd_can_network_connect_db=1 httpd_can_sendmail=1 exim_can_connect_db=1

replaces all of the above.

roland