October 2007 - selinux - Fedora Mailing-Lists

Re: [busybox:01282] Re: BUG? in mkswap (Re: The current status of sebusybox project)

by KaiGai Kohei

Karel Zak wrote: > On Wed, Oct 10, 2007 at 01:48:49PM +0900, KaiGai Kohei wrote: >> Can I consider that you are the most appropriate person to report >> about the following matter? > > Yes. > >> Pay attention around line 741. >> If fgetfilecon() fails and returns -ENODATA, context_new() will be >> called with uninitialized oldcontext in the next. Then, it cause >> a segmentation fault. > > Thanks for your patch. Applied to upstream repository. (I've added > "Signed-off-by: KaiGai Kohei <kaigai(a)kaigai.gr.jp>", I hope you > agree.) I agree the additional "Signed-off-by:" line, of course. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai(a)ak.jp.nec.com>

16 years, 6 months

1
0
0 / 0

Re: SELinux revisited

by Steve G

> >All of those rules look fine for audit package > 1.3 and > > kernel probably > 2.6.21. But those rules are not default > > and would have taken some research to come up with > > since I know of no public examples of auditing by selinux > > context. > > So what should line 15 look like today? There is no line 15. The default audit rules are simply 14 lines ending with feel free to add rules below this. And that is where all your problems are. The audit by obj_type would have a very esoteric use and would encode knowledge of a specific selinux policy, so its not something I'd ever ship by default - even in sample rules. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

16 years, 6 months

1
0
0 / 0

Re: SELinux revisited

by Steve G

>> # This file contains the auditctl rules that are loaded >> # whenever the audit daemon is started via the initscripts. >> # The rules are simply the parameters that would be passed >> # to auditctl. >> >> # First rule - delete all >> -D >> >> # Increase the buffers to survive stress events. >> # Make this bigger for busy systems >> -b 320 >> >> # Feel free to add below this line. See auditctl man page >> >> -a exit,always -S chroot >> #-a exit,always -S chdir -F obj_type=dhclient_t > >I don't know the rule syntax, but just looking at the source, it appears >to me that the rule on line 15 is malformed (at least compared to the >others). All of those rules look fine for audit package > 1.3 and kernel probably > 2.6.21. But those rules are not default and would have taken some research to come up with since I know of no public examples of auditing by selinux context. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

16 years, 6 months

2
1
0 / 0

Re: SELinux revisited

by Steve G

Hi, >>> But the next reboot then had auditd advise me there was an error in line >>> 16 of /etc/audit/auditd.rules. Which audit package are you using? FWIW, audit and selinux are different subsystems. If you have audit problems, it would be more helpful to change the subject line so that it catches my attention. I do not read every SE Linux email. :) >-a exit,always -S chroot >#-a exit,always -S chdir -F obj_type=dhclient_t >----------- >Now it seems to me that those rules were there for a reason, and to have to >comment all but the first one out to get rid of the error: These are not default audit rules. you or someone with access to your machine would have put these there. Did they work when you originally installed them and they quit working recently? >Starting auditd: [ OK ] >Error sending add rule data request (Unknown error 524) >There was an error in line 27 of /etc/audit/audit.rules To know what is happening, I'd need to know your audit package version and kernel version. And then I'd need to see the actual rule and an strace of loading just that one rule from the command line. >isn't the real problem, so what do the experts here think? The audit system compliments SE Linux in that it records the results of Access Vector Calculations (AVCs) whenever the rules say to. But SE Linux will work without the audit system. >SELinux is running in permissive mode, and seems to be logging res=success for >everything so far, SE Linux does not record "res=" fields. That is the audit system doing its normal stuff. To see if you have denials, I'd run the summary report: "aureport --start today" to see if you have anything in the avc row. If so, you can ;look deeper with "aureport --start today --avc -i" You would look for denied in the second to last column of each row. An example: 1. 10/15/2007 20:14:07 vpnc-script user_u:system_r:vpnc_t:s0 stat file getattr system_u:object_r:var_run_t:s0 denied 180 >Would it have logged res=denied for anything if set to permissive? You need to look for "denied" in avc records. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

16 years, 6 months

1
0
0 / 0

allowing in.tftpd to read/write files?

by Chuck Anderson

How do I allow tftpd to write files? I changed the context to "system_u:object_r:public_content_rw_t:s0" but that doesn't work. Also I'm using /var/tftp instead of /tftpboot, and there doesn't seem to be any file_contexts set up for /var/tftp. I manually set the context to match that of /tftpboot: drwxr-xr-x root root system_u:object_r:tftpdir_t /tftpboot// drwxrwsr-x tftp tftp system_u:object_r:tftpdir_t /var/tftp/ -rw-rw-rw- cra tftp system_u:object_r:public_content_rw_t /var/tftp/testfile type=AVC msg=audit(1192818715.964:10131): avc: denied { write } for pid=15860 comm="in.tftpd" name="testfile" dev=dm-4 ino=84549655 scontext=user_u:system_r:tftpd_t:s0 tcontext=system_u:object_r:public_content_rw_t:s0 tclass=file type=SYSCALL msg=audit(1192818715.964:10131): arch=40000003 syscall=5 success=no exit=-13 a0=805fa02 a1=8041 a2=1b6 a3=8041 items=0 ppid=15781 pid=15860 auid=10002 uid=99 gid=99 euid=99 suid=99 fsuid=99 egid=99 sgid=99 fsgid=99 tty=(none) comm="in.tftpd" exe="/usr/sbin/in.tftpd" subj=user_u:system_r:tftpd_t:s0 key=(null) Thanks.

16 years, 6 months

4
5
0 / 0

Question About Amavisd audit messages

by Ali Nebi

Hi, i want to ask about some audit messages realted with amavisd. I get this kind of messages: Oct 16 16:35:21 hermod kernel: audit(1192545321.959:4): avc: denied { name_bind } for pid=15305 comm="amavisd" src=3551 scontext=system_u:system_r:amavis_t:s0 tcontext=system _u:object_r:apcupsd_port_t:s0 tclass=udp_socket Oct 17 06:41:11 hermod kernel: audit(1192596071.584:5): avc: denied { name_bind } for pid=1135 comm="amavisd" src=5353 scontext=system_u:system_r:amavis_t:s0 tcontext=system_ u:object_r:howl_port_t:s0 tclass=udp_socket Oct 17 14:45:13 hermod kernel: audit(1192625113.850:6): avc: denied { name_bind } for pid=8183 comm="amavisd" src=7004 scontext=system_u:system_r:amavis_t:s0 tcontext=system_ u:object_r:afs_ka_port_t:s0 tclass=udp_socket Oct 17 22:33:30 hermod kernel: audit(1192653210.933:7): avc: denied { name_bind } for pid=20082 comm="amavisd" src=7004 scontext=system_u:system_r:amavis_t:s0 tcontext=system _u:object_r:afs_ka_port_t:s0 tclass=udp_socket Oct 17 23:00:40 hermod kernel: audit(1192654840.481:8): avc: denied { name_bind } for pid=21759 comm="amavisd" src=7007 scontext=system_u:system_r:amavis_t:s0 tcontext=system _u:object_r:afs_bos_port_t:s0 tclass=udp_socket Oct 18 08:59:38 hermod kernel: audit(1192690778.529:9): avc: denied { name_bind } for pid=25286 comm="amavisd" src=5353 scontext=system_u:system_r:amavis_t:s0 tcontext=system _u:object_r:howl_port_t:s0 tclass=udp_socket Oct 18 09:32:09 hermod kernel: audit(1192692729.031:10): avc: denied { name_bind } for pid=28781 comm="amavisd" src=1194 scontext=system_u:system_r:amavis_t:s0 tcontext=syste m_u:object_r:openvpn_port_t:s0 tclass=udp_socket These are a part of them, i allowed some of these, but there are many of these with different udp ports. What can i do to solve this problem, because amavisd try every time with a different port and i can't allow all of them? Thank in advanced!

16 years, 6 months

2
1
0 / 0

Re: SELinux revisited

by Gene Heskett

On Thursday 18 October 2007, Gene Heskett wrote: >On Thursday 18 October 2007, Andy Green wrote: >>Somebody in the thread at some point said: >>> Greetings; >>> >>> Running 2.6.23 here, on a AMD XP-2800, gig of ram, lots of drive. >>> >>> I thought maybe I should give selinux another chance here. So I removed >>> the selinux=0 in my grub.conf, and edited its .conf file in >>> /etc/sysconfig to set it for permissive. >>> >>> On the reboot, the relabel wasn't done, so I looked around and reset a >>> fresh /.autorelabel file and rebooted again. It was already present >>> however. >>> >>> This time it did a very short autorelabel, maybe 2 screens full and was >>> done in just a couple of seconds, at which point it went into yet another >>> reboot cycle making me think it was stuck in a loop or something. >> >>Sounds like you are going about it in a good way FWIW. >> >>> But the next reboot then had auditd advise me there was an error in line >>> 16 of /etc/audit/auditd.rules. >> >>That file looks like this here, in full: >> >># This file contains the auditctl rules that are loaded >># whenever the audit daemon is started via the initscripts. >># The rules are simply the parameters that would be passed >># to auditctl. >> >># First rule - delete all >>-D >> >># Increase the buffers to survive stress events. >># Make this bigger for busy systems >>-b 320 >> >># Feel free to add below this line. See auditctl man page >> >> >>Here's the state of the selinux packages here for reference >> >># rpm -qa | grep selinux >>libselinux-2.0.14-9.fc7 >>libselinux-python-2.0.14-9.fc7 >>selinux-policy-targeted-2.6.4-48.fc7 >>selinux-policy-2.6.4-48.fc7 >># rpm -qa | grep audit >>audit-libs-python-1.5.6-2.fc7 >>audit-libs-1.5.6-2.fc7 >>audit-1.5.6-2.fc7 > >All fc6 here, but uptodate. > >># chkconfig --list | grep audit >>auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off >> >>I would nuke the entries at the end of your /etc/audit/auditd.rules and >>retry. > >I'll give that a shot tomorrow, its getting sleepy out around here, 4am & > I've already lost any chance at beauty sleep, which wouldn't help at my age > anyway. :) > >>-Andy > >Thanks Andy. > Ok, up again, nuked a pint of coffee but its too hot yet. I commented that line 16 in audit.rules, and it moved the error to line 17, so I commented that one too. Step & repeat until there is only one active line in the file, line 15. -------------- # This file contains the auditctl rules that are loaded # whenever the audit daemon is started via the initscripts. # The rules are simply the parameters that would be passed # to auditctl. # First rule - delete all -D # Increase the buffers to survive stress events. # Make this bigger for busy systems -b 320 # Feel free to add below this line. See auditctl man page -a exit,always -S chroot #-a exit,always -S chdir -F obj_type=dhclient_t #-a exit,always -S chdir -F obj_type=sendmail_t #-a exit,always -S chdir -F obj_type=mcstransd_t #-a exit,always -S chdir -F obj_type=sshd_t #-a exit,always -S chdir -F obj_type=ntpd_t #-a exit,always -S chdir -F obj_type=samba_t #-a exit,always -S chdir -F obj_type=named_t #-a exit,always -S chdir -F obj_type=klogd_t #-a exit,always -S chdir -F obj_type=crond_t #-a exit,always -S chdir -F obj_type=httpd_t #-a exit,always -S chdir -F obj_type=auditd_t #-a exit,always -S chdir -F obj_type=portmap_t #-a exit,always -S chdir -F obj_type=syslogd_t ----------- Now it seems to me that those rules were there for a reason, and to have to comment all but the first one out to get rid of the error: --------- [root@coyote audit]# service auditd restart Stopping auditd: [ OK ] Starting auditd: [ OK ] Error sending add rule data request (Unknown error 524) There was an error in line 27 of /etc/audit/audit.rules [root@coyote audit]# vim audit.rules [root@coyote audit]# service auditd restart Stopping auditd: [ OK ] Starting auditd: [ OK ] ---------- isn't the real problem, so what do the experts here think? SELinux is running in permissive mode, and seems to be logging res=success for everything so far, so it may be possible to set it to targeted. I figured if I tried it on a known, fully working system, that would be a hell of a lot more accurate test than trying to make it work on a fresh install, which forced me to disable it months ago. Would it have logged res=denied for anything if set to permissive? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) A Vulcan can no sooner be disloyal than he can exist without breathing. -- Kirk, "The Menagerie", stardate 3012.4

16 years, 6 months

3
2
0 / 0

setroubleshoot question: database.xml ?

by Tom London

I noticed that the initscript for setroubleshoot has a 'cleardb' entry that refers to /var/lib/setroubleshoot/database.xml: cleardb(){ running=0 [ -e /var/lock/subsys/$prog ] && running=1 [ $running == 1 ] && stop echo $"Clearing database" rm -f /var/lib/setroubleshoot/database.xml [ $running == 1 ] && start return 0 } But I don't seem to have that file: [tbl@localhost init.d]$ ls -l /var/lib/setroubleshoot total 256 -rw------- 1 root root 251139 2007-10-11 09:42 audit_listener_database.xml [tbl@localhost init.d]$ /usr/lib/python2.5/site-packages/setroubleshoot/config.py refers to audit_listener: 'database' : { 'database_dir' : { 'value' : '/var/lib/setroubleshoot', 'description' : '', }, 'filename' : { 'value' : 'audit_listener', 'description' : '', Is there a mismatch here? My over reading? tom -- Tom London

16 years, 6 months

2
2
0 / 0

policycoreutils version

by Clarkson, Mike R (US SSA)

Is "policycoreutils 2.0.19 or later" available as a Red Hat rpm or do I need to download this from another source? It's much easier for me to get approval to download directly from Red Hat then from other sources but it looks like 1.33.12 is the current version from Red Hat. > -----Original Message----- > From: Stephen Smalley [mailto:sds@tycho.nsa.gov] > Sent: Tuesday, October 16, 2007 4:56 AM > To: Clarkson, Mike R (US SSA) > Cc: selinux(a)tycho.nsa.gov; Joshua Brindle > Subject: Re: newrole authentication > > On Mon, 2007-10-15 at 16:12 -0700, Clarkson, Mike R (US SSA) wrote: > > Will someone point me to information or send me an example on how to set > > up newrole so that is does not ask for a password, so that it can by > > used like this within software "newrole -l s1 -- -c <cmd>"? > > You need policycoreutils 2.0.19 or later, or you need to back port that > change to whatever newrole you have. > > See: > http://marc.info/?t=117769973100008&r=1&w=2 > http://marc.info/?l=selinux&m=117865153827263&w=2 > > Then you can set up a /etc/selinux/newrole_pam.conf file with e.g.: > /path/to/cmd newrole-noauth > and you can set up a /etc/pam.d/newrole-noauth file with pam_permit.so > as the auth module. > > -- > Stephen Smalley > National Security Agency

16 years, 6 months

1
0
0 / 0

Re: SELinux problem after sendmail.mc modification.

by Doug Thistlethwaite

David, Thanks for the quick reply. I answered your questions in-line below: David Caplan wrote: > Doug, > > > ... >> My mail server was working fine secured by SELinux running in enforcing mode. Our company lost connection the the Internet for a couple days so I edited sendmail.mc to skip the domain check for the duration. I edited the file ran MAKE and restarted the sendmail process. I also disabled spamd because all of the email would be internal. >> >> > > Did you do all of the above as root/unconfined_t? The most likely > problem (at least at that point) was a labeling problem. As you are > running targeted policy it should not have caused a problem. > > I assume that I did. I was logged in as root and did not even know until know that something called unconfirmed_t existed. Initially, I entered the commands suggested by setroubleshoot. > >> Well SELinux didn't like what I did and started to produce lots of AVC >> messages and provided solutions to most of them. I followed the >> suggestion in the "Allowing Access" section of the setroubleshoot >> browser and most of the messages went away. >> > > Does that mean you added a local policy module? > I don't think so. I entered commands like the following: (Copied from my command buffer) chcon -t httpd_sys_content_t /etc/mail/local-host-names chcon -t httpd_sys_content_t /etc/mail/trusted-users chcon -t httpd_sys_content_t submit.cf chcon -t httpd_sys_content_t clientmqueue chcon -t httpd_sys_content_t anon_inode:[eventpoll] The last one wouldn't work and this is when I decided to just disable SELinux until my internet connection was restored. > >> After about a dozen of these >> messages, I decided to just have the system "relabel on next reboot" >> using the SELinux management tool. When that didn't fix the problem, I >> just disabled SELinux until the Internet connection was fixed. >> >> So the connection was fixed, I fixed the sendmail.mc file to be exactly the same as before the problem. I used MAKE on the file and relabeled >> the SELinux during a reboot and reset SELinux to enforcement mode. Spamd will not start in enforcement mode. I get the following >> setroubleshoot message: >> >> > > The indication below (in the "Additional Information" section) says that > you are in Permissive, not Enforcing. Of course, things should work in > Permissive mode. > > Yes, I switch to Permissive mode so my users were not burried in spam. The same messages were there in Enforcing mode. >> Summary >> SELinux is preventing spamd (spamd_t) "search" to mail >> (httpd_sys_content_t). >> >> > > It doesn't seem like spamd should need access to httpd* files. If you > are in Permissive mode that may not be what your problem is. What is the > file related to this message (i.e., the path of the target directory > that is labeled with httpd_sys_content_t)? > I have no idea. The information in my first message is everything that was dsiplayed in setroubleshoot window. Other messages in the setroubleshoot window show file names, but this one doesn't. How would I find this out? > >> Detailed Description >> SELinux denied access requested by spamd. It is not expected that this >> access is required by spamd and this access may signal an intrusion >> attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. >> >> Allowing Access >> Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for mail, restorecon -v mail If >> >> this does not work, there is currently no automatic way to allow this >> access. Instead, you can generate a local policy module to allow this >> access - see FAQ Or you can disable SELinux protection altogether. >> Disabling SELinux protection is not recommended. Please file a bug >> report against this package. >> >> Additional Information >> Source Context: system_u:system_r:spamd_t >> Target Context: system_u:object_r:httpd_sys_content_t >> Target Objects: mail [ dir ] >> Affected RPM Packages: >> Policy RPM: selinux-policy-2.6.4-46.fc7 >> Selinux Enabled: TruePolicy Type: targetedMLS Enabled: True >> Enforcing Mode: Permissive >> Plugin Name: plugins.catchall_file >> >> >> When I ran the suggested fix "restorecon -v mail" I get the following >> error message: >> lstat(mail) failed: No such file or directory >> >> > > I think you want to run this in the directory above the mail directory > (e.g., this is typically /etc). Everything in /etc/mail should be > labeled with etc_mail_t. You should also run it with -R. For example: > # restorecon -v mail > lstat(mail) failed: No such file or directory > # cd /etc > # restorecon -v mail > # chcon -t file_t mail/sendmail.mc > # restorecon -v mail > # ls -Z mail/sendmail.mc > -rw-r--r-- root root system_u:object_r:file_t mail/sendmail.mc > # restorecon -Rv mail > restorecon reset /etc/mail/sendmail.mc context > system_u:object_r:file_t:s0->system_u:object_r:etc_mail_t:s0 > # > > I ran the suggested commands and restarted sendmail, spamassassin and I did the same restorecon command for any file listed in the error messages. After this I sent an email through a web interface. I got the following errors in setroubleshoot: #1 Summary SELinux is preventing spamd (spamd_t) "search" to mail(httpd_sys_content_t). Detailed Description SELinux denied access requested by spamd. It is not expected that this access is required by spamd and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for mail, restorecon -v mail If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context root:system_r:spamd_t Target Context system_u:object_r:httpd_sys_content_t Target Objects mail [ dir ] Affected RPM Packages Policy RPM selinux-policy-2.6.4-46.fc7 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name plugins.catchall_file Host Name mail.dupreeinc.com Platform Linux mail.dupreeinc.com 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 Alert Count 1 First Seen Thu 11 Oct 2007 03:32:24 PM PDT Last Seen Thu 11 Oct 2007 03:32:24 PM PDT Local ID d478c85c-d36f-4fa3-9371-2ab3f4bb05f5 Line Numbers Raw Audit Messages avc: denied { search } for comm="spamd" dev=dm-0 egid=0 euid=0 exe="/usr/bin/perl" exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="mail" pid=31883 scontext=root:system_r:spamd_t:s0 sgid=0 subj=root:system_r:spamd_t:s0 suid=0 tclass=dir tcontext=system_u:object_r:httpd_sys_content_t:s0 tty=pts1 uid=0 #2 Summary SELinux is preventing the /usr/sbin/sendmail.sendmail from using potentially mislabeled files submit.cf (etc_mail_t). Detailed Description SELinux has denied the /usr/sbin/sendmail.sendmail access to potentially mislabeled files submit.cf. This means that SELinux will not allow http to use these files. Many third party apps install html files in directories that SELinux policy can not predict. These directories have to be labeled with a file context which httpd can accesss. Allowing Access If you want to change the file context of submit.cf so that the httpd daemon can access it, you need to execute it using chcon -t httpd_sys_content_t submit.cf. You can look at the httpd_selinux man page for additional information. Additional Information Source Context system_u:system_r:httpd_sys_script_t Target Context system_u:object_r:etc_mail_t Target Objects submit.cf [ file ] Affected RPM Packages sendmail-8.14.1-4.2.fc7 [application] Policy RPM selinux-policy-2.6.4-46.fc7 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name plugins.httpd_bad_labels Host Name mail.dupreeinc.com Platform Linux mail.dupreeinc.com 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 Alert Count 1 First Seen Thu 11 Oct 2007 03:33:03 PM PDT Last Seen Thu 11 Oct 2007 03:33:03 PM PDT Local ID e67e0ecc-909e-44ba-8a80-106228c8e348 Line Numbers Raw Audit Messages avc: denied { read } for comm="sendmail" dev=dm-0 egid=51 euid=48 exe="/usr/sbin/sendmail.sendmail" exit=3 fsgid=51 fsuid=48 gid=48 items=0 name="submit.cf" pid=31906 scontext=system_u:system_r:httpd_sys_script_t:s0 sgid=51 subj=system_u:system_r:httpd_sys_script_t:s0 suid=48 tclass=file tcontext=system_u:object_r:etc_mail_t:s0 tty=(none) uid=48 #3 Summary SELinux is preventing the /usr/sbin/sendmail.sendmail from using potentially mislabeled files /etc/mail/submit.cf (etc_mail_t). Detailed Description SELinux has denied the /usr/sbin/sendmail.sendmail access to potentially mislabeled files /etc/mail/submit.cf. This means that SELinux will not allow http to use these files. Many third party apps install html files in directories that SELinux policy can not predict. These directories have to be labeled with a file context which httpd can accesss. Allowing Access If you want to change the file context of /etc/mail/submit.cf so that the httpd daemon can access it, you need to execute it using chcon -t httpd_sys_content_t /etc/mail/submit.cf. You can look at the httpd_selinux man page for additional information. Additional Information Source Context system_u:system_r:httpd_sys_script_t Target Context system_u:object_r:etc_mail_t Target Objects /etc/mail/submit.cf [ file ] Affected RPM Packages sendmail-8.14.1-4.2.fc7 [application]sendmail-8.14.1-4.2.fc7 [target] Policy RPM selinux-policy-2.6.4-46.fc7 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name plugins.httpd_bad_labels Host Name mail.dupreeinc.com Platform Linux mail.dupreeinc.com 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 Alert Count 1 First Seen Thu 11 Oct 2007 03:33:03 PM PDT Last Seen Thu 11 Oct 2007 03:33:03 PM PDT Local ID 10bd0547-6b5c-4b86-96e6-6bb16af2a64d Line Numbers Raw Audit Messages avc: denied { getattr } for comm="sendmail" dev=dm-0 egid=51 euid=48 exe="/usr/sbin/sendmail.sendmail" exit=0 fsgid=51 fsuid=48 gid=48 items=0 name="submit.cf" path="/etc/mail/submit.cf" pid=31906 scontext=system_u:system_r:httpd_sys_script_t:s0 sgid=51 subj=system_u:system_r:httpd_sys_script_t:s0 suid=48 tclass=file tcontext=system_u:object_r:etc_mail_t:s0 tty=(none) uid=48 #4 Summary SELinux is preventing /usr/sbin/sendmail.sendmail (httpd_sys_script_t) "create" to <Unknown> (httpd_sys_script_t). Detailed Description SELinux denied access requested by /usr/sbin/sendmail.sendmail. It is not expected that this access is required by /usr/sbin/sendmail.sendmail and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access You can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context system_u:system_r:httpd_sys_script_t Target Context system_u:system_r:httpd_sys_script_t Target Objects None [ unix_dgram_socket ] Affected RPM Packages sendmail-8.14.1-4.2.fc7 [application] Policy RPM selinux-policy-2.6.4-46.fc7 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name plugins.catchall Host Name mail.dupreeinc.com Platform Linux mail.dupreeinc.com 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 Alert Count 1 First Seen Thu 11 Oct 2007 03:33:03 PM PDT Last Seen Thu 11 Oct 2007 03:33:03 PM PDT Local ID ef574580-2190-4edc-8e54-b92181831531 Line Numbers Raw Audit Messages avc: denied { create } for comm="sendmail" egid=51 euid=48 exe="/usr/sbin/sendmail.sendmail" exit=3 fsgid=51 fsuid=48 gid=48 items=0 pid=31906 scontext=system_u:system_r:httpd_sys_script_t:s0 sgid=51 subj=system_u:system_r:httpd_sys_script_t:s0 suid=48 tclass=unix_dgram_socket tcontext=system_u:system_r:httpd_sys_script_t:s0 tty=(none) uid=48 #5 Summary SELinux is preventing /usr/sbin/sendmail.sendmail (httpd_sys_script_t) "sendto" to /dev/log (syslogd_t). Detailed Description SELinux denied access requested by /usr/sbin/sendmail.sendmail. It is not expected that this access is required by /usr/sbin/sendmail.sendmail and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access You can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context system_u:system_r:httpd_sys_script_t Target Context system_u:system_r:syslogd_t Target Objects /dev/log [ unix_dgram_socket ] Affected RPM Packages sendmail-8.14.1-4.2.fc7 [application] Policy RPM selinux-policy-2.6.4-46.fc7 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name plugins.catchall Host Name mail.dupreeinc.com Platform Linux mail.dupreeinc.com 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 Alert Count 1 First Seen Thu 11 Oct 2007 03:33:03 PM PDT Last Seen Thu 11 Oct 2007 03:33:03 PM PDT Local ID 831be357-c006-4d42-8ab7-1634e2035ef4 Line Numbers Raw Audit Messages avc: denied { sendto } for comm="sendmail" dev=tmpfs egid=51 euid=48 exe="/usr/sbin/sendmail.sendmail" exit=0 fsgid=51 fsuid=48 gid=48 items=0 name="log" path="/dev/log" pid=31906 scontext=system_u:system_r:httpd_sys_script_t:s0 sgid=51 subj=system_u:system_r:httpd_sys_script_t:s0 suid=48 tclass=unix_dgram_socket tcontext=system_u:system_r:syslogd_t:s0 tty=(none) uid=48 #6 Summary SELinux is preventing /usr/sbin/sendmail.sendmail (httpd_sys_script_t) "write" to <Unknown> (httpd_sys_script_t). Detailed Description SELinux denied access requested by /usr/sbin/sendmail.sendmail. It is not expected that this access is required by /usr/sbin/sendmail.sendmail and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access You can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context system_u:system_r:httpd_sys_script_t Target Context system_u:system_r:httpd_sys_script_t Target Objects None [ unix_dgram_socket ] Affected RPM Packages sendmail-8.14.1-4.2.fc7 [application] Policy RPM selinux-policy-2.6.4-46.fc7 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name plugins.catchall Host Name mail.dupreeinc.com Platform Linux mail.dupreeinc.com 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 Alert Count 1 First Seen Thu 11 Oct 2007 03:33:03 PM PDT Last Seen Thu 11 Oct 2007 03:33:03 PM PDT Local ID a793410a-36e5-4685-b82a-c7a0ddee7c44 Line Numbers Raw Audit Messages avc: denied { write } for comm="sendmail" egid=51 euid=48 exe="/usr/sbin/sendmail.sendmail" exit=141 fsgid=51 fsuid=48 gid=48 items=0 pid=31906 scontext=system_u:system_r:httpd_sys_script_t:s0 sgid=51 subj=system_u:system_r:httpd_sys_script_t:s0 suid=48 tclass=unix_dgram_socket tcontext=system_u:system_r:httpd_sys_script_t:s0 tty=(none) uid=48 #7 Summary SELinux is preventing the /usr/sbin/sendmail.sendmail from using potentially mislabeled files anon_inode:[eventpoll] (anon_inodefs_t). Detailed Description SELinux has denied the /usr/sbin/sendmail.sendmail access to potentially mislabeled files anon_inode:[eventpoll]. This means that SELinux will not allow http to use these files. Many third party apps install html files in directories that SELinux policy can not predict. These directories have to be labeled with a file context which httpd can accesss. Allowing Access If you want to change the file context of anon_inode:[eventpoll] so that the httpd daemon can access it, you need to execute it using chcon -t httpd_sys_content_t anon_inode:[eventpoll]. You can look at the httpd_selinux man page for additional information. Additional Information Source Context system_u:system_r:httpd_sys_script_t Target Context system_u:object_r:anon_inodefs_t Target Objects anon_inode:[eventpoll] [ file ] Affected RPM Packages sendmail-8.14.1-4.2.fc7 [application] Policy RPM selinux-policy-2.6.4-46.fc7 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name plugins.httpd_bad_labels Host Name mail.dupreeinc.com Platform Linux mail.dupreeinc.com 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 Alert Count 1 First Seen Thu 11 Oct 2007 03:33:03 PM PDT Last Seen Thu 11 Oct 2007 03:33:03 PM PDT Local ID 5c2f5b86-899e-44d6-ba25-906180a5731d Line Numbers Raw Audit Messages avc: denied { read, write } for comm="sendmail" dev=anon_inodefs egid=51 euid=48 exe="/usr/sbin/sendmail.sendmail" exit=0 fsgid=51 fsuid=48 gid=48 items=0 name="[eventpoll]" path="anon_inode:[eventpoll]" pid=31906 scontext=system_u:system_r:httpd_sys_script_t:s0 sgid=51 subj=system_u:system_r:httpd_sys_script_t:s0 suid=48 tclass=file tcontext=system_u:object_r:anon_inodefs_t:s0 tty=(none) uid=48

16 years, 6 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux October 2007