Current status of mailman and clamav selinux
by Edward Kuns
With current policies from RH8 updates, I removed the clamav policy I
had in place to see what current AVCs I receive. All AVCs I receive
regularly are related to mailman.
I get a *lot* of this:
host=kilroy.chi.il.us type=AVC msg=audit(1205972595.706:10245): avc:
denied { read write } for pid=28531 comm="mailman"
path="socket:[3905242]" dev=sockfs ino=3905242
scontext=system_u:system_r:mailman_mail_t:s0
tcontext=system_u:system_r:sendmail_t:s0 tclass=unix_stream_socket
host=kilroy.chi.il.us type=SYSCALL msg=audit(1205972595.706:10245):
arch=40000003 syscall=11 success=yes exit=0 a0=8845e78 a1=8845f48
a2=88454f8 a3=40 items=0 ppid=28530 pid=28531 auid=4294967295 uid=8
gid=12 euid=8 suid=8 fsuid=8 egid=41 sgid=41 fsgid=41 tty=(none)
comm="mailman" exe="/usr/lib/mailman/mail/mailman"
subj=system_u:system_r:mailman_mail_t:s0 key=(null)
which I suspect is sendmail not closing a socket before it forks
mailman, but I am not certain how to judge, nor how to get sendmail to
address the issue.
The one I get more rarely seems to occur once every time clamav finds a
virus. I get the following collection of AVCs for each virus discovered
by clamav:
type=AVC msg=audit(1205970966.746:10166): avc: denied { append } for
pid=26516 comm="sendmail" path="/var/log/clamd.milter" dev=dm-2
ino=327743 scontext=system_u:system_r:system_mail_t:s0
tcontext=system_u:object_r:clamd_var_log_t:s0 tclass=file
type=AVC msg=audit(1205970966.746:10166): avc: denied { append } for
pid=26516 comm="sendmail" path="/var/log/clamd.milter" dev=dm-2
ino=327743 scontext=system_u:system_r:system_mail_t:s0
tcontext=system_u:object_r:clamd_var_log_t:s0 tclass=file
type=AVC msg=audit(1205970966.746:10166): avc: denied { read write }
for pid=26516 comm="sendmail" path="socket:[3831091]" dev=sockfs
ino=3831091 scontext=system_u:system_r:system_mail_t:s0
tcontext=system_u:system_r:clamd_t:s0 tclass=unix_stream_socket
type=AVC msg=audit(1205970966.746:10166): avc: denied { read write }
for pid=26516 comm="sendmail" path="socket:[3855167]" dev=sockfs
ino=3855167 scontext=system_u:system_r:system_mail_t:s0
tcontext=system_u:system_r:clamd_t:s0 tclass=unix_stream_socket
type=AVC msg=audit(1205970966.746:10166): avc: denied { read write }
for pid=26516 comm="sendmail"
path="/var/tmp/clamav-00c6b962e3f10e1caad8ced3cff4e084/msg.2Orwhh"
dev=dm-2 ino=32843 scontext=system_u:system_r:system_mail_t:s0
tcontext=system_u:object_r:clamd_tmp_t:s0 tclass=file
host=kilroy.chi.il.us type=SYSCALL msg=audit(1205970966.746:10166):
arch=40000003 syscall=11 success=yes exit=0 a0=89d56d0 a1=89d57a8
a2=89d4b98 a3=40 items=0 ppid=2867 pid=26516 auid=4294967295 uid=492
gid=486 euid=492 suid=492 fsuid=492 egid=51 sgid=51 fsgid=51 tty=(none)
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=system_u:system_r:system_mail_t:s0 key=(null)
The setroubleshoot browser message associated with these AVCs is:
"SELinux is preventing sendmail (system_mail_t) "append"
to /var/log/clamd.milter (clamd_var_log_t)." For now I've created a new
myclamav policy from the above AVCs (just the 2nd set listed).
Eddie
--
Eddie Kuns | Home: ekuns at kilroy.chi.il.us
--------------/ URL: http://kilroy.chi.il.us/
"Ah, savory cheese puffs, made inedible by time and fate." -- The Tick
16 years, 1 month
Re: aduitd failing to start
by Steve G
> I am on Red Hat Linux enterprise 5 (Dell 1950). Auditing is failing to
> start. This is the message in messages file
This looks like dns name resolution. Which auditd version are you running? Did you enable name_format = fqdin auditd.conf? You could temporarily change that setting to none orhostname. but maybe you should file a bz for this, too.
-Steve
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
16 years, 1 month
problems using refpolicy
by selinux .
I'm on fc8 and have recently installed refpolicy. However, I can't get KDE
to work. It says that it was unable to get the network connections list and
that it can't connect to dcopserver. There are a lot of error messages --
many about hotplug, which I don't think are relevant. There are some
though, saying that selinux is preventing things from using potentially
mislabeled files in the /tmp directory. I've done every combination of
installation configurations and relabelings that I can think of.
I don't know exactly what error messages are relevant, so I put dmesg output
and the messages file (only containing one boot-up) on a website --
http://www.hostingsimplicity.net/ I made condensed versions of the dmesg
and messages output, but put the full ones there to. Also, there is all the
output from running sealert on the items listed in messages.
I hate to ask someone to look at this for me, but if it is a common problem
that I haven't found in the archives, or if you think you can help, please
do...
Sincerely,
dylan
16 years, 1 month
Re: Question on semanage fcontext -a
by Taylor, Tim
Does anything special have to be done to cause SELinux to start using newly
added local filecontexts? What I'm finding is that if I use semanage
fcontext -a to add a local filecontext definition, it is not used by
restorecon unless I specify the "-F" option. Without the "-F" option,
restorecon -vv <file_path> gives the following message:
/sbin/restorecon: <file_path> not reset customized by admin to
<current_context>
but restorecon -vv -F <file_path> gives this:
/sbin/restorecon reset <file_path> context <current_context>-><new_context>
I've also tried using /usr/sbin/semodule --build to try rebuilding (and
reloading) the current policy, but that
didn't change the behavior I'm seeing.
Any suggestions would be greatly appreciated.
- Tim
--
View this message in context: http://www.nabble.com/Question-on-semanage-fcontext--a-tp15240526p1605831...
Sent from the Fedora SELinux List mailing list archive at Nabble.com.
16 years, 1 month
Re: Bash script problem [OT] - Solved
by Arthur Dent
On Tue, Mar 11, 2008 at 08:58:11PM -0400, Daniel J Walsh wrote:
>
> Arthur Dent wrote:
> > On Mon, Mar 10, 2008 at 09:27:04AM -0400, Daniel J Walsh wrote:
> >> setroubleshoot can be setup on a headless box to send email. And there
> >> is an interface (named pipe) to audit system where you can receive AVC
> >> messages as they happen. Just look at the setroubleshoot code since it
> >> is using this.
> >
> > Ooooo. That sounds interesting. I'm all for not re-inventing the wheel. Thing
> > is, I looked at man sealert and I couldn't see how to do this. I am not much
> > of a hacker, so looking at the code would probably not help me too much.
> >
> > Is there a configuration setting I can set somewhere?
> >
> > Thanks
> >
> > Mark
> >
> > fedora-selinux-list mailing list
> > fedora-selinux-list(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> vi /etc/setroubleshoot/setroubleshoot.cfg
>
> And search for email.
Hi,
Apologies for slow response. Thanks ever so much for this. Just what I
was looking for!
Just one small thing...
When I tried this, editing /etc/setroubleshoot/setroubleshoot.cfg
and creating a file /var/lib/setroubleshoot/email_alert_recipients it
didn't work. I looked at this wiki entry
http://fedoraproject.org/wiki/Docs/Drafts/SELinux/SETroubleShoot/UserFAQ#...
and it said essentially exactly the same thing. It also said that that I
could use the sealert GUI to set the mailing settings, so I SSH'd into
my serving using a forwarded X server and tried that. It worked!
The strange thing is that the wiki says that the GUI method simply
modifies the same file (which makes sense), but I used a different email
address and the old email address (which doesn't work) is still in that file with no sign of
the new one (which works!).
Ho hum... I suppose I goofed somewhere along the line. I'll look into it
with a little more care when I get the chance. In the meantime, the
important thing is it works!
Thanks again, your help is greatly appreciated.
Mark
16 years, 1 month
here a few issues I have
by Valent Turkovic
Here are few issues I have in my selinux troubleshooter.
I have tested wicd wireless manager instead of NM and that got selinux
in a full alert mode... please check out fedora devel mailing for
links to wich packages because they aren't still in fedora
repositories.
Valent.
--
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic
16 years, 2 months
Bash script problem [OT]
by Arthur Dent
Hello all,
I run my F8 SELinux machine headless, and administer it through ssh.
This means I don't easily have many of the graphical tools available to
help.
During the early stages of my transition to "enforcing" mode I want to
keep a close eye on denials but of course I don't have the wonderful
sealert graphical troubleshooter popping up each time something happens.
So I have written this little script to check the logs using a cron job
every ten minutes. (NB I'm no expert in bash scripting - that much
should be obvious!)
The script itself works just fine when run from the command line as
root. When run from cron however (still as root), no matter what denials
there have been, ausearch *always* returns "<no matches>". I have tried
this by putting the ausearch command on a line of its own, and even with
the command ausearch -m AVC -ts yesterday (when there *were* denials) it
returns "<no matches>" wehre running the exact same command from the
command line produces the correct output.
I have no idea why this doesn't work - environment variables perhaps?
Any bash script gurus out there?
Thanks
Mark
=====8<===============================================================
#!/bin/bash
# selinux_avc_check.sh
# This script uses the "ausearch" tool which reads the SELinux
# /var/log/audit/audit.log file.
# The "-m AVC" means search for the term AVC (denial).
# The "-ts recent" means in the last 10 minutes
# If there are no AVC denials it will report "<no matches>"
# and all will be well.
# If there is any other output (i.e there has been a denial) it
# will send an email to root to check the logs.
# It is designed to be run as a cron job every 10 mins
# */10 * * * * /root/scripts/selinux_avc_check.sh
if /sbin/ausearch -m AVC -ts recent 2>&1| grep -q no\ matches
then
exit 1
else
echo "SELinux AVC Denial - please check the logs!" |mail -s "SELinux AVC Denial!" root
fi
=====8<===============================================================
16 years, 2 months