From alex.slesarev at gmail.com Sat Dec 1 01:24:04 2007 From: alex.slesarev at gmail.com (Alex Slesarev) Date: Sat, 01 Dec 2007 11:24:04 +1000 Subject: CGI can't read public_html files Message-ID: <4750B7B4.1000305@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello! I want to access public_html files from CGI script, but can't do it - got AVC error during reading README file from public_html dir: - ----------------------------------------------------------------------- [root at elc6002s nuald]# tail /var/log/messages | grep setroubleshoot -m 1 Nov 29 13:42:51 elc6002s setroubleshoot: #012 SELinux is preventing the format.cgi from using potentially mislabeled files (unconfined_home_dir_t).#012 For complete SELinux messages. run sealert -l 69519bd7-3e77-46d9-b845-7f066c4515e6 - ----------------------------------------------------------------------- I have only one item with unconfined_home_dir_t type in the path to README file: - ----------------------------------------------------------------------- [nuald at elc6002s public_html]$ ls -Z `pwd`/README && pushd . > /dev/null && while [[ `pwd` != '/' ]]; do ls -Zd `pwd` && cd ..; done && popd > /dev/null - -rw-rw-r-- nuald nuald system_u:object_r:httpd_user_content_t:s0 /home/nuald/public_html/README drwxrwxr-x nuald nuald system_u:object_r:httpd_user_content_t:s0 /home/nuald/public_html drwx--x--x nuald nuald unconfined_u:object_r:unconfined_home_dir_t:s0 /home/nuald drwxr-xr-x root root system_u:object_r:home_root_t:s0 /home - ----------------------------------------------------------------------- So, only my home dir have unconfined_home_dir_t type. But I do not want to change it to httpd_sys_content_t type and I don't like this solution. The CGI script itself works fine either it have httpd_user_content_t type now: - ----------------------------------------------------------------------- [nuald at elc6002s cgi-bin]$ ls -Z `pwd`/format.cgi && pushd . > /dev/null && while [[ `pwd` != '/' ]]; do ls -Zd `pwd` && cd ..; done && popd > /dev/null - -rwxr-xr-x nuald nuald system_u:object_r:httpd_user_content_t:s0 /home/nuald/public_html/cgi-bin/format.cgi drwxr-xr-x nuald nuald system_u:object_r:httpd_user_content_t:s0 /home/nuald/public_html/cgi-bin drwxrwxr-x nuald nuald system_u:object_r:httpd_user_content_t:s0 /home/nuald/public_html drwx--x--x nuald nuald unconfined_u:object_r:unconfined_home_dir_t:s0 /home/nuald drwxr-xr-x root root system_u:object_r:home_root_t:s0 /home - ----------------------------------------------------------------------- So the script only can't read files in public_html folder. What is right way to fix it? The script itself is below and used as http://localhost/~nuald/cgi-bin/format.cgi?file=README - ----------------------------------------------------------------------- [nuald at elc6002s cgi-bin]$ cat format.cgi #!/usr/bin/perl -wT use strict; use CGI qw/:standard/; use IO::File; use File::Spec; use Cwd 'realpath'; print header; my $filename = param('file') or die "Can be executed only as CGI"; my $updir = File::Spec->updir(); my $rel_path = File::Spec->catfile($updir, $filename); my $path = realpath($rel_path) ; my $file = IO::File->new($path,"<") or die "Can't open file $path"; my $text = join "", <$file>; $file->close or die "Can't close file"; print $text; - ----------------------------------------------------------------------- Thanks in advance. - -- Best regards, Alex Slesarev. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHULe0NLNdFA8Hg1cRCBUOAJ9LhblT0DTYN5hs4HqDYzfNpt66MACgitJO hR0isSJ+FDxHy7C8Izc+y7k= =MDzY -----END PGP SIGNATURE----- From alex.slesarev at gmail.com Sat Dec 1 01:29:31 2007 From: alex.slesarev at gmail.com (Alex Slesarev) Date: Sat, 1 Dec 2007 11:29:31 +1000 Subject: CGI can't read public_html files Message-ID: <3e71d26a0711301729x4c07d9d7h27b3e93953e56609@mail.gmail.com> Hello! I want to access public_html files from CGI script, but can't do it - got AVC error during reading README file from public_html dir: ----------------------------------------------------------------------- [root at elc6002s nuald]# tail /var/log/messages | grep setroubleshoot -m 1 Nov 29 13:42:51 elc6002s setroubleshoot: #012 SELinux is preventing the format.cgi from using potentially mislabeled files (unconfined_home_dir_t).#012 For complete SELinux messages. run sealert -l 69519bd7-3e77-46d9-b845-7f066c4515e6 ----------------------------------------------------------------------- I have only one item with unconfined_home_dir_t type in the path to README file: ----------------------------------------------------------------------- [nuald at elc6002s public_html]$ ls -Z `pwd`/README && pushd . > /dev/null && while [[ `pwd` != '/' ]]; do ls -Zd `pwd` && cd ..; done && popd > /dev/null -rw-rw-r-- nuald nuald system_u:object_r:httpd_user_content_t:s0 /home/nuald/public_html/README drwxrwxr-x nuald nuald system_u:object_r:httpd_user_content_t:s0 /home/nuald/public_html drwx--x--x nuald nuald unconfined_u:object_r:unconfined_home_dir_t:s0 /home/nuald drwxr-xr-x root root system_u:object_r:home_root_t:s0 /home ----------------------------------------------------------------------- So, only my home dir have unconfined_home_dir_t type. But I do not want to change it to httpd_sys_content_t type and I don't like this solution. The CGI script itself works fine either it have httpd_user_content_t type now: ----------------------------------------------------------------------- [nuald at elc6002s cgi-bin]$ ls -Z `pwd`/format.cgi && pushd . > /dev/null && while [[ `pwd` != '/' ]]; do ls -Zd `pwd` && cd ..; done && popd > /dev/null -rwxr-xr-x nuald nuald system_u:object_r:httpd_user_content_t:s0 /home/nuald/public_html/cgi-bin/format.cgi drwxr-xr-x nuald nuald system_u:object_r:httpd_user_content_t:s0 /home/nuald/public_html/cgi-bin drwxrwxr-x nuald nuald system_u:object_r:httpd_user_content_t:s0 /home/nuald/public_html drwx--x--x nuald nuald unconfined_u:object_r:unconfined_home_dir_t:s0 /home/nuald drwxr-xr-x root root system_u:object_r:home_root_t:s0 /home ----------------------------------------------------------------------- So the script only can't read files in public_html folder. What is right way to fix it? The script itself is below and used as http://localhost/~nuald/cgi-bin/format.cgi?file=README ----------------------------------------------------------------------- [nuald at elc6002s cgi-bin]$ cat format.cgi #!/usr/bin/perl -wT use strict; use CGI qw/:standard/; use IO::File; use File::Spec; use Cwd 'realpath'; print header; my $filename = param('file') or die "Can be executed only as CGI"; my $updir = File::Spec->updir(); my $rel_path = File::Spec->catfile($updir, $filename); my $path = realpath($rel_path) ; my $file = IO::File->new($path,"<") or die "Can't open file $path"; my $text = join "", <$file>; $file->close or die "Can't close file"; print $text; ----------------------------------------------------------------------- Thanks in advance. -- Best regards, Alex Slesarev. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora02 at grifent.com Sat Dec 1 07:49:35 2007 From: fedora02 at grifent.com (John Griffiths) Date: Sat, 01 Dec 2007 02:49:35 -0500 Subject: selinux preventing clamd and amavisd even in Permissive Message-ID: <4751120F.8090601@grifent.com> I am getting numerous AVCs from selinixtrobleshoot when clamd and amavisd try to operate even with selinux in Permissive mode the actions are still prevented. I did a touch /.autorelabel before reporting this. The problem still occurs. An example: Summary SELinux is preventing /usr/bin/clamscan (clamscan_t) "read" to (amavis_spool_t). Detailed Description SELinux denied access requested by /usr/bin/clamscan. It is not expected that this access is required by /usr/bin/clamscan 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 , restorecon -v 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 system_u:system_r:clamscan_t Target Context system_u:object_r:amavis_spool_t Target Objects None [ dir ] Affected RPM Packages clamav-0.91.2-3.fc8 [application] Policy RPM selinux-policy-3.0.8-56.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name plugins.catchall_file Host Name joe Platform Linux joe 2.6.23.1-49.fc8 #1 SMP Thu Nov 8 21:41:26 EST 2007 i686 i686 Alert Count 7 First Seen Sat 01 Dec 2007 02:13:33 AM EST Last Seen Sat 01 Dec 2007 02:23:33 AM EST Local ID d41e6d82-4a90-48ee-a554-3c557f6cfe61 Line Numbers Raw Audit Messages avc: denied { read } for comm=clamscan dev=dm-0 egid=490 euid=495 exe=/usr/bin/clamscan exit=6 fsgid=490 fsuid=495 gid=490 items=0 name=clamav- f1269664cac0bef43a67b3a6dbae41b8 pid=2785 scontext=system_u:system_r:clamscan_t:s0 sgid=490 subj=system_u:system_r:clamscan_t:s0 suid=495 tclass=dir tcontext=system_u:object_r:amavis_spool_t:s0 tty=(none) uid=495 There are others, but selinux should only log the AVCs in Permissive. Right? But the selinux system is actually doing denials. The email system will not work since the emails cannot be virus checked. Glad this is a test installation. There was a problem in Fedora Core 6 with Postfix, amavisd, and clamd as I remember it, but it would run in Permissive. I will post all the the AVCs later, but I thought this was important. Regards, John From jdennis at redhat.com Sat Dec 1 14:51:38 2007 From: jdennis at redhat.com (John Dennis) Date: Sat, 01 Dec 2007 09:51:38 -0500 Subject: selinux preventing clamd and amavisd even in Permissive In-Reply-To: <4751120F.8090601@grifent.com> References: <4751120F.8090601@grifent.com> Message-ID: <475174FA.4020503@redhat.com> > There are others, but selinux should only log the AVCs in Permissive. > Right? But the selinux system is actually doing denials. Just for clarification, setroubleshoot will still report a denial in permissive mode because it is logged as a denial by the audit system, however the action should still be permitted. There is an open bug report requesting the text in the setroubleshoot message to be modified when the system is in permissive mode to say "SELinux would have denied" instead of denied. We're going to be fixing that, it's not quite as trivial as it seems because all the messages have been translated into other languages so you can't just do a simple string substitution and retain correct grammar in another language, but we will be fixing this one way or another. In theory if you're spam filtering is not working it shouldn't be because SELinux is actually denying anything because you're in permissive mode. I would first look elsewhere. I'm not saying it's impossible it's SELinux, but because you're in permissive mode it's very unlikely. -- John Dennis From fedora02 at grifent.com Sat Dec 1 16:57:33 2007 From: fedora02 at grifent.com (John Griffiths) Date: Sat, 01 Dec 2007 11:57:33 -0500 Subject: selinux preventing clamd and amavisd even in Permissive In-Reply-To: <475174FA.4020503@redhat.com> References: <4751120F.8090601@grifent.com> <475174FA.4020503@redhat.com> Message-ID: <4751927D.30606@grifent.com> An HTML attachment was scrubbed... URL: From selinux at gmail.com Sun Dec 2 00:19:02 2007 From: selinux at gmail.com (Tom London) Date: Sat, 1 Dec 2007 16:19:02 -0800 Subject: usbfs, updpwd_t, gdm (xdm_t) avcs with today's rawhide Message-ID: <4c4ba1530712011619k2823a3acqd2c6756c9b8e7a0@mail.gmail.com> Today's gdm is finally runnable for me, and with gcc-4.1.2-33, I can compile newest kernel (2.6.24-0.61.rc3.git5.local.fc9). However, a bunch of AVCs: #============= mount_t ============== allow mount_t usbfs_t:dir { read ioctl }; #============= updpwd_t ============== allow updpwd_t tty_device_t:chr_file { read write }; #============= xdm_t ============== allow xdm_t gconfd_exec_t:file { read execute execute_no_trans }; allow xdm_t inotifyfs_t:dir getattr; allow xdm_t self:netlink_selinux_socket { read bind create }; allow xdm_t system_dbusd_exec_t:file { read execute execute_no_trans }; allow xdm_t system_dbusd_t:dbus acquire_svc; allow xdm_t var_lib_t:file { rename unlink append }; allow xdm_t var_log_t:file write; The mount_t/usbfs_t ones come early in boot. Without adding rules for the xdm_t ones (at least some of them), graphical login fails with 'X respawn too fast' messages. I attach the AVCs from /var/log/messages and /var/log/audit/audit.log tom -- Tom London -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: log.txt URL: From fedora02 at grifent.com Sun Dec 2 01:47:42 2007 From: fedora02 at grifent.com (John Griffiths) Date: Sat, 01 Dec 2007 20:47:42 -0500 Subject: selinux preventing clamd and amavisd even in Permissive In-Reply-To: <20071201170009.564737392C@hormel.redhat.com> References: <20071201170009.564737392C@hormel.redhat.com> Message-ID: <47520EBE.9050900@grifent.com> OK. I am baffled. I went out to do some shopping and when I came back, everything was working. And no one else was working on the system either. There are a couple of AVCs but they don't seem to affect anything. Oh well. I must remind myself; computers only do what they are programmed to do ... computers only do what they are programmed to do ... computers only do what they are programmed to do ... computers only do what they are programmed to do ... Sorry for the alarm. Regards, John From shintaro.fujiwara at gmail.com Sun Dec 2 20:27:17 2007 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Mon, 3 Dec 2007 05:27:17 +0900 Subject: [ANN] segatex-4.00 RPM,SRPM released !! Message-ID: I released RPM,SRPM version of segatex-4.00.tgz. segatex is a program even if not knowing much about SELinux commands, can easily set SELinux commands by GUI. Written in C++. Requires Qt ( qt-devel package ). Thank you very much for your attention. p.s. I want to wrap semanage next. Any comments appreciated to me. -- Shintaro Fujiwara segatex project (SELinux policy tool) http://sourceforge.net/projects/segatex/ Home page http://intrajp.no-ip.com/ Blog http://intrajp.no-ip.com/nucleus/ CMS http://intrajp.no-ip.com/xoops/ Wiki http://intrajp.no-ip.com/pukiwiki/ From fedora02 at grifent.com Sun Dec 2 23:01:10 2007 From: fedora02 at grifent.com (John Griffiths) Date: Sun, 02 Dec 2007 18:01:10 -0500 Subject: selinux preventing clamd and amavisd even in Permissive In-Reply-To: <20071202170010.74FDF73D2B@hormel.redhat.com> References: <20071202170010.74FDF73D2B@hormel.redhat.com> Message-ID: <47533936.9030402@grifent.com> I think I figured it out. I had not configured freshclam yet. Even though clamav had the default virus databases from clamav-data.i386, clamav system would not start until freshclam had updated the databases. I configured freshclam before I went out. Apparently, when cron updated the virus databases, clamav started normally and opened the missing socket and the email system started working properly. At least this is my best deduction. I don't remember having to have freshclam configured for updates prior to email working in Fedora 7. Guess this is a question for a different list, but I just wanted to put things to rest. Regards, John From spng.yang at gmail.com Mon Dec 3 05:38:05 2007 From: spng.yang at gmail.com (NZzi) Date: Mon, 03 Dec 2007 13:38:05 +0800 Subject: [Bug] some problems about setroubleshoot In-Reply-To: <474ED627.3000108@redhat.com> References: <474E5F3B.7080704@gmail.com> <474ED627.3000108@redhat.com> Message-ID: <4753963D.2080908@gmail.com> John Dennis ????: > Ken YANG wrote: >> >> hi all: >> >> in my F8(update) with setroubleshoot: >> >> setroubleshoot-1.10.7-1.fc8.noarch >> >> my setroubleshoot often close connect: >> >> connection lost on /var/run/setroubleshoot/setroubleshoot_server >> >> i found a error message in setroubleshoot log: >> >> 2007-11-29 10:02:41,561 [email.WARNING] ???????????? >> /var/lib/setroubleshoot/email_alert_recipients, No such file or directory >> >> in english is: >> >> 2007-11-29 10:02:41,561 [email.WARNING] can not open file: >> /var/lib/setroubleshoot/email_alert_recipients, No such file or directory >> >> >> and after i restart setroubleshoot >> >> $ sudo service setroubleshoot restart >> ???? setroubleshootd?? [OK] >> ???? setroubleshootd?? [OK] >> >> >> i got: >> >> /var/lib/setroubleshoot/audit_listener_database.xml:570: parser error >> : Input is not proper UTF-8, indicate encoding ! >> Bytes: 0xDF 0x20 0xE8 0xAE >> ?????????? ? ???????????????????????? restorecon -v > >> in english is: >> >> /var/lib/setroubleshoot/audit_listener_database.xml:570: parser error >> : Input is not proper UTF-8, indicate encoding ! >> Bytes: 0xDF 0x20 0xE8 0xAE >> If you want to access this file??you should use restorecon -v < >> unknown >> >> above english error messages is translated by me, not setroubleshoot >> original error messages. >> >> because i doubt that the error is caused by chinese locale, so i keep >> the "chinese error message" from setroubleshoot. My system runs in >> LANG=zh_CN.UTF-8 >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Please file a bug report at http://bugzilla.redhat.com under the > setroubleshoot component. > > The message about email_alert_recipients is a non-issue. > > It appears as though a chinese bad translation been entered into the > alert database. This occurs because the setroubleshoot-plugins (seperate > package) have translations for each alert. When the alert fires the > translation from your locale is copied into your alert database. It > looks like the .po file has bad UTF-8. > > When you file the bug report please attach the > /var/lib/setroubleshoot/audit_listener_database.xml file and specify the > rpm versions of setroubleshoot, setroubleshoot-server, and > setroubleshoot-plugins and the locale your system is set to. i have report this as a bug, but the bugzilla reported the file as "Empty". > > Thank you From paul at city-fan.org Mon Dec 3 12:09:51 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 03 Dec 2007 12:09:51 +0000 Subject: Qustion regarding: selinux / perl-cgi / iptables In-Reply-To: <3d765ec40711261110k2a1ddcbcuf16acf6477c5fa6b@mail.gmail.com> References: <3d765ec40711261110k2a1ddcbcuf16acf6477c5fa6b@mail.gmail.com> Message-ID: <4753F20F.8010900@city-fan.org> Paul McAvoy wrote: > Hi, I was wondering if anyone has information or can direct me to more > details on the following: > > I have been using a perl cgi script on a personal web-server of mine > to control access to SSH. > Essentially, it is a knock-knock system. I would go to a specific URL > with the cgi, enter some information, and the perl script would add my > ip address to the allowed list for SSH in the fire-wall. > > I have been working on learning the details with SElinux, and trying > to come up with some rules to allow the script to work correctly. > There appears to be some kind of conflict either related to the script > itself, or being run through httpd and getting access to the IPTables > command tools. > > The CGI script (written in perl) is SUID root. > Httpd runs the script. > The script will run the iptables command line tools to examine the > table (to see if the ip address is already allowed), and also to add a > new ip address to the allowed list. > > My current method of trying to create the appropriate policy is to > continue testing the cgi-script, watching the audit log, and running > audit2allow on the selected audit messages. > > My current policy is: > > ... > require { > type modules_conf_t; > type modules_dep_t; > type sysctl_modprobe_t; > type boot_t; > type httpd_sys_script_t; > type modules_object_t; > class capability net_raw; > class dir { getattr search }; > class file { read getattr }; > class rawip_socket { getopt create }; > } > > #============= httpd_sys_script_t ============== > allow httpd_sys_script_t boot_t:dir getattr; > allow httpd_sys_script_t modules_conf_t:file { read getattr }; > allow httpd_sys_script_t modules_dep_t:file read; > allow httpd_sys_script_t modules_object_t:dir search; > allow httpd_sys_script_t self:capability net_raw; > allow httpd_sys_script_t self:rawip_socket { getopt create }; > ... > > So, my question boils down to this: > (I'm running Fedora Core 7) > Do I just continue running the audit2allow repeatedly to create a > policy to do what I want? > > Is there a better way to solve this problem? I am concerned that just > creating a policy to allow my script to run will create other more > substantial holes. > > I am also open to creating a tool to update my iptables some other > way. Maybe perl-cgi is not the best method? > > Thanks in advance for any information! The quickest fix for this is probably to relabel your script as httpd_unconfined_script_exec_t, which would run that particular script unconfined by SELinux without opening up all sorts of extra avenues for all the other scripts on your system. Longer term I'd be inclined to write a specific policy for this script using the apache_content_template, but that's a bigger job. Paul. From paul at city-fan.org Mon Dec 3 12:12:59 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 03 Dec 2007 12:12:59 +0000 Subject: F8 ssh avc Message-ID: <4753F2CB.5000203@city-fan.org> Got this one on the server end when using sftp with key-based auth and using keychain: type=AVC msg=audit(1196678377.841:1040): avc: denied { setkeycreate } for pid=23895 comm="sshd" scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=process type=SYSCALL msg=audit(1196678377.841:1040): arch=40000003 syscall=4 success=no exit=-13 a0=5 a1=b802c120 a2=22 a3=15a03a items=0 ppid=31470 pid=23895 auid=1012 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) What's actually being denied here? Everything still seemed to work. Paul. From tmraz at redhat.com Mon Dec 3 13:13:20 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 03 Dec 2007 14:13:20 +0100 Subject: F8 ssh avc In-Reply-To: <4753F2CB.5000203@city-fan.org> References: <4753F2CB.5000203@city-fan.org> Message-ID: <1196687600.3037.11.camel@vespa.kabelta.loc> On Mon, 2007-12-03 at 12:12 +0000, Paul Howarth wrote: > Got this one on the server end when using sftp with key-based auth and > using keychain: > > type=AVC msg=audit(1196678377.841:1040): avc: denied { setkeycreate } > for pid=23895 comm="sshd" > scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 > tcontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=process > type=SYSCALL msg=audit(1196678377.841:1040): arch=40000003 syscall=4 > success=no exit=-13 a0=5 a1=b802c120 a2=22 a3=15a03a items=0 ppid=31470 > pid=23895 auid=1012 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=(none) comm="sshd" exe="/usr/sbin/sshd" > subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > > What's actually being denied here? Everything still seemed to work. This is already reported: https://bugzilla.redhat.com/show_bug.cgi?id=406951 Sshd now calls setkeycreatecon() which is not but should be allowed in policy. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From dpquigl at tycho.nsa.gov Mon Dec 3 13:37:29 2007 From: dpquigl at tycho.nsa.gov (Dave Quigley) Date: Mon, 03 Dec 2007 08:37:29 -0500 Subject: F8 ssh avc In-Reply-To: <1196687600.3037.11.camel@vespa.kabelta.loc> References: <4753F2CB.5000203@city-fan.org> <1196687600.3037.11.camel@vespa.kabelta.loc> Message-ID: <1196689049.31856.0.camel@moss-terrapins.epoch.ncsc.mil> On Mon, 2007-12-03 at 14:13 +0100, Tomas Mraz wrote: > On Mon, 2007-12-03 at 12:12 +0000, Paul Howarth wrote: > > Got this one on the server end when using sftp with key-based auth and > > using keychain: > > > > type=AVC msg=audit(1196678377.841:1040): avc: denied { setkeycreate } > > for pid=23895 comm="sshd" > > scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 > > tcontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=process > > type=SYSCALL msg=audit(1196678377.841:1040): arch=40000003 syscall=4 > > success=no exit=-13 a0=5 a1=b802c120 a2=22 a3=15a03a items=0 ppid=31470 > > pid=23895 auid=1012 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > > fsgid=0 tty=(none) comm="sshd" exe="/usr/sbin/sshd" > > subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > > > > What's actually being denied here? Everything still seemed to work. > > This is already reported: > https://bugzilla.redhat.com/show_bug.cgi?id=406951 > > Sshd now calls setkeycreatecon() which is not but should be allowed in > policy. I reported this to Dan last week and it should be fixed in selinux-policy-3.0.8-62.fc8 Dave From selinux at gmail.com Mon Dec 3 14:55:12 2007 From: selinux at gmail.com (Tom London) Date: Mon, 3 Dec 2007 06:55:12 -0800 Subject: rpm_script_t AVC with today's openoffice.org-writer2latex Message-ID: <4c4ba1530712030655g730aa9b9t59681f5a64362a88@mail.gmail.com> Yum update today stalled in enforcing mode. In permissive mode, worked, but got this: type=AVC msg=audit(1196693534.458:415): avc: denied { execstack } for pid=12928 comm="uno.bin" scontext=system_u:system_r:rpm_script_t:s0 tcontext=system_u:system_r:rpm_script_t:s0 tclass=process type=AVC msg=audit(1196693534.458:415): avc: denied { execmem } for pid=12928 comm="uno.bin" scontext=system_u:system_r:rpm_script_t:s0 tcontext=system_u:system_r:rpm_script_t:s0 tclass=process type=SYSCALL msg=audit(1196693534.458:415): arch=40000003 syscall=125 success=yes exit=0 a0=bfa83000 a1=1000 a2=1000007 a3=fffff000 items=0 ppid=12906 pid=12928 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="uno.bin" exe="/usr/lib/openoffice.org/program/uno.bin" subj=system_u:system_r:rpm_script_t:s0 key=(null) Not sure where to file this.... openoffice.org? tom -- Tom London From selinux at gmail.com Mon Dec 3 15:06:38 2007 From: selinux at gmail.com (Tom London) Date: Mon, 3 Dec 2007 07:06:38 -0800 Subject: rpm_script_t AVC with today's openoffice.org-writer2latex In-Reply-To: <4c4ba1530712030655g730aa9b9t59681f5a64362a88@mail.gmail.com> References: <4c4ba1530712030655g730aa9b9t59681f5a64362a88@mail.gmail.com> Message-ID: <4c4ba1530712030706j6d6fd688jd7c21d4602114a83@mail.gmail.com> On Dec 3, 2007 6:55 AM, Tom London wrote: > Yum update today stalled in enforcing mode. Forgot to add this: Here is the console error message generated when attempting to yum in enforcing mode: [Java framework]sunjavaplugin.so could not load Java runtime library: file:///usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/jre/lib/i386/client/libjvm.so. Got many, many of these..... > > In permissive mode, worked, but got this: > > type=AVC msg=audit(1196693534.458:415): avc: denied { execstack } > for pid=12928 comm="uno.bin" > scontext=system_u:system_r:rpm_script_t:s0 > tcontext=system_u:system_r:rpm_script_t:s0 tclass=process > type=AVC msg=audit(1196693534.458:415): avc: denied { execmem } for > pid=12928 comm="uno.bin" scontext=system_u:system_r:rpm_script_t:s0 > tcontext=system_u:system_r:rpm_script_t:s0 tclass=process > type=SYSCALL msg=audit(1196693534.458:415): arch=40000003 syscall=125 > success=yes exit=0 a0=bfa83000 a1=1000 a2=1000007 a3=fffff000 items=0 > ppid=12906 pid=12928 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 comm="uno.bin" > exe="/usr/lib/openoffice.org/program/uno.bin" > subj=system_u:system_r:rpm_script_t:s0 key=(null) > > Not sure where to file this.... openoffice.org? > -- Tom London From cra at WPI.EDU Mon Dec 3 15:18:20 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 3 Dec 2007 10:18:20 -0500 Subject: allow_daemons_dump_core doesn't work? Message-ID: <20071203151820.GB19857@angus.ind.WPI.EDU> I've been having issues with BIND so I set up the named process to dump core and enabled allow_daemons_dump_core. However, it would not create any core file until I put SELinux into permissive mode. I also didn't get any audit messages related to the failed core dump. Why is that? The CWD of the process is /var/named which is where the core dump got written after I put SELinux in permissive mode. From dwalsh at redhat.com Mon Dec 3 15:37:10 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Dec 2007 10:37:10 -0500 Subject: AVCs whilst installing latest F8 update batch In-Reply-To: <47455816.9000405@city-fan.org> References: <47455816.9000405@city-fan.org> Message-ID: <475422A6.40607@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > Got a bunch of AVCs whilst installing these updates today: > > Nov 22 07:50:15 Updated: bind-libs - 32:9.5.0-18.a7.fc8.x86_64 > Nov 22 07:50:17 Updated: pilot-link - 2:0.12.2-7.fc8.x86_64 > Nov 22 07:50:20 Updated: bind - 32:9.5.0-18.a7.fc8.x86_64 > Nov 22 07:50:22 Updated: smolt - 1.0-1.fc8.noarch > Nov 22 07:50:25 Updated: system-config-firewall-tui - 1.0.11-1.fc8.noarch > Nov 22 07:50:25 Updated: bind-utils - 32:9.5.0-18.a7.fc8.x86_64 > Nov 22 07:50:29 Updated: system-config-firewall - 1.0.11-1.fc8.noarch > Nov 22 07:50:29 Updated: smolt-firstboot - 1.0-1.fc8.noarch > Nov 22 07:50:35 Updated: bind-chroot - 32:9.5.0-18.a7.fc8.x86_64 > Nov 22 07:50:37 Updated: setroubleshoot-plugins - 1.10.4-1.fc8.noarch > Nov 22 07:50:38 Updated: libao - 0.8.8-2.fc8.x86_64 > Nov 22 07:50:40 Updated: pilot-link - 2:0.12.2-7.fc8.i386 > > > Piping the AVCs into audit2allow -R yielded: > > require { > type named_conf_t; > type setfiles_t; > type proc_t; > class lnk_file relabelfrom; > class dir relabelfrom; > class file relabelfrom; > class filesystem associate; > } > > #============= named_conf_t ============== > allow named_conf_t proc_t:filesystem associate; > > #============= setfiles_t ============== > allow setfiles_t self:dir relabelfrom; > allow setfiles_t self:file relabelfrom; > allow setfiles_t self:lnk_file relabelfrom; > kernel_getattr_core_if(setfiles_t) > kernel_getattr_message_if(setfiles_t) > kernel_read_device_sysctls(setfiles_t) > kernel_read_kernel_sysctls(setfiles_t) > kernel_read_net_sysctls(setfiles_t) > kernel_read_software_raid_state(setfiles_t) > kernel_read_vm_sysctls(setfiles_t) > > As far as I can see, the updates installed OK. > > I can post the raw audit messages if it's useful. > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Most of these are caused by bind-chroot running a recursive restorecon over the /var/chroot directory after /proc is mounted. The restorecon command runs over all the directories and tries to relabel them named_conf_t including the /proc mounted under the chroot. bind-chroot should run the restorecon before mounting the file systems, which would eliminate these avc's. I have updated the bugzilla. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVCKmrlYvE4MpobMRAgzsAJsFX/TJCHznz3XTynhpG60tjspAfACeN8oL OmS/X49YK/J9gNzvZTfFUHI= =yetv -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Dec 3 15:38:42 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Dec 2007 10:38:42 -0500 Subject: gdm + selinux problem In-Reply-To: <4746DA92.2000204@avtechpulse.com> References: <4746DA92.2000204@avtechpulse.com> Message-ID: <47542302.9080908@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dr. Michael J. Chudobiak wrote: > Hi all, > > After an F7 -> F8 upgrade, I can't start the xorg server in enforcing > mode. Logs say things like: > > type=AVC msg=audit(1195824979.681:23): avc: denied { getattr } for > pid=2585 comm="gdm-binary" path="/tmp/.X11-unix" dev=dm-0 ino=8871462 > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir > type=SYSCALL msg=audit(1195824979.681:23): arch=40000003 syscall=196 > success=yes exit=0 a0=8090daf a1=bfb4d320 a2=c2bff4 a3=3 items=0 ppid=1 > pid=2585 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=(none) comm="gdm-binary" exe="/usr/sbin/gdm-binary" > subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) > > > audit2allow says: > > #============= cupsd_t ============== > allow cupsd_t nscd_t:nscd shmemserv; > > #============= iptables_t ============== > allow iptables_t nscd_t:nscd shmemserv; > > #============= nfsd_t ============== > allow nfsd_t nscd_t:nscd { shmemserv getserv }; > > #============= ntpd_t ============== > allow ntpd_t nscd_t:nscd shmemserv; > > #============= sendmail_t ============== > allow sendmail_t fail2ban_log_t:file append; > allow sendmail_t initrc_t:unix_stream_socket { read write }; > allow sendmail_t nscd_t:nscd shmemserv; > > #============= system_mail_t ============== > allow system_mail_t nscd_t:nscd shmemserv; > > #============= xdm_t ============== > allow xdm_t initrc_tmp_t:dir { getattr setattr }; > > #============= xdm_xserver_t ============== > allow xdm_xserver_t initrc_tmp_t:dir { write getattr search add_name }; > allow xdm_xserver_t initrc_tmp_t:sock_file create; > > > > Now... how would this have happened? Should I just run the above > commands to fix everything, or is there a deeper bug / issue? > > Help appreciated! > > > - Mike > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Looks like you might have some labeliing problems, but first update to the latest version of selinux-policy yum -y upgrade selinux-policy And see if most of these have been fixed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVCMCrlYvE4MpobMRAtS6AJ9KrOK3dc8t8bLJCcUUK0SBvxgWXACfVuy2 JNYcjIBN4MzTprQVdKwaiZo= =o1QY -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Dec 3 15:43:16 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Dec 2007 10:43:16 -0500 Subject: Qustion regarding: selinux / perl-cgi / iptables In-Reply-To: <4753F20F.8010900@city-fan.org> References: <3d765ec40711261110k2a1ddcbcuf16acf6477c5fa6b@mail.gmail.com> <4753F20F.8010900@city-fan.org> Message-ID: <47542414.80303@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > Paul McAvoy wrote: >> Hi, I was wondering if anyone has information or can direct me to more >> details on the following: >> >> I have been using a perl cgi script on a personal web-server of mine >> to control access to SSH. >> Essentially, it is a knock-knock system. I would go to a specific URL >> with the cgi, enter some information, and the perl script would add my >> ip address to the allowed list for SSH in the fire-wall. >> >> I have been working on learning the details with SElinux, and trying >> to come up with some rules to allow the script to work correctly. >> There appears to be some kind of conflict either related to the script >> itself, or being run through httpd and getting access to the IPTables >> command tools. >> >> The CGI script (written in perl) is SUID root. >> Httpd runs the script. >> The script will run the iptables command line tools to examine the >> table (to see if the ip address is already allowed), and also to add a >> new ip address to the allowed list. >> >> My current method of trying to create the appropriate policy is to >> continue testing the cgi-script, watching the audit log, and running >> audit2allow on the selected audit messages. >> >> My current policy is: >> >> ... >> require { >> type modules_conf_t; >> type modules_dep_t; >> type sysctl_modprobe_t; >> type boot_t; >> type httpd_sys_script_t; >> type modules_object_t; >> class capability net_raw; >> class dir { getattr search }; >> class file { read getattr }; >> class rawip_socket { getopt create }; >> } >> >> #============= httpd_sys_script_t ============== >> allow httpd_sys_script_t boot_t:dir getattr; >> allow httpd_sys_script_t modules_conf_t:file { read getattr }; >> allow httpd_sys_script_t modules_dep_t:file read; >> allow httpd_sys_script_t modules_object_t:dir search; >> allow httpd_sys_script_t self:capability net_raw; >> allow httpd_sys_script_t self:rawip_socket { getopt create }; >> ... >> >> So, my question boils down to this: >> (I'm running Fedora Core 7) >> Do I just continue running the audit2allow repeatedly to create a >> policy to do what I want? >> >> Is there a better way to solve this problem? I am concerned that just >> creating a policy to allow my script to run will create other more >> substantial holes. >> >> I am also open to creating a tool to update my iptables some other >> way. Maybe perl-cgi is not the best method? >> >> Thanks in advance for any information! > > The quickest fix for this is probably to relabel your script as > httpd_unconfined_script_exec_t, which would run that particular script > unconfined by SELinux without opening up all sorts of extra avenues for > all the other scripts on your system. > > Longer term I'd be inclined to write a specific policy for this script > using the apache_content_template, but that's a bigger job. > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list You could fairly simply write a policy for this script using system-config-selinux/polgengui If you go under the modules section of system-config-selinux and select new. It will start a Wizard to help you write the policy. When the policy is generated, you can add these specific rules without chaning the behaviour of how all other http scripts would work. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVCQUrlYvE4MpobMRAguLAJ9+tgtsfjxT9CPnicaIIplmxrXywACgwA5D HjBc7+6fhEES0KsDh6i0gmo= =4hyS -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Dec 3 15:46:23 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Dec 2007 10:46:23 -0500 Subject: permission issue with bugzilla In-Reply-To: <5e5d9e5f0711261833x252cd6f0p76ce3cc781c30c56@mail.gmail.com> References: <5e5d9e5f0711261833x252cd6f0p76ce3cc781c30c56@mail.gmail.com> Message-ID: <475424CF.4020203@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ritesh Trivedi wrote: > Hi, > > After accidental reboot of one of our servers, I started getting avc > denial messages when bugzilla tries to connect to local mysql > instance. > > At first I was seeing httpd_sys_script_ro_t vs httpd_sys_script_t > denial messages. I fixed that by issuing chcon httpd_sys_script_rw_t > on the mysql directory. But now I am seeing unix socket denial error > (see following...) > > Any help will be highly appreciated. Also please reply directly to me > at this email address if possible. > > Nov 26 18:05:09 nbprod2 kernel: audit(1196129109.301:3152): avc: > denied { connectto } for pid=5900 comm="index.cgi" name="mysql.sock" > scontext=root:system_r:httpd_sys_script_t:s0 > tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 > tclass=unix_stream_socket You have mysql running ad unconfined_t? It should be running as mysql_t, if you execute service mysql restart does it fix the problem? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVCTPrlYvE4MpobMRAv0EAJ4oO8HfPjfwNEtqRRfzhoEyUtY1eQCguBxw mlf4XXGOKjIfzHwibvVkbQA= =HfB/ -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Dec 3 15:59:58 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Dec 2007 10:59:58 -0500 Subject: policy compile error In-Reply-To: References: Message-ID: <475427FE.3090505@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Clarkson, Mike R (US SSA) wrote: > I just downloaded the policy source from redhat (serefpolicy-2.4.6) and > attempted to build a strict-mls loadable module policy and got the > following compile error: > > Compiling mls base module > /usr/bin/checkmodule -M base.conf -o tmp/base.mod > /usr/bin/checkmodule: loading policy configuration from base.conf > policy/modules/kernel/domain.te:174:ERROR 'unknown type ipsec_spd_t' at > token ';' on line 10298: > allow domain ipsec_spd_t:association polmatch; > #line 174 > /usr/bin/checkmodule: error(s) encountered while parsing configuration > make: *** [tmp/base.mod] Error 1 > > > Here is the offending portion of domain.te: > > ifdef(`enable_mls',` > tunable_policy(`allow_netlabel',` > kernel_raw_recvfrom_unlabeled(domain) > kernel_tcp_recvfrom_unlabeled(domain) > kernel_udp_recvfrom_unlabeled(domain) > ') > tunable_policy(`allow_ipsec_label',` > ipsec_labeled(domain) > ') > ') > > > Since domain is a base module and ipsec is a loadable module, doesn't > the call to the ipsec_labeled interface need to be wrapped in an > optional_policy statement? Since nesting conditional statements aren't > supported, I had to comment out the tunable_policy statement to get this > to compile: > #tunable_policy(`allow_ipsec_label',` > optional_policy(` > ipsec_labeled(domain) > ') > #') > > What's the right fix for this? > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list You should move the option_policy lines outside of the tunable_policy, then it should work. Also on modules-mls.conf has ipsec as a base module. While targeted has it as a module. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVCf+rlYvE4MpobMRAsTCAJwIrOejaMnf5SSQ2CZCsXTPNnAuBQCfa/eP tD0X+wuPOKgUEsSC7wF3wvw= =sZM6 -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Dec 3 16:03:37 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Dec 2007 11:03:37 -0500 Subject: selinux out smarted itself. "Multiple different specifications" One FILE But two types labled ------------- (system_u:object_r:home_root_t:s0 and system_u:object_r:boot_t:s0). In-Reply-To: <020001c8316c$88498e10$8b00a8c0@rogersxp> References: <020001c8316c$88498e10$8b00a8c0@rogersxp> Message-ID: <475428D9.3000509@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roger Salisbury wrote: > ----------- a challenge for selinux------------ > > Hi fellow selinux uses ... > > How can you fix labeling when the selinux tools don't allow you to. > > Selinux commands complain & refuse to work. > > Tradition selinux commands don't work. IE chcon, restorecon , fixfiles, > > setfiles etc..I Need an *expert* here, .......... > > PROBLEM is : > > my /boot directory has : > > :boot_t: > > and > > :home_root_t: > > .......... together labled --- see below. > > and I can't fix it. do we have to edit the "inode" directly?? > > Having two types on one file I believe should *never* happen but -- it has. > > Should be one ":boot_t:" or the other ":home_root_t:" but never *both*! > > I think I know how it happened -- but that's not the issue right now -- > how do you fix it?? > The security of selinux normaly is designed to prevent adhoc changes --- so > this is why it is difficult... but with root password their would be a > solution somehow. > > Thx > Roger Salisbury > > > Below is the setfiles display: > > > /etc/selinux/targeted/contexts/files/file_contexts: Multiple same > > specifications for /boot/lost\+found/.*. > > /etc/selinux/targeted/contexts/files/file_contexts: Multiple different > > specifications for /boot (system_u:object_r:home_root_t:s0 and > > system_u:object_r:boot_t:s0). > > /etc/selinux/targeted/contexts/files/file_contexts: Multiple same > > specifications for /boot/\.journal. > > /etc/selinux/targeted/contexts/files/file_contexts: Multiple same > > specifications for /boot/lost\+found. > > setfiles: labeling files under /boot > > setfiles: labeling files under /boot > > matchpathcon_filespec_eval: hash table stats: 28 elements, 28/65536 buckets > > used, longest chain length 1 > > setfiles: Done. > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list This looks like selinux is confused and thinks you have a homedirectory under /boot? Or someone added a context for /boot as home_root_t. is there an entry in /etc/passwd with a homedir of /boot in the path? grep /boot /etc/selinux/targeted/contexts/files/* -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVCjYrlYvE4MpobMRAiu6AKDIFAL2HPrWHG5c9ddNbd3aYX3HDwCgwSZC FX8YhLW0aRFlO60gSchwDZg= =Kf2p -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Dec 3 16:07:20 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Dec 2007 11:07:20 -0500 Subject: [Bug] about the bug with semanage In-Reply-To: <474CFA2E.5090709@gmail.com> References: <474CFA2E.5090709@gmail.com> Message-ID: <475429B8.6090300@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ken YANG wrote: > > hi selinuxers: > > several days, i remmeber someone report a bug about > semanage in non-english locale: > > -(:11:30:$)-> locale > LANG=zh_CN.UTF-8 > LC_CTYPE="zh_CN.UTF-8" > LC_NUMERIC="zh_CN.UTF-8" > LC_TIME="zh_CN.UTF-8" > LC_COLLATE="zh_CN.UTF-8" > LC_MONETARY="zh_CN.UTF-8" > LC_MESSAGES="zh_CN.UTF-8" > LC_PAPER="zh_CN.UTF-8" > LC_NAME="zh_CN.UTF-8" > LC_ADDRESS="zh_CN.UTF-8" > LC_TELEPHONE="zh_CN.UTF-8" > LC_MEASUREMENT="zh_CN.UTF-8" > LC_IDENTIFICATION="zh_CN.UTF-8" > LC_ALL= > -(yangshao at NZzi:pts/4)--------------------(~)-(3/133)- > -(:13:17:$)-> sudo semanage login -l > /usr/sbin/semanage: ascii > > -(:11:02:$)-> LANG=C sudo semanage login -l > > Login Name SELinux User MLS/MCS Range > > __default__ system_u s0 > root root -s0:c0.c255 > system_u system_u SystemLow-SystemHigh > > > i notice this bug is fixed in F9 rawhide, but F8 has not > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list I believe the latest updates of F8 and Rawhide should fix this problem. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVCm4rlYvE4MpobMRAuueAKC69E/NKWF0IlfkOAM0XRmIFihLBQCg3lUJ 1zpz+q9vHEsDVPhpwO9NYiw= =dCzD -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Dec 3 16:12:11 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Dec 2007 11:12:11 -0500 Subject: Problem with existing user directories on F* In-Reply-To: <200711291101.57262.tony.molloy@ul.ie> References: <200711291101.57262.tony.molloy@ul.ie> Message-ID: <47542ADB.4060504@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony Molloy wrote: > Hi, > > After an install of F8 I have a problem with pre-existing user directories. > > I did a full install of F8 with SELinux in enforcing mode and kept my existing > user directories in /users. At the end of the install I did a "fixfiles > relabel". Now when I try to login to my account I'm told that my home > directory does not exist. It does. > > The problem appears to be SELinux because when I disable it everything works. > > Some info: > > ls -al| /home/testacc ( account created during the install ) > > drwx------ testacc testacc system_u:object_r:user_home_dir_t . > drwxr-xr-x root root system_u:object_r:home_root_t .. > -rw-r--r-- testacc testacc system_u:object_r:user_home_t .bash_logout > .... > > > ls -alZ /users/molloyt ( my home directory ) > > drwx------ molloyt csstaff system_u:object_r:default_t . > drwxr-xr-x root root system_u:object_r:default_t .. > -rw-r--r-- molloyt csstaff user_u:object_r:default_t 3rd-monday > .... > > The SELinux permissions on the home directory, the owing directory and the > contents of the home directory are wrong. > > So two questions: > > 1. how can I reset the permissions. > > 2. was the problem caused by the "fixfiles relabel" which I did at the end of > the install. If I had unmounted the /users partition before I did that > would I have been OK. > > > Thanks, > > Tony > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list What does molloyt entry in the /etcpasswd file look like? IE Does it list his homedir as /users/molloyt? SELinux is supposed to figure out where home directories are and label them correctly. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVCrbrlYvE4MpobMRAuZ+AKDoWsJ05eecVotQ04qKMk6WpXsaBgCg11Up BffORSm5yq8n/Vy+XFTo2bI= =X09G -----END PGP SIGNATURE----- From selinux at gmail.com Mon Dec 3 16:13:02 2007 From: selinux at gmail.com (Tom London) Date: Mon, 3 Dec 2007 08:13:02 -0800 Subject: usbfs, updpwd_t, gdm (xdm_t) avcs with today's rawhide In-Reply-To: <4c4ba1530712011619k2823a3acqd2c6756c9b8e7a0@mail.gmail.com> References: <4c4ba1530712011619k2823a3acqd2c6756c9b8e7a0@mail.gmail.com> Message-ID: <4c4ba1530712030813g40699129gb9bf9d04ba681b07@mail.gmail.com> On Dec 1, 2007 4:19 PM, Tom London wrote: > Today's gdm is finally runnable for me, and with gcc-4.1.2-33, I can > compile newest kernel (2.6.24-0.61.rc3.git5.local.fc9). > > However, a bunch of AVCs: > > #============= mount_t ============== > allow mount_t usbfs_t:dir { read ioctl }; > > #============= updpwd_t ============== > allow updpwd_t tty_device_t:chr_file { read write }; > > #============= xdm_t ============== > allow xdm_t gconfd_exec_t:file { read execute execute_no_trans }; > allow xdm_t inotifyfs_t:dir getattr; > allow xdm_t self:netlink_selinux_socket { read bind create }; > allow xdm_t system_dbusd_exec_t:file { read execute execute_no_trans }; > allow xdm_t system_dbusd_t:dbus acquire_svc; > allow xdm_t var_lib_t:file { rename unlink append }; > allow xdm_t var_log_t:file write; > > The mount_t/usbfs_t ones come early in boot. > > Without adding rules for the xdm_t ones (at least some of them), > graphical login fails with 'X respawn too fast' messages. > > I attach the AVCs from /var/log/messages and /var/log/audit/audit.log > I found a few more AVCs generated during graphical login: #============= pam_t ============== allow pam_t user_home_t:file { read getattr ioctl append }; #============= xdm_dbusd_t ============== allow xdm_dbusd_t xdm_var_lib_t:dir search; /var/log/audit/audit.log attached. tom -- Tom London -------------- next part -------------- A non-text attachment was scrubbed... Name: log5 Type: application/octet-stream Size: 13419 bytes Desc: not available URL: From dwalsh at redhat.com Mon Dec 3 16:18:13 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Dec 2007 11:18:13 -0500 Subject: AW: RHEL5 + strict policy: Unprivileged user cron - "Unauthorized SELinux context" In-Reply-To: <783545.32918.qm@web27710.mail.ukl.yahoo.com> References: <783545.32918.qm@web27710.mail.ukl.yahoo.com> Message-ID: <47542C45.1000400@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Harald Beugler-Bell wrote: > I got a similar problem when trying to run cron as root. It looks like selinux is unable to get the correct user context of the crond process > > crond[5587]: (*system*) NULL security context for user () > crond[5587]: CRON (root) ERROR: failed to change SELinux context > crond[5587]: CRON (root) ERROR: cannot set security context > > The file context of the cron file is set according to default context: > $ ls -lZ /etc/cron.d/testing-cron > -rw-r--r-- root root system_u:object_r:system_cron_spool_t:s0 /etc/cron.d/testing-cron > > $ ps -efZ | grep crond > staff_u:system_r:crond_t:s0 root 14922 1 0 00:19 ? 00:00:00 /usr/sbin/crond start > > $ /usr/sbin/semanage login -l | egrep "root|system" > > root root s0-s0:c0.c1023 > > system_u system_u s0-s0:c0.c1023 > > bash-3.1# cat /etc/redhat-release > > Red Hat Enterprise Linux Server release 5 (Tikanga) > vixie-cron-4.1-66.1.el5 > libselinux-1.33.4-2.el5 > libselinux-python-1.33.4-2.el5 > selinux-policy-strict-2.4.6-79.el5 > selinux-policy-2.4.6-79.el5 > > any help is welcome. > > thanks > Hari > > ----- Urspr?ngliche Mail ---- > Von: Aleksander Adamowski > An: fedora-selinux-list at redhat.com > Gesendet: Mittwoch, den 28. November 2007, 16:10:58 Uhr > Betreff: Re: RHEL5 + strict policy: Unprivileged user cron - "Unauthorized SELinux context" > > Stephen Smalley pisze: >> On Wed, 2007-11-28 at 21:16 +0100, Aleksander Adamowski wrote: >> >>> crond[27249]: (apache) Unauthorized SELinux context, but SELinux in >>> permissive mode, continuing (cron/apache) >>> crond[29358]: (apache) NULL security context for user, but SELinux > in >>> permissive mode, continuing () >>> >> Sounds like it just stayed in crond's context since it failed the > check >> and the system was permissive. Naturally, in enforcing mode, it > would >> have not executed the job at all. >> >> crond computes a context for the user's cron job in the usual manner, >> then applies a entrypoint permission check between that context and > the >> file context on the crontab file (which gets picked up from a >> combination of its creator and the parent directory). If that check >> fails, then crond refuses to execute the crontab commands in that >> process context. The check is intended to prevent injection of > commands >> from one context into another via crontab, unless authorized by > policy >> of course. >> > That's reasonable. >> I'd have expected it to try to run the cron job in user_u:user_r: >> user_crond_t:s0 since apache wouldn't have a specific entry in > seusers. >> So it would have wanted the crontab file to have user_cron_spool_t on >> it, which would have happened if a user_t process created it. If >> instead an admin created it and it got sysadm_cron_spool_t or >> staff_cron_spool_t, that might explain it. So you could relabel it > or >> allow that permission. First though check the current label on the >> crontab file. >> > Yes, you're right. That was precisely the cause. > I've used "crontab -e -u apache" as root. > The files in /var/spool/cron got sysadm_cron_spool_t type (the full > context was root:object_r:sysadm_cron_spool_t). > > After running "fixfiles relabel /var/spool/cron/", the apache crontab > got system_u:object_r:user_cron_spool_t. > > Now cron runs fine and doesn't log anything suspicious. > > IMHO crontab should be modified to relabel crontab files that are > edited > using the "-u" option, but this is a question to Dan - should I file a > new bug to bugzilla.redhat.com on this? > Please update to the U1 policy. I think you should be able to get this from RHN or you can grab it off of http://people.redhat.com/dwalsh/SELinux/RHEL5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVCxErlYvE4MpobMRAhI4AKDNDDa5Nmz0D1hzlneVDMwrCoV6jwCfWCwd lrYMtBD3xAYpoQ8CFlH8sWM= =H/J2 -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Dec 3 16:19:48 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Dec 2007 11:19:48 -0500 Subject: CGI can't read public_html files In-Reply-To: <3e71d26a0711301729x4c07d9d7h27b3e93953e56609@mail.gmail.com> References: <3e71d26a0711301729x4c07d9d7h27b3e93953e56609@mail.gmail.com> Message-ID: <47542CA4.6010601@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Slesarev wrote: > Hello! > > I want to access public_html files from CGI script, but can't do it - > got AVC error during reading README file from public_html dir: > > ----------------------------------------------------------------------- > [root at elc6002s nuald]# tail /var/log/messages | grep setroubleshoot -m 1 > > Nov 29 13:42:51 elc6002s setroubleshoot: #012 SELinux is preventing > the format.cgi from using potentially mislabeled files > (unconfined_home_dir_t).#012 For complete SELinux messages. run > sealert -l 69519bd7-3e77-46d9-b845-7f066c4515e6 > ----------------------------------------------------------------------- > > I have only one item with unconfined_home_dir_t type in the path to > README file: > > ----------------------------------------------------------------------- > [nuald at elc6002s public_html]$ ls -Z `pwd`/README && pushd . > /dev/null > && while [[ `pwd` != '/' ]]; do ls -Zd `pwd` && cd ..; done && popd > > /dev/null > > -rw-rw-r-- nuald nuald system_u:object_r:httpd_user_content_t:s0 > /home/nuald/public_html/README > drwxrwxr-x nuald nuald system_u:object_r:httpd_user_content_t:s0 > /home/nuald/public_html > drwx--x--x nuald nuald unconfined_u:object_r:unconfined_home_dir_t:s0 > /home/nuald > drwxr-xr-x root root system_u:object_r:home_root_t:s0 /home > ----------------------------------------------------------------------- > > So, only my home dir have unconfined_home_dir_t type. But I do not want > to change it to httpd_sys_content_t type and I don't like this solution. > > The CGI script itself works fine either it have httpd_user_content_t > type now: > > ----------------------------------------------------------------------- > [nuald at elc6002s cgi-bin]$ ls -Z `pwd`/format.cgi && pushd . > /dev/null > && while [[ `pwd` != '/' ]]; do ls -Zd `pwd` && cd ..; done && popd > > /dev/null > > -rwxr-xr-x nuald nuald system_u:object_r:httpd_user_content_t:s0 > /home/nuald/public_html/cgi-bin/format.cgi > drwxr-xr-x nuald nuald system_u:object_r:httpd_user_content_t:s0 > /home/nuald/public_html/cgi-bin > drwxrwxr-x nuald nuald system_u:object_r:httpd_user_content_t:s0 > /home/nuald/public_html > drwx--x--x nuald nuald unconfined_u:object_r:unconfined_home_dir_t:s0 > /home/nuald > drwxr-xr-x root root system_u:object_r:home_root_t:s0 /home > ----------------------------------------------------------------------- > > So the script only can't read files in public_html folder. What is right > way to fix it? > > The script itself is below and used as > http://localhost/~nuald/cgi-bin/format.cgi?file=README > > ----------------------------------------------------------------------- > [nuald at elc6002s cgi-bin]$ cat format.cgi > > #!/usr/bin/perl -wT > > use strict; > use CGI qw/:standard/; > use IO::File; > use File::Spec; > use Cwd 'realpath'; > > print header; > my $filename = param('file') or die "Can be executed only as CGI"; > my $updir = File::Spec->updir(); > my $rel_path = File::Spec->catfile($updir, $filename); > my $path = realpath($rel_path) ; > my $file = IO::File->new($path,"<") or die "Can't open file $path"; > my $text = join "", <$file>; > $file->close or die "Can't close file"; > > print $text; > ----------------------------------------------------------------------- > > Thanks in advance. > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list What selinux policy are you running? rpm -q selinux-policy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVCyjrlYvE4MpobMRAj//AKCY7DoTOEGQpXL6criBA8kOZthyIwCfVYTW jgaaqMBnr4qv3ob0YiqeJvM= =6KbB -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Dec 3 16:22:13 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Dec 2007 11:22:13 -0500 Subject: selinux preventing clamd and amavisd even in Permissive In-Reply-To: <47533936.9030402@grifent.com> References: <20071202170010.74FDF73D2B@hormel.redhat.com> <47533936.9030402@grifent.com> Message-ID: <47542D35.70101@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Griffiths wrote: > I think I figured it out. > > I had not configured freshclam yet. Even though clamav had the default > virus databases from clamav-data.i386, clamav system would not start > until freshclam had updated the databases. I configured freshclam before > I went out. Apparently, when cron updated the virus databases, clamav > started normally and opened the missing socket and the email system > started working properly. > > At least this is my best deduction. > > I don't remember having to have freshclam configured for updates prior > to email working in Fedora 7. Guess this is a question for a different > list, but I just wanted to put things to rest. > > Regards, > John > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list In permissive mode, SELinux will not prevent anything from happening although it will report avc messages like it did. setroubleshoot will still interpret these messages like SELinux had prevented the access. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVC01rlYvE4MpobMRAvrYAKC4lf8rCHTT5lsHMONHV2ZABoubVACgtl5z kZ62NmqbIuUdAIncJJNG/NY= =Vca9 -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Dec 3 16:24:21 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Dec 2007 11:24:21 -0500 Subject: rpm_script_t AVC with today's openoffice.org-writer2latex In-Reply-To: <4c4ba1530712030655g730aa9b9t59681f5a64362a88@mail.gmail.com> References: <4c4ba1530712030655g730aa9b9t59681f5a64362a88@mail.gmail.com> Message-ID: <47542DB5.6030804@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > Yum update today stalled in enforcing mode. > > In permissive mode, worked, but got this: > > type=AVC msg=audit(1196693534.458:415): avc: denied { execstack } > for pid=12928 comm="uno.bin" > scontext=system_u:system_r:rpm_script_t:s0 > tcontext=system_u:system_r:rpm_script_t:s0 tclass=process > type=AVC msg=audit(1196693534.458:415): avc: denied { execmem } for > pid=12928 comm="uno.bin" scontext=system_u:system_r:rpm_script_t:s0 > tcontext=system_u:system_r:rpm_script_t:s0 tclass=process > type=SYSCALL msg=audit(1196693534.458:415): arch=40000003 syscall=125 > success=yes exit=0 a0=bfa83000 a1=1000 a2=1000007 a3=fffff000 items=0 > ppid=12906 pid=12928 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 comm="uno.bin" > exe="/usr/lib/openoffice.org/program/uno.bin" > subj=system_u:system_r:rpm_script_t:s0 key=(null) > > Not sure where to file this.... openoffice.org? > > tom Yes report agains openoffice.org, and cc me. Thanks. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVC21rlYvE4MpobMRAmBFAJsFsTZiJWscfbFI6uBz0EgB6EyEQgCeNY+O ZRJMnkGfpHA4qq2IQpS1618= =XOJ2 -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Dec 3 16:26:49 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Dec 2007 11:26:49 -0500 Subject: allow_daemons_dump_core doesn't work? In-Reply-To: <20071203151820.GB19857@angus.ind.WPI.EDU> References: <20071203151820.GB19857@angus.ind.WPI.EDU> Message-ID: <47542E49.4020803@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck Anderson wrote: > I've been having issues with BIND so I set up the named process to > dump core and enabled allow_daemons_dump_core. However, it would not > create any core file until I put SELinux into permissive mode. I also > didn't get any audit messages related to the failed core dump. Why is > that? The CWD of the process is /var/named which is where the core > dump got written after I put SELinux in permissive mode. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list allow_daemons_dump_core, is only allowing daemons to create new files in / It would not allow named to create a file in /var/named. So I guess we need to add a rule to allow named to write to named_zone_t if this boolean is set, or make named use / as its cwd. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVC5JrlYvE4MpobMRAtOwAKCerxBSjPszDUT+KVgZe1xyyJ5RnACgld+q PVFSYPcXS/TERkhH6B9DSQQ= =lHB3 -----END PGP SIGNATURE----- From fedora02 at grifent.com Mon Dec 3 16:56:20 2007 From: fedora02 at grifent.com (John Griffiths) Date: Mon, 03 Dec 2007 11:56:20 -0500 Subject: selinux preventing clamd and amavisd even in Permissive In-Reply-To: <47542D35.70101@redhat.com> References: <20071202170010.74FDF73D2B@hormel.redhat.com> <47533936.9030402@grifent.com> <47542D35.70101@redhat.com> Message-ID: <47543534.2040603@grifent.com> I realize now that it was not selinux preventing the socket from being created. The combination of symptoms seemed to indicate that selinux was the culprit when in reality, it was clamav and freshclam. Thanks for the reply. Regards, John Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > John Griffiths wrote: > >> I think I figured it out. >> >> I had not configured freshclam yet. Even though clamav had the default >> virus databases from clamav-data.i386, clamav system would not start >> until freshclam had updated the databases. I configured freshclam before >> I went out. Apparently, when cron updated the virus databases, clamav >> started normally and opened the missing socket and the email system >> started working properly. >> >> At least this is my best deduction. >> >> I don't remember having to have freshclam configured for updates prior >> to email working in Fedora 7. Guess this is a question for a different >> list, but I just wanted to put things to rest. >> >> Regards, >> John >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > In permissive mode, SELinux will not prevent anything from happening > although it will report avc messages like it did. setroubleshoot will > still interpret these messages like SELinux had prevented the access. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFHVC01rlYvE4MpobMRAvrYAKC4lf8rCHTT5lsHMONHV2ZABoubVACgtl5z > kZ62NmqbIuUdAIncJJNG/NY= > =Vca9 > -----END PGP SIGNATURE----- > From selinux at gmail.com Mon Dec 3 17:34:27 2007 From: selinux at gmail.com (Tom London) Date: Mon, 3 Dec 2007 09:34:27 -0800 Subject: rpm_script_t AVC with today's openoffice.org-writer2latex In-Reply-To: <47542DB5.6030804@redhat.com> References: <4c4ba1530712030655g730aa9b9t59681f5a64362a88@mail.gmail.com> <47542DB5.6030804@redhat.com> Message-ID: <4c4ba1530712030934v528fc46dre8feb11f4c226eb4@mail.gmail.com> On Dec 3, 2007 8:24 AM, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Tom London wrote: > > Yum update today stalled in enforcing mode. > > > > In permissive mode, worked, but got this: > > > > type=AVC msg=audit(1196693534.458:415): avc: denied { execstack } > > for pid=12928 comm="uno.bin" > > scontext=system_u:system_r:rpm_script_t:s0 > > tcontext=system_u:system_r:rpm_script_t:s0 tclass=process > > type=AVC msg=audit(1196693534.458:415): avc: denied { execmem } for > > pid=12928 comm="uno.bin" scontext=system_u:system_r:rpm_script_t:s0 > > tcontext=system_u:system_r:rpm_script_t:s0 tclass=process > > type=SYSCALL msg=audit(1196693534.458:415): arch=40000003 syscall=125 > > success=yes exit=0 a0=bfa83000 a1=1000 a2=1000007 a3=fffff000 items=0 > > ppid=12906 pid=12928 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > > sgid=0 fsgid=0 tty=pts0 comm="uno.bin" > > exe="/usr/lib/openoffice.org/program/uno.bin" > > subj=system_u:system_r:rpm_script_t:s0 key=(null) > > > > Not sure where to file this.... openoffice.org? > > > > tom > Yes report agains openoffice.org, and cc me. > > Thanks. BZ'd here: https://bugzilla.redhat.com/show_bug.cgi?id=408911 -- Tom London From selinux at gmail.com Mon Dec 3 19:20:01 2007 From: selinux at gmail.com (Tom London) Date: Mon, 3 Dec 2007 11:20:01 -0800 Subject: pulseaudio, policykit - works in permissive, fails in enforcing Message-ID: <4c4ba1530712031120i7e071207o226d0487829db847@mail.gmail.com> Running latest Rawhide. I've noticed the following problem that I cannot track down fully. Pulseaudio seems to have stopped working when in enforcing mode, unless I manually change the permissions to the numerous /dev/ files to 666 (e.g., /dev/*dsp*, /dev/audio* /dev/snd/*, ....) I get no AVCs. Below are snippets from /var/log/messages. My (simpleminded) interpretation is that in permissive mode, policykit is running but not when in enforcing. Any suggestions on how to track this down further? tom Permissive: Dec 3 09:48:10 localhost pulseaudio[2947]: polkit.c: Failed to show grant dialog: Unable to lookup exe for caller Dec 3 09:48:10 localhost pulseaudio[2947]: polkit.c: PolicyKit responded with 'auth_admin_keep_always' Dec 3 09:48:10 localhost pulseaudio[2947]: pid.c: Stale PID file, overwriting. Dec 3 09:48:10 localhost pulseaudio[2947]: main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted Dec 3 09:48:12 localhost pulseaudio[2947]: module.c: Failed to load module "module-rtp-recv" (argument: ""): initialization failed. Dec 3 09:48:12 localhost pulseaudio[2947]: module-gconf.c: pa_module_load() failed Enforcing: Dec 3 10:59:27 localhost pulseaudio[3995]: pid.c: Stale PID file, overwriting. Dec 3 10:59:27 localhost pulseaudio[3995]: main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted Dec 3 10:59:28 localhost pulseaudio[3995]: alsa-util.c: Error opening PCM device hw:0: No such device Dec 3 10:59:28 localhost pulseaudio[3995]: module.c: Failed to load module "module-alsa-sink" (argument: "device_id=0 sink_name=alsa_output.pci_8086_27d8_alsa_playback_0"): initialization failed. Dec 3 10:59:28 localhost pulseaudio[3995]: alsa-util.c: Error opening PCM device hw:0: No such device Dec 3 10:59:28 localhost pulseaudio[3995]: module.c: Failed to load module "module-alsa-source" (argument: "device_id=0 source_name=alsa_input.pci_8086_27d8_alsa_capture_0"): initialization failed. Dec 3 10:59:29 localhost pulseaudio[3995]: module.c: Failed to load module "module-rtp-recv" (argument: ""): initialization failed. Dec 3 10:59:29 localhost pulseaudio[3995]: module-gconf.c: pa_module_load() failed -- Tom London From selinux at gmail.com Mon Dec 3 23:22:00 2007 From: selinux at gmail.com (Tom London) Date: Mon, 3 Dec 2007 15:22:00 -0800 Subject: pulseaudio, policykit - works in permissive, fails in enforcing In-Reply-To: <4c4ba1530712031120i7e071207o226d0487829db847@mail.gmail.com> References: <4c4ba1530712031120i7e071207o226d0487829db847@mail.gmail.com> Message-ID: <4c4ba1530712031522v3a88bae6h23b3c6fe0ab41c84@mail.gmail.com> On Dec 3, 2007 11:20 AM, Tom London wrote: > Running latest Rawhide. > > I've noticed the following problem that I cannot track down fully. > > Pulseaudio seems to have stopped working when in enforcing mode, > unless I manually change the permissions to the numerous /dev/ files > to 666 (e.g., /dev/*dsp*, /dev/audio* /dev/snd/*, ....) > > I get no AVCs. Below are snippets from /var/log/messages. > > My (simpleminded) interpretation is that in permissive mode, policykit > is running but not when in enforcing. > > Any suggestions on how to track this down further? > > tom > > Permissive: > > Dec 3 09:48:10 localhost pulseaudio[2947]: polkit.c: Failed to show > grant dialog: Unable to lookup exe for caller > Dec 3 09:48:10 localhost pulseaudio[2947]: polkit.c: PolicyKit > responded with 'auth_admin_keep_always' > Dec 3 09:48:10 localhost pulseaudio[2947]: pid.c: Stale PID file, overwriting. > Dec 3 09:48:10 localhost pulseaudio[2947]: main.c: > setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted > Dec 3 09:48:12 localhost pulseaudio[2947]: module.c: Failed to load > module "module-rtp-recv" (argument: ""): initialization failed. > Dec 3 09:48:12 localhost pulseaudio[2947]: module-gconf.c: > pa_module_load() failed > > > > Enforcing: > > Dec 3 10:59:27 localhost pulseaudio[3995]: pid.c: Stale PID file, overwriting. > Dec 3 10:59:27 localhost pulseaudio[3995]: main.c: > setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted > Dec 3 10:59:28 localhost pulseaudio[3995]: alsa-util.c: Error opening > PCM device hw:0: No such device > Dec 3 10:59:28 localhost pulseaudio[3995]: module.c: Failed to load > module "module-alsa-sink" (argument: "device_id=0 > sink_name=alsa_output.pci_8086_27d8_alsa_playback_0"): initialization > failed. > Dec 3 10:59:28 localhost pulseaudio[3995]: alsa-util.c: Error opening > PCM device hw:0: No such device > Dec 3 10:59:28 localhost pulseaudio[3995]: module.c: Failed to load > module "module-alsa-source" (argument: "device_id=0 > source_name=alsa_input.pci_8086_27d8_alsa_capture_0"): initialization > failed. > Dec 3 10:59:29 localhost pulseaudio[3995]: module.c: Failed to load > module "module-rtp-recv" (argument: ""): initialization failed. > Dec 3 10:59:29 localhost pulseaudio[3995]: module-gconf.c: > pa_module_load() failed > I ran 'semodule -DB' and rebooted in enforcing mode. I attach below the complete list of AVCs from /var/log/audit/audit.log. Eliminating some of the obvious ones (e.g., from NetworkManager, etc.) leaves the 'allows' below. Do any of them seem likely? #============= avahi_t ============== allow avahi_t init_t:fd use; #============= consolekit_t ============== allow consolekit_t NetworkManager_t:process ptrace; allow consolekit_t init_t:fd use; allow consolekit_t xdm_t:process ptrace; #============= hald_t ============== allow hald_t cupsd_config_t:process { siginh rlimitinh noatsecure }; allow hald_t dmidecode_t:process { siginh rlimitinh noatsecure }; allow hald_t hald_acl_t:process { siginh rlimitinh noatsecure }; allow hald_t init_t:fd use; allow hald_t udev_t:process { siginh rlimitinh noatsecure }; #============= insmod_t ============== allow insmod_t tty_device_t:chr_file { read write }; allow insmod_t xdm_t:fd use; allow insmod_t xdm_xserver_t:tcp_socket { read write }; allow insmod_t xdm_xserver_t:unix_stream_socket { read write }; allow insmod_t xserver_log_t:file write; #============= pam_t ============== allow pam_t xdm_t:fd use; #============= setrans_t ============== allow setrans_t init_t:fd use; allow setrans_t security_t:filesystem getattr; #============= setroubleshootd_t ============== allow setroubleshootd_t init_t:fd use; allow setroubleshootd_t rpm_var_lib_t:dir write; #============= system_chkpwd_t ============== allow system_chkpwd_t security_t:dir search; allow system_chkpwd_t security_t:filesystem getattr; #============= system_dbusd_t ============== allow system_dbusd_t NetworkManager_t:process { siginh rlimitinh noatsecure }; #============= udev_t ============== allow udev_t pam_console_t:process { siginh rlimitinh noatsecure }; #============= updpwd_t ============== allow updpwd_t security_t:dir search; allow updpwd_t security_t:filesystem getattr; allow updpwd_t selinux_config_t:dir search; #============= xdm_t ============== allow xdm_t pam_console_t:process { siginh rlimitinh noatsecure }; allow xdm_t system_chkpwd_t:process { siginh rlimitinh noatsecure }; allow xdm_t unconfined_t:process { siginh noatsecure }; allow xdm_t updpwd_t:process { siginh rlimitinh noatsecure }; allow xdm_t xdm_dbusd_t:process { siginh rlimitinh noatsecure }; allow xdm_t xdm_xserver_t:dir search; #============= xdm_xserver_t ============== allow xdm_xserver_t insmod_t:process { siginh rlimitinh noatsecure }; allow xdm_xserver_t security_t:dir search; allow xdm_xserver_t security_t:filesystem getattr; allow xdm_xserver_t selinux_config_t:dir search; tom -- Tom London From selinux at gmail.com Mon Dec 3 23:54:43 2007 From: selinux at gmail.com (Tom London) Date: Mon, 3 Dec 2007 15:54:43 -0800 Subject: pulseaudio, policykit - works in permissive, fails in enforcing In-Reply-To: <4c4ba1530712031550sda04922n45a03a497c6c1b42@mail.gmail.com> References: <4c4ba1530712031120i7e071207o226d0487829db847@mail.gmail.com> <4c4ba1530712031522v3a88bae6h23b3c6fe0ab41c84@mail.gmail.com> <4c4ba1530712031550sda04922n45a03a497c6c1b42@mail.gmail.com> Message-ID: <4c4ba1530712031554j52bda259x47d9b68bd5035e8@mail.gmail.com> On Dec 3, 2007 3:50 PM, Tom London wrote: > Forgot to attach the AVCs...... > > Does this one look suspicious? > > type=AVC msg=audit(1196722543.811:703): avc: denied { search } for > pid=2746 comm="ck-get-x11-disp" name="2719" dev=proc ino=9484 > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=dir > type=SYSCALL msg=audit(1196722543.811:703): arch=40000003 syscall=5 > success=no exit=-13 a0=8299418 a1=8000 a2=0 a3=8000 items=0 ppid=2715 > pid=2746 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=(none) comm="ck-get-x11-disp" > exe="/usr/libexec/ck-get-x11-display-device" > subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) > Attached compressed....sigh tom -- Tom London -------------- next part -------------- A non-text attachment was scrubbed... Name: logDB.txt.gz Type: application/x-gzip Size: 9118 bytes Desc: not available URL: From aleksander.adamowski at altkom.pl Tue Dec 4 10:01:14 2007 From: aleksander.adamowski at altkom.pl (Aleksander Adamowski) Date: Tue, 04 Dec 2007 11:01:14 +0100 Subject: AW: RHEL5 + strict policy: Unprivileged user cron - "Unauthorized SELinux context" In-Reply-To: <47542C45.1000400@redhat.com> References: <783545.32918.qm@web27710.mail.ukl.yahoo.com> <47542C45.1000400@redhat.com> Message-ID: <4755256A.2000208@altkom.pl> Daniel J Walsh pisze: > Please update to the U1 policy. > > I think you should be able to get this from RHN or you can grab it off of > http://people.redhat.com/dwalsh/SELinux/RHEL5 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFHVCxErlYvE4MpobMRAhI4AKDNDDa5Nmz0D1hzlneVDMwrCoV6jwCfWCwd > lrYMtBD3xAYpoQ8CFlH8sWM= > =H/J2 > -----END PGP SIGNATURE----- > It seems OK now, when I use "crontab -e -u unprivileged_user", the created crontab file looks like this: $ ls -lZ /var/spool/cron/unprivileged_user -rw------- root root root:object_r:sysadm_cron_spool_t /var/spool/cron/unprivileged_user The version I have is: $ rpm -q selinux-policy-strict selinux-policy-strict-2.4.6-106.el5_1.3 -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl -- Aleksander Adamowski Administrator system?w korporacyjnych; Instruktor Altkom Akademia S.A. http://www.altkom.pl Warszawa, ul. Ch?odna 51 kom. 0-601-318-080 S?d Rejonowy dla m.st. Warszawy w Warszawie, XII Wydzia? Gospodarczy Krajowego Rejestru S?dowego, KRS: 0000120139, NIP 118-00-08-391, Kapita? zak?adowy: 1000 000 PLN. Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa. Niniejsza wiadomo?? zawiera informacje zastrze?one i stanowi?ce tajemnic? przedsi?biorstwa firmy Altkom Akademia S.A. Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do w?asnych cel?w jest zabronione. Je?eli otrzymali?cie Pa?stwo niniejsz? wiadomo?? omy?kowo, prosimy o niezw?oczne skontaktowanie si? z nadawc? oraz usuni?cie wszelkich kopii niniejszej wiadomo?ci. This message contains proprietary information and trade secrets of Altkom Akademia S.A. company. Unauthorized use or disclosure of this information to any third party is prohibited. If you received this message by mistake, please contact the sender immediately and delete all copies of this message. From selinux at gmail.com Tue Dec 4 18:16:50 2007 From: selinux at gmail.com (Tom London) Date: Tue, 4 Dec 2007 10:16:50 -0800 Subject: pulseaudio, policykit - works in permissive, fails in enforcing In-Reply-To: <4c4ba1530712031554j52bda259x47d9b68bd5035e8@mail.gmail.com> References: <4c4ba1530712031120i7e071207o226d0487829db847@mail.gmail.com> <4c4ba1530712031522v3a88bae6h23b3c6fe0ab41c84@mail.gmail.com> <4c4ba1530712031550sda04922n45a03a497c6c1b42@mail.gmail.com> <4c4ba1530712031554j52bda259x47d9b68bd5035e8@mail.gmail.com> Message-ID: <4c4ba1530712041016y2201740vb7d0fb6a3a5f31f4@mail.gmail.com> On Dec 3, 2007 3:54 PM, Tom London wrote: > > On Dec 3, 2007 3:50 PM, Tom London wrote: > > Forgot to attach the AVCs...... > > > > Does this one look suspicious? > > > > type=AVC msg=audit(1196722543.811:703): avc: denied { search } for > > pid=2746 comm="ck-get-x11-disp" name="2719" dev=proc ino=9484 > > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > > tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=dir > > type=SYSCALL msg=audit(1196722543.811:703): arch=40000003 syscall=5 > > success=no exit=-13 a0=8299418 a1=8000 a2=0 a3=8000 items=0 ppid=2715 > > pid=2746 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > > sgid=0 fsgid=0 tty=(none) comm="ck-get-x11-disp" > > exe="/usr/libexec/ck-get-x11-display-device" > > subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) > > > > Attached compressed....sigh > Reran the above in permissive mode. This seemed suspicious: type=AVC msg=audit(1196779565.801:132): avc: denied { search } for pid=2614 comm="ck-get-x11-disp" name="2587" dev=proc ino=9642 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=dir type=AVC msg=audit(1196779565.801:132): avc: denied { read } for pid=2614 comm="ck-get-x11-disp" name="stat" dev=proc ino=9861 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=file type=SYSCALL msg=audit(1196779565.801:132): arch=40000003 syscall=5 success=yes exit=4 a0=8d27418 a1=8000 a2=0 a3=8000 items=0 ppid=2585 pid=2614 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ck-get-x11-disp" exe="/usr/libexec/ck-get-x11-display-device" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1196779565.802:133): avc: denied { getattr } for pid=2614 comm="ck-get-x11-disp" path="/proc/2587/stat" dev=proc ino=9861 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=file type=SYSCALL msg=audit(1196779565.802:133): arch=40000003 syscall=197 success=yes exit=0 a0=4 a1=bff4cfc8 a2=bdcff4 a3=8d27418 items=0 ppid=2585 pid=2614 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ck-get-x11-disp" exe="/usr/libexec/ck-get-x11-display-device" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) So, I did a 'audit2allow -M localpulse2' on the above. Here is the .te file: module localpulse2 1.0; require { type xdm_xserver_t; type xdm_t; class dir search; class file { read getattr }; } #============= xdm_t ============== allow xdm_t xdm_xserver_t:dir search; allow xdm_t xdm_xserver_t:file { read getattr }; 'semodule -i localpulse2.pp' makes pulseaudio work. Should this be added? tom -- Tom London From shintaro.fujiwara at gmail.com Tue Dec 4 21:50:11 2007 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Wed, 5 Dec 2007 06:50:11 +0900 Subject: [Bug] about the bug with semanage In-Reply-To: <475429B8.6090300@redhat.com> References: <474CFA2E.5090709@gmail.com> <475429B8.6090300@redhat.com> Message-ID: 2007/12/4, Daniel J Walsh : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ken YANG wrote: > > > > hi selinuxers: > > > > several days, i remmeber someone report a bug about > > semanage in non-english locale: Actually I reported it. > > -(:11:30:$)-> locale > > LANG=zh_CN.UTF-8 > > LC_CTYPE="zh_CN.UTF-8" > > LC_NUMERIC="zh_CN.UTF-8" > > LC_TIME="zh_CN.UTF-8" > > LC_COLLATE="zh_CN.UTF-8" > > LC_MONETARY="zh_CN.UTF-8" > > LC_MESSAGES="zh_CN.UTF-8" > > LC_PAPER="zh_CN.UTF-8" > > LC_NAME="zh_CN.UTF-8" > > LC_ADDRESS="zh_CN.UTF-8" > > LC_TELEPHONE="zh_CN.UTF-8" > > LC_MEASUREMENT="zh_CN.UTF-8" > > LC_IDENTIFICATION="zh_CN.UTF-8" > > LC_ALL= > > -(yangshao at NZzi:pts/4)--------------------(~)-(3/133)- > > -(:13:17:$)-> sudo semanage login -l > > /usr/sbin/semanage: ascii > > > > -(:11:02:$)-> LANG=C sudo semanage login -l > > > > Login Name SELinux User MLS/MCS Range > > > > __default__ system_u s0 > > root root -s0:c0.c255 > > system_u system_u SystemLow-SystemHigh > > > > > > i notice this bug is fixed in F9 rawhide, but F8 has not > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > I believe the latest updates of F8 and Rawhide should fix this problem. I updated yesterday to newest policy on F8, but still having this problem. I can avoid this problem, but perplexed. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFHVCm4rlYvE4MpobMRAuueAKC69E/NKWF0IlfkOAM0XRmIFihLBQCg3lUJ > 1zpz+q9vHEsDVPhpwO9NYiw= > =dCzD > -----END PGP SIGNATURE----- > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- Shintaro Fujiwara segatex project (SELinux policy tool) http://sourceforge.net/projects/segatex/ Home page http://intrajp.no-ip.com/ Blog http://intrajp.no-ip.com/nucleus/ CMS http://intrajp.no-ip.com/xoops/ Wiki http://intrajp.no-ip.com/pukiwiki/ From maximilian_bianco at yahoo.com Wed Dec 5 03:25:47 2007 From: maximilian_bianco at yahoo.com (Maximilian Bianco) Date: Tue, 4 Dec 2007 19:25:47 -0800 (PST) Subject: Good Primer Message-ID: <486900.61230.qm@web62305.mail.re1.yahoo.com> No offense to Google but I prefer to consult with my fellow humans sometimes....where can i find a good intro or primer on SELinux? All opinions welcome. Thanks Max ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From dwalsh at redhat.com Wed Dec 5 16:22:31 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 05 Dec 2007 11:22:31 -0500 Subject: [Bug] about the bug with semanage In-Reply-To: References: <474CFA2E.5090709@gmail.com> <475429B8.6090300@redhat.com> Message-ID: <4756D047.4000801@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Shintaro Fujiwara wrote: > 2007/12/4, Daniel J Walsh : > Ken YANG wrote: >>>> hi selinuxers: >>>> >>>> several days, i remmeber someone report a bug about >>>> semanage in non-english locale: > >> Actually I reported it. > >>>> -(:11:30:$)-> locale >>>> LANG=zh_CN.UTF-8 >>>> LC_CTYPE="zh_CN.UTF-8" >>>> LC_NUMERIC="zh_CN.UTF-8" >>>> LC_TIME="zh_CN.UTF-8" >>>> LC_COLLATE="zh_CN.UTF-8" >>>> LC_MONETARY="zh_CN.UTF-8" >>>> LC_MESSAGES="zh_CN.UTF-8" >>>> LC_PAPER="zh_CN.UTF-8" >>>> LC_NAME="zh_CN.UTF-8" >>>> LC_ADDRESS="zh_CN.UTF-8" >>>> LC_TELEPHONE="zh_CN.UTF-8" >>>> LC_MEASUREMENT="zh_CN.UTF-8" >>>> LC_IDENTIFICATION="zh_CN.UTF-8" >>>> LC_ALL= >>>> -(yangshao at NZzi:pts/4)--------------------(~)-(3/133)- >>>> -(:13:17:$)-> sudo semanage login -l >>>> /usr/sbin/semanage: ascii >>>> >>>> -(:11:02:$)-> LANG=C sudo semanage login -l >>>> >>>> Login Name SELinux User MLS/MCS Range >>>> >>>> __default__ system_u s0 >>>> root root -s0:c0.c255 >>>> system_u system_u SystemLow-SystemHigh >>>> >>>> >>>> i notice this bug is fixed in F9 rawhide, but F8 has not >>>> >>>> -- >>>> fedora-selinux-list mailing list >>>> fedora-selinux-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > I believe the latest updates of F8 and Rawhide should fix this problem. > > >> I updated yesterday to newest policy on F8, but still having this problem. >> I can avoid this problem, but perplexed. > >> - -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> What are you actually seeing now? What language? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVtBHrlYvE4MpobMRAjsdAJ4rVM9F3Cv6DoXateRn3DE/fQ9x6wCfUcQX XiGYezHUWcdxY4vKSpZ08tQ= =26mQ -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed Dec 5 16:25:31 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 05 Dec 2007 11:25:31 -0500 Subject: pulseaudio, policykit - works in permissive, fails in enforcing In-Reply-To: <4c4ba1530712041016y2201740vb7d0fb6a3a5f31f4@mail.gmail.com> References: <4c4ba1530712031120i7e071207o226d0487829db847@mail.gmail.com> <4c4ba1530712031522v3a88bae6h23b3c6fe0ab41c84@mail.gmail.com> <4c4ba1530712031550sda04922n45a03a497c6c1b42@mail.gmail.com> <4c4ba1530712031554j52bda259x47d9b68bd5035e8@mail.gmail.com> <4c4ba1530712041016y2201740vb7d0fb6a3a5f31f4@mail.gmail.com> Message-ID: <4756D0FB.8050602@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > On Dec 3, 2007 3:54 PM, Tom London wrote: >> On Dec 3, 2007 3:50 PM, Tom London wrote: >>> Forgot to attach the AVCs...... >>> >>> Does this one look suspicious? >>> >>> type=AVC msg=audit(1196722543.811:703): avc: denied { search } for >>> pid=2746 comm="ck-get-x11-disp" name="2719" dev=proc ino=9484 >>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 >>> tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=dir >>> type=SYSCALL msg=audit(1196722543.811:703): arch=40000003 syscall=5 >>> success=no exit=-13 a0=8299418 a1=8000 a2=0 a3=8000 items=0 ppid=2715 >>> pid=2746 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 >>> sgid=0 fsgid=0 tty=(none) comm="ck-get-x11-disp" >>> exe="/usr/libexec/ck-get-x11-display-device" >>> subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) >>> >> Attached compressed....sigh >> > Reran the above in permissive mode. This seemed suspicious: > > type=AVC msg=audit(1196779565.801:132): avc: denied { search } for > pid=2614 comm="ck-get-x11-disp" name="2587" dev=proc ino=9642 > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=dir > type=AVC msg=audit(1196779565.801:132): avc: denied { read } for > pid=2614 comm="ck-get-x11-disp" name="stat" dev=proc ino=9861 > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=file > type=SYSCALL msg=audit(1196779565.801:132): arch=40000003 syscall=5 > success=yes exit=4 a0=8d27418 a1=8000 a2=0 a3=8000 items=0 ppid=2585 > pid=2614 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=(none) comm="ck-get-x11-disp" > exe="/usr/libexec/ck-get-x11-display-device" > subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1196779565.802:133): avc: denied { getattr } for > pid=2614 comm="ck-get-x11-disp" path="/proc/2587/stat" dev=proc > ino=9861 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=file > type=SYSCALL msg=audit(1196779565.802:133): arch=40000003 syscall=197 > success=yes exit=0 a0=4 a1=bff4cfc8 a2=bdcff4 a3=8d27418 items=0 > ppid=2585 pid=2614 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 tty=(none) comm="ck-get-x11-disp" > exe="/usr/libexec/ck-get-x11-display-device" > subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) > > So, I did a 'audit2allow -M localpulse2' on the above. > > Here is the .te file: > > module localpulse2 1.0; > > require { > type xdm_xserver_t; > type xdm_t; > class dir search; > class file { read getattr }; > } > > #============= xdm_t ============== > allow xdm_t xdm_xserver_t:dir search; > allow xdm_t xdm_xserver_t:file { read getattr }; > > 'semodule -i localpulse2.pp' makes pulseaudio work. > > Should this be added? > > tom I have added this to the latest rawhide policy 3.2.2-1 BTW: a handy tool to see what consolekit thinks of you is > ck-list-sessions Session2: uid = '3267' realname = 'Daniel J Walsh,,978-392-3130,508-485-6146' seat = 'Seat1' session-type = '' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2007-12-04T18:46:05Z' If it does not show active, then consolekit thinks you are not on the console and will not change the permissions on the devices. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVtD7rlYvE4MpobMRAhu3AJoDabDb46sprRHbhG1hyszuxe3ivACgh/Fu 9g6WxQLmLHKd/50xwZh5tRg= =em8+ -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed Dec 5 16:26:24 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 05 Dec 2007 11:26:24 -0500 Subject: Good Primer In-Reply-To: <486900.61230.qm@web62305.mail.re1.yahoo.com> References: <486900.61230.qm@web62305.mail.re1.yahoo.com> Message-ID: <4756D130.6030602@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maximilian Bianco wrote: > No offense to Google but I prefer to consult with my > fellow humans sometimes....where can i find a good > intro or primer on SELinux? All opinions welcome. > > Thanks > > Max > > > ____________________________________________________________________________________ > Looking for last minute shopping deals? > Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list My favorite is my blog. :^) danwalsh.livejournal.com Read it from the beginning. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHVtEwrlYvE4MpobMRAuwRAJ9oIbI50kUdcvryTW/lmAtj+115wACdFk7i joqd5MczofHOcKzOz7DH3lI= =I1zW -----END PGP SIGNATURE----- From shintaro.fujiwara at gmail.com Wed Dec 5 20:44:00 2007 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Thu, 6 Dec 2007 05:44:00 +0900 Subject: [Bug] about the bug with semanage In-Reply-To: <4756D047.4000801@redhat.com> References: <474CFA2E.5090709@gmail.com> <475429B8.6090300@redhat.com> <4756D047.4000801@redhat.com> Message-ID: 2007/12/6, Daniel J Walsh : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Shintaro Fujiwara wrote: > > 2007/12/4, Daniel J Walsh : > > Ken YANG wrote: > >>>> hi selinuxers: > >>>> > >>>> several days, i remmeber someone report a bug about > >>>> semanage in non-english locale: > > > >> Actually I reported it. > > > >>>> -(:11:30:$)-> locale > >>>> LANG=zh_CN.UTF-8 > >>>> LC_CTYPE="zh_CN.UTF-8" > >>>> LC_NUMERIC="zh_CN.UTF-8" > >>>> LC_TIME="zh_CN.UTF-8" > >>>> LC_COLLATE="zh_CN.UTF-8" > >>>> LC_MONETARY="zh_CN.UTF-8" > >>>> LC_MESSAGES="zh_CN.UTF-8" > >>>> LC_PAPER="zh_CN.UTF-8" > >>>> LC_NAME="zh_CN.UTF-8" > >>>> LC_ADDRESS="zh_CN.UTF-8" > >>>> LC_TELEPHONE="zh_CN.UTF-8" > >>>> LC_MEASUREMENT="zh_CN.UTF-8" > >>>> LC_IDENTIFICATION="zh_CN.UTF-8" > >>>> LC_ALL= > >>>> -(yangshao at NZzi:pts/4)--------------------(~)-(3/133)- > >>>> -(:13:17:$)-> sudo semanage login -l > >>>> /usr/sbin/semanage: ascii > >>>> > >>>> -(:11:02:$)-> LANG=C sudo semanage login -l > >>>> > >>>> Login Name SELinux User MLS/MCS Range > >>>> > >>>> __default__ system_u s0 > >>>> root root -s0:c0.c255 > >>>> system_u system_u SystemLow-SystemHigh > >>>> > >>>> > >>>> i notice this bug is fixed in F9 rawhide, but F8 has not > >>>> > >>>> -- > >>>> fedora-selinux-list mailing list > >>>> fedora-selinux-list at redhat.com > >>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > I believe the latest updates of F8 and Rawhide should fix this problem. > > > > > >> I updated yesterday to newest policy on F8, but still having this problem. > >> I can avoid this problem, but perplexed. Oh, sorry, I yum updated again and typed #semanage login -l again, and found it had been fixed. Thanks ! > >> > - -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > >> > > What are you actually seeing now? > > What language? > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFHVtBHrlYvE4MpobMRAjsdAJ4rVM9F3Cv6DoXateRn3DE/fQ9x6wCfUcQX > XiGYezHUWcdxY4vKSpZ08tQ= > =26mQ > -----END PGP SIGNATURE----- > -- Shintaro Fujiwara segatex project (SELinux policy tool) http://sourceforge.net/projects/segatex/ Home page http://intrajp.no-ip.com/ Blog http://intrajp.no-ip.com/nucleus/ CMS http://intrajp.no-ip.com/xoops/ Wiki http://intrajp.no-ip.com/pukiwiki/ From chris at yipyap.com Thu Dec 6 05:51:59 2007 From: chris at yipyap.com (Chris Howard) Date: Wed, 05 Dec 2007 22:51:59 -0700 Subject: home directory problems with Fedora 8 Message-ID: <1196920319.3483.7.camel@w0ep.yipyap.com> I have previously existing home directories under /u01/home. I did this because upgrading from FC6 to Fedora 7 caused me trouble and I want to avoid having to recreate my home directory. So I copied the whole system into /u01 before doing a fresh Fedora 8 install. I do not have a separate home-only partition. SELinux prevents me from making a symbolic link like this: /home--> /u01/home or like this /home/chris--> /u01/home/chris. If I setup a dummy user with home at /home/chris, then edit /etc/passwd to change the home to /u01/home/chris... that doesn't work either. nor if I create a new user like so: useradd -d /u01/home/pete pete Is there something magic about the string '/home' ? that keeps me from creating home directories anywhere else? I'd really love to keep from smashing /home on every OS reload. For now I have SELinux in Permissive mode so I can at least use the system. From fedora02 at grifent.com Thu Dec 6 17:15:06 2007 From: fedora02 at grifent.com (John Griffiths) Date: Thu, 06 Dec 2007 12:15:06 -0500 Subject: home directory problems with Fedora 8 In-Reply-To: <20071206170009.9C8F2734BB@hormel.redhat.com> References: <20071206170009.9C8F2734BB@hormel.redhat.com> Message-ID: <47582E1A.5080302@grifent.com> My reply is not selinux related but will solve you bashing the /home. Put /home on a separate file system. When you install Fedora 9 or whatever comes down the pike, install and use the advanced options for the disk layout. Do not change the lay out and make sure you know which partition belongs to which file system. Lay them out the same way and choose not to format the partitions you want to keep. Depending on what options you choose, you may have to just not do anything with the /home file system at install and add the mount after the installation over the /home directory. Works for me. Regards, John > > Subject: > home directory problems with Fedora 8 > From: > Chris Howard > Date: > Wed, 05 Dec 2007 22:51:59 -0700 > To: > fedora-selinux-list at redhat.com > > To: > fedora-selinux-list at redhat.com > > Content-Transfer-Encoding: > 7bit > Precedence: > junk > MIME-Version: > 1.0 > Reply-To: > chris at yipyap.com > Message-ID: > <1196920319.3483.7.camel at w0ep.yipyap.com> > Content-Type: > text/plain > Message: > 2 > > > I have previously existing home directories under /u01/home. > I did this because upgrading from FC6 to Fedora 7 caused me trouble > and I want to avoid having to recreate my home directory. So I copied > the whole system into /u01 before doing a fresh Fedora 8 install. I > do not have a separate home-only partition. > > SELinux prevents me from making a symbolic link like this: > > /home--> /u01/home or like this > > /home/chris--> /u01/home/chris. > > If I setup a dummy user with home at /home/chris, then > edit /etc/passwd to change the home to /u01/home/chris... that doesn't > work either. > > nor if I create a new user like so: > > useradd -d /u01/home/pete pete > > Is there something magic about the string '/home' ? > that keeps me from creating home directories anywhere else? > > I'd really love to keep from smashing /home on every OS reload. > > For now I have SELinux in Permissive mode so I can at least use the > system. > > > > > > > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From selinux at gmail.com Thu Dec 6 17:42:30 2007 From: selinux at gmail.com (Tom London) Date: Thu, 6 Dec 2007 09:42:30 -0800 Subject: AVC with today's rawhide Message-ID: <4c4ba1530712060942m3ea4a5e3s8b56aeb77d65c42d@mail.gmail.com> I think today's policykit update needs some more love.... Graphical login failed with 'respawn too fast' messages. Here are the AVCs: type=AVC msg=audit(1196960817.504:18): avc: denied { read } for pid=2324 comm="hald" name="PolicyKit.reload" dev=dm-0 ino=67633 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:system_crond_var_lib_t:s0 tclass=file type=SYSCALL msg=audit(1196960817.504:18): arch=40000003 syscall=292 success=no exit=-13 a0=d a1=923400 a2=106 a3=9b25d88 items=0 ppid=2323 pid=2324 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="hald" exe="/usr/sbin/hald" subj=system_u:system_r:hald_t:s0 key=(null) type=AVC msg=audit(1196961900.294:38): avc: denied { getattr } for pid=3308 comm="polkit-read-aut" scontext=root:system_r:hald_t:s0 tcontext=root:system_r:hald_t:s0 tclass=process type=SYSCALL msg=audit(1196961900.294:38): arch=40000003 syscall=3 success=yes exit=24 a0=4 a1=945f538 a2=fff a3=fff items=0 ppid=2833 pid=3308 auid=0 uid=68 gid=68 euid=68 suid=68 fsuid=68 egid=87 sgid=87 fsgid=87 tty=(none) comm="polkit-read-aut" exe="/usr/libexec/polkit-read-auth-helper" subj=root:system_r:hald_t:s0 key=(null) 'audit2allow -M'/etc. fixes: #============= hald_t ============== allow hald_t self:process getattr; allow hald_t system_crond_var_lib_t:file read; tom -- Tom London From matt at gillens.us Thu Dec 6 17:49:29 2007 From: matt at gillens.us (Matthew Gillen) Date: Thu, 06 Dec 2007 12:49:29 -0500 Subject: home directory problems with Fedora 8 In-Reply-To: <1196920319.3483.7.camel@w0ep.yipyap.com> References: <1196920319.3483.7.camel@w0ep.yipyap.com> Message-ID: <47583629.9090407@gillens.us> Chris Howard wrote: > I have previously existing home directories under /u01/home. > I did this because upgrading from FC6 to Fedora 7 caused me trouble > and I want to avoid having to recreate my home directory. So I copied > the whole system into /u01 before doing a fresh Fedora 8 install. I > do not have a separate home-only partition. > > SELinux prevents me from making a symbolic link like this: > > /home--> /u01/home or like this > > /home/chris--> /u01/home/chris. I wouldn't do symlinks like that unless you have some strange reason to. Just have /etc/passwd point to the actual directories under /u01/home. > If I setup a dummy user with home at /home/chris, then > edit /etc/passwd to change the home to /u01/home/chris... that doesn't > work either. > > nor if I create a new user like so: > > useradd -d /u01/home/pete pete > > Is there something magic about the string '/home' ? > that keeps me from creating home directories anywhere else? > > I'd really love to keep from smashing /home on every OS reload. > > For now I have SELinux in Permissive mode so I can at least use the > system. Here's how I /think/ it works: a) If you've got an empty /u01/home, and you want to add new users, do this: Set the type of /u01/home to home_root_t: chcon -t home_root_t /u01/home and then useradd -d /u01/home/pete will do the right thing. b) Supposing you already have some use home dirs there (ie the homeidrs in /etc/passwd point to /u01/home/*), I think you can just run 'genhomedircon' and then run: restorcon -R -v /u01/home In the case of (b), it doesn't hurt to do the chcon operation first, but I don't think it's necessary. (note: I'm not an expert myself, but if these steps don't work for you, they should at least point you in the right direction). HTH, Matt From jczucco at ucs.br Thu Dec 6 18:29:35 2007 From: jczucco at ucs.br (Jeronimo Zucco) Date: Thu, 06 Dec 2007 16:29:35 -0200 Subject: Good Primer In-Reply-To: <486900.61230.qm@web62305.mail.re1.yahoo.com> References: <486900.61230.qm@web62305.mail.re1.yahoo.com> Message-ID: <47583F8F.2050007@ucs.br> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maximilian Bianco wrote: > No offense to Google but I prefer to consult with my > fellow humans sometimes....where can i find a good > intro or primer on SELinux? All opinions welcome. > http://fedoraproject.org/wiki/SELinux/Understanding Or you can browse all my bookmarks either: http://del.icio.us/jczucco/selinux - -- Jeronimo Zucco LPIC-1 Linux Professional Institute Certified N?cleo de Processamento de Dados Universidade de Caxias do Sul http://jczucco.blogspot.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHWD+PWi/PuDd2cZARAjs/AJ90VXMwzVx1T2U5VyxzzpQ3dwImgACfYaXQ YVECt1k9ibuh+/qvygoMhKg= =SlBL -----END PGP SIGNATURE----- From chris at yipyap.com Fri Dec 7 01:40:20 2007 From: chris at yipyap.com (Chris Howard) Date: Thu, 06 Dec 2007 18:40:20 -0700 Subject: home directory problems with Fedora 8 In-Reply-To: <47583629.9090407@gillens.us> References: <1196920319.3483.7.camel@w0ep.yipyap.com> <47583629.9090407@gillens.us> Message-ID: <1196991620.3863.2.camel@w0ep.yipyap.com> On Thu, 2007-12-06 at 12:49 -0500, Matthew Gillen wrote: > Chris Howard wrote: > > I have previously existing home directories under /u01/home. > > I did this because upgrading from FC6 to Fedora 7 caused me trouble > > and I want to avoid having to recreate my home directory. So I copied > > the whole system into /u01 before doing a fresh Fedora 8 install. I > > do not have a separate home-only partition. > > > > SELinux prevents me from making a symbolic link like this: > > > > /home--> /u01/home or like this > > > > /home/chris--> /u01/home/chris. > > I wouldn't do symlinks like that unless you have some strange reason to. Just > have /etc/passwd point to the actual directories under /u01/home. > > > If I setup a dummy user with home at /home/chris, then > > edit /etc/passwd to change the home to /u01/home/chris... that doesn't > > work either. > > > > nor if I create a new user like so: > > > > useradd -d /u01/home/pete pete > > > > Is there something magic about the string '/home' ? > > that keeps me from creating home directories anywhere else? > > > > I'd really love to keep from smashing /home on every OS reload. > > > > For now I have SELinux in Permissive mode so I can at least use the > > system. > > Here's how I /think/ it works: > a) If you've got an empty /u01/home, and you want to add new users, do this: > Set the type of /u01/home to home_root_t: > chcon -t home_root_t /u01/home > and then useradd -d /u01/home/pete will do the right thing. > > b) Supposing you already have some use home dirs there (ie the homeidrs in > /etc/passwd point to /u01/home/*), I think you can just run 'genhomedircon' > and then run: > restorcon -R -v /u01/home > > In the case of (b), it doesn't hurt to do the chcon operation first, but I > don't think it's necessary. > > (note: I'm not an expert myself, but if these steps don't work for you, they > should at least point you in the right direction). > > HTH, > Matt > Thanks Matt... but it doesn't work. When I do: chcon-t home_root_t /u01/home then a: restorecon -R -v /u01/home changes it back to default_t A system-wide recontext sets it back to: /u01 is default_t /u01/home is default_t /u01/home/chris is default_t ARGG! in the "real" filesystem / is root_t /home is home_root_t /usr is usr_t /var is var_t (maybe I need to make a u01_t??) later... If I set /u01/home to home_root_t and /u01/home/chris to unconfined_home_dir_t and all files under /u01/home/chris to unconfined_home_t then it works.... but recontexting will mess that all up again. Somewhere in this box there is something that won't let me put home directories on /u01/home. From matt at gillens.us Fri Dec 7 02:07:12 2007 From: matt at gillens.us (Matthew Gillen) Date: Thu, 06 Dec 2007 21:07:12 -0500 Subject: home directory problems with Fedora 8 In-Reply-To: <1196991620.3863.2.camel@w0ep.yipyap.com> References: <1196920319.3483.7.camel@w0ep.yipyap.com> <47583629.9090407@gillens.us> <1196991620.3863.2.camel@w0ep.yipyap.com> Message-ID: <4758AAD0.6040102@gillens.us> Chris Howard wrote: > Thanks Matt... but it doesn't work. > > When I do: > > chcon-t home_root_t /u01/home > > then a: > > restorecon -R -v /u01/home > > changes it back to default_t > > A system-wide recontext sets it back to: > > /u01 is default_t > /u01/home is default_t > /u01/home/chris is default_t Well, the brute force way would be to open up: /etc/selinux/targeted/contexts/files/file_contexts.homedirs and copy/paste all the "/home/*" entries and do some grep-replace on the new copy. A restorcon on /u01/home /should/ work then. Good luck, Matt From tony.molloy at ul.ie Fri Dec 7 08:44:22 2007 From: tony.molloy at ul.ie (Tony Molloy) Date: Fri, 7 Dec 2007 08:44:22 +0000 Subject: home directory problems with Fedora 8 In-Reply-To: <47583629.9090407@gillens.us> References: <1196920319.3483.7.camel@w0ep.yipyap.com> <47583629.9090407@gillens.us> Message-ID: <200712070844.22459.tony.molloy@ul.ie> On Thursday 06 December 2007 17:49, Matthew Gillen wrote: > Chris Howard wrote: > > I have previously existing home directories under /u01/home. > > I did this because upgrading from FC6 to Fedora 7 caused me trouble > > and I want to avoid having to recreate my home directory. So I copied > > the whole system into /u01 before doing a fresh Fedora 8 install. I > > do not have a separate home-only partition. > > > > SELinux prevents me from making a symbolic link like this: > > > > /home--> /u01/home or like this > > > > /home/chris--> /u01/home/chris. > > I wouldn't do symlinks like that unless you have some strange reason to. > Just have /etc/passwd point to the actual directories under /u01/home. > > > If I setup a dummy user with home at /home/chris, then > > edit /etc/passwd to change the home to /u01/home/chris... that doesn't > > work either. > > > > nor if I create a new user like so: > > > > useradd -d /u01/home/pete pete > > > > Is there something magic about the string '/home' ? > > that keeps me from creating home directories anywhere else? > > > > I'd really love to keep from smashing /home on every OS reload. > > > > For now I have SELinux in Permissive mode so I can at least use the > > system. > > Here's how I /think/ it works: > a) If you've got an empty /u01/home, and you want to add new users, do > this: Set the type of /u01/home to home_root_t: > chcon -t home_root_t /u01/home > and then useradd -d /u01/home/pete will do the right thing. > > b) Supposing you already have some use home dirs there (ie the homeidrs in > /etc/passwd point to /u01/home/*), I think you can just run 'genhomedircon' > and then run: > restorcon -R -v /u01/home > > In the case of (b), it doesn't hurt to do the chcon operation first, but I > don't think it's necessary. > > (note: I'm not an expert myself, but if these steps don't work for you, > they should at least point you in the right direction). > > HTH, > Matt > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list I had similar problems after a fresh install of F8 last week messed up my /users directory. After an off-list discussion with Daniel Walsh he traced it to a problem in libsemanage and released a new libsemanage to F8-testing libsemanage-2.0.12-2.fc8. Here is a snippet from his e-mail There is a bug in libsemanage that is preventing proper labeling. I have just released libsemanage-2.0.12-2.fc8 to fedora-testing. If you install this package, you can execute #semodule -B #restorecon -R -v /users and it should clean up the labeling. You can check what semodule and restorecon do in the man pages. Hope this helps, Tony From selinux at gmail.com Fri Dec 7 20:32:44 2007 From: selinux at gmail.com (Tom London) Date: Fri, 7 Dec 2007 12:32:44 -0800 Subject: hald_acl_t AVC Message-ID: <4c4ba1530712071232x6cb76c8w1f3a89c79d9dae3f@mail.gmail.com> Seeing this after some updates today (enforcing): #============= hald_acl_t ============== allow hald_acl_t self:fifo_file write; type=AVC msg=audit(1197057157.993:94): avc: denied { write } for pid=11138 comm="polkit-read-aut" path="pipe:[79635]" dev=pipefs ino=79635 scontext=system_u:system_r:hald_acl_t:s0 tcontext=system_u:system_r:hald_acl_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1197057157.993:94): arch=40000003 syscall=4 success=no exit=-13 a0=1 a1=bfea83c8 a2=9 a3=9 items=0 ppid=11123 pid=11138 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=87 sgid=87 fsgid=87 tty=(none) comm="polkit-read-aut" exe="/usr/libexec/polkit-read-auth-helper" subj=system_u:system_r:hald_acl_t:s0 key=(null) type=USER_ACCT msg=audit(1197057661.316:95): user pid=11508 uid=0 auid=4294967295 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct=root exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)' -- Tom London From shintaro.fujiwara at gmail.com Sat Dec 8 13:47:01 2007 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Sat, 8 Dec 2007 22:47:01 +0900 Subject: [Question] How enforcing and permissive differ on start-up Message-ID: Hi, I have a question on differences between permissve and enforcing. I installed courier-imap from source (as always), and configured courier.te, courier.fc just to apply installation-path to souece installation. There are two say, daemons, courier_$1_t, i.e. courier_authdaemon_t, and I had to declair domain_auto_trans(initrc_t, courier_exec_t, courier_t) (courier_t was not declared in courier.te, so I did) as I declared starting script in /etc/rc.d/rc.local. I set selinux enforcing and found that courier_authdaemon_t started all-right, but courier_t not. When I set selinux permissive, it started all-right. How should I fix this problem ? Thanks in advance ! -- Shintaro Fujiwara segatex project (SELinux policy tool) http://sourceforge.net/projects/segatex/ Home page http://intrajp.no-ip.com/ Blog http://intrajp.no-ip.com/nucleus/ CMS http://intrajp.no-ip.com/xoops/ Wiki http://intrajp.no-ip.com/pukiwiki/ From linuxweb at gmail.com Sat Dec 8 16:41:47 2007 From: linuxweb at gmail.com (Johnny Tan) Date: Sat, 08 Dec 2007 11:41:47 -0500 Subject: mounting nfs as httpd_sys_content_t under selinux Message-ID: <475AC94B.4090501@gmail.com> I have a NFS mount that I want apache to be able to serve files from. According to this doc: http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/en-US/RHEL510/Deployment_Guide/ch45s02s03.html I should be able to mount it with a context that will allow apache to access it. But when I try the suggested command: [root at vm-37:~] mount -t nfs -o \ context=system_u:object_r:httpd_sys_content_t \ 192.168.1.100:/data/test /mnt/test It *does* mount, but when I do: [root at vm-37:~]# ls -lZ /mnt drwxr-xr-x 65534 65534 system_u:object_r:nfs_t test It doesn't show the correct context. (I don't know if it matters that I don't have a user with UID 65534, only the remote NFS server has that.) And sure enough, apache still can't serve from it. I see this in /var/log/messages: Dec 7 17:30:14 vm-37 kernel: audit(1197066614.787:240): avc: denied { search } for pid=18066 comm="httpd" name= "" dev=0:14 ino=4301717509 scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir Dec 7 17:30:14 vm-37 kernel: audit(1197066614.787:241): avc: denied { getattr } for pid=18066 comm="httpd" name ="" dev=0:14 ino=4301717509 scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir When I "setenforce 0", it works. But I want SELinux. Granted, I could do: allow httpd_t nfs_t:dir { search getattr }; Well, actually, I haven't tried it but I'm guessing that that will work. The problem is that I have other nfs directories that I don't want httpd to access, even accidentally if we ever point httpd at those directories. So... any ideas on the nfs mount with the context option? I'm running CentOS-5.1 with latest updates of everything. johnn From fedora02 at grifent.com Sat Dec 8 22:03:14 2007 From: fedora02 at grifent.com (John Griffiths) Date: Sat, 08 Dec 2007 17:03:14 -0500 Subject: Adobe acroread In-Reply-To: <20071208170012.6CD8F73335@hormel.redhat.com> References: <20071208170012.6CD8F73335@hormel.redhat.com> Message-ID: <475B14A2.8080001@grifent.com> The Adobe acroread rpm from Adobe installs the plugin for firefox/mozilla with a context of system_u:object_r:lib_t nppdf.so. It will not run with that context because nppdf.so request text relocation, so selinux denies firefox to load nppdf.so. nppdf.so needs a context of system_u:object_r:textrel_shlib_t to run. Regards, John Griffiths From jczucco at ucs.br Sun Dec 9 02:55:14 2007 From: jczucco at ucs.br (Jeronimo Zucco) Date: Sun, 9 Dec 2007 00:55:14 -0200 Subject: MLS Security Levels Message-ID: <1197168914.475b59122bad7@webmail.ucs.br> How many is the atual max number of sensitivity level and max capabilities in a MLS security context ? In Fedora 5 was: s0-s15 and c0-c255. Today is the same values? Where can i get this information? -- Jeronimo Zucco LPIC-1 Linux Professional Institute Certified N?cleo de Processamento de Dados Universidade de Caxias do Sul http://jczucco.blogspot.com --------------------------------------- Essa mensagem foi enviada pelo UCS Mail From shintaro.fujiwara at gmail.com Sun Dec 9 16:04:00 2007 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Mon, 10 Dec 2007 01:04:00 +0900 Subject: [Question: solved ] How enforcing and permissive differ on start-up Message-ID: I looked courier.fc again and found type courier_..._exec_t. I set proper type courier_pop_exec_t, and others, eliminated my own difinisitons. And courier started up all-right in enforcing. Thanks ! -- Shintaro Fujiwara segatex project (SELinux policy tool) http://sourceforge.net/projects/segatex/ Home page http://intrajp.no-ip.com/ Blog http://intrajp.no-ip.com/nucleus/ CMS http://intrajp.no-ip.com/xoops/ Wiki http://intrajp.no-ip.com/pukiwiki/ From spng.yang at gmail.com Mon Dec 10 05:17:16 2007 From: spng.yang at gmail.com (NZzi) Date: Mon, 10 Dec 2007 13:17:16 +0800 Subject: Adobe acroread In-Reply-To: <475B14A2.8080001@grifent.com> References: <20071208170012.6CD8F73335@hormel.redhat.com> <475B14A2.8080001@grifent.com> Message-ID: <475CCBDC.1000900@gmail.com> John Griffiths ??: > The Adobe acroread rpm from Adobe installs the plugin for > firefox/mozilla with a context of system_u:object_r:lib_t > nppdf.so. > It will not run with that context because nppdf.so request text > relocation, so selinux denies firefox to load nppdf.so. nppdf.so needs a > context of system_u:object_r:textrel_shlib_t to run. you can follow the direction of setroubleshoot to enable the nppdf plugin, and report bug to adobe > > Regards, > John Griffiths > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From sds at tycho.nsa.gov Mon Dec 10 14:31:34 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 10 Dec 2007 09:31:34 -0500 Subject: [Question] How enforcing and permissive differ on start-up In-Reply-To: References: Message-ID: <1197297094.18120.28.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2007-12-08 at 22:47 +0900, Shintaro Fujiwara wrote: > Hi, I have a question on differences between permissve and enforcing. > > I installed courier-imap from source (as always), and configured > courier.te, courier.fc just to apply installation-path to souece installation. > > There are two say, daemons, courier_$1_t, i.e. courier_authdaemon_t, > and I had to declair > domain_auto_trans(initrc_t, courier_exec_t, courier_t) > (courier_t was not declared in courier.te, so I did) > as I declared starting script in /etc/rc.d/rc.local. > > I set selinux enforcing and found that courier_authdaemon_t started all-right, > but courier_t not. > When I set selinux permissive, it started all-right. > > How should I fix this problem ? Just to clarify, there is a difference between permissive and enforcing with regard to type transitions. In permissive, if the type transition would yield an invalid context (e.g. role is not authorized for the new type), it nonetheless is allowed to proceed, whereas in enforcing mode, it fails. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Dec 10 14:34:14 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 10 Dec 2007 09:34:14 -0500 Subject: mounting nfs as httpd_sys_content_t under selinux In-Reply-To: <475AC94B.4090501@gmail.com> References: <475AC94B.4090501@gmail.com> Message-ID: <1197297254.18120.33.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2007-12-08 at 11:41 -0500, Johnny Tan wrote: > I have a NFS mount that I want apache to be able to serve > files from. > > According to this doc: > http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/en-US/RHEL510/Deployment_Guide/ch45s02s03.html > > I should be able to mount it with a context that will allow > apache to access it. > > But when I try the suggested command: > > [root at vm-37:~] mount -t nfs -o \ > context=system_u:object_r:httpd_sys_content_t \ > 192.168.1.100:/data/test /mnt/test What kernel messages in /var/log/messages did you get when you ran this command? Did you already have a mount from the same server/filesystem when you tried doing this? If so, unmount those first and try again - context mounts are limited to one per superblock. > It *does* mount, but when I do: > [root at vm-37:~]# ls -lZ /mnt > drwxr-xr-x 65534 65534 system_u:object_r:nfs_t test > > It doesn't show the correct context. > > (I don't know if it matters that I don't have a user with > UID 65534, only the remote NFS server has that.) > > > And sure enough, apache still can't serve from it. I see > this in /var/log/messages: > Dec 7 17:30:14 vm-37 kernel: audit(1197066614.787:240): > avc: denied { search } for pid=18066 comm="httpd" name= > "" dev=0:14 ino=4301717509 scontext=root:system_r:httpd_t:s0 > tcontext=system_u:object_r:nfs_t:s0 tclass=dir > Dec 7 17:30:14 vm-37 kernel: audit(1197066614.787:241): > avc: denied { getattr } for pid=18066 comm="httpd" name > ="" dev=0:14 ino=4301717509 > scontext=root:system_r:httpd_t:s0 > tcontext=system_u:object_r:nfs_t:s0 tclass=dir > > When I "setenforce 0", it works. But I want SELinux. > > > Granted, I could do: > allow httpd_t nfs_t:dir { search getattr }; > > Well, actually, I haven't tried it but I'm guessing that > that will work. The problem is that I have other nfs > directories that I don't want httpd to access, even > accidentally if we ever point httpd at those directories. > > So... any ideas on the nfs mount with the context option? > > > I'm running CentOS-5.1 with latest updates of everything. > > johnn > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- Stephen Smalley National Security Agency From eparis at redhat.com Mon Dec 10 14:39:29 2007 From: eparis at redhat.com (Eric Paris) Date: Mon, 10 Dec 2007 09:39:29 -0500 Subject: mounting nfs as httpd_sys_content_t under selinux In-Reply-To: <475AC94B.4090501@gmail.com> References: <475AC94B.4090501@gmail.com> Message-ID: <1197297569.25989.5.camel@dhcp231-215.rdu.redhat.com> On Sat, 2007-12-08 at 11:41 -0500, Johnny Tan wrote: > I have a NFS mount that I want apache to be able to serve > files from. > > According to this doc: > http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/en-US/RHEL510/Deployment_Guide/ch45s02s03.html > > I should be able to mount it with a context that will allow > apache to access it. > > But when I try the suggested command: > > [root at vm-37:~] mount -t nfs -o \ > context=system_u:object_r:httpd_sys_content_t \ > 192.168.1.100:/data/test /mnt/test > > It *does* mount, but when I do: > [root at vm-37:~]# ls -lZ /mnt > drwxr-xr-x 65534 65534 system_u:object_r:nfs_t test > > It doesn't show the correct context. > > (I don't know if it matters that I don't have a user with > UID 65534, only the remote NFS server has that.) Do you have /data/test mounted somewhere else at the same time? Or maybe /data is the actual export from the server and you have /data/some_other_dir mounted somewhere else? If it is case #1 you are going to have to mount it the first time with the context= option. We can't have one mount using !context= and the other mount having context=. Just a way the software works. If it is case #2 it might work by mounting it with nosharecache (not sure if you have to do that on both mounts....) If it is neither of these cases can you file a RH bugzilla clearly explaining your versions of everything, how the server exports things, and what else the client has mounted at the time? -Eric From shintaro.fujiwara at gmail.com Mon Dec 10 16:51:58 2007 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Tue, 11 Dec 2007 01:51:58 +0900 Subject: [Question] How enforcing and permissive differ on start-up In-Reply-To: <1197297094.18120.28.camel@moss-spartans.epoch.ncsc.mil> References: <1197297094.18120.28.camel@moss-spartans.epoch.ncsc.mil> Message-ID: 2007/12/10, Stephen Smalley : > On Sat, 2007-12-08 at 22:47 +0900, Shintaro Fujiwara wrote: > > Hi, I have a question on differences between permissve and enforcing. > > > > I installed courier-imap from source (as always), and configured > > courier.te, courier.fc just to apply installation-path to souece installation. > > > > There are two say, daemons, courier_$1_t, i.e. courier_authdaemon_t, > > and I had to declair > > domain_auto_trans(initrc_t, courier_exec_t, courier_t) > > (courier_t was not declared in courier.te, so I did) > > as I declared starting script in /etc/rc.d/rc.local. > > > > I set selinux enforcing and found that courier_authdaemon_t started all-right, > > but courier_t not. > > When I set selinux permissive, it started all-right. > > > > How should I fix this problem ? > > Just to clarify, there is a difference between permissive and enforcing > with regard to type transitions. In permissive, if the type transition > would yield an invalid context (e.g. role is not authorized for the new > type), it nonetheless is allowed to proceed, whereas in enforcing mode, > it fails. I had a same kind of problem on cron in F6. I solved it somehow at the time, though. Now I'm trying to configure bind and it does not start up even in permissive. I think something is wrong with the application itself? I will ask again if I have a question on SELinux related matters. Thanks ! > -- > Stephen Smalley > National Security Agency > > -- Shintaro Fujiwara segatex project (SELinux policy tool) http://sourceforge.net/projects/segatex/ Home page http://intrajp.no-ip.com/ Blog http://intrajp.no-ip.com/nucleus/ CMS http://intrajp.no-ip.com/xoops/ Wiki http://intrajp.no-ip.com/pukiwiki/ From linuxweb at gmail.com Mon Dec 10 17:02:14 2007 From: linuxweb at gmail.com (Johnny Tan) Date: Mon, 10 Dec 2007 12:02:14 -0500 Subject: mounting nfs as httpd_sys_content_t under selinux In-Reply-To: <1197297254.18120.33.camel@moss-spartans.epoch.ncsc.mil> References: <475AC94B.4090501@gmail.com> <1197297254.18120.33.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <475D7116.9050604@gmail.com> Stephen Smalley wrote: > Did you already have a mount from the same server/filesystem when you > tried doing this? If so, unmount those first and try again - context > mounts are limited to one per superblock. Thanks Stephen & Eric. Yes, the problem was I had another mount from the same server. So, now both mounts have httpd_sys_content_t context even though I only put that option on one of them. I do not want the other mount to have this context. Based on what you're saying, that's not possible, right, since they are coming from the same server? johnn From eparis at redhat.com Mon Dec 10 17:24:12 2007 From: eparis at redhat.com (Eric Paris) Date: Mon, 10 Dec 2007 12:24:12 -0500 Subject: mounting nfs as httpd_sys_content_t under selinux In-Reply-To: <475D7116.9050604@gmail.com> References: <475AC94B.4090501@gmail.com> <1197297254.18120.33.camel@moss-spartans.epoch.ncsc.mil> <475D7116.9050604@gmail.com> Message-ID: <1197307452.5142.9.camel@localhost.localdomain> On Mon, 2007-12-10 at 12:02 -0500, Johnny Tan wrote: > Stephen Smalley wrote: > > Did you already have a mount from the same server/filesystem when you > > tried doing this? If so, unmount those first and try again - context > > mounts are limited to one per superblock. > > Thanks Stephen & Eric. > > Yes, the problem was I had another mount from the same server. > > So, now both mounts have httpd_sys_content_t context even > though I only put that option on one of them. I do not want > the other mount to have this context. > > Based on what you're saying, that's not possible, right, > since they are coming from the same server? You might get what you want with the nosharecache mount option i mentioned, if adding that to both mounts doesn't help, yeah, you are stuck, sorry. -Eric From sds at tycho.nsa.gov Mon Dec 10 17:31:11 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 10 Dec 2007 12:31:11 -0500 Subject: mounting nfs as httpd_sys_content_t under selinux In-Reply-To: <1197307452.5142.9.camel@localhost.localdomain> References: <475AC94B.4090501@gmail.com> <1197297254.18120.33.camel@moss-spartans.epoch.ncsc.mil> <475D7116.9050604@gmail.com> <1197307452.5142.9.camel@localhost.localdomain> Message-ID: <1197307871.18120.79.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2007-12-10 at 12:24 -0500, Eric Paris wrote: > On Mon, 2007-12-10 at 12:02 -0500, Johnny Tan wrote: > > Stephen Smalley wrote: > > > Did you already have a mount from the same server/filesystem when you > > > tried doing this? If so, unmount those first and try again - context > > > mounts are limited to one per superblock. > > > > Thanks Stephen & Eric. > > > > Yes, the problem was I had another mount from the same server. > > > > So, now both mounts have httpd_sys_content_t context even > > though I only put that option on one of them. I do not want > > the other mount to have this context. > > > > Based on what you're saying, that's not possible, right, > > since they are coming from the same server? Just to clarify: it isn't just that they are coming from the same server but that they are coming from the same server with the same filesystem id. > You might get what you want with the nosharecache mount option i > mentioned, if adding that to both mounts doesn't help, yeah, you are > stuck, sorry. Not that it helps now, but it looks like nfs_compare_mount_options() needs to be made security-aware so that it doesn't try sharing superblocks when there are different security options. -- Stephen Smalley National Security Agency From linuxweb at gmail.com Mon Dec 10 20:05:14 2007 From: linuxweb at gmail.com (Johnny Tan) Date: Mon, 10 Dec 2007 15:05:14 -0500 Subject: mounting nfs as httpd_sys_content_t under selinux In-Reply-To: <1197307871.18120.79.camel@moss-spartans.epoch.ncsc.mil> References: <475AC94B.4090501@gmail.com> <1197297254.18120.33.camel@moss-spartans.epoch.ncsc.mil> <475D7116.9050604@gmail.com> <1197307452.5142.9.camel@localhost.localdomain> <1197307871.18120.79.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <475D9BFA.30807@gmail.com> Stephen Smalley wrote: > Just to clarify: it isn't just that they are coming from the same > server but that they are coming from the same server with the same > filesystem id. Since the remote NFS server is an appliance, I'm pretty sure I won't be able to mount a different filesystem on top or at a different mountpoint in order to prevent this. > On Mon, 2007-12-10 at 12:24 -0500, Eric Paris wrote: >> You might get what you want with the nosharecache mount option i >> mentioned, if adding that to both mounts doesn't help, yeah, you are >> stuck, sorry. I did add this option, but it's hard to tell right now whether it because we are also disallowing from httpd side. I'll have to wait for another downtime to test this. Thanks to both of you for the assistance. johnn From dwalsh at redhat.com Mon Dec 10 20:42:48 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 10 Dec 2007 15:42:48 -0500 Subject: home directory problems with Fedora 8 In-Reply-To: <200712070844.22459.tony.molloy@ul.ie> References: <1196920319.3483.7.camel@w0ep.yipyap.com> <47583629.9090407@gillens.us> <200712070844.22459.tony.molloy@ul.ie> Message-ID: <475DA4C8.7070301@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony Molloy wrote: > On Thursday 06 December 2007 17:49, Matthew Gillen wrote: >> Chris Howard wrote: >>> I have previously existing home directories under /u01/home. >>> I did this because upgrading from FC6 to Fedora 7 caused me trouble >>> and I want to avoid having to recreate my home directory. So I copied >>> the whole system into /u01 before doing a fresh Fedora 8 install. I >>> do not have a separate home-only partition. >>> >>> SELinux prevents me from making a symbolic link like this: >>> >>> /home--> /u01/home or like this >>> >>> /home/chris--> /u01/home/chris. >> I wouldn't do symlinks like that unless you have some strange reason to. >> Just have /etc/passwd point to the actual directories under /u01/home. >> >>> If I setup a dummy user with home at /home/chris, then >>> edit /etc/passwd to change the home to /u01/home/chris... that doesn't >>> work either. >>> >>> nor if I create a new user like so: >>> >>> useradd -d /u01/home/pete pete >>> >>> Is there something magic about the string '/home' ? >>> that keeps me from creating home directories anywhere else? >>> >>> I'd really love to keep from smashing /home on every OS reload. >>> >>> For now I have SELinux in Permissive mode so I can at least use the >>> system. >> Here's how I /think/ it works: >> a) If you've got an empty /u01/home, and you want to add new users, do >> this: Set the type of /u01/home to home_root_t: >> chcon -t home_root_t /u01/home >> and then useradd -d /u01/home/pete will do the right thing. >> >> b) Supposing you already have some use home dirs there (ie the homeidrs in >> /etc/passwd point to /u01/home/*), I think you can just run 'genhomedircon' >> and then run: >> restorcon -R -v /u01/home >> >> In the case of (b), it doesn't hurt to do the chcon operation first, but I >> don't think it's necessary. >> >> (note: I'm not an expert myself, but if these steps don't work for you, >> they should at least point you in the right direction). >> >> HTH, >> Matt >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > I had similar problems after a fresh install of F8 last week messed up > my /users directory. After an off-list discussion with Daniel Walsh he traced > it to a problem in libsemanage and released a new libsemanage to F8-testing > libsemanage-2.0.12-2.fc8. > > Here is a snippet from his e-mail > > There is a bug in libsemanage that is preventing proper labeling. I > have just released libsemanage-2.0.12-2.fc8 to fedora-testing. > > If you install this package, you can execute > > #semodule -B > #restorecon -R -v /users > and it should clean up the labeling. > > You can check what semodule and restorecon do in the man pages. > > Hope this helps, > > Tony > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list There is a bug in libsemanage that is preventing proper labeling of non-default homedirectories. This is in testing right now and should be released to updates soon. I requested the release over the weekend. libsemanage-2.0.12-2.fc8 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHXaTIrlYvE4MpobMRAnRbAKDKBfvgz8Y1kY3wYOlYFYpetWfsJQCfVmxv MCD/S/73YsGH2HnEStQkWKw= =227O -----END PGP SIGNATURE----- From linuxweb at gmail.com Mon Dec 10 21:41:28 2007 From: linuxweb at gmail.com (Johnny Tan) Date: Mon, 10 Dec 2007 16:41:28 -0500 Subject: adding only port 1186 to mysqld connect Message-ID: <475DB288.8080003@gmail.com> I'm doing mysql clustering (aka NDB). It requires a mysqld client to connect to the cluster management node on port 1186. By default, SELinux disallows mysqld from making tcp connections (except to port 3306, I think?, not sure). To allow mysqld to connect to the management node, I ran audit2allow on the denials and got this: allow mysqld_t port_t:tcp_socket name_connect; But this rule seems *too* open. Ideally, I'd like it to only be able to connect on port 1186. Then I tried: semanage port -a -t mysqld_port_t -p tcp 1186 But this didn't work either. I think this just allows mysqld to bind to port 1186. (Or maybe not. Because, even without this rule, it's still able to bind to 1186 on the management nodes. So maybe this means something else.) How would I accomplish adding ONLY port 1186 to what mysqld can do a tcp connect to? p.s. Does this patch: http://www.redhat.com/archives/fedora-extras-commits/2007-November/msg00786.html ... do what I'm trying to accomplish? I see 1186 is added to the mysqld network ports. But either way, since it's a recent commit against Fedora, I'm guessing it will be some time before it gets into RHEL-5. Actaully, do these types of SELinux targeted-policy commits even get backported into RHEL? It's not really a security patch, as such. johnn From sds at tycho.nsa.gov Mon Dec 10 22:01:08 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 10 Dec 2007 17:01:08 -0500 Subject: adding only port 1186 to mysqld connect In-Reply-To: <475DB288.8080003@gmail.com> References: <475DB288.8080003@gmail.com> Message-ID: <1197324068.18120.185.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2007-12-10 at 16:41 -0500, Johnny Tan wrote: > I'm doing mysql clustering (aka NDB). It requires a mysqld > client to connect to the cluster management node on port 1186. > > By default, SELinux disallows mysqld from making tcp > connections (except to port 3306, I think?, not sure). > > To allow mysqld to connect to the management node, I ran > audit2allow on the denials and got this: > allow mysqld_t port_t:tcp_socket name_connect; > > But this rule seems *too* open. Ideally, I'd like it to only > be able to connect on port 1186. > > Then I tried: > semanage port -a -t mysqld_port_t -p tcp 1186 What does semanage port -l | grep 1186 show afterward? What do you mean by "didn't work", i.e. same avc message repeated afterward upon subsequent attempts to connect? The command should cause the port to be treated with that type for all subsequent permission checks, whether name_connect or name_bind. > But this didn't work either. I think this just allows mysqld > to bind to port 1186. (Or maybe not. Because, even without > this rule, it's still able to bind to 1186 on the management > nodes. So maybe this means something else.) > > > How would I accomplish adding ONLY port 1186 to what mysqld > can do a tcp connect to? > > > p.s. Does this patch: > http://www.redhat.com/archives/fedora-extras-commits/2007-November/msg00786.html > > ... do what I'm trying to accomplish? I see 1186 is added to > the mysqld network ports. > > But either way, since it's a recent commit against Fedora, > I'm guessing it will be some time before it gets into > RHEL-5. Actaully, do these types of SELinux targeted-policy > commits even get backported into RHEL? It's not really a > security patch, as such. > > johnn > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- Stephen Smalley National Security Agency From linuxweb at gmail.com Mon Dec 10 22:14:10 2007 From: linuxweb at gmail.com (Johnny Tan) Date: Mon, 10 Dec 2007 17:14:10 -0500 Subject: adding only port 1186 to mysqld connect In-Reply-To: <1197324068.18120.185.camel@moss-spartans.epoch.ncsc.mil> References: <475DB288.8080003@gmail.com> <1197324068.18120.185.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <475DBA32.9030308@gmail.com> Stephen Smalley wrote: >> Then I tried: >> semanage port -a -t mysqld_port_t -p tcp 1186 > > What does semanage port -l | grep 1186 show afterward? # semanage port -l | grep 1186 mysqld_port_t tcp 1186, 3306 > What do you mean by "didn't work", i.e. same avc message repeated > afterward upon subsequent attempts to connect? type=AVC msg=audit(1197324654.830:1482): avc: denied { name_connect } for pid=20484 comm="mysqld" dest=54859 scontext=root:system_r:mysqld_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket type=SYSCALL msg=audit(1197324654.830:1482): arch=c000003e syscall=42 success=no exit=-13 a0=e a1=1972e194 a2=10 a3=4504aedc items=0 ppid=20385 pid=20484 auid=0 uid=27 gid=27 euid=27 suid=27 fsuid=27 egid=27 sgid=27 fsgid=27 tty=pts1 comm="mysqld" exe="/usr/libexec/mysqld" subj=root:system_r:mysqld_t:s0 key=(null) > The command should cause the port to be treated with that type for all > subsequent permission checks, whether name_connect or name_bind. > >> But this didn't work either. I think this just allows mysqld >> to bind to port 1186. (Or maybe not. Because, even without >> this rule, it's still able to bind to 1186 on the management >> nodes. So maybe this means something else.) >> >> >> How would I accomplish adding ONLY port 1186 to what mysqld >> can do a tcp connect to? >> >> >> p.s. Does this patch: >> http://www.redhat.com/archives/fedora-extras-commits/2007-November/msg00786.html >> >> ... do what I'm trying to accomplish? I see 1186 is added to >> the mysqld network ports. >> >> But either way, since it's a recent commit against Fedora, >> I'm guessing it will be some time before it gets into >> RHEL-5. Actaully, do these types of SELinux targeted-policy >> commits even get backported into RHEL? It's not really a >> security patch, as such. >> >> johnn >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list From sds at tycho.nsa.gov Tue Dec 11 18:30:28 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 11 Dec 2007 13:30:28 -0500 Subject: adding only port 1186 to mysqld connect In-Reply-To: <475DBA32.9030308@gmail.com> References: <475DB288.8080003@gmail.com> <1197324068.18120.185.camel@moss-spartans.epoch.ncsc.mil> <475DBA32.9030308@gmail.com> Message-ID: <1197397828.28006.7.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2007-12-10 at 17:14 -0500, Johnny Tan wrote: > Stephen Smalley wrote: > >> Then I tried: > >> semanage port -a -t mysqld_port_t -p tcp 1186 > > > > What does semanage port -l | grep 1186 show afterward? > > # semanage port -l | grep 1186 > mysqld_port_t tcp 1186, 3306 > > > > What do you mean by "didn't work", i.e. same avc message repeated > > afterward upon subsequent attempts to connect? > > type=AVC msg=audit(1197324654.830:1482): avc: denied { > name_connect } for pid=20484 comm="mysqld" dest=54859 > scontext=root:system_r:mysqld_t:s0 > tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket > type=SYSCALL msg=audit(1197324654.830:1482): arch=c000003e > syscall=42 success=no exit=-13 a0=e a1=1972e194 a2=10 > a3=4504aedc items=0 ppid=20385 pid=20484 auid=0 uid=27 > gid=27 euid=27 suid=27 fsuid=27 egid=27 sgid=27 fsgid=27 > tty=pts1 comm="mysqld" exe="/usr/libexec/mysqld" > subj=root:system_r:mysqld_t:s0 key=(null) Hmm...that's a bug then - that should work, and seems to work for me on Fedora 7. > > The command should cause the port to be treated with that type for all > > subsequent permission checks, whether name_connect or name_bind. > > > >> But this didn't work either. I think this just allows mysqld > >> to bind to port 1186. (Or maybe not. Because, even without > >> this rule, it's still able to bind to 1186 on the management > >> nodes. So maybe this means something else.) > >> > >> > >> How would I accomplish adding ONLY port 1186 to what mysqld > >> can do a tcp connect to? > >> > >> > >> p.s. Does this patch: > >> http://www.redhat.com/archives/fedora-extras-commits/2007-November/msg00786.html > >> > >> ... do what I'm trying to accomplish? I see 1186 is added to > >> the mysqld network ports. > >> > >> But either way, since it's a recent commit against Fedora, > >> I'm guessing it will be some time before it gets into > >> RHEL-5. Actaully, do these types of SELinux targeted-policy > >> commits even get backported into RHEL? It's not really a > >> security patch, as such. > >> > >> johnn > >> > >> -- > >> fedora-selinux-list mailing list > >> fedora-selinux-list at redhat.com > >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- Stephen Smalley National Security Agency From linuxweb at gmail.com Tue Dec 11 19:41:51 2007 From: linuxweb at gmail.com (Johnny Tan) Date: Tue, 11 Dec 2007 14:41:51 -0500 Subject: adding only port 1186 to mysqld connect In-Reply-To: <1197397828.28006.7.camel@moss-spartans.epoch.ncsc.mil> References: <475DB288.8080003@gmail.com> <1197324068.18120.185.camel@moss-spartans.epoch.ncsc.mil> <475DBA32.9030308@gmail.com> <1197397828.28006.7.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <475EE7FF.2060306@gmail.com> Stephen Smalley wrote: > On Mon, 2007-12-10 at 17:14 -0500, Johnny Tan wrote: >> Stephen Smalley wrote: >>>> Then I tried: >>>> semanage port -a -t mysqld_port_t -p tcp 1186 >>> What does semanage port -l | grep 1186 show afterward? >> # semanage port -l | grep 1186 >> mysqld_port_t tcp 1186, 3306 >> >> >>> What do you mean by "didn't work", i.e. same avc message repeated >>> afterward upon subsequent attempts to connect? >> type=AVC msg=audit(1197324654.830:1482): avc: denied { >> name_connect } for pid=20484 comm="mysqld" dest=54859 >> scontext=root:system_r:mysqld_t:s0 >> tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket >> type=SYSCALL msg=audit(1197324654.830:1482): arch=c000003e >> syscall=42 success=no exit=-13 a0=e a1=1972e194 a2=10 >> a3=4504aedc items=0 ppid=20385 pid=20484 auid=0 uid=27 >> gid=27 euid=27 suid=27 fsuid=27 egid=27 sgid=27 fsgid=27 >> tty=pts1 comm="mysqld" exe="/usr/libexec/mysqld" >> subj=root:system_r:mysqld_t:s0 key=(null) > > Hmm...that's a bug then - that should work, and seems to work for me on > Fedora 7. I can file a bugzilla. But do you know if these types of changes get backported into RHEL? They're technically not security exploits so I'm guessing "no". I had previously wrote this... does this fix my issue? >>>> p.s. Does this patch: >>>> http://www.redhat.com/archives/fedora-extras-commits/2007-November/msg00786.html >>>> >>>> ... do what I'm trying to accomplish? I see 1186 is added to >>>> the mysqld network ports. >>>> >>>> But either way, since it's a recent commit against Fedora, >>>> I'm guessing it will be some time before it gets into >>>> RHEL-5. Actaully, do these types of SELinux targeted-policy >>>> commits even get backported into RHEL? It's not really a >>>> security patch, as such. Thanks for your help, Stephen. johnn From sds at tycho.nsa.gov Tue Dec 11 20:27:56 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 11 Dec 2007 15:27:56 -0500 Subject: adding only port 1186 to mysqld connect In-Reply-To: <7e0fb38c0712111157g611d0cf1i4a6eaaa2c36f6e74@mail.gmail.com> References: <475DB288.8080003@gmail.com> <1197324068.18120.185.camel@moss-spartans.epoch.ncsc.mil> <475DBA32.9030308@gmail.com> <1197397828.28006.7.camel@moss-spartans.epoch.ncsc.mil> <475EE7FF.2060306@gmail.com> <7e0fb38c0712111157g611d0cf1i4a6eaaa2c36f6e74@mail.gmail.com> Message-ID: <1197404876.28006.120.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2007-12-11 at 14:57 -0500, Eric Paris wrote: > On 12/11/07, Johnny Tan wrote: > > Stephen Smalley wrote: > > > On Mon, 2007-12-10 at 17:14 -0500, Johnny Tan wrote: > > >> Stephen Smalley wrote: > > >>>> Then I tried: > > >>>> semanage port -a -t mysqld_port_t -p tcp 1186 > > >>> What does semanage port -l | grep 1186 show afterward? > > >> # semanage port -l | grep 1186 > > >> mysqld_port_t tcp 1186, 3306 > > >> > > >> > > >>> What do you mean by "didn't work", i.e. same avc message repeated > > >>> afterward upon subsequent attempts to connect? > > >> type=AVC msg=audit(1197324654.830:1482): avc: denied { > > >> name_connect } for pid=20484 comm="mysqld" dest=54859 > > >> scontext=root:system_r:mysqld_t:s0 > > >> tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket > > >> type=SYSCALL msg=audit(1197324654.830:1482): arch=c000003e > > >> syscall=42 success=no exit=-13 a0=e a1=1972e194 a2=10 > > >> a3=4504aedc items=0 ppid=20385 pid=20484 auid=0 uid=27 > > >> gid=27 euid=27 suid=27 fsuid=27 egid=27 sgid=27 fsgid=27 > > >> tty=pts1 comm="mysqld" exe="/usr/libexec/mysqld" > > >> subj=root:system_r:mysqld_t:s0 key=(null) > > > > > > Hmm...that's a bug then - that should work, and seems to work for me on > > > Fedora 7. > > > > I can file a bugzilla. But do you know if these types of > > changes get backported into RHEL? They're technically not > > security exploits so I'm guessing "no". > > Actually, isn't that AVC saying the port you are connecting to is > 54859, not 1186? Ah, good catch, I missed that. In which case semanage and the kernel are working correctly. I doubt he wants to map that to mysqld_port_t though - since it comes from the local port range. So there's a question - should we be mapping everything in the local port range to a single type for name_connect checking? name_bind doesn't get checked against that range at all since the kernel internally allocates from it. Sounds like a job for secmark to control, but not sure how the port is originally conveyed to mysqld for use. -- Stephen Smalley National Security Agency From linuxweb at gmail.com Tue Dec 11 21:36:53 2007 From: linuxweb at gmail.com (Johnny Tan) Date: Tue, 11 Dec 2007 16:36:53 -0500 Subject: mounting nfs as httpd_sys_content_t under selinux In-Reply-To: <475D9BFA.30807@gmail.com> References: <475AC94B.4090501@gmail.com> <1197297254.18120.33.camel@moss-spartans.epoch.ncsc.mil> <475D7116.9050604@gmail.com> <1197307452.5142.9.camel@localhost.localdomain> <1197307871.18120.79.camel@moss-spartans.epoch.ncsc.mil> <475D9BFA.30807@gmail.com> Message-ID: <475F02F5.1050200@gmail.com> Johnny Tan wrote: >> On Mon, 2007-12-10 at 12:24 -0500, Eric Paris wrote: >>> You might get what you want with the nosharecache mount option i >>> mentioned, if adding that to both mounts doesn't help, yeah, you are >>> stuck, sorry. > > I did add this option, but it's hard to tell right now whether it > because we are also disallowing from httpd side. I'll have to wait for > another downtime to test this. nosharecache seems to have done the trick! "ls -Z" shows the correct context (previously, it showed the same context for both, even though one wasn't mounted with that context). And httpd gets denied in attempts to look at the one that wasn't mounted with the httpd_sys_content_t context. Thanks! johnn From linuxweb at gmail.com Tue Dec 11 21:48:14 2007 From: linuxweb at gmail.com (Johnny Tan) Date: Tue, 11 Dec 2007 16:48:14 -0500 Subject: adding only port 1186 to mysqld connect In-Reply-To: <7e0fb38c0712111157g611d0cf1i4a6eaaa2c36f6e74@mail.gmail.com> References: <475DB288.8080003@gmail.com> <1197324068.18120.185.camel@moss-spartans.epoch.ncsc.mil> <475DBA32.9030308@gmail.com> <1197397828.28006.7.camel@moss-spartans.epoch.ncsc.mil> <475EE7FF.2060306@gmail.com> <7e0fb38c0712111157g611d0cf1i4a6eaaa2c36f6e74@mail.gmail.com> Message-ID: <475F059E.5050905@gmail.com> Eric Paris wrote: > On 12/11/07, Johnny Tan wrote: >> Stephen Smalley wrote: >>> On Mon, 2007-12-10 at 17:14 -0500, Johnny Tan wrote: >>>> Stephen Smalley wrote: >>>>>> Then I tried: >>>>>> semanage port -a -t mysqld_port_t -p tcp 1186 >>>>> What does semanage port -l | grep 1186 show afterward? >>>> # semanage port -l | grep 1186 >>>> mysqld_port_t tcp 1186, 3306 >>>> >>>> >>>>> What do you mean by "didn't work", i.e. same avc message repeated >>>>> afterward upon subsequent attempts to connect? >>>> type=AVC msg=audit(1197324654.830:1482): avc: denied { >>>> name_connect } for pid=20484 comm="mysqld" dest=54859 >>>> scontext=root:system_r:mysqld_t:s0 >>>> tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket >>>> type=SYSCALL msg=audit(1197324654.830:1482): arch=c000003e >>>> syscall=42 success=no exit=-13 a0=e a1=1972e194 a2=10 >>>> a3=4504aedc items=0 ppid=20385 pid=20484 auid=0 uid=27 >>>> gid=27 euid=27 suid=27 fsuid=27 egid=27 sgid=27 fsgid=27 >>>> tty=pts1 comm="mysqld" exe="/usr/libexec/mysqld" >>>> subj=root:system_r:mysqld_t:s0 key=(null) >>> Hmm...that's a bug then - that should work, and seems to work for me on >>> Fedora 7. >> I can file a bugzilla. But do you know if these types of >> changes get backported into RHEL? They're technically not >> security exploits so I'm guessing "no". > > Actually, isn't that AVC saying the port you are connecting to is > 54859, not 1186? You're right. I just saw the name_connect and assumed it was 1186 again. It seems it only connects to the cluster manager on port 1186. Once that's successful (which it now is with the semanage rule above), it then makes a connection to every node in the cluster, using ports in the ephemeral port range. And it's those extra node connect attempts that are being denied. There's one denial for every single cluster node. (I didn't look closely, and thought those were simply multiple denials for the 1186 connect.) So, my two follow-up questions are: 1) Is there a better way to allow mysqld to connect to the cluster nodes besides just allowing mysqld to make any tcp connect? 2) If this is changed to the correct behavior in the future, is this something that Red Hat would backport into existing RHELs, like RHEL-5? johnn From linuxweb at gmail.com Tue Dec 11 22:55:50 2007 From: linuxweb at gmail.com (Johnny Tan) Date: Tue, 11 Dec 2007 17:55:50 -0500 Subject: adding only port 1186 to mysqld connect In-Reply-To: <7e0fb38c0712111411m7cbe02fdqc4d6d4562a6ae7b7@mail.gmail.com> References: <475DB288.8080003@gmail.com> <1197324068.18120.185.camel@moss-spartans.epoch.ncsc.mil> <475DBA32.9030308@gmail.com> <1197397828.28006.7.camel@moss-spartans.epoch.ncsc.mil> <475EE7FF.2060306@gmail.com> <7e0fb38c0712111157g611d0cf1i4a6eaaa2c36f6e74@mail.gmail.com> <475F059E.5050905@gmail.com> <7e0fb38c0712111411m7cbe02fdqc4d6d4562a6ae7b7@mail.gmail.com> Message-ID: <475F1576.1050807@gmail.com> Eric Paris wrote: >> 1) Is there a better way to allow mysqld to connect to the >> cluster nodes besides just allowing mysqld to make any tcp >> connect? > > Maybe. But I don't know. Does name_connect/the socket controls pay > attention to rules set by SECMARK? If not, I don't know how to make > this work. Even if it will pay attention to labeling from SECMARK is > there some sort of iptables matching which would find this? I glanced over the secmark stuff at: http://james-morris.livejournal.com/11010.html Can't say I fully understand it, but right off the bat, I would say if I'm opening the ephemeral ports for mysqld_packet_t (is that right?) via iptables, then the main win for me is that it's not open for all the other ports, in particular, the privileged ports? >> 2) If this is changed to the correct behavior in the future, >> is this something that Red Hat would backport into existing >> RHELs, like RHEL-5? > > Dan might be willing to backport the first port change to RHEL5, I'm > not sure. I'd suggest opening a BZ against the policy. If SECMARK > solves your problem (hopefully while I sleep James will answer that > question) open up a BZ for RHEL5 iptables stating that secmark would > be a serious win for you (and if you have paid support open it there > as well) Assuming you do open the secmark BZ please let me know (off > list if you like) the BZ number. (and most/all of this would only > possibly be backported to RHEL5, not RHEL4) We're moving forward with allowing mysqld to make any tcp connect, just because we have to, for the moment. But I'm willing to continue working on this (I have a spare box I can dedicate to testing this), as it's important to me, and I think it's going to become more common and more important to others using SELinux with NDB (mysql clustering). I'll wait for James's reply first before opening BZ, because it's very possible secmark does what I need. johnn From matthew.thompson at nrl.navy.mil Wed Dec 12 16:55:55 2007 From: matthew.thompson at nrl.navy.mil (Matt Thompson) Date: Wed, 12 Dec 2007 11:55:55 -0500 Subject: FC8: selinux stops cupsd from starting Message-ID: <4760129B.7060303@nrl.navy.mil> I am having a problem with cupsd on my FC8 box. Namely, it only seems to want to start on reboot. If I try to start it later I get: # service cups start Starting cups: /bin/bash: /usr/sbin/cupsd: Permission denied [FAILED] and then audit.log sayeth: type=SELINUX_ERR msg=audit(1197478409.420:673): security_compute_sid: invalid context user_u:system_r:cupsd_t:s0-s0:c0.c1023 for scontext=user_u:system_r:initrc_t:s0 tcontext=system_u:object_r:cupsd_exec_t:s0 tclass=process This seems to be the same bug as in #390391: https://bugzilla.redhat.com/show_bug.cgi?id=390391 but none of the fixes in that seemed to work. More detail can be found at the bug, but I thought I'd ask here in case the answer was well known and my bugzilla-search-fu was lacking. Thanks for any help, Matt Thompson -- Matt Thompson, PhD Naval Research Laboratory 202-767-2160 From petteri.kautonen at pp.inet.fi Thu Dec 13 05:29:58 2007 From: petteri.kautonen at pp.inet.fi (Petteri Kautonen) Date: Thu, 13 Dec 2007 07:29:58 +0200 Subject: SELinux prevents Samba from sharing NTFS mounts. Message-ID: <4760C356.6080708@pp.inet.fi> An HTML attachment was scrubbed... URL: From linuxweb at gmail.com Thu Dec 13 13:20:42 2007 From: linuxweb at gmail.com (Johnny Tan) Date: Thu, 13 Dec 2007 08:20:42 -0500 Subject: SELinux prevents Samba from sharing NTFS mounts. In-Reply-To: <4760C356.6080708@pp.inet.fi> References: <4760C356.6080708@pp.inet.fi> Message-ID: <476131AA.5090009@gmail.com> Petteri Kautonen wrote: > Hi, > I have F8 and every time to I try to access remotely or locally NTFS > filesystems that shared via Samba I get a warning (at the end of this > mesage) from SELinux troubleshooter and can't access the share. > I have tried to mount the filesystem with different context's but none > of them seem to do anything. The shares worked with previous version of > Fedora (F7). I have tried to mount the NTFS volume doing the following > to change it context: > * mount -t ntfs-3g /dev/sda1 /mnt/petteri-c -o > context=system_u:system_r:smbd_t > * mount -t ntfs-3g /dev/sda1 /mnt/petteri-c -o > context=system_u:object_r:smbd_t > * mount -t ntfs-3g /dev/sda1 /mnt/petteri-c -o > fscontext=system_u:object_r:samba_share_t > and various other mount options such as defcontext= and changed the > context=, fscontext=, and defcontext= parameter values. > But the context stays the same (ls --lcontext): > drwxrwxrwx 1 _system_u:object_r:fusefs_t_ root root 12288 > 2007-12-12 21:13 petteri-c I think this might be similar to my httpd/nfs question a couple days ago. Do you have other mounts of /dev/sda1 besides the /mnt/petteri-c? johnn From dsugar at tresys.com Thu Dec 13 13:28:52 2007 From: dsugar at tresys.com (Dave Sugar) Date: Thu, 13 Dec 2007 08:28:52 -0500 Subject: ANN: SELinux Policy IDE (SLIDE) version 1.3 Message-ID: <1197552532.3555.10.camel@localhost.localdomain> Version 1.3 of the SELinux Policy IDE (SLIDE) from Tresys Technology is now available for download from the Tresys Open source website at http://oss.tresys.com. SLIDE is an Eclipse plug-in that integrates with the SELinux Reference Policy to provide a development environment for building SELinux policy. SLIDE Features: * A graphical user interface for policy development, including policy syntax highlighting, context suggestions, and integrated compilation. * Integration with SELinux Reference Policy, including quick lookup and documentation for interfaces and macros. * Wizards and easy to use templates to automate common tasks from creating a new SELinux policy to adding an interface into an existing module. * Integrated remote policy installation and audit log monitoring, to facilitate policy testing. * Integration with SETools to provide many analysis and auditing features. * Seamless integration with the power of standard Eclipse. Version 1.3 highlights: * Graphical interface for editing user and rolemap files. * Modified syntax coloring to include attributes, classes, permissions, roles, type and users. * Integration with SETools 3.3 to include some basic analysis features including TE Rule searching and Domain Transition Analysis. * Integration with audit2allow to provide quick and easy way to convert one or more audit denials into call to interfaces or allow rules. * New 'Open Module' dialog to quickly find and open any module based on name. * Improved documentation on the open source web site. * Updates to work with SETools version 3.3. * Fixed problems with the Console output. * Bugs fixed with undo/redo when toggling commenting on numerous lines of policy. If you would like to contribute, currently the best help would be to test and provide feedback on the SLIDE plugin and SLIDE Remote. Dave Sugar Tresys Technology, LLC From petteri.kautonen at pp.inet.fi Thu Dec 13 14:16:28 2007 From: petteri.kautonen at pp.inet.fi (Petteri Kautonen) Date: Thu, 13 Dec 2007 16:16:28 +0200 Subject: SELinux prevents Samba from sharing NTFS mounts. In-Reply-To: <476131AA.5090009@gmail.com> References: <4760C356.6080708@pp.inet.fi> <476131AA.5090009@gmail.com> Message-ID: <47613EBC.5060807@pp.inet.fi> Johnny Tan wrote: > I think this might be similar to my httpd/nfs question a couple days ago. > > Do you have other mounts of /dev/sda1 besides the /mnt/petteri-c? > > johnn It has been mounted only to /mnt/petteri-c. I joined the list a few days ago, so I haven't been able to see the whole conversation. Perhaps I should check the archives. From jonathan.stott at gmail.com Thu Dec 13 15:51:20 2007 From: jonathan.stott at gmail.com (Jonathan Stott) Date: Thu, 13 Dec 2007 15:51:20 +0000 Subject: Serving Mercurial Repositories Message-ID: <14cf210a0712130751k2cdecf67ib06bba394d3173c5@mail.gmail.com> Hi I'm quite new to Fedora (and SELinux) but I've been using linux for some time and one of the tools I use more or less daily is the mercurial scm. I would like to share (read only) versions of some of the repositories I work on to other members of my group. The mercurial team provide a script to do this which (when configured via a simple file) can read the configured repository directories (scattered about my home directory) and from there generate the web interface. Currently this fails, because I have policies configured such that lighttpd can only read from the public_html directory of home directories and I would prefer not to have to change things so that it can read all of my home directory. I would also prefer to avoid the need to have 2 copies of the repository on the system, one in my home directory and one somewhere else (say /var/hg ) that I can let lighttpd read as it desires, since this brings about synchronisation issues. I thought a solution might be to write a policy for mercurial so that all repos are created with a 'mercurial_repo_t' type or similar and then allow the lighttpd_t context to read them (it can already search home directories) but I am unsure of how to go about implementing such a policy, or how it might be done better. Any advice would be appreciated, Jon From dwalsh at redhat.com Thu Dec 13 21:13:57 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 13 Dec 2007 16:13:57 -0500 Subject: SELinux prevents Samba from sharing NTFS mounts. In-Reply-To: <4760C356.6080708@pp.inet.fi> References: <4760C356.6080708@pp.inet.fi> Message-ID: <4761A095.1030100@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Petteri Kautonen wrote: > Hi, > I have F8 and every time to I try to access remotely or locally NTFS filesystems > that shared via Samba I get a warning (at the end of this mesage) from SELinux > troubleshooter and can't access the share. > I have tried to mount the filesystem with different context's but none of them > seem to do anything. The shares worked with previous version of Fedora (F7). I > have tried to mount the NTFS volume doing the following to change it context: > * mount -t ntfs-3g /dev/sda1 /mnt/petteri-c -o context=system_u:system_r:smbd_t > * mount -t ntfs-3g /dev/sda1 /mnt/petteri-c -o context=system_u:object_r:smbd_t > * mount -t ntfs-3g /dev/sda1 /mnt/petteri-c -o > fscontext=system_u:object_r:samba_share_t > and various other mount options such as defcontext= and changed the context=, > fscontext=, and defcontext= parameter values. > But the context stays the same (ls --lcontext): > drwxrwxrwx 1 _system_u:object_r:fusefs_t_ root root 12288 2007-12-12 > 21:13 petteri-c > > So how I am going tho get SELinux to allow Samba to share mounted NTFS > filesystem? (Sorry about the newbie question :( and possibly bad english). > SELinux is enforcing/targetted and all the booleans that refer to smbd are > checked allow from SELinux Administration. > > /Summary > SELinux is preventing samba (smbd) "read" to (fusefs_t). > > Detailed Description > SELinux denied samba access to . If you want to share this > directory with samba it has to have a file context label of samba_share_t. > If you did not intend to use as a samba repository it could > indicate either a bug or it could signal a intrusion attempt. > > Allowing Access > You can alter the file context by executing chcon -R -t samba_share_t > You must also change the default file context files on the system > in order to preserve them even on a full relabel. "semanage fcontext -a -t > samba_share_t " > > The following command will allow this access: > chcon -R -t samba_share_t > > Additional Information > > Source Context system_u:system_r:smbd_t > Target Context system_u:object_r:fusefs_t > Target Objects None [ dir ] > Affected RPM Packages > Policy RPM selinux-policy-3.0.8-64.fc8 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name plugins.samba_share > Host Name petteri > Platform Linux petteri 2.6.23.8-63.fc8 #1 SMP Wed Nov 21 > 18:51:08 EST 2007 i686 athlon > Alert Count 126 > First Seen ke 14. marraskuuta 2007 15:57:05 > Last Seen to 13. joulukuuta 2007 07:13:17 > Local ID 2f2fd1b5-757e-4b37-a44f-eb76e86a81c2 > Line Numbers > > Raw Audit Messages > > avc: denied { read } for comm=smbd dev=sda1 name=/ pid=21782 > scontext=system_u:system_r:smbd_t:s0 tclass=dir > tcontext=system_u:object_r:fusefs_t:s0 > > > / > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list You should mount them as samba_share_t mount -t ntfs-3g /dev/sda1 /mnt/petteri-c -o context=system_u:system_r:samba_share_t -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHYaCVrlYvE4MpobMRAlNtAJ9UfV6sOAhND/uks/42NURRaAvoYgCgkKln J1bCcg2QLpKUv+Ao1dxq+eU= =dbrj -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Dec 13 21:16:56 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 13 Dec 2007 16:16:56 -0500 Subject: Serving Mercurial Repositories In-Reply-To: <14cf210a0712130751k2cdecf67ib06bba394d3173c5@mail.gmail.com> References: <14cf210a0712130751k2cdecf67ib06bba394d3173c5@mail.gmail.com> Message-ID: <4761A148.3010500@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonathan Stott wrote: > Hi > > I'm quite new to Fedora (and SELinux) but I've been using linux for > some time and one of the tools I use more or less daily is the > mercurial scm. I would like to share (read only) versions of some of > the repositories I work on to other members of my group. The > mercurial team provide a script to do this which (when configured via > a simple file) can read the configured repository directories > (scattered about my home directory) and from there generate the web > interface. > > Currently this fails, because I have policies configured such that > lighttpd can only read from the public_html directory of home > directories and I would prefer not to have to change things so that it > can read all of my home directory. I would also prefer to avoid the > need to have 2 copies of the repository on the system, one in my home > directory and one somewhere else (say /var/hg ) that I can let > lighttpd read as it desires, since this brings about synchronisation > issues. > > I thought a solution might be to write a policy for mercurial so that > all repos are created with a 'mercurial_repo_t' type or similar and > then allow the lighttpd_t context to read them (it can already search > home directories) but I am unsure of how to go about implementing such > a policy, or how it might be done better. > > Any advice would be appreciated, > Jon > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Why not just label the directory where you want mercurial to be shared http_*_content_t Just like public_html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHYaFIrlYvE4MpobMRAijtAKCv6FARdJfSOTgCT7uAXtD+scKoGgCfZmYP bmVBokULiPWedRovwCocpOM= =NVAD -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Dec 13 21:18:31 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 13 Dec 2007 16:18:31 -0500 Subject: FC8: selinux stops cupsd from starting In-Reply-To: <4760129B.7060303@nrl.navy.mil> References: <4760129B.7060303@nrl.navy.mil> Message-ID: <4761A1A7.9040203@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Thompson wrote: > I am having a problem with cupsd on my FC8 box. Namely, it only seems > to want to start on reboot. If I try to start it later I get: > > # service cups start > Starting cups: /bin/bash: /usr/sbin/cupsd: Permission denied > [FAILED] > > and then audit.log sayeth: > type=SELINUX_ERR msg=audit(1197478409.420:673): security_compute_sid: > invalid context user_u:system_r:cupsd_t:s0-s0:c0.c1023 for > scontext=user_u:system_r:initrc_t:s0 > tcontext=system_u:object_r:cupsd_exec_t:s0 tclass=process > > This seems to be the same bug as in #390391: > https://bugzilla.redhat.com/show_bug.cgi?id=390391 > > but none of the fixes in that seemed to work. > > More detail can be found at the bug, but I thought I'd ask here in case > the answer was well known and my bugzilla-search-fu was lacking. > > Thanks for any help, > Matt Thompson > That bug was resolved. Policy 68 should correct the default file context for the administrator, which will allow them to start and stop the service. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHYaGmrlYvE4MpobMRAspSAKCEQpSDZIuKukX0zkbQXmzNup6eegCffin0 X+VCPNUMtGFDX+QT4nkzwPQ= =tE7v -----END PGP SIGNATURE----- From jonathan.stott at gmail.com Thu Dec 13 22:06:40 2007 From: jonathan.stott at gmail.com (Jonathan Stott) Date: Thu, 13 Dec 2007 22:06:40 +0000 Subject: Serving Mercurial Repositories In-Reply-To: <4761A148.3010500@redhat.com> References: <14cf210a0712130751k2cdecf67ib06bba394d3173c5@mail.gmail.com> <4761A148.3010500@redhat.com> Message-ID: <14cf210a0712131406k6553a4e0wc6c7761be9dbb451@mail.gmail.com> ... that would probably work well, yes. And would also easily work should I switch to Apache (or something else) later. If I am reading the docs correctly once I have set this on the directory, any subsequent files created in there would gain the right label? Regards, Jonathan From petteri.kautonen at pp.inet.fi Fri Dec 14 06:06:19 2007 From: petteri.kautonen at pp.inet.fi (Petteri Kautonen) Date: Fri, 14 Dec 2007 08:06:19 +0200 Subject: SELinux prevents Samba from sharing NTFS mounts. In-Reply-To: <4761A095.1030100@redhat.com> References: <4760C356.6080708@pp.inet.fi> <4761A095.1030100@redhat.com> Message-ID: <47621D5B.5010600@pp.inet.fi> Daniel J Walsh wrote: > You should mount them as samba_share_t > Well, that much I know, but any of the commands don't seem to work... > mount -t ntfs-3g /dev/sda1 /mnt/petteri-c -o > context=system_u:system_r:samba_share_t > ..including this one. It mounts the partition but the context according to 'ls --lcontext' still is system_u:object_r:fusefs_t. From mark at opus11.net Fri Dec 14 15:07:35 2007 From: mark at opus11.net (Mark Knoop) Date: Fri, 14 Dec 2007 15:07:35 +0000 Subject: Python httpd permission denied Message-ID: <47629C37.4070807@opus11.net> I am running a python script as Apache CGI in ~/www/sitename/python/index.py. All was working fine in F7 and F8 until selinux-policy-3.0.8-58 arrived in updates. I've only now had time to look at this and am not sure what the problem might be. Apache error log reads: [error] [client 127.0.0.1] python: can't open file '/home/user/www/sitename/python/index.py': [Errno 13] Permission denied /var/log/messages: setroubleshoot: #012 SELinux is preventing the python from using potentially mislabeled files (user_home_dir_t).#012 For complete SELinux messages. run sealert -l 3506ffc2-aeb9-493c-b2f1-f579479c7ed5 The script is labelled user_u:object_r:httpd_sys_content_t, I've also tried httpd_sys_script_exec_t but get the same error. Labelling as httpd_unconfined_script_exec_t DOES work, as do other (non-CGI) pages. There don't seem to be any changes in the changelogs for -57 and -58 which would affect this... any ideas? * Fri Nov 16 2007 Dan Walsh 3.0.8-58 - Allow nmbd to list inotifyfs_t - Dontaudit consolekit access to user homedir - dontaudit nscd getserv and shmemserv - Allow rsync_t dac overrides - Allow xfs_t to listen to sockets * Fri Nov 16 2007 Dan Walsh 3.0.8-57 - Allow lvm to search mnt - Add booleans for xguest account xguest_mount_media xguest_connect_network xguest_use_bluetooth -- Mark Knoop From rdieter at math.unl.edu Fri Dec 14 14:56:51 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 14 Dec 2007 08:56:51 -0600 Subject: kde4/selinux love Message-ID: kde4 could use some serious selinux attention/love, looking for help/volunteers. First off, any help to address: "Selinux is preventing kdm to login a user" http://bugzilla.redhat.com/421951 would be greatly appreciated. What's worse, (I could be wrong, have only tested it now 3 times), is that a kde4 desktop/login isn't functional even with enforcing=0, but selinux=0 is required. eek. -- Rex From dant at cdkkt.com Fri Dec 14 15:17:04 2007 From: dant at cdkkt.com (Daniel B. Thurman) Date: Fri, 14 Dec 2007 07:17:04 -0800 Subject: [F8] setroubleshoot running at 85-95% of CPU Message-ID: <021126B987E43D44A860139823C079110E2C14@orion.cdkkt.com> This thread was originally posted at fedora-list, but other posters recommended that I repost this thread here in this list, although cleaned up. For awhile, it seemed that I was getting regular sealert warnings (the "star" in notification taskbar) but now I no longer receive it. I noticed that setroubleshoot was running at 85-95% of CPU load so I killed it along with sealert processes and that brought the CPU load WAY down. I have removed the setroubleshoot packages and re-installed it. It did not remove the problem. At this point, I have disabled the setroubleshootd service and my CPU is now quiet. What can I do to fix or analyze this problem? No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.17.1/1183 - Release Date: 12/13/2007 9:15 AM From mc-al34luc at sbcglobal.net Fri Dec 14 16:48:12 2007 From: mc-al34luc at sbcglobal.net (Mike Carney) Date: Fri, 14 Dec 2007 08:48:12 -0800 Subject: F7: update of selinux policy to 61 breaks cups printing Message-ID: type=AVC msg=audit(1197649819.259:300): avc: denied { getattr } for pid=22338 comm="sh" path="/usr/bin/hpijs" dev=sda2 ino=225020 scontext=user_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file type=SYSCALL msg=audit(1197649819.259:300): arch=40000003 syscall=195 success=no exit=-13 a0=9b4bd48 a1=bfbd9f90 a2=9b3ff4 a3=9b4bd48 items=0 ppid=22335 pid=22338 auid=4868 uid=4 gid=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) comm="sh" exe="/bin/bash" subj=user_u:system_r:cupsd_t:s0-s0:c0.c1023 key=(null) Is there an updated version coming? From jdennis at redhat.com Fri Dec 14 18:38:01 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 14 Dec 2007 13:38:01 -0500 Subject: [F8] setroubleshoot running at 85-95% of CPU In-Reply-To: <021126B987E43D44A860139823C079110E2C14@orion.cdkkt.com> References: <021126B987E43D44A860139823C079110E2C14@orion.cdkkt.com> Message-ID: <4762CD89.7000006@redhat.com> Daniel B. Thurman wrote: > This thread was originally posted at fedora-list, but other > posters recommended that I repost this thread here in this > list, although cleaned up. > > For awhile, it seemed that I was getting regular sealert warnings > (the "star" in notification taskbar) but now I no longer receive it. > > I noticed that setroubleshoot was running at 85-95% of CPU load so > I killed it along with sealert processes and that brought the CPU > load WAY down. > > I have removed the setroubleshoot packages and re-installed it. > It did not remove the problem. > > At this point, I have disabled the setroubleshootd service and my > CPU is now quiet. > > What can I do to fix or analyze this problem? File a bug report for starters. It would really help to get some diagnostic information. To do this edit /etc/setroubleshoot/setroubleshoot.cfg, find the section in the cfg file label setroubleshootd_log, in that section change the value of level to debug and then restart setroubleshootd with /sbin/service setroubleshoot restart After it misbehaves stop the service with /sbin/service setroubleshoot stop Then attach the logfile /var/log/setroubleshoot/setroubleshootd.log to the bug report. Thank you. -- John Dennis From dant at cdkkt.com Fri Dec 14 21:22:31 2007 From: dant at cdkkt.com (Daniel B. Thurman) Date: Fri, 14 Dec 2007 13:22:31 -0800 Subject: [F8] setroubleshoot running at 85-95% of CPU Message-ID: <021126B987E43D44A860139823C079110E2C19@orion.cdkkt.com> John Dennis wrote" >File a bug report for starters. It would really help to get some >diagnostic information. To do this edit >/etc/setroubleshoot/setroubleshoot.cfg, find the section in >the cfg file >label setroubleshootd_log, in that section change the value of >level to >debug and then restart setroubleshootd with > >/sbin/service setroubleshoot restart > >After it misbehaves stop the service with > >/sbin/service setroubleshoot stop > >Then attach the logfile /var/log/setroubleshoot/setroubleshootd.log to >the bug report. Ok, I have set the level = debug, started setroublesootd and tail'ed /var/log/setroubleshootd/*.log for about 15-30 minutes and I see nothing at all. Not a single entry was logged. I tried to bring up the sealert (or Applications->System-Tools-> SELinux Troubleshooter) and I was not able to get/see the gui for this application to even come up. It refuses to display the gui. Any ideas? No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.17.1/1183 - Release Date: 12/13/2007 9:15 AM From jdennis at redhat.com Fri Dec 14 21:44:25 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 14 Dec 2007 16:44:25 -0500 Subject: [F8] setroubleshoot running at 85-95% of CPU In-Reply-To: <021126B987E43D44A860139823C079110E2C19@orion.cdkkt.com> References: <021126B987E43D44A860139823C079110E2C19@orion.cdkkt.com> Message-ID: <4762F939.7000307@redhat.com> Daniel B. Thurman wrote: > Ok, I have set the level = debug, started setroublesootd and tail'ed > /var/log/setroubleshootd/*.log for about 15-30 minutes and I see > nothing at all. Not a single entry was logged. Is it consuming 85-95% of your CPU or not? The log file should not be empty. > I tried to bring up the sealert (or Applications->System-Tools-> > SELinux Troubleshooter) and I was not able to get/see the gui > for this application to even come up. It refuses to display > the gui. > > Any ideas? Stop any running sealert with "sealert -q" Then run it in the foreground with verbose output to the console by doing this: "sealert -s -v" What does it tell you? -- John Dennis From jdennis at redhat.com Fri Dec 14 22:20:15 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 14 Dec 2007 17:20:15 -0500 Subject: [F8] setroubleshoot running at 85-95% of CPU In-Reply-To: <4762F939.7000307@redhat.com> References: <021126B987E43D44A860139823C079110E2C19@orion.cdkkt.com> <4762F939.7000307@redhat.com> Message-ID: <4763019F.5080505@redhat.com> P.S. There may be some confusion unless you understand setroubleshoot is comprised of two processes setroubleshootd is a daemon process run with an init script. sealert is a user process run in your desktop session. There should be one copy of each process running, verify this with "ps ax | grep se" There is no process named setroubleshoot. When you report setroubleshoot is running at 85-95% of CPU I need to know which of the two processes you're referring to. Running tail on /var/log/setroubleshoot/setroubleshootd is not sufficient. I need to see the entire contents of this file. But please don't post it to the list, you can just send it to me directly. -- John Dennis From jkubin at redhat.com Sat Dec 15 00:45:45 2007 From: jkubin at redhat.com (Josef Kubin) Date: Sat, 15 Dec 2007 01:45:45 +0100 Subject: a new tool Message-ID: <476323B9.6070905@redhat.com> Hello, I've just wrote a simple sed script for conversion of audit.log to html counterpart, because the audit.log file over web is really hard to read without highlighting by "avc: denied" substring and corresponding timestamp group. http://people.redhat.com/jkubin/selinux/audit2html $ audit2html < /var/log/audit/audit.log > audit.log.html http://people.redhat.com/jkubin/selinux/audit.log.html http://tinyurl.com/2ek3oe Suggestions and comments are welcomed, thank you for your feedback. Regards, Josef Kubin From craignied at gmail.com Sat Dec 15 23:12:33 2007 From: craignied at gmail.com (Craig Niederberger) Date: Sat, 15 Dec 2007 17:12:33 -0600 Subject: SELinux enforcing, an external ntfs-3g mount, Samba and Fedora 8 Message-ID: <1b006b7b0712151512j1f68eb34g61e4781cb14065a3@mail.gmail.com> Hi Fedora SELinux gurus, question from a very perplexed newbie. I'm trying to access an external ntfs-3g drive from vmware on Fedora, with the drive seen through vmware as a networked samba drive. I have Fedora 8 as the host, VMware Workstation 6.0.2 with Windows XP Pro as the guest OS, and SELinux set to enforcing. I have the host visible as a networked drive in My Network Places on the guest, and can access files in my Fedora 8 home directory, so SELinux is at least allowing that. The external ntfs-3g drive that I'd like to also access is visible in My Network Places on the guest. However, whenever I click on it, I get an SELinux AVC Denial, which says SELinux is preventing the samba daemon from serving r/o local files to remote clients, and tells me that I need to turn on the samba_export_all_ro boolean, which is already on. The raw audit message that I get in the SELinux popup is: avc: denied { read } for comm=smbd dev=sdd1 name=/ pid=4347 scontext=system_u:system_r:smbd_t:s0 tclass=dir tcontext=system_u:object_r:fusefs_t:s0 I have mounted the ntfs-3g drive so that it matches the ownership of my home drive, e.g. the fstab entry is: /dev/sdd1 /mnt/media ntfs-3g rw,locale=en_US.utf8,uid=500,gid=1000 0 0 $ ls -al media total 233 drwxrwxrwx 1 craign family 4096 2007-12-12 23:04 . drwxr-xr-x 6 root root 4096 2007-12-02 14:13 .. drwxrwxrwx 1 craign family 0 2007-09-16 11:31 Craig ... Can anyone help? Many TIA, Craig From jkubin at redhat.com Sun Dec 16 01:10:05 2007 From: jkubin at redhat.com (Josef Kubin) Date: Sun, 16 Dec 2007 02:10:05 +0100 Subject: SELinux enforcing, an external ntfs-3g mount, Samba and Fedora 8 In-Reply-To: <1b006b7b0712151512j1f68eb34g61e4781cb14065a3@mail.gmail.com> References: <1b006b7b0712151512j1f68eb34g61e4781cb14065a3@mail.gmail.com> Message-ID: <47647AED.1050500@redhat.com> Hello Craig, Craig Niederberger wrote: > Hi Fedora SELinux gurus, question from a very perplexed newbie. > > I'm trying to access an external ntfs-3g drive from vmware on Fedora, > with the drive seen through vmware as a networked samba drive. I have > Fedora 8 as the host, VMware Workstation 6.0.2 with Windows XP Pro as > the guest OS, and SELinux set to enforcing. > > I have the host visible as a networked drive in My Network Places on > the guest, and can access files in my Fedora 8 home directory, so > SELinux is at least allowing that. > > The external ntfs-3g drive that I'd like to also access is visible in > My Network Places on the guest. However, whenever I click on it, I get > an SELinux AVC Denial, which says SELinux is preventing the samba > daemon from serving r/o local files to remote clients, and tells me > that I need to turn on the samba_export_all_ro boolean, which is > already on. > > The raw audit message that I get in the SELinux popup is: > avc: denied { read } for comm=smbd dev=sdd1 name=/ pid=4347 > scontext=system_u:system_r:smbd_t:s0 tclass=dir > tcontext=system_u:object_r:fusefs_t:s0 > > I have mounted the ntfs-3g drive so that it matches the ownership of > my home drive, e.g. the fstab entry is: > /dev/sdd1 /mnt/media ntfs-3g rw,locale=en_US.utf8,uid=500,gid=1000 0 0 Did you tried to mount your drive with proper context? /dev/sdd1 /mnt/media ntfs-3g rw,locale=en_US.utf8,uid=500,gid=1000,context=system_u:system_r:samba_share_t 0 0 > $ ls -al media > total 233 > drwxrwxrwx 1 craign family 4096 2007-12-12 23:04 . > drwxr-xr-x 6 root root 4096 2007-12-02 14:13 .. > drwxrwxrwx 1 craign family 0 2007-09-16 11:31 Craig > ... > > Can anyone help? > > Many TIA, > Craig > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Cheers, Josef Kubin From craignied at gmail.com Sun Dec 16 11:16:35 2007 From: craignied at gmail.com (Craig Niederberger) Date: Sun, 16 Dec 2007 05:16:35 -0600 Subject: SELinux enforcing, an external ntfs-3g mount, Samba and Fedora 8 In-Reply-To: <47647AED.1050500@redhat.com> References: <1b006b7b0712151512j1f68eb34g61e4781cb14065a3@mail.gmail.com> <47647AED.1050500@redhat.com> Message-ID: <1b006b7b0712160316x1a4ac215o23a8c2b01311992f@mail.gmail.com> Thanks for answering my post, Josef. Unfortunately, I'm getting exactly the same AVC denial and message when trying to access the drive from vmware. The odd thing is, I can access my home directory from vmware without problem. The /etc/fstab entry now reads: /dev/sdd1 /mnt/media ntfs-3g rw,locale=en_US.utf8,uid=500,gid=1000,context=system_u:system_r:samba_share_t 0 0 Thanks, Craig On Dec 15, 2007 7:10 PM, Josef Kubin wrote: > Hello Craig, > > Craig Niederberger wrote: > > Hi Fedora SELinux gurus, question from a very perplexed newbie. > > > > I'm trying to access an external ntfs-3g drive from vmware on Fedora, > > with the drive seen through vmware as a networked samba drive. I have > > Fedora 8 as the host, VMware Workstation 6.0.2 with Windows XP Pro as > > the guest OS, and SELinux set to enforcing. > > > > I have the host visible as a networked drive in My Network Places on > > the guest, and can access files in my Fedora 8 home directory, so > > SELinux is at least allowing that. > > > > The external ntfs-3g drive that I'd like to also access is visible in > > My Network Places on the guest. However, whenever I click on it, I get > > an SELinux AVC Denial, which says SELinux is preventing the samba > > daemon from serving r/o local files to remote clients, and tells me > > that I need to turn on the samba_export_all_ro boolean, which is > > already on. > > > > The raw audit message that I get in the SELinux popup is: > > avc: denied { read } for comm=smbd dev=sdd1 name=/ pid=4347 > > scontext=system_u:system_r:smbd_t:s0 tclass=dir > > tcontext=system_u:object_r:fusefs_t:s0 > > > > I have mounted the ntfs-3g drive so that it matches the ownership of > > my home drive, e.g. the fstab entry is: > > /dev/sdd1 /mnt/media ntfs-3g rw,locale=en_US.utf8,uid=500,gid=1000 0 0 > > Did you tried to mount your drive with proper context? > > /dev/sdd1 /mnt/media ntfs-3g > rw,locale=en_US.utf8,uid=500,gid=1000,context=system_u:system_r:samba_share_t > 0 0 > > > $ ls -al media > > total 233 > > drwxrwxrwx 1 craign family 4096 2007-12-12 23:04 . > > drwxr-xr-x 6 root root 4096 2007-12-02 14:13 .. > > drwxrwxrwx 1 craign family 0 2007-09-16 11:31 Craig > > ... > > > > Can anyone help? > > > > Many TIA, > > Craig > > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Cheers, > Josef Kubin > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From jkubin at redhat.com Sun Dec 16 17:09:13 2007 From: jkubin at redhat.com (Josef Kubin) Date: Sun, 16 Dec 2007 18:09:13 +0100 Subject: SELinux enforcing, an external ntfs-3g mount, Samba and Fedora 8 In-Reply-To: <1b006b7b0712160316x1a4ac215o23a8c2b01311992f@mail.gmail.com> References: <1b006b7b0712151512j1f68eb34g61e4781cb14065a3@mail.gmail.com> <47647AED.1050500@redhat.com> <1b006b7b0712160316x1a4ac215o23a8c2b01311992f@mail.gmail.com> Message-ID: <47655BB9.9070400@redhat.com> Hi, it looks that you rediscovered a bug ... Craig Niederberger wrote: > Thanks for answering my post, Josef. Unfortunately, I'm getting > exactly the same AVC denial and message when trying to access the > drive from vmware. The odd thing is, I can access my home directory > from vmware without problem. The /etc/fstab entry now reads: > > /dev/sdd1 /mnt/media ntfs-3g > rw,locale=en_US.utf8,uid=500,gid=1000,context=system_u:system_r:samba_share_t > 0 0 I've tried to a little bit investigate things, in this case the forced context is completely ignored ... [root at localhost vmware]# ls -Z /mnt/ drwxr-xr-x root root system_u:object_r:mnt_t:s0 foo [root at localhost vmware]# mount -t ntfs-3g -o loop,offset=32256,context=blabla ntfsImg-flat /mnt/foo/ [root at localhost vmware]# ls -Z /mnt/ drwxrwxrwx root root system_u:object_r:fusefs_t:s0 foo [root at localhost vmware]# umount /mnt/foo/ [root at localhost vmware]# mount -t ntfs-3g -o context=blabla:bleble:blabla,loop,offset=32256 ntfsImg-flat /mnt/foo/ [root at localhost vmware]# ls -Z /mnt/ drwxrwxrwx root root system_u:object_r:fusefs_t:s0 foo ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ But not in this case. [root at localhost vmware]# cat /dev/zero > file [root at localhost vmware]# mkfs.ext3 file ... [root at localhost vmware]# mount -o loop,context=system_u:object_r:httpd_sys_content_t:s0 file /mnt/foo/ [root at localhost vmware]# ls -Z /mnt/ drwxr-xr-x root root system_u:object_r:httpd_sys_content_t:s0 foo Similar bug(s) has been already reported. https://bugzilla.redhat.com/show_bug.cgi?id=216846 Following command should help :-( # setsebool -P samba_run_unconfined 1 Bye. Josef From craignied at gmail.com Sun Dec 16 23:27:20 2007 From: craignied at gmail.com (Craig Niederberger) Date: Sun, 16 Dec 2007 17:27:20 -0600 Subject: SELinux enforcing, an external ntfs-3g mount, Samba and Fedora 8 In-Reply-To: <47655BB9.9070400@redhat.com> References: <1b006b7b0712151512j1f68eb34g61e4781cb14065a3@mail.gmail.com> <47647AED.1050500@redhat.com> <1b006b7b0712160316x1a4ac215o23a8c2b01311992f@mail.gmail.com> <47655BB9.9070400@redhat.com> Message-ID: <1b006b7b0712161527q36b2cd23rcb12795e44edf088@mail.gmail.com> sudo /usr/sbin/setsebool -P samba_run_unconfined 1 Strangely, exactly the same AVC denial. Anything else I can try, short of turning off SELinux, which I'd prefer not to do? Many thanks, Craig On Dec 16, 2007 11:09 AM, Josef Kubin wrote: > Hi, it looks that you rediscovered a bug ... > > Craig Niederberger wrote: > > Thanks for answering my post, Josef. Unfortunately, I'm getting > > exactly the same AVC denial and message when trying to access the > > drive from vmware. The odd thing is, I can access my home directory > > from vmware without problem. The /etc/fstab entry now reads: > > > > /dev/sdd1 /mnt/media ntfs-3g > > rw,locale=en_US.utf8,uid=500,gid=1000,context=system_u:system_r:samba_share_t > > 0 0 > > I've tried to a little bit investigate things, > in this case the forced context is completely ignored ... > > [root at localhost vmware]# ls -Z /mnt/ > drwxr-xr-x root root system_u:object_r:mnt_t:s0 foo > > [root at localhost vmware]# mount -t ntfs-3g -o > loop,offset=32256,context=blabla ntfsImg-flat /mnt/foo/ > > [root at localhost vmware]# ls -Z /mnt/ > drwxrwxrwx root root system_u:object_r:fusefs_t:s0 foo > > [root at localhost vmware]# umount /mnt/foo/ > > [root at localhost vmware]# mount -t ntfs-3g -o > context=blabla:bleble:blabla,loop,offset=32256 ntfsImg-flat /mnt/foo/ > > [root at localhost vmware]# ls -Z /mnt/ > drwxrwxrwx root root system_u:object_r:fusefs_t:s0 foo > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > But not in this case. > > [root at localhost vmware]# cat /dev/zero > file > [root at localhost vmware]# mkfs.ext3 file > ... > [root at localhost vmware]# mount -o > loop,context=system_u:object_r:httpd_sys_content_t:s0 file /mnt/foo/ > > [root at localhost vmware]# ls -Z /mnt/ > drwxr-xr-x root root system_u:object_r:httpd_sys_content_t:s0 foo > > Similar bug(s) has been already reported. > https://bugzilla.redhat.com/show_bug.cgi?id=216846 > > > Following command should help :-( > > # setsebool -P samba_run_unconfined 1 > > Bye. > Josef > > > From chrisdanezis at gmail.com Mon Dec 17 09:37:50 2007 From: chrisdanezis at gmail.com (Chris Danezis) Date: Mon, 17 Dec 2007 11:37:50 +0200 Subject: SELinux enforcing, an external ntfs-3g mount, Samba and Fedora 8 In-Reply-To: <1b006b7b0712161527q36b2cd23rcb12795e44edf088@mail.gmail.com> References: <1b006b7b0712151512j1f68eb34g61e4781cb14065a3@mail.gmail.com> <47647AED.1050500@redhat.com> <1b006b7b0712160316x1a4ac215o23a8c2b01311992f@mail.gmail.com> <47655BB9.9070400@redhat.com> <1b006b7b0712161527q36b2cd23rcb12795e44edf088@mail.gmail.com> Message-ID: <13ffefea0712170137scea7140w3bf0e48c59883dc1@mail.gmail.com> I am facing the exact same issues, not only when dealing with ntfs-3g drives, but with my RAID hard drive and my external drive also (both mounted as vfat). I went through all the aforementioned steps and I still haven't managed to resolve the issue. On Dec 17, 2007 1:27 AM, Craig Niederberger wrote: > sudo /usr/sbin/setsebool -P samba_run_unconfined 1 > > Strangely, exactly the same AVC denial. Anything else I can try, > short of turning off SELinux, which I'd prefer not to do? > > Many thanks, > Craig > > On Dec 16, 2007 11:09 AM, Josef Kubin wrote: > > Hi, it looks that you rediscovered a bug ... > > > > Craig Niederberger wrote: > > > Thanks for answering my post, Josef. Unfortunately, I'm getting > > > exactly the same AVC denial and message when trying to access the > > > drive from vmware. The odd thing is, I can access my home directory > > > from vmware without problem. The /etc/fstab entry now reads: > > > > > > /dev/sdd1 /mnt/media ntfs-3g > > > > rw,locale=en_US.utf8,uid=500,gid=1000,context=system_u:system_r:samba_share_t > > > 0 0 > > > > I've tried to a little bit investigate things, > > in this case the forced context is completely ignored ... > > > > [root at localhost vmware]# ls -Z /mnt/ > > drwxr-xr-x root root system_u:object_r:mnt_t:s0 foo > > > > [root at localhost vmware]# mount -t ntfs-3g -o > > loop,offset=32256,context=blabla ntfsImg-flat /mnt/foo/ > > > > [root at localhost vmware]# ls -Z /mnt/ > > drwxrwxrwx root root system_u:object_r:fusefs_t:s0 foo > > > > [root at localhost vmware]# umount /mnt/foo/ > > > > [root at localhost vmware]# mount -t ntfs-3g -o > > context=blabla:bleble:blabla,loop,offset=32256 ntfsImg-flat /mnt/foo/ > > > > [root at localhost vmware]# ls -Z /mnt/ > > drwxrwxrwx root root system_u:object_r:fusefs_t:s0 foo > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > But not in this case. > > > > [root at localhost vmware]# cat /dev/zero > file > > [root at localhost vmware]# mkfs.ext3 file > > ... > > [root at localhost vmware]# mount -o > > loop,context=system_u:object_r:httpd_sys_content_t:s0 file /mnt/foo/ > > > > [root at localhost vmware]# ls -Z /mnt/ > > drwxr-xr-x root root system_u:object_r:httpd_sys_content_t:s0 foo > > > > Similar bug(s) has been already reported. > > https://bugzilla.redhat.com/show_bug.cgi?id=216846 > > > > > > Following command should help :-( > > > > # setsebool -P samba_run_unconfined 1 > > > > Bye. > > Josef > > > > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmorris at namei.org Mon Dec 17 14:05:30 2007 From: jmorris at namei.org (James Morris) Date: Tue, 18 Dec 2007 01:05:30 +1100 (EST) Subject: OLS CfP Message-ID: The OLS CfP is open: http://www.linuxsymposium.org/2008/cfp.php I think it would be great if we could get some SELinux tutorials/talks/BoFs happening with a focus on usability and recent advances. One of the problems we face now is that people have had bad experiences with earlier versions of SELinux, and understandably not then closely followed subsequent developments. e.g. - tutorial ideas: - "Developing SELinux policy with SLIDE" - "How to manage SELinux servers" (with modern techniques) - "Using xguest: kiosks, consumer electronics, ..." - A BoF session for various distro integration efforts might be useful, as there seems to be more happening again outside of Fedora/RH, and I'm sure there are things we can all help each other with, wishlists for upstream etc. The CfP closes on Feb 1st 2008. - James -- James Morris From mjc at avtechpulse.com Mon Dec 17 14:13:27 2007 From: mjc at avtechpulse.com (Dr. Michael J. Chudobiak) Date: Mon, 17 Dec 2007 09:13:27 -0500 Subject: gdm + selinux problem In-Reply-To: <47542302.9080908@redhat.com> References: <4746DA92.2000204@avtechpulse.com> <47542302.9080908@redhat.com> Message-ID: <47668407.9010903@avtechpulse.com> >> #============= xdm_t ============== >> allow xdm_t initrc_tmp_t:dir { getattr setattr }; >> >> #============= xdm_xserver_t ============== >> allow xdm_xserver_t initrc_tmp_t:dir { write getattr search add_name }; >> allow xdm_xserver_t initrc_tmp_t:sock_file create; >> >> Now... how would this have happened? Should I just run the above >> commands to fix everything, or is there a deeper bug / issue? >> > Looks like you might have some labeliing problems, but first update to > the latest version of selinux-policy > > yum -y upgrade selinux-policy > > > And see if most of these have been fixed. Daniel, After updating another machine (F7 -> F8), I still get gdm failures due to selinux, as originally reported. The problem has not be fixed by recent rpms. See below: [root at titus log]# rpm -qa | grep selinux libselinux-python-2.0.43-1.fc8 selinux-policy-devel-3.0.8-64.fc8 libselinux-devel-2.0.43-1.fc8 selinux-policy-3.0.8-64.fc8 selinux-policy-targeted-3.0.8-64.fc8 libselinux-2.0.43-1.fc8 [root at titus log]# ps ax | grep gdm 2264 ? Ss 0:00 /usr/sbin/gdm-binary -nodaemon 2355 ? Ss 0:00 /bin/sh /etc/gdm/XKeepsCrashing 2372 ? S 0:00 /usr/libexec/gdmopen -l /bin/sh -c /etc/gdm/XKeepsCrashing -noopen 2373 tty7 Ss+ 0:00 /bin/sh /etc/gdm/XKeepsCrashing -noopen 2779 pts/0 S+ 0:00 grep gdm [root at titus log]# audit2allow -i messages ...snip... #============= xdm_t ============== allow xdm_t default_t:file write; allow xdm_t initrc_tmp_t:dir { getattr search setattr }; #============= xdm_xserver_t ============== allow xdm_xserver_t initrc_tmp_t:dir { write remove_name getattr search add_name }; allow xdm_xserver_t initrc_tmp_t:sock_file { create unlink }; Disabling selinux lets gdm / xorg run correctly. I tried removing all selinux rpms, rm -rf /etc/selinux, re-installing selinux, and touching /.autorelabel. No better. - Mike From mmaslano at redhat.com Tue Dec 18 10:12:24 2007 From: mmaslano at redhat.com (Marcela Maslanova) Date: Tue, 18 Dec 2007 11:12:24 +0100 Subject: a new tool In-Reply-To: <476323B9.6070905@redhat.com> References: <476323B9.6070905@redhat.com> Message-ID: <47679D08.9040409@redhat.com> That could be really useful in command line. Josef Kubin wrote: > Hello, > > I've just wrote a simple sed script for conversion of audit.log to > html counterpart, because the audit.log file over web is really hard > to read without highlighting by "avc: denied" substring and > corresponding timestamp group. > > http://people.redhat.com/jkubin/selinux/audit2html > > $ audit2html < /var/log/audit/audit.log > audit.log.html > > http://people.redhat.com/jkubin/selinux/audit.log.html > > http://tinyurl.com/2ek3oe > > Suggestions and comments are welcomed, thank you for your feedback. > > Regards, > Josef Kubin > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From olivares14031 at yahoo.com Tue Dec 18 13:41:42 2007 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Tue, 18 Dec 2007 05:41:42 -0800 (PST) Subject: Enforced Selinux prevents booting In-Reply-To: <4c37b6af0712180525g36aebafbv7d4cd5d678701c64@mail.gmail.com> Message-ID: <627752.53788.qm@web52607.mail.re2.yahoo.com> --- Antonio M wrote: > I updated to kernel-2.6.24-0.107.rc5.git3.fc9, > selinux-policy-3.2.4-2.fc9 and related packages. > > I switched to enforced and I rebooted: I get a > kernel panic, I don't > think it is connected as I get same result with > older kernels. > > Any bug connected or shall we file a new one? (I > didn't find any bug > in my bugzilla query that could play with this > problem..) > > -- > Antonio Montagnani > Skype : antoniomontag > > -- I agree with you here 100%. To login, you have to at least use enforcing=0, otherwise your system will hang. I logged into level 3 and login, and then I see the login again and it cycles recursively if I leave selinux on in enforcing mode. Selinux is misbehaving :( ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From jdennis at redhat.com Tue Dec 18 14:09:13 2007 From: jdennis at redhat.com (John Dennis) Date: Tue, 18 Dec 2007 09:09:13 -0500 Subject: a new tool In-Reply-To: <476323B9.6070905@redhat.com> References: <476323B9.6070905@redhat.com> Message-ID: <4767D489.4070103@redhat.com> Josef Kubin wrote: > Hello, > > I've just wrote a simple sed script for conversion of audit.log to html > counterpart, because the audit.log file over web is really hard to read > without highlighting by "avc: denied" substring and corresponding > timestamp group. > > http://people.redhat.com/jkubin/selinux/audit2html > > $ audit2html < /var/log/audit/audit.log > audit.log.html > > http://people.redhat.com/jkubin/selinux/audit.log.html > > http://tinyurl.com/2ek3oe > > Suggestions and comments are welcomed, thank you for your feedback. Thank you for sharing this Josef, this looks interesting and useful, but I have a couple of questions, at least based on the example you provided. The grouping appears to be wrong. Some items in a group share a common timestamp, others do not and are a mix of other audit events. Events must share a common second, millisecond, and serial number (and host when present). I looked at the sed script to see how this was happening but complex sed syntax is too cryptic to be readable :-( Also, have you considered using the audit parsing library (auparse) for this task? It is designed to make parsing audit data easy and robust (and I dare say more readable and maintainable than sed :-) -- John Dennis From dwalsh at redhat.com Tue Dec 18 19:57:27 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 18 Dec 2007 14:57:27 -0500 Subject: Serving Mercurial Repositories In-Reply-To: <14cf210a0712131406k6553a4e0wc6c7761be9dbb451@mail.gmail.com> References: <14cf210a0712130751k2cdecf67ib06bba394d3173c5@mail.gmail.com> <4761A148.3010500@redhat.com> <14cf210a0712131406k6553a4e0wc6c7761be9dbb451@mail.gmail.com> Message-ID: <47682627.30904@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonathan Stott wrote: > ... that would probably work well, yes. > > And would also easily work should I switch to Apache (or something else) later. > > If I am reading the docs correctly once I have set this on the > directory, any subsequent files created in there would gain the right > label? > > Regards, > Jonathan > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Yes file/dir creations adopt the parent directories context unless their is policy or the program creating the file is selinux aware. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHaCYnrlYvE4MpobMRAscGAJ9gYGhrGZMTpk2OWJjmp07Q9k8g0ACg65th 1EEQCH89+0Sp2Z0ooCzEnj0= =srq4 -----END PGP SIGNATURE----- From Matt_Domsch at dell.com Tue Dec 18 20:09:39 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 18 Dec 2007 14:09:39 -0600 Subject: F7: update of selinux policy to 61 breaks cups printing In-Reply-To: References: Message-ID: <20071218200939.GA18531@auslistsprd01.us.dell.com> On Fri, Dec 14, 2007 at 08:48:12AM -0800, Mike Carney wrote: > > > type=AVC msg=audit(1197649819.259:300): avc: denied { getattr } for > pid=22338 comm="sh" path="/usr/bin/hpijs" dev=sda2 ino=225020 > scontext=user_u:system_r:cupsd_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1197649819.259:300): arch=40000003 syscall=195 > success=no exit=-13 a0=9b4bd48 a1=bfbd9f90 a2=9b3ff4 a3=9b4bd48 items=0 > ppid=22335 pid=22338 auid=4868 uid=4 gid=7 euid=4 suid=4 fsuid=4 egid=7 > sgid=7 fsgid=7 tty=(none) comm="sh" exe="/bin/bash" > subj=user_u:system_r:cupsd_t:s0-s0:c0.c1023 key=(null) > > Is there an updated version coming? I don't usually do this, but: 1) Me too. 2) Mike, is this filed in a bugzilla please? Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From selinux at gmail.com Wed Dec 19 15:59:46 2007 From: selinux at gmail.com (Tom London) Date: Wed, 19 Dec 2007 07:59:46 -0800 Subject: dbus AVCS from rhythmbox? Message-ID: <4c4ba1530712190759h307dcf21y466dbbb223af365d@mail.gmail.com> I have rhythmbox started up in my gnome session. I notice these in /var/log/messages when running in permissive mode: Dec 19 06:16:31 localhost dbus: avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=Hello dest=org.freedesktop.DBus spid=2861 scontext=unconfined_u:unconfined_r:unconfined_execmem_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0 tclass=dbus Dec 19 06:16:31 localhost dbus: avc: denied { acquire_svc } for service=org.gnome.Rhythmbox spid=2861 scontext=unconfined_u:unconfined_r:unconfined_execmem_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0 tclass=dbus or #============= unconfined_execmem_t ============== allow unconfined_execmem_t unconfined_dbusd_t:dbus { acquire_svc send_msg }; That an artifact of running in permissive mode? Or needed? tom -- Tom London From dwalsh at redhat.com Wed Dec 19 21:17:32 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 19 Dec 2007 16:17:32 -0500 Subject: F7: update of selinux policy to 61 breaks cups printing In-Reply-To: <20071218200939.GA18531@auslistsprd01.us.dell.com> References: <20071218200939.GA18531@auslistsprd01.us.dell.com> Message-ID: <47698A6C.104@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Domsch wrote: > On Fri, Dec 14, 2007 at 08:48:12AM -0800, Mike Carney wrote: >> >> type=AVC msg=audit(1197649819.259:300): avc: denied { getattr } for >> pid=22338 comm="sh" path="/usr/bin/hpijs" dev=sda2 ino=225020 >> scontext=user_u:system_r:cupsd_t:s0-s0:c0.c1023 >> tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file >> type=SYSCALL msg=audit(1197649819.259:300): arch=40000003 syscall=195 >> success=no exit=-13 a0=9b4bd48 a1=bfbd9f90 a2=9b3ff4 a3=9b4bd48 items=0 >> ppid=22335 pid=22338 auid=4868 uid=4 gid=7 euid=4 suid=4 fsuid=4 egid=7 >> sgid=7 fsgid=7 tty=(none) comm="sh" exe="/bin/bash" >> subj=user_u:system_r:cupsd_t:s0-s0:c0.c1023 key=(null) >> >> Is there an updated version coming? > > I don't usually do this, but: > > 1) Me too. > > 2) Mike, is this filed in a bugzilla please? > > Thanks, > Matt > 63 should fix. It is in testing. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHaYpsrlYvE4MpobMRAvTzAKCEb6Se/WiZZN0HySOFDdinh4jdNQCeMRfo Ka2gzAO12ieMjB6uIE01qCQ= =P5nh -----END PGP SIGNATURE----- From selinux at gmail.com Thu Dec 20 01:37:28 2007 From: selinux at gmail.com (Tom London) Date: Wed, 19 Dec 2007 17:37:28 -0800 Subject: SELINUX_ERR during update of libgnome Message-ID: <4c4ba1530712191737hb93aba0qa4c02dbbf6ef1567@mail.gmail.com> Running selinux-policy-3.2.4-5.fc9, targeted/enforcing. yum updating libgnome produced: Updating : libgnome ##################### [ 23/198] /var/tmp/rpm-tmp.65437: line 1: /usr/sbin/groupadd: Permission denied The following is in /var/log/audit/audit.log: type=SELINUX_ERR msg=audit(1198114407.394:63): security_compute_sid: invalid context unconfined_u:unconfined_r:groupadd_t:s0 for scontext=unconfined_u:unconfined_r:rpm_script_t:s0 tcontext=system_u:object_r:groupadd_exec_t:s0 tclass=process type=SYSCALL msg=audit(1198114407.394:63): arch=40000003 syscall=11 success=no exit=-13 a0=92e3d38 a1=92e3058 a2=92e2bc8 a3=0 items=0 ppid=26907 pid=26908 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="sh" exe="/bin/bash" subj=unconfined_u:unconfined_r:rpm_script_t:s0 key=(null) type=SELINUX_ERR msg=audit(1198114429.545:64): security_compute_sid: invalid context unconfined_u:unconfined_r:useradd_t:s0 for scontext=unconfined_u:unconfined_r:rpm_script_t:s0 tcontext=system_u:object_r:useradd_exec_t:s0 tclass=process type=SYSCALL msg=audit(1198114429.545:64): arch=40000003 syscall=11 success=no exit=-13 a0=96c8208 a1=96c7ad0 a2=96c6bc8 a3=0 items=0 ppid=26946 pid=26947 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="sh" exe="/bin/bash" subj=unconfined_u:unconfined_r:rpm_script_t:s0 key=(null) tom -- Tom London From selinux at gmail.com Thu Dec 20 01:42:30 2007 From: selinux at gmail.com (Tom London) Date: Wed, 19 Dec 2007 17:42:30 -0800 Subject: SELINUX_ERR during update of libgnome In-Reply-To: <4c4ba1530712191737hb93aba0qa4c02dbbf6ef1567@mail.gmail.com> References: <4c4ba1530712191737hb93aba0qa4c02dbbf6ef1567@mail.gmail.com> Message-ID: <4c4ba1530712191742o68cfa0e8q967db7f0690d05d0@mail.gmail.com> On Dec 19, 2007 5:37 PM, Tom London wrote: > Running selinux-policy-3.2.4-5.fc9, targeted/enforcing. > > yum updating libgnome produced: > > Updating : libgnome ##################### [ 23/198] > /var/tmp/rpm-tmp.65437: line 1: /usr/sbin/groupadd: Permission denied > > The following is in /var/log/audit/audit.log: > > type=SELINUX_ERR msg=audit(1198114407.394:63): security_compute_sid: > invalid context unconfined_u:unconfined_r:groupadd_t:s0 for > scontext=unconfined_u:unconfined_r:rpm_script_t:s0 > tcontext=system_u:object_r:groupadd_exec_t:s0 tclass=process > type=SYSCALL msg=audit(1198114407.394:63): arch=40000003 syscall=11 > success=no exit=-13 a0=92e3d38 a1=92e3058 a2=92e2bc8 a3=0 items=0 > ppid=26907 pid=26908 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 comm="sh" exe="/bin/bash" > subj=unconfined_u:unconfined_r:rpm_script_t:s0 key=(null) > type=SELINUX_ERR msg=audit(1198114429.545:64): security_compute_sid: > invalid context unconfined_u:unconfined_r:useradd_t:s0 for > scontext=unconfined_u:unconfined_r:rpm_script_t:s0 > tcontext=system_u:object_r:useradd_exec_t:s0 tclass=process > type=SYSCALL msg=audit(1198114429.545:64): arch=40000003 syscall=11 > success=no exit=-13 a0=96c8208 a1=96c7ad0 a2=96c6bc8 a3=0 items=0 > ppid=26946 pid=26947 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 comm="sh" exe="/bin/bash" > subj=unconfined_u:unconfined_r:rpm_script_t:s0 key=(null) > Got this too installing kernel package: Installing: kernel ##################### [ 81/198] /sbin/new-kernel-pkg: line 254: /sbin/depmod: Permission denied Updating : gnome-icon-theme ##################### [ 82/198] type=SELINUX_ERR msg=audit(1198114544.945:72): security_compute_sid: invalid context unconfined_u:unconfined_r:useradd_t:s0 for scontext=unconfined_u:unconfined_r:rpm_script_t:s0 tcontext=system_u:object_r:useradd_exec_t:s0 tclass=process type=SYSCALL msg=audit(1198114544.945:72): arch=40000003 syscall=11 success=no exit=-13 a0=9aa73d0 a1=9aa6f50 a2=9aa5e38 a3=0 items=0 ppid=27143 pid=27147 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="sh" exe="/bin/bash" subj=unconfined_u:unconfined_r:rpm_script_t:s0 key=(null) type=SELINUX_ERR msg=audit(1198114778.861:73): security_compute_sid: invalid context unconfined_u:unconfined_r:depmod_t:s0 for scontext=unconfined_u:unconfined_r:rpm_script_t:s0 tcontext=system_u:object_r:depmod_exec_t:s0 tclass=process type=SYSCALL msg=audit(1198114778.861:73): arch=40000003 syscall=11 success=no exit=-13 a0=93c6d40 a1=93b8cd8 a2=93b8e58 a3=0 items=0 ppid=27431 pid=27439 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="new-kernel-pkg" exe="/bin/bash" subj=unconfined_u:unconfined_r:rpm_script_t:s0 key=(null) tom -- Tom London From olivares14031 at yahoo.com Thu Dec 20 01:46:27 2007 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Wed, 19 Dec 2007 17:46:27 -0800 (PST) Subject: sound problems, login works from level 3 no gdm Message-ID: <643867.45856.qm@web52607.mail.re2.yahoo.com> Dear all, Upon booting to newer released kernel [olivares at localhost ~]$ uname -iprm 2.6.24-0.115.rc5.git5.fc9 i686 athlon i386 Sound does not work, I tried to use alsamixer, as of a few updates ago, sound came back :), now it went backwards :(. I typed [olivares at localhost ~]$ alsamixer alsamixer: function snd_ctl_open failed for default: No such device [olivares at localhost ~]$ I then used dmesg and from there I saw the following: audit(1198114515.338:4): avc: denied { search } for pid=1134 comm="salsa" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.339:5): avc: denied { search } for pid=1134 comm="salsa" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.340:6): avc: denied { search } for pid=1131 comm="salsa" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.340:7): avc: denied { search } for pid=1131 comm="salsa" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.341:8): avc: denied { search } for pid=1129 comm="salsa" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.341:9): avc: denied { search } for pid=1129 comm="salsa" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.342:10): avc: denied { search } for pid=1136 comm="salsa" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.342:11): avc: denied { search } for pid=1136 comm="salsa" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.343:12): avc: denied { search } for pid=1140 comm="salsa" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.343:13): avc: denied { search } for pid=1140 comm="salsa" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.394:14): avc: denied { search } for pid=1129 comm="alsactl" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.394:15): avc: denied { search } for pid=1129 comm="alsactl" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.403:16): avc: denied { search } for pid=1131 comm="alsactl" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.403:17): avc: denied { search } for pid=1131 comm="alsactl" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.405:18): avc: denied { search } for pid=1134 comm="alsactl" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.405:19): avc: denied { search } for pid=1134 comm="alsactl" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.411:20): avc: denied { search } for pid=1136 comm="alsactl" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.411:21): avc: denied { search } for pid=1136 comm="alsactl" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.424:22): avc: denied { search } for pid=1140 comm="alsactl" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1198114515.424:23): avc: denied { search } for pid=1140 comm="alsactl" name="nscd" dev=dm-0 ino=3309695 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir EXT3 FS on dm-0, internal journal audit(1198114517.322:24): avc: denied { read } for pid=1177 comm="mount" name="/" dev=usbfs ino=261 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:usbfs_t:s0 tclass=dir audit(1198114517.322:25): avc: denied { read } for pid=1177 comm="mount" name="/" dev=usbfs ino=261 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:usbfs_t:s0 tclass=dir [olivares at localhost ~]$ rpm -qa selinux-* selinux-policy-3.2.4-5.fc9 selinux-policy-targeted-3.2.4-5.fc9 selinux-policy-devel-3.2.4-5.fc9 [olivares at localhost ~]$ GDM still does not work, INIT: error message, but at least login works from level 3 without enforcing=0 starting parameter. Thanks, Antonio ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From selinux at gmail.com Thu Dec 20 14:34:44 2007 From: selinux at gmail.com (Tom London) Date: Thu, 20 Dec 2007 06:34:44 -0800 Subject: SELINUX_ERR during update of libgnome In-Reply-To: <4c4ba1530712191742o68cfa0e8q967db7f0690d05d0@mail.gmail.com> References: <4c4ba1530712191737hb93aba0qa4c02dbbf6ef1567@mail.gmail.com> <4c4ba1530712191742o68cfa0e8q967db7f0690d05d0@mail.gmail.com> Message-ID: <4c4ba1530712200634w4bc2b61fuefa12bcf0ae507ce@mail.gmail.com> More from today's update, this time running permissive: type=SELINUX_ERR msg=audit(1198161003.852:35): security_compute_sid: invalid context unconfined_u:unconfined_r:useradd_t:s0 for scontext=unconfined_u:unconfined_r:rpm_script_t:s0 tcontext=system_u:object_r:useradd_exec_t:s0 tclass=process type=SYSCALL msg=audit(1198161003.852:35): arch=40000003 syscall=11 success=yes exit=0 a0=81c0ee8 a1=81c0248 a2=81bfbc8 a3=0 items=0 ppid=4036 pid=4037 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="useradd" exe="/usr/sbin/useradd" subj=unconfined_u:unconfined_r:useradd_t:s0 key=(null) type=USER_CHAUTHTOK msg=audit(1198161003.958:36): user pid=4037 uid=0 auid=500 subj=unconfined_u:unconfined_r:useradd_t:s0 msg='op=adding user acct=gdm exe="/usr/sbin/useradd" (hostname=?, addr=?, terminal=? res=failed)' type=SELINUX_ERR msg=audit(1198161003.960:37): security_compute_sid: invalid context unconfined_u:unconfined_r:useradd_t:s0 for scontext=unconfined_u:unconfined_r:rpm_script_t:s0 tcontext=system_u:object_r:useradd_exec_t:s0 tclass=process type=SYSCALL msg=audit(1198161003.960:37): arch=40000003 syscall=11 success=yes exit=0 a0=81c0058 a1=81bfda0 a2=81bfe38 a3=0 items=0 ppid=4036 pid=4038 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="usermod" exe="/usr/sbin/usermod" subj=unconfined_u:unconfined_r:useradd_t:s0 key=(null) type=USER_CHAUTHTOK msg=audit(1198161003.993:38): user pid=4038 uid=0 auid=500 subj=unconfined_u:unconfined_r:useradd_t:s0 msg='op=changing user shell acct=gdm exe="/usr/sbin/usermod" (hostname=?, addr=?, terminal=? res=success)' from around here: Updating : gtk2-devel ####################### [19/62] Updating : gdm ####################### [20/62] Updating : ipsec-tools ####################### [21/62] I'd like to understand the issue here. Is the error message saying that a transition to unconfined_u:unconfined_r:useradd_t:s0 from scontext=unconfined_u:unconfined_r:rpm_script_t:s0 hasn't be allowed? tom -- Tom London From sds at tycho.nsa.gov Thu Dec 20 19:38:29 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 20 Dec 2007 14:38:29 -0500 Subject: SELINUX_ERR during update of libgnome In-Reply-To: <4c4ba1530712200634w4bc2b61fuefa12bcf0ae507ce@mail.gmail.com> References: <4c4ba1530712191737hb93aba0qa4c02dbbf6ef1567@mail.gmail.com> <4c4ba1530712191742o68cfa0e8q967db7f0690d05d0@mail.gmail.com> <4c4ba1530712200634w4bc2b61fuefa12bcf0ae507ce@mail.gmail.com> Message-ID: <1198179509.32563.34.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2007-12-20 at 06:34 -0800, Tom London wrote: > More from today's update, this time running permissive: > > type=SELINUX_ERR msg=audit(1198161003.852:35): security_compute_sid: > invalid context unconfined_u:unconfined_r:useradd_t:s0 for > scontext=unconfined_u:unconfined_r:rpm_script_t:s0 > tcontext=system_u:object_r:useradd_exec_t:s0 tclass=process > type=SYSCALL msg=audit(1198161003.852:35): arch=40000003 syscall=11 > success=yes exit=0 a0=81c0ee8 a1=81c0248 a2=81bfbc8 a3=0 items=0 > ppid=4036 pid=4037 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 comm="useradd" exe="/usr/sbin/useradd" > subj=unconfined_u:unconfined_r:useradd_t:s0 key=(null) > type=USER_CHAUTHTOK msg=audit(1198161003.958:36): user pid=4037 uid=0 > auid=500 subj=unconfined_u:unconfined_r:useradd_t:s0 msg='op=adding > user acct=gdm exe="/usr/sbin/useradd" (hostname=?, addr=?, terminal=? > res=failed)' > type=SELINUX_ERR msg=audit(1198161003.960:37): security_compute_sid: > invalid context unconfined_u:unconfined_r:useradd_t:s0 for > scontext=unconfined_u:unconfined_r:rpm_script_t:s0 > tcontext=system_u:object_r:useradd_exec_t:s0 tclass=process > type=SYSCALL msg=audit(1198161003.960:37): arch=40000003 syscall=11 > success=yes exit=0 a0=81c0058 a1=81bfda0 a2=81bfe38 a3=0 items=0 > ppid=4036 pid=4038 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 comm="usermod" exe="/usr/sbin/usermod" > subj=unconfined_u:unconfined_r:useradd_t:s0 key=(null) > type=USER_CHAUTHTOK msg=audit(1198161003.993:38): user pid=4038 uid=0 > auid=500 subj=unconfined_u:unconfined_r:useradd_t:s0 msg='op=changing > user shell acct=gdm exe="/usr/sbin/usermod" (hostname=?, addr=?, > terminal=? res=success)' > > from around here: > Updating : gtk2-devel ####################### [19/62] > Updating : gdm ####################### [20/62] > Updating : ipsec-tools ####################### [21/62] > > > I'd like to understand the issue here. > > Is the error message saying that a transition to > unconfined_u:unconfined_r:useradd_t:s0 from > scontext=unconfined_u:unconfined_r:rpm_script_t:s0 hasn't be allowed? It means that the new context computed by a transition rule (e.g. a type, role, and/or range transition rule) in the policy upon execution of a program is not a valid context, i.e. the user isn't authorized for the role or the role isn't authorized for the type or the user isn't authorized for the range. These kinds of errors were automatically turned into role ... types ...; rules by the old audit2allow, pre-sepolgen. That's a regression in the new audit2allow/sepolgen. -- Stephen Smalley National Security Agency From dant at cdkkt.com Thu Dec 20 20:28:17 2007 From: dant at cdkkt.com (Daniel B. Thurman) Date: Thu, 20 Dec 2007 12:28:17 -0800 Subject: GDM problems: gdm-binary Message-ID: <021126B987E43D44A860139823C079110E2C3B@ns1.cdkkt.com> Due to reasons of my /usr space partition running out of room, I had tar-copied my /usr/share directory into different partition, deleted the contents of /usr/share, changed the fstab to mount the /share partition /usr/share. Because there is a filesystem change, I believed an autorelabel is necessary to ensure that all of the selinux tags are properly labeled. Fortunately, after a reboot, I was able to log into my system, but not without some problems. The following is a list of issues that cropped up during the ordeal: When I rebooted after changing /usr/share: 1. The normal linux textscreen data appears 2. udev 3. A black screen with quick X11 black/white "watch" cursor popped up then it disappeared quickly, like a flash. [NOTE: Here, you would normally see a gnome cursor with a blue spinner then a gui screen showing the progress bar on the loading of services ] 4. Then it switched back into text mode showing (among other things), the last 4 lines: a. Remounting / rw b. Mounting local filesystems c. Doing local filesystem quotas d. Enabling /etc/fstab swap [text-cursor sits waiting] and less than a minute later, (Maybe services are being loaded during this waiting period but you cannot know or see it, can only assume it is or after logging in. Turns out that services are loaded successfully. It is interesting to note that loading of services are VERY QUICK compared to watching the gui screen on service loading progress. Interesting.) 5. The gui login screen pops up. 6. I am able to log in as myself as a normal user. 7. Many sealert messages popped up, most of it showing GDM, sendmail, clamav, spamassassin avc denial errors. 8. After hours trying restorecon in progression: a. /var/run/{clamav-milter,clamd.clamdsvc} directory i. restorecon -vR on these directries did not work, sealerts kept coming ii. Changed directory permissions to 750, owners to [owner]:root Problem solved. sealert stopped. b. SpamAssassin i. After many attempts to fix this, I finally tried: rm -fr ~[users]/.spamassasin directories Problem solved. selalerts stopped for spamassassin. [NOTE: ~[user]/.spamassassin is automatically recreated.] 9. Now, tying to solve gdm-binary problems: a. Remove and reinstall GDM. It fixed a /var/log/messages error entry that showed gdm-binary was segfaulting, but it did not restore the missing services-loading gui screen and there are still problems with gdm-binary and sealerts. b. Grepping for GDM in the /var/log/messages file reveals: + Dec 19 07:42:59 linux setroubleshoot: #012 SELinux is preventing gdm-binary (xdm_t) "signal" to (mono_t).#012 For complete SELinux messages. run sealert -l 966ed3a0-cb89-41cc-8eff-7168d263b538 + Dec 19 07:47:17 linux gdm-binary[2998]: (null): cannot open shared object file: No such file or directory Running: sealert -l 966ed3a0-cb89-41cc-8eff-7168d263b538 ======================================================== Summary SELinux is preventing gdm-binary (xdm_t) "signal" to (mono_t). Detailed Description SELinux denied access requested by gdm-binary. It is not expected that this access is required by gdm-binary 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:xdm_t:s0-s0:c0.c1023 Target Context system_u:system_r:mono_t:s0-s0:c0.c1023 Target Objects None [ process ] Affected RPM Packages Policy RPM selinux-policy-3.0.8-64.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall Host Name linux.cdkkt.com Platform Linux linux.cdkkt.com 2.6.23.8-63.fc8 #1 SMP Wed Nov 21 18:51:08 EST 2007 i686 i686 Alert Count 2 First Seen Wed Dec 19 07:42:32 2007 Last Seen Wed Dec 19 07:42:48 2007 Local ID 966ed3a0-cb89-41cc-8eff-7168d263b538 Line Numbers Raw Audit Messages avc: denied { signal } for comm=gdm-binary pid=3060 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=process tcontext=system_u:system_r:mono_t:s0-s0:c0.c1023 ====================================================== c. I am thinking of removing and reinstalling mono since it seems that mono problems are showing in the above sealert trace? Note: 1. Tar (with --xattrs) and cp -a does not preserve the selinux tags at all. It seems broken. It is possible, but not verified, that maybe the copy-over of some files got corrupted? 2. It seems that autorelabeling does not completely relabel and restore selinux tags faithfully? No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.17.5/1190 - Release Date: 12/19/2007 7:37 PM From dwalsh at redhat.com Fri Dec 21 05:58:23 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 21 Dec 2007 00:58:23 -0500 Subject: SELINUX_ERR during update of libgnome In-Reply-To: <4c4ba1530712200634w4bc2b61fuefa12bcf0ae507ce@mail.gmail.com> References: <4c4ba1530712191737hb93aba0qa4c02dbbf6ef1567@mail.gmail.com> <4c4ba1530712191742o68cfa0e8q967db7f0690d05d0@mail.gmail.com> <4c4ba1530712200634w4bc2b61fuefa12bcf0ae507ce@mail.gmail.com> Message-ID: <476B55FF.60104@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > More from today's update, this time running permissive: > > type=SELINUX_ERR msg=audit(1198161003.852:35): security_compute_sid: > invalid context unconfined_u:unconfined_r:useradd_t:s0 for > scontext=unconfined_u:unconfined_r:rpm_script_t:s0 > tcontext=system_u:object_r:useradd_exec_t:s0 tclass=process > type=SYSCALL msg=audit(1198161003.852:35): arch=40000003 syscall=11 > success=yes exit=0 a0=81c0ee8 a1=81c0248 a2=81bfbc8 a3=0 items=0 > ppid=4036 pid=4037 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 comm="useradd" exe="/usr/sbin/useradd" > subj=unconfined_u:unconfined_r:useradd_t:s0 key=(null) > type=USER_CHAUTHTOK msg=audit(1198161003.958:36): user pid=4037 uid=0 > auid=500 subj=unconfined_u:unconfined_r:useradd_t:s0 msg='op=adding > user acct=gdm exe="/usr/sbin/useradd" (hostname=?, addr=?, terminal=? > res=failed)' > type=SELINUX_ERR msg=audit(1198161003.960:37): security_compute_sid: > invalid context unconfined_u:unconfined_r:useradd_t:s0 for > scontext=unconfined_u:unconfined_r:rpm_script_t:s0 > tcontext=system_u:object_r:useradd_exec_t:s0 tclass=process > type=SYSCALL msg=audit(1198161003.960:37): arch=40000003 syscall=11 > success=yes exit=0 a0=81c0058 a1=81bfda0 a2=81bfe38 a3=0 items=0 > ppid=4036 pid=4038 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 comm="usermod" exe="/usr/sbin/usermod" > subj=unconfined_u:unconfined_r:useradd_t:s0 key=(null) > type=USER_CHAUTHTOK msg=audit(1198161003.993:38): user pid=4038 uid=0 > auid=500 subj=unconfined_u:unconfined_r:useradd_t:s0 msg='op=changing > user shell acct=gdm exe="/usr/sbin/usermod" (hostname=?, addr=?, > terminal=? res=success)' > > from around here: > Updating : gtk2-devel ####################### [19/62] > Updating : gdm ####################### [20/62] > Updating : ipsec-tools ####################### [21/62] > > > I'd like to understand the issue here. > > Is the error message saying that a transition to > unconfined_u:unconfined_r:useradd_t:s0 from > scontext=unconfined_u:unconfined_r:rpm_script_t:s0 hasn't be allowed? > > tom Yes this is saying the unconfined_r:rpm_script_t can not transition to unconfined_r:useradd_t This is an RBAC problem. Tomorrows policy will transtion from unconfined_r to system_r when unconfined_t runs rpm. This should fix the problem. I am fully turning on RBAC and will probably have some hiccups. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHa1X+rlYvE4MpobMRAmqmAJ9frDkWz/m+fK/LrhaQvNSq18HlQgCgo8C1 qTnOhZyX46wY4laQeWDWMyM= =JjwJ -----END PGP SIGNATURE----- From dant at cdkkt.com Fri Dec 21 16:19:26 2007 From: dant at cdkkt.com (Daniel B. Thurman) Date: Fri, 21 Dec 2007 08:19:26 -0800 Subject: GDM problems: gdm-binary Message-ID: <021126B987E43D44A860139823C079110E2C3C@ns1.cdkkt.com> Daniel B. Thurman wrote: > >Due to reasons of my /usr space partition running out of >room, I had tar-copied my /usr/share directory into different >partition, deleted the contents of /usr/share, changed the >fstab to mount the /share partition /usr/share. Because there >is a filesystem change, I believed an autorelabel is necessary >to ensure that all of the selinux tags are properly labeled. > >Fortunately, after a reboot, I was able to log into my system, >but not without some problems. The following is a list of issues >that cropped up during the ordeal: > >When I rebooted after changing /usr/share: > >1. The normal linux textscreen data appears >2. udev >3. A black screen with quick X11 black/white "watch" cursor popped up > then it disappeared quickly, like a flash. > [NOTE: > Here, you would normally see a gnome cursor with a blue spinner > then a gui screen showing the progress bar on the >loading of services > ] >4. Then it switched back into text mode showing (among other things), > the last 4 lines: > a. Remounting / rw > b. Mounting local filesystems > c. Doing local filesystem quotas > d. Enabling /etc/fstab swap > [text-cursor sits waiting] and less than a minute later, > (Maybe services are being loaded during this waiting period > but you cannot know or see it, can only assume it is or after > logging in. Turns out that services are loaded successfully. > It is interesting to note that loading of services are VERY > QUICK compared to watching the gui screen on service loading > progress. Interesting.) >5. The gui login screen pops up. >6. I am able to log in as myself as a normal user. >7. Many sealert messages popped up, most of it showing GDM, sendmail, > clamav, spamassassin avc denial errors. >8. After hours trying restorecon in progression: > a. /var/run/{clamav-milter,clamd.clamdsvc} directory > i. restorecon -vR on these directries did not work, >sealerts kept coming > ii. Changed directory permissions to 750, owners to [owner]:root > Problem solved. sealert stopped. > b. SpamAssassin > i. After many attempts to fix this, I finally tried: > rm -fr ~[users]/.spamassasin directories > Problem solved. selalerts stopped for spamassassin. > [NOTE: ~[user]/.spamassassin is automatically recreated.] >9. Now, tying to solve gdm-binary problems: > a. Remove and reinstall GDM. > It fixed a /var/log/messages error entry that showed >gdm-binary was > segfaulting, but it did not restore the missing >services-loading gui > screen and there are still problems with gdm-binary and sealerts. > > b. Grepping for GDM in the /var/log/messages file reveals: > > + Dec 19 07:42:59 linux setroubleshoot: #012 SELinux is >preventing gdm-binary (xdm_t) "signal" to >(mono_t).#012 For complete SELinux messages. run sealert >-l 966ed3a0-cb89-41cc-8eff-7168d263b538 > + Dec 19 07:47:17 linux gdm-binary[2998]: (null): cannot >open shared object file: No such file or directory > > Running: sealert -l 966ed3a0-cb89-41cc-8eff-7168d263b538 > ======================================================== > Summary > SELinux is preventing gdm-binary (xdm_t) "signal" to > (mono_t). > > Detailed Description > SELinux denied access requested by gdm-binary. It is >not expected that this > access is required by gdm-binary 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:xdm_t:s0-s0:c0.c1023 > Target Context >system_u:system_r:mono_t:s0-s0:c0.c1023 > Target Objects None [ process ] > Affected RPM Packages > Policy RPM selinux-policy-3.0.8-64.fc8 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name plugins.catchall > Host Name linux.cdkkt.com > Platform Linux linux.cdkkt.com >2.6.23.8-63.fc8 #1 SMP Wed > Nov 21 18:51:08 EST 2007 i686 i686 > Alert Count 2 > First Seen Wed Dec 19 07:42:32 2007 > Last Seen Wed Dec 19 07:42:48 2007 > Local ID >966ed3a0-cb89-41cc-8eff-7168d263b538 > Line Numbers > > Raw Audit Messages > > avc: denied { signal } for comm=gdm-binary pid=3060 > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=process > tcontext=system_u:system_r:mono_t:s0-s0:c0.c1023 > ====================================================== > > c. I am thinking of removing and reinstalling mono since it seems > that mono problems are showing in the above sealert trace? > >Note: > 1. Tar (with --xattrs) and cp -a does not preserve the selinux tags > at all. It seems broken. It is possible, but not >verified, that > maybe the copy-over of some files got corrupted? > 2. It seems that autorelabeling does not completely >relabel and restore > selinux tags faithfully? > > I have reinstalled gdm, rhgb, clamav-milter, spamass-milter and I am not able to fix the problems I am trying to solve. I found some more problems with selinux tags and somehow it is not able to label files after a autorelabel which I was hoping it would fix but does not. Can someone please tell me how to fix these problems? >From /var/log/audit log: ============================================================= type=SYSCALL msg=audit(1198252520.322:187): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfc093c0 a2=b7f6d31c a3=0 items=0 ppid=2700 pid=3667 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:sendmail_t:s0 key=(null) type=AVC msg=audit(1198252520.322:187): avc: denied { connectto } for pid=3667 comm="sendmail" path="/var/run/spamass-milter/spamass-milter.sock" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1198252486.805:186): avc: denied { connectto } for pid=3647 comm="sendmail" path="/var/run/spamass-milter/spamass-milter.sock" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket >From /var/log/messages log: (Note that all of these errors are coming from the /usr/share that is mounted from a drive partition while all in / is in its own partition, but /usr/share) ============================================================= Dec 21 07:50:21 linux kernel: audit(1198252191.457:5): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.457:6): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.457:7): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.457:8): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.457:9): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.457:10): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.457:11): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.547:12): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.547:13): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.547:14): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.547:15): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.547:16): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.548:17): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.548:18): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.548:19): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.548:20): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.687:21): avc: denied { search } for pid=1170 comm="ifconfig" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:ifconfig_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.687:22): avc: denied { search } for pid=1170 comm="ifconfig" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:ifconfig_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.687:23): avc: denied { search } for pid=1170 comm="ifconfig" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:ifconfig_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.688:24): avc: denied { search } for pid=1170 comm="ifconfig" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:ifconfig_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.688:25): avc: denied { search } for pid=1170 comm="ifconfig" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:ifconfig_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.688:26): avc: denied { search } for pid=1170 comm="ifconfig" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:ifconfig_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252191.688:27): avc: denied { search } for pid=1170 comm="ifconfig" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:ifconfig_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.653:28): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.931:29): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.939:30): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.939:31): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.939:32): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.939:33): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.959:34): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.959:35): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.959:36): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.959:37): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.959:38): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.959:39): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.959:40): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.959:41): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.960:42): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.960:43): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.961:44): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.961:45): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.961:46): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.961:47): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.961:48): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.962:49): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.962:50): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.962:51): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.962:52): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.962:53): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.962:54): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.964:55): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.964:56): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.990:57): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.990:58): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.990:59): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.990:60): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.990:61): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252193.990:62): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.175:63): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.175:64): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.175:65): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.175:66): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.354:67): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.374:68): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.374:69): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.374:70): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.374:71): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.407:72): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.408:73): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.408:74): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.408:75): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.408:76): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.408:77): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.408:78): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.468:79): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.468:80): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.468:81): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.468:82): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.468:83): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.468:84): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.494:85): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.494:86): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.494:87): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.494:88): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.494:89): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.494:90): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.494:91): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.570:92): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.570:93): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.570:94): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.570:95): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.571:96): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.571:97): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.571:98): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.571:99): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.603:100): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.603:101): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.603:102): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.603:103): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.847:104): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.847:105): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.847:106): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.847:107): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.847:108): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.847:109): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.854:110): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252194.854:111): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.094:112): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.350:113): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.350:114): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.351:115): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.351:116): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.351:117): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.351:118): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.351:119): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.351:120): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.351:121): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.351:122): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.351:123): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.351:124): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.352:125): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.352:126): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.352:127): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.352:128): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.352:129): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.352:130): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.352:131): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.352:132): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.352:133): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.352:134): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.353:135): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.353:136): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.353:137): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.353:138): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.353:139): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:50:21 linux kernel: audit(1198252195.353:140): avc: denied { search } for pid=1179 comm="Xorg" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:xdm_xserver_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Dec 21 07:51:05 linux setroubleshoot: #012 SELinux is preventing /usr/sbin/clamav-milter (clamd_t) "append" to (var_log_t).#012 For complete SELinux messages. run sealert -l 3339843a-b196-4c68-8241-0b8722c2ec40 Dec 21 07:53:11 linux setroubleshoot: #012 SELinux is preventing sendmail (sendmail_t) "connectto" to /var/run/spamass-milter/spamass-milter.sock (initrc_t).#012 For complete SELinux messages. run sealert -l 70f55a23-8d63-4ffe-9d17-1cd63ac4123f No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.6/1192 - Release Date: 12/21/2007 1:17 PM From paul at city-fan.org Fri Dec 21 16:57:14 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 21 Dec 2007 16:57:14 +0000 Subject: GDM problems: gdm-binary In-Reply-To: <021126B987E43D44A860139823C079110E2C3C@ns1.cdkkt.com> References: <021126B987E43D44A860139823C079110E2C3C@ns1.cdkkt.com> Message-ID: <476BF06A.6020806@city-fan.org> Daniel B. Thurman wrote: > Daniel B. Thurman wrote: >> Due to reasons of my /usr space partition running out of >> room, I had tar-copied my /usr/share directory into different >> partition, deleted the contents of /usr/share, changed the >> fstab to mount the /share partition /usr/share. Because there >> is a filesystem change, I believed an autorelabel is necessary >> to ensure that all of the selinux tags are properly labeled. ... > I found some more problems with selinux tags and somehow it > is not able to label files after a autorelabel which I was > hoping it would fix but does not. Can someone please tell > me how to fix these problems? > >>From /var/log/audit log: > ============================================================= > type=SYSCALL msg=audit(1198252520.322:187): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfc093c0 a2=b7f6d31c a3=0 items=0 ppid=2700 pid=3667 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:sendmail_t:s0 key=(null) > type=AVC msg=audit(1198252520.322:187): avc: denied { connectto } for pid=3667 comm="sendmail" path="/var/run/spamass-milter/spamass-milter.sock" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket > type=AVC msg=audit(1198252486.805:186): avc: denied { connectto } for pid=3647 comm="sendmail" path="/var/run/spamass-milter/spamass-milter.sock" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket This looks remarkably like this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=425958 You seem to have the socket labelled as initrc_t rather than spamd_var_run_t, but I don't know why this should happen. Can you post the output of: $ ls -lZd /var/run $ ls -laZ /var/run/spamass-milter $ sestatus -v >From /var/log/messages log: (Note that all of these errors are > coming from the /usr/share that is mounted from a drive partition > while all in / is in its own partition, but /usr/share) > ============================================================= > Dec 21 07:50:21 linux kernel: audit(1198252191.457:5): avc: denied { search } for pid=1169 comm="rhgb" name="share" dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=dir Try unmounting /usr/share, labelling the now-empty directory as mnt_t, remounting /usr/share and labelling the mounted directory as usr_t. Paul. From dant at cdkkt.com Fri Dec 21 17:05:55 2007 From: dant at cdkkt.com (Daniel B. Thurman) Date: Fri, 21 Dec 2007 09:05:55 -0800 Subject: GDM problems: gdm-binary Message-ID: <021126B987E43D44A860139823C079110E2C3D@ns1.cdkkt.com> Paul Howarth wrote: >Daniel B. Thurman wrote: >> Daniel B. Thurman wrote: >>> Due to reasons of my /usr space partition running out of >>> room, I had tar-copied my /usr/share directory into different >>> partition, deleted the contents of /usr/share, changed the >>> fstab to mount the /share partition /usr/share. Because there >>> is a filesystem change, I believed an autorelabel is necessary >>> to ensure that all of the selinux tags are properly labeled. > >... > >> I found some more problems with selinux tags and somehow it >> is not able to label files after a autorelabel which I was >> hoping it would fix but does not. Can someone please tell >> me how to fix these problems? >> >>>From /var/log/audit log: >> ============================================================= >> type=SYSCALL msg=audit(1198252520.322:187): arch=40000003 >syscall=102 success=no exit=-13 a0=3 a1=bfc093c0 a2=b7f6d31c >a3=0 items=0 ppid=2700 pid=3667 auid=4294967295 uid=0 gid=0 >euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) >comm="sendmail" exe="/usr/sbin/sendmail.sendmail" >subj=system_u:system_r:sendmail_t:s0 key=(null) >> type=AVC msg=audit(1198252520.322:187): avc: denied { >connectto } for pid=3667 comm="sendmail" >path="/var/run/spamass-milter/spamass-milter.sock" >scontext=system_u:system_r:sendmail_t:s0 >tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket >> type=AVC msg=audit(1198252486.805:186): avc: denied { >connectto } for pid=3647 comm="sendmail" >path="/var/run/spamass-milter/spamass-milter.sock" >scontext=system_u:system_r:sendmail_t:s0 >tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket > >This looks remarkably like this bug report: >https://bugzilla.redhat.com/show_bug.cgi?id=425958 > >You seem to have the socket labelled as initrc_t rather than >spamd_var_run_t, but I don't know why this should happen. > >Can you post the output of: >$ ls -lZd /var/run drwxr-xr-x root root system_u:object_r:var_run_t:s0 /var/run >$ ls -laZ /var/run/spamass-milter drwxr-x--- sa-milt root system_u:object_r:spamd_var_run_t:s0 . drwxr-xr-x root root system_u:object_r:var_run_t:s0 .. srwxr-xr-x sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0 spamass-milter.sock >$ sestatus -v SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 21 Policy from config file: targeted Process contexts: Current context: unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 Init context: system_u:system_r:init_t:s0 /sbin/mingetty system_u:system_r:getty_t:s0 /usr/sbin/sshd system_u:system_r:sshd_t:s0-s0:c0.c1023 File contexts: Controlling term: unconfined_u:object_r:unconfined_devpts_t:s0 /etc/passwd system_u:object_r:etc_t:s0 /etc/shadow system_u:object_r:shadow_t:s0 /bin/bash system_u:object_r:shell_exec_t:s0 /bin/login system_u:object_r:login_exec_t:s0 /bin/sh system_u:object_r:bin_t:s0 -> system_u:object_r:shell_exec_t:s0 /sbin/agetty system_u:object_r:getty_exec_t:s0 /sbin/init system_u:object_r:init_exec_t:s0 /sbin/mingetty system_u:object_r:getty_exec_t:s0 /usr/sbin/sshd system_u:object_r:sshd_exec_t:s0 /lib/libc.so.6 system_u:object_r:lib_t:s0 -> system_u:object_r:lib_t:s0 /lib/ld-linux.so.2 system_u:object_r:lib_t:s0 -> system_u:object_r:ld_so_t:s0 > >>From /var/log/messages log: (Note that all of these errors are >> coming from the /usr/share that is mounted from a drive partition >> while all in / is in its own partition, but /usr/share) >> ============================================================= >> Dec 21 07:50:21 linux kernel: audit(1198252191.457:5): avc: >denied { search } for pid=1169 comm="rhgb" name="share" >dev=sda2 ino=102929 scontext=system_u:system_r:rhgb_t:s0 >tcontext=user_u:object_r:default_t:s0 tclass=dir > >Try unmounting /usr/share, labelling the now-empty directory as mnt_t, How do I do this, please? >remounting /usr/share and labelling the mounted directory as usr_t. > >Paul. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.6/1192 - Release Date: 12/21/2007 1:17 PM From paul at city-fan.org Fri Dec 21 18:24:27 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 21 Dec 2007 18:24:27 +0000 Subject: GDM problems: gdm-binary In-Reply-To: <021126B987E43D44A860139823C079110E2C3D@ns1.cdkkt.com> References: <021126B987E43D44A860139823C079110E2C3D@ns1.cdkkt.com> Message-ID: <20071221182427.5253b57e@metropolis.intra.city-fan.org> On Fri, 21 Dec 2007 09:05:55 -0800 "Daniel B. Thurman" wrote: > Paul Howarth wrote: > >Daniel B. Thurman wrote: > >> Daniel B. Thurman wrote: > >>> Due to reasons of my /usr space partition running out of > >>> room, I had tar-copied my /usr/share directory into different > >>> partition, deleted the contents of /usr/share, changed the > >>> fstab to mount the /share partition /usr/share. Because there > >>> is a filesystem change, I believed an autorelabel is necessary > >>> to ensure that all of the selinux tags are properly labeled. > > > >... > > > >> I found some more problems with selinux tags and somehow it > >> is not able to label files after a autorelabel which I was > >> hoping it would fix but does not. Can someone please tell > >> me how to fix these problems? > >> > >>>From /var/log/audit log: > >> ============================================================>> > >> type=SYSCALL msg=audit(1198252520.322:187): arch at 000003 > >syscall2 success=no exit=-13 a0=3 a1?c093c0 a2?f6d31c > >a3=0 items=0 ppid'00 pid667 auidB94967295 uid=0 gid=0 > >euid=0 suid=0 fsuid=0 egidQ sgidQ fsgidQ tty=(none) > >comm="sendmail" exe="/usr/sbin/sendmail.sendmail" > >subj=system_u:system_r:sendmail_t:s0 key=(null) > >> type=AVC msg=audit(1198252520.322:187): avc: denied { > >connectto } for pid667 comm="sendmail" > >path="/var/run/spamass-milter/spamass-milter.sock" > >scontext=system_u:system_r:sendmail_t:s0 > >tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket > >> type=AVC msg=audit(1198252486.805:186): avc: denied { > >connectto } for pid647 comm="sendmail" > >path="/var/run/spamass-milter/spamass-milter.sock" > >scontext=system_u:system_r:sendmail_t:s0 > >tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket > > > >This looks remarkably like this bug report: > >https://bugzilla.redhat.com/show_bug.cgi?idB5958 > > > >You seem to have the socket labelled as initrc_t rather than > >spamd_var_run_t, but I don't know why this should happen. > > > >Can you post the output of: > >$ ls -lZd /var/run > > drwxr-xr-x root root system_u:object_r:var_run_t:s0 /var/run > > >$ ls -laZ /var/run/spamass-milter > > drwxr-x--- sa-milt root system_u:object_r:spamd_var_run_t:s0 . > drwxr-xr-x root root system_u:object_r:var_run_t:s0 .. > srwxr-xr-x sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0 > spamass-milter.sock This all looks normal so I guess you're not getting the AVCs from spamass-milter anymore? > >>From /var/log/messages log: (Note that all of these errors are > >> coming from the /usr/share that is mounted from a drive partition > >> while all in / is in its own partition, but /usr/share) > >> ============================================================>> Dec > >> 21 07:50:21 linux kernel: audit(1198252191.457:5): avc: > >denied { search } for pid69 comm="rhgb" name="share" > >dev=sda2 ino2929 scontext=system_u:system_r:rhgb_t:s0 > >tcontext=user_u:object_r:default_t:s0 tclass=dir > > > >Try unmounting /usr/share, labelling the now-empty directory as > >mnt_t, > > How do I do this, please? # umount /usr/share # chcon -t mnt_t /usr/share > >remounting /usr/share and labelling the mounted directory as usr_t. # mount /usr/share # chcon -t usr_t /usr/share Paul. From dant at cdkkt.com Fri Dec 21 19:54:04 2007 From: dant at cdkkt.com (Daniel B. Thurman) Date: Fri, 21 Dec 2007 11:54:04 -0800 Subject: GDM problems: gdm-binary Message-ID: <021126B987E43D44A860139823C079110E2C3F@ns1.cdkkt.com> Paul Howarth wrote: >"Daniel B. Thurman" wrote: >> Paul Howarth wrote: > >This all looks normal so I guess you're not getting the AVCs from >spamass-milter anymore? Rats, I forgot to add that I still get the sealert errors reporting type initrc_t, even though the actual type on the file is spamd_var_run_t Please read the previous post for my detailed report other than the above I forgot to include. Sorry about that! Dan No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.6/1192 - Release Date: 12/21/2007 1:17 PM From dant at cdkkt.com Fri Dec 21 19:55:31 2007 From: dant at cdkkt.com (Daniel B. Thurman) Date: Fri, 21 Dec 2007 11:55:31 -0800 Subject: GDM problems: gdm-binary Message-ID: <021126B987E43D44A860139823C079110E2C40@ns1.cdkkt.com> Paul Howarth wrote: >"Daniel B. Thurman" wrote: > >> Paul Howarth wrote: >> >Daniel B. Thurman wrote: >> >> Daniel B. Thurman wrote: >> >>> Due to reasons of my /usr space partition running out of >> >>> room, I had tar-copied my /usr/share directory into different >> >>> partition, deleted the contents of /usr/share, changed the >> >>> fstab to mount the /share partition /usr/share. Because there >> >>> is a filesystem change, I believed an autorelabel is necessary >> >>> to ensure that all of the selinux tags are properly labeled. >> > >> >... >> > >> >> I found some more problems with selinux tags and somehow it >> >> is not able to label files after a autorelabel which I was >> >> hoping it would fix but does not. Can someone please tell >> >> me how to fix these problems? >> >> >> >>>From /var/log/audit log: >> >> ============================================================>> >> >> type=SYSCALL msg=audit(1198252520.322:187): arch at 000003 >> >syscall2 success=no exit=-13 a0=3 a1?c093c0 a2?f6d31c >> >a3=0 items=0 ppid'00 pid667 auidB94967295 uid=0 gid=0 >> >euid=0 suid=0 fsuid=0 egidQ sgidQ fsgidQ tty=(none) >> >comm="sendmail" exe="/usr/sbin/sendmail.sendmail" >> >subj=system_u:system_r:sendmail_t:s0 key=(null) >> >> type=AVC msg=audit(1198252520.322:187): avc: denied { >> >connectto } for pid667 comm="sendmail" >> >path="/var/run/spamass-milter/spamass-milter.sock" >> >scontext=system_u:system_r:sendmail_t:s0 >> >tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket >> >> type=AVC msg=audit(1198252486.805:186): avc: denied { >> >connectto } for pid647 comm="sendmail" >> >path="/var/run/spamass-milter/spamass-milter.sock" >> >scontext=system_u:system_r:sendmail_t:s0 >> >tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket >> > >> >This looks remarkably like this bug report: >> >https://bugzilla.redhat.com/show_bug.cgi?idB5958 >> > >> >You seem to have the socket labelled as initrc_t rather than >> >spamd_var_run_t, but I don't know why this should happen. >> > >> >Can you post the output of: >> >$ ls -lZd /var/run >> >> drwxr-xr-x root root system_u:object_r:var_run_t:s0 /var/run >> >> >$ ls -laZ /var/run/spamass-milter >> >> drwxr-x--- sa-milt root system_u:object_r:spamd_var_run_t:s0 . >> drwxr-xr-x root root system_u:object_r:var_run_t:s0 .. >> srwxr-xr-x sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0 >> spamass-milter.sock > >This all looks normal so I guess you're not getting the AVCs from >spamass-milter anymore? > >> >>From /var/log/messages log: (Note that all of these errors are >> >> coming from the /usr/share that is mounted from a drive partition >> >> while all in / is in its own partition, but /usr/share) >> >> ============================================================>> Dec >> >> 21 07:50:21 linux kernel: audit(1198252191.457:5): avc: >> >denied { search } for pid69 comm="rhgb" name="share" >> >dev=sda2 ino2929 scontext=system_u:system_r:rhgb_t:s0 >> >tcontext=user_u:object_r:default_t:s0 tclass=dir >> > >> >Try unmounting /usr/share, labelling the now-empty directory as >> >mnt_t, >> >> How do I do this, please? > ># umount /usr/share ># chcon -t mnt_t /usr/share > >> >remounting /usr/share and labelling the mounted directory as usr_t. > ># mount /usr/share ># chcon -t usr_t /usr/share > >Paul. Notes: 1: Just to make sure that I have noted it here, the latest yum updates have been applied. 2: The mounting of LABEL=/share to /usr/share appears as a drive on the desktop, unlike /usr, which does not appear. This is quite annoying. Why is that it appears on the desktop? 1. Have have done what you have asked, above. 2. restorecon -vvR /usr 3. clamav-milter: + was never started at boot. Logs show a permission problem with clamav.log + deleted: /var/log/clamav-milter/clamav.log + service clamav-milter start [perhaps, the problem here is that an existing log file from a previous startup, is no longer accepted and fails on the next reboot unless clamav-milter service is shutdown, the log file is deleted, before rebooting. This has been verified.] 4. spamass-milter: + The spamass-milter.sock orignally when created at reboot shows: srwxr-xr-x sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0 spamass-milter.sock BUT, when restarting spamassassin, it shows a different user context: drwxr-x--- sa-milt root system_u:object_r:spamd_var_run_t:s0 . drwxr-xr-x root root system_u:object_r:var_run_t:s0 .. srwxr-xr-x sa-milt sa-milt unconfined_u:object_r:spamd_var_run_t:s0 spamass-milter.sock ----------------------------^^^^^^^^^^^^ + chcon -u system_u spamass-milter.sock + chcon -t initrc_t spamass-milter.sock 5. I still have unresolved issues with the others: rhgb, xorg, ifconfig, xdm-server Any ideas, anyone? No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.6/1192 - Release Date: 12/21/2007 1:17 PM From olivares14031 at yahoo.com Fri Dec 21 19:57:48 2007 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Fri, 21 Dec 2007 11:57:48 -0800 (PST) Subject: SELinux is preventing /usr/sbin/hald (hald_t) "read" to (system_crond_var_lib_t)., and others Message-ID: <112008.16613.qm@web52608.mail.re2.yahoo.com> Dear all, running rawhide: [olivares at localhost ~]$ uname -a Linux localhost 2.6.24-0.115.rc5.git5.fc9 #1 SMP Tue Dec 18 23:57:17 EST 2007 i686 athlon i386 GNU/Linux [olivares at localhost ~]$ cat /etc/fedora-release Fedora release 8.90 (Rawhide) [olivares at localhost ~]$ After a while of booting with enforcing=0, and now setroubleshoot kicks in, it is reporting lots of havoc, notably the following: Summary SELinux is preventing /usr/sbin/hald (hald_t) "read" to (system_crond_var_lib_t). Detailed Description SELinux denied access requested by /usr/sbin/hald. It is not expected that this access is required by /usr/sbin/hald 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 , restorecon -v 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 unconfined_u:system_r:hald_t Target Context system_u:object_r:system_crond_var_lib_t Target Objects None [ file ] Affected RPM Packages hal-0.5.10-3.fc9 [application] Policy RPM selinux-policy-3.2.5-2.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name localhost Platform Linux localhost 2.6.24-0.115.rc5.git5.fc9 #1 SMP Tue Dec 18 23:57:17 EST 2007 i686 athlon Alert Count 2 First Seen Fri 21 Dec 2007 01:49:40 PM CST Last Seen Fri 21 Dec 2007 01:49:53 PM CST Local ID c4301741-d5e1-42f5-9c6d-0008aeef8586 Line Numbers Raw Audit Messages avc: denied { read } for comm=hald dev=dm-0 egid=0 euid=0 exe=/usr/sbin/hald exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name=PolicyKit.reload pid=30320 scontext=unconfined_u:system_r:hald_t:s0 sgid=0 subj=unconfined_u:system_r:hald_t:s0 suid=0 tclass=file tcontext=system_u:object_r:system_crond_var_lib_t:s0 tty=(none) uid=0 It now makes sense that haldeamon does not run because selinux prevents it from doing so: [root at localhost ~]# service haldaemon status hald is stopped [root at localhost ~]# service haldaemon start Starting HAL daemon: [FAILED] [root at localhost ~]# service haldaemon stop Stopping HAL daemon: [FAILED] [root at localhost ~]# service haldaemon restart Stopping HAL daemon: [FAILED] Starting HAL daemon: [FAILED] [root at localhost ~]# K3b tells me the following: * similar to what Antonio M. also previously told us * No CD/DVD writer found. K3b did not find an optical writing device in your system. Thus, you will not be able to burn CDs or DVDs. However, you can still use other K3b features like audio track extraction or audio transcoding or ISO9660 image creation. I am about to go to the holidays, just reporting an observation. Should I file bugs or has this been taken care of ? Thanks to all for reading this far. I also saw this : Summary SELinux prevented dbus-daemon from using the terminal /dev/tty1. Detailed Description SELinux prevented dbus-daemon from using the terminal /dev/tty1. In most cases daemons do not need to interact with the terminal, usually these avc messages can be ignored. All of the confined daemons should have dontaudit rules around using the terminal. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this selinux- policy. If you would like to allow all daemons to interact with the terminal, you can turn on the allow_daemons_use_tty boolean. Allowing Access Changing the "allow_daemons_use_tty" boolean to true will allow this access: "setsebool -P allow_daemons_use_tty=1." The following command will allow this access: setsebool -P allow_daemons_use_tty=1 Additional Information Source Context unconfined_u:unconfined_r:unconfined_dbusd_t :SystemLow-SystemHigh Target Context unconfined_u:object_r:unconfined_tty_device_t Target Objects /dev/tty1 [ chr_file ] Affected RPM Packages Policy RPM selinux-policy-3.2.5-2.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.allow_daemons_use_tty Host Name localhost Platform Linux localhost 2.6.24-0.115.rc5.git5.fc9 #1 SMP Tue Dec 18 23:57:17 EST 2007 i686 athlon Alert Count 7 First Seen Wed 19 Dec 2007 07:36:11 PM CST Last Seen Fri 21 Dec 2007 01:29:01 PM CST Local ID 66ca0ade-760e-4112-9557-5c46b66b1296 Line Numbers Raw Audit Messages avc: denied { read write } for comm=dbus-daemon dev=tmpfs path=/dev/tty1 pid=28235 scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tclass=chr_file tcontext=unconfined_u:object_r:unconfined_tty_device_t:s0 and this one Summary SELinux is preventing access to files with the label, file_t. Detailed Description SELinux permission checks on files labeled file_t are being denied. file_t is the context the SELinux kernel gives to files that do not have a label. This indicates a serious labeling problem. No files on an SELinux box should ever be labeled file_t. If you have just added a new disk drive to the system you can relabel it using the restorecon command. Otherwise you should relabel the entire files system. Allowing Access You can execute the following command as root to relabel your computer system: "touch /.autorelabel; reboot" Additional Information Source Context system_u:system_r:tmpreaper_t Target Context system_u:object_r:file_t Target Objects /tmp/virtual-olivares.1dNZIJ [ dir ] Affected RPM Packages Policy RPM selinux-policy-3.2.5-2.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.file Host Name localhost Platform Linux localhost 2.6.24-0.115.rc5.git5.fc9 #1 SMP Tue Dec 18 23:57:17 EST 2007 i686 athlon Alert Count 1 First Seen Fri 21 Dec 2007 10:36:45 AM CST Last Seen Fri 21 Dec 2007 10:36:45 AM CST Local ID 59f19014-265b-4a97-96ff-b86653d2fe1d Line Numbers Raw Audit Messages avc: denied { getattr } for comm=tmpwatch dev=dm-0 path=/tmp/virtual- olivares.1dNZIJ pid=14502 scontext=system_u:system_r:tmpreaper_t:s0 tclass=dir tcontext=system_u:object_r:file_t:s0 Happy Holidays -> Merry Christmas and a Happy New Year ! Regards, Antonio ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From jmorris at namei.org Sat Dec 22 08:23:32 2007 From: jmorris at namei.org (James Morris) Date: Sat, 22 Dec 2007 19:23:32 +1100 (EST) Subject: SELinux is preventing /usr/sbin/hald (hald_t) "read" to (system_crond_var_lib_t)., and others In-Reply-To: <112008.16613.qm@web52608.mail.re2.yahoo.com> References: <112008.16613.qm@web52608.mail.re2.yahoo.com> Message-ID: On Fri, 21 Dec 2007, Antonio Olivares wrote: > Dear all, > > running rawhide: > [olivares at localhost ~]$ uname -a > Linux localhost 2.6.24-0.115.rc5.git5.fc9 #1 SMP Tue Dec 18 23:57:17 EST 2007 i686 athlon i386 GNU/Linux > [olivares at localhost ~]$ cat /etc/fedora-release > Fedora release 8.90 (Rawhide) > [olivares at localhost ~]$ It's probably this: https://bugzilla.redhat.com/show_bug.cgi?id=425819 -- James Morris From choeger at cs.tu-berlin.de Thu Dec 27 18:57:33 2007 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Thu, 27 Dec 2007 19:57:33 +0100 Subject: need module advice Message-ID: <1198781853.4234.4.camel@choeger4> Hi, I am writing a selinux module for tomcat5. This is what I currently got: type tomcat5_log_t; logging_log_file(tomcat5_log_t) type tomcat5_tmp_t; files_tmp_file(tomcat5_tmp_t) role system_r types tomcat5_java_t; ######################################## # # local policy # init_daemon_domain(tomcat5_t, tomcat5_exec_t) allow tomcat5_t tomcat5_log_t:file ra_file_perms; manage_files_pattern(tomcat5_t, tomcat5_log_t, tomcat5_log_t) allow tomcat5_t tomcat5_tmp_t:file manage_file_perms; files_tmp_filetrans(tomcat5_t,tomcat5_tmp_t,file) # neccessary for startup files_search_etc(tomcat5_t) files_search_usr(tomcat5_t) libs_search_lib(tomcat5_t) libs_use_shared_libs(tomcat5_t) miscfiles_read_localization(tomcat5_t) libs_use_ld_so(tomcat5_t) kernel_read_system_state(tomcat5_t) corecmd_search_bin(tomcat5_t) corecmd_getattr_bin_files(tomcat5_t) corecmd_exec_bin(tomcat5_t) init_write_utmp(tomcat5_t) files_read_usr_files(tomcat5_t) corecmd_exec_shell(tomcat5_t) rw_fifo_files_pattern(tomcat5_t, tomcat5_t, tomcat5_t) files_read_etc_files(tomcat5_t) logging_search_logs(tomcat5_t) # run java as tomcat5_java_t #java_spec_domtrans(tomcat5_t, tomcat5_java_t) domain_auto_trans(tomcat5_t, java_exec_t, tomcat5_java_t) # privileges for tomcat java applications allow tomcat5_t tomcat5_java_t:process { rlimitinh siginh noatsecure }; allow tomcat5_java_t tomcat5_t:process { sigchld getsched sigkill execheap execmem execstack }; libs_search_lib(tomcat5_java_t) libs_use_shared_libs(tomcat5_java_t) files_search_usr(tomcat5_java_t) files_read_usr_files(tomcat5_java_t) files_search_etc(tomcat5_java_t) files_read_etc_files(tomcat5_java_t) rw_fifo_files_pattern(tomcat5_java_t,tomcat5_t,tomcat5_t) libs_use_ld_so(tomcat5_java_t) write_files_pattern(tomcat5_java_t, tomcat5_log_t, tomcat5_log_t) unconfined_dontaudit_use_terminals(tomcat5_java_t) The idea is to 'sandbox' all java applications run by tomcat5 to avoid damage by exploits in webservices and stuff. The problem is, when I try to start tomcat I got the error that libjli.so is not found, which seems to occur because the environment variable ORIGIN is not resolved (I find a lot of open($ORIGIN/../libjli.so in strace). I have no idea what causes this behavior and I have no audits even with dontaudit disabled. Has anyone any advise please? I'm running really out of ideas here! regards christoph From selinux at gmail.com Fri Dec 28 19:27:58 2007 From: selinux at gmail.com (Tom London) Date: Fri, 28 Dec 2007 11:27:58 -0800 Subject: logrotate_t wants { rename write } to NetworkManager_log_t Message-ID: <4c4ba1530712281127m2968cd11ia81c34aea8fbede4@mail.gmail.com> Running selinux-policy-3.2.5-5.fc9, targeted/enforcing. Been seeing these lately: type=AVC msg=audit(1198863940.082:38): avc: denied { rename } for pid=7287 comm="logrotate" name="wpa_supplicant.log" dev=dm-0 ino=66102 scontext=system_u:system_r:logrotate_t:s0 tcontext=system_u:object_r:NetworkManager_log_t:s0 tclass=file type=SYSCALL msg=audit(1198863940.082:38): arch=40000003 syscall=38 success=no exit=-13 a0=96d01d8 a1=96cdcd0 a2=96d0dc0 a3=96cdcb8 items=0 ppid=7285 pid=7287 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0 key=(null) type=AVC msg=audit(1198863940.082:39): avc: denied { write } for pid=7287 comm="logrotate" name="wpa_supplicant.log" dev=dm-0 ino=66102 scontext=system_u:system_r:logrotate_t:s0 tcontext=system_u:object_r:NetworkManager_log_t:s0 tclass=file type=SYSCALL msg=audit(1198863940.082:39): arch=40000003 syscall=5 success=no exit=-13 a0=96d01d8 a1=8042 a2=180 a3=8042 items=0 ppid=7285 pid=7287 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0 key=(null) tom -- Tom London From flyingboxcutter at yahoo.com Fri Dec 28 21:59:45 2007 From: flyingboxcutter at yahoo.com (Harley Race) Date: Fri, 28 Dec 2007 13:59:45 -0800 (PST) Subject: Sendmail 8.14 selinux Message-ID: <881903.84062.qm@web60216.mail.yahoo.com> Ladies and Gentlemen, If I can get some help here. I am running Fedora 8 with sendmail 8.14.2. I have been getting the following messages in audit.log. I am not really sure what to make of them either. Sendmail runs. Errors are listed below: type=AVC msg=audit(1198878517.713:16): avc: denied { signull } for pid=3153 comm="sendmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:sendmail_t:s0 tclass=process type=SYSCALL msg=audit(1198878517.713:16): arch=40000003 syscall=37 success=no exit=-13 a0=10fd a1=0 a2=b7f3731c a3=84 items=0 ppid=1 pid=3153 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:sendmail_t:s0 key=(null) Sorry about the formatting, this webmail interface does not support elaborate formatting. ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From choeger at cs.tu-berlin.de Mon Dec 31 15:44:48 2007 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 31 Dec 2007 16:44:48 +0100 Subject: Feature request: Tomcat5-Policy Message-ID: <1199115888.3197.1.camel@choeger4> Hi, here is a sample policy for Tomcat5. Could we integrate this (or a reviewed and much better version) into fedora? regards christoph -------------- next part -------------- /usr/bin/tomcat5 -- gen_context(system_u:object_r:tomcat5_exec_t,s0) /usr/bin/dtomcat5 -- gen_context(system_u:object_r:tomcat5_exec_t,s0) /var/log/tomcat5 -d gen_context(system_u:object_r:tomcat5_log_t,s0) /var/log/tomcat5/.* -- gen_context(system_u:object_r:tomcat5_log_t,s0) -------------- next part -------------- policy_module(tomcat5,0.3) ######################################## # # Declarations # type tomcat5_t; type tomcat5_exec_t; type tomcat5_java_t; domain_type(tomcat5_t) domain_type(tomcat5_java_t) domain_entry_file(tomcat5_t, tomcat5_exec_t) gen_require(` type java_exec_t; ') domain_entry_file(tomcat5_java_t, java_exec_t) type tomcat5_log_t; logging_log_file(tomcat5_log_t) type tomcat5_tmp_t; files_tmp_file(tomcat5_tmp_t) role system_r types tomcat5_java_t; ######################################## # # local policy # init_daemon_domain(tomcat5_t, tomcat5_exec_t) allow tomcat5_t tomcat5_log_t:file ra_file_perms; manage_files_pattern(tomcat5_t, tomcat5_log_t, tomcat5_log_t) allow tomcat5_t tomcat5_tmp_t:file manage_file_perms; files_tmp_filetrans(tomcat5_t,tomcat5_tmp_t,file) # neccessary for startup files_search_etc(tomcat5_t) files_search_usr(tomcat5_t) libs_search_lib(tomcat5_t) libs_use_shared_libs(tomcat5_t) miscfiles_read_localization(tomcat5_t) libs_use_ld_so(tomcat5_t) kernel_read_system_state(tomcat5_t) corecmd_search_bin(tomcat5_t) corecmd_getattr_bin_files(tomcat5_t) corecmd_exec_bin(tomcat5_t) init_write_utmp(tomcat5_t) files_read_usr_files(tomcat5_t) corecmd_exec_shell(tomcat5_t) rw_fifo_files_pattern(tomcat5_t, tomcat5_t, tomcat5_t) files_read_etc_files(tomcat5_t) logging_search_logs(tomcat5_t) # run java as tomcat5_java_t #java_spec_domtrans(tomcat5_t, tomcat5_java_t) domain_auto_trans(tomcat5_t, java_exec_t, tomcat5_java_t) # privileges for tomcat java applications allow tomcat5_t tomcat5_java_t:process { rlimitinh siginh noatsecure }; allow tomcat5_java_t tomcat5_t:process { sigchld getsched sigkill execheap execmem execstack rlimitinh siginh noatsecure }; allow tomcat5_java_t tomcat5_java_t:process { signull sigchld getsched sigkill execheap execmem execstack rlimitinh siginh noatsecure}; manage_files_pattern(tomcat5_java_t, tomcat5_log_t, tomcat5_log_t) create_files_pattern(tomcat5_java_t, tomcat5_log_t, tomcat5_log_t) libs_search_lib(tomcat5_java_t) libs_use_shared_libs(tomcat5_java_t) libs_read_lib_files(tomcat5_java_t) files_search_usr(tomcat5_java_t) files_read_usr_files(tomcat5_java_t) files_read_usr_symlinks(tomcat5_java_t) files_search_etc(tomcat5_java_t) files_manage_etc_files(tomcat5_java_t) files_search_var_lib(tomcat5_java_t) files_read_var_lib_files(tomcat5_java_t) files_read_var_lib_symlinks(tomcat5_java_t) files_manage_var_files(tomcat5_java_t) logging_search_logs(tomcat5_java_t) rw_fifo_files_pattern(tomcat5_java_t,tomcat5_t,tomcat5_t) libs_use_ld_so(tomcat5_java_t) write_files_pattern(tomcat5_java_t, tomcat5_log_t, tomcat5_log_t) unconfined_dontaudit_use_terminals(tomcat5_java_t) corecmd_search_bin(tomcat5_java_t) corecmd_getattr_bin_files(tomcat5_java_t) corecmd_read_bin_files(tomcat5_java_t) kernel_read_system_state(tomcat5_java_t) dev_read_sysfs(tomcat5_java_t) files_manage_generic_tmp_files(tomcat5_java_t) files_manage_generic_tmp_dirs(tomcat5_java_t) files_read_var_lib_files(tomcat5_java_t) miscfiles_read_localization(tomcat5_java_t) nscd_read_pid(tomcat5_java_t) dev_read_urand(tomcat5_java_t) dev_read_rand(tomcat5_java_t) kernel_search_network_state(tomcat5_java_t) kernel_read_network_state(tomcat5_java_t) allow tomcat5_java_t java_exec_t:file execute_no_trans; allow tomcat5_java_t tomcat5_java_t:process { signal getsched execstack execmem }; allow tomcat5_java_t tomcat5_java_t:tcp_socket { create ioctl bind setopt listen accept read write getattr setattr connect shutdown }; allow tomcat5_java_t tomcat5_java_t:netlink_route_socket { create ioctl read getattr write setattr append bind connect getopt setopt shutdown nlmsg_read nlmsg_write }; corenet_tcp_bind_all_ports(tomcat5_java_t) corenet_tcp_connect_all_ports(tomcat5_java_t) corenet_tcp_sendrecv_all_ports(tomcat5_java_t) corenet_tcp_bind_mapped_ipv4_node(tomcat5_java_t) corenet_tcp_sendrecv_mapped_ipv4_node(tomcat5_java_t) corenet_tcp_sendrecv_unspec_node(tomcat5_java_t) corenet_tcp_bind_unspec_node(tomcat5_java_t) sysnet_read_config(tomcat5_java_t) From selinux at gmail.com Mon Dec 31 16:48:59 2007 From: selinux at gmail.com (Tom London) Date: Mon, 31 Dec 2007 08:48:59 -0800 Subject: Multiple same specifications in selinux-policy-3.2.5-6.fc9 Message-ID: <4c4ba1530712310848o1d18db6es1b1606882f2ece14@mail.gmail.com> Minor nit in selinux-policy-3.2.5-6.fc9: Updating : selinux-policy-targeted ####################### [14/36] /etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /home/[^/]*/\.mozilla(/.*)?/plugins/libflashplayer\.so.*. /etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /root/\.mozilla(/.*)?/plugins/libflashplayer\.so.*. tom -- Tom London From dwalsh at redhat.com Mon Dec 31 20:41:06 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Dec 2007 15:41:06 -0500 Subject: logrotate_t wants { rename write } to NetworkManager_log_t In-Reply-To: <4c4ba1530712281127m2968cd11ia81c34aea8fbede4@mail.gmail.com> References: <4c4ba1530712281127m2968cd11ia81c34aea8fbede4@mail.gmail.com> Message-ID: <477953E2.4010400@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > Running selinux-policy-3.2.5-5.fc9, targeted/enforcing. > > Been seeing these lately: > > type=AVC msg=audit(1198863940.082:38): avc: denied { rename } for > pid=7287 comm="logrotate" name="wpa_supplicant.log" dev=dm-0 ino=66102 > scontext=system_u:system_r:logrotate_t:s0 > tcontext=system_u:object_r:NetworkManager_log_t:s0 tclass=file > type=SYSCALL msg=audit(1198863940.082:38): arch=40000003 syscall=38 > success=no exit=-13 a0=96d01d8 a1=96cdcd0 a2=96d0dc0 a3=96cdcb8 > items=0 ppid=7285 pid=7287 auid=4294967295 uid=0 gid=0 euid=0 suid=0 > fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="logrotate" > exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0 > key=(null) > type=AVC msg=audit(1198863940.082:39): avc: denied { write } for > pid=7287 comm="logrotate" name="wpa_supplicant.log" dev=dm-0 ino=66102 > scontext=system_u:system_r:logrotate_t:s0 > tcontext=system_u:object_r:NetworkManager_log_t:s0 tclass=file > type=SYSCALL msg=audit(1198863940.082:39): arch=40000003 syscall=5 > success=no exit=-13 a0=96d01d8 a1=8042 a2=180 a3=8042 items=0 > ppid=7285 pid=7287 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 tty=(none) comm="logrotate" > exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0 > key=(null) > > tom Fixed in selinux-policy-3.2.5-6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkd5U+IACgkQrlYvE4MpobPJogCeP+/04zTry2CIAa294MJsYBJ6 cNYAn252kn87rfK9L/9a8g1Fa0ERaMo/ =+01H -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Dec 31 20:44:09 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Dec 2007 15:44:09 -0500 Subject: Sendmail 8.14 selinux In-Reply-To: <881903.84062.qm@web60216.mail.yahoo.com> References: <881903.84062.qm@web60216.mail.yahoo.com> Message-ID: <47795499.2040205@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Harley Race wrote: > Ladies and Gentlemen, > > If I can get some help here. I am running Fedora 8 > with sendmail 8.14.2. I have been getting the > following messages in audit.log. I am not really sure > what to make of them either. Sendmail runs. Errors > are listed below: > > type=AVC msg=audit(1198878517.713:16): avc: denied { > signull } for pid=3153 comm="sendmail" > scontext=system_u:system_r:sendmail_t:s0 > tcontext=system_u:system_r:sendmail_t:s0 > tclass=process > type=SYSCALL msg=audit(1198878517.713:16): > arch=40000003 syscall=37 success=no exit=-13 a0=10fd > a1=0 a2=b7f3731c a3=84 items=0 ppid=1 pid=3153 > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=51 sgid=51 fsgid=51 tty=(none) comm="sendmail" > exe="/usr/sbin/sendmail.sendmail" > subj=system_u:system_r:sendmail_t:s0 key=(null) > > Sorry about the formatting, this webmail interface > does not support elaborate formatting. > > > > ____________________________________________________________________________________ > Be a better friend, newshound, and > know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list I will add this to the next upgrade of selinux policy. You can add it yourself by executing # grep signull /var/log/audit/audit.log | audit2allow -M mysendmail # semodule -i mysendmail.pp Fixed in selinux-policy-3.0.8-73 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkd5VJkACgkQrlYvE4MpobP99gCgofL5GC3+NqFKKp3xhBXmc/b7 WxQAoL4JPgFUuVwjVkC7gxjl+6cYQRqy =dV96 -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Dec 31 20:46:25 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Dec 2007 15:46:25 -0500 Subject: Multiple same specifications in selinux-policy-3.2.5-6.fc9 In-Reply-To: <4c4ba1530712310848o1d18db6es1b1606882f2ece14@mail.gmail.com> References: <4c4ba1530712310848o1d18db6es1b1606882f2ece14@mail.gmail.com> Message-ID: <47795521.2070106@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > Minor nit in selinux-policy-3.2.5-6.fc9: > > Updating : selinux-policy-targeted ####################### [14/36] > /etc/selinux/targeted/contexts/files/file_contexts: Multiple same > specifications for > /home/[^/]*/\.mozilla(/.*)?/plugins/libflashplayer\.so.*. > /etc/selinux/targeted/contexts/files/file_contexts: Multiple same > specifications for /root/\.mozilla(/.*)?/plugins/libflashplayer\.so.*. > > tom FIxed in 7. Shows you should not work over the holidays. :^( -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkd5VSAACgkQrlYvE4MpobPxYQCgmdsQVqyFSU7/eYWiFlOTsYZz 7TwAniqWpEK5V8pwT4azh+ZYVNtJoSTE =fz3a -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Dec 31 20:49:30 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Dec 2007 15:49:30 -0500 Subject: gdm + selinux problem In-Reply-To: <47668407.9010903@avtechpulse.com> References: <4746DA92.2000204@avtechpulse.com> <47542302.9080908@redhat.com> <47668407.9010903@avtechpulse.com> Message-ID: <477955DA.7040309@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dr. Michael J. Chudobiak wrote: >>> #============= xdm_t ============== >>> allow xdm_t initrc_tmp_t:dir { getattr setattr }; >>> >>> #============= xdm_xserver_t ============== >>> allow xdm_xserver_t initrc_tmp_t:dir { write getattr search add_name }; >>> allow xdm_xserver_t initrc_tmp_t:sock_file create; >>> >>> Now... how would this have happened? Should I just run the above >>> commands to fix everything, or is there a deeper bug / issue? >>> >> Looks like you might have some labeliing problems, but first update to >> the latest version of selinux-policy >> >> yum -y upgrade selinux-policy >> >> >> And see if most of these have been fixed. > > > Daniel, > > After updating another machine (F7 -> F8), I still get gdm failures due > to selinux, as originally reported. The problem has not be fixed by > recent rpms. See below: > > [root at titus log]# rpm -qa | grep selinux > libselinux-python-2.0.43-1.fc8 > selinux-policy-devel-3.0.8-64.fc8 > libselinux-devel-2.0.43-1.fc8 > selinux-policy-3.0.8-64.fc8 > selinux-policy-targeted-3.0.8-64.fc8 > libselinux-2.0.43-1.fc8 > > [root at titus log]# ps ax | grep gdm > 2264 ? Ss 0:00 /usr/sbin/gdm-binary -nodaemon > 2355 ? Ss 0:00 /bin/sh /etc/gdm/XKeepsCrashing > 2372 ? S 0:00 /usr/libexec/gdmopen -l /bin/sh -c > /etc/gdm/XKeepsCrashing -noopen > 2373 tty7 Ss+ 0:00 /bin/sh /etc/gdm/XKeepsCrashing -noopen > 2779 pts/0 S+ 0:00 grep gdm > > [root at titus log]# audit2allow -i messages > ...snip... > #============= xdm_t ============== > allow xdm_t default_t:file write; > allow xdm_t initrc_tmp_t:dir { getattr search setattr }; > #============= xdm_xserver_t ============== > allow xdm_xserver_t initrc_tmp_t:dir { write remove_name getattr search > add_name }; > allow xdm_xserver_t initrc_tmp_t:sock_file { create unlink }; > > > Disabling selinux lets gdm / xorg run correctly. > > I tried removing all selinux rpms, rm -rf /etc/selinux, re-installing > selinux, and touching /.autorelabel. No better. > > - Mike Please attach your audit.log? ps -eZ | grep initrc_t -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkd5VdoACgkQrlYvE4MpobOvcACg48bDjbIVbi9LkG59W2aZZSHa 4/8AoMYPw8SxUsaXXI5Pwm+7jtaqDzTW =uPzY -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Dec 31 21:00:17 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Dec 2007 16:00:17 -0500 Subject: SELinux enforcing, an external ntfs-3g mount, Samba and Fedora 8 In-Reply-To: <13ffefea0712170137scea7140w3bf0e48c59883dc1@mail.gmail.com> References: <1b006b7b0712151512j1f68eb34g61e4781cb14065a3@mail.gmail.com> <47647AED.1050500@redhat.com> <1b006b7b0712160316x1a4ac215o23a8c2b01311992f@mail.gmail.com> <47655BB9.9070400@redhat.com> <1b006b7b0712161527q36b2cd23rcb12795e44edf088@mail.gmail.com> <13ffefea0712170137scea7140w3bf0e48c59883dc1@mail.gmail.com> Message-ID: <47795861.8040907@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Danezis wrote: > I am facing the exact same issues, not only when dealing with ntfs-3g > drives, but with my RAID hard drive and my external drive also (both mounted > as vfat). I went through all the aforementioned steps and I still haven't > managed to resolve the issue. > > On Dec 17, 2007 1:27 AM, Craig Niederberger wrote: > >> sudo /usr/sbin/setsebool -P samba_run_unconfined 1 >> >> Strangely, exactly the same AVC denial. Anything else I can try, >> short of turning off SELinux, which I'd prefer not to do? >> >> Many thanks, >> Craig >> >> On Dec 16, 2007 11:09 AM, Josef Kubin wrote: >>> Hi, it looks that you rediscovered a bug ... >>> >>> Craig Niederberger wrote: >>>> Thanks for answering my post, Josef. Unfortunately, I'm getting >>>> exactly the same AVC denial and message when trying to access the >>>> drive from vmware. The odd thing is, I can access my home directory >>>> from vmware without problem. The /etc/fstab entry now reads: >>>> >>>> /dev/sdd1 /mnt/media ntfs-3g >>>> >> rw,locale=en_US.utf8,uid=500,gid=1000,context=system_u:system_r:samba_share_t >>>> 0 0 >>> I've tried to a little bit investigate things, >>> in this case the forced context is completely ignored ... >>> >>> [root at localhost vmware]# ls -Z /mnt/ >>> drwxr-xr-x root root system_u:object_r:mnt_t:s0 foo >>> >>> [root at localhost vmware]# mount -t ntfs-3g -o >>> loop,offset=32256,context=blabla ntfsImg-flat /mnt/foo/ >>> >>> [root at localhost vmware]# ls -Z /mnt/ >>> drwxrwxrwx root root system_u:object_r:fusefs_t:s0 foo >>> >>> [root at localhost vmware]# umount /mnt/foo/ >>> >>> [root at localhost vmware]# mount -t ntfs-3g -o >>> context=blabla:bleble:blabla,loop,offset=32256 ntfsImg-flat /mnt/foo/ >>> >>> [root at localhost vmware]# ls -Z /mnt/ >>> drwxrwxrwx root root system_u:object_r:fusefs_t:s0 foo >>> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> But not in this case. >>> >>> [root at localhost vmware]# cat /dev/zero > file >>> [root at localhost vmware]# mkfs.ext3 file >>> ... >>> [root at localhost vmware]# mount -o >>> loop,context=system_u:object_r:httpd_sys_content_t:s0 file /mnt/foo/ >>> >>> [root at localhost vmware]# ls -Z /mnt/ >>> drwxr-xr-x root root system_u:object_r:httpd_sys_content_t:s0 foo >>> >>> Similar bug(s) has been already reported. >>> https://bugzilla.redhat.com/show_bug.cgi?id=216846 >>> >>> >>> Following command should help :-( >>> >>> # setsebool -P samba_run_unconfined 1 >>> >>> Bye. >>> Josef >>> >>> >>> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list You can update your policy to allow this # grep fusefs_t /var/log/audit/audit.log | audit2allow -M mysamba # semodule -i mysamba.pp Then please open a bugzilla on this. It might be a kernel problem. Or we can fix it in policy. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkd5WGAACgkQrlYvE4MpobOkHQCgomIisTsODRTk7fZhawRTNUtK zDQAoNJN/8ipYiE0WrqElrQIE8AUhqFJ =MygV -----END PGP SIGNATURE-----