From phaceton at gmail.com Sat Jul 1 15:16:37 2006 From: phaceton at gmail.com (netpython) Date: Sat, 1 Jul 2006 17:16:37 +0200 Subject: firefox targeted policy Message-ID: <3655f5d90607010816t5268d9b7u7ff4311ca2ac858b@mail.gmail.com> I have made a custom policy for the firefox www-browser. To adchieve this i did the following: # cd /usr/share/selinux/devel # policygentool firefox /usr/bin/firefox # make -f /usr/share/selinux/devel/Makefile # semodule -i firefox.pp # restorecon -R -v /usr/bin/firefox When i enter: semodule -l i see the firefox module has been loaded however i expected too see some action though in /var/log/messages. -- I have made this letter longer than usual, because i lack the time to make it short. From Valdis.Kletnieks at vt.edu Sat Jul 1 15:45:12 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 01 Jul 2006 11:45:12 -0400 Subject: firefox targeted policy In-Reply-To: Your message of "Sat, 01 Jul 2006 17:16:37 +0200." <3655f5d90607010816t5268d9b7u7ff4311ca2ac858b@mail.gmail.com> References: <3655f5d90607010816t5268d9b7u7ff4311ca2ac858b@mail.gmail.com> Message-ID: <200607011545.k61FjDJ7007120@turing-police.cc.vt.edu> On Sat, 01 Jul 2006 17:16:37 +0200, netpython said: > I have made a custom policy for the firefox www-browser. > To adchieve this i did the following: > > # cd /usr/share/selinux/devel > # policygentool firefox /usr/bin/firefox > # make -f /usr/share/selinux/devel/Makefile > # semodule -i firefox.pp > # restorecon -R -v /usr/bin/firefox > > When i enter: semodule -l i see the firefox module has been loaded > however i expected too see some action though in /var/log/messages. OK.. I'll bite... what specifically did you try that *should* have generated an AVC? Also, note that if auditd is running, it will be logged in /var/log/audit/ rather than via syslogd. 'man ausearch' -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From MSchwartz at mn.rr.com Sat Jul 1 17:38:39 2006 From: MSchwartz at mn.rr.com (Marc Schwartz) Date: Sat, 01 Jul 2006 12:38:39 -0500 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <44A524CE.1070205@city-fan.org> References: <449EB4DB.2000607@laPoste.net> <449EF7D6.80708@mn.rr.com> <449FC744.6060004@city-fan.org> <1151353351.8219.118.camel@localhost.localdomain> <1151363136.2911.52.camel@laurel.intra.city-fan.org> <1151381464.13100.65.camel@localhost.localdomain> <44A15AC3.5090000@city-fan.org> <1151429665.4219.57.camel@localhost.localdomain> <1151503719.7470.12.camel@laurel.intra.city-fan.org> <1151522527.3438.52.camel@localhost.localdomain> <1151525638.7470.77.camel@laurel.intra.city-fan.org> <1151528181.3438.98.camel@localhost.localdomain> <1151529828.7470.92.camel@laurel.intra.city-fan.org> <1151530682.3438.108.camel@localhost.localdomain> <1151532794.7470.101.camel@laurel.intra.city-fan.org> <1151550925.6200.48.camel@localhost.localdomain> <1151566188.7470.111.camel@laurel.intra.city-fan.org> <1151587633.6200.56.camel@localhost.localdomain> <1151624293.6466.10.camel@localhost.localdomain> <44A524CE.1070205@city-fan.org> Message-ID: <1151775520.6413.0.camel@localhost.localdomain> On Fri, 2006-06-30 at 14:19 +0100, Paul Howarth wrote: > Marc Schwartz wrote: > > I just got home and noted the following avc's which appear to be a > > post-reboot scenario. > > > > There are some that appear to be networking related, which may indeed be > > associated with the kernel related reports. I have more than one network > > profile, where I used one at home that has a fixed IP address behind a > > router. At work, I use NM with DHCP. As I noted in a prior post, some > > network things have been flaky with the new kernel. > > > > Is this an indication that I should consider the 'updates testing' > > initscripts update as referenced in other threads on the general lists? > > Possibly; my understanding of the update is that it fixes the order of > assignment of network devices at boot time. This is useful to me for > instance, as I have a two-interface firewall, which doesn't work if it > boots with the internal and external interfaces the wrong way around. Yeah, eth0 (should be a hardwired connection) and eth1 (which should be a wireless connection) have been frequently switching back and forth. Under the former kernel, the wireless was wlan0 when using ndiswrapper. OK. I updated the rpm. I have not fully tested the updated scripts, but what was interesting is that I had modified rc.sysinit to handle my LUKS partitions during boot, but the update (which includes the default file) did not overwrite my modified version. I presume that there may be an entry in the spec file for the rpm to check for this, though I have not taken the time to review it. > > Up until the reboot, there were no other avc's. > > > > Note also what appears to be a double "//" in the path to the > > razor-agent.log. Not sure where that comes from, as the mods that I > > made in the config files are: > > > > local.cf: > > razor_config /etc/mail/spamassassin/razor/razor-agent.conf > > > > razor-agent.conf : > > razorhome = /etc/mail/spamassassin/razor/ > > > > The trailing '/' in the second file was there previously. > > You could try it without the trailing slash and see what happens. Double > slashes aren't usually an issue though. I'll leave it for now and see if it continues to show. > > New avc's: > > > > type=AVC msg=audit(1151607255.655:1577): avc: denied { signal } for pid=2283 comm="spamd" scontext=system_u:system_r:spamd_t:s0 t context=system_u:system_r:dcc_client_t:s0 tclass=process > > type=SYSCALL msg=audit(1151607255.655:1577): arch=40000003 syscall=37 success=no exit=-13 a0=780b a1=f a2=2b5b8c a3=90e7894 items=0 pid=2283 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd" exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0 > > Spamassassin signalling dcc_client. I wonder if the "a1" value is the > signal number? If so, that's SIGTERM. > > > type=AVC msg=audit(1151620643.074:452): avc: denied { append } for pid=2312 comm="spamd" name="razor-agent.log" dev=hdc7 ino=1081 390 scontext=system_u:system_r:spamd_t:s0 tcontext=user_u:object_r:etc_mail_t:s0 tclass=file > > type=SYSCALL msg=audit(1151620643.074:452): arch=40000003 syscall=5 success=no exit=-13 a0=b5c6ee0 a1=8441 a2=1b6 a3=8441 items=1 pi d=2312 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="spamd" exe="/usr/bin/perl" subj=syst em_u:system_r:spamd_t:s0 > > type=CWD msg=audit(1151620643.074:452): cwd="/" > > type=PATH msg=audit(1151620643.074:452): item=0 name="/etc/mail/spamassassin/razor//razor-agent.log" parent=1081385 dev=16:07 mode=0 40755 ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0 > > Trying to append to /etc/mail/spamassassin/razor/razor-agent.log, which > of course is etc_mail_t. Is there any way to persuade razor to put this > log in /var/log instead? Yep. Done. I made a change in: /etc/mail/spamassassin/razor/razor-agent.conf Now with a line: logfile = /var/log/razor-agent.log which was just logfile = razor-agent.log Specifying the full path overrides the normal home dir for razor files. After a spamassassin service restart, the log file is now: ls -lZ /var/log/razor-agent.log -rw-r--r-- root root user_u:object_r:var_log_t /var/log/razor-agent.log Note the change in context below. > > type=AVC msg=audit(1151620645.415:453): avc: denied { setgid } for pid=2410 comm="dccproc" capability=6 scontext=system_u:system_ r:dcc_client_t:s0 tcontext=system_u:system_r:dcc_client_t:s0 tclass=capability > > type=SYSCALL msg=audit(1151620645.415:453): arch=40000003 syscall=210 success=yes exit=0 a0=ffffffff a1=0 a2=ffffffff a3=47fcfcc0 it ems=0 pid=2410 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="dccproc" exe="/usr/local/bin /dccproc" subj=system_u:system_r:dcc_client_t:s0 > > dccproc changing its group ID. > > > type=AVC msg=audit(1151620795.471:481): avc: denied { use } for pid=5120 comm="dhclient" name="[10508]" dev=pipefs ino=10508 scon text=user_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=fd > > type=AVC msg=audit(1151620795.471:481): avc: denied { use } for pid=5120 comm="dhclient" name="[10508]" dev=pipefs ino=10508 scon text=user_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=fd > > type=SYSCALL msg=audit(1151620795.471:481): arch=40000003 syscall=11 success=yes exit=0 a0=99120f8 a1=993b580 a2=9912608 a3=993b5f0 items=2 pid=5120 auid=500 uid=0 gid=500 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) comm="dhclient" exe="/sbin/dhcl ient" subj=user_u:system_r:dhcpc_t:s0 > > type=AVC_PATH msg=audit(1151620795.471:481): path="pipe:[10508]" > > type=AVC_PATH msg=audit(1151620795.471:481): path="pipe:[10508]" > > type=CWD msg=audit(1151620795.471:481): cwd="/etc/sysconfig/network-scripts" > > type=PATH msg=audit(1151620795.471:481): item=0 name="/sbin/dhclient" inode=3542818 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:dhcpc_exec_t:s0 > > type=PATH msg=audit(1151620795.471:481): item=1 name=(null) inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_ u:object_r:ld_so_t:s0 > > type=AVC msg=audit(1151620808.228:498): avc: denied { use } for pid=5217 comm="dhclient-script" name="[10508]" dev=pipefs ino=105 08 scontext=user_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=fd > > type=AVC msg=audit(1151620808.228:498): avc: denied { use } for pid=5217 comm="dhclient-script" name="[10508]" dev=pipefs ino=105 08 scontext=user_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=fd > > type=SYSCALL msg=audit(1151620808.228:498): arch=40000003 syscall=11 success=yes exit=0 a0=9fdff30 a1=a0044c8 a2=9fe1378 a3=a002498 items=3 pid=5217 auid=500 uid=0 gid=500 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) comm="dhclient-script" exe="/bi n/bash" subj=user_u:system_r:dhcpc_t:s0 > > type=AVC_PATH msg=audit(1151620808.228:498): path="pipe:[10508]" > > type=AVC_PATH msg=audit(1151620808.228:498): path="pipe:[10508]" > > type=CWD msg=audit(1151620808.228:498): cwd="/etc/sysconfig/network-scripts" > > type=PATH msg=audit(1151620808.228:498): item=0 name="/sbin/dhclient-script" inode=3548518 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev =00:00 obj=system_u:object_r:dhcpc_exec_t:s0 > > type=PATH msg=audit(1151620808.228:498): item=1 name=(null) inode=1966191 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system _u:object_r:shell_exec_t:s0 > > type=PATH msg=audit(1151620808.228:498): item=2 name=(null) inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_ u:object_r:ld_so_t:s0 > > These appear to be unrelated network issues. > > Could be allowed by having > xserver_use_xdm_fds(dhcpc_t) > in the sysnetwork policy but I'm not sure what's happening there and if > that would be the right thing to do. > > Updated policy: > :::::::::::::: > mydcc.if > :::::::::::::: > ######################################## > ## > ## Signal the dcc client > ## > ## > ## > ## The type of the process performing this action. > ## > ## > # > interface(`dcc_signal_client',` > gen_require(` > type dcc_client_t; > ') > > allow $1 dcc_client_t:process signal; > ') > > :::::::::::::: > myspamassassin.te > :::::::::::::: > policy_module(myspamassassin, 0.1.2) > > require { > type spamd_t; > } > > # This will be included in FC5 policy when dcc module is included > dcc_domtrans_client(spamd_t) > > # This is already supposed to be included but doesn't seem to be working > pyzor_domtrans(spamd_t) > > # This will be included in FC5 policy when razor module is included > razor_domtrans(spamd_t) > > # Signal the dcc client (SIGTERM is used?) > dcc_signal_client(spamd_t) > :::::::::::::: > mydcc.te > :::::::::::::: > policy_module(mydcc, 0.1.9) > > # ================================================== > # Declarations > # ================================================== > > require { > type dcc_client_t; > } > > # ================================================== > # DCC client local policy > # ================================================== > > allow dcc_client_t self:capability setgid; > allow dcc_client_t self:netlink_route_socket r_netlink_socket_perms; > > corenet_udp_bind_inaddr_any_node(dcc_client_t) > > # dcc_client probably doesn't need to be able to read /proc/meminfo > kernel_dontaudit_list_proc(dcc_client_t) > kernel_dontaudit_read_system_state(dcc_client_t) > > spamassassin_read_spamd_tmp_files(dcc_client_t) Policies updated: amavis 1.0.4 clamav 1.0.1 dcc 1.0.0 myclamav 0.1.5 mydcc 0.1.9 mypostfix 0.1.0 mypyzor 0.2.3 myspamassassin 0.1.2 procmail 0.5.4 pyzor 1.0.1 razor 1.0.0 I also ran a restorecon on /var/log/razor-agent.log, which is now: ls -lZ /var/log/razor-agent.log -rw-r--r-- root root system_u:object_r:razor_log_t /var/log/razor-agent.log New avc's so far, after manually running all relevant cron jobs and a re-boot: type=AVC msg=audit(1151774266.909:5311): avc: denied { search } for pid=11652 comm="spamd" name="log" dev=dm-1 ino=73126 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir type=SYSCALL msg=audit(1151774266.909:5311): arch=40000003 syscall=5 success=no exit=-13 a0=b1676f0 a1=8441 a2=1b6 a3=8441 items=1 pid=11652 auid=500 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd" exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0 type=CWD msg=audit(1151774266.909:5311): cwd="/" type=PATH msg=audit(1151774266.909:5311): item=0 name="/var/log/razor-agent.log" obj=user_u:object_r:etc_mail_t:s0 type=AVC msg=audit(1151774267.629:5312): avc: denied { read } for pid=18080 comm="dccproc" name=".fonts.cache-2" dev=hdc7 ino=427877 scontext=system_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file type=SYSCALL msg=audit(1151774267.629:5312): arch=40000003 syscall=11 success=yes exit=0 a0=b0c96b8 a1=a432fd8 a2=b18feb8 a3=bfce606c items=2 pid=18080 auid=500 uid=500 gid=0 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) comm="dccproc" exe="/usr/local/bin/dccproc" subj=system_u:system_r:dcc_client_t:s0 type=AVC_PATH msg=audit(1151774267.629:5312): path="/root/.rh-fontconfig/.fonts.cache-2" type=CWD msg=audit(1151774267.629:5312): cwd="/" type=PATH msg=audit(1151774267.629:5312): item=0 name="/usr/local/bin/dccproc" inode=3118478 dev=16:07 mode=0104555 ouid=0 ogid=1 rdev=00:00 obj=system_u:object_r:dcc_client_exec_t:s0 type=PATH msg=audit(1151774267.629:5312): item=1 name=(null) inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 Thanks, Marc From tscherf at redhat.com Sun Jul 2 22:13:16 2006 From: tscherf at redhat.com (Thorsten Scherf) Date: Sun, 02 Jul 2006 18:13:16 -0400 Subject: firefox targeted policy In-Reply-To: <3655f5d90607010816t5268d9b7u7ff4311ca2ac858b@mail.gmail.com> References: <3655f5d90607010816t5268d9b7u7ff4311ca2ac858b@mail.gmail.com> Message-ID: <1151878397.9097.1.camel@tiffy.tuxgeek.de> On Sat, 2006-07-01 at 17:16 +0200, netpython wrote: > I have made a custom policy for the firefox www-browser. > To adchieve this i did the following: > > # cd /usr/share/selinux/devel > # policygentool firefox /usr/bin/firefox > # make -f /usr/share/selinux/devel/Makefile > # semodule -i firefox.pp > # restorecon -R -v /usr/bin/firefox > > When i enter: semodule -l i see the firefox module has been loaded > however i expected too see some action though in /var/log/messages. Audit-Log is /var/log/audit/audit.log in Fedora Core 5. Happy Day. Thorsten -- Thorsten Scherf Red Hat GmbH -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul at city-fan.org Tue Jul 4 16:53:05 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 04 Jul 2006 17:53:05 +0100 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <1151775520.6413.0.camel@localhost.localdomain> References: <449EF7D6.80708@mn.rr.com> <449FC744.6060004@city-fan.org> <1151353351.8219.118.camel@localhost.localdomain> <1151363136.2911.52.camel@laurel.intra.city-fan.org> <1151381464.13100.65.camel@localhost.localdomain> <44A15AC3.5090000@city-fan.org> <1151429665.4219.57.camel@localhost.localdomain> <1151503719.7470.12.camel@laurel.intra.city-fan.org> <1151522527.3438.52.camel@localhost.localdomain> <1151525638.7470.77.camel@laurel.intra.city-fan.org> <1151528181.3438.98.camel@localhost.localdomain> <1151529828.7470.92.camel@laurel.intra.city-fan.org> <1151530682.3438.108.camel@localhost.localdomain> <1151532794.7470.101.camel@laurel.intra.city-fan.org> <1151550925.6200.48.camel@localhost.localdomain> <1151566188.7470.111.camel@laurel.intra.city-fan.org> <1151587633.6200.56.camel@localhost.localdomain> <1151624293.6466.10.camel@localhost.localdomain> <44A524CE.1070205@city-fan.org> <1151775520.6413.0.camel@localhost.localdoma! in> Message-ID: <44AA9CF1.6000601@city-fan.org> Marc Schwartz wrote: > On Fri, 2006-06-30 at 14:19 +0100, Paul Howarth wrote: >> Marc Schwartz wrote: >>> I just got home and noted the following avc's which appear to be a >>> post-reboot scenario. >>> >>> There are some that appear to be networking related, which may indeed be >>> associated with the kernel related reports. I have more than one network >>> profile, where I used one at home that has a fixed IP address behind a >>> router. At work, I use NM with DHCP. As I noted in a prior post, some >>> network things have been flaky with the new kernel. >>> >>> Is this an indication that I should consider the 'updates testing' >>> initscripts update as referenced in other threads on the general lists? >> Possibly; my understanding of the update is that it fixes the order of >> assignment of network devices at boot time. This is useful to me for >> instance, as I have a two-interface firewall, which doesn't work if it >> boots with the internal and external interfaces the wrong way around. > > Yeah, eth0 (should be a hardwired connection) and eth1 (which should be > a wireless connection) have been frequently switching back and forth. > > Under the former kernel, the wireless was wlan0 when using ndiswrapper. > > OK. I updated the rpm. > > I have not fully tested the updated scripts, but what was interesting is > that I had modified rc.sysinit to handle my LUKS partitions during boot, > but the update (which includes the default file) did not overwrite my > modified version. I presume that there may be an entry in the spec file > for the rpm to check for this, though I have not taken the time to > review it. It may be that rc.sysinit was unchanged in the new package version, so your local changes would be retained. Only if there was a change to rc.sysinit would you get a .rpmnew or .rpmsave file. >>> type=AVC msg=audit(1151620643.074:452): avc: denied { append } for pid=2312 comm="spamd" name="razor-agent.log" dev=hdc7 ino=1081 390 scontext=system_u:system_r:spamd_t:s0 tcontext=user_u:object_r:etc_mail_t:s0 tclass=file >>> type=SYSCALL msg=audit(1151620643.074:452): arch=40000003 syscall=5 success=no exit=-13 a0=b5c6ee0 a1=8441 a2=1b6 a3=8441 items=1 pi d=2312 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="spamd" exe="/usr/bin/perl" subj=syst em_u:system_r:spamd_t:s0 >>> type=CWD msg=audit(1151620643.074:452): cwd="/" >>> type=PATH msg=audit(1151620643.074:452): item=0 name="/etc/mail/spamassassin/razor//razor-agent.log" parent=1081385 dev=16:07 mode=0 40755 ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0 >> Trying to append to /etc/mail/spamassassin/razor/razor-agent.log, which >> of course is etc_mail_t. Is there any way to persuade razor to put this >> log in /var/log instead? > > Yep. Done. I made a change in: > > /etc/mail/spamassassin/razor/razor-agent.conf > > Now with a line: > > logfile = /var/log/razor-agent.log > > which was just > > logfile = razor-agent.log > > Specifying the full path overrides the normal home dir for razor files. > > After a spamassassin service restart, the log file is now: > > ls -lZ /var/log/razor-agent.log > -rw-r--r-- root root user_u:object_r:var_log_t /var/log/razor-agent.log > > Note the change in context below. Not sure what to do about this. I would like the file to be created with the right context really. Unfortunately it is a process in the spamd_t domain that is creating this file rather than one in the razor_t domain. Can you check that /usr/bin/razor* have context type razor_exec_t? If they don't, try: # restorecon -v /usr/bin/razor* > Policies updated: > > amavis 1.0.4 > clamav 1.0.1 > dcc 1.0.0 > myclamav 0.1.5 > mydcc 0.1.9 > mypostfix 0.1.0 > mypyzor 0.2.3 > myspamassassin 0.1.2 > procmail 0.5.4 > pyzor 1.0.1 > razor 1.0.0 > > I also ran a restorecon on /var/log/razor-agent.log, which is now: > > ls -lZ /var/log/razor-agent.log > -rw-r--r-- root root system_u:object_r:razor_log_t /var/log/razor-agent.log > > New avc's so far, after manually running all relevant cron jobs and a > re-boot: > > type=AVC msg=audit(1151774266.909:5311): avc: denied { search } for pid=11652 comm="spamd" name="log" dev=dm-1 ino=73126 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir > type=SYSCALL msg=audit(1151774266.909:5311): arch=40000003 syscall=5 success=no exit=-13 a0=b1676f0 a1=8441 a2=1b6 a3=8441 items=1 pid=11652 auid=500 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd" exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0 > type=CWD msg=audit(1151774266.909:5311): cwd="/" > type=PATH msg=audit(1151774266.909:5311): item=0 name="/var/log/razor-agent.log" obj=user_u:object_r:etc_mail_t:s0 spamd_t trying to write the razor log. I think this should be razor_t doing this so we'll leave it for now. > type=AVC msg=audit(1151774267.629:5312): avc: denied { read } for pid=18080 comm="dccproc" name=".fonts.cache-2" dev=hdc7 ino=427877 scontext=system_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file > type=SYSCALL msg=audit(1151774267.629:5312): arch=40000003 syscall=11 success=yes exit=0 a0=b0c96b8 a1=a432fd8 a2=b18feb8 a3=bfce606c items=2 pid=18080 auid=500 uid=500 gid=0 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) comm="dccproc" exe="/usr/local/bin/dccproc" subj=system_u:system_r:dcc_client_t:s0 > type=AVC_PATH msg=audit(1151774267.629:5312): path="/root/.rh-fontconfig/.fonts.cache-2" > type=CWD msg=audit(1151774267.629:5312): cwd="/" > type=PATH msg=audit(1151774267.629:5312): item=0 name="/usr/local/bin/dccproc" inode=3118478 dev=16:07 mode=0104555 ouid=0 ogid=1 rdev=00:00 obj=system_u:object_r:dcc_client_exec_t:s0 > type=PATH msg=audit(1151774267.629:5312): item=1 name=(null) inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 Any thoughts on why dccproc might be wanting to read /root/.rh-fontconfig/.fonts.cache-2? Paul. From mschwartz at mn.rr.com Wed Jul 5 18:58:39 2006 From: mschwartz at mn.rr.com (Marc Schwartz (via MN)) Date: Wed, 05 Jul 2006 13:58:39 -0500 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <44AA9CF1.6000601@city-fan.org> References: <449EF7D6.80708@mn.rr.com> <449FC744.6060004@city-fan.org> <1151353351.8219.118.camel@localhost.localdomain> <1151363136.2911.52.camel@laurel.intra.city-fan.org> <1151381464.13100.65.camel@localhost.localdomain> <44A15AC3.5090000@city-fan.org> <1151429665.4219.57.camel@localhost.localdomain> <1151503719.7470.12.camel@laurel.intra.city-fan.org> <1151522527.3438.52.camel@localhost.localdomain> <1151525638.7470.77.camel@laurel.intra.city-fan.org> <1151528181.3438.98.camel@localhost.localdomain> <1151529828.7470.92.camel@laurel.intra.city-fan.org> <1151530682.3438.108.camel@localhost.localdomain> <1151532794.7470.101.camel@laurel.intra.city-fan.org> <1151550925.6200.48.camel@localhost.localdomain> <1151566188.7470.111.camel@laurel.intra.city-fan.org> <1151587633.6200.56.camel@localhost.localdomain> <1151624293.6466.10.camel@localhost.localdomain> <44A524CE.1070205@city-fan.org> <44AA9CF1.6000601@city-fan.org> Message-ID: <1152125919.4843.141.camel@localhost.localdomain> On Tue, 2006-07-04 at 17:53 +0100, Paul Howarth wrote: > Marc Schwartz wrote: > > On Fri, 2006-06-30 at 14:19 +0100, Paul Howarth wrote: > >> Marc Schwartz wrote: > >>> I just got home and noted the following avc's which appear to be a > >>> post-reboot scenario. > >>> > >>> There are some that appear to be networking related, which may indeed be > >>> associated with the kernel related reports. I have more than one network > >>> profile, where I used one at home that has a fixed IP address behind a > >>> router. At work, I use NM with DHCP. As I noted in a prior post, some > >>> network things have been flaky with the new kernel. > >>> > >>> Is this an indication that I should consider the 'updates testing' > >>> initscripts update as referenced in other threads on the general lists? > >> Possibly; my understanding of the update is that it fixes the order of > >> assignment of network devices at boot time. This is useful to me for > >> instance, as I have a two-interface firewall, which doesn't work if it > >> boots with the internal and external interfaces the wrong way around. > > > > Yeah, eth0 (should be a hardwired connection) and eth1 (which should be > > a wireless connection) have been frequently switching back and forth. > > > > Under the former kernel, the wireless was wlan0 when using ndiswrapper. > > > > OK. I updated the rpm. > > > > I have not fully tested the updated scripts, but what was interesting is > > that I had modified rc.sysinit to handle my LUKS partitions during boot, > > but the update (which includes the default file) did not overwrite my > > modified version. I presume that there may be an entry in the spec file > > for the rpm to check for this, though I have not taken the time to > > review it. > > It may be that rc.sysinit was unchanged in the new package version, so > your local changes would be retained. Only if there was a change to > rc.sysinit would you get a .rpmnew or .rpmsave file. OK. Thanks. Yeah, according to a check (using cpio, etc. to extract the file) it was unchanged relative to the prior original version. I wanted to be sure on this, since it could affect my ability to unlock the LUKS protected partitions on boot. > >>> type=AVC msg=audit(1151620643.074:452): avc: denied { append } for pid=2312 comm="spamd" name="razor-agent.log" dev=hdc7 ino=1081 390 scontext=system_u:system_r:spamd_t:s0 tcontext=user_u:object_r:etc_mail_t:s0 tclass=file > >>> type=SYSCALL msg=audit(1151620643.074:452): arch=40000003 syscall=5 success=no exit=-13 a0=b5c6ee0 a1=8441 a2=1b6 a3=8441 items=1 pi d=2312 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="spamd" exe="/usr/bin/perl" subj=syst em_u:system_r:spamd_t:s0 > >>> type=CWD msg=audit(1151620643.074:452): cwd="/" > >>> type=PATH msg=audit(1151620643.074:452): item=0 name="/etc/mail/spamassassin/razor//razor-agent.log" parent=1081385 dev=16:07 mode=0 40755 ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0 > >> Trying to append to /etc/mail/spamassassin/razor/razor-agent.log, which > >> of course is etc_mail_t. Is there any way to persuade razor to put this > >> log in /var/log instead? > > > > Yep. Done. I made a change in: > > > > /etc/mail/spamassassin/razor/razor-agent.conf > > > > Now with a line: > > > > logfile = /var/log/razor-agent.log > > > > which was just > > > > logfile = razor-agent.log > > > > Specifying the full path overrides the normal home dir for razor files. > > > > After a spamassassin service restart, the log file is now: > > > > ls -lZ /var/log/razor-agent.log > > -rw-r--r-- root root user_u:object_r:var_log_t /var/log/razor-agent.log > > > > Note the change in context below. > > Not sure what to do about this. I would like the file to be created with > the right context really. Unfortunately it is a process in the spamd_t > domain that is creating this file rather than one in the razor_t domain. > > Can you check that /usr/bin/razor* have context type razor_exec_t? Currently: ls -lZ /usr/bin/razor* -rwxr-xr-x root root system_u:object_r:razor_exec_t /usr/bin/razor-admin -rwxr-xr-x root root system_u:object_r:razor_exec_t /usr/bin/razor-check -rwxr-xr-x root root system_u:object_r:razor_exec_t /usr/bin/razor-client -rwxr-xr-x root root system_u:object_r:razor_exec_t /usr/bin/razor-report > If they don't, try: > # restorecon -v /usr/bin/razor* > > > Policies updated: > > > > amavis 1.0.4 > > clamav 1.0.1 > > dcc 1.0.0 > > myclamav 0.1.5 > > mydcc 0.1.9 > > mypostfix 0.1.0 > > mypyzor 0.2.3 > > myspamassassin 0.1.2 > > procmail 0.5.4 > > pyzor 1.0.1 > > razor 1.0.0 > > > > I also ran a restorecon on /var/log/razor-agent.log, which is now: > > > > ls -lZ /var/log/razor-agent.log > > -rw-r--r-- root root system_u:object_r:razor_log_t /var/log/razor-agent.log > > > > New avc's so far, after manually running all relevant cron jobs and a > > re-boot: > > > > type=AVC msg=audit(1151774266.909:5311): avc: denied { search } for pid=11652 comm="spamd" name="log" dev=dm-1 ino=73126 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir > > type=SYSCALL msg=audit(1151774266.909:5311): arch=40000003 syscall=5 success=no exit=-13 a0=b1676f0 a1=8441 a2=1b6 a3=8441 items=1 pid=11652 auid=500 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd" exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0 > > type=CWD msg=audit(1151774266.909:5311): cwd="/" > > type=PATH msg=audit(1151774266.909:5311): item=0 name="/var/log/razor-agent.log" obj=user_u:object_r:etc_mail_t:s0 > > spamd_t trying to write the razor log. I think this should be razor_t > doing this so we'll leave it for now. > > > type=AVC msg=audit(1151774267.629:5312): avc: denied { read } for pid=18080 comm="dccproc" name=".fonts.cache-2" dev=hdc7 ino=427877 scontext=system_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file > > type=SYSCALL msg=audit(1151774267.629:5312): arch=40000003 syscall=11 success=yes exit=0 a0=b0c96b8 a1=a432fd8 a2=b18feb8 a3=bfce606c items=2 pid=18080 auid=500 uid=500 gid=0 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) comm="dccproc" exe="/usr/local/bin/dccproc" subj=system_u:system_r:dcc_client_t:s0 > > type=AVC_PATH msg=audit(1151774267.629:5312): path="/root/.rh-fontconfig/.fonts.cache-2" > > type=CWD msg=audit(1151774267.629:5312): cwd="/" > > type=PATH msg=audit(1151774267.629:5312): item=0 name="/usr/local/bin/dccproc" inode=3118478 dev=16:07 mode=0104555 ouid=0 ogid=1 rdev=00:00 obj=system_u:object_r:dcc_client_exec_t:s0 > > type=PATH msg=audit(1151774267.629:5312): item=1 name=(null) inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 > > Any thoughts on why dccproc might be wanting to read > /root/.rh-fontconfig/.fonts.cache-2? No definitive answer. Checking the dcc source code tree using grep, the only references to 'font' are in the cgi-bin files (common and common.in) and then in the HTML files (FAQ.HTML and INSTALL.HTML). Thanks, Marc From selinux at tecnopolis.ca Thu Jul 6 13:11:01 2006 From: selinux at tecnopolis.ca (Trevor Cordes) Date: Thu, 6 Jul 2006 08:11:01 -0500 Subject: selinux breaks vgetty Message-ID: <20060706131101.GA18482@pog.tecnopolis.ca> selinux appears to break vgetty (in the mgetty-voice package). I'm wondering if selinux was even meant to be applied to vgetty or if it's somehow getting confused with its sister mgetty, which is selinux protected. My main question is, how can I work around this so I can get my voice/fax system working again? Is there an easy way to turn off selinux protection just for vgetty? Or can someone help me with what I need to do to make it work with vgetty? My vgetty setup is quite complex with many user-defined helper scripts which process incoming voicemail. It may be too hard (and not worth it) to get selinux and vgetty to live happily together. Thanks! I've opened a bugzilla for this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197574 From ynakam at gwu.edu Thu Jul 6 19:29:29 2006 From: ynakam at gwu.edu (Yuichi Nakamura) Date: Thu, 6 Jul 2006 15:29:29 -0400 Subject: [ANN] SELinux Policy Editor 2.0(seedit 2.0) Message-ID: <20060706152929.dcab61db.ynakam@gwu.edu> Hi. I am glad to announce that SELinux Policy Editor 2.0(seedit 2.0) has been released. seedit is a tool to make SELinux easy. We have renewed the tool. Almost everything have been changed. Policy generator, new GUI are developed, and many others. You can download and try it from http://seedit.sourceforge.net Manuals are also provided. It supports Fedora Core 5 and Cent OS 4. If you have question, please feel free to contact me. Here is a brief introduction of seedit 2.0: 1. About SELinux Policy Editor SELinux Policy Editor(seedit) is a tool to make SELinux easy. It was originally developed by Hitachi Software, now is developed in SELinux Policy Editor Project(http://seedit.sourceforge.net). seedit is composed of Simplified Policy and tools such as GUI and policy generator. The most important is Simplified Policy. Simplified Policy is a policy described by Simplified Policy Description Language(SPDL). SPDL hides detail of SELinux configuration by name-based configuration and reducing number of permissions. Following is example policy for Apache by SPDL. domain httpd_t; include daemon.sp; program /usr/sbin/httpd; allow /var/www/** r,s; allownet -protocol tcp -port 80 server. ... As you see, type is not used. You can use file name, port number in configuration. SPDL is converted into SELinux policy by SPDL compiler. 2. New features in 2.0 In this release, we have renewed our tool. We improved usability and security. 2.1 Improvement in usability About usability, we learned a lot from AppArmor. We investigated AppArmor and taken good points of it. We have to thank to them :-) * New GUI We have developed new GUI "seedit Control Panel". It works on X Window System, implemented by python and pygtk. You can see screenshots at http://sourceforge.net/project/screenshots.php?group_id=135756 . You can do almost everything about SELinux from control panel. Features of control panel are following: - Policy Generator Read audit log and generate Simplified Policy. - Policy Template tool User can generate policy template for applications by answering some questions. - Editor Editor for SPDL, you can insert configuration by GUI. - Status checker It is like AppArmor's unconfined command. You can check network process's domain. You can see which domains are assigned unconfined domain. * Syntax of SPDL: We have taken some AppArmor's profile syntax into SPDL. * RBAC(Role-Based Access Control) Support You can switch on/off RBAC support easily by one command. See RBAC guide. 2.2 Improvement of security SPDL reduces number of permissions by integrating SELinux's permissions, but it affects security. We have re-designed permission integration of SPDL, as a research project at The George Washington University. For detail of SPDL, see document "Specification of Simplified Policy Description Language(SPDL)". More documents about security is in progress. 3. Feedback If you have question or want to say something to us, please e-mail to me(himainu-ynakam at miomio.jp), or subscribe seedit-devel-list at http://sourceforge.net/mail/?group_id=135756 --- Yuichi Nakamura The George Washington University, Hitachi Software SELinux Policy Editor: http://seedit.sourceforge.net/ From selinux at gmail.com Fri Jul 7 14:14:08 2006 From: selinux at gmail.com (Tom London) Date: Fri, 7 Jul 2006 07:14:08 -0700 Subject: Latest kernel (2356), avc's on hwclock Message-ID: <4c4ba1530607070714v270295e2yc6ebb5d43f602914@mail.gmail.com> Running latest rawhide kernel, get the following during boot (in /var/log/messages): Jul 7 06:22:45 localhost kernel: audit(1152278484.994:5): avc: denied { audit_write } for pid=471 comm="hwclock" capability=29 scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:hwclock_t:s0 tclass=capability tom -- Tom London From sds at tycho.nsa.gov Fri Jul 7 14:27:08 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 07 Jul 2006 10:27:08 -0400 Subject: Latest kernel (2356), avc's on hwclock In-Reply-To: <4c4ba1530607070714v270295e2yc6ebb5d43f602914@mail.gmail.com> References: <4c4ba1530607070714v270295e2yc6ebb5d43f602914@mail.gmail.com> Message-ID: <1152282428.3663.4.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-07-07 at 07:14 -0700, Tom London wrote: > Running latest rawhide kernel, get the following during boot (in > /var/log/messages): > > Jul 7 06:22:45 localhost kernel: audit(1152278484.994:5): avc: > denied { audit_write } for pid=471 comm="hwclock" capability=29 > scontext=system_u:system_r:hwclock_t:s0 > tcontext=system_u:system_r:hwclock_t:s0 tclass=capability Looks like the Fedora hwclock is instrumented to generate an audit record, but policy doesn't yet allow it to do so. These capability checks used to be silent (no auditing) since they occur on netlink recv, but a recent patch has enabled SELinux to generate audit messages on the netlink recv capability checks. So we can expect these types of denials to show up now. Should be allowed in this case. -- Stephen Smalley National Security Agency From redhatdude at bellsouth.net Fri Jul 7 20:34:54 2006 From: redhatdude at bellsouth.net (redhatdude at bellsouth.net) Date: Fri, 7 Jul 2006 16:34:54 -0400 Subject: SeLinux and mail relaying Message-ID: <63DD9642-13DD-4A47-9092-36C3508BACDD@bellsouth.net> Hi, While trying to set up a mail cgi script, I discovered that Selinux is not allowing relaying mail from anything but postfix. I realized this when I turned off selinux and I started getting the result of cron jobs and other similar system emails. So my question is , how can I make selinux allow programs other than postfix and cyrus to relay emails? Thanks, EJ. From i.pilcher at comcast.net Fri Jul 7 23:06:59 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Fri, 07 Jul 2006 18:06:59 -0500 Subject: Latest kernel (2356), avc's on hwclock In-Reply-To: <1152282428.3663.4.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba1530607070714v270295e2yc6ebb5d43f602914@mail.gmail.com> <1152282428.3663.4.camel@moss-spartans.epoch.ncsc.mil> Message-ID: Stephen Smalley wrote: > Looks like the Fedora hwclock is instrumented to generate an audit > record, but policy doesn't yet allow it to do so. These capability > checks used to be silent (no auditing) since they occur on netlink recv, > but a recent patch has enabled SELinux to generate audit messages on the > netlink recv capability checks. So we can expect these types of denials > to show up now. Should be allowed in this case. So it's generating an audit message, because it wasn't allowed to generate an audit message? I've only had half a beer... -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From dwalsh at redhat.com Sat Jul 8 19:41:59 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 08 Jul 2006 15:41:59 -0400 Subject: pam_console_t wants access to device_t:chr_file ? In-Reply-To: <4c4ba1530606290652k7a5e402ekfb79e996eee202d0@mail.gmail.com> References: <4c4ba1530606290652k7a5e402ekfb79e996eee202d0@mail.gmail.com> Message-ID: <44B00A87.9050909@redhat.com> Tom London wrote: > Running targeted/enforcing, latest Rawhide. > > Noticed this in /var/log/messages, before auditd is started I guess: > > Jun 29 06:43:48 localhost kernel: audit(1151588567.562:102): avc: > denied { getattr } for pid=1526 comm="pam_console_app" > name="usbdev5.5_ep02" dev=tmpfs ino=5143 > scontext=system_u:system_r:pam_console_t:s0 > tcontext=system_u:object_r:device_t:s0 tclass=chr_file > \ The problem is usbdev5.5_ep02 is not labeled correctly. Is this a real device? What kind of device is is? > Jun 29 06:43:48 localhost kernel: audit(1151588567.562:103): avc: > denied { getattr } for pid=1526 comm="pam_console_app" > name="usbdev5.5_ep81" dev=tmpfs ino=5120 > scontext=system_u:system_r:pam_console_t:s0 > tcontext=system_u:object_r:device_t:s0 tclass=chr_file > Jun 29 06:43:48 localhost kernel: audit(1151588567.562:104): avc: > denied { getattr } for pid=1526 comm="pam_console_app" > name="usbdev5.5_ep00" dev=tmpfs ino=5068 > scontext=system_u:system_r:pam_console_t:s0 > tcontext=system_u:object_r:device_t:s0 tclass=chr_file > > << actually many, many copies of these....>> > > tom From selinux at gmail.com Sat Jul 8 20:15:36 2006 From: selinux at gmail.com (Tom London) Date: Sat, 8 Jul 2006 13:15:36 -0700 Subject: pam_console_t wants access to device_t:chr_file ? In-Reply-To: <44B00A87.9050909@redhat.com> References: <4c4ba1530606290652k7a5e402ekfb79e996eee202d0@mail.gmail.com> <44B00A87.9050909@redhat.com> Message-ID: <4c4ba1530607081315k57637dd0n77db7b61f93a1839@mail.gmail.com> On 7/8/06, Daniel J Walsh wrote: > Tom London wrote: > > Running targeted/enforcing, latest Rawhide. > > > > Noticed this in /var/log/messages, before auditd is started I guess: > > > > Jun 29 06:43:48 localhost kernel: audit(1151588567.562:102): avc: > > denied { getattr } for pid=1526 comm="pam_console_app" > > name="usbdev5.5_ep02" dev=tmpfs ino=5143 > > scontext=system_u:system_r:pam_console_t:s0 > > tcontext=system_u:object_r:device_t:s0 tclass=chr_file > > \ > The problem is usbdev5.5_ep02 is not labeled correctly. Is this a real > device? What kind of device is is? > > Jun 29 06:43:48 localhost kernel: audit(1151588567.562:103): avc: > > denied { getattr } for pid=1526 comm="pam_console_app" > > name="usbdev5.5_ep81" dev=tmpfs ino=5120 > > scontext=system_u:system_r:pam_console_t:s0 > > tcontext=system_u:object_r:device_t:s0 tclass=chr_file > > Jun 29 06:43:48 localhost kernel: audit(1151588567.562:104): avc: > > denied { getattr } for pid=1526 comm="pam_console_app" > > name="usbdev5.5_ep00" dev=tmpfs ino=5068 > > scontext=system_u:system_r:pam_console_t:s0 > > tcontext=system_u:object_r:device_t:s0 tclass=chr_file > > > > << actually many, many copies of these....>> > > Happens every time I boot. Appears to depend on the usb devices I have connected at the time (I have 2 'docks' for my laptop, so the USB setup is not the same). In this case, 'lsusb' says: Bus 005 Device 005: ID 04b8:010a Seiko Epson Corp. Perfection 1640SU Bus 005 Device 004: ID 0461:4d03 Primax Electronics, Ltd Kensington Mouse-in-a-box Bus 005 Device 002: ID 04b3:4484 IBM Corp. Bus 005 Device 001: ID 0000:0000 Bus 002 Device 001: ID 0000:0000 Bus 003 Device 003: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader Bus 003 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 So I'm guessing usbdev5.5_ep* is pointing at this. tom -- Tom London From jacliburn at bellsouth.net Sun Jul 9 01:11:46 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Sat, 08 Jul 2006 20:11:46 -0500 Subject: avc: denied for netstat under 2.6.17-1.2358.fc6 Message-ID: <1152407506.2385.3.camel@osprey.hogchain.net> Running rawhide, netstat -ptuna produces the following in /var/log/messages. Jul 8 20:08:17 osprey kernel: audit(1152407297.929:15): avc: denied { ptrace } for pid=2526 comm="netstat" scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:udev_t:s0-s0:c0.c255 tclass=process Jul 8 20:08:17 osprey kernel: audit(1152407297.949:16): avc: denied { ptrace } for pid=2526 comm="netstat" scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tclass=process Jul 8 20:08:17 osprey kernel: audit(1152407297.949:17): avc: denied { ptrace } for pid=2526 comm="netstat" scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process Jul 8 20:08:17 osprey kernel: audit(1152407297.977:18): avc: denied { ptrace } for pid=2526 comm="netstat" scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=process Jul 8 20:08:19 osprey kernel: audit(1152407297.993:19): avc: denied { ptrace } for pid=2526 comm="netstat" scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=process From m3freak at rogers.com Sun Jul 9 01:11:54 2006 From: m3freak at rogers.com (Kanwar Ranbir Sandhu) Date: Sat, 08 Jul 2006 21:11:54 -0400 Subject: [ANN] SELinux Policy Editor 2.0(seedit 2.0) In-Reply-To: <20060706152929.dcab61db.ynakam@gwu.edu> References: <20060706152929.dcab61db.ynakam@gwu.edu> Message-ID: <1152407514.5947.14.camel@krs> On Thu, 2006-06-07 at 15:29 -0400, Yuichi Nakamura wrote: > 3. Feedback > If you have question or want to say something to us, > please e-mail to me(himainu-ynakam at miomio.jp), > or subscribe seedit-devel-list at > http://sourceforge.net/mail/?group_id=135756 Anything that makes SELinux easier is good in my books (well, to a limit, of course). If I can use SELinux, tweak it for my needs as needed, and not have to know about it in intimate detail, I'll be fairly happy. :) Has anyone used this tool? Does it work with CentOS 4, FC4 and 5? I've stayed away from SELinux because of its complexity, but I can't do that much longer. Regards, Ranbir -- Kanwar Ranbir Sandhu Linux 2.6.17-1.2139_FC4 i686 GNU/Linux 21:08:30 up 14:38, 3 users, load average: 0.00, 0.12, 0.23 From jan at codejunky.org Sun Jul 9 15:45:43 2006 From: jan at codejunky.org (Jan Meier) Date: Sun, 9 Jul 2006 17:45:43 +0200 Subject: Problem accessing samba shares with enforcing enabled Message-ID: <200607091745.46514.jan@codejunky.org> Hello, I get the following avc denied when I try to write a file via samba from a remote machine: jeeves kernel: audit(1152459345.543:71): avc: denied { write } for pid=2332 comm="smbd" name="jan" dev=hda1 ino=131 scontext=root:system_r:smbd_t:s0 tcontext=root:object_r:smbd_t:s0 tclass=dir ls -Z for the proper directory where I want to write into shows: drwxr-xr-x jan users root:object_r:smbd_t jan Any suggestions? Regards Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at city-fan.org Mon Jul 10 07:47:49 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 10 Jul 2006 08:47:49 +0100 Subject: Problem accessing samba shares with enforcing enabled In-Reply-To: <200607091745.46514.jan@codejunky.org> References: <200607091745.46514.jan@codejunky.org> Message-ID: <1152517669.10312.55.camel@laurel.intra.city-fan.org> On Sun, 2006-07-09 at 17:45 +0200, Jan Meier wrote: > Hello, > > I get the following avc denied when I try to write a file via samba from a > remote machine: > > jeeves kernel: audit(1152459345.543:71): avc: denied { write } for pid=2332 > comm="smbd" name="jan" dev=hda1 ino=131 scontext=root:system_r:smbd_t:s0 > tcontext=root:object_r:smbd_t:s0 tclass=dir > > ls -Z for the proper directory where I want to write into shows: > > drwxr-xr-x jan users root:object_r:smbd_t jan > > Any suggestions? It should be samba_share_t, not Smbd_t. Paul. From paul at city-fan.org Mon Jul 10 07:49:19 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 10 Jul 2006 08:49:19 +0100 Subject: SeLinux and mail relaying In-Reply-To: <63DD9642-13DD-4A47-9092-36C3508BACDD@bellsouth.net> References: <63DD9642-13DD-4A47-9092-36C3508BACDD@bellsouth.net> Message-ID: <1152517760.10312.58.camel@laurel.intra.city-fan.org> On Fri, 2006-07-07 at 16:34 -0400, redhatdude at bellsouth.net wrote: > Hi, > While trying to set up a mail cgi script, I discovered that Selinux > is not allowing relaying mail from anything but postfix. I realized > this when I turned off selinux and I started getting the result of > cron jobs and other similar system emails. > So my question is , how can I make selinux allow programs other than > postfix and cyrus to relay emails? Can you post the AVC messages you are getting when mail from cron is being blocked by SELinux? Paul. From tmraz at redhat.com Mon Jul 10 09:23:16 2006 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 10 Jul 2006 11:23:16 +0200 Subject: pam_console_t wants access to device_t:chr_file ? In-Reply-To: <4c4ba1530607081315k57637dd0n77db7b61f93a1839@mail.gmail.com> References: <4c4ba1530606290652k7a5e402ekfb79e996eee202d0@mail.gmail.com> <44B00A87.9050909@redhat.com> <4c4ba1530607081315k57637dd0n77db7b61f93a1839@mail.gmail.com> Message-ID: <1152523396.3470.13.camel@perun.kabelta.loc> On Sat, 2006-07-08 at 13:15 -0700, Tom London wrote: > On 7/8/06, Daniel J Walsh wrote: > > Tom London wrote: > > > Running targeted/enforcing, latest Rawhide. > > > > > > Noticed this in /var/log/messages, before auditd is started I guess: > > > > > > Jun 29 06:43:48 localhost kernel: audit(1151588567.562:102): avc: > > > denied { getattr } for pid=1526 comm="pam_console_app" > > > name="usbdev5.5_ep02" dev=tmpfs ino=5143 > > > scontext=system_u:system_r:pam_console_t:s0 > > > tcontext=system_u:object_r:device_t:s0 tclass=chr_file > > > \ > > The problem is usbdev5.5_ep02 is not labeled correctly. Is this a real > > device? What kind of device is is? > > > Jun 29 06:43:48 localhost kernel: audit(1151588567.562:103): avc: > > > denied { getattr } for pid=1526 comm="pam_console_app" > > > name="usbdev5.5_ep81" dev=tmpfs ino=5120 > > > scontext=system_u:system_r:pam_console_t:s0 > > > tcontext=system_u:object_r:device_t:s0 tclass=chr_file > > > Jun 29 06:43:48 localhost kernel: audit(1151588567.562:104): avc: > > > denied { getattr } for pid=1526 comm="pam_console_app" > > > name="usbdev5.5_ep00" dev=tmpfs ino=5068 > > > scontext=system_u:system_r:pam_console_t:s0 > > > tcontext=system_u:object_r:device_t:s0 tclass=chr_file > > > > > > << actually many, many copies of these....>> > > > > Happens every time I boot. Appears to depend on the usb devices I > have connected at the time (I have 2 'docks' for my laptop, so the USB > setup is not the same). > > In this case, 'lsusb' says: > Bus 005 Device 005: ID 04b8:010a Seiko Epson Corp. Perfection 1640SU > Bus 005 Device 004: ID 0461:4d03 Primax Electronics, Ltd Kensington > Mouse-in-a-box > Bus 005 Device 002: ID 04b3:4484 IBM Corp. > Bus 005 Device 001: ID 0000:0000 > Bus 002 Device 001: ID 0000:0000 > Bus 003 Device 003: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader > Bus 003 Device 001: ID 0000:0000 > Bus 001 Device 001: ID 0000:0000 > Bus 004 Device 001: ID 0000:0000 > > So I'm guessing usbdev5.5_ep* is pointing at this. It is the scanner device so it should have a scanner_device_t type. pam_console_apply actually accesses /dev/usb/scanner* or /dev/scanner* symlink which points to the device node. -- Tomas Mraz From selinux at gmail.com Mon Jul 10 13:37:44 2006 From: selinux at gmail.com (Tom London) Date: Mon, 10 Jul 2006 06:37:44 -0700 Subject: pam_console_t wants access to device_t:chr_file ? In-Reply-To: <1152523396.3470.13.camel@perun.kabelta.loc> References: <4c4ba1530606290652k7a5e402ekfb79e996eee202d0@mail.gmail.com> <44B00A87.9050909@redhat.com> <4c4ba1530607081315k57637dd0n77db7b61f93a1839@mail.gmail.com> <1152523396.3470.13.camel@perun.kabelta.loc> Message-ID: <4c4ba1530607100637v60b94586re4894d92a63d1ee@mail.gmail.com> On 7/10/06, Tomas Mraz wrote: > On Sat, 2006-07-08 at 13:15 -0700, Tom London wrote: > > On 7/8/06, Daniel J Walsh wrote: > > Happens every time I boot. Appears to depend on the usb devices I > > have connected at the time (I have 2 'docks' for my laptop, so the USB > > setup is not the same). > > > > In this case, 'lsusb' says: > > Bus 005 Device 005: ID 04b8:010a Seiko Epson Corp. Perfection 1640SU > > Bus 005 Device 004: ID 0461:4d03 Primax Electronics, Ltd Kensington > > Mouse-in-a-box > > Bus 005 Device 002: ID 04b3:4484 IBM Corp. > > Bus 005 Device 001: ID 0000:0000 > > Bus 002 Device 001: ID 0000:0000 > > Bus 003 Device 003: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader > > Bus 003 Device 001: ID 0000:0000 > > Bus 001 Device 001: ID 0000:0000 > > Bus 004 Device 001: ID 0000:0000 > > > > So I'm guessing usbdev5.5_ep* is pointing at this. > > It is the scanner device so it should have a scanner_device_t type. > pam_console_apply actually accesses /dev/usb/scanner* or /dev/scanner* > symlink which points to the device node. > -- > Tomas Mraz > Here is the output from 'ls -lZ /dev/scanner*': lrwxrwxrwx root root system_u:object_r:device_t /dev/scanner-usbdev1.5 -> bus/usb/001/005 lrwxrwxrwx root root system_u:object_r:device_t /dev/scanner-usbdev1.5_ep00 -> usbdev1.5_ep00 lrwxrwxrwx root root system_u:object_r:device_t /dev/scanner-usbdev1.5_ep02 -> usbdev1.5_ep02 lrwxrwxrwx root root system_u:object_r:device_t /dev/scanner-usbdev1.5_ep81 -> usbdev1.5_ep81 All /dev/usbdev* files are labeled as device_t. tom -- Tom London From ynakam at gwu.edu Mon Jul 10 14:41:40 2006 From: ynakam at gwu.edu (Yuichi Nakamura) Date: Mon, 10 Jul 2006 10:41:40 -0400 Subject: [ANN] SELinux Policy Editor 2.0(seedit 2.0) In-Reply-To: <1152407514.5947.14.camel@krs> References: <20060706152929.dcab61db.ynakam@gwu.edu> <1152407514.5947.14.camel@krs> Message-ID: <20060710104140.98c41442.ynakam@gwu.edu> Hi. On Sat, 08 Jul 2006 21:11:54 -0400 Kanwar Ranbir Sandhu wrote: > Has anyone used this tool? Does it work with CentOS 4, FC4 and 5? It should work on Fedora Core 5 and CentOS 4.3. I think it will work on system whose SELinux is based on that of after Fedora Core 3. I heared someone tried on Ubuntu, but not sure it is working correctly. Yuichi Nakamura From selinux at gmail.com Mon Jul 10 15:05:11 2006 From: selinux at gmail.com (Tom London) Date: Mon, 10 Jul 2006 08:05:11 -0700 Subject: Latest kernel (2356), avc's on hwclock In-Reply-To: References: <4c4ba1530607070714v270295e2yc6ebb5d43f602914@mail.gmail.com> <1152282428.3663.4.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4c4ba1530607100805l44412dc3o38d318771c003e83@mail.gmail.com> On 7/7/06, Ian Pilcher wrote: > Stephen Smalley wrote: > > Looks like the Fedora hwclock is instrumented to generate an audit > > record, but policy doesn't yet allow it to do so. These capability > > checks used to be silent (no auditing) since they occur on netlink recv, > > but a recent patch has enabled SELinux to generate audit messages on the > > netlink recv capability checks. So we can expect these types of denials > > to show up now. Should be allowed in this case. > > So it's generating an audit message, because it wasn't allowed to > generate an audit message? > > I've only had half a beer... > > -- > ======================================================================== > Ian Pilcher i.pilcher at comcast.net > ======================================================================== > A slight side question: hwclock seems to be producing audit messages either before or after auditd has started/exited. I see a message on shutdown, but it appears not to be logged anywhere. Does that meet auditing requirements? tom -- Tom London From redhatdude at bellsouth.net Mon Jul 10 16:38:35 2006 From: redhatdude at bellsouth.net (redhatdude at bellsouth.net) Date: Mon, 10 Jul 2006 12:38:35 -0400 Subject: SeLinux and mail relaying In-Reply-To: References: <63DD9642-13DD-4A47-9092-36C3508BACDD@bellsouth.net> <1152517760.10312.58.camel@laurel.intra.city-fan.org> Message-ID: <4A523356-66FF-43B3-8054-47DF0512AA12@bellsouth.net> > > On Jul 10, 2006, at 3:49 AM, Paul Howarth wrote: > >> On Fri, 2006-07-07 at 16:34 -0400, redhatdude at bellsouth.net wrote: >>> Hi, >>> While trying to set up a mail cgi script, I discovered that Selinux >>> is not allowing relaying mail from anything but postfix. I realized >>> this when I turned off selinux and I started getting the result of >>> cron jobs and other similar system emails. >>> So my question is , how can I make selinux allow programs other >>> than >>> postfix and cyrus to relay emails? >> >> Can you post the AVC messages you are getting when mail from cron is >> being blocked by SELinux? >> >> Paul. >> > Hi, Here it is. Thanks for you help. EJ type=AVC_PATH msg=audit(1152547081.207:3467): path="/var/lib/imap/ socket/lmtp" type=SOCKADDR msg=audit(1152547081.207:3467): saddr=01002F7661722F6C69622F696D61702F736F636B65742F6C6D7470000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 0000000000 type=SOCKETCALL msg=audit(1152547081.207:3467): nargs=3 a0=b a1=bfc966ec a2=6e type=PATH msg=audit(1152547081.207:3467): item=0 name=(null) inode=8585327 dev=fd:00 mode=0140777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:cyrus_var_lib_t:s0 type=AVC msg=audit(1152547081.303:3468): avc: denied { connectto } for pid=31220 comm="lmtp" name="lmtp" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket type=SYSCALL msg=audit(1152547081.303:3468): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bffc5900 a2=f8e430 a3=f90c24 items=1 pid=31220 auid=4294967295 uid=89 gid=89 euid=89 suid=89 fsuid=89 egid=89 sgid=89 fsgid=89 tty=(none) comm="lmtp" exe="/usr/ libexec/postfix/lmtp" subj=system_u:system_r:postfix_master_t:s0 type=AVC_PATH msg=audit(1152547081.303:3468): path="/var/lib/imap/ socket/lmtp" type=SOCKADDR msg=audit(1152547081.303:3468): saddr=01002F7661722F6C69622F696D61702F736F636B65742F6C6D7470000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 0000000000 type=SOCKETCALL msg=audit(1152547081.303:3468): nargs=3 a0=b a1=bffc5a1c a2=6e type=PATH msg=audit(1152547081.303:3468): item=0 name=(null) inode=8585327 dev=fd:00 mode=0140777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:cyrus_var_lib_t:s0 This is the message I get when I try to run a mail form cgi script, which is why I realized that I was having problems with my system sending mail. type=AVC msg=audit(1152547494.882:3475): avc: denied { getattr } for pid=31270 comm="postdrop" name="[165322]" dev=pipefs ino=165322 scontext=user_u:system_r:postfix_postdrop_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1152547494.882:3475): arch=40000003 syscall=197 success=no exit=-13 a0=2 a1=bfa6d7c0 a2=50aff4 a3=3 items=0 pid=31270 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=90 sgid=90 fsgid=90 tty=(none) comm="postdrop" exe="/ usr/sbin/postdrop" subj=user_u:system_r:postfix_postdrop_t:s0 type=AVC_PATH msg=audit(1152547494.882:3475): path="pipe:[165322]" type=AVC msg=audit(1152547495.010:3476): avc: denied { connectto } for pid=31274 comm="lmtp" name="lmtp" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket type=SYSCALL msg=audit(1152547495.010:3476): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bffb50f0 a2=4b1430 a3=4b3c24 items=1 pid=31274 auid=4294967295 uid=89 gid=89 euid=89 suid=89 fsuid=89 egid=89 sgid=89 fsgid=89 tty=(none) comm="lmtp" exe="/usr/ libexec/postfix/lmtp" subj=system_u:system_r:postfix_master_t:s0 type=AVC_PATH msg=audit(1152547495.010:3476): path="/var/lib/imap/ socket/lmtp" type=SOCKADDR msg=audit(1152547495.010:3476): saddr=01002F7661722F6C69622F696D61702F736F636B65742F6C6D7470000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 0000000000 type=SOCKETCALL msg=audit(1152547495.010:3476): nargs=3 a0=b a1=bffb520c a2=6e type=PATH msg=audit(1152547495.010:3476): item=0 name=(null) inode=8585327 dev=fd:00 mode=0140777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:cyrus_var_lib_t:s0 From sds at tycho.nsa.gov Mon Jul 10 19:58:27 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 10 Jul 2006 15:58:27 -0400 Subject: Latest kernel (2356), avc's on hwclock In-Reply-To: References: <4c4ba1530607070714v270295e2yc6ebb5d43f602914@mail.gmail.com> <1152282428.3663.4.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1152561507.29240.1.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-07-07 at 18:06 -0500, Ian Pilcher wrote: > Stephen Smalley wrote: > > Looks like the Fedora hwclock is instrumented to generate an audit > > record, but policy doesn't yet allow it to do so. These capability > > checks used to be silent (no auditing) since they occur on netlink recv, > > but a recent patch has enabled SELinux to generate audit messages on the > > netlink recv capability checks. So we can expect these types of denials > > to show up now. Should be allowed in this case. > > So it's generating an audit message, because it wasn't allowed to > generate an audit message? No, the kernel is generating an audit message about a permission denial on hwclock's attempt to generate its own user audit message (with its own content, which could be arbitary). -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Jul 10 20:11:30 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 10 Jul 2006 16:11:30 -0400 Subject: Latest kernel (2356), avc's on hwclock In-Reply-To: <4c4ba1530607100805l44412dc3o38d318771c003e83@mail.gmail.com> References: <4c4ba1530607070714v270295e2yc6ebb5d43f602914@mail.gmail.com> <1152282428.3663.4.camel@moss-spartans.epoch.ncsc.mil> <4c4ba1530607100805l44412dc3o38d318771c003e83@mail.gmail.com> Message-ID: <1152562290.29240.3.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2006-07-10 at 08:05 -0700, Tom London wrote: > On 7/7/06, Ian Pilcher wrote: > > Stephen Smalley wrote: > > > Looks like the Fedora hwclock is instrumented to generate an audit > > > record, but policy doesn't yet allow it to do so. These capability > > > checks used to be silent (no auditing) since they occur on netlink recv, > > > but a recent patch has enabled SELinux to generate audit messages on the > > > netlink recv capability checks. So we can expect these types of denials > > > to show up now. Should be allowed in this case. > > > > So it's generating an audit message, because it wasn't allowed to > > generate an audit message? > > > > I've only had half a beer... > > > > -- > > ======================================================================== > > Ian Pilcher i.pilcher at comcast.net > > ======================================================================== > > > A slight side question: > > hwclock seems to be producing audit messages either before or after > auditd has started/exited. I see a message on shutdown, but it appears > not to be logged anywhere. > > Does that meet auditing requirements? Something to ask over on linux-audit, not here. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Jul 10 21:03:29 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 10 Jul 2006 17:03:29 -0400 Subject: [ANN] SELinux Policy Editor 2.0(seedit 2.0) In-Reply-To: <20060706152929.dcab61db.ynakam@gwu.edu> References: <20060706152929.dcab61db.ynakam@gwu.edu> Message-ID: <1152565409.29240.25.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-07-06 at 15:29 -0400, Yuichi Nakamura wrote: > Hi. > > I am glad to announce that SELinux Policy Editor 2.0(seedit 2.0) has been released. > seedit is a tool to make SELinux easy. > We have renewed the tool. Almost everything have been changed. > Policy generator, new GUI are developed, and many others. > You can download and try it from > http://seedit.sourceforge.net > Manuals are also provided. > It supports Fedora Core 5 and Cent OS 4. > > If you have question, please feel free to contact me. What are your plans for modular policy support? In the absence of it, using your tool/policy on FC5 will disable the ability to use policy modules and semanage on FC5, which would be a regression for users and may break some packages that are beginning to leverage the semodule and semanage functionality. > allownet -protocol tcp -port 80 server. Be aware that the old network controls are being superseded by the new secmark functionalty, so you will need to rework your tool to generate the new allow...:packet { send recv} rules and to generate iptables rules for marking the packets appropriately for 2.6.18 and later, unless you enable compatibility mode for the old checks. -- Stephen Smalley National Security Agency From ynakam at gwu.edu Tue Jul 11 04:32:34 2006 From: ynakam at gwu.edu (Yuichi Nakamura) Date: Tue, 11 Jul 2006 00:32:34 -0400 Subject: [ANN] SELinux Policy Editor 2.0(seedit 2.0) In-Reply-To: <1152565409.29240.25.camel@moss-spartans.epoch.ncsc.mil> References: <20060706152929.dcab61db.ynakam@gwu.edu> <1152565409.29240.25.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Mon, 10 Jul 2006 17:03:29 -0400 Stephen Smalley wrote: > What are your plans for modular policy support? In the absence of it, > using your tool/policy on FC5 will disable the ability to use policy > modules and semanage on FC5, which would be a regression for users and > may break some packages that are beginning to leverage the semodule and > semanage functionality. I have two plans. 1) Full Simplified Policy, no modular policy This is current version. Whole policy is replaced by simplified policy, generated policy is monolithic. What I want do is AppArmor-like configuration(security enhanced AppArmor??). I think I do not need modular policy for that use. semanage, semodule commands,APIs are not used in current version. 2) Appendable simplified policy, modular policy support It exists only in my head.. Simplified policy for one domain is converted into .pp file, and loadable to existing policy. It will take time, because I have been spending time for 1). > Be aware that the old network controls are being superseded by the new > secmark functionalty, so you will need to rework your tool to generate > the new allow...:packet { send recv} rules and to generate iptables > rules for marking the packets appropriately for 2.6.18 and later, unless > you enable compatibility mode for the old checks. Thanks for information. I will support both. Yuichi Nakamura From sds at tycho.nsa.gov Tue Jul 11 11:48:13 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 11 Jul 2006 07:48:13 -0400 Subject: [ANN] SELinux Policy Editor 2.0(seedit 2.0) In-Reply-To: References: <20060706152929.dcab61db.ynakam@gwu.edu> <1152565409.29240.25.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1152618493.29240.87.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-07-11 at 00:32 -0400, Yuichi Nakamura wrote: > On Mon, 10 Jul 2006 17:03:29 -0400 > Stephen Smalley wrote: > > What are your plans for modular policy support? In the absence of it, > > using your tool/policy on FC5 will disable the ability to use policy > > modules and semanage on FC5, which would be a regression for users and > > may break some packages that are beginning to leverage the semodule and > > semanage functionality. > I have two plans. > > 1) Full Simplified Policy, no modular policy > This is current version. > Whole policy is replaced by simplified policy, generated policy is > monolithic. > What I want do is AppArmor-like configuration(security enhanced AppArmor??). > I think I do not need modular policy for that use. > semanage, semodule commands,APIs are not used in current version. You might not be using semanage and semodule from your own tools, but users are using them already in FC5 and packages are beginning to use them as well from scriptlets in order to install per-package policy or apply other package-specific customizations. Hence, switching to using seedit will break such usage. It shouldn't be difficult for you to just build your simplified policy as a base policy module using checkmodule and install it via semodule, in the same manner as the stock FC5 selinux-policy package. Then users and packages can continue using semodule and semanage. -- Stephen Smalley National Security Agency From linux_4ever at yahoo.com Tue Jul 11 14:23:08 2006 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 11 Jul 2006 07:23:08 -0700 (PDT) Subject: Latest kernel (2356), avc's on hwclock In-Reply-To: <1152562290.29240.3.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20060711142308.89033.qmail@web51504.mail.yahoo.com> >> Does that meet auditing requirements? Yes it does. During shutdown and startup it can be argued that the system is doing its normal housekeeping. What is of interest is changes to the hwclock during the time that the system is able to be logged into by users. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From stuart at secpay.com Tue Jul 11 15:40:20 2006 From: stuart at secpay.com (Stuart James) Date: Tue, 11 Jul 2006 16:40:20 +0100 Subject: Openswan on FC4/5 In-Reply-To: <20060627144629.7d07673f@stuart.ripon.secpay.com> References: <20060626092226.7ab61183@stuart.ripon.secpay.com> <20060627124822.47e0c08d@stuart.ripon.secpay.com> <20060627144629.7d07673f@stuart.ripon.secpay.com> Message-ID: <20060711164020.372c05d8@stuart.ripon.secpay.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 27 Jun 2006 14:46:29 +0100 Stuart James wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Hi, > > > > > > We are using Openswan to connect two of our sites together via an > > > IPSEC tunnel. Recently we upgraded from FC3 to FC5 on our frontend > > > firewalls, including the version of openswan , selinux policy, > > > kernel ,ect. We used to run in enforcing mode without any > > > difficulties, it now seems that with Enforcing mode on Openswan > > > does not seem to be able to add the route. > > > > > > Using setenforce 0 , the tunnel becomes active. As far as i can > > > tell Openswan has difficulty adding the route to the Right/Left > > > nexthop, although the status of the tunnel appears to be up, the > > > routing does not appear to take place. > > > > > > #audit2allow -a -t /var/log/audit/audit.log > > > allow ifconfig_t self:netlink_xfrm_socket create; > > > allow ifconfig_t initrc_t:unix_stream_socket { read write }; > > > > I've followed this up in more detail, adding to > > /usr/src/redhat/SOURCES/serefpolicy-2.2.43/policy/modules/system/sysnetwork.te > > > > # IPsec > > allow ifconfig_t self:netlink_xfrm_socket create; > > allow ifconfig_t initrc_t:unix_stream_socket { read write }; > > allow ifconfig_t self:netlink_xfrm_socket setopt; > > allow ifconfig_t initrc_t:udp_socket { read write }; > > allow ifconfig_t self:netlink_xfrm_socket { bind setopt }; > > allow ifconfig_t self:netlink_xfrm_socket bind; > > allow ifconfig_t self:netlink_xfrm_socket read; > > allow ifconfig_t self:netlink_xfrm_socket { bind getattr }; > > allow ifconfig_t self:netlink_xfrm_socket { bind getattr write }; > > allow ifconfig_t self:netlink_xfrm_socket { bind getattr nlmsg_read > > write }; > > > > These rules seem to work now. > > # IPSEC (openswan-2.4.x) allow traceroute_t initrc_t:rawip_socket { read write }; allow traceroute_t initrc_t:udp_socket { read write }; allow traceroute_t user_home_dir_t:dir search; allow ifconfig_t self:netlink_xfrm_socket create; allow ifconfig_t initrc_t:unix_stream_socket { read write }; allow ifconfig_t self:netlink_xfrm_socket setopt; allow ifconfig_t initrc_t:udp_socket { read write }; allow ifconfig_t self:netlink_xfrm_socket { bind setopt }; allow ifconfig_t self:netlink_xfrm_socket bind; allow ifconfig_t self:netlink_xfrm_socket read; allow ifconfig_t self:netlink_xfrm_socket { bind getattr }; allow ifconfig_t self:netlink_xfrm_socket { bind getattr write }; allow ifconfig_t self:netlink_xfrm_socket { bind getattr nlmsg_read write }; allow ifconfig_t self:netlink_xfrm_socket { nlmsg_write read }; allow ifconfig_t unconfined_t:udp_socket { read write }; allow unlabeled_t self:association sendto; allow unlabeled_t self:association recvfrom; Regards, - -- Stuart James System Administrator DDI - (44) 0 1765 643354 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEs8Znr8LwOCpshrYRAsy/AKC777P7eAugVKSer5Qlh6WFgsyDdQCeNyyp 6xAQw09KvJ92wtidicpJqhg= =+sXV -----END PGP SIGNATURE----- From paul at city-fan.org Tue Jul 11 18:27:29 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 11 Jul 2006 19:27:29 +0100 Subject: openvpn Message-ID: <1152642450.3135.2.camel@laurel.intra.city-fan.org> Openvpn was working OK with FC5 originally, but with the recent changes I've had to add additional rules: policy_module(myopenvpn, 0.1.4) ######################################## # # Declarations # require { type openvpn_t; } ######################################## # # Local policy # # Need to interact with terminals if config option "auth-user-pass" is used term_use_generic_ptys(openvpn_t) dev_search_sysfs(openvpn_t) kernel_read_kernel_sysctls(openvpn_t) sysnet_dns_name_resolve(openvpn_t) allow openvpn_t self:netlink_route_socket { rw_netlink_socket_perms }; It's now working for me again without AVCs being reported, and better still, no hard lockups when trying to start/stop the service :-) Paul. From paul at city-fan.org Wed Jul 12 07:29:53 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 12 Jul 2006 08:29:53 +0100 Subject: SELinux protect my squid using havp as parent proxy In-Reply-To: <44B45F94.40402@rg.co.id> References: <44B45F94.40402@rg.co.id> Message-ID: <1152689393.2873.5.camel@laurel.intra.city-fan.org> On Wed, 2006-07-12 at 09:33 +0700, Lutfi wrote: > After upgrade to FC5, my squid cannot using havp (localhost:8080) as > parent proxy anymore. The audit log msg is here: > > ===> /var/log/audit/audit.log > type=AVC msg=audit(1152671338.823:21775): avc: denied > { name_connect } for pid=2371 comm="squid" dest=8080 > scontext=system_u:system_r:squid_t:s0 > tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket > type=SYSCALL msg=audit(1152671338.823:21775): arch=40000003 > syscall=102 success=no exit=-13 a0=3 a1=bf9eb1a0 a2=52e1c4 a3=b7f1ca2c > items=0 pid=2371 auid=4294967295 uid=23 gid=23 euid=23 suid=0 fsuid=23 > egid=23 sgid=23 fsgid=23 tty=(none) comm="squid" exe="/usr/sbin/squid" > subj=system_u:system_r:squid_t:s0 > type=SOCKADDR msg=audit(1152671338.823:21775): > saddr=02001F907F0000010000000000000000 > type=SOCKETCALL msg=audit(1152671338.823:21775): nargs=3 a0=12 > a1=bbdd8f8 a2=10 > > How to fix this? Thx This is off-topic for fedora-extras-list. Please address any followups to fedora-selinux-list, where the right people will see it to get the problem fixed in the next selinux-policy update. I have fixed this problem here using a local policy module: policy_module(localmisc, 0.1.0) require { type squid_t; }; # Squid doing what comes naturally? WTF? corenet_tcp_connect_http_cache_port(squid_t) corenet_tcp_sendrecv_http_cache_port(squid_t) Paul. From method at gentoo.org Wed Jul 12 12:37:17 2006 From: method at gentoo.org (Joshua Brindle) Date: Wed, 12 Jul 2006 08:37:17 -0400 Subject: SELinux protect my squid using havp as parent proxy In-Reply-To: <1152689393.2873.5.camel@laurel.intra.city-fan.org> References: <44B45F94.40402@rg.co.id> <1152689393.2873.5.camel@laurel.intra.city-fan.org> Message-ID: <44B4ECFD.8080305@gentoo.org> Paul Howarth wrote: > On Wed, 2006-07-12 at 09:33 +0700, Lutfi wrote: > >> After upgrade to FC5, my squid cannot using havp (localhost:8080) as >> parent proxy anymore. The audit log msg is here: >> >> ===> /var/log/audit/audit.log >> type=AVC msg=audit(1152671338.823:21775): avc: denied >> { name_connect } for pid=2371 comm="squid" dest=8080 >> scontext=system_u:system_r:squid_t:s0 >> tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket >> type=SYSCALL msg=audit(1152671338.823:21775): arch=40000003 >> syscall=102 success=no exit=-13 a0=3 a1=bf9eb1a0 a2=52e1c4 a3=b7f1ca2c >> items=0 pid=2371 auid=4294967295 uid=23 gid=23 euid=23 suid=0 fsuid=23 >> egid=23 sgid=23 fsgid=23 tty=(none) comm="squid" exe="/usr/sbin/squid" >> subj=system_u:system_r:squid_t:s0 >> type=SOCKADDR msg=audit(1152671338.823:21775): >> saddr=02001F907F0000010000000000000000 >> type=SOCKETCALL msg=audit(1152671338.823:21775): nargs=3 a0=12 >> a1=bbdd8f8 a2=10 >> >> How to fix this? Thx >> > > This is off-topic for fedora-extras-list. Please address any followups > to fedora-selinux-list, where the right people will see it to get the > problem fixed in the next selinux-policy update. > > I have fixed this problem here using a local policy module: > > policy_module(localmisc, 0.1.0) > > require { > type squid_t; > }; > > # Squid doing what comes naturally? WTF? > corenet_tcp_connect_http_cache_port(squid_t) > corenet_tcp_sendrecv_http_cache_port(squid_t) > > Ah, the real disadvantage of modules comes out.. hopefully policy issues like these will be referred to refpolicy upstream as well, so that the mainline policy can be fixed and not just this persons local setup... From paul at city-fan.org Wed Jul 12 13:23:32 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 12 Jul 2006 14:23:32 +0100 Subject: SELinux protect my squid using havp as parent proxy In-Reply-To: <44B4ECFD.8080305@gentoo.org> References: <44B45F94.40402@rg.co.id> <1152689393.2873.5.camel@laurel.intra.city-fan.org> <44B4ECFD.8080305@gentoo.org> Message-ID: <44B4F7D4.70809@city-fan.org> Joshua Brindle wrote: > Paul Howarth wrote: >> On Wed, 2006-07-12 at 09:33 +0700, Lutfi wrote: >> >>> After upgrade to FC5, my squid cannot using havp (localhost:8080) as >>> parent proxy anymore. The audit log msg is here: >>> >>> ===> /var/log/audit/audit.log >>> type=AVC msg=audit(1152671338.823:21775): avc: denied >>> { name_connect } for pid=2371 comm="squid" dest=8080 >>> scontext=system_u:system_r:squid_t:s0 >>> tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket >>> type=SYSCALL msg=audit(1152671338.823:21775): arch=40000003 >>> syscall=102 success=no exit=-13 a0=3 a1=bf9eb1a0 a2=52e1c4 a3=b7f1ca2c >>> items=0 pid=2371 auid=4294967295 uid=23 gid=23 euid=23 suid=0 fsuid=23 >>> egid=23 sgid=23 fsgid=23 tty=(none) comm="squid" exe="/usr/sbin/squid" >>> subj=system_u:system_r:squid_t:s0 >>> type=SOCKADDR msg=audit(1152671338.823:21775): >>> saddr=02001F907F0000010000000000000000 >>> type=SOCKETCALL msg=audit(1152671338.823:21775): nargs=3 a0=12 >>> a1=bbdd8f8 a2=10 >>> >>> How to fix this? Thx >>> >> >> This is off-topic for fedora-extras-list. Please address any followups >> to fedora-selinux-list, where the right people will see it to get the >> problem fixed in the next selinux-policy update. >> >> I have fixed this problem here using a local policy module: >> >> policy_module(localmisc, 0.1.0) >> >> require { >> type squid_t; >> }; >> >> # Squid doing what comes naturally? WTF? >> corenet_tcp_connect_http_cache_port(squid_t) >> corenet_tcp_sendrecv_http_cache_port(squid_t) >> >> > Ah, the real disadvantage of modules comes out.. hopefully policy issues > like these will be referred to refpolicy upstream as well, so that the > mainline policy can be fixed and not just this persons local setup... This is why I CC'ed the reply to fedora-selinux-list where I know Dan will see it and it'll get pushed upstream if I haven't suggested something silly. Paul. From lmespinoza at frutex.net Wed Jul 12 16:13:17 2006 From: lmespinoza at frutex.net (Luis Miguel Espinoza) Date: Wed, 12 Jul 2006 10:13:17 -0600 Subject: PROBLEM RUNNING CGI IN APACHE, FEDORA 3 Message-ID: <309218F0-34F2-44C1-883C-699ED2823C70@frutex.net> Hello people, I hope someone can help me with this problem. I have FEDORA CORE 3 with: - selinux-policy-targeted-1.17.30-3.19 - httpd-2.2.2 - changepassword-0.9.tar.gz When I access "var/www/cgi-bin/changepassword.cgi" program and try to change squid passwords, SELINUX security send to the console some errrors as that: Jul 10 13:48:19 proxy kernel: audit(1152560899.793:2): avc: denied { read } for pid=4004 comm="changepassword." name="shadow" dev=hda2 ino=1166230 scontext=root:system_r:httpd_sys_script_t tcontext=system_u:object_r:shadow_t tclass=file Jul 10 13:48:19 proxy kernel: audit(1152560899.793:3): avc: denied { getattr } for pid=4004 comm="changepassword." name="shadow" dev=hda2 ino=1166230 scontext=root:system_r:httpd_sys_script_t tcontext=system_u:object_r:shadow_t tclass=file I did ran the selinux command: [root at proxy ~]# audit2allow -i /var/log/messages allow httpd_sys_script_t shadow_t:file { getattr read }; allow httpd_t httpd_sys_script_t:process { noatsecure rlimitinh siginh }; allow httpd_t nscd_var_run_t:dir search; allow snmpd_t selinux_config_t:file { getattr read }; allow snmpd_t self:process execmem; allow squid_t boot_t:dir getattr; allow squid_t home_root_t:dir getattr; allow squid_t nscd_var_run_t:dir search; allow syslogd_t root_t:file read; I add thats security lines to domains/program/apache.te I add that security lines to policy/policy.conf , but anything is working. I was reading some post of other mailing list, and some ones say that I must to change apache.te, , others say that I must to create into misc/local.te and add that lines, but anything can fix my problem. I run again audit2allow -i /var/log/messages and I get same messages. I run " make load" command and "reboot", but i can't get "changepassword application" do change my squid users password across website. Can some help me about that??? Luis Miguel Espinoza lmespinoza at frutex.net IT Frutex S.A -------------- next part -------------- An HTML attachment was scrubbed... URL: From phaceton at gmail.com Wed Jul 12 21:55:38 2006 From: phaceton at gmail.com (netpython) Date: Wed, 12 Jul 2006 23:55:38 +0200 Subject: error Message-ID: <3655f5d90607121455i2ab8d156k29f256aac23afb05@mail.gmail.com> i get the following error: What doe this Duplicate declaration mean? make -f /usr/share/selinux/devel/Makefile Compiling targeted firefox module /usr/bin/checkmodule: loading policy configuration from tmp/firefox.tmp /usr/bin/checkmodule: policy configuration loaded /usr/bin/checkmodule: writing binary representation (version 5) to tmp/firefox.mod Creating targeted firefox.pp policy package rm tmp/firefox.mod.fc tmp/firefox.mod [root at ph devel]# semodule -i firefox.pp libsepol.scope_copy_callback: firefox: Duplicate declaration in module: type/attribute proc_t libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! the firefox.te file is: policy_module(firefox,1.0.0) ######################################## # # Declarations # type xdm_t; type proc_t; type home_root_t; type bin_t; type firefox_t; type firefox_exec_t; domain_type(firefox_t) init_daemon_domain(firefox_t, firefox_exec_t) ######################################## # # firefox local policy # # Check in /etc/selinux/refpolicy/include for macros to use instead of allow rules. # Some common macros (you might be able to remove some) # Some common macros (you might be able to remove some) files_read_etc_files(firefox_t) libs_use_ld_so(firefox_t) libs_use_shared_libs(firefox_t) miscfiles_read_localization(firefox_t) ## internal communication is often done using fifo and unix sockets. allow firefox_t self:fifo_file { read write }; allow firefox_t self:unix_stream_socket create_stream_socket_perms; allow firefox_t bin_t:dir search; allow firefox_t home_root_t:dir search; allow firefox_t proc_t:dir search; #allow firefox_t xdm_t:fd use; -- I have made this letter longer than usual, because i lack the time to make it short. From method at gentoo.org Wed Jul 12 22:01:29 2006 From: method at gentoo.org (Joshua Brindle) Date: Wed, 12 Jul 2006 18:01:29 -0400 Subject: error In-Reply-To: <3655f5d90607121455i2ab8d156k29f256aac23afb05@mail.gmail.com> References: <3655f5d90607121455i2ab8d156k29f256aac23afb05@mail.gmail.com> Message-ID: <44B57139.1080501@gentoo.org> netpython wrote: > i get the following error: > What doe this Duplicate declaration mean? > > make -f /usr/share/selinux/devel/Makefile > Compiling targeted firefox module > /usr/bin/checkmodule: loading policy configuration from tmp/firefox.tmp > /usr/bin/checkmodule: policy configuration loaded > /usr/bin/checkmodule: writing binary representation (version 5) to > tmp/firefox.mod > Creating targeted firefox.pp policy package > rm tmp/firefox.mod.fc tmp/firefox.mod > [root at ph devel]# semodule -i firefox.pp > libsepol.scope_copy_callback: firefox: Duplicate declaration in > module: type/attribute proc_t > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! > > the firefox.te file is: > > policy_module(firefox,1.0.0) > > ######################################## > # > # Declarations > # > type xdm_t; > type proc_t; > type home_root_t; > type bin_t; > type firefox_t; > type firefox_exec_t; you probably meant to require xdm, proc, home_root and bin, like this require { type xdm_t, proc_t, home_root_t, bin_t; } otherwise you are trying to declare them and they've already been declared in base. However, in refpolicy you should never have to declare types since the interface calls you make will bring them in, requiring xdm_t manually is breaking the encapsulation around the xdm policy, you'll want to find an xdm interface call that does what you want. From dwalsh at redhat.com Thu Jul 13 14:09:38 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 13 Jul 2006 10:09:38 -0400 Subject: SELinux protect my squid using havp as parent proxy In-Reply-To: <44B4F7D4.70809@city-fan.org> References: <44B45F94.40402@rg.co.id> <1152689393.2873.5.camel@laurel.intra.city-fan.org> <44B4ECFD.8080305@gentoo.org> <44B4F7D4.70809@city-fan.org> Message-ID: <44B65422.7010309@redhat.com> Paul Howarth wrote: > Joshua Brindle wrote: >> Paul Howarth wrote: >>> On Wed, 2006-07-12 at 09:33 +0700, Lutfi wrote: >>> >>>> After upgrade to FC5, my squid cannot using havp (localhost:8080) as >>>> parent proxy anymore. The audit log msg is here: >>>> >>>> ===> /var/log/audit/audit.log >>>> type=AVC msg=audit(1152671338.823:21775): avc: denied >>>> { name_connect } for pid=2371 comm="squid" dest=8080 >>>> scontext=system_u:system_r:squid_t:s0 >>>> tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket >>>> type=SYSCALL msg=audit(1152671338.823:21775): arch=40000003 >>>> syscall=102 success=no exit=-13 a0=3 a1=bf9eb1a0 a2=52e1c4 a3=b7f1ca2c >>>> items=0 pid=2371 auid=4294967295 uid=23 gid=23 euid=23 suid=0 fsuid=23 >>>> egid=23 sgid=23 fsgid=23 tty=(none) comm="squid" exe="/usr/sbin/squid" >>>> subj=system_u:system_r:squid_t:s0 >>>> type=SOCKADDR msg=audit(1152671338.823:21775): >>>> saddr=02001F907F0000010000000000000000 >>>> type=SOCKETCALL msg=audit(1152671338.823:21775): nargs=3 a0=12 >>>> a1=bbdd8f8 a2=10 >>>> >>>> How to fix this? Thx >>>> >>> >>> This is off-topic for fedora-extras-list. Please address any followups >>> to fedora-selinux-list, where the right people will see it to get the >>> problem fixed in the next selinux-policy update. >>> >>> I have fixed this problem here using a local policy module: >>> >>> policy_module(localmisc, 0.1.0) >>> >>> require { >>> type squid_t; >>> }; >>> >>> # Squid doing what comes naturally? WTF? >>> corenet_tcp_connect_http_cache_port(squid_t) >>> corenet_tcp_sendrecv_http_cache_port(squid_t) >>> >>> >> Ah, the real disadvantage of modules comes out.. hopefully policy >> issues like these will be referred to refpolicy upstream as well, so >> that the mainline policy can be fixed and not just this persons local >> setup... > > This is why I CC'ed the reply to fedora-selinux-list where I know Dan > will see it and it'll get pushed upstream if I haven't suggested > something silly. > Already updated upstream policy. Thanks Paul > Paul. > > -- > 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 Jul 13 14:16:22 2006 From: selinux at gmail.com (Tom London) Date: Thu, 13 Jul 2006 07:16:22 -0700 Subject: useradd - audit_write ? Message-ID: <4c4ba1530607130716n168fbb26kd21a6856e20de878@mail.gmail.com> Running selinux-policy-2.3.2-1 targeted/permissive. Doing my usual 'yum update' of yesterday's rawhide (including selinux-policy-2.3.2-2), I noticed this in audit log: type=AVC msg=audit(1152799768.153:34): avc: denied { audit_write } for pid=3084 comm="useradd" capability=29 scontext=user_u:system_r:useradd_t:s0 tcontext=user_u:system_r:useradd_t:s0 tclass=capability type=USER_CHAUTHTOK msg=audit(1152799768.153:35): user pid=3084 uid=0 auid=500 subj=user_u:system_r:useradd_t:s0 msg='op=adding user acct=dbus exe="/usr/sbin/useradd" (hostname=?, addr=?, terminal=pts/0 res=failed)' type=SYSCALL msg=audit(1152799768.153:34): arch=40000003 syscall=102 success=yes exit=116 a0=b a1=bf95a240 a2=6ecff4 a3=bf96068e items=0 ppid=3083 pid=3084 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=user_u:system_r:useradd_t:s0 key=(null) type=SOCKADDR msg=audit(1152799768.153:34): saddr=100000000000000000000000 type=SOCKETCALL msg=audit(1152799768.153:34): nargs=6 a0=3 a1=bf95e4dc a2=74 a3=0 a4=bf95a270 a5=c tom -- Tom London From sds at tycho.nsa.gov Thu Jul 13 14:22:06 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 13 Jul 2006 10:22:06 -0400 Subject: useradd - audit_write ? In-Reply-To: <4c4ba1530607130716n168fbb26kd21a6856e20de878@mail.gmail.com> References: <4c4ba1530607130716n168fbb26kd21a6856e20de878@mail.gmail.com> Message-ID: <1152800526.10075.280.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-07-13 at 07:16 -0700, Tom London wrote: > Running selinux-policy-2.3.2-1 targeted/permissive. > > Doing my usual 'yum update' of yesterday's rawhide (including > selinux-policy-2.3.2-2), I noticed this in audit log: > > type=AVC msg=audit(1152799768.153:34): avc: denied { audit_write } > for pid=3084 comm="useradd" capability=29 > scontext=user_u:system_r:useradd_t:s0 > tcontext=user_u:system_r:useradd_t:s0 tclass=capability > type=USER_CHAUTHTOK msg=audit(1152799768.153:35): user pid=3084 uid=0 > auid=500 subj=user_u:system_r:useradd_t:s0 msg='op=adding user > acct=dbus exe="/usr/sbin/useradd" (hostname=?, addr=?, terminal=pts/0 > res=failed)' > type=SYSCALL msg=audit(1152799768.153:34): arch=40000003 syscall=102 > success=yes exit=116 a0=b a1=bf95a240 a2=6ecff4 a3=bf96068e items=0 > ppid=3083 pid=3084 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=user_u:system_r:useradd_t:s0 key=(null) > type=SOCKADDR msg=audit(1152799768.153:34): saddr=100000000000000000000000 > type=SOCKETCALL msg=audit(1152799768.153:34): nargs=6 a0=3 a1=bf95e4dc > a2=74 a3=0 a4=bf95a270 a5=c Yes, another program instrumented for audit generation, needs that capability. Why wasn't this taken care of when these programs were originally instrumented for audit? (We are only now getting audit denials due to the netlink capability checking patch that went into recent kernels, but this would have been getting denied all along, so I would have expected it to show up in testing). -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Jul 13 14:24:23 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 13 Jul 2006 10:24:23 -0400 Subject: useradd - audit_write ? In-Reply-To: <1152800526.10075.280.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba1530607130716n168fbb26kd21a6856e20de878@mail.gmail.com> <1152800526.10075.280.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <44B65797.8010207@redhat.com> Stephen Smalley wrote: > On Thu, 2006-07-13 at 07:16 -0700, Tom London wrote: > >> Running selinux-policy-2.3.2-1 targeted/permissive. >> >> Doing my usual 'yum update' of yesterday's rawhide (including >> selinux-policy-2.3.2-2), I noticed this in audit log: >> >> type=AVC msg=audit(1152799768.153:34): avc: denied { audit_write } >> for pid=3084 comm="useradd" capability=29 >> scontext=user_u:system_r:useradd_t:s0 >> tcontext=user_u:system_r:useradd_t:s0 tclass=capability >> type=USER_CHAUTHTOK msg=audit(1152799768.153:35): user pid=3084 uid=0 >> auid=500 subj=user_u:system_r:useradd_t:s0 msg='op=adding user >> acct=dbus exe="/usr/sbin/useradd" (hostname=?, addr=?, terminal=pts/0 >> res=failed)' >> type=SYSCALL msg=audit(1152799768.153:34): arch=40000003 syscall=102 >> success=yes exit=116 a0=b a1=bf95a240 a2=6ecff4 a3=bf96068e items=0 >> ppid=3083 pid=3084 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=user_u:system_r:useradd_t:s0 key=(null) >> type=SOCKADDR msg=audit(1152799768.153:34): saddr=100000000000000000000000 >> type=SOCKETCALL msg=audit(1152799768.153:34): nargs=6 a0=3 a1=bf95e4dc >> a2=74 a3=0 a4=bf95a270 a5=c >> > > Yes, another program instrumented for audit generation, needs that > capability. Why wasn't this taken care of when these programs were > originally instrumented for audit? (We are only now getting audit > denials due to the netlink capability checking patch that went into > recent kernels, but this would have been getting denied all along, so I > would have expected it to show up in testing). > > Testing in permissive mode I guess. From linux_4ever at yahoo.com Thu Jul 13 14:26:17 2006 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 13 Jul 2006 07:26:17 -0700 (PDT) Subject: useradd - audit_write ? In-Reply-To: <1152800526.10075.280.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20060713142617.90647.qmail@web51502.mail.yahoo.com> >Yes, another program instrumented for audit generation, needs that >capability. There's a lot of them. Someone needs to look at all the places where CAP_AUDIT_WRITE and CONTROL were and update the policy. This broke about 2-3 weeks ago. This stuff used to work. >Why wasn't this taken care of when these programs were originally >instrumented for audit? They were. Something broke a couple weeks ago. Look back when someone reported the hwclock problem. That's when all this occurred. I thought it would have been fixed, too. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From selinux at gmail.com Thu Jul 13 14:33:37 2006 From: selinux at gmail.com (Tom London) Date: Thu, 13 Jul 2006 07:33:37 -0700 Subject: useradd - audit_write ? In-Reply-To: <20060713142617.90647.qmail@web51502.mail.yahoo.com> References: <1152800526.10075.280.camel@moss-spartans.epoch.ncsc.mil> <20060713142617.90647.qmail@web51502.mail.yahoo.com> Message-ID: <4c4ba1530607130733q5283dcfeg30d75814e1008806@mail.gmail.com> On 7/13/06, Steve G wrote: > > > >Yes, another program instrumented for audit generation, needs that > >capability. > > There's a lot of them. Someone needs to look at all the places where > CAP_AUDIT_WRITE and CONTROL were and update the policy. This broke about 2-3 > weeks ago. This stuff used to work. > > >Why wasn't this taken care of when these programs were originally > >instrumented for audit? > > They were. Something broke a couple weeks ago. Look back when someone reported > the hwclock problem. That's when all this occurred. I thought it would have been > fixed, too. > > -Steve > Also one for groupadd: type=AVC msg=audit(1152800976.477:60): avc: denied { audit_write } for pid=5737 comm="groupadd" capability=29 scontext=user_u:system_r:groupadd_t:s0 tcontext=user_u:system_r:groupadd_t:s0 tclass=capability type=USER_CHAUTHTOK msg=audit(1152800976.477:61): user pid=5737 uid=0 auid=500 subj=user_u:system_r:groupadd_t:s0 msg='op=adding group acct=rpm exe="/usr/sbin/groupadd" (hostname=?, addr=?, terminal=? res=failed)' type=SYSCALL msg=audit(1152800976.477:60): arch=40000003 syscall=102 success=yes exit=112 a0=b a1=bfaf66e0 a2=6ecff4 a3=bfafcb2e items=0 ppid=5736 pid=5737 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="groupadd" exe="/usr/sbin/groupadd" subj=user_u:system_r:groupadd_t:s0 key=(null) type=SOCKADDR msg=audit(1152800976.477:60): saddr=100000000000000000000000 type=SOCKETCALL msg=audit(1152800976.477:60): nargs=6 a0=3 a1=bfafa97c a2=70 a3=0 a4=bfaf6710 a5=c -- Tom London From dwalsh at redhat.com Thu Jul 13 14:45:02 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 13 Jul 2006 10:45:02 -0400 Subject: SeLinux and mail relaying In-Reply-To: <4A523356-66FF-43B3-8054-47DF0512AA12@bellsouth.net> References: <63DD9642-13DD-4A47-9092-36C3508BACDD@bellsouth.net> <1152517760.10312.58.camel@laurel.intra.city-fan.org> <4A523356-66FF-43B3-8054-47DF0512AA12@bellsouth.net> Message-ID: <44B65C6E.6050504@redhat.com> redhatdude at bellsouth.net wrote: >> >> On Jul 10, 2006, at 3:49 AM, Paul Howarth wrote: >> >>> On Fri, 2006-07-07 at 16:34 -0400, redhatdude at bellsouth.net wrote: >>>> Hi, >>>> While trying to set up a mail cgi script, I discovered that Selinux >>>> is not allowing relaying mail from anything but postfix. I realized >>>> this when I turned off selinux and I started getting the result of >>>> cron jobs and other similar system emails. >>>> So my question is , how can I make selinux allow programs other than >>>> postfix and cyrus to relay emails? >>> >>> Can you post the AVC messages you are getting when mail from cron is >>> being blocked by SELinux? >>> >>> Paul. >>> >> > Hi, > Here it is. > Thanks for you help. > EJ > Sorry I was away on Vacation. > type=AVC_PATH msg=audit(1152547081.207:3467): > path="/var/lib/imap/socket/lmtp" > type=SOCKADDR msg=audit(1152547081.207:3467): > saddr=01002F7661722F6C69622F696D61702F736F636B65742F6C6D74700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > > type=SOCKETCALL msg=audit(1152547081.207:3467): nargs=3 a0=b > a1=bfc966ec a2=6e > type=PATH msg=audit(1152547081.207:3467): item=0 name=(null) > inode=8585327 dev=fd:00 mode=0140777 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:cyrus_var_lib_t:s0 > type=AVC msg=audit(1152547081.303:3468): avc: denied { connectto } > for pid=31220 comm="lmtp" name="lmtp" > scontext=system_u:system_r:postfix_master_t:s0 > tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket > type=SYSCALL msg=audit(1152547081.303:3468): arch=40000003 syscall=102 > success=no exit=-13 a0=3 a1=bffc5900 a2=f8e430 a3=f90c24 items=1 > pid=31220 auid=4294967295 uid=89 gid=89 euid=89 suid=89 fsuid=89 > egid=89 sgid=89 fsgid=89 tty=(none) comm="lmtp" > exe="/usr/libexec/postfix/lmtp" > subj=system_u:system_r:postfix_master_t:s0 > type=AVC_PATH msg=audit(1152547081.303:3468): > path="/var/lib/imap/socket/lmtp" I am not sure what lmtp is but is looks like it does not have a domain around it so you will probably need to add this rule, > type=SOCKADDR msg=audit(1152547081.303:3468): > saddr=01002F7661722F6C69622F696D61702F736F636B65742F6C6D74700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > > type=SOCKETCALL msg=audit(1152547081.303:3468): nargs=3 a0=b > a1=bffc5a1c a2=6e > type=PATH msg=audit(1152547081.303:3468): item=0 name=(null) > inode=8585327 dev=fd:00 mode=0140777 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:cyrus_var_lib_t:s0 > > This is the message I get when I try to run a mail form cgi script, > which is why I realized that I was having problems with my system > sending mail. > > type=AVC msg=audit(1152547494.882:3475): avc: denied { getattr } > for pid=31270 comm="postdrop" name="[165322]" dev=pipefs ino=165322 > scontext=user_u:system_r:postfix_postdrop_t:s0 > tcontext=user_u:system_r:httpd_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1152547494.882:3475): arch=40000003 syscall=197 > success=no exit=-13 a0=2 a1=bfa6d7c0 a2=50aff4 a3=3 items=0 pid=31270 > auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=90 sgid=90 > fsgid=90 tty=(none) comm="postdrop" exe="/usr/sbin/postdrop" > subj=user_u:system_r:postfix_postdrop_t:s0 > type=AVC_PATH msg=audit(1152547494.882:3475): path="pipe:[165322]" not sure why postdrop wants to talk to a fifo file owned by apache? > type=AVC msg=audit(1152547495.010:3476): avc: denied { connectto } > for pid=31274 comm="lmtp" name="lmtp" > scontext=system_u:system_r:postfix_master_t:s0 > tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket > type=SYSCALL msg=audit(1152547495.010:3476): arch=40000003 syscall=102 > success=no exit=-13 a0=3 a1=bffb50f0 a2=4b1430 a3=4b3c24 items=1 > pid=31274 auid=4294967295 uid=89 gid=89 euid=89 suid=89 fsuid=89 > egid=89 sgid=89 fsgid=89 tty=(none) comm="lmtp" > exe="/usr/libexec/postfix/lmtp" > subj=system_u:system_r:postfix_master_t:s0 > type=AVC_PATH msg=audit(1152547495.010:3476): > path="/var/lib/imap/socket/lmtp" > type=SOCKADDR msg=audit(1152547495.010:3476): > saddr=01002F7661722F6C69622F696D61702F736F636B65742F6C6D74700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > > type=SOCKETCALL msg=audit(1152547495.010:3476): nargs=3 a0=b > a1=bffb520c a2=6e > type=PATH msg=audit(1152547495.010:3476): item=0 name=(null) > inode=8585327 dev=fd:00 mode=0140777 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:cyrus_var_lib_t:s0 > > -- I would suggest you turn off enforcing mode and generate all the AVC messages. Then use audit2allow to generate a loadable policy module. audit2allow -M imtp -i /var/log/messages semodule -i impt.pp Then someone can convince me or upstream to add the policy. :^) > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Thu Jul 13 15:16:32 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 13 Jul 2006 11:16:32 -0400 Subject: Openswan on FC4/5 In-Reply-To: <20060711164020.372c05d8@stuart.ripon.secpay.com> References: <20060626092226.7ab61183@stuart.ripon.secpay.com> <20060627124822.47e0c08d@stuart.ripon.secpay.com> <20060627144629.7d07673f@stuart.ripon.secpay.com> <20060711164020.372c05d8@stuart.ripon.secpay.com> Message-ID: <44B663D0.7000402@redhat.com> Stuart James wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, 27 Jun 2006 14:46:29 +0100 > Stuart James wrote: > > > >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Hi, >>>> >>>> We are using Openswan to connect two of our sites together via an >>>> IPSEC tunnel. Recently we upgraded from FC3 to FC5 on our frontend >>>> firewalls, including the version of openswan , selinux policy, >>>> kernel ,ect. We used to run in enforcing mode without any >>>> difficulties, it now seems that with Enforcing mode on Openswan >>>> does not seem to be able to add the route. >>>> >>>> Using setenforce 0 , the tunnel becomes active. As far as i can >>>> tell Openswan has difficulty adding the route to the Right/Left >>>> nexthop, although the status of the tunnel appears to be up, the >>>> routing does not appear to take place. >>>> >>>> #audit2allow -a -t /var/log/audit/audit.log >>>> allow ifconfig_t self:netlink_xfrm_socket create; >>>> allow ifconfig_t initrc_t:unix_stream_socket { read write }; >>>> >>> I've followed this up in more detail, adding to >>> /usr/src/redhat/SOURCES/serefpolicy-2.2.43/policy/modules/system/sysnetwork.te >>> >>> # IPsec >>> allow ifconfig_t self:netlink_xfrm_socket create; >>> allow ifconfig_t initrc_t:unix_stream_socket { read write }; >>> allow ifconfig_t self:netlink_xfrm_socket setopt; >>> allow ifconfig_t initrc_t:udp_socket { read write }; >>> allow ifconfig_t self:netlink_xfrm_socket { bind setopt }; >>> allow ifconfig_t self:netlink_xfrm_socket bind; >>> allow ifconfig_t self:netlink_xfrm_socket read; >>> allow ifconfig_t self:netlink_xfrm_socket { bind getattr }; >>> allow ifconfig_t self:netlink_xfrm_socket { bind getattr write }; >>> allow ifconfig_t self:netlink_xfrm_socket { bind getattr nlmsg_read >>> write }; >>> >>> >> These rules seem to work now. >> >> >> > # IPSEC (openswan-2.4.x) > > > allow traceroute_t initrc_t:rawip_socket { read write }; > allow traceroute_t initrc_t:udp_socket { read write }; > allow traceroute_t user_home_dir_t:dir search; > > allow ifconfig_t self:netlink_xfrm_socket create; > allow ifconfig_t initrc_t:unix_stream_socket { read write }; > allow ifconfig_t self:netlink_xfrm_socket setopt; > allow ifconfig_t initrc_t:udp_socket { read write }; > allow ifconfig_t self:netlink_xfrm_socket { bind setopt }; > allow ifconfig_t self:netlink_xfrm_socket bind; > allow ifconfig_t self:netlink_xfrm_socket read; > allow ifconfig_t self:netlink_xfrm_socket { bind getattr }; > allow ifconfig_t self:netlink_xfrm_socket { bind getattr write }; > allow ifconfig_t self:netlink_xfrm_socket { bind getattr nlmsg_read > write }; > allow ifconfig_t self:netlink_xfrm_socket { nlmsg_write read }; > allow ifconfig_t unconfined_t:udp_socket { read write }; > allow unlabeled_t self:association sendto; > allow unlabeled_t self:association recvfrom; > > > Ok I can add the netlink_xfrm_socket stuff to upstream. They will be in tonights policy The unlabeled_t should be gone with the latest policy. I am not sure about allow ifconfig_t unconfined_t:udp_socket { read write }; allow ifconfig_t initrc_t:udp_socket { read write }; allow ifconfig_t initrc_t:unix_stream_socket { read write }; allow traceroute_t initrc_t:rawip_socket { read write }; allow traceroute_t initrc_t:udp_socket { read write }; allow traceroute_t user_home_dir_t:dir search; Could you attach avc messages for these? > Regards, > > - -- > Stuart James > System Administrator > DDI - (44) 0 1765 643354 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (GNU/Linux) > > iD8DBQFEs8Znr8LwOCpshrYRAsy/AKC777P7eAugVKSer5Qlh6WFgsyDdQCeNyyp > 6xAQw09KvJ92wtidicpJqhg= > =+sXV > -----END PGP SIGNATURE----- > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From dwalsh at redhat.com Thu Jul 13 15:18:49 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 13 Jul 2006 11:18:49 -0400 Subject: AVCs when printing from firefox... In-Reply-To: <1151353112.17801.9.camel@cyberelk.elk> References: <4c4ba1530606261020s37d2e00fi2ebc520d9378a355@mail.gmail.com> <1151353112.17801.9.camel@cyberelk.elk> Message-ID: <44B66459.6080504@redhat.com> Tim Waugh wrote: > On Mon, 2006-06-26 at 10:20 -0700, Tom London wrote: > >> Running targeted/enforcing, latest rawhide. >> >> Trying to print from firefox, I get: >> >> type=AVC msg=audit(1151341517.216:697): avc: denied { recv } for >> pid=2965 comm="firefox-bin" saddr=127.0.0.1 src=50209 daddr=127.0.0.1 >> dest=631 netif=lo scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 >> tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet >> > > Ah, this is because libcups now uses the UNIX domain > socket /var/run/cups/cups.sock (if it exists) to communicate with cupsd. > We need to add this capability to all targeted applications that need to > communicate with CUPS. > > Tim. > */ > unlabled_t:packet problems should be working now in Rawhide. > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Thu Jul 13 15:34:31 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 13 Jul 2006 11:34:31 -0400 Subject: dovecot 1.0.rc1 In-Reply-To: <44A26223.20509@city-fan.org> References: <44A26223.20509@city-fan.org> Message-ID: <44B66807.3060000@redhat.com> Paul Howarth wrote: > New in rc1 is a directory /var/lib/dovecot where the SSL parameters > files are generated before they are copied to the login directory. > > The following additions to policy support this: > > :::::::::::::: > dovecot.fc > :::::::::::::: > /var/lib/dovecot(/.*)? > gen_context(system_u:object_r:dovecot_var_lib_t,s0) > :::::::::::::: > dovecot.te > :::::::::::::: > policy_module(dovecot, 0.1.4) > > ######################################## > # > # Declarations > # > > require { > type dovecot_t; > }; > > # /var/lib/dovecot holds SSL parameters file > type dovecot_var_lib_t; > files_type(dovecot_var_lib_t) > > ######################################## > # > # Local policy > # > > # Allow dovecot to read the routing table (in selinux-policy > 2.2.43-4.fc5) > #allow dovecot_t self:netlink_route_socket { r_netlink_socket_perms }; > > # Allow dovecot to create and read SSL parameters file > files_search_var_lib(dovecot_t) > allow dovecot_t dovecot_var_lib_t:dir { rw_dir_perms }; > allow dovecot_t dovecot_var_lib_t:file { manage_file_perms }; > > > Paul. Added to selinux-policy-2.3.2-3 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Thu Jul 13 15:36:17 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 13 Jul 2006 11:36:17 -0400 Subject: FC2 useradd in chroot on FC5 host with SELinux In-Reply-To: <1151601933.7470.241.camel@laurel.intra.city-fan.org> References: <1151601933.7470.241.camel@laurel.intra.city-fan.org> Message-ID: <44B66871.3080707@redhat.com> Paul Howarth wrote: > I use mock to build packages for old distributions in a chroot-ed > environment on my FC5 box. I've pretty well got this working for all old > distributions now apart from FC2 (see > http://www.fedoraproject.org/wiki/Legacy/Mock). On FC2, the process gets > off to quite a good start, installing the following packages into the > chroot: > > ============================================================================= > Package Arch Version Repository > Size > ============================================================================= > Installing: > buildsys-build noarch 0.5-1.CF.fc2 groups > 1.8 k > Installing for dependencies: > SysVinit i386 2.85-25 core > 96 k > basesystem noarch 8.0-3 core > 2.7 k > bash i386 2.05b-38 core > 1.5 M > beecrypt i386 3.1.0-3 core > 64 k > binutils i386 2.15.90.0.3-5 core > 2.8 M > buildsys-macros noarch 2-2.fc2 groups > 2.1 k > bzip2 i386 1.0.2-12.1 core > 48 k > bzip2-libs i386 1.0.2-12.1 core > 32 k chkconfig i386 1.3.9-1.1 core > 99 k > coreutils i386 5.2.1-7 core > 2.8 M > cpio i386 2.5-6 core > 45 k > cpp i386 3.3.3-7 core > 1.4 M > cracklib i386 2.7-27.1 core > 26 k > cracklib-dicts i386 2.7-27.1 core > 409 k > db4 i386 4.2.52-3.1 core > 1.5 M > dev i386 3.3.13-1 core > 3.6 M > diffutils i386 2.8.1-11 core > 205 k > e2fsprogs i386 1.35-7.1 core > 728 k > elfutils-libelf i386 0.95-2 core > 36 k > ethtool i386 1.8-3.1 core > 48 k > fedora-release i386 2-4 core > 92 k > file i386 4.07-4 core > 242 k > filesystem i386 2.2.4-1 core > 18 k > findutils i386 1:4.1.7-25 core > 102 k > gawk i386 3.1.3-7 core > 1.5 M > gcc i386 3.3.3-7 core > 3.8 M > gcc-c++ i386 3.3.3-7 core > 2.0 M > gdbm i386 1.8.0-22.1 core > 26 k > glib i386 1:1.2.10-12.1.1 core > 134 k > glib2 i386 2.4.8-1.fc2 updates-released > 477 k > glibc i686 2.3.3-27.1 updates-released > 4.9 M > glibc-common i386 2.3.3-27.1 updates-released > 14 M > glibc-devel i386 2.3.3-27.1 updates-released > 1.9 M > glibc-headers i386 2.3.3-27.1 updates-released > 530 k > glibc-kernheaders i386 2.4-8.44 core > 697 k > grep i386 2.5.1-26 core > 168 k > gzip i386 1.3.3-12.2.legacy updates-released > 88 k > info i386 4.7-4 updates-released > 147 k > initscripts i386 7.55.2-1 updates-released > 906 k > iproute i386 2.4.7-14 core > 591 k > iputils i386 20020927-13 core > 92 k > less i386 382-3 core > 85 k > libacl i386 2.2.7-5 core > 15 k > libattr i386 2.4.1-4 core > 8.6 k > libgcc i386 3.3.3-7 core > 33 k > libselinux i386 1.11.4-1 core > 45 k > libstdc++ i386 3.3.3-7 core > 240 k > libstdc++-devel i386 3.3.3-7 core > 1.3 M > libtermcap i386 2.0.8-38 core > 12 k > make i386 1:3.80-3 core > 337 k > mingetty i386 1.07-2 core > 18 k > mktemp i386 2:1.5-7 core > 12 k > modutils i386 2.4.26-16 core > 395 k > ncurses i386 5.4-5 core > 1.5 M > net-tools i386 1.60-25.1 updates-released > 311 k > pam i386 0.77-40 core > 1.9 M > patch i386 2.5.4-19 core > 61 k > pcre i386 4.5-2 core > 59 k > perl i386 3:5.8.3-18 core > 11 M > perl-Filter i386 1.30-5 core > 68 k > popt i386 1.9.1-0.4.1 updates-released > 61 k > procps i386 3.2.0-1.2 updates-released > 176 k > psmisc i386 21.4-2 core > 41 k > redhat-rpm-config noarch 8.0.28-1.1.1 core > 41 k > rpm i386 4.3.1-0.4.1 updates-released > 2.2 M > rpm-build i386 4.3.1-0.4.1 updates-released > 437 k > sed i386 4.0.8-4 core > 116 k > setup noarch 2.5.33-1 core > 29 k > shadow-utils i386 2:4.0.3-55 updates-released > 671 k > sysklogd i386 1.4.1-16 core > 65 k > tar i386 1.13.25-14 core > 351 k > termcap noarch 11.0.1-18.1 core > 237 k > tzdata noarch 2005f-1.fc2 updates-released > 449 k > unzip i386 5.50-37 core > 139 k > util-linux i386 2.12-19 updates-released > 1.5 M > which i386 2.16-2 core > 21 k > words noarch 2-22 core > 137 k > zlib i386 1.2.1.2-0.fc2 updates-released > 44 k > > After installing all of these packages successfully, the next thing that > happens is: > > Executing /usr/sbin/mock-helper > chroot /var/lib/mock/fedora-2-i386-core/root /bin/su - root -c > "/usr/sbin/useradd -m -u 500 -d /builddir mockbuild" > > and at that point the "useradd" process just hangs indefinitely. I'm > told that if SELinux is disabled (I've tried permissive mode and that > doesn't help), this works. I can't see any AVCs in the logs. > > Any ideas what might be causing this and how it might be fixed? > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > In fc2 you should disable SELinux. From paul at city-fan.org Thu Jul 13 15:53:14 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 13 Jul 2006 16:53:14 +0100 Subject: FC2 useradd in chroot on FC5 host with SELinux In-Reply-To: <44B66871.3080707@redhat.com> References: <1151601933.7470.241.camel@laurel.intra.city-fan.org> <44B66871.3080707@redhat.com> Message-ID: <44B66C6A.6090808@city-fan.org> Daniel J Walsh wrote: > Paul Howarth wrote: >> I use mock to build packages for old distributions in a chroot-ed >> environment on my FC5 box. I've pretty well got this working for all old >> distributions now apart from FC2 (see >> http://www.fedoraproject.org/wiki/Legacy/Mock). On FC2, the process gets >> off to quite a good start, installing the following packages into the >> chroot: >> >> ============================================================================= >> >> Package Arch Version Repository >> Size >> ============================================================================= >> >> Installing: >> buildsys-build noarch 0.5-1.CF.fc2 groups >> 1.8 k >> Installing for dependencies: >> SysVinit i386 2.85-25 core >> 96 k >> basesystem noarch 8.0-3 core >> 2.7 k >> bash i386 2.05b-38 core >> 1.5 M >> beecrypt i386 3.1.0-3 core >> 64 k >> binutils i386 2.15.90.0.3-5 core >> 2.8 M >> buildsys-macros noarch 2-2.fc2 groups >> 2.1 k >> bzip2 i386 1.0.2-12.1 core >> 48 k >> bzip2-libs i386 1.0.2-12.1 core >> 32 k chkconfig i386 1.3.9-1.1 core >> 99 k >> coreutils i386 5.2.1-7 core >> 2.8 M >> cpio i386 2.5-6 core >> 45 k >> cpp i386 3.3.3-7 core >> 1.4 M >> cracklib i386 2.7-27.1 core >> 26 k >> cracklib-dicts i386 2.7-27.1 core >> 409 k >> db4 i386 4.2.52-3.1 core >> 1.5 M >> dev i386 3.3.13-1 core >> 3.6 M >> diffutils i386 2.8.1-11 core >> 205 k >> e2fsprogs i386 1.35-7.1 core >> 728 k >> elfutils-libelf i386 0.95-2 core >> 36 k >> ethtool i386 1.8-3.1 core >> 48 k >> fedora-release i386 2-4 core >> 92 k >> file i386 4.07-4 core >> 242 k >> filesystem i386 2.2.4-1 core >> 18 k >> findutils i386 1:4.1.7-25 core >> 102 k >> gawk i386 3.1.3-7 core >> 1.5 M >> gcc i386 3.3.3-7 core >> 3.8 M >> gcc-c++ i386 3.3.3-7 core >> 2.0 M >> gdbm i386 1.8.0-22.1 core >> 26 k >> glib i386 1:1.2.10-12.1.1 core >> 134 k >> glib2 i386 2.4.8-1.fc2 updates-released >> 477 k >> glibc i686 2.3.3-27.1 updates-released >> 4.9 M >> glibc-common i386 2.3.3-27.1 updates-released >> 14 M >> glibc-devel i386 2.3.3-27.1 updates-released >> 1.9 M >> glibc-headers i386 2.3.3-27.1 updates-released >> 530 k >> glibc-kernheaders i386 2.4-8.44 core >> 697 k >> grep i386 2.5.1-26 core >> 168 k >> gzip i386 1.3.3-12.2.legacy updates-released >> 88 k >> info i386 4.7-4 updates-released >> 147 k >> initscripts i386 7.55.2-1 updates-released >> 906 k >> iproute i386 2.4.7-14 core >> 591 k >> iputils i386 20020927-13 core >> 92 k >> less i386 382-3 core >> 85 k >> libacl i386 2.2.7-5 core >> 15 k >> libattr i386 2.4.1-4 core >> 8.6 k >> libgcc i386 3.3.3-7 core >> 33 k >> libselinux i386 1.11.4-1 core >> 45 k >> libstdc++ i386 3.3.3-7 core >> 240 k >> libstdc++-devel i386 3.3.3-7 core >> 1.3 M >> libtermcap i386 2.0.8-38 core >> 12 k >> make i386 1:3.80-3 core >> 337 k >> mingetty i386 1.07-2 core >> 18 k >> mktemp i386 2:1.5-7 core >> 12 k >> modutils i386 2.4.26-16 core >> 395 k >> ncurses i386 5.4-5 core >> 1.5 M >> net-tools i386 1.60-25.1 updates-released >> 311 k >> pam i386 0.77-40 core >> 1.9 M >> patch i386 2.5.4-19 core >> 61 k >> pcre i386 4.5-2 core >> 59 k >> perl i386 3:5.8.3-18 core >> 11 M >> perl-Filter i386 1.30-5 core >> 68 k >> popt i386 1.9.1-0.4.1 updates-released >> 61 k >> procps i386 3.2.0-1.2 updates-released >> 176 k >> psmisc i386 21.4-2 core >> 41 k >> redhat-rpm-config noarch 8.0.28-1.1.1 core >> 41 k >> rpm i386 4.3.1-0.4.1 updates-released >> 2.2 M >> rpm-build i386 4.3.1-0.4.1 updates-released >> 437 k >> sed i386 4.0.8-4 core >> 116 k >> setup noarch 2.5.33-1 core >> 29 k >> shadow-utils i386 2:4.0.3-55 updates-released >> 671 k >> sysklogd i386 1.4.1-16 core >> 65 k >> tar i386 1.13.25-14 core >> 351 k >> termcap noarch 11.0.1-18.1 core >> 237 k >> tzdata noarch 2005f-1.fc2 updates-released >> 449 k >> unzip i386 5.50-37 core >> 139 k >> util-linux i386 2.12-19 updates-released >> 1.5 M >> which i386 2.16-2 core >> 21 k >> words noarch 2-22 core >> 137 k >> zlib i386 1.2.1.2-0.fc2 updates-released >> 44 k >> >> After installing all of these packages successfully, the next thing that >> happens is: >> >> Executing /usr/sbin/mock-helper >> chroot /var/lib/mock/fedora-2-i386-core/root /bin/su - root -c >> "/usr/sbin/useradd -m -u 500 -d /builddir mockbuild" >> >> and at that point the "useradd" process just hangs indefinitely. I'm >> told that if SELinux is disabled (I've tried permissive mode and that >> doesn't help), this works. I can't see any AVCs in the logs. >> >> Any ideas what might be causing this and how it might be fixed? > In fc2 you should disable SELinux. I'm running this on FC5; what I'm trying to do is set up a chroot with FC2 packages. This includes the FC2 version of useradd, and it's this that's hanging when run in the chroot. I'd happily give things in the chroot the impression that SELinux is disabled (I believe mock actually does this already) but I *really* don't want to disable SELinux on my FC5 host. Paul. From dwalsh at redhat.com Thu Jul 13 16:28:49 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 13 Jul 2006 12:28:49 -0400 Subject: FC2 useradd in chroot on FC5 host with SELinux In-Reply-To: <44B66C6A.6090808@city-fan.org> References: <1151601933.7470.241.camel@laurel.intra.city-fan.org> <44B66871.3080707@redhat.com> <44B66C6A.6090808@city-fan.org> Message-ID: <44B674C1.80705@redhat.com> Paul Howarth wrote: > Daniel J Walsh wrote: >> Paul Howarth wrote: >>> I use mock to build packages for old distributions in a chroot-ed >>> environment on my FC5 box. I've pretty well got this working for all >>> old >>> distributions now apart from FC2 (see >>> http://www.fedoraproject.org/wiki/Legacy/Mock). On FC2, the process >>> gets >>> off to quite a good start, installing the following packages into the >>> chroot: >>> >>> ============================================================================= >>> >>> Package Arch Version Repository >>> Size >>> ============================================================================= >>> >>> Installing: >>> buildsys-build noarch 0.5-1.CF.fc2 groups >>> 1.8 k >>> Installing for dependencies: >>> SysVinit i386 2.85-25 core >>> 96 k >>> basesystem noarch 8.0-3 core >>> 2.7 k >>> bash i386 2.05b-38 core >>> 1.5 M >>> beecrypt i386 3.1.0-3 core >>> 64 k >>> binutils i386 2.15.90.0.3-5 core >>> 2.8 M >>> buildsys-macros noarch 2-2.fc2 groups >>> 2.1 k >>> bzip2 i386 1.0.2-12.1 core >>> 48 k >>> bzip2-libs i386 1.0.2-12.1 core >>> 32 k chkconfig i386 1.3.9-1.1 core >>> 99 k >>> coreutils i386 5.2.1-7 core >>> 2.8 M >>> cpio i386 2.5-6 core >>> 45 k >>> cpp i386 3.3.3-7 core >>> 1.4 M >>> cracklib i386 2.7-27.1 core >>> 26 k >>> cracklib-dicts i386 2.7-27.1 core >>> 409 k >>> db4 i386 4.2.52-3.1 core >>> 1.5 M >>> dev i386 3.3.13-1 core >>> 3.6 M >>> diffutils i386 2.8.1-11 core >>> 205 k >>> e2fsprogs i386 1.35-7.1 core >>> 728 k >>> elfutils-libelf i386 0.95-2 core >>> 36 k >>> ethtool i386 1.8-3.1 core >>> 48 k >>> fedora-release i386 2-4 core >>> 92 k >>> file i386 4.07-4 core >>> 242 k >>> filesystem i386 2.2.4-1 core >>> 18 k >>> findutils i386 1:4.1.7-25 core >>> 102 k >>> gawk i386 3.1.3-7 core >>> 1.5 M >>> gcc i386 3.3.3-7 core >>> 3.8 M >>> gcc-c++ i386 3.3.3-7 core >>> 2.0 M >>> gdbm i386 1.8.0-22.1 core >>> 26 k >>> glib i386 1:1.2.10-12.1.1 core >>> 134 k >>> glib2 i386 2.4.8-1.fc2 updates-released >>> 477 k >>> glibc i686 2.3.3-27.1 updates-released >>> 4.9 M >>> glibc-common i386 2.3.3-27.1 updates-released >>> 14 M >>> glibc-devel i386 2.3.3-27.1 updates-released >>> 1.9 M >>> glibc-headers i386 2.3.3-27.1 updates-released >>> 530 k >>> glibc-kernheaders i386 2.4-8.44 core >>> 697 k >>> grep i386 2.5.1-26 core >>> 168 k >>> gzip i386 1.3.3-12.2.legacy updates-released >>> 88 k >>> info i386 4.7-4 updates-released >>> 147 k >>> initscripts i386 7.55.2-1 updates-released >>> 906 k >>> iproute i386 2.4.7-14 core >>> 591 k >>> iputils i386 20020927-13 core >>> 92 k >>> less i386 382-3 core >>> 85 k >>> libacl i386 2.2.7-5 core >>> 15 k >>> libattr i386 2.4.1-4 core >>> 8.6 k >>> libgcc i386 3.3.3-7 core >>> 33 k >>> libselinux i386 1.11.4-1 core >>> 45 k >>> libstdc++ i386 3.3.3-7 core >>> 240 k >>> libstdc++-devel i386 3.3.3-7 core >>> 1.3 M >>> libtermcap i386 2.0.8-38 core >>> 12 k >>> make i386 1:3.80-3 core >>> 337 k >>> mingetty i386 1.07-2 core >>> 18 k >>> mktemp i386 2:1.5-7 core >>> 12 k >>> modutils i386 2.4.26-16 core >>> 395 k >>> ncurses i386 5.4-5 core >>> 1.5 M >>> net-tools i386 1.60-25.1 updates-released >>> 311 k >>> pam i386 0.77-40 core >>> 1.9 M >>> patch i386 2.5.4-19 core >>> 61 k >>> pcre i386 4.5-2 core >>> 59 k >>> perl i386 3:5.8.3-18 core >>> 11 M >>> perl-Filter i386 1.30-5 core >>> 68 k >>> popt i386 1.9.1-0.4.1 updates-released >>> 61 k >>> procps i386 3.2.0-1.2 updates-released >>> 176 k >>> psmisc i386 21.4-2 core >>> 41 k >>> redhat-rpm-config noarch 8.0.28-1.1.1 core >>> 41 k >>> rpm i386 4.3.1-0.4.1 updates-released >>> 2.2 M >>> rpm-build i386 4.3.1-0.4.1 updates-released >>> 437 k >>> sed i386 4.0.8-4 core >>> 116 k >>> setup noarch 2.5.33-1 core >>> 29 k >>> shadow-utils i386 2:4.0.3-55 updates-released >>> 671 k >>> sysklogd i386 1.4.1-16 core >>> 65 k >>> tar i386 1.13.25-14 core >>> 351 k >>> termcap noarch 11.0.1-18.1 core >>> 237 k >>> tzdata noarch 2005f-1.fc2 updates-released >>> 449 k >>> unzip i386 5.50-37 core >>> 139 k >>> util-linux i386 2.12-19 updates-released >>> 1.5 M >>> which i386 2.16-2 core >>> 21 k >>> words noarch 2-22 core >>> 137 k >>> zlib i386 1.2.1.2-0.fc2 updates-released >>> 44 k >>> >>> After installing all of these packages successfully, the next thing >>> that >>> happens is: >>> >>> Executing /usr/sbin/mock-helper >>> chroot /var/lib/mock/fedora-2-i386-core/root /bin/su - root -c >>> "/usr/sbin/useradd -m -u 500 -d /builddir mockbuild" >>> >>> and at that point the "useradd" process just hangs indefinitely. I'm >>> told that if SELinux is disabled (I've tried permissive mode and that >>> doesn't help), this works. I can't see any AVCs in the logs. >>> >>> Any ideas what might be causing this and how it might be fixed? > > >> In fc2 you should disable SELinux. > > I'm running this on FC5; what I'm trying to do is set up a chroot with > FC2 packages. This includes the FC2 version of useradd, and it's this > that's hanging when run in the chroot. > > I'd happily give things in the chroot the impression that SELinux is > disabled (I believe mock actually does this already) but I *really* > don't want to disable SELinux on my FC5 host. > > Paul. I have no idea why this would happen then. And I am not sure I believe them when they say that if SELinux was disabled this would work differently, unless there is a kernel bug. You are not seeing avc messages, correct? Usually if it does not work in permissive mode it is not an SELinux problem. From paul at city-fan.org Thu Jul 13 16:59:12 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 13 Jul 2006 17:59:12 +0100 Subject: FC2 useradd in chroot on FC5 host with SELinux In-Reply-To: <44B674C1.80705@redhat.com> References: <1151601933.7470.241.camel@laurel.intra.city-fan.org> <44B66871.3080707@redhat.com> <44B66C6A.6090808@city-fan.org> <44B674C1.80705@redhat.com> Message-ID: <44B67BE0.6010802@city-fan.org> Daniel J Walsh wrote: > Paul Howarth wrote: >> Daniel J Walsh wrote: >>> Paul Howarth wrote: >>>> I use mock to build packages for old distributions in a chroot-ed >>>> environment on my FC5 box. I've pretty well got this working for all >>>> old >>>> distributions now apart from FC2 (see >>>> http://www.fedoraproject.org/wiki/Legacy/Mock). On FC2, the process >>>> gets >>>> off to quite a good start, installing the following packages into the >>>> chroot: >>>> >>>> ============================================================================= >>>> >>>> Package Arch Version Repository >>>> Size >>>> ============================================================================= >>>> >>>> Installing: >>>> buildsys-build noarch 0.5-1.CF.fc2 groups >>>> 1.8 k >>>> Installing for dependencies: >>>> SysVinit i386 2.85-25 core >>>> 96 k >>>> basesystem noarch 8.0-3 core >>>> 2.7 k >>>> bash i386 2.05b-38 core >>>> 1.5 M >>>> beecrypt i386 3.1.0-3 core >>>> 64 k >>>> binutils i386 2.15.90.0.3-5 core >>>> 2.8 M >>>> buildsys-macros noarch 2-2.fc2 groups >>>> 2.1 k >>>> bzip2 i386 1.0.2-12.1 core >>>> 48 k >>>> bzip2-libs i386 1.0.2-12.1 core >>>> 32 k chkconfig i386 1.3.9-1.1 core >>>> 99 k >>>> coreutils i386 5.2.1-7 core >>>> 2.8 M >>>> cpio i386 2.5-6 core >>>> 45 k >>>> cpp i386 3.3.3-7 core >>>> 1.4 M >>>> cracklib i386 2.7-27.1 core >>>> 26 k >>>> cracklib-dicts i386 2.7-27.1 core >>>> 409 k >>>> db4 i386 4.2.52-3.1 core >>>> 1.5 M >>>> dev i386 3.3.13-1 core >>>> 3.6 M >>>> diffutils i386 2.8.1-11 core >>>> 205 k >>>> e2fsprogs i386 1.35-7.1 core >>>> 728 k >>>> elfutils-libelf i386 0.95-2 core >>>> 36 k >>>> ethtool i386 1.8-3.1 core >>>> 48 k >>>> fedora-release i386 2-4 core >>>> 92 k >>>> file i386 4.07-4 core >>>> 242 k >>>> filesystem i386 2.2.4-1 core >>>> 18 k >>>> findutils i386 1:4.1.7-25 core >>>> 102 k >>>> gawk i386 3.1.3-7 core >>>> 1.5 M >>>> gcc i386 3.3.3-7 core >>>> 3.8 M >>>> gcc-c++ i386 3.3.3-7 core >>>> 2.0 M >>>> gdbm i386 1.8.0-22.1 core >>>> 26 k >>>> glib i386 1:1.2.10-12.1.1 core >>>> 134 k >>>> glib2 i386 2.4.8-1.fc2 updates-released >>>> 477 k >>>> glibc i686 2.3.3-27.1 updates-released >>>> 4.9 M >>>> glibc-common i386 2.3.3-27.1 updates-released >>>> 14 M >>>> glibc-devel i386 2.3.3-27.1 updates-released >>>> 1.9 M >>>> glibc-headers i386 2.3.3-27.1 updates-released >>>> 530 k >>>> glibc-kernheaders i386 2.4-8.44 core >>>> 697 k >>>> grep i386 2.5.1-26 core >>>> 168 k >>>> gzip i386 1.3.3-12.2.legacy updates-released >>>> 88 k >>>> info i386 4.7-4 updates-released >>>> 147 k >>>> initscripts i386 7.55.2-1 updates-released >>>> 906 k >>>> iproute i386 2.4.7-14 core >>>> 591 k >>>> iputils i386 20020927-13 core >>>> 92 k >>>> less i386 382-3 core >>>> 85 k >>>> libacl i386 2.2.7-5 core >>>> 15 k >>>> libattr i386 2.4.1-4 core >>>> 8.6 k >>>> libgcc i386 3.3.3-7 core >>>> 33 k >>>> libselinux i386 1.11.4-1 core >>>> 45 k >>>> libstdc++ i386 3.3.3-7 core >>>> 240 k >>>> libstdc++-devel i386 3.3.3-7 core >>>> 1.3 M >>>> libtermcap i386 2.0.8-38 core >>>> 12 k >>>> make i386 1:3.80-3 core >>>> 337 k >>>> mingetty i386 1.07-2 core >>>> 18 k >>>> mktemp i386 2:1.5-7 core >>>> 12 k >>>> modutils i386 2.4.26-16 core >>>> 395 k >>>> ncurses i386 5.4-5 core >>>> 1.5 M >>>> net-tools i386 1.60-25.1 updates-released >>>> 311 k >>>> pam i386 0.77-40 core >>>> 1.9 M >>>> patch i386 2.5.4-19 core >>>> 61 k >>>> pcre i386 4.5-2 core >>>> 59 k >>>> perl i386 3:5.8.3-18 core >>>> 11 M >>>> perl-Filter i386 1.30-5 core >>>> 68 k >>>> popt i386 1.9.1-0.4.1 updates-released >>>> 61 k >>>> procps i386 3.2.0-1.2 updates-released >>>> 176 k >>>> psmisc i386 21.4-2 core >>>> 41 k >>>> redhat-rpm-config noarch 8.0.28-1.1.1 core >>>> 41 k >>>> rpm i386 4.3.1-0.4.1 updates-released >>>> 2.2 M >>>> rpm-build i386 4.3.1-0.4.1 updates-released >>>> 437 k >>>> sed i386 4.0.8-4 core >>>> 116 k >>>> setup noarch 2.5.33-1 core >>>> 29 k >>>> shadow-utils i386 2:4.0.3-55 updates-released >>>> 671 k >>>> sysklogd i386 1.4.1-16 core >>>> 65 k >>>> tar i386 1.13.25-14 core >>>> 351 k >>>> termcap noarch 11.0.1-18.1 core >>>> 237 k >>>> tzdata noarch 2005f-1.fc2 updates-released >>>> 449 k >>>> unzip i386 5.50-37 core >>>> 139 k >>>> util-linux i386 2.12-19 updates-released >>>> 1.5 M >>>> which i386 2.16-2 core >>>> 21 k >>>> words noarch 2-22 core >>>> 137 k >>>> zlib i386 1.2.1.2-0.fc2 updates-released >>>> 44 k >>>> >>>> After installing all of these packages successfully, the next thing >>>> that >>>> happens is: >>>> >>>> Executing /usr/sbin/mock-helper >>>> chroot /var/lib/mock/fedora-2-i386-core/root /bin/su - root -c >>>> "/usr/sbin/useradd -m -u 500 -d /builddir mockbuild" >>>> >>>> and at that point the "useradd" process just hangs indefinitely. I'm >>>> told that if SELinux is disabled (I've tried permissive mode and that >>>> doesn't help), this works. I can't see any AVCs in the logs. >>>> >>>> Any ideas what might be causing this and how it might be fixed? >> >> >>> In fc2 you should disable SELinux. >> >> I'm running this on FC5; what I'm trying to do is set up a chroot with >> FC2 packages. This includes the FC2 version of useradd, and it's this >> that's hanging when run in the chroot. >> >> I'd happily give things in the chroot the impression that SELinux is >> disabled (I believe mock actually does this already) but I *really* >> don't want to disable SELinux on my FC5 host. >> >> Paul. > I have no idea why this would happen then. And I am not sure I believe > them when they say that if SELinux was disabled this would work > differently, unless there is a kernel bug. You are not seeing avc > messages, correct? Correct. > Usually if it does not work in permissive mode it is > not an SELinux problem. *Usually*... I guess I'll have to bite the bullet and try it with SELinux disabled (so I'll have to relabel my desktop box afterwards, sigh). I know of two people that have this working with SELinux disabled, and I vaguely recall it working for me when I was first trying this (with SELinux disabled, probably a year ago). I've got it working for everything from RHL7 through to FC5 targets apart from FC2, so I doubt I'm doing something significantly wrong. Paul. From dwalsh at redhat.com Thu Jul 13 18:43:07 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 13 Jul 2006 14:43:07 -0400 Subject: pam_console_t wants access to device_t:chr_file ? In-Reply-To: <4c4ba1530607100637v60b94586re4894d92a63d1ee@mail.gmail.com> References: <4c4ba1530606290652k7a5e402ekfb79e996eee202d0@mail.gmail.com> <44B00A87.9050909@redhat.com> <4c4ba1530607081315k57637dd0n77db7b61f93a1839@mail.gmail.com> <1152523396.3470.13.camel@perun.kabelta.loc> <4c4ba1530607100637v60b94586re4894d92a63d1ee@mail.gmail.com> Message-ID: <44B6943B.6090805@redhat.com> Tom London wrote: > On 7/10/06, Tomas Mraz wrote: >> On Sat, 2006-07-08 at 13:15 -0700, Tom London wrote: >> > On 7/8/06, Daniel J Walsh wrote: >> > Happens every time I boot. Appears to depend on the usb devices I >> > have connected at the time (I have 2 'docks' for my laptop, so the USB >> > setup is not the same). >> > >> > In this case, 'lsusb' says: >> > Bus 005 Device 005: ID 04b8:010a Seiko Epson Corp. Perfection 1640SU >> > Bus 005 Device 004: ID 0461:4d03 Primax Electronics, Ltd Kensington >> > Mouse-in-a-box >> > Bus 005 Device 002: ID 04b3:4484 IBM Corp. >> > Bus 005 Device 001: ID 0000:0000 >> > Bus 002 Device 001: ID 0000:0000 >> > Bus 003 Device 003: ID 0483:2016 SGS Thomson Microelectronics >> Fingerprint Reader >> > Bus 003 Device 001: ID 0000:0000 >> > Bus 001 Device 001: ID 0000:0000 >> > Bus 004 Device 001: ID 0000:0000 >> > >> > So I'm guessing usbdev5.5_ep* is pointing at this. >> >> It is the scanner device so it should have a scanner_device_t type. >> pam_console_apply actually accesses /dev/usb/scanner* or /dev/scanner* >> symlink which points to the device node. >> -- >> Tomas Mraz >> > Here is the output from 'ls -lZ /dev/scanner*': > lrwxrwxrwx root root system_u:object_r:device_t > /dev/scanner-usbdev1.5 -> bus/usb/001/005 > lrwxrwxrwx root root system_u:object_r:device_t > /dev/scanner-usbdev1.5_ep00 -> usbdev1.5_ep00 > lrwxrwxrwx root root system_u:object_r:device_t > /dev/scanner-usbdev1.5_ep02 -> usbdev1.5_ep02 > lrwxrwxrwx root root system_u:object_r:device_t > /dev/scanner-usbdev1.5_ep81 -> usbdev1.5_ep81 > > All /dev/usbdev* files are labeled as device_t. > > tom If I add the following /dev/usbdev.* -c gen_context(system_u:object_r:usb_device_t,s0) Will it fix the problem? From dwalsh at redhat.com Thu Jul 13 19:00:26 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 13 Jul 2006 15:00:26 -0400 Subject: Running two named processes in selinux In-Reply-To: <200606302042.k5UKg9cL019692@mx1.redhat.com> References: <200606302042.k5UKg9cL019692@mx1.redhat.com> Message-ID: <44B6984A.3010006@redhat.com> Faisal Ali wrote: > Hi, > > Is it possible to run two named process in selinux each having different > file permissions. Instead of using DNS Views Iam thinking about running two > named processes, one for external and one for internal. Ofcourse external > named process will have access to different set of files versus internal > named process. > > > Can this be done. > Yes Paul explained how. > Its security-of-Xen-Vm-isolation vs SELinux-isolation comparision. > > Should I run two Xen VMs one for external DNS and the other for Internal DNS > or run two named processes each isolated and jailed by SELinux. > > Two Xens with SELinux protection on both > Faisal Ali > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From jbrindle at tresys.com Thu Jul 13 20:10:19 2006 From: jbrindle at tresys.com (Joshua Brindle) Date: Thu, 13 Jul 2006 16:10:19 -0400 Subject: SELinux opensource server online Message-ID: <6FE441CD9F0C0C479F2D88F959B015882986F5@exchange.columbia.tresys.com> During the SELinux Symposium developer summit we discussed moving Tresys' SELinux related projects to a new server with anonymous subversion access. The server is now up and the reference policy pages and subversion repository have been moved. The server's address is http://oss.tresys.com. Instructions for checking out reference policy subversion tree are on the reference policy page. Additionally, our other projects will be moving to the server soon. The press release is available at http://www.tresys.com/news/press32 From jacliburn at bellsouth.net Fri Jul 14 00:44:05 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Thu, 13 Jul 2006 19:44:05 -0500 Subject: mailq.postfix.gz.1 incorrectly labeled in FC6T1 Message-ID: <1152837845.2381.6.camel@osprey.hogchain.net> After installing postfix under FC6T1, I kept getting this avc: audit(1152836951.218:8): avc: denied { getattr } for pid=3130 comm="sh" name="mailq.postfix.1.gz" dev=dm-0 ino=1084752 scontext=user_u:system_r:postfix_master_t:s0 tcontext=system_u:object_r:man_t:s0 tclass=file It's a manpage and it looks to me like it came from the factory labeled incorrectly. A chcon to system_u:object_r:man_t seems to have fixed it. From daobrien at redhat.com Fri Jul 14 06:31:42 2006 From: daobrien at redhat.com (David O'Brien) Date: Fri, 14 Jul 2006 16:31:42 +1000 Subject: RHEL5 Security Documentation Scope Statement Message-ID: <200607141631.42793.daobrien@redhat.com> I've prepared the following Scope Statement to help those involved in the project to update the RHEL5 Security Documentation. Please feel free to offer any suggestions, ask questions or get clarification. As we move forward there may be minor changes, but this should be pretty close. Apologies for the cross-post and to those who receive multiple copies. Please forward this to interested parties who may not be on any of these lists. ---- The RHEL5 Security Guide integrates two previously separate guides: The Red Hat Enterprise Linux 4 Security Guide and the Red Hat Enterprise Linux 4 SELinux Guide. These guides are being integrated and updated to provide a single source of information for all security-related topics for Red Hat Enterprise Linux. The RHEL5 Security Guide provides a general introduction to security, and from the perspective of Red Hat Linux in particular. It provides conceptual information in the areas of security assessment, common exploits, and intrusion and incident response. It also provides conceptual and specific configuration information for hardening Workstation, Server, VPN, firewall and other implementations using SELinux. A Troubleshooting section provides information on common problems and how to resolve them. The RHEL5 Security Guide assumes a basic knowledge of IT security, and consequently provides only minimal coverage of common security practices such as controlling physical access, sound account-keeping policies and procedures, auditing, etc. Neither does it cover the intricacies of SELinux in detail, such as writing policies for certain 3rd party applications. Where appropriate, reference is made to external resources for this and related information. ---- regards, David O'Brien Red Hat Asia Pacific Pty Ltd Tel: +61-7-3514-8189 Fax: +61-7-3514-8199 email: daobrien at redhat.com web: http://apac.redhat.com/ From paul at city-fan.org Fri Jul 14 06:59:29 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 14 Jul 2006 07:59:29 +0100 Subject: mailq.postfix.gz.1 incorrectly labeled in FC6T1 In-Reply-To: <1152837845.2381.6.camel@osprey.hogchain.net> References: <1152837845.2381.6.camel@osprey.hogchain.net> Message-ID: <1152860370.14587.3.camel@laurel.intra.city-fan.org> On Thu, 2006-07-13 at 19:44 -0500, Jay Cliburn wrote: > After installing postfix under FC6T1, I kept getting this avc: > > audit(1152836951.218:8): avc: denied { getattr } for pid=3130 > comm="sh" name="mailq.postfix.1.gz" dev=dm-0 ino=1084752 > scontext=user_u:system_r:postfix_master_t:s0 > tcontext=system_u:object_r:man_t:s0 tclass=file > > It's a manpage and it looks to me like it came from the factory labeled > incorrectly. A chcon to system_u:object_r:man_t seems to have fixed it. This has been seen before on FC5: http://www.redhat.com/archives/fedora-selinux-list/2006-June/msg00021.html It appears to happen when postfix is started. The AVC suggests that the manpage already has the correct context, and the strange thing is that the postfix master program is tying to access it (why should that be?). What did you change the context of, and what was it previously? Paul. From method at gentoo.org Fri Jul 14 12:28:15 2006 From: method at gentoo.org (Joshua Brindle) Date: Fri, 14 Jul 2006 08:28:15 -0400 Subject: error In-Reply-To: <3655f5d90607140354qba3470ftc2468d519f8ba869@mail.gmail.com> References: <3655f5d90607121455i2ab8d156k29f256aac23afb05@mail.gmail.com> <44B57139.1080501@gentoo.org> <3655f5d90607140354qba3470ftc2468d519f8ba869@mail.gmail.com> Message-ID: <44B78DDF.8020300@gentoo.org> netpython wrote: > Sry to bother you with my n00b questions. > > I used lsof to get a better understanding on what files > are opened.The te files are now: run-mozilla.te and firefox-bin.te > However the checkpolicy tool complains about an error in > the policy made by the policygentool. > Keep questions on list for the benefit of others. the immediate error is that you can't have a '-' in a module name. Just out of curiosity why aren't you just using the mozilla/firefox policies in refpolicy? you should be able to build the module (make mozilla.pp) and then insert it with semodule -i mozilla.pp > run-mozilla.te: > ------------------- > policy_module(run-mozilla,1.0.0) > > ######################################## > # > # Declarations > # > > type run-mozilla_t; > type run-mozilla_exec_t; > domain_type(run-mozilla_t) > init_daemon_domain(run-mozilla_t, run-mozilla_exec_t) > > ######################################## > # > # run-mozilla local policy > # > # Check in /etc/selinux/refpolicy/include for macros to use instead of > allow rules. > > # Some common macros (you might be able to remove some) > files_read_etc_files(run-mozilla_t) > libs_use_ld_so(run-mozilla_t) > libs_use_shared_libs(run-mozilla_t) > miscfiles_read_localization(run-mozilla_t) > ## internal communication is often done using fifo and unix sockets. > allow run-mozilla_t self:fifo_file { read write }; > allow run-mozilla_t self:unix_stream_socket create_stream_socket_perms; > > # Init script handling > init_use_fds(run-mozilla_t) > init_use_script_ptys(run-mozilla_t) > domain_use_interactive_fds(run-mozilla_t) > ------------------------------------------------------ > > firefox-bin.te: > > policy_module(firefox-bin,1.0.0) > > ######################################## > # > # Declarations > # > > type firefox-bin_t; > type firefox-bin_exec_t; > domain_type(firefox-bin_t) > init_daemon_domain(firefox-bin_t, firefox-bin_exec_t) > > ######################################## > # > # firefox-bin local policy > # > # Check in /etc/selinux/refpolicy/include for macros to use instead of > allow rules. > > # Some common macros (you might be able to remove some) > files_read_etc_files(firefox-bin_t) > libs_use_ld_so(firefox-bin_t) > libs_use_shared_libs(firefox-bin_t) > miscfiles_read_localization(firefox-bin_t) > ## internal communication is often done using fifo and unix sockets. > allow firefox-bin_t self:fifo_file { read write }; > allow firefox-bin_t self:unix_stream_socket create_stream_socket_perms; > > # Init script handling > init_use_fds(firefox-bin_t) > init_use_script_ptys(firefox-bin_t) > domain_use_interactive_fds(firefox-bin_t) > ------------------------------------------------------ > > Errors i get: > > Compiling targeted firefox-bin module > /usr/bin/checkmodule: loading policy configuration from > tmp/firefox-bin.tmp > firefox-bin.te:1:ERROR 'syntax error' at token 'firefox-bin' on line > 57284: > module firefox-bin 1.0.0; > #line 1 > /usr/bin/checkmodule: error(s) encountered while parsing configuration > make: *** [tmp/firefox-bin.mod] Error 1 > > > In /usr/share/selinux/devel/include/apps there's a mozilla.if file. > What could i do with it? I searched in the doc's and now know it's > an interface file,but other than that... > > kind regards, > > Peter > > > From jacliburn at bellsouth.net Fri Jul 14 12:19:53 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Fri, 14 Jul 2006 07:19:53 -0500 Subject: gdm-binary AVCs in current rawhide Message-ID: <1152879593.2358.15.camel@osprey.hogchain.net> [jcliburn at osprey ~]$ uname -rm 2.6.17-1.2391.fc6 x86_64 The following avcs appear in an updated FC6T1 system. Jul 14 06:54:35 osprey kernel: audit(1152878073.967:5): avc: denied { write } for pid=2234 comm="gdm-binary" scontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=key Jul 14 06:54:35 osprey kernel: audit(1152878073.967:6): avc: denied { link } for pid=2234 comm="gdm-binary" scontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=key From cpebenito at tresys.com Fri Jul 14 13:12:55 2006 From: cpebenito at tresys.com (Christopher J. PeBenito) Date: Fri, 14 Jul 2006 09:12:55 -0400 Subject: gdm-binary AVCs in current rawhide In-Reply-To: <1152879593.2358.15.camel@osprey.hogchain.net> References: <1152879593.2358.15.camel@osprey.hogchain.net> Message-ID: <1152882775.3299.75.camel@sgc.columbia.tresys.com> On Fri, 2006-07-14 at 07:19 -0500, Jay Cliburn wrote: > The following avcs appear in an updated FC6T1 system. > > Jul 14 06:54:35 osprey kernel: audit(1152878073.967:5): avc: denied > { write } for pid=2234 comm="gdm-binary" > scontext=system_u:system_r:xdm_t:s0-s0:c0.c255 > tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=key > Jul 14 06:54:35 osprey kernel: audit(1152878073.967:6): avc: denied > { link } for pid=2234 comm="gdm-binary" > scontext=system_u:system_r:xdm_t:s0-s0:c0.c255 > tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=key If this is a targeted policy, I've fixed it in the upstream policy. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 From paul at city-fan.org Fri Jul 14 14:59:42 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 14 Jul 2006 15:59:42 +0100 Subject: mailq.postfix.gz.1 incorrectly labeled in FC6T1 In-Reply-To: <1152888640.13137.39.camel@code.and.org> References: <1152837845.2381.6.camel@osprey.hogchain.net> <1152860370.14587.3.camel@laurel.intra.city-fan.org> <1152888640.13137.39.camel@code.and.org> Message-ID: <44B7B15E.4030105@city-fan.org> James Antill wrote: > On Fri, 2006-07-14 at 07:59 +0100, Paul Howarth wrote: >> On Thu, 2006-07-13 at 19:44 -0500, Jay Cliburn wrote: >>> After installing postfix under FC6T1, I kept getting this avc: >>> >>> audit(1152836951.218:8): avc: denied { getattr } for pid=3130 >>> comm="sh" name="mailq.postfix.1.gz" dev=dm-0 ino=1084752 >>> scontext=user_u:system_r:postfix_master_t:s0 >>> tcontext=system_u:object_r:man_t:s0 tclass=file >>> >>> It's a manpage and it looks to me like it came from the factory labeled >>> incorrectly. A chcon to system_u:object_r:man_t seems to have fixed it. >> This has been seen before on FC5: >> >> http://www.redhat.com/archives/fedora-selinux-list/2006-June/msg00021.html >> >> It appears to happen when postfix is started. The AVC suggests that the >> manpage already has the correct context, and the strange thing is that >> the postfix master program is tying to access it (why should that be?). > > AIUI postfix looks for where the documentation is for error messages to > the user (Ie. look at the documentation at X to help solve problem Y). Excellent! A sane explanation :-) I suggest adding the following to the postfix policy: # Postfix master process looking for its man pages so that it can refer # to them in error messages # (e.g. look at the documentation at X to help solve problem Y) miscfiles_read_man_pages(postfix_master_t) Paul. From jacliburn at bellsouth.net Fri Jul 14 15:32:53 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Fri, 14 Jul 2006 10:32:53 -0500 Subject: mailq.postfix.gz.1 incorrectly labeled in FC6T1 In-Reply-To: <1152860370.14587.3.camel@laurel.intra.city-fan.org> References: <1152837845.2381.6.camel@osprey.hogchain.net> <1152860370.14587.3.camel@laurel.intra.city-fan.org> Message-ID: <1152891173.2358.35.camel@osprey.hogchain.net> On Fri, 2006-07-14 at 07:59 +0100, Paul Howarth wrote: > On Thu, 2006-07-13 at 19:44 -0500, Jay Cliburn wrote: > > After installing postfix under FC6T1, I kept getting this avc: > > > > audit(1152836951.218:8): avc: denied { getattr } for pid=3130 > > comm="sh" name="mailq.postfix.1.gz" dev=dm-0 ino=1084752 > > scontext=user_u:system_r:postfix_master_t:s0 > > tcontext=system_u:object_r:man_t:s0 tclass=file > > > > It's a manpage and it looks to me like it came from the factory labeled > > incorrectly. A chcon to system_u:object_r:man_t seems to have fixed it. > > This has been seen before on FC5: > > http://www.redhat.com/archives/fedora-selinux-list/2006-June/msg00021.html > > It appears to happen when postfix is started. The AVC suggests that the > manpage already has the correct context, and the strange thing is that > the postfix master program is tying to access it (why should that be?). So the "tcontext" in the AVC message indicates the current context of the file called out in "name"? From paul at city-fan.org Fri Jul 14 15:45:33 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 14 Jul 2006 16:45:33 +0100 Subject: mailq.postfix.gz.1 incorrectly labeled in FC6T1 In-Reply-To: <1152891173.2358.35.camel@osprey.hogchain.net> References: <1152837845.2381.6.camel@osprey.hogchain.net> <1152860370.14587.3.camel@laurel.intra.city-fan.org> <1152891173.2358.35.camel@osprey.hogchain.net> Message-ID: <44B7BC1D.4030900@city-fan.org> Jay Cliburn wrote: > On Fri, 2006-07-14 at 07:59 +0100, Paul Howarth wrote: >> On Thu, 2006-07-13 at 19:44 -0500, Jay Cliburn wrote: >>> After installing postfix under FC6T1, I kept getting this avc: >>> >>> audit(1152836951.218:8): avc: denied { getattr } for pid=3130 >>> comm="sh" name="mailq.postfix.1.gz" dev=dm-0 ino=1084752 >>> scontext=user_u:system_r:postfix_master_t:s0 >>> tcontext=system_u:object_r:man_t:s0 tclass=file >>> >>> It's a manpage and it looks to me like it came from the factory labeled >>> incorrectly. A chcon to system_u:object_r:man_t seems to have fixed it. >> This has been seen before on FC5: >> >> http://www.redhat.com/archives/fedora-selinux-list/2006-June/msg00021.html >> >> It appears to happen when postfix is started. The AVC suggests that the >> manpage already has the correct context, and the strange thing is that >> the postfix master program is tying to access it (why should that be?). > > So the "tcontext" in the AVC message indicates the current context of > the file called out in "name"? Yes, the "scontext" or "source context" is that of the calling process, and the "tcontext" or "target context" is that of the object being acted on. That's my understanding of it. Paul. From paul at city-fan.org Fri Jul 14 17:14:02 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 14 Jul 2006 18:14:02 +0100 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <1152125919.4843.141.camel@localhost.localdomain> References: <1151353351.8219.118.camel@localhost.localdomain> <1151363136.2911.52.camel@laurel.intra.city-fan.org> <1151381464.13100.65.camel@localhost.localdomain> <44A15AC3.5090000@city-fan.org> <1151429665.4219.57.camel@localhost.localdomain> <1151503719.7470.12.camel@laurel.intra.city-fan.org> <1151522527.3438.52.camel@localhost.localdomain> <1151525638.7470.77.camel@laurel.intra.city-fan.org> <1151528181.3438.98.camel@localhost.localdomain> <1151529828.7470.92.camel@laurel.intra.city-fan.org> <1151530682.3438.108.camel@localhost.localdomain> <1151532794.7470.101.camel@laurel.intra.city-fan.org> <1151550925.6200.48.camel@localhost.localdomain> <1151566188.7470.111.camel@laurel.intra.city-fan.org> <1151587633.6200.56.camel@localhost.localdomain> <1151624293.6466.10.camel@localhost.localdomain> <44A524CE.1070205@city-fan.org> <44AA9CF1.6000601@city-fan.org> <1152125919.4843.141.camel@localhost.localdomain> Message-ID: <44B7D0DA.9090207@city-fan.org> Marc Schwartz (via MN) wrote: >>>>> type=AVC msg=audit(1151620643.074:452): avc: denied { append } for pid=2312 comm="spamd" name="razor-agent.log" dev=hdc7 ino=1081 390 scontext=system_u:system_r:spamd_t:s0 tcontext=user_u:object_r:etc_mail_t:s0 tclass=file >>>>> type=SYSCALL msg=audit(1151620643.074:452): arch=40000003 syscall=5 success=no exit=-13 a0=b5c6ee0 a1=8441 a2=1b6 a3=8441 items=1 pi d=2312 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="spamd" exe="/usr/bin/perl" subj=syst em_u:system_r:spamd_t:s0 >>>>> type=CWD msg=audit(1151620643.074:452): cwd="/" >>>>> type=PATH msg=audit(1151620643.074:452): item=0 name="/etc/mail/spamassassin/razor//razor-agent.log" parent=1081385 dev=16:07 mode=0 40755 ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0 >>>> Trying to append to /etc/mail/spamassassin/razor/razor-agent.log, which >>>> of course is etc_mail_t. Is there any way to persuade razor to put this >>>> log in /var/log instead? >>> Yep. Done. I made a change in: >>> >>> /etc/mail/spamassassin/razor/razor-agent.conf >>> >>> Now with a line: >>> >>> logfile = /var/log/razor-agent.log >>> >>> which was just >>> >>> logfile = razor-agent.log >>> >>> Specifying the full path overrides the normal home dir for razor files. >>> >>> After a spamassassin service restart, the log file is now: >>> >>> ls -lZ /var/log/razor-agent.log >>> -rw-r--r-- root root user_u:object_r:var_log_t /var/log/razor-agent.log >>> >>> Note the change in context below. >> Not sure what to do about this. I would like the file to be created with >> the right context really. Unfortunately it is a process in the spamd_t >> domain that is creating this file rather than one in the razor_t domain. I think I've got to the bottom of this now. I actually installed perl-Razor-Agent myself (I'm using sendmail but that doesn't really matter) to figure out what was happening. razor, like spamassassin, is written in perl. This allows spamassassin to call razor directly by simply using the razor perl modules rather than the razor client "binaries" in /usr/bin. Thus spamassassin runs a razor client in its own domain, spamd_t. There is in fact no need for a domain transition from spamd_t to razor_t. Now to get rid of the AVCs. Please update to the policy modules included below. Then: # mkdir /var/log/spamassassin # restorecon -v /var/log/spamassassin Edit /etc/mail/spamassassin/razor/razor-agent.conf and set: logfile = /var/log/spamassassin/razor-agent.log Then restart spamassassin. >> Any thoughts on why dccproc might be wanting to read >> /root/.rh-fontconfig/.fonts.cache-2? > > No definitive answer. > > Checking the dcc source code tree using grep, the only references to > 'font' are in the cgi-bin files (common and common.in) and then in the > HTML files (FAQ.HTML and INSTALL.HTML). I think this is probably a leaked file descriptor. I don't know where the leak is or what to do about it though. :::::::::::::: mypostfix.te :::::::::::::: policy_module(mypostfix, 0.1.1) require { type postfix_master_t; }; # Postfix master process looking for its man pages so that it can refer # to them in error messages # (e.g. look at the documentation at X to help solve problem Y) miscfiles_read_man_pages(postfix_master_t) :::::::::::::: myspamassassin.fc (all one long line) :::::::::::::: /var/log/spamassassin(/.*)? gen_context(system_u:object_r:spamd_log_t,s0) :::::::::::::: myspamassassin.te :::::::::::::: policy_module(myspamassassin, 0.1.4) require { type spamd_t; } type spamd_log_t; logging_log_file(spamd_log_t) # THESE ALL APPEAR TO BE IN selinux-policy-2.2.47-3.fc5 # # This will be included in FC5 policy when dcc module is included #dcc_domtrans_client(spamd_t) # # This is already supposed to be included but doesn't seem to be working #pyzor_domtrans(spamd_t) # Signal the dcc client (SIGTERM is used?) dcc_signal_client(spamd_t) # Use log files allow spamd_t spamd_log_t:file create_file_perms; allow spamd_t spamd_log_t:dir rw_dir_perms; logging_log_filetrans(spamd_t,spamd_log_t,{ file dir }) Paul. From mikezang at yahoo.co.jp Sat Jul 15 01:43:06 2006 From: mikezang at yahoo.co.jp (Mike Zang) Date: Sat, 15 Jul 2006 10:43:06 +0900 (JST) Subject: My FC4 server doesn't work after updated Message-ID: <20060715014306.45281.qmail@web10512.mail.bbt.yahoo.co.jp> My FC4 server worked welll. It doesn't work after I updated by yum. Here is audit avc information from /var/log/message, what can I do? Jul 11 23:29:11 server1 shutdown: shutting down for system reboot Jul 11 23:29:12 server1 init: Switching to runlevel: 6 Jul 11 23:29:14 server1 ainit: Operation not permitted Jul 11 23:29:14 server1 ainit: Operation not permitted Jul 11 23:29:15 server1 dbus: avc: 5 AV entries and 5/512 buckets used, longest chain length 1 Jul 11 23:29:22 server1 xfs[2013]: terminating Jul 11 23:29:36 server1 nmbd[2024]: [2006/07/11 23:29:36, 0] nmbd/nmbd.c:terminate(56) Jul 11 23:29:37 server1 nmbd[2024]: Got SIGTERM: going down... Jul 11 23:30:00 server1 ntpd[1892]: ntpd exiting on signal 15 Jul 11 23:30:01 server1 auditd[1631]: The audit daemon is exiting. Jul 11 23:30:01 server1 kernel: audit(1152628201.909:1300): audit_pid=0 old=1631 by auid=4294967295 subj=system_u:system_r:auditd_t Jul 11 23:30:03 server1 kernel: audit(1152628203.405:1301): avc: denied { search } for pid=27967 comm="rndc" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:ndc_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:30:03 server1 kernel: audit(1152628203.405:1301): arch=40000003 syscall=5 success=no exit=-13 a0=b7ff9406 a1=0 a2=0 a3=8 items=1 pid=27967 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="rndc" exe="/usr/sbin/rndc" subj=system_u:system_r:ndc_t Jul 11 23:30:03 server1 kernel: audit(1152628203.405:1301): cwd="/" Jul 11 23:30:03 server1 kernel: audit(1152628203.405:1301): item=0 name="/usr/lib/libisccfg.so.1" obj=root:object_r:ld_so_cache_t Jul 11 23:30:03 server1 kernel: audit(1152628203.425:1302): avc: denied { search } for pid=27967 comm="rndc" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:ndc_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:30:03 server1 kernel: audit(1152628203.425:1302): arch=40000003 syscall=5 success=no exit=-13 a0=bfbb3460 a1=0 a2=0 a3=40 items=1 pid=27967 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="rndc" exe="/usr/sbin/rndc" subj=system_u:system_r:ndc_t Jul 11 23:30:03 server1 kernel: audit(1152628203.425:1302): cwd="/" Jul 11 23:30:03 server1 kernel: audit(1152628203.425:1302): item=0 name="/usr/lib/tls/i686/libisccfg.so.1" obj=root:object_r:ld_so_cache_t Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1303): avc: denied { search } for pid=27967 comm="rndc" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:ndc_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1303): arch=40000003 syscall=5 success=no exit=-13 a0=bfbb3460 a1=0 a2=0 a3=40 items=1 pid=27967 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="rndc" exe="/usr/sbin/rndc" subj=system_u:system_r:ndc_t Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1303): cwd="/" Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1303): item=0 name="/usr/lib/tls/libisccfg.so.1" obj=root:object_r:ld_so_cache_t Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1304): avc: denied { search } for pid=27967 comm="rndc" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:ndc_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1304): arch=40000003 syscall=5 success=no exit=-13 a0=bfbb3460 a1=0 a2=0 a3=40 items=1 pid=27967 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="rndc" exe="/usr/sbin/rndc" subj=system_u:system_r:ndc_t Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1304): cwd="/" Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1304): item=0 name="/usr/lib/i686/libisccfg.so.1" obj=root:object_r:ld_so_cache_t Jul 11 23:30:03 server1 kernel: audit(1152628203.433:1305): avc: denied { search } for pid=27967 comm="rndc" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:ndc_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:30:03 server1 kernel: audit(1152628203.433:1305): arch=40000003 syscall=5 success=no exit=-13 a0=bfbb3460 a1=0 a2=0 a3=40 items=1 pid=27967 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="rndc" exe="/usr/sbin/rndc" subj=system_u:system_r:ndc_t Jul 11 23:30:03 server1 kernel: audit(1152628203.433:1305): cwd="/" Jul 11 23:30:03 server1 kernel: audit(1152628203.433:1305): item=0 name="/usr/lib/libisccfg.so.1" obj=root:object_r:ld_so_cache_t Jul 11 23:30:04 server1 named[1572]: shutting down Jul 11 23:30:04 server1 named[1572]: stopping command channel on 127.0.0.1#953 Jul 11 23:30:04 server1 ntpd_initres[2076]: parent died before we finished, exiting Jul 11 23:30:05 server1 named[1572]: no longer listening on 127.0.0.1#53 Jul 11 23:30:05 server1 named[1572]: no longer listening on 192.168.1.10#53 Jul 11 23:30:05 server1 named[1572]: exiting Jul 11 23:30:06 server1 kernel: Kernel logging (proc) stopped. Jul 11 23:30:06 server1 kernel: Kernel log daemon terminating. Jul 11 23:30:07 server1 exiting on signal 15 Jul 11 23:32:26 server1 syslogd 1.4.1: restart. Jul 11 23:32:27 server1 kernel: klogd 1.4.1, log source = /proc/kmsg started. Jul 11 23:32:27 server1 kernel: Linux version 2.6.17-1.2141_FC4 (bhcompile at hs20-bc1-4.build.redhat.com) (gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 Fri Jun 30 14:53:04 EDT 2006 Jul 11 23:32:27 server1 kernel: BIOS-provided physical RAM map: Jul 11 23:32:27 server1 kernel: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) Jul 11 23:32:27 server1 kernel: BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) Jul 11 23:32:27 server1 kernel: BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) Jul 11 23:32:27 server1 kernel: BIOS-e820: 0000000000100000 - 0000000007ff0000 (usable) Jul 11 23:32:27 server1 kernel: BIOS-e820: 0000000007ff0000 - 0000000007fffc00 (ACPI data) Jul 11 23:32:27 server1 kernel: BIOS-e820: 0000000007fffc00 - 0000000008000000 (ACPI NVS) Jul 11 23:32:27 server1 kernel: BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) Jul 11 23:32:27 server1 kernel: 0MB HIGHMEM available. Jul 11 23:32:27 server1 kernel: 127MB LOWMEM available. Jul 11 23:32:27 server1 kernel: Using x86 segment limits to approximate NX protection Jul 11 23:32:27 server1 kernel: DMI 2.2 present. Jul 11 23:32:28 server1 kernel: ACPI: PM-Timer IO Port: 0x1008 Jul 11 23:32:28 server1 kernel: Allocating PCI resources starting at 10000000 (gap: 08000000:f7ff0000) Jul 11 23:32:28 server1 kernel: Built 1 zonelists Jul 11 23:32:28 server1 kernel: Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet Jul 11 23:32:28 server1 kernel: Local APIC disabled by BIOS -- you can enable it with "lapic" Jul 11 23:32:28 server1 kernel: Enabling fast FPU save and restore... done. Jul 11 23:32:28 server1 kernel: Initializing CPU#0 Jul 11 23:32:28 server1 kernel: CPU 0 irqstacks, hard=c077d000 soft=c077e000 Jul 11 23:32:28 server1 kernel: PID hash table entries: 512 (order: 9, 2048 bytes) Jul 11 23:32:28 server1 kernel: Detected 331.886 MHz processor. Jul 11 23:32:28 server1 kernel: Using pmtmr for high-res timesource Jul 11 23:32:28 server1 kernel: Console: colour VGA+ 80x25 Jul 11 23:32:28 server1 kernel: Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Jul 11 23:32:28 server1 kernel: Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Jul 11 23:32:28 server1 kernel: Memory: 123604k/131008k available (1977k kernel code, 6868k reserved, 1358k data, 212k init, 0k highmem) Jul 11 23:32:28 server1 kernel: Checking if this processor honours the WP bit even in supervisor mode... Ok. Jul 11 23:32:28 server1 named: /usr/sbin/named-checkconf: error while loading shared libraries: libbind9.so.0: cannot open shared object file: Permission denied Jul 11 23:32:28 server1 kernel: Calibrating delay using timer specific routine.. 664.55 BogoMIPS (lpj=1329111) Jul 11 23:32:28 server1 kernel: Security Framework v1.0.0 initialized Jul 11 23:32:28 server1 kernel: SELinux: Initializing. Jul 11 23:32:29 server1 kernel: SELinux: Starting in permissive mode Jul 11 23:32:29 server1 kernel: selinux_register_security: Registering secondary module capability Jul 11 23:32:29 server1 kernel: Capability LSM initialized as secondary Jul 11 23:32:29 server1 kernel: Mount-cache hash table entries: 512 Jul 11 23:32:29 server1 kernel: CPU: L1 I cache: 16K, L1 D cache: 16K Jul 11 23:32:29 server1 kernel: CPU: L2 cache: 256K Jul 11 23:32:29 server1 kernel: Intel machine check architecture supported. Jul 11 23:32:29 server1 kernel: Intel machine check reporting enabled on CPU#0. Jul 11 23:32:29 server1 kernel: CPU: Intel Mobile Pentium II stepping 0a Jul 11 23:32:29 server1 kernel: Checking 'hlt' instruction... OK. Jul 11 23:32:29 server1 kernel: ACPI: setting ELCR to 0200 (from 0800) Jul 11 23:32:29 server1 kernel: checking if image is initramfs... it is Jul 11 23:32:29 server1 kernel: Freeing initrd memory: 1695k freed Jul 11 23:32:29 server1 kernel: NET: Registered protocol family 16 Jul 11 23:32:29 server1 kernel: ACPI: bus type pci registered Jul 11 23:32:29 server1 kernel: PCI: PCI BIOS revision 2.10 entry at 0xfd96f, last bus=10 Jul 11 23:32:29 server1 kernel: Setting up standard PCI resources Jul 11 23:32:29 server1 kernel: ACPI: Subsystem revision 20060127 Jul 11 23:32:29 server1 kernel: ACPI: Interpreter enabled Jul 11 23:32:30 server1 kernel: ACPI: Using PIC for interrupt routing Jul 11 23:32:30 server1 kernel: ACPI: PCI Root Bridge [PCI] (0000:00) Jul 11 23:32:30 server1 kernel: PCI quirk: region 1000-103f claimed by PIIX4 ACPI Jul 11 23:32:30 server1 kernel: PCI quirk: region 1040-104f claimed by PIIX4 SMB Jul 11 23:32:30 server1 kernel: PIIX4 devres C PIO at 15e8-15ef Jul 11 23:32:30 server1 kernel: PIIX4 devres I PIO at 03f0-03f7 Jul 11 23:32:30 server1 kernel: PIIX4 devres J PIO at 002e-002f Jul 11 23:32:30 server1 kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11 15) Jul 11 23:32:30 server1 kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 10 *11 15) Jul 11 23:32:31 server1 kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 15) Jul 11 23:32:31 server1 kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 10 *11 15) Jul 11 23:32:31 server1 kernel: ACPI: Power Resource [FANP] (off) Jul 11 23:32:31 server1 kernel: Linux Plug and Play Support v0.97 (c) Adam Belay Jul 11 23:32:31 server1 kernel: pnp: PnP ACPI init Jul 11 23:32:31 server1 auditd[1579]: Init complete, auditd 1.0.14 listening for events Jul 11 23:32:31 server1 kernel: pnp: PnP ACPI: found 16 devices Jul 11 23:32:31 server1 kernel: usbcore: registered new driver usbfs Jul 11 23:32:31 server1 kernel: usbcore: registered new driver hub Jul 11 23:32:31 server1 kernel: PCI: Using ACPI for IRQ routing Jul 11 23:32:31 server1 kernel: PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report Jul 11 23:32:31 server1 kernel: PCI: Ignore bogus resource 6 [0:0] of 0000:01:00.0 Jul 11 23:32:31 server1 kernel: PCI: Bridge: 0000:00:01.0 Jul 11 23:32:31 server1 kernel: IO window: disabled. Jul 11 23:32:31 server1 kernel: MEM window: f4200000-f47fffff Jul 11 23:32:31 server1 kernel: PREFETCH window: f5000000-f5ffffff Jul 11 23:32:31 server1 kernel: PCI: Bus 2, cardbus bridge: 0000:00:02.0 Jul 11 23:32:31 server1 kernel: IO window: 00001400-000014ff Jul 11 23:32:31 server1 kernel: IO window: 00001c00-00001cff Jul 11 23:32:31 server1 kernel: PREFETCH window: 10000000-11ffffff Jul 11 23:32:31 server1 kernel: MEM window: 12000000-13ffffff Jul 11 23:32:32 server1 kernel: PCI: Bus 6, cardbus bridge: 0000:00:02.1 Jul 11 23:32:32 server1 kernel: IO window: 00002400-000024ff Jul 11 23:32:32 server1 kernel: IO window: 00002800-000028ff Jul 11 23:32:32 server1 kernel: PREFETCH window: 14000000-15ffffff Jul 11 23:32:32 server1 kernel: MEM window: 16000000-17ffffff Jul 11 23:32:32 server1 kernel: ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 Jul 11 23:32:32 server1 kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 Jul 11 23:32:32 server1 kernel: ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11 Jul 11 23:32:32 server1 kernel: ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11 Jul 11 23:32:32 server1 kernel: NET: Registered protocol family 2 Jul 11 23:32:32 server1 kernel: IP route cache hash table entries: 1024 (order: 0, 4096 bytes) Jul 11 23:32:32 server1 kernel: TCP established hash table entries: 4096 (order: 4, 65536 bytes) Jul 11 23:32:32 server1 kernel: TCP bind hash table entries: 2048 (order: 3, 40960 bytes) Jul 11 23:32:32 server1 kernel: TCP: Hash tables configured (established 4096 bind 2048) Jul 11 23:32:33 server1 kernel: TCP reno registered Jul 11 23:32:33 server1 kernel: Simple Boot Flag at 0x36 set to 0x1 Jul 11 23:32:33 server1 kernel: * Found PM-Timer Bug on this chipset. Due to workarounds for a bug, Jul 11 23:32:33 server1 kernel: * this time source is slow. Consider trying other time sources (clock=) Jul 11 23:32:33 server1 kernel: IBM machine detected. Enabling interrupts during APM calls. Jul 11 23:32:33 server1 kernel: apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) Jul 11 23:32:33 server1 kernel: apm: overridden by ACPI. Jul 11 23:32:33 server1 kernel: audit: initializing netlink socket (disabled) Jul 11 23:32:33 server1 kernel: audit(1152660675.080:1): initialized Jul 11 23:32:33 server1 kernel: Total HugeTLB memory allocated, 0 Jul 11 23:32:33 server1 kernel: VFS: Disk quotas dquot_6.5.1 Jul 11 23:32:33 server1 kernel: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Jul 11 23:32:33 server1 kernel: SELinux: Registering netfilter hooks Jul 11 23:32:33 server1 kernel: Initializing Cryptographic API Jul 11 23:32:33 server1 kernel: ksign: Installing public key data Jul 11 23:32:33 server1 kernel: Loading keyring Jul 11 23:32:33 server1 kernel: - Added public key CECC7E59912DB2CA Jul 11 23:32:33 server1 kernel: - User ID: Red Hat, Inc. (Kernel Module GPG key) Jul 11 23:32:33 server1 kernel: io scheduler noop registered Jul 11 23:32:33 server1 kernel: io scheduler anticipatory registered Jul 11 23:32:33 server1 kernel: io scheduler deadline registered Jul 11 23:32:33 server1 kernel: io scheduler cfq registered (default) Jul 11 23:32:33 server1 kernel: Limiting direct PCI/PCI transfers. Jul 11 23:32:33 server1 kernel: pci_hotplug: PCI Hot Plug PCI Core version: 0.5 Jul 11 23:32:33 server1 kernel: ACPI: Fan [FAN] (off) Jul 11 23:32:33 server1 kernel: ACPI: CPU0 (power states: C1[C1] C2[C2]) Jul 11 23:32:33 server1 kernel: ACPI: Processor [CPU] (supports 8 throttling states) Jul 11 23:32:33 server1 kernel: ACPI: Thermal Zone [THM0] (64 C) Jul 11 23:32:33 server1 kernel: isapnp: Scanning for PnP cards... Jul 11 23:32:33 server1 kernel: isapnp: No Plug & Play device found Jul 11 23:32:33 server1 kernel: Real Time Clock Driver v1.12ac Jul 11 23:32:33 server1 kernel: Non-volatile memory driver v1.2 Jul 11 23:32:34 server1 kernel: Linux agpgart interface v0.101 (c) Dave Jones Jul 11 23:32:34 server1 kernel: agpgart: Detected an Intel 440BX Chipset. Jul 11 23:32:34 server1 kernel: agpgart: AGP aperture is 64M @ 0xf8000000 Jul 11 23:32:34 server1 kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled Jul 11 23:32:34 server1 kernel: pnp: Device 00:09 activated. Jul 11 23:32:34 server1 kernel: 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Jul 11 23:32:34 server1 kernel: RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize Jul 11 23:32:34 server1 kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 Jul 11 23:32:34 server1 kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Jul 11 23:32:34 server1 kernel: PIIX4: IDE controller at PCI slot 0000:00:06.1 Jul 11 23:32:34 server1 kernel: PIIX4: chipset revision 1 Jul 11 23:32:34 server1 kernel: PIIX4: not 100% native mode: will probe irqs later Jul 11 23:32:34 server1 kernel: ide0: BM-DMA at 0x1800-0x1807, BIOS settings: hda:DMA, hdb:pio Jul 11 23:32:34 server1 kernel: ide1: BM-DMA at 0x1808-0x180f, BIOS settings: hdc:pio, hdd:pio Jul 11 23:32:34 server1 kernel: hda: IBM-DBCA-206480, ATA DISK drive Jul 11 23:32:34 server1 kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Jul 11 23:32:34 server1 kernel: hda: max request size: 128KiB Jul 11 23:32:34 server1 kernel: hda: 12594960 sectors (6448 MB) w/420KiB Cache, CHS=13328/15/63, UDMA(33) Jul 11 23:32:34 server1 kernel: hda: cache flushes not supported Jul 11 23:32:35 server1 kernel: hda: hda1 hda2 Jul 11 23:32:35 server1 kernel: ide-floppy driver 0.99.newide Jul 11 23:32:35 server1 kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 Jul 11 23:32:35 server1 kernel: Yenta: CardBus bridge found at 0000:00:02.0 [1014:0130] Jul 11 23:32:35 server1 kernel: Yenta: Using INTVAL to route CSC interrupts to PCI Jul 11 23:32:35 server1 kernel: Yenta: Routing CardBus interrupts to PCI Jul 11 23:32:35 server1 kernel: Yenta TI: socket 0000:00:02.0, mfunc 0x00001000, devctl 0x66 Jul 11 23:32:35 server1 kernel: Yenta: ISA IRQ mask 0x04b8, PCI irq 11 Jul 11 23:32:35 server1 kernel: Socket status: 30000006 Jul 11 23:32:35 server1 kernel: ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11 Jul 11 23:32:35 server1 kernel: Yenta: CardBus bridge found at 0000:00:02.1 [1014:0130] Jul 11 23:32:35 server1 kernel: Yenta: Using INTVAL to route CSC interrupts to PCI Jul 11 23:32:35 server1 kernel: Yenta: Routing CardBus interrupts to PCI Jul 11 23:32:35 server1 kernel: Yenta TI: socket 0000:00:02.1, mfunc 0x00001000, devctl 0x66 Jul 11 23:32:35 server1 kernel: Yenta: ISA IRQ mask 0x04b8, PCI irq 11 Jul 11 23:32:35 server1 kernel: Socket status: 30000010 Jul 11 23:32:35 server1 kernel: usbcore: registered new driver libusual Jul 11 23:32:35 server1 kernel: usbcore: registered new driver hiddev Jul 11 23:32:35 server1 kernel: usbcore: registered new driver usbhid Jul 11 23:32:35 server1 kernel: drivers/usb/input/hid-core.c: v2.6:USB HID core driver Jul 11 23:32:35 server1 kernel: PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:MOUS] at 0x60,0x64 irq 1,12 Jul 11 23:32:35 server1 kernel: serio: i8042 AUX port at 0x60,0x64 irq 12 Jul 11 23:32:35 server1 kernel: serio: i8042 KBD port at 0x60,0x64 irq 1 Jul 11 23:32:35 server1 kernel: mice: PS/2 mouse device common for all mice Jul 11 23:32:35 server1 kernel: md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27 Jul 11 23:32:35 server1 kernel: md: bitmap version 4.39 Jul 11 23:32:35 server1 kernel: TCP bic registered Jul 11 23:32:35 server1 kernel: Initializing IPsec netlink socket Jul 11 23:32:35 server1 kernel: NET: Registered protocol family 1 Jul 11 23:32:36 server1 kernel: NET: Registered protocol family 17 Jul 11 23:32:36 server1 kernel: Using IPI Shortcut mode Jul 11 23:32:36 server1 kernel: ACPI wakeup devices: Jul 11 23:32:36 server1 kernel: LID SLPB CRD0 CRD1 COMA USB MODM Jul 11 23:32:36 server1 kernel: ACPI: (supports S0 S1 S3 S4 S5) Jul 11 23:32:37 server1 kernel: Freeing unused kernel memory: 212k freed Jul 11 23:32:37 server1 kernel: Write protecting the kernel read-only data: 924k Jul 11 23:32:37 server1 kernel: input: AT Translated Set 2 keyboard as /class/input/input0 Jul 11 23:32:37 server1 kernel: device-mapper: 4.6.0-ioctl (2006-02-17) initialised: dm-devel at redhat.com Jul 11 23:32:37 server1 kernel: pccard: PCMCIA card inserted into slot 1 Jul 11 23:32:37 server1 kernel: kjournald starting. Commit interval 5 seconds Jul 11 23:32:37 server1 kernel: EXT3-fs: mounted filesystem with ordered data mode. Jul 11 23:32:37 server1 kernel: IBM TrackPoint firmware: 0x0b, buttons: 3/3 Jul 11 23:32:37 server1 kernel: input: TPPS/2 IBM TrackPoint as /class/input/input1 Jul 11 23:32:37 server1 kernel: audit(1152660681.792:2): enforcing=1 old_enforcing=0 auid=4294967295 Jul 11 23:32:37 server1 kernel: security: 3 users, 6 roles, 890 types, 110 bools Jul 11 23:32:37 server1 kernel: security: 55 classes, 244688 rules Jul 11 23:32:37 server1 kernel: SELinux: Completing initialization. Jul 11 23:32:37 server1 kernel: SELinux: Setting up existing superblocks. Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev dm-0, type ext3), uses xattr Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses genfs_contexts Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev devpts, type devpts), uses transition SIDs Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev pipefs, type pipefs), uses task SIDs Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev sockfs, type sockfs), uses task SIDs Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev proc, type proc), uses genfs_contexts Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev bdev, type bdev), uses genfs_contexts Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts Jul 11 23:32:39 server1 kernel: audit(1152660688.364:3): policy loaded auid=4294967295 Jul 11 23:32:39 server1 kernel: audit(1152660688.396:4): avc: denied { search } for pid=537 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:39 server1 kernel: audit(1152660688.408:5): avc: denied { search } for pid=539 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:39 server1 kernel: audit(1152660688.428:6): avc: denied { search } for pid=538 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:39 server1 kernel: audit(1152660688.444:7): avc: denied { search } for pid=540 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:39 server1 kernel: audit(1152660688.464:8): avc: denied { search } for pid=541 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:39 server1 kernel: audit(1152660688.480:9): avc: denied { search } for pid=542 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:39 server1 kernel: audit(1152660688.508:10): avc: denied { search } for pid=543 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:39 server1 kernel: audit(1152660688.524:11): avc: denied { search } for pid=544 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:39 server1 kernel: audit(1152660688.552:12): avc: denied { search } for pid=545 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:40 server1 kernel: audit(1152660688.564:13): avc: denied { search } for pid=547 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:40 server1 kernel: audit(1152660688.588:14): avc: denied { search } for pid=546 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:40 server1 kernel: audit(1152660688.600:15): avc: denied { search } for pid=548 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:40 server1 kernel: audit(1152660688.644:16): avc: denied { search } for pid=549 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:41 server1 kernel: audit(1152660688.656:17): avc: denied { search } for pid=550 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:41 server1 kernel: audit(1152660688.680:18): avc: denied { search } for pid=551 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:42 server1 kernel: audit(1152660688.696:19): avc: denied { search } for pid=552 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:42 server1 kernel: audit(1152660688.724:20): avc: denied { search } for pid=553 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:42 server1 kernel: audit(1152660688.736:21): avc: denied { search } for pid=554 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:42 server1 kernel: audit(1152660688.748:22): avc: denied { search } for pid=556 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:42 server1 kernel: audit(1152660688.772:23): avc: denied { search } for pid=555 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:42 server1 kernel: audit(1152660688.796:24): avc: denied { search } for pid=557 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:42 server1 kernel: audit(1152660688.808:25): avc: denied { search } for pid=558 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:42 server1 kernel: audit(1152660688.836:26): avc: denied { search } for pid=559 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:42 server1 kernel: audit(1152660688.848:27): avc: denied { search } for pid=560 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:42 server1 kernel: audit(1152660688.876:28): avc: denied { search } for pid=561 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:42 server1 kernel: audit(1152660688.888:29): avc: denied { search } for pid=563 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:42 server1 kernel: audit(1152660688.912:30): avc: denied { search } for pid=562 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:42 server1 kernel: audit(1152660688.924:31): avc: denied { search } for pid=564 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:43 server1 kernel: audit(1152660688.948:32): avc: denied { search } for pid=565 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:43 server1 kernel: audit(1152660688.964:33): avc: denied { search } for pid=566 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:43 server1 kernel: audit(1152660688.988:34): avc: denied { search } for pid=567 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:43 server1 kernel: audit(1152660689.000:35): avc: denied { search } for pid=568 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:43 server1 ntpdate[1814]: can't find host 0.pool.ntp.org Jul 11 23:32:43 server1 kernel: audit(1152660689.028:36): avc: denied { search } for pid=570 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:43 server1 ntpdate[1814]: can't find host 1.pool.ntp.org Jul 11 23:32:43 server1 kernel: audit(1152660689.040:37): avc: denied { search } for pid=571 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:43 server1 ntpdate[1814]: can't find host 2.pool.ntp.org Jul 11 23:32:43 server1 kernel: audit(1152660689.064:38): avc: denied { search } for pid=569 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:43 server1 kernel: audit(1152660689.076:39): avc: denied { search } for pid=572 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:43 server1 kernel: audit(1152660689.124:40): avc: denied { search } for pid=574 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:43 server1 kernel: audit(1152660689.136:41): avc: denied { search } for pid=575 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:43 server1 kernel: audit(1152660689.160:42): avc: denied { search } for pid=576 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:43 server1 kernel: audit(1152660689.172:43): avc: denied { search } for pid=577 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:43 server1 kernel: SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts Jul 11 23:32:43 server1 kernel: audit(1152660692.353:44): avc: denied { search } for pid=595 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:43 server1 kernel: audit(1152660692.369:45): avc: denied { search } for pid=596 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:43 server1 kernel: audit(1152660692.393:46): avc: denied { search } for pid=597 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:43 server1 kernel: audit(1152660692.405:47): avc: denied { search } for pid=598 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:44 server1 kernel: audit(1152660692.437:48): avc: denied { search } for pid=600 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:44 server1 kernel: audit(1152660692.457:49): avc: denied { search } for pid=599 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:44 server1 kernel: audit(1152660692.469:50): avc: denied { search } for pid=602 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:45 server1 kernel: audit(1152660692.481:51): avc: denied { search } for pid=601 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:45 server1 kernel: audit(1152660692.509:52): avc: denied { search } for pid=603 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:45 server1 kernel: audit(1152660692.525:53): avc: denied { search } for pid=604 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:46 server1 kernel: audit(1152660692.549:54): avc: denied { search } for pid=605 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:46 server1 kernel: audit(1152660692.565:55): avc: denied { search } for pid=606 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:46 server1 kernel: audit(1152660692.597:56): avc: denied { search } for pid=608 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:46 server1 kernel: audit(1152660692.605:57): avc: denied { search } for pid=607 comm="hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:46 server1 kernel: audit(1152660692.621:58): avc: denied { search } for pid=609 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:46 server1 kernel: audit(1152660692.641:59): avc: denied { search } for pid=610 comm="default.hotplug" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:46 server1 kernel: Floppy drive(s): fd0 is 1.44M Jul 11 23:32:46 server1 kernel: FDC 0 is a National Semiconductor PC87306 Jul 11 23:32:46 server1 kernel: ACPI: PCI Interrupt 0000:00:05.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 Jul 11 23:32:46 server1 kernel: cs46xx: failure waiting for FIFO command to complete Jul 11 23:32:46 server1 kernel: gameport: CS46xx Gameport is pci0000:00:05.0/gameport0, speed 1491kHz Jul 11 23:32:46 server1 kernel: piix4_smbus 0000:00:06.3: Found 0000:00:06.3 device Jul 11 23:32:46 server1 kernel: piix4_smbus 0000:00:06.3: IBM Laptop detected; this module may corrupt your serial eeprom! Refusing to load module! Jul 11 23:32:46 server1 kernel: piix4_smbus: probe of 0000:00:06.3 failed with error -1 Jul 11 23:32:46 server1 kernel: USB Universal Host Controller Interface driver v3.0 Jul 11 23:32:46 server1 kernel: ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 Jul 11 23:32:46 server1 kernel: ACPI: PCI Interrupt 0000:00:06.2[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 Jul 11 23:32:46 server1 kernel: uhci_hcd 0000:00:06.2: UHCI Host Controller Jul 11 23:32:46 server1 kernel: uhci_hcd 0000:00:06.2: new USB bus registered, assigned bus number 1 Jul 11 23:32:46 server1 kernel: uhci_hcd 0000:00:06.2: irq 11, io base 0x00001820 Jul 11 23:32:46 server1 kernel: usb usb1: configuration #1 chosen from 1 choice Jul 11 23:32:46 server1 kernel: hub 1-0:1.0: USB hub found Jul 11 23:32:46 server1 kernel: hub 1-0:1.0: 2 ports detected Jul 11 23:32:46 server1 kernel: audit(1152660724.983:60): avc: denied { search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hwclock_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:46 server1 kernel: audit(1152660724.983:61): avc: denied { search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hwclock_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:46 server1 kernel: audit(1152660724.983:62): avc: denied { search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hwclock_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:46 server1 kernel: audit(1152660724.983:63): avc: denied { search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hwclock_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:46 server1 kernel: audit(1152660724.983:64): avc: denied { search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hwclock_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:46 server1 kernel: audit(1152660724.983:65): avc: denied { search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hwclock_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:46 server1 kernel: audit(1152660724.983:66): avc: denied { search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hwclock_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:46 server1 kernel: audit(1152660724.983:67): avc: denied { search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:hwclock_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:46 server1 kernel: ACPI: AC Adapter [AC] (on-line) Jul 11 23:32:46 server1 kernel: ACPI: Battery Slot [BAT1] (battery present) Jul 11 23:32:46 server1 kernel: ACPI: Battery Slot [BAT2] (battery absent) Jul 11 23:32:46 server1 kernel: ACPI: Power Button (FF) [PWRF] Jul 11 23:32:46 server1 kernel: ACPI: Lid Switch [LID] Jul 11 23:32:46 server1 kernel: ACPI: Sleep Button (CM) [SLPB] Jul 11 23:32:46 server1 kernel: ibm_acpi: IBM ThinkPad ACPI Extras v0.12a Jul 11 23:32:46 server1 kernel: ibm_acpi: http://ibm-acpi.sf.net/ Jul 11 23:32:46 server1 kernel: ibm_acpi: dock device not present Jul 11 23:32:46 server1 kernel: ibm_acpi: bay device not present Jul 11 23:32:46 server1 kernel: ACPI: Video Device [VGA] (multi-head: yes rom: no post: no) Jul 11 23:32:46 server1 kernel: md: Autodetecting RAID arrays. Jul 11 23:32:46 server1 kernel: md: autorun ... Jul 11 23:32:47 server1 kernel: md: ... autorun DONE. Jul 11 23:32:47 server1 kernel: EXT3 FS on dm-0, internal journal Jul 11 23:32:47 server1 kernel: kjournald starting. Commit interval 5 seconds Jul 11 23:32:47 server1 kernel: EXT3 FS on hda1, internal journal Jul 11 23:32:47 server1 kernel: EXT3-fs: mounted filesystem with ordered data mode. Jul 11 23:32:47 server1 kernel: SELinux: initialized (dev hda1, type ext3), uses xattr Jul 11 23:32:47 server1 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Jul 11 23:32:47 server1 kernel: Adding 262136k swap on /dev/VolGroup00/LogVol01. Priority:-1 extents:1 across:262136k Jul 11 23:32:47 server1 kernel: SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts Jul 11 23:32:47 server1 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team Jul 11 23:32:47 server1 kernel: Netfilter messages via NETLINK v0.30. Jul 11 23:32:47 server1 kernel: ip_conntrack version 2.4 (1023 buckets, 8184 max) - 224 bytes per conntrack Jul 11 23:32:47 server1 kernel: pcmcia: Detected deprecated PCMCIA ioctl usage from process: cardmgr. Jul 11 23:32:47 server1 kernel: pcmcia: This interface will soon be removed from the kernel; please expect breakage unless you upgrade to new tools. Jul 11 23:32:47 server1 kernel: pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for details. Jul 11 23:32:47 server1 kernel: cs: IO port probe 0xc00-0xcff: excluding 0xcf8-0xcff Jul 11 23:32:47 server1 kernel: cs: IO port probe 0xc00-0xcff: excluding 0xcf8-0xcff Jul 11 23:32:47 server1 kernel: cs: IO port probe 0x800-0x8ff: clean. Jul 11 23:32:47 server1 kernel: cs: IO port probe 0x800-0x8ff: clean. Jul 11 23:32:47 server1 kernel: cs: IO port probe 0x100-0x4ff: excluding 0x170-0x177 0x370-0x377 0x3b8-0x3df 0x4d0-0x4d7 Jul 11 23:32:47 server1 kernel: cs: IO port probe 0x100-0x4ff: excluding 0x170-0x177 0x370-0x377 0x3b8-0x3df 0x4d0-0x4d7 Jul 11 23:32:47 server1 kernel: cs: IO port probe 0xa00-0xaff: clean. Jul 11 23:32:47 server1 kernel: cs: IO port probe 0xa00-0xaff: clean. Jul 11 23:32:47 server1 kernel: cs: memory probe 0xa0000000-0xa0ffffff: clean. Jul 11 23:32:47 server1 kernel: pcmcia: registering new device pcmcia1.0 Jul 11 23:32:47 server1 kernel: eth0: 3Com 3c589, io 0x300, irq 3, hw_addr 00:10:5A:6A:A4:2F Jul 11 23:32:47 server1 kernel: 8K FIFO split 5:3 Rx:Tx, auto xcvr Jul 11 23:32:47 server1 kernel: audit(1152628341.239:68): avc: denied { search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628341.239:69): avc: denied { search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628341.239:70): avc: denied { search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628341.239:71): avc: denied { search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628341.239:72): avc: denied { search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628341.239:73): avc: denied { search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628341.239:74): avc: denied { search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628341.239:75): avc: denied { search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628341.275:76): avc: denied { search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628341.275:77): avc: denied { search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628341.275:78): avc: denied { search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628341.279:79): avc: denied { search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628341.279:80): avc: denied { search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628341.279:81): avc: denied { search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628341.279:82): avc: denied { search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628341.279:83): avc: denied { search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: eth0: flipped to 10base2 Jul 11 23:32:47 server1 kernel: audit(1152628348.743:84): avc: denied { search } for pid=1545 comm="named-checkconf" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:named_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628348.775:85): avc: denied { search } for pid=1545 comm="named-checkconf" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:named_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628348.779:86): avc: denied { search } for pid=1545 comm="named-checkconf" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:named_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628348.779:87): avc: denied { search } for pid=1545 comm="named-checkconf" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:named_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628348.779:88): avc: denied { search } for pid=1545 comm="named-checkconf" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:named_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628348.787:89): avc: denied { search } for pid=1547 comm="named-checkconf" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:named_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 kernel: audit(1152628348.787:90): avc: denied { search } for pid=1547 comm="named-checkconf" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:named_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:47 server1 ntpdate[1814]: no server suitable for synchronization found Jul 11 23:32:47 server1 kernel: audit(1152628348.787:91): avc: denied { search } for pid=1547 comm="named-checkconf" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:named_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:48 server1 kernel: audit(1152628348.787:92): avc: denied { search } for pid=1547 comm="named-checkconf" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:named_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:48 server1 kernel: audit(1152628348.787:93): avc: denied { search } for pid=1547 comm="named-checkconf" name="usr" dev=dm-0 ino=1212417 scontext=system_u:system_r:named_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir Jul 11 23:32:48 server1 kernel: audit(1152628351.123:94): audit_pid=1579 old=0 by auid=4294967295 subj=system_u:system_r:auditd_t Jul 11 23:32:48 server1 kernel: SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts Jul 11 23:32:48 server1 kernel: SELinux: initialized (dev autofs, type autofs), uses genfs_contexts Jul 11 23:32:48 server1 kernel: NET: Registered protocol family 10 Jul 11 23:32:48 server1 kernel: lo: Disabled Privacy Extensions Jul 11 23:32:48 server1 kernel: IPv6 over IPv4 tunneling driver Jul 11 23:32:50 server1 gpm[1844]: *** info [startup.c(95)]: Jul 11 23:32:50 server1 gpm[1844]: Started gpm successfully. Entered daemon mode. Jul 11 23:32:50 server1 gpm[1844]: *** info [mice.c(1766)]: Jul 11 23:32:50 server1 gpm[1844]: imps2: Auto-detected intellimouse PS/2 Jul 11 23:33:02 server1 iiimd[1881]: started. Jul 11 23:33:15 server1 kernel: eth0: coax cable problem Jul 11 23:33:20 server1 kernel: eth0: flipped to 10baseT ZANG Land -------------------- http://zangland.com/ From jbrindle at tresys.com Sat Jul 15 08:07:21 2006 From: jbrindle at tresys.com (Joshua Brindle) Date: Sat, 15 Jul 2006 04:07:21 -0400 Subject: CVS-2006-3626 local privilege escalation stopped by targeted policy Message-ID: <6FE441CD9F0C0C479F2D88F959B015882987B8@exchange.columbia.tresys.com> The local privilege escalation from http://lists.grok.org.uk/pipermail/full-disclosure/2006-July/047907.html is stopped by selinux targeted policy (both old and reference policy). I used a rhel4 test vm to demonstrate below. This was released yesterday so there is no updated kernel rpm yet. This requires a.out support to exploit, you'll have to grab binfmt_aout.c from the appropriate kernel sources (it isn't shipped with RHEL or Fedora) and use a module makefile to build it, then insert it. Setenforce 0 [jbrindle at rhel4-dev ~]$ id uid=501(jbrindle) gid=502(jbrindle) groups=502(jbrindle) context=user_u:system_r:unconfined_t [jbrindle at rhel4-dev ~]$ ./h00lyshit /bin/ash.static preparing trying to exploit /bin/ash.static sh-3.00# id uid=0(root) gid=502(jbrindle) groups=502(jbrindle) context=user_u:system_r:unconfined_t (may take a few times to get since it's a race, clear your cache between tries) Setenforce 1 [jbrindle at rhel4-dev ~]$ ./h00lyshit /bin/ash.static preparing trying to exploit /bin/ash.static failed: Permission denied All related denials: audit(1152957171.464:5): avc: denied { setattr } for pid=6291 comm="h00lyshit" name="environ" dev=proc ino=412286986 scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:unconfined_t tclass=file audit(1152957171.465:6): avc: denied { execute } for pid=6292 comm="h00lyshit" name="environ" dev=proc ino=412286986 scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:unconfined_t tclass=file audit(1152957171.467:7): avc: denied { execute_no_trans } for pid=6292 comm="h00lyshit" name="environ" dev=proc ino=412286986 scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:unconfined_t tclass=file From selinux at gmail.com Sat Jul 15 16:50:59 2006 From: selinux at gmail.com (Tom London) Date: Sat, 15 Jul 2006 09:50:59 -0700 Subject: key {search write} for xdm_t (and /sbin/su)? Message-ID: <4c4ba1530607150950k2ed27be9lbbfc1f6313c8bf44@mail.gmail.com> Running latest rawhide, targeted/enforcing. Notice the following in /var/log/audit/audit.log: type=AVC msg=audit(1152981861.606:20): avc: denied { search } for pid=2505 comm="gdm-binary" scontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=key type=SYSCALL msg=audit(1152981861.606:20): arch=40000003 syscall=288 success=no exit=-13 a0=3 a1=292e05f8 a2=35ce48 a3=7ce759 items=0 ppid=2471 pid=2505 auid=500 uid=0 gid=500 euid=0 suid=0 fsuid=0 egid=0 sgid=500 fsgid=0 tty=(none) comm="gdm-binary" exe="/usr/sbin/gdm-binary" subj=system_u:system_r:xdm_t:s0-s0:c0.c255 key=(null) type=AVC msg=audit(1152981872.490:26): avc: denied { write } for pid=2804 comm="gdm-binary" scontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=key type=SYSCALL msg=audit(1152981872.490:26): arch=40000003 syscall=288 success=no exit=-13 a0=8 a1=fffffffc a2=fffffffd a3=1f4 items=0 ppid=2471 pid=2804 auid=4294967295 uid=500 gid=500 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) comm="gdm-binary" exe="/usr/sbin/gdm-binary" subj=system_u:system_r:xdm_t:s0-s0:c0.c255 key=(null) and type=AVC msg=audit(1152981908.300:32): avc: denied { write } for pid=3037 comm="su" scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=key type=SYSCALL msg=audit(1152981908.300:32): arch=40000003 syscall=288 success=no exit=-13 a0=8 a1=fffffffc a2=fffffffd a3=0 items=0 ppid=2984 pid=3037 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=pts0 comm="su" exe="/bin/su" subj=user_u:system_r:unconfined_t:s0 key=(null) Believe the second results from me entering 'su -'. tom -- Tom London From paul at city-fan.org Sat Jul 15 18:03:31 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 15 Jul 2006 19:03:31 +0100 Subject: My FC4 server doesn't work after updated In-Reply-To: <20060715014306.45281.qmail@web10512.mail.bbt.yahoo.co.jp> References: <20060715014306.45281.qmail@web10512.mail.bbt.yahoo.co.jp> Message-ID: <1152986612.23617.2.camel@laurel.intra.city-fan.org> On Sat, 2006-07-15 at 10:43 +0900, Mike Zang wrote: > My FC4 server worked welll. It doesn't work after I updated by yum. > Here is audit avc information from /var/log/message, what can I do? > Jul 11 23:29:11 server1 shutdown: shutting down for system reboot > Jul 11 23:29:12 server1 init: Switching to runlevel: 6 > Jul 11 23:29:14 server1 ainit: Operation not permitted > Jul 11 23:29:14 server1 ainit: Operation not permitted > Jul 11 23:29:15 server1 dbus: avc: 5 AV entries and 5/512 buckets used, > longest chain length 1 > Jul 11 23:29:22 server1 xfs[2013]: terminating > Jul 11 23:29:36 server1 nmbd[2024]: [2006/07/11 23:29:36, 0] > nmbd/nmbd.c:terminate(56) > Jul 11 23:29:37 server1 nmbd[2024]: Got SIGTERM: going down... > Jul 11 23:30:00 server1 ntpd[1892]: ntpd exiting on signal 15 > Jul 11 23:30:01 server1 auditd[1631]: The audit daemon is exiting. > Jul 11 23:30:01 server1 kernel: audit(1152628201.909:1300): audit_pid=0 > old=1631 by auid=4294967295 subj=system_u:system_r:auditd_t > Jul 11 23:30:03 server1 kernel: audit(1152628203.405:1301): avc: denied { > search } for pid=27967 comm="rndc" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:ndc_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:30:03 server1 kernel: audit(1152628203.405:1301): arch=40000003 > syscall=5 success=no exit=-13 a0=b7ff9406 a1=0 a2=0 a3=8 items=1 pid=27967 > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > tty=(none) comm="rndc" exe="/usr/sbin/rndc" subj=system_u:system_r:ndc_t > Jul 11 23:30:03 server1 kernel: audit(1152628203.405:1301): cwd="/" > Jul 11 23:30:03 server1 kernel: audit(1152628203.405:1301): item=0 > name="/usr/lib/libisccfg.so.1" obj=root:object_r:ld_so_cache_t > Jul 11 23:30:03 server1 kernel: audit(1152628203.425:1302): avc: denied { > search } for pid=27967 comm="rndc" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:ndc_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:30:03 server1 kernel: audit(1152628203.425:1302): arch=40000003 > syscall=5 success=no exit=-13 a0=bfbb3460 a1=0 a2=0 a3=40 items=1 pid=27967 > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > tty=(none) comm="rndc" exe="/usr/sbin/rndc" subj=system_u:system_r:ndc_t > Jul 11 23:30:03 server1 kernel: audit(1152628203.425:1302): cwd="/" > Jul 11 23:30:03 server1 kernel: audit(1152628203.425:1302): item=0 > name="/usr/lib/tls/i686/libisccfg.so.1" obj=root:object_r:ld_so_cache_t > Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1303): avc: denied { > search } for pid=27967 comm="rndc" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:ndc_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1303): arch=40000003 > syscall=5 success=no exit=-13 a0=bfbb3460 a1=0 a2=0 a3=40 items=1 pid=27967 > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > tty=(none) comm="rndc" exe="/usr/sbin/rndc" subj=system_u:system_r:ndc_t > Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1303): cwd="/" > Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1303): item=0 > name="/usr/lib/tls/libisccfg.so.1" obj=root:object_r:ld_so_cache_t > Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1304): avc: denied { > search } for pid=27967 comm="rndc" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:ndc_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1304): arch=40000003 > syscall=5 success=no exit=-13 a0=bfbb3460 a1=0 a2=0 a3=40 items=1 pid=27967 > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > tty=(none) comm="rndc" exe="/usr/sbin/rndc" subj=system_u:system_r:ndc_t > Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1304): cwd="/" > Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1304): item=0 > name="/usr/lib/i686/libisccfg.so.1" obj=root:object_r:ld_so_cache_t > Jul 11 23:30:03 server1 kernel: audit(1152628203.433:1305): avc: denied { > search } for pid=27967 comm="rndc" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:ndc_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:30:03 server1 kernel: audit(1152628203.433:1305): arch=40000003 > syscall=5 success=no exit=-13 a0=bfbb3460 a1=0 a2=0 a3=40 items=1 pid=27967 > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > tty=(none) comm="rndc" exe="/usr/sbin/rndc" subj=system_u:system_r:ndc_t > Jul 11 23:30:03 server1 kernel: audit(1152628203.433:1305): cwd="/" > Jul 11 23:30:03 server1 kernel: audit(1152628203.433:1305): item=0 > name="/usr/lib/libisccfg.so.1" obj=root:object_r:ld_so_cache_t > Jul 11 23:30:04 server1 named[1572]: shutting down > Jul 11 23:30:04 server1 named[1572]: stopping command channel on > 127.0.0.1#953 > Jul 11 23:30:04 server1 ntpd_initres[2076]: parent died before we finished, > exiting > Jul 11 23:30:05 server1 named[1572]: no longer listening on 127.0.0.1#53 > Jul 11 23:30:05 server1 named[1572]: no longer listening on 192.168.1.10#53 > Jul 11 23:30:05 server1 named[1572]: exiting > Jul 11 23:30:06 server1 kernel: Kernel logging (proc) stopped. > Jul 11 23:30:06 server1 kernel: Kernel log daemon terminating. > Jul 11 23:30:07 server1 exiting on signal 15 > Jul 11 23:32:26 server1 syslogd 1.4.1: restart. > Jul 11 23:32:27 server1 kernel: klogd 1.4.1, log source = /proc/kmsg > started. > Jul 11 23:32:27 server1 kernel: Linux version 2.6.17-1.2141_FC4 > (bhcompile at hs20-bc1-4.build.redhat.com) (gcc version 4.0.2 20051125 (Red > Hat 4.0.2-8)) #1 Fri Jun 30 14:53:04 EDT 2006 > Jul 11 23:32:27 server1 kernel: BIOS-provided physical RAM map: > Jul 11 23:32:27 server1 kernel: BIOS-e820: 0000000000000000 - > 000000000009fc00 (usable) > Jul 11 23:32:27 server1 kernel: BIOS-e820: 000000000009fc00 - > 00000000000a0000 (reserved) > Jul 11 23:32:27 server1 kernel: BIOS-e820: 00000000000e0000 - > 0000000000100000 (reserved) > Jul 11 23:32:27 server1 kernel: BIOS-e820: 0000000000100000 - > 0000000007ff0000 (usable) > Jul 11 23:32:27 server1 kernel: BIOS-e820: 0000000007ff0000 - > 0000000007fffc00 (ACPI data) > Jul 11 23:32:27 server1 kernel: BIOS-e820: 0000000007fffc00 - > 0000000008000000 (ACPI NVS) > Jul 11 23:32:27 server1 kernel: BIOS-e820: 00000000ffff0000 - > 0000000100000000 (reserved) > Jul 11 23:32:27 server1 kernel: 0MB HIGHMEM available. > Jul 11 23:32:27 server1 kernel: 127MB LOWMEM available. > Jul 11 23:32:27 server1 kernel: Using x86 segment limits to approximate NX > protection > Jul 11 23:32:27 server1 kernel: DMI 2.2 present. > Jul 11 23:32:28 server1 kernel: ACPI: PM-Timer IO Port: 0x1008 > Jul 11 23:32:28 server1 kernel: Allocating PCI resources starting at > 10000000 (gap: 08000000:f7ff0000) > Jul 11 23:32:28 server1 kernel: Built 1 zonelists > Jul 11 23:32:28 server1 kernel: Kernel command line: ro > root=/dev/VolGroup00/LogVol00 rhgb quiet > Jul 11 23:32:28 server1 kernel: Local APIC disabled by BIOS -- you can > enable it with "lapic" > Jul 11 23:32:28 server1 kernel: Enabling fast FPU save and restore... done. > Jul 11 23:32:28 server1 kernel: Initializing CPU#0 > Jul 11 23:32:28 server1 kernel: CPU 0 irqstacks, hard=c077d000 > soft=c077e000 > Jul 11 23:32:28 server1 kernel: PID hash table entries: 512 (order: 9, 2048 > bytes) > Jul 11 23:32:28 server1 kernel: Detected 331.886 MHz processor. > Jul 11 23:32:28 server1 kernel: Using pmtmr for high-res timesource > Jul 11 23:32:28 server1 kernel: Console: colour VGA+ 80x25 > Jul 11 23:32:28 server1 kernel: Dentry cache hash table entries: 16384 > (order: 4, 65536 bytes) > Jul 11 23:32:28 server1 kernel: Inode-cache hash table entries: 8192 > (order: 3, 32768 bytes) > Jul 11 23:32:28 server1 kernel: Memory: 123604k/131008k available (1977k > kernel code, 6868k reserved, 1358k data, 212k init, 0k highmem) > Jul 11 23:32:28 server1 kernel: Checking if this processor honours the WP > bit even in supervisor mode... Ok. > Jul 11 23:32:28 server1 named: /usr/sbin/named-checkconf: error while > loading shared libraries: libbind9.so.0: cannot open shared object file: > Permission denied > Jul 11 23:32:28 server1 kernel: Calibrating delay using timer specific > routine.. 664.55 BogoMIPS (lpj=1329111) > Jul 11 23:32:28 server1 kernel: Security Framework v1.0.0 initialized > Jul 11 23:32:28 server1 kernel: SELinux: Initializing. > Jul 11 23:32:29 server1 kernel: SELinux: Starting in permissive mode > Jul 11 23:32:29 server1 kernel: selinux_register_security: Registering > secondary module capability > Jul 11 23:32:29 server1 kernel: Capability LSM initialized as secondary > Jul 11 23:32:29 server1 kernel: Mount-cache hash table entries: 512 > Jul 11 23:32:29 server1 kernel: CPU: L1 I cache: 16K, L1 D cache: 16K > Jul 11 23:32:29 server1 kernel: CPU: L2 cache: 256K > Jul 11 23:32:29 server1 kernel: Intel machine check architecture supported. > Jul 11 23:32:29 server1 kernel: Intel machine check reporting enabled on > CPU#0. > Jul 11 23:32:29 server1 kernel: CPU: Intel Mobile Pentium II stepping 0a > Jul 11 23:32:29 server1 kernel: Checking 'hlt' instruction... OK. > Jul 11 23:32:29 server1 kernel: ACPI: setting ELCR to 0200 (from 0800) > Jul 11 23:32:29 server1 kernel: checking if image is initramfs... it is > Jul 11 23:32:29 server1 kernel: Freeing initrd memory: 1695k freed > Jul 11 23:32:29 server1 kernel: NET: Registered protocol family 16 > Jul 11 23:32:29 server1 kernel: ACPI: bus type pci registered > Jul 11 23:32:29 server1 kernel: PCI: PCI BIOS revision 2.10 entry at > 0xfd96f, last bus=10 > Jul 11 23:32:29 server1 kernel: Setting up standard PCI resources > Jul 11 23:32:29 server1 kernel: ACPI: Subsystem revision 20060127 > Jul 11 23:32:29 server1 kernel: ACPI: Interpreter enabled > Jul 11 23:32:30 server1 kernel: ACPI: Using PIC for interrupt routing > Jul 11 23:32:30 server1 kernel: ACPI: PCI Root Bridge [PCI] (0000:00) > Jul 11 23:32:30 server1 kernel: PCI quirk: region 1000-103f claimed by > PIIX4 ACPI > Jul 11 23:32:30 server1 kernel: PCI quirk: region 1040-104f claimed by > PIIX4 SMB > Jul 11 23:32:30 server1 kernel: PIIX4 devres C PIO at 15e8-15ef > Jul 11 23:32:30 server1 kernel: PIIX4 devres I PIO at 03f0-03f7 > Jul 11 23:32:30 server1 kernel: PIIX4 devres J PIO at 002e-002f > Jul 11 23:32:30 server1 kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 > 7 9 10 *11 15) > Jul 11 23:32:30 server1 kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 > 7 9 10 *11 15) > Jul 11 23:32:31 server1 kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 > 7 9 10 *11 15) > Jul 11 23:32:31 server1 kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 > 7 9 10 *11 15) > Jul 11 23:32:31 server1 kernel: ACPI: Power Resource [FANP] (off) > Jul 11 23:32:31 server1 kernel: Linux Plug and Play Support v0.97 (c) Adam > Belay > Jul 11 23:32:31 server1 kernel: pnp: PnP ACPI init > Jul 11 23:32:31 server1 auditd[1579]: Init complete, auditd 1.0.14 > listening for events > Jul 11 23:32:31 server1 kernel: pnp: PnP ACPI: found 16 devices > Jul 11 23:32:31 server1 kernel: usbcore: registered new driver usbfs > Jul 11 23:32:31 server1 kernel: usbcore: registered new driver hub > Jul 11 23:32:31 server1 kernel: PCI: Using ACPI for IRQ routing > Jul 11 23:32:31 server1 kernel: PCI: If a device doesn't work, try > "pci=routeirq". If it helps, post a report > Jul 11 23:32:31 server1 kernel: PCI: Ignore bogus resource 6 [0:0] of > 0000:01:00.0 > Jul 11 23:32:31 server1 kernel: PCI: Bridge: 0000:00:01.0 > Jul 11 23:32:31 server1 kernel: IO window: disabled. > Jul 11 23:32:31 server1 kernel: MEM window: f4200000-f47fffff > Jul 11 23:32:31 server1 kernel: PREFETCH window: f5000000-f5ffffff > Jul 11 23:32:31 server1 kernel: PCI: Bus 2, cardbus bridge: 0000:00:02.0 > Jul 11 23:32:31 server1 kernel: IO window: 00001400-000014ff > Jul 11 23:32:31 server1 kernel: IO window: 00001c00-00001cff > Jul 11 23:32:31 server1 kernel: PREFETCH window: 10000000-11ffffff > Jul 11 23:32:31 server1 kernel: MEM window: 12000000-13ffffff > Jul 11 23:32:32 server1 kernel: PCI: Bus 6, cardbus bridge: 0000:00:02.1 > Jul 11 23:32:32 server1 kernel: IO window: 00002400-000024ff > Jul 11 23:32:32 server1 kernel: IO window: 00002800-000028ff > Jul 11 23:32:32 server1 kernel: PREFETCH window: 14000000-15ffffff > Jul 11 23:32:32 server1 kernel: MEM window: 16000000-17ffffff > Jul 11 23:32:32 server1 kernel: ACPI: PCI Interrupt Link [LNKA] enabled at > IRQ 11 > Jul 11 23:32:32 server1 kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> Link > [LNKA] -> GSI 11 (level, low) -> IRQ 11 > Jul 11 23:32:32 server1 kernel: ACPI: PCI Interrupt Link [LNKB] enabled at > IRQ 11 > Jul 11 23:32:32 server1 kernel: ACPI: PCI Interrupt 0000:00:02.1[B] -> Link > [LNKB] -> GSI 11 (level, low) -> IRQ 11 > Jul 11 23:32:32 server1 kernel: NET: Registered protocol family 2 > Jul 11 23:32:32 server1 kernel: IP route cache hash table entries: 1024 > (order: 0, 4096 bytes) > Jul 11 23:32:32 server1 kernel: TCP established hash table entries: 4096 > (order: 4, 65536 bytes) > Jul 11 23:32:32 server1 kernel: TCP bind hash table entries: 2048 (order: > 3, 40960 bytes) > Jul 11 23:32:32 server1 kernel: TCP: Hash tables configured (established > 4096 bind 2048) > Jul 11 23:32:33 server1 kernel: TCP reno registered > Jul 11 23:32:33 server1 kernel: Simple Boot Flag at 0x36 set to 0x1 > Jul 11 23:32:33 server1 kernel: * Found PM-Timer Bug on this chipset. Due > to workarounds for a bug, > Jul 11 23:32:33 server1 kernel: * this time source is slow. Consider > trying other time sources (clock=) > Jul 11 23:32:33 server1 kernel: IBM machine detected. Enabling interrupts > during APM calls. > Jul 11 23:32:33 server1 kernel: apm: BIOS version 1.2 Flags 0x03 (Driver > version 1.16ac) > Jul 11 23:32:33 server1 kernel: apm: overridden by ACPI. > Jul 11 23:32:33 server1 kernel: audit: initializing netlink socket > (disabled) > Jul 11 23:32:33 server1 kernel: audit(1152660675.080:1): initialized > Jul 11 23:32:33 server1 kernel: Total HugeTLB memory allocated, 0 > Jul 11 23:32:33 server1 kernel: VFS: Disk quotas dquot_6.5.1 > Jul 11 23:32:33 server1 kernel: Dquot-cache hash table entries: 1024 (order > 0, 4096 bytes) > Jul 11 23:32:33 server1 kernel: SELinux: Registering netfilter hooks > Jul 11 23:32:33 server1 kernel: Initializing Cryptographic API > Jul 11 23:32:33 server1 kernel: ksign: Installing public key data > Jul 11 23:32:33 server1 kernel: Loading keyring > Jul 11 23:32:33 server1 kernel: - Added public key CECC7E59912DB2CA > Jul 11 23:32:33 server1 kernel: - User ID: Red Hat, Inc. (Kernel Module GPG > key) > Jul 11 23:32:33 server1 kernel: io scheduler noop registered > Jul 11 23:32:33 server1 kernel: io scheduler anticipatory registered > Jul 11 23:32:33 server1 kernel: io scheduler deadline registered > Jul 11 23:32:33 server1 kernel: io scheduler cfq registered (default) > Jul 11 23:32:33 server1 kernel: Limiting direct PCI/PCI transfers. > Jul 11 23:32:33 server1 kernel: pci_hotplug: PCI Hot Plug PCI Core version: > 0.5 > Jul 11 23:32:33 server1 kernel: ACPI: Fan [FAN] (off) > Jul 11 23:32:33 server1 kernel: ACPI: CPU0 (power states: C1[C1] C2[C2]) > Jul 11 23:32:33 server1 kernel: ACPI: Processor [CPU] (supports 8 > throttling states) > Jul 11 23:32:33 server1 kernel: ACPI: Thermal Zone [THM0] (64 C) > Jul 11 23:32:33 server1 kernel: isapnp: Scanning for PnP cards... > Jul 11 23:32:33 server1 kernel: isapnp: No Plug & Play device found > Jul 11 23:32:33 server1 kernel: Real Time Clock Driver v1.12ac > Jul 11 23:32:33 server1 kernel: Non-volatile memory driver v1.2 > Jul 11 23:32:34 server1 kernel: Linux agpgart interface v0.101 (c) Dave > Jones > Jul 11 23:32:34 server1 kernel: agpgart: Detected an Intel 440BX Chipset. > Jul 11 23:32:34 server1 kernel: agpgart: AGP aperture is 64M @ 0xf8000000 > Jul 11 23:32:34 server1 kernel: Serial: 8250/16550 driver $Revision: 1.90 $ > 4 ports, IRQ sharing enabled > Jul 11 23:32:34 server1 kernel: pnp: Device 00:09 activated. > Jul 11 23:32:34 server1 kernel: 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a > 16550A > Jul 11 23:32:34 server1 kernel: RAMDISK driver initialized: 16 RAM disks of > 16384K size 1024 blocksize > Jul 11 23:32:34 server1 kernel: Uniform Multi-Platform E-IDE driver > Revision: 7.00alpha2 > Jul 11 23:32:34 server1 kernel: ide: Assuming 33MHz system bus speed for > PIO modes; override with idebus=xx > Jul 11 23:32:34 server1 kernel: PIIX4: IDE controller at PCI slot > 0000:00:06.1 > Jul 11 23:32:34 server1 kernel: PIIX4: chipset revision 1 > Jul 11 23:32:34 server1 kernel: PIIX4: not 100% native mode: will probe > irqs later > Jul 11 23:32:34 server1 kernel: ide0: BM-DMA at 0x1800-0x1807, BIOS > settings: hda:DMA, hdb:pio > Jul 11 23:32:34 server1 kernel: ide1: BM-DMA at 0x1808-0x180f, BIOS > settings: hdc:pio, hdd:pio > Jul 11 23:32:34 server1 kernel: hda: IBM-DBCA-206480, ATA DISK drive > Jul 11 23:32:34 server1 kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > Jul 11 23:32:34 server1 kernel: hda: max request size: 128KiB > Jul 11 23:32:34 server1 kernel: hda: 12594960 sectors (6448 MB) w/420KiB > Cache, CHS=13328/15/63, UDMA(33) > Jul 11 23:32:34 server1 kernel: hda: cache flushes not supported > Jul 11 23:32:35 server1 kernel: hda: hda1 hda2 > Jul 11 23:32:35 server1 kernel: ide-floppy driver 0.99.newide > Jul 11 23:32:35 server1 kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> Link > [LNKA] -> GSI 11 (level, low) -> IRQ 11 > Jul 11 23:32:35 server1 kernel: Yenta: CardBus bridge found at 0000:00:02.0 > [1014:0130] > Jul 11 23:32:35 server1 kernel: Yenta: Using INTVAL to route CSC interrupts > to PCI > Jul 11 23:32:35 server1 kernel: Yenta: Routing CardBus interrupts to PCI > Jul 11 23:32:35 server1 kernel: Yenta TI: socket 0000:00:02.0, mfunc > 0x00001000, devctl 0x66 > Jul 11 23:32:35 server1 kernel: Yenta: ISA IRQ mask 0x04b8, PCI irq 11 > Jul 11 23:32:35 server1 kernel: Socket status: 30000006 > Jul 11 23:32:35 server1 kernel: ACPI: PCI Interrupt 0000:00:02.1[B] -> Link > [LNKB] -> GSI 11 (level, low) -> IRQ 11 > Jul 11 23:32:35 server1 kernel: Yenta: CardBus bridge found at 0000:00:02.1 > [1014:0130] > Jul 11 23:32:35 server1 kernel: Yenta: Using INTVAL to route CSC interrupts > to PCI > Jul 11 23:32:35 server1 kernel: Yenta: Routing CardBus interrupts to PCI > Jul 11 23:32:35 server1 kernel: Yenta TI: socket 0000:00:02.1, mfunc > 0x00001000, devctl 0x66 > Jul 11 23:32:35 server1 kernel: Yenta: ISA IRQ mask 0x04b8, PCI irq 11 > Jul 11 23:32:35 server1 kernel: Socket status: 30000010 > Jul 11 23:32:35 server1 kernel: usbcore: registered new driver libusual > Jul 11 23:32:35 server1 kernel: usbcore: registered new driver hiddev > Jul 11 23:32:35 server1 kernel: usbcore: registered new driver usbhid > Jul 11 23:32:35 server1 kernel: drivers/usb/input/hid-core.c: v2.6:USB HID > core driver > Jul 11 23:32:35 server1 kernel: PNP: PS/2 Controller > [PNP0303:KBC,PNP0f13:MOUS] at 0x60,0x64 irq 1,12 > Jul 11 23:32:35 server1 kernel: serio: i8042 AUX port at 0x60,0x64 irq 12 > Jul 11 23:32:35 server1 kernel: serio: i8042 KBD port at 0x60,0x64 irq 1 > Jul 11 23:32:35 server1 kernel: mice: PS/2 mouse device common for all mice > Jul 11 23:32:35 server1 kernel: md: md driver 0.90.3 MAX_MD_DEVS=256, > MD_SB_DISKS=27 > Jul 11 23:32:35 server1 kernel: md: bitmap version 4.39 > Jul 11 23:32:35 server1 kernel: TCP bic registered > Jul 11 23:32:35 server1 kernel: Initializing IPsec netlink socket > Jul 11 23:32:35 server1 kernel: NET: Registered protocol family 1 > Jul 11 23:32:36 server1 kernel: NET: Registered protocol family 17 > Jul 11 23:32:36 server1 kernel: Using IPI Shortcut mode > Jul 11 23:32:36 server1 kernel: ACPI wakeup devices: > Jul 11 23:32:36 server1 kernel: LID SLPB CRD0 CRD1 COMA USB MODM > Jul 11 23:32:36 server1 kernel: ACPI: (supports S0 S1 S3 S4 S5) > Jul 11 23:32:37 server1 kernel: Freeing unused kernel memory: 212k freed > Jul 11 23:32:37 server1 kernel: Write protecting the kernel read-only data: > 924k > Jul 11 23:32:37 server1 kernel: input: AT Translated Set 2 keyboard as > /class/input/input0 > Jul 11 23:32:37 server1 kernel: device-mapper: 4.6.0-ioctl (2006-02-17) > initialised: dm-devel at redhat.com > Jul 11 23:32:37 server1 kernel: pccard: PCMCIA card inserted into slot 1 > Jul 11 23:32:37 server1 kernel: kjournald starting. Commit interval 5 > seconds > Jul 11 23:32:37 server1 kernel: EXT3-fs: mounted filesystem with ordered > data mode. > Jul 11 23:32:37 server1 kernel: IBM TrackPoint firmware: 0x0b, buttons: 3/3 > Jul 11 23:32:37 server1 kernel: input: TPPS/2 IBM TrackPoint as > /class/input/input1 > Jul 11 23:32:37 server1 kernel: audit(1152660681.792:2): enforcing=1 > old_enforcing=0 auid=4294967295 > Jul 11 23:32:37 server1 kernel: security: 3 users, 6 roles, 890 types, 110 > bools > Jul 11 23:32:37 server1 kernel: security: 55 classes, 244688 rules > Jul 11 23:32:37 server1 kernel: SELinux: Completing initialization. > Jul 11 23:32:37 server1 kernel: SELinux: Setting up existing superblocks. > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev dm-0, type ext3), > uses xattr > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev tmpfs, type > tmpfs), uses transition SIDs > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev debugfs, type > debugfs), uses genfs_contexts > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev selinuxfs, type > selinuxfs), uses genfs_contexts > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev mqueue, type > mqueue), uses transition SIDs > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev hugetlbfs, type > hugetlbfs), uses genfs_contexts > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev devpts, type > devpts), uses transition SIDs > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev eventpollfs, type > eventpollfs), uses genfs_contexts > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev inotifyfs, type > inotifyfs), uses genfs_contexts > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev tmpfs, type > tmpfs), uses transition SIDs > Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev futexfs, type > futexfs), uses genfs_contexts > Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev pipefs, type > pipefs), uses task SIDs > Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev sockfs, type > sockfs), uses task SIDs > Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev proc, type proc), > uses genfs_contexts > Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev bdev, type bdev), > uses genfs_contexts > Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev rootfs, type > rootfs), uses genfs_contexts > Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev sysfs, type > sysfs), uses genfs_contexts > Jul 11 23:32:39 server1 kernel: audit(1152660688.364:3): policy loaded > auid=4294967295 > Jul 11 23:32:39 server1 kernel: audit(1152660688.396:4): avc: denied { > search } for pid=537 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:39 server1 kernel: audit(1152660688.408:5): avc: denied { > search } for pid=539 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:39 server1 kernel: audit(1152660688.428:6): avc: denied { > search } for pid=538 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:39 server1 kernel: audit(1152660688.444:7): avc: denied { > search } for pid=540 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:39 server1 kernel: audit(1152660688.464:8): avc: denied { > search } for pid=541 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:39 server1 kernel: audit(1152660688.480:9): avc: denied { > search } for pid=542 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:39 server1 kernel: audit(1152660688.508:10): avc: denied { > search } for pid=543 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:39 server1 kernel: audit(1152660688.524:11): avc: denied { > search } for pid=544 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:39 server1 kernel: audit(1152660688.552:12): avc: denied { > search } for pid=545 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:40 server1 kernel: audit(1152660688.564:13): avc: denied { > search } for pid=547 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:40 server1 kernel: audit(1152660688.588:14): avc: denied { > search } for pid=546 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:40 server1 kernel: audit(1152660688.600:15): avc: denied { > search } for pid=548 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:40 server1 kernel: audit(1152660688.644:16): avc: denied { > search } for pid=549 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:41 server1 kernel: audit(1152660688.656:17): avc: denied { > search } for pid=550 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:41 server1 kernel: audit(1152660688.680:18): avc: denied { > search } for pid=551 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:42 server1 kernel: audit(1152660688.696:19): avc: denied { > search } for pid=552 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:42 server1 kernel: audit(1152660688.724:20): avc: denied { > search } for pid=553 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:42 server1 kernel: audit(1152660688.736:21): avc: denied { > search } for pid=554 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:42 server1 kernel: audit(1152660688.748:22): avc: denied { > search } for pid=556 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:42 server1 kernel: audit(1152660688.772:23): avc: denied { > search } for pid=555 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:42 server1 kernel: audit(1152660688.796:24): avc: denied { > search } for pid=557 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:42 server1 kernel: audit(1152660688.808:25): avc: denied { > search } for pid=558 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:42 server1 kernel: audit(1152660688.836:26): avc: denied { > search } for pid=559 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:42 server1 kernel: audit(1152660688.848:27): avc: denied { > search } for pid=560 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:42 server1 kernel: audit(1152660688.876:28): avc: denied { > search } for pid=561 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:42 server1 kernel: audit(1152660688.888:29): avc: denied { > search } for pid=563 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:42 server1 kernel: audit(1152660688.912:30): avc: denied { > search } for pid=562 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:42 server1 kernel: audit(1152660688.924:31): avc: denied { > search } for pid=564 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:43 server1 kernel: audit(1152660688.948:32): avc: denied { > search } for pid=565 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:43 server1 kernel: audit(1152660688.964:33): avc: denied { > search } for pid=566 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:43 server1 kernel: audit(1152660688.988:34): avc: denied { > search } for pid=567 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:43 server1 kernel: audit(1152660689.000:35): avc: denied { > search } for pid=568 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:43 server1 ntpdate[1814]: can't find host 0.pool.ntp.org > Jul 11 23:32:43 server1 kernel: audit(1152660689.028:36): avc: denied { > search } for pid=570 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:43 server1 ntpdate[1814]: can't find host 1.pool.ntp.org > Jul 11 23:32:43 server1 kernel: audit(1152660689.040:37): avc: denied { > search } for pid=571 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:43 server1 ntpdate[1814]: can't find host 2.pool.ntp.org > Jul 11 23:32:43 server1 kernel: audit(1152660689.064:38): avc: denied { > search } for pid=569 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:43 server1 kernel: audit(1152660689.076:39): avc: denied { > search } for pid=572 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:43 server1 kernel: audit(1152660689.124:40): avc: denied { > search } for pid=574 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:43 server1 kernel: audit(1152660689.136:41): avc: denied { > search } for pid=575 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:43 server1 kernel: audit(1152660689.160:42): avc: denied { > search } for pid=576 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:43 server1 kernel: audit(1152660689.172:43): avc: denied { > search } for pid=577 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:43 server1 kernel: SELinux: initialized (dev usbfs, type > usbfs), uses genfs_contexts > Jul 11 23:32:43 server1 kernel: audit(1152660692.353:44): avc: denied { > search } for pid=595 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:43 server1 kernel: audit(1152660692.369:45): avc: denied { > search } for pid=596 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:43 server1 kernel: audit(1152660692.393:46): avc: denied { > search } for pid=597 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:43 server1 kernel: audit(1152660692.405:47): avc: denied { > search } for pid=598 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:44 server1 kernel: audit(1152660692.437:48): avc: denied { > search } for pid=600 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:44 server1 kernel: audit(1152660692.457:49): avc: denied { > search } for pid=599 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:44 server1 kernel: audit(1152660692.469:50): avc: denied { > search } for pid=602 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:45 server1 kernel: audit(1152660692.481:51): avc: denied { > search } for pid=601 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:45 server1 kernel: audit(1152660692.509:52): avc: denied { > search } for pid=603 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:45 server1 kernel: audit(1152660692.525:53): avc: denied { > search } for pid=604 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:46 server1 kernel: audit(1152660692.549:54): avc: denied { > search } for pid=605 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:46 server1 kernel: audit(1152660692.565:55): avc: denied { > search } for pid=606 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:46 server1 kernel: audit(1152660692.597:56): avc: denied { > search } for pid=608 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:46 server1 kernel: audit(1152660692.605:57): avc: denied { > search } for pid=607 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:46 server1 kernel: audit(1152660692.621:58): avc: denied { > search } for pid=609 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:46 server1 kernel: audit(1152660692.641:59): avc: denied { > search } for pid=610 comm="default.hotplug" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:hotplug_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:46 server1 kernel: Floppy drive(s): fd0 is 1.44M > Jul 11 23:32:46 server1 kernel: FDC 0 is a National Semiconductor PC87306 > Jul 11 23:32:46 server1 kernel: ACPI: PCI Interrupt 0000:00:05.0[A] -> Link > [LNKA] -> GSI 11 (level, low) -> IRQ 11 > Jul 11 23:32:46 server1 kernel: cs46xx: failure waiting for FIFO command to > complete > Jul 11 23:32:46 server1 kernel: gameport: CS46xx Gameport is > pci0000:00:05.0/gameport0, speed 1491kHz > Jul 11 23:32:46 server1 kernel: piix4_smbus 0000:00:06.3: Found > 0000:00:06.3 device > Jul 11 23:32:46 server1 kernel: piix4_smbus 0000:00:06.3: IBM Laptop > detected; this module may corrupt your serial eeprom! Refusing to load > module! > Jul 11 23:32:46 server1 kernel: piix4_smbus: probe of 0000:00:06.3 failed > with error -1 > Jul 11 23:32:46 server1 kernel: USB Universal Host Controller Interface > driver v3.0 > Jul 11 23:32:46 server1 kernel: ACPI: PCI Interrupt Link [LNKD] enabled at > IRQ 11 > Jul 11 23:32:46 server1 kernel: ACPI: PCI Interrupt 0000:00:06.2[D] -> Link > [LNKD] -> GSI 11 (level, low) -> IRQ 11 > Jul 11 23:32:46 server1 kernel: uhci_hcd 0000:00:06.2: UHCI Host Controller > Jul 11 23:32:46 server1 kernel: uhci_hcd 0000:00:06.2: new USB bus > registered, assigned bus number 1 > Jul 11 23:32:46 server1 kernel: uhci_hcd 0000:00:06.2: irq 11, io base > 0x00001820 > Jul 11 23:32:46 server1 kernel: usb usb1: configuration #1 chosen from 1 > choice > Jul 11 23:32:46 server1 kernel: hub 1-0:1.0: USB hub found > Jul 11 23:32:46 server1 kernel: hub 1-0:1.0: 2 ports detected > Jul 11 23:32:46 server1 kernel: audit(1152660724.983:60): avc: denied { > search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hwclock_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:46 server1 kernel: audit(1152660724.983:61): avc: denied { > search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hwclock_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:46 server1 kernel: audit(1152660724.983:62): avc: denied { > search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hwclock_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:46 server1 kernel: audit(1152660724.983:63): avc: denied { > search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hwclock_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:46 server1 kernel: audit(1152660724.983:64): avc: denied { > search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hwclock_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:46 server1 kernel: audit(1152660724.983:65): avc: denied { > search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hwclock_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:46 server1 kernel: audit(1152660724.983:66): avc: denied { > search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hwclock_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:46 server1 kernel: audit(1152660724.983:67): avc: denied { > search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:hwclock_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:46 server1 kernel: ACPI: AC Adapter [AC] (on-line) > Jul 11 23:32:46 server1 kernel: ACPI: Battery Slot [BAT1] (battery present) > Jul 11 23:32:46 server1 kernel: ACPI: Battery Slot [BAT2] (battery absent) > Jul 11 23:32:46 server1 kernel: ACPI: Power Button (FF) [PWRF] > Jul 11 23:32:46 server1 kernel: ACPI: Lid Switch [LID] > Jul 11 23:32:46 server1 kernel: ACPI: Sleep Button (CM) [SLPB] > Jul 11 23:32:46 server1 kernel: ibm_acpi: IBM ThinkPad ACPI Extras v0.12a > Jul 11 23:32:46 server1 kernel: ibm_acpi: http://ibm-acpi.sf.net/ > Jul 11 23:32:46 server1 kernel: ibm_acpi: dock device not present > Jul 11 23:32:46 server1 kernel: ibm_acpi: bay device not present > Jul 11 23:32:46 server1 kernel: ACPI: Video Device [VGA] (multi-head: yes > rom: no post: no) > Jul 11 23:32:46 server1 kernel: md: Autodetecting RAID arrays. > Jul 11 23:32:46 server1 kernel: md: autorun ... > Jul 11 23:32:47 server1 kernel: md: ... autorun DONE. > Jul 11 23:32:47 server1 kernel: EXT3 FS on dm-0, internal journal > Jul 11 23:32:47 server1 kernel: kjournald starting. Commit interval 5 > seconds > Jul 11 23:32:47 server1 kernel: EXT3 FS on hda1, internal journal > Jul 11 23:32:47 server1 kernel: EXT3-fs: mounted filesystem with ordered > data mode. > Jul 11 23:32:47 server1 kernel: SELinux: initialized (dev hda1, type ext3), > uses xattr > Jul 11 23:32:47 server1 kernel: SELinux: initialized (dev tmpfs, type > tmpfs), uses transition SIDs > Jul 11 23:32:47 server1 kernel: Adding 262136k swap on > /dev/VolGroup00/LogVol01. Priority:-1 extents:1 across:262136k > Jul 11 23:32:47 server1 kernel: SELinux: initialized (dev binfmt_misc, type > binfmt_misc), uses genfs_contexts > Jul 11 23:32:47 server1 kernel: ip_tables: (C) 2000-2006 Netfilter Core > Team > Jul 11 23:32:47 server1 kernel: Netfilter messages via NETLINK v0.30. > Jul 11 23:32:47 server1 kernel: ip_conntrack version 2.4 (1023 buckets, > 8184 max) - 224 bytes per conntrack > Jul 11 23:32:47 server1 kernel: pcmcia: Detected deprecated PCMCIA ioctl > usage from process: cardmgr. > Jul 11 23:32:47 server1 kernel: pcmcia: This interface will soon be removed > from the kernel; please expect breakage unless you upgrade to new tools. > Jul 11 23:32:47 server1 kernel: pcmcia: see > http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for > details. > Jul 11 23:32:47 server1 kernel: cs: IO port probe 0xc00-0xcff: excluding > 0xcf8-0xcff > Jul 11 23:32:47 server1 kernel: cs: IO port probe 0xc00-0xcff: excluding > 0xcf8-0xcff > Jul 11 23:32:47 server1 kernel: cs: IO port probe 0x800-0x8ff: clean. > Jul 11 23:32:47 server1 kernel: cs: IO port probe 0x800-0x8ff: clean. > Jul 11 23:32:47 server1 kernel: cs: IO port probe 0x100-0x4ff: excluding > 0x170-0x177 0x370-0x377 0x3b8-0x3df 0x4d0-0x4d7 > Jul 11 23:32:47 server1 kernel: cs: IO port probe 0x100-0x4ff: excluding > 0x170-0x177 0x370-0x377 0x3b8-0x3df 0x4d0-0x4d7 > Jul 11 23:32:47 server1 kernel: cs: IO port probe 0xa00-0xaff: clean. > Jul 11 23:32:47 server1 kernel: cs: IO port probe 0xa00-0xaff: clean. > Jul 11 23:32:47 server1 kernel: cs: memory probe 0xa0000000-0xa0ffffff: > clean. > Jul 11 23:32:47 server1 kernel: pcmcia: registering new device pcmcia1.0 > Jul 11 23:32:47 server1 kernel: eth0: 3Com 3c589, io 0x300, irq 3, hw_addr > 00:10:5A:6A:A4:2F > Jul 11 23:32:47 server1 kernel: 8K FIFO split 5:3 Rx:Tx, auto xcvr > Jul 11 23:32:47 server1 kernel: audit(1152628341.239:68): avc: denied { > search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:cardmgr_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628341.239:69): avc: denied { > search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:cardmgr_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628341.239:70): avc: denied { > search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:cardmgr_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628341.239:71): avc: denied { > search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:cardmgr_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628341.239:72): avc: denied { > search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:cardmgr_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628341.239:73): avc: denied { > search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:cardmgr_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628341.239:74): avc: denied { > search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:cardmgr_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628341.239:75): avc: denied { > search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:cardmgr_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628341.275:76): avc: denied { > search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:cardmgr_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628341.275:77): avc: denied { > search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:cardmgr_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628341.275:78): avc: denied { > search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:cardmgr_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628341.279:79): avc: denied { > search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:cardmgr_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628341.279:80): avc: denied { > search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:cardmgr_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628341.279:81): avc: denied { > search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:cardmgr_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628341.279:82): avc: denied { > search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:cardmgr_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628341.279:83): avc: denied { > search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 > scontext=system_u:system_r:cardmgr_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: eth0: flipped to 10base2 > Jul 11 23:32:47 server1 kernel: audit(1152628348.743:84): avc: denied { > search } for pid=1545 comm="named-checkconf" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:named_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628348.775:85): avc: denied { > search } for pid=1545 comm="named-checkconf" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:named_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628348.779:86): avc: denied { > search } for pid=1545 comm="named-checkconf" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:named_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628348.779:87): avc: denied { > search } for pid=1545 comm="named-checkconf" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:named_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628348.779:88): avc: denied { > search } for pid=1545 comm="named-checkconf" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:named_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628348.787:89): avc: denied { > search } for pid=1547 comm="named-checkconf" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:named_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 kernel: audit(1152628348.787:90): avc: denied { > search } for pid=1547 comm="named-checkconf" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:named_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:47 server1 ntpdate[1814]: no server suitable for > synchronization found > Jul 11 23:32:47 server1 kernel: audit(1152628348.787:91): avc: denied { > search } for pid=1547 comm="named-checkconf" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:named_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:48 server1 kernel: audit(1152628348.787:92): avc: denied { > search } for pid=1547 comm="named-checkconf" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:named_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:48 server1 kernel: audit(1152628348.787:93): avc: denied { > search } for pid=1547 comm="named-checkconf" name="usr" dev=dm-0 > ino=1212417 scontext=system_u:system_r:named_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > Jul 11 23:32:48 server1 kernel: audit(1152628351.123:94): audit_pid=1579 > old=0 by auid=4294967295 subj=system_u:system_r:auditd_t > Jul 11 23:32:48 server1 kernel: SELinux: initialized (dev rpc_pipefs, type > rpc_pipefs), uses genfs_contexts > Jul 11 23:32:48 server1 kernel: SELinux: initialized (dev autofs, type > autofs), uses genfs_contexts > Jul 11 23:32:48 server1 kernel: NET: Registered protocol family 10 > Jul 11 23:32:48 server1 kernel: lo: Disabled Privacy Extensions > Jul 11 23:32:48 server1 kernel: IPv6 over IPv4 tunneling driver > Jul 11 23:32:50 server1 gpm[1844]: *** info [startup.c(95)]: > Jul 11 23:32:50 server1 gpm[1844]: Started gpm successfully. Entered daemon > mode. > Jul 11 23:32:50 server1 gpm[1844]: *** info [mice.c(1766)]: > Jul 11 23:32:50 server1 gpm[1844]: imps2: Auto-detected intellimouse PS/2 > Jul 11 23:33:02 server1 iiimd[1881]: started. > Jul 11 23:33:15 server1 kernel: eth0: coax cable problem > Jul 11 23:33:20 server1 kernel: eth0: flipped to 10baseT It looks to me like you have a labelling problem, with the directory /usr being labelled httpd_sys_script_exec_t instead of usr_t. That accounts for most of the above anyway. Try: # restorecon -v /usr If that doesn't work, try a full relabel. # touch /.autorelabel # reboot (that will take a long time) Paul. From wieseltux23 at gmail.com Sat Jul 15 18:05:11 2006 From: wieseltux23 at gmail.com (wieseltux23) Date: Sat, 15 Jul 2006 20:05:11 +0200 Subject: My FC4 server doesn't work after updated In-Reply-To: <1152986612.23617.2.camel@laurel.intra.city-fan.org> References: <20060715014306.45281.qmail@web10512.mail.bbt.yahoo.co.jp> <1152986612.23617.2.camel@laurel.intra.city-fan.org> Message-ID: <20060715200511.9a20b948.wieseltux23@gmail.com> http://en.fon.com/ On Sat, 15 Jul 2006 19:03:31 +0100 Paul Howarth wrote: > On Sat, 2006-07-15 at 10:43 +0900, Mike Zang wrote: > > My FC4 server worked welll. It doesn't work after I updated by yum. > > Here is audit avc information from /var/log/message, what can I do? > > Jul 11 23:29:11 server1 shutdown: shutting down for system reboot > > Jul 11 23:29:12 server1 init: Switching to runlevel: 6 > > Jul 11 23:29:14 server1 ainit: Operation not permitted > > Jul 11 23:29:14 server1 ainit: Operation not permitted > > Jul 11 23:29:15 server1 dbus: avc: 5 AV entries and 5/512 buckets used, > > longest chain length 1 > > Jul 11 23:29:22 server1 xfs[2013]: terminating > > Jul 11 23:29:36 server1 nmbd[2024]: [2006/07/11 23:29:36, 0] > > nmbd/nmbd.c:terminate(56) > > Jul 11 23:29:37 server1 nmbd[2024]: Got SIGTERM: going down... > > Jul 11 23:30:00 server1 ntpd[1892]: ntpd exiting on signal 15 > > Jul 11 23:30:01 server1 auditd[1631]: The audit daemon is exiting. > > Jul 11 23:30:01 server1 kernel: audit(1152628201.909:1300): audit_pid=0 > > old=1631 by auid=4294967295 subj=system_u:system_r:auditd_t > > Jul 11 23:30:03 server1 kernel: audit(1152628203.405:1301): avc: denied { > > search } for pid=27967 comm="rndc" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:ndc_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:30:03 server1 kernel: audit(1152628203.405:1301): arch=40000003 > > syscall=5 success=no exit=-13 a0=b7ff9406 a1=0 a2=0 a3=8 items=1 pid=27967 > > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > > tty=(none) comm="rndc" exe="/usr/sbin/rndc" subj=system_u:system_r:ndc_t > > Jul 11 23:30:03 server1 kernel: audit(1152628203.405:1301): cwd="/" > > Jul 11 23:30:03 server1 kernel: audit(1152628203.405:1301): item=0 > > name="/usr/lib/libisccfg.so.1" obj=root:object_r:ld_so_cache_t > > Jul 11 23:30:03 server1 kernel: audit(1152628203.425:1302): avc: denied { > > search } for pid=27967 comm="rndc" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:ndc_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:30:03 server1 kernel: audit(1152628203.425:1302): arch=40000003 > > syscall=5 success=no exit=-13 a0=bfbb3460 a1=0 a2=0 a3=40 items=1 pid=27967 > > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > > tty=(none) comm="rndc" exe="/usr/sbin/rndc" subj=system_u:system_r:ndc_t > > Jul 11 23:30:03 server1 kernel: audit(1152628203.425:1302): cwd="/" > > Jul 11 23:30:03 server1 kernel: audit(1152628203.425:1302): item=0 > > name="/usr/lib/tls/i686/libisccfg.so.1" obj=root:object_r:ld_so_cache_t > > Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1303): avc: denied { > > search } for pid=27967 comm="rndc" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:ndc_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1303): arch=40000003 > > syscall=5 success=no exit=-13 a0=bfbb3460 a1=0 a2=0 a3=40 items=1 pid=27967 > > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > > tty=(none) comm="rndc" exe="/usr/sbin/rndc" subj=system_u:system_r:ndc_t > > Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1303): cwd="/" > > Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1303): item=0 > > name="/usr/lib/tls/libisccfg.so.1" obj=root:object_r:ld_so_cache_t > > Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1304): avc: denied { > > search } for pid=27967 comm="rndc" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:ndc_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1304): arch=40000003 > > syscall=5 success=no exit=-13 a0=bfbb3460 a1=0 a2=0 a3=40 items=1 pid=27967 > > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > > tty=(none) comm="rndc" exe="/usr/sbin/rndc" subj=system_u:system_r:ndc_t > > Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1304): cwd="/" > > Jul 11 23:30:03 server1 kernel: audit(1152628203.429:1304): item=0 > > name="/usr/lib/i686/libisccfg.so.1" obj=root:object_r:ld_so_cache_t > > Jul 11 23:30:03 server1 kernel: audit(1152628203.433:1305): avc: denied { > > search } for pid=27967 comm="rndc" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:ndc_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:30:03 server1 kernel: audit(1152628203.433:1305): arch=40000003 > > syscall=5 success=no exit=-13 a0=bfbb3460 a1=0 a2=0 a3=40 items=1 pid=27967 > > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > > tty=(none) comm="rndc" exe="/usr/sbin/rndc" subj=system_u:system_r:ndc_t > > Jul 11 23:30:03 server1 kernel: audit(1152628203.433:1305): cwd="/" > > Jul 11 23:30:03 server1 kernel: audit(1152628203.433:1305): item=0 > > name="/usr/lib/libisccfg.so.1" obj=root:object_r:ld_so_cache_t > > Jul 11 23:30:04 server1 named[1572]: shutting down > > Jul 11 23:30:04 server1 named[1572]: stopping command channel on > > 127.0.0.1#953 > > Jul 11 23:30:04 server1 ntpd_initres[2076]: parent died before we finished, > > exiting > > Jul 11 23:30:05 server1 named[1572]: no longer listening on 127.0.0.1#53 > > Jul 11 23:30:05 server1 named[1572]: no longer listening on 192.168.1.10#53 > > Jul 11 23:30:05 server1 named[1572]: exiting > > Jul 11 23:30:06 server1 kernel: Kernel logging (proc) stopped. > > Jul 11 23:30:06 server1 kernel: Kernel log daemon terminating. > > Jul 11 23:30:07 server1 exiting on signal 15 > > Jul 11 23:32:26 server1 syslogd 1.4.1: restart. > > Jul 11 23:32:27 server1 kernel: klogd 1.4.1, log source = /proc/kmsg > > started. > > Jul 11 23:32:27 server1 kernel: Linux version 2.6.17-1.2141_FC4 > > (bhcompile at hs20-bc1-4.build.redhat.com) (gcc version 4.0.2 20051125 (Red > > Hat 4.0.2-8)) #1 Fri Jun 30 14:53:04 EDT 2006 > > Jul 11 23:32:27 server1 kernel: BIOS-provided physical RAM map: > > Jul 11 23:32:27 server1 kernel: BIOS-e820: 0000000000000000 - > > 000000000009fc00 (usable) > > Jul 11 23:32:27 server1 kernel: BIOS-e820: 000000000009fc00 - > > 00000000000a0000 (reserved) > > Jul 11 23:32:27 server1 kernel: BIOS-e820: 00000000000e0000 - > > 0000000000100000 (reserved) > > Jul 11 23:32:27 server1 kernel: BIOS-e820: 0000000000100000 - > > 0000000007ff0000 (usable) > > Jul 11 23:32:27 server1 kernel: BIOS-e820: 0000000007ff0000 - > > 0000000007fffc00 (ACPI data) > > Jul 11 23:32:27 server1 kernel: BIOS-e820: 0000000007fffc00 - > > 0000000008000000 (ACPI NVS) > > Jul 11 23:32:27 server1 kernel: BIOS-e820: 00000000ffff0000 - > > 0000000100000000 (reserved) > > Jul 11 23:32:27 server1 kernel: 0MB HIGHMEM available. > > Jul 11 23:32:27 server1 kernel: 127MB LOWMEM available. > > Jul 11 23:32:27 server1 kernel: Using x86 segment limits to approximate NX > > protection > > Jul 11 23:32:27 server1 kernel: DMI 2.2 present. > > Jul 11 23:32:28 server1 kernel: ACPI: PM-Timer IO Port: 0x1008 > > Jul 11 23:32:28 server1 kernel: Allocating PCI resources starting at > > 10000000 (gap: 08000000:f7ff0000) > > Jul 11 23:32:28 server1 kernel: Built 1 zonelists > > Jul 11 23:32:28 server1 kernel: Kernel command line: ro > > root=/dev/VolGroup00/LogVol00 rhgb quiet > > Jul 11 23:32:28 server1 kernel: Local APIC disabled by BIOS -- you can > > enable it with "lapic" > > Jul 11 23:32:28 server1 kernel: Enabling fast FPU save and restore... done. > > Jul 11 23:32:28 server1 kernel: Initializing CPU#0 > > Jul 11 23:32:28 server1 kernel: CPU 0 irqstacks, hard=c077d000 > > soft=c077e000 > > Jul 11 23:32:28 server1 kernel: PID hash table entries: 512 (order: 9, 2048 > > bytes) > > Jul 11 23:32:28 server1 kernel: Detected 331.886 MHz processor. > > Jul 11 23:32:28 server1 kernel: Using pmtmr for high-res timesource > > Jul 11 23:32:28 server1 kernel: Console: colour VGA+ 80x25 > > Jul 11 23:32:28 server1 kernel: Dentry cache hash table entries: 16384 > > (order: 4, 65536 bytes) > > Jul 11 23:32:28 server1 kernel: Inode-cache hash table entries: 8192 > > (order: 3, 32768 bytes) > > Jul 11 23:32:28 server1 kernel: Memory: 123604k/131008k available (1977k > > kernel code, 6868k reserved, 1358k data, 212k init, 0k highmem) > > Jul 11 23:32:28 server1 kernel: Checking if this processor honours the WP > > bit even in supervisor mode... Ok. > > Jul 11 23:32:28 server1 named: /usr/sbin/named-checkconf: error while > > loading shared libraries: libbind9.so.0: cannot open shared object file: > > Permission denied > > Jul 11 23:32:28 server1 kernel: Calibrating delay using timer specific > > routine.. 664.55 BogoMIPS (lpj=1329111) > > Jul 11 23:32:28 server1 kernel: Security Framework v1.0.0 initialized > > Jul 11 23:32:28 server1 kernel: SELinux: Initializing. > > Jul 11 23:32:29 server1 kernel: SELinux: Starting in permissive mode > > Jul 11 23:32:29 server1 kernel: selinux_register_security: Registering > > secondary module capability > > Jul 11 23:32:29 server1 kernel: Capability LSM initialized as secondary > > Jul 11 23:32:29 server1 kernel: Mount-cache hash table entries: 512 > > Jul 11 23:32:29 server1 kernel: CPU: L1 I cache: 16K, L1 D cache: 16K > > Jul 11 23:32:29 server1 kernel: CPU: L2 cache: 256K > > Jul 11 23:32:29 server1 kernel: Intel machine check architecture supported. > > Jul 11 23:32:29 server1 kernel: Intel machine check reporting enabled on > > CPU#0. > > Jul 11 23:32:29 server1 kernel: CPU: Intel Mobile Pentium II stepping 0a > > Jul 11 23:32:29 server1 kernel: Checking 'hlt' instruction... OK. > > Jul 11 23:32:29 server1 kernel: ACPI: setting ELCR to 0200 (from 0800) > > Jul 11 23:32:29 server1 kernel: checking if image is initramfs... it is > > Jul 11 23:32:29 server1 kernel: Freeing initrd memory: 1695k freed > > Jul 11 23:32:29 server1 kernel: NET: Registered protocol family 16 > > Jul 11 23:32:29 server1 kernel: ACPI: bus type pci registered > > Jul 11 23:32:29 server1 kernel: PCI: PCI BIOS revision 2.10 entry at > > 0xfd96f, last bus=10 > > Jul 11 23:32:29 server1 kernel: Setting up standard PCI resources > > Jul 11 23:32:29 server1 kernel: ACPI: Subsystem revision 20060127 > > Jul 11 23:32:29 server1 kernel: ACPI: Interpreter enabled > > Jul 11 23:32:30 server1 kernel: ACPI: Using PIC for interrupt routing > > Jul 11 23:32:30 server1 kernel: ACPI: PCI Root Bridge [PCI] (0000:00) > > Jul 11 23:32:30 server1 kernel: PCI quirk: region 1000-103f claimed by > > PIIX4 ACPI > > Jul 11 23:32:30 server1 kernel: PCI quirk: region 1040-104f claimed by > > PIIX4 SMB > > Jul 11 23:32:30 server1 kernel: PIIX4 devres C PIO at 15e8-15ef > > Jul 11 23:32:30 server1 kernel: PIIX4 devres I PIO at 03f0-03f7 > > Jul 11 23:32:30 server1 kernel: PIIX4 devres J PIO at 002e-002f > > Jul 11 23:32:30 server1 kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 > > 7 9 10 *11 15) > > Jul 11 23:32:30 server1 kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 > > 7 9 10 *11 15) > > Jul 11 23:32:31 server1 kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 > > 7 9 10 *11 15) > > Jul 11 23:32:31 server1 kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 > > 7 9 10 *11 15) > > Jul 11 23:32:31 server1 kernel: ACPI: Power Resource [FANP] (off) > > Jul 11 23:32:31 server1 kernel: Linux Plug and Play Support v0.97 (c) Adam > > Belay > > Jul 11 23:32:31 server1 kernel: pnp: PnP ACPI init > > Jul 11 23:32:31 server1 auditd[1579]: Init complete, auditd 1.0.14 > > listening for events > > Jul 11 23:32:31 server1 kernel: pnp: PnP ACPI: found 16 devices > > Jul 11 23:32:31 server1 kernel: usbcore: registered new driver usbfs > > Jul 11 23:32:31 server1 kernel: usbcore: registered new driver hub > > Jul 11 23:32:31 server1 kernel: PCI: Using ACPI for IRQ routing > > Jul 11 23:32:31 server1 kernel: PCI: If a device doesn't work, try > > "pci=routeirq". If it helps, post a report > > Jul 11 23:32:31 server1 kernel: PCI: Ignore bogus resource 6 [0:0] of > > 0000:01:00.0 > > Jul 11 23:32:31 server1 kernel: PCI: Bridge: 0000:00:01.0 > > Jul 11 23:32:31 server1 kernel: IO window: disabled. > > Jul 11 23:32:31 server1 kernel: MEM window: f4200000-f47fffff > > Jul 11 23:32:31 server1 kernel: PREFETCH window: f5000000-f5ffffff > > Jul 11 23:32:31 server1 kernel: PCI: Bus 2, cardbus bridge: 0000:00:02.0 > > Jul 11 23:32:31 server1 kernel: IO window: 00001400-000014ff > > Jul 11 23:32:31 server1 kernel: IO window: 00001c00-00001cff > > Jul 11 23:32:31 server1 kernel: PREFETCH window: 10000000-11ffffff > > Jul 11 23:32:31 server1 kernel: MEM window: 12000000-13ffffff > > Jul 11 23:32:32 server1 kernel: PCI: Bus 6, cardbus bridge: 0000:00:02.1 > > Jul 11 23:32:32 server1 kernel: IO window: 00002400-000024ff > > Jul 11 23:32:32 server1 kernel: IO window: 00002800-000028ff > > Jul 11 23:32:32 server1 kernel: PREFETCH window: 14000000-15ffffff > > Jul 11 23:32:32 server1 kernel: MEM window: 16000000-17ffffff > > Jul 11 23:32:32 server1 kernel: ACPI: PCI Interrupt Link [LNKA] enabled at > > IRQ 11 > > Jul 11 23:32:32 server1 kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> Link > > [LNKA] -> GSI 11 (level, low) -> IRQ 11 > > Jul 11 23:32:32 server1 kernel: ACPI: PCI Interrupt Link [LNKB] enabled at > > IRQ 11 > > Jul 11 23:32:32 server1 kernel: ACPI: PCI Interrupt 0000:00:02.1[B] -> Link > > [LNKB] -> GSI 11 (level, low) -> IRQ 11 > > Jul 11 23:32:32 server1 kernel: NET: Registered protocol family 2 > > Jul 11 23:32:32 server1 kernel: IP route cache hash table entries: 1024 > > (order: 0, 4096 bytes) > > Jul 11 23:32:32 server1 kernel: TCP established hash table entries: 4096 > > (order: 4, 65536 bytes) > > Jul 11 23:32:32 server1 kernel: TCP bind hash table entries: 2048 (order: > > 3, 40960 bytes) > > Jul 11 23:32:32 server1 kernel: TCP: Hash tables configured (established > > 4096 bind 2048) > > Jul 11 23:32:33 server1 kernel: TCP reno registered > > Jul 11 23:32:33 server1 kernel: Simple Boot Flag at 0x36 set to 0x1 > > Jul 11 23:32:33 server1 kernel: * Found PM-Timer Bug on this chipset. Due > > to workarounds for a bug, > > Jul 11 23:32:33 server1 kernel: * this time source is slow. Consider > > trying other time sources (clock=) > > Jul 11 23:32:33 server1 kernel: IBM machine detected. Enabling interrupts > > during APM calls. > > Jul 11 23:32:33 server1 kernel: apm: BIOS version 1.2 Flags 0x03 (Driver > > version 1.16ac) > > Jul 11 23:32:33 server1 kernel: apm: overridden by ACPI. > > Jul 11 23:32:33 server1 kernel: audit: initializing netlink socket > > (disabled) > > Jul 11 23:32:33 server1 kernel: audit(1152660675.080:1): initialized > > Jul 11 23:32:33 server1 kernel: Total HugeTLB memory allocated, 0 > > Jul 11 23:32:33 server1 kernel: VFS: Disk quotas dquot_6.5.1 > > Jul 11 23:32:33 server1 kernel: Dquot-cache hash table entries: 1024 (order > > 0, 4096 bytes) > > Jul 11 23:32:33 server1 kernel: SELinux: Registering netfilter hooks > > Jul 11 23:32:33 server1 kernel: Initializing Cryptographic API > > Jul 11 23:32:33 server1 kernel: ksign: Installing public key data > > Jul 11 23:32:33 server1 kernel: Loading keyring > > Jul 11 23:32:33 server1 kernel: - Added public key CECC7E59912DB2CA > > Jul 11 23:32:33 server1 kernel: - User ID: Red Hat, Inc. (Kernel Module GPG > > key) > > Jul 11 23:32:33 server1 kernel: io scheduler noop registered > > Jul 11 23:32:33 server1 kernel: io scheduler anticipatory registered > > Jul 11 23:32:33 server1 kernel: io scheduler deadline registered > > Jul 11 23:32:33 server1 kernel: io scheduler cfq registered (default) > > Jul 11 23:32:33 server1 kernel: Limiting direct PCI/PCI transfers. > > Jul 11 23:32:33 server1 kernel: pci_hotplug: PCI Hot Plug PCI Core version: > > 0.5 > > Jul 11 23:32:33 server1 kernel: ACPI: Fan [FAN] (off) > > Jul 11 23:32:33 server1 kernel: ACPI: CPU0 (power states: C1[C1] C2[C2]) > > Jul 11 23:32:33 server1 kernel: ACPI: Processor [CPU] (supports 8 > > throttling states) > > Jul 11 23:32:33 server1 kernel: ACPI: Thermal Zone [THM0] (64 C) > > Jul 11 23:32:33 server1 kernel: isapnp: Scanning for PnP cards... > > Jul 11 23:32:33 server1 kernel: isapnp: No Plug & Play device found > > Jul 11 23:32:33 server1 kernel: Real Time Clock Driver v1.12ac > > Jul 11 23:32:33 server1 kernel: Non-volatile memory driver v1.2 > > Jul 11 23:32:34 server1 kernel: Linux agpgart interface v0.101 (c) Dave > > Jones > > Jul 11 23:32:34 server1 kernel: agpgart: Detected an Intel 440BX Chipset. > > Jul 11 23:32:34 server1 kernel: agpgart: AGP aperture is 64M @ 0xf8000000 > > Jul 11 23:32:34 server1 kernel: Serial: 8250/16550 driver $Revision: 1.90 $ > > 4 ports, IRQ sharing enabled > > Jul 11 23:32:34 server1 kernel: pnp: Device 00:09 activated. > > Jul 11 23:32:34 server1 kernel: 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a > > 16550A > > Jul 11 23:32:34 server1 kernel: RAMDISK driver initialized: 16 RAM disks of > > 16384K size 1024 blocksize > > Jul 11 23:32:34 server1 kernel: Uniform Multi-Platform E-IDE driver > > Revision: 7.00alpha2 > > Jul 11 23:32:34 server1 kernel: ide: Assuming 33MHz system bus speed for > > PIO modes; override with idebus=xx > > Jul 11 23:32:34 server1 kernel: PIIX4: IDE controller at PCI slot > > 0000:00:06.1 > > Jul 11 23:32:34 server1 kernel: PIIX4: chipset revision 1 > > Jul 11 23:32:34 server1 kernel: PIIX4: not 100% native mode: will probe > > irqs later > > Jul 11 23:32:34 server1 kernel: ide0: BM-DMA at 0x1800-0x1807, BIOS > > settings: hda:DMA, hdb:pio > > Jul 11 23:32:34 server1 kernel: ide1: BM-DMA at 0x1808-0x180f, BIOS > > settings: hdc:pio, hdd:pio > > Jul 11 23:32:34 server1 kernel: hda: IBM-DBCA-206480, ATA DISK drive > > Jul 11 23:32:34 server1 kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > > Jul 11 23:32:34 server1 kernel: hda: max request size: 128KiB > > Jul 11 23:32:34 server1 kernel: hda: 12594960 sectors (6448 MB) w/420KiB > > Cache, CHS=13328/15/63, UDMA(33) > > Jul 11 23:32:34 server1 kernel: hda: cache flushes not supported > > Jul 11 23:32:35 server1 kernel: hda: hda1 hda2 > > Jul 11 23:32:35 server1 kernel: ide-floppy driver 0.99.newide > > Jul 11 23:32:35 server1 kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> Link > > [LNKA] -> GSI 11 (level, low) -> IRQ 11 > > Jul 11 23:32:35 server1 kernel: Yenta: CardBus bridge found at 0000:00:02.0 > > [1014:0130] > > Jul 11 23:32:35 server1 kernel: Yenta: Using INTVAL to route CSC interrupts > > to PCI > > Jul 11 23:32:35 server1 kernel: Yenta: Routing CardBus interrupts to PCI > > Jul 11 23:32:35 server1 kernel: Yenta TI: socket 0000:00:02.0, mfunc > > 0x00001000, devctl 0x66 > > Jul 11 23:32:35 server1 kernel: Yenta: ISA IRQ mask 0x04b8, PCI irq 11 > > Jul 11 23:32:35 server1 kernel: Socket status: 30000006 > > Jul 11 23:32:35 server1 kernel: ACPI: PCI Interrupt 0000:00:02.1[B] -> Link > > [LNKB] -> GSI 11 (level, low) -> IRQ 11 > > Jul 11 23:32:35 server1 kernel: Yenta: CardBus bridge found at 0000:00:02.1 > > [1014:0130] > > Jul 11 23:32:35 server1 kernel: Yenta: Using INTVAL to route CSC interrupts > > to PCI > > Jul 11 23:32:35 server1 kernel: Yenta: Routing CardBus interrupts to PCI > > Jul 11 23:32:35 server1 kernel: Yenta TI: socket 0000:00:02.1, mfunc > > 0x00001000, devctl 0x66 > > Jul 11 23:32:35 server1 kernel: Yenta: ISA IRQ mask 0x04b8, PCI irq 11 > > Jul 11 23:32:35 server1 kernel: Socket status: 30000010 > > Jul 11 23:32:35 server1 kernel: usbcore: registered new driver libusual > > Jul 11 23:32:35 server1 kernel: usbcore: registered new driver hiddev > > Jul 11 23:32:35 server1 kernel: usbcore: registered new driver usbhid > > Jul 11 23:32:35 server1 kernel: drivers/usb/input/hid-core.c: v2.6:USB HID > > core driver > > Jul 11 23:32:35 server1 kernel: PNP: PS/2 Controller > > [PNP0303:KBC,PNP0f13:MOUS] at 0x60,0x64 irq 1,12 > > Jul 11 23:32:35 server1 kernel: serio: i8042 AUX port at 0x60,0x64 irq 12 > > Jul 11 23:32:35 server1 kernel: serio: i8042 KBD port at 0x60,0x64 irq 1 > > Jul 11 23:32:35 server1 kernel: mice: PS/2 mouse device common for all mice > > Jul 11 23:32:35 server1 kernel: md: md driver 0.90.3 MAX_MD_DEVS=256, > > MD_SB_DISKS=27 > > Jul 11 23:32:35 server1 kernel: md: bitmap version 4.39 > > Jul 11 23:32:35 server1 kernel: TCP bic registered > > Jul 11 23:32:35 server1 kernel: Initializing IPsec netlink socket > > Jul 11 23:32:35 server1 kernel: NET: Registered protocol family 1 > > Jul 11 23:32:36 server1 kernel: NET: Registered protocol family 17 > > Jul 11 23:32:36 server1 kernel: Using IPI Shortcut mode > > Jul 11 23:32:36 server1 kernel: ACPI wakeup devices: > > Jul 11 23:32:36 server1 kernel: LID SLPB CRD0 CRD1 COMA USB MODM > > Jul 11 23:32:36 server1 kernel: ACPI: (supports S0 S1 S3 S4 S5) > > Jul 11 23:32:37 server1 kernel: Freeing unused kernel memory: 212k freed > > Jul 11 23:32:37 server1 kernel: Write protecting the kernel read-only data: > > 924k > > Jul 11 23:32:37 server1 kernel: input: AT Translated Set 2 keyboard as > > /class/input/input0 > > Jul 11 23:32:37 server1 kernel: device-mapper: 4.6.0-ioctl (2006-02-17) > > initialised: dm-devel at redhat.com > > Jul 11 23:32:37 server1 kernel: pccard: PCMCIA card inserted into slot 1 > > Jul 11 23:32:37 server1 kernel: kjournald starting. Commit interval 5 > > seconds > > Jul 11 23:32:37 server1 kernel: EXT3-fs: mounted filesystem with ordered > > data mode. > > Jul 11 23:32:37 server1 kernel: IBM TrackPoint firmware: 0x0b, buttons: 3/3 > > Jul 11 23:32:37 server1 kernel: input: TPPS/2 IBM TrackPoint as > > /class/input/input1 > > Jul 11 23:32:37 server1 kernel: audit(1152660681.792:2): enforcing=1 > > old_enforcing=0 auid=4294967295 > > Jul 11 23:32:37 server1 kernel: security: 3 users, 6 roles, 890 types, 110 > > bools > > Jul 11 23:32:37 server1 kernel: security: 55 classes, 244688 rules > > Jul 11 23:32:37 server1 kernel: SELinux: Completing initialization. > > Jul 11 23:32:37 server1 kernel: SELinux: Setting up existing superblocks. > > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev dm-0, type ext3), > > uses xattr > > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev tmpfs, type > > tmpfs), uses transition SIDs > > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev debugfs, type > > debugfs), uses genfs_contexts > > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev selinuxfs, type > > selinuxfs), uses genfs_contexts > > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev mqueue, type > > mqueue), uses transition SIDs > > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev hugetlbfs, type > > hugetlbfs), uses genfs_contexts > > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev devpts, type > > devpts), uses transition SIDs > > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev eventpollfs, type > > eventpollfs), uses genfs_contexts > > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev inotifyfs, type > > inotifyfs), uses genfs_contexts > > Jul 11 23:32:38 server1 kernel: SELinux: initialized (dev tmpfs, type > > tmpfs), uses transition SIDs > > Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev futexfs, type > > futexfs), uses genfs_contexts > > Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev pipefs, type > > pipefs), uses task SIDs > > Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev sockfs, type > > sockfs), uses task SIDs > > Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev proc, type proc), > > uses genfs_contexts > > Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev bdev, type bdev), > > uses genfs_contexts > > Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev rootfs, type > > rootfs), uses genfs_contexts > > Jul 11 23:32:39 server1 kernel: SELinux: initialized (dev sysfs, type > > sysfs), uses genfs_contexts > > Jul 11 23:32:39 server1 kernel: audit(1152660688.364:3): policy loaded > > auid=4294967295 > > Jul 11 23:32:39 server1 kernel: audit(1152660688.396:4): avc: denied { > > search } for pid=537 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:39 server1 kernel: audit(1152660688.408:5): avc: denied { > > search } for pid=539 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:39 server1 kernel: audit(1152660688.428:6): avc: denied { > > search } for pid=538 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:39 server1 kernel: audit(1152660688.444:7): avc: denied { > > search } for pid=540 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:39 server1 kernel: audit(1152660688.464:8): avc: denied { > > search } for pid=541 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:39 server1 kernel: audit(1152660688.480:9): avc: denied { > > search } for pid=542 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:39 server1 kernel: audit(1152660688.508:10): avc: denied { > > search } for pid=543 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:39 server1 kernel: audit(1152660688.524:11): avc: denied { > > search } for pid=544 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:39 server1 kernel: audit(1152660688.552:12): avc: denied { > > search } for pid=545 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:40 server1 kernel: audit(1152660688.564:13): avc: denied { > > search } for pid=547 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:40 server1 kernel: audit(1152660688.588:14): avc: denied { > > search } for pid=546 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:40 server1 kernel: audit(1152660688.600:15): avc: denied { > > search } for pid=548 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:40 server1 kernel: audit(1152660688.644:16): avc: denied { > > search } for pid=549 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:41 server1 kernel: audit(1152660688.656:17): avc: denied { > > search } for pid=550 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:41 server1 kernel: audit(1152660688.680:18): avc: denied { > > search } for pid=551 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:42 server1 kernel: audit(1152660688.696:19): avc: denied { > > search } for pid=552 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:42 server1 kernel: audit(1152660688.724:20): avc: denied { > > search } for pid=553 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:42 server1 kernel: audit(1152660688.736:21): avc: denied { > > search } for pid=554 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:42 server1 kernel: audit(1152660688.748:22): avc: denied { > > search } for pid=556 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:42 server1 kernel: audit(1152660688.772:23): avc: denied { > > search } for pid=555 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:42 server1 kernel: audit(1152660688.796:24): avc: denied { > > search } for pid=557 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:42 server1 kernel: audit(1152660688.808:25): avc: denied { > > search } for pid=558 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:42 server1 kernel: audit(1152660688.836:26): avc: denied { > > search } for pid=559 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:42 server1 kernel: audit(1152660688.848:27): avc: denied { > > search } for pid=560 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:42 server1 kernel: audit(1152660688.876:28): avc: denied { > > search } for pid=561 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:42 server1 kernel: audit(1152660688.888:29): avc: denied { > > search } for pid=563 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:42 server1 kernel: audit(1152660688.912:30): avc: denied { > > search } for pid=562 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:42 server1 kernel: audit(1152660688.924:31): avc: denied { > > search } for pid=564 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:43 server1 kernel: audit(1152660688.948:32): avc: denied { > > search } for pid=565 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:43 server1 kernel: audit(1152660688.964:33): avc: denied { > > search } for pid=566 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:43 server1 kernel: audit(1152660688.988:34): avc: denied { > > search } for pid=567 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:43 server1 kernel: audit(1152660689.000:35): avc: denied { > > search } for pid=568 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:43 server1 ntpdate[1814]: can't find host 0.pool.ntp.org > > Jul 11 23:32:43 server1 kernel: audit(1152660689.028:36): avc: denied { > > search } for pid=570 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:43 server1 ntpdate[1814]: can't find host 1.pool.ntp.org > > Jul 11 23:32:43 server1 kernel: audit(1152660689.040:37): avc: denied { > > search } for pid=571 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:43 server1 ntpdate[1814]: can't find host 2.pool.ntp.org > > Jul 11 23:32:43 server1 kernel: audit(1152660689.064:38): avc: denied { > > search } for pid=569 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:43 server1 kernel: audit(1152660689.076:39): avc: denied { > > search } for pid=572 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:43 server1 kernel: audit(1152660689.124:40): avc: denied { > > search } for pid=574 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:43 server1 kernel: audit(1152660689.136:41): avc: denied { > > search } for pid=575 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:43 server1 kernel: audit(1152660689.160:42): avc: denied { > > search } for pid=576 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:43 server1 kernel: audit(1152660689.172:43): avc: denied { > > search } for pid=577 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:43 server1 kernel: SELinux: initialized (dev usbfs, type > > usbfs), uses genfs_contexts > > Jul 11 23:32:43 server1 kernel: audit(1152660692.353:44): avc: denied { > > search } for pid=595 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:43 server1 kernel: audit(1152660692.369:45): avc: denied { > > search } for pid=596 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:43 server1 kernel: audit(1152660692.393:46): avc: denied { > > search } for pid=597 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:43 server1 kernel: audit(1152660692.405:47): avc: denied { > > search } for pid=598 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:44 server1 kernel: audit(1152660692.437:48): avc: denied { > > search } for pid=600 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:44 server1 kernel: audit(1152660692.457:49): avc: denied { > > search } for pid=599 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:44 server1 kernel: audit(1152660692.469:50): avc: denied { > > search } for pid=602 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:45 server1 kernel: audit(1152660692.481:51): avc: denied { > > search } for pid=601 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:45 server1 kernel: audit(1152660692.509:52): avc: denied { > > search } for pid=603 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:45 server1 kernel: audit(1152660692.525:53): avc: denied { > > search } for pid=604 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:46 server1 kernel: audit(1152660692.549:54): avc: denied { > > search } for pid=605 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:46 server1 kernel: audit(1152660692.565:55): avc: denied { > > search } for pid=606 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:46 server1 kernel: audit(1152660692.597:56): avc: denied { > > search } for pid=608 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:46 server1 kernel: audit(1152660692.605:57): avc: denied { > > search } for pid=607 comm="hotplug" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:46 server1 kernel: audit(1152660692.621:58): avc: denied { > > search } for pid=609 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:46 server1 kernel: audit(1152660692.641:59): avc: denied { > > search } for pid=610 comm="default.hotplug" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:hotplug_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:46 server1 kernel: Floppy drive(s): fd0 is 1.44M > > Jul 11 23:32:46 server1 kernel: FDC 0 is a National Semiconductor PC87306 > > Jul 11 23:32:46 server1 kernel: ACPI: PCI Interrupt 0000:00:05.0[A] -> Link > > [LNKA] -> GSI 11 (level, low) -> IRQ 11 > > Jul 11 23:32:46 server1 kernel: cs46xx: failure waiting for FIFO command to > > complete > > Jul 11 23:32:46 server1 kernel: gameport: CS46xx Gameport is > > pci0000:00:05.0/gameport0, speed 1491kHz > > Jul 11 23:32:46 server1 kernel: piix4_smbus 0000:00:06.3: Found > > 0000:00:06.3 device > > Jul 11 23:32:46 server1 kernel: piix4_smbus 0000:00:06.3: IBM Laptop > > detected; this module may corrupt your serial eeprom! Refusing to load > > module! > > Jul 11 23:32:46 server1 kernel: piix4_smbus: probe of 0000:00:06.3 failed > > with error -1 > > Jul 11 23:32:46 server1 kernel: USB Universal Host Controller Interface > > driver v3.0 > > Jul 11 23:32:46 server1 kernel: ACPI: PCI Interrupt Link [LNKD] enabled at > > IRQ 11 > > Jul 11 23:32:46 server1 kernel: ACPI: PCI Interrupt 0000:00:06.2[D] -> Link > > [LNKD] -> GSI 11 (level, low) -> IRQ 11 > > Jul 11 23:32:46 server1 kernel: uhci_hcd 0000:00:06.2: UHCI Host Controller > > Jul 11 23:32:46 server1 kernel: uhci_hcd 0000:00:06.2: new USB bus > > registered, assigned bus number 1 > > Jul 11 23:32:46 server1 kernel: uhci_hcd 0000:00:06.2: irq 11, io base > > 0x00001820 > > Jul 11 23:32:46 server1 kernel: usb usb1: configuration #1 chosen from 1 > > choice > > Jul 11 23:32:46 server1 kernel: hub 1-0:1.0: USB hub found > > Jul 11 23:32:46 server1 kernel: hub 1-0:1.0: 2 ports detected > > Jul 11 23:32:46 server1 kernel: audit(1152660724.983:60): avc: denied { > > search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hwclock_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:46 server1 kernel: audit(1152660724.983:61): avc: denied { > > search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hwclock_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:46 server1 kernel: audit(1152660724.983:62): avc: denied { > > search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hwclock_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:46 server1 kernel: audit(1152660724.983:63): avc: denied { > > search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hwclock_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:46 server1 kernel: audit(1152660724.983:64): avc: denied { > > search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hwclock_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:46 server1 kernel: audit(1152660724.983:65): avc: denied { > > search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hwclock_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:46 server1 kernel: audit(1152660724.983:66): avc: denied { > > search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hwclock_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:46 server1 kernel: audit(1152660724.983:67): avc: denied { > > search } for pid=1148 comm="hwclock" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:hwclock_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:46 server1 kernel: ACPI: AC Adapter [AC] (on-line) > > Jul 11 23:32:46 server1 kernel: ACPI: Battery Slot [BAT1] (battery present) > > Jul 11 23:32:46 server1 kernel: ACPI: Battery Slot [BAT2] (battery absent) > > Jul 11 23:32:46 server1 kernel: ACPI: Power Button (FF) [PWRF] > > Jul 11 23:32:46 server1 kernel: ACPI: Lid Switch [LID] > > Jul 11 23:32:46 server1 kernel: ACPI: Sleep Button (CM) [SLPB] > > Jul 11 23:32:46 server1 kernel: ibm_acpi: IBM ThinkPad ACPI Extras v0.12a > > Jul 11 23:32:46 server1 kernel: ibm_acpi: http://ibm-acpi.sf.net/ > > Jul 11 23:32:46 server1 kernel: ibm_acpi: dock device not present > > Jul 11 23:32:46 server1 kernel: ibm_acpi: bay device not present > > Jul 11 23:32:46 server1 kernel: ACPI: Video Device [VGA] (multi-head: yes > > rom: no post: no) > > Jul 11 23:32:46 server1 kernel: md: Autodetecting RAID arrays. > > Jul 11 23:32:46 server1 kernel: md: autorun ... > > Jul 11 23:32:47 server1 kernel: md: ... autorun DONE. > > Jul 11 23:32:47 server1 kernel: EXT3 FS on dm-0, internal journal > > Jul 11 23:32:47 server1 kernel: kjournald starting. Commit interval 5 > > seconds > > Jul 11 23:32:47 server1 kernel: EXT3 FS on hda1, internal journal > > Jul 11 23:32:47 server1 kernel: EXT3-fs: mounted filesystem with ordered > > data mode. > > Jul 11 23:32:47 server1 kernel: SELinux: initialized (dev hda1, type ext3), > > uses xattr > > Jul 11 23:32:47 server1 kernel: SELinux: initialized (dev tmpfs, type > > tmpfs), uses transition SIDs > > Jul 11 23:32:47 server1 kernel: Adding 262136k swap on > > /dev/VolGroup00/LogVol01. Priority:-1 extents:1 across:262136k > > Jul 11 23:32:47 server1 kernel: SELinux: initialized (dev binfmt_misc, type > > binfmt_misc), uses genfs_contexts > > Jul 11 23:32:47 server1 kernel: ip_tables: (C) 2000-2006 Netfilter Core > > Team > > Jul 11 23:32:47 server1 kernel: Netfilter messages via NETLINK v0.30. > > Jul 11 23:32:47 server1 kernel: ip_conntrack version 2.4 (1023 buckets, > > 8184 max) - 224 bytes per conntrack > > Jul 11 23:32:47 server1 kernel: pcmcia: Detected deprecated PCMCIA ioctl > > usage from process: cardmgr. > > Jul 11 23:32:47 server1 kernel: pcmcia: This interface will soon be removed > > from the kernel; please expect breakage unless you upgrade to new tools. > > Jul 11 23:32:47 server1 kernel: pcmcia: see > > http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for > > details. > > Jul 11 23:32:47 server1 kernel: cs: IO port probe 0xc00-0xcff: excluding > > 0xcf8-0xcff > > Jul 11 23:32:47 server1 kernel: cs: IO port probe 0xc00-0xcff: excluding > > 0xcf8-0xcff > > Jul 11 23:32:47 server1 kernel: cs: IO port probe 0x800-0x8ff: clean. > > Jul 11 23:32:47 server1 kernel: cs: IO port probe 0x800-0x8ff: clean. > > Jul 11 23:32:47 server1 kernel: cs: IO port probe 0x100-0x4ff: excluding > > 0x170-0x177 0x370-0x377 0x3b8-0x3df 0x4d0-0x4d7 > > Jul 11 23:32:47 server1 kernel: cs: IO port probe 0x100-0x4ff: excluding > > 0x170-0x177 0x370-0x377 0x3b8-0x3df 0x4d0-0x4d7 > > Jul 11 23:32:47 server1 kernel: cs: IO port probe 0xa00-0xaff: clean. > > Jul 11 23:32:47 server1 kernel: cs: IO port probe 0xa00-0xaff: clean. > > Jul 11 23:32:47 server1 kernel: cs: memory probe 0xa0000000-0xa0ffffff: > > clean. > > Jul 11 23:32:47 server1 kernel: pcmcia: registering new device pcmcia1.0 > > Jul 11 23:32:47 server1 kernel: eth0: 3Com 3c589, io 0x300, irq 3, hw_addr > > 00:10:5A:6A:A4:2F > > Jul 11 23:32:47 server1 kernel: 8K FIFO split 5:3 Rx:Tx, auto xcvr > > Jul 11 23:32:47 server1 kernel: audit(1152628341.239:68): avc: denied { > > search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:cardmgr_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628341.239:69): avc: denied { > > search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:cardmgr_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628341.239:70): avc: denied { > > search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:cardmgr_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628341.239:71): avc: denied { > > search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:cardmgr_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628341.239:72): avc: denied { > > search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:cardmgr_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628341.239:73): avc: denied { > > search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:cardmgr_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628341.239:74): avc: denied { > > search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:cardmgr_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628341.239:75): avc: denied { > > search } for pid=1362 comm="sh" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:cardmgr_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628341.275:76): avc: denied { > > search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:cardmgr_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628341.275:77): avc: denied { > > search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:cardmgr_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628341.275:78): avc: denied { > > search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:cardmgr_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628341.279:79): avc: denied { > > search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:cardmgr_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628341.279:80): avc: denied { > > search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:cardmgr_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628341.279:81): avc: denied { > > search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:cardmgr_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628341.279:82): avc: denied { > > search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:cardmgr_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628341.279:83): avc: denied { > > search } for pid=1363 comm="network" name="usr" dev=dm-0 ino=1212417 > > scontext=system_u:system_r:cardmgr_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: eth0: flipped to 10base2 > > Jul 11 23:32:47 server1 kernel: audit(1152628348.743:84): avc: denied { > > search } for pid=1545 comm="named-checkconf" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:named_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628348.775:85): avc: denied { > > search } for pid=1545 comm="named-checkconf" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:named_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628348.779:86): avc: denied { > > search } for pid=1545 comm="named-checkconf" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:named_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628348.779:87): avc: denied { > > search } for pid=1545 comm="named-checkconf" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:named_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628348.779:88): avc: denied { > > search } for pid=1545 comm="named-checkconf" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:named_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628348.787:89): avc: denied { > > search } for pid=1547 comm="named-checkconf" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:named_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 kernel: audit(1152628348.787:90): avc: denied { > > search } for pid=1547 comm="named-checkconf" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:named_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:47 server1 ntpdate[1814]: no server suitable for > > synchronization found > > Jul 11 23:32:47 server1 kernel: audit(1152628348.787:91): avc: denied { > > search } for pid=1547 comm="named-checkconf" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:named_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:48 server1 kernel: audit(1152628348.787:92): avc: denied { > > search } for pid=1547 comm="named-checkconf" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:named_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:48 server1 kernel: audit(1152628348.787:93): avc: denied { > > search } for pid=1547 comm="named-checkconf" name="usr" dev=dm-0 > > ino=1212417 scontext=system_u:system_r:named_t > > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > > Jul 11 23:32:48 server1 kernel: audit(1152628351.123:94): audit_pid=1579 > > old=0 by auid=4294967295 subj=system_u:system_r:auditd_t > > Jul 11 23:32:48 server1 kernel: SELinux: initialized (dev rpc_pipefs, type > > rpc_pipefs), uses genfs_contexts > > Jul 11 23:32:48 server1 kernel: SELinux: initialized (dev autofs, type > > autofs), uses genfs_contexts > > Jul 11 23:32:48 server1 kernel: NET: Registered protocol family 10 > > Jul 11 23:32:48 server1 kernel: lo: Disabled Privacy Extensions > > Jul 11 23:32:48 server1 kernel: IPv6 over IPv4 tunneling driver > > Jul 11 23:32:50 server1 gpm[1844]: *** info [startup.c(95)]: > > Jul 11 23:32:50 server1 gpm[1844]: Started gpm successfully. Entered daemon > > mode. > > Jul 11 23:32:50 server1 gpm[1844]: *** info [mice.c(1766)]: > > Jul 11 23:32:50 server1 gpm[1844]: imps2: Auto-detected intellimouse PS/2 > > Jul 11 23:33:02 server1 iiimd[1881]: started. > > Jul 11 23:33:15 server1 kernel: eth0: coax cable problem > > Jul 11 23:33:20 server1 kernel: eth0: flipped to 10baseT > > It looks to me like you have a labelling problem, with the > directory /usr being labelled httpd_sys_script_exec_t instead of usr_t. > That accounts for most of the above anyway. > > Try: > # restorecon -v /usr > > If that doesn't work, try a full relabel. > > # touch /.autorelabel > # reboot > > (that will take a long time) > > Paul. > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From phaceton at gmail.com Sun Jul 16 12:40:35 2006 From: phaceton at gmail.com (netpython) Date: Sun, 16 Jul 2006 14:40:35 +0200 Subject: mozilla.pp Message-ID: <3655f5d90607160540k61133a57yf3d24d5d6cc0320@mail.gmail.com> Has anyone an idea where to find mozilla.pp file? All i can find are the *.if files. Any help is sincerly apreciated. -- I have made this letter longer than usual, because i lack the time to make it short. From jacliburn at bellsouth.net Sun Jul 16 14:03:57 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Sun, 16 Jul 2006 09:03:57 -0500 Subject: restorecond won't die In-Reply-To: <1153018177.2306.10.camel@osprey.hogchain.net> References: <1153018177.2306.10.camel@osprey.hogchain.net> Message-ID: <1153058637.2234.25.camel@osprey.hogchain.net> On Sat, 2006-07-15 at 21:49 -0500, Jay Cliburn wrote: > On logout of current rawhide, I notice restorecond fails to stop. It > also fails to stop when issued the command 'service restorecond > restart'. This is because the pid in /var/run/restorecond.pid is one > less than the actual pid, so the killproc() function > in /etc/init.d/functions can't find the pid to kill. > > [root at osprey ~]# cat /var/run/restorecond.pid > 2302 > [root at osprey ~]# ps -ef | grep restorecond | grep -v grep > root 2303 1 0 21:35 ? 00:00:00 /usr/sbin/restorecond > > Hand editing /var/run/restorecond.pid to make the value match the > running pid results in a successful restart. > > The end result of this problem is a new restorecond for every 'service > restorecond restart' invocation, since the 'stop' fails and the 'start' > succeeds. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199045 From selinux at gmail.com Sun Jul 16 18:04:54 2006 From: selinux at gmail.com (Tom London) Date: Sun, 16 Jul 2006 11:04:54 -0700 Subject: bootloader_t AVC from nash during kernel install ? Message-ID: <4c4ba1530607161104n6a20c411qb0440cab2a73081f@mail.gmail.com> Running targeted/enforcing (latest Rawhide). Running .2401 kernel, 'yum update'-ing to .2405. Notice this in /var/log/audit/audit.log: type=AVC msg=audit(1153069191.610:60): avc: denied { search } for pid=3962 comm="nash" name="net" dev=proc ino=-268435431 scontext=system_u:system_r:bootloader_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=dir type=SYSCALL msg=audit(1153069191.610:60): arch=40000003 syscall=5 success=no exit=-13 a0=bff1ba68 a1=0 a2=1b6 a3=8 items=1 ppid=3958 pid=3962 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="nash" exe="/sbin/nash" subj=system_u:system_r:bootloader_t:s0 key=(null) type=CWD msg=audit(1153069191.610:60): cwd="/" type=PATH msg=audit(1153069191.610:60): item=0 name="/proc/net/psched" obj=system_u:object_r:sbin_t:s0 <<<< Above repeats about 50 times >>>> type=AVC msg=audit(1153069199.047:110): avc: denied { search } for pid=4277 comm="nash" name="net" dev=proc ino=-268435431 scontext=system_u:system_r:bootloader_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=dir type=SYSCALL msg=audit(1153069199.047:110): arch=40000003 syscall=5 success=no exit=-13 a0=bf9c84d8 a1=0 a2=1b6 a3=8 items=1 ppid=4275 pid=4277 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="nash" exe="/sbin/nash" subj=system_u:system_r:bootloader_t:s0 key=(null) type=CWD msg=audit(1153069199.047:110): cwd="/sys/block/sda" type=PATH msg=audit(1153069199.047:110): item=0 name="/proc/net/psched" obj=system_u:object_r:sbin_t:s0 type=AVC msg=audit(1153069199.711:111): avc: denied { getattr } for pid=4309 comm="lvs" name="/" dev=tmpfs ino=6180 scontext=system_u:system_r:lvm_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir type=SYSCALL msg=audit(1153069199.711:111): arch=40000003 syscall=195 success=no exit=-13 a0=9596cf8 a1=bfcf839c a2=4b09eff4 a3=9596cf8 items=1 ppid=4308 pid=4309 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="lvs" exe="/usr/sbin/lvm" subj=system_u:system_r:lvm_t:s0 key=(null) type=AVC_PATH msg=audit(1153069199.711:111): path="/dev/shm" type=CWD msg=audit(1153069199.711:111): cwd="/" type=PATH msg=audit(1153069199.711:111): item=0 name="/dev/shm" inode=6180 dev=00:12 mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmpfs_t:s0 type=AVC msg=audit(1153069203.111:138): avc: denied { search } for pid=4724 comm="nash" name="net" dev=proc ino=-268435431 scontext=system_u:system_r:bootloader_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=dir type=SYSCALL msg=audit(1153069203.111:138): arch=40000003 syscall=5 success=no exit=-13 a0=bfdc90e8 a1=0 a2=1b6 a3=8 items=1 ppid=4722 pid=4724 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="nash" exe="/sbin/nash" subj=system_u:system_r:bootloader_t:s0 key=(null) type=CWD msg=audit(1153069203.111:138): cwd="/tmp/initrd.GI4508" type=PATH msg=audit(1153069203.111:138): item=0 name="/proc/net/psched" obj=system_u:object_r:sbin_t:s0 tom -- Tom London From paul at city-fan.org Mon Jul 17 07:16:16 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 17 Jul 2006 08:16:16 +0100 Subject: mozilla.pp In-Reply-To: <3655f5d90607160540k61133a57yf3d24d5d6cc0320@mail.gmail.com> References: <3655f5d90607160540k61133a57yf3d24d5d6cc0320@mail.gmail.com> Message-ID: <1153120577.23617.14.camel@laurel.intra.city-fan.org> On Sun, 2006-07-16 at 14:40 +0200, netpython wrote: > Has anyone an idea where to find mozilla.pp file? > All i can find are the *.if files. > Any help is sincerly apreciated. It's part of the base policy, not a separate module. What do you want it for? Paul. From tmraz at redhat.com Mon Jul 17 08:59:33 2006 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 17 Jul 2006 10:59:33 +0200 Subject: key {search write} for xdm_t (and /sbin/su)? In-Reply-To: <4c4ba1530607150950k2ed27be9lbbfc1f6313c8bf44@mail.gmail.com> References: <4c4ba1530607150950k2ed27be9lbbfc1f6313c8bf44@mail.gmail.com> Message-ID: <1153126773.3723.15.camel@perun.kabelta.loc> On Sat, 2006-07-15 at 09:50 -0700, Tom London wrote: > Running latest rawhide, targeted/enforcing. > > Notice the following in /var/log/audit/audit.log: > > type=AVC msg=audit(1152981861.606:20): avc: denied { search } for > pid=2505 comm="gdm-binary" > scontext=system_u:system_r:xdm_t:s0-s0:c0.c255 > tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=key > type=SYSCALL msg=audit(1152981861.606:20): arch=40000003 syscall=288 > success=no exit=-13 a0=3 a1=292e05f8 a2=35ce48 a3=7ce759 items=0 > ppid=2471 pid=2505 auid=500 uid=0 gid=500 euid=0 suid=0 fsuid=0 egid=0 > sgid=500 fsgid=0 tty=(none) comm="gdm-binary" > exe="/usr/sbin/gdm-binary" subj=system_u:system_r:xdm_t:s0-s0:c0.c255 > key=(null) > > type=AVC msg=audit(1152981872.490:26): avc: denied { write } for > pid=2804 comm="gdm-binary" > scontext=system_u:system_r:xdm_t:s0-s0:c0.c255 > tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=key > type=SYSCALL msg=audit(1152981872.490:26): arch=40000003 syscall=288 > success=no exit=-13 a0=8 a1=fffffffc a2=fffffffd a3=1f4 items=0 > ppid=2471 pid=2804 auid=4294967295 uid=500 gid=500 euid=0 suid=0 > fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) comm="gdm-binary" > exe="/usr/sbin/gdm-binary" subj=system_u:system_r:xdm_t:s0-s0:c0.c255 > key=(null) > > and > > type=AVC msg=audit(1152981908.300:32): avc: denied { write } for > pid=3037 comm="su" scontext=user_u:system_r:unconfined_t:s0 > tcontext=user_u:system_r:unconfined_t:s0 tclass=key > type=SYSCALL msg=audit(1152981908.300:32): arch=40000003 syscall=288 > success=no exit=-13 a0=8 a1=fffffffc a2=fffffffd a3=0 items=0 > ppid=2984 pid=3037 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=500 > sgid=500 fsgid=500 tty=pts0 comm="su" exe="/bin/su" > subj=user_u:system_r:unconfined_t:s0 key=(null) > > Believe the second results from me entering 'su -'. This is caused by adding pam_keyinit.so to default configurations of gdm, su and other login services. It will also be added to /etc/pam.d/system-auth(-ac) so it will be called for all services calling pam_open_session. This module initializes the user's session keyring in kernel so that should be probably allowed. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From paul at city-fan.org Mon Jul 17 12:00:44 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 17 Jul 2006 13:00:44 +0100 Subject: mozilla.pp In-Reply-To: <3655f5d90607170426p54d01b21ge608b7c361fe9dca@mail.gmail.com> References: <3655f5d90607160540k61133a57yf3d24d5d6cc0320@mail.gmail.com> <1153120577.23617.14.camel@laurel.intra.city-fan.org> <3655f5d90607170426p54d01b21ge608b7c361fe9dca@mail.gmail.com> Message-ID: <44BB7BEC.2000800@city-fan.org> netpython wrote: > I'm trying to make a policy for the firefox web-browser. > Somebody suggested i should issue:'make mozilla.pp'. > However after a fresh install of fedora is can't possibly > find any mozilla.pp just a bunch of interface files that's > my obstacle :-) Firefox is included in the mozilla policy, but the mozilla policy does not appear to be enabled in FC5 targeted policy. If you want to look at the sources for current policy, install the selinux-policy SRPM, then do "rpmbuild -bp selinux-policy.spec" to get a source tree with the Fedora patches applied. You'll be able to find all you need there. Paul. From selinux at gmail.com Mon Jul 17 13:43:46 2006 From: selinux at gmail.com (Tom London) Date: Mon, 17 Jul 2006 06:43:46 -0700 Subject: SmartCard (pc/sc) generates AVCs Message-ID: <4c4ba1530607170643l66c5c459nc78cc4c9d70dc919@mail.gmail.com> Running latest Rawhide targeted/enforcing. Installing and activating coolkey/etc., causes the following AVCs on shutdown: type=AVC msg=audit(1153095472.474:71): avc: denied { read } for pid=6132 comm="consoletype" name="pcscd.pub" dev=dm-0 ino=2785394 scontext=system_u:system_r:consoletype_t:s0-s0:c0.c255 tcontext=system_u:object_r:var_run_t:s0 tclass=file type=AVC msg=audit(1153095472.474:71): avc: denied { read write } for pid=6132 comm="consoletype" name="[10724]" dev=sockfs ino=10724 scontext=system_u:system_r:consoletype_t:s0-s0:c0.c255 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=unix_stream_socket type=AVC msg=audit(1153095472.474:71): avc: denied { read write } for pid=6132 comm="consoletype" name=636F6F6C6B6579706B313173452D4761746520302030 dev=dm-0 ino=5898307 scontext=system_u:system_r:consoletype_t:s0-s0:c0.c255 tcontext=system_u:object_r:tmp_t:s0 tclass=file type=SYSCALL msg=audit(1153095472.474:71): arch=40000003 syscall=11 success=yes exit=0 a0=890dd48 a1=8913e68 a2=890f528 a3=8913a68 items=2 ppid=6131 pid=6132 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="consoletype" exe="/sbin/consoletype" subj=system_u:system_r:consoletype_t:s0-s0:c0.c255 key=(null) type=AVC_PATH msg=audit(1153095472.474:71): path=2F746D702F2E706B3131697063312F636F6F6C6B6579706B313173452D4761746520302030 type=AVC_PATH msg=audit(1153095472.474:71): path="socket:[10724]" type=AVC_PATH msg=audit(1153095472.474:71): path="/var/run/pcscd.pub" type=EXECVE msg=audit(1153095472.474:71): a0="/sbin/consoletype" type=CWD msg=audit(1153095472.474:71): cwd="/" type=PATH msg=audit(1153095472.474:71): item=0 name="/sbin/consoletype" inode=2687172 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:consoletype_exec_t:s0 type=PATH msg=audit(1153095472.474:71): item=1 name=(null) inode=7798798 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 type=AVC msg=audit(1153095472.478:72): avc: denied { read } for pid=6133 comm="consoletype" name="pcscd.pub" dev=dm-0 ino=2785394 scontext=system_u:system_r:consoletype_t:s0-s0:c0.c255 tcontext=system_u:object_r:var_run_t:s0 tclass=file type=AVC msg=audit(1153095472.478:72): avc: denied { read write } for pid=6133 comm="consoletype" name="[10724]" dev=sockfs ino=10724 scontext=system_u:system_r:consoletype_t:s0-s0:c0.c255 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=unix_stream_socket type=AVC msg=audit(1153095472.478:72): avc: denied { read write } for pid=6133 comm="consoletype" name=636F6F6C6B6579706B313173452D4761746520302030 dev=dm-0 ino=5898307 scontext=system_u:system_r:consoletype_t:s0-s0:c0.c255 tcontext=system_u:object_r:tmp_t:s0 tclass=file type=SYSCALL msg=audit(1153095472.478:72): arch=40000003 syscall=11 success=yes exit=0 a0=8913e50 a1=8913950 a2=890f528 a3=8913a68 items=2 ppid=6113 pid=6133 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="consoletype" exe="/sbin/consoletype" subj=system_u:system_r:consoletype_t:s0-s0:c0.c255 key=(null) type=AVC_PATH msg=audit(1153095472.478:72): path=2F746D702F2E706B3131697063312F636F6F6C6B6579706B313173452D4761746520302030 type=AVC_PATH msg=audit(1153095472.478:72): path="socket:[10724]" type=AVC_PATH msg=audit(1153095472.478:72): path="/var/run/pcscd.pub" type=EXECVE msg=audit(1153095472.478:72): a0="/sbin/consoletype" a1="fg" type=CWD msg=audit(1153095472.478:72): cwd="/" type=PATH msg=audit(1153095472.478:72): item=0 name="/sbin/consoletype" inode=2687172 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:consoletype_exec_t:s0 type=PATH msg=audit(1153095472.478:72): item=1 name=(null) inode=7798798 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 tom -- Tom London From mschwartz at mn.rr.com Mon Jul 17 13:58:33 2006 From: mschwartz at mn.rr.com (Marc Schwartz (via MN)) Date: Mon, 17 Jul 2006 08:58:33 -0500 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <44B7D0DA.9090207@city-fan.org> References: <1151353351.8219.118.camel@localhost.localdomain> <1151363136.2911.52.camel@laurel.intra.city-fan.org> <1151381464.13100.65.camel@localhost.localdomain> <44A15AC3.5090000@city-fan.org> <1151429665.4219.57.camel@localhost.localdomain> <1151503719.7470.12.camel@laurel.intra.city-fan.org> <1151522527.3438.52.camel@localhost.localdomain> <1151525638.7470.77.camel@laurel.intra.city-fan.org> <1151528181.3438.98.camel@localhost.localdomain> <1151529828.7470.92.camel@laurel.intra.city-fan.org> <1151530682.3438.108.camel@localhost.localdomain> <1151532794.7470.101.camel@laurel.intra.city-fan.org> <1151550925.6200.48.camel@localhost.localdomain> <1151566188.7470.111.camel@laurel.intra.city-fan.org> <1151587633.6200.56.camel@localhost.localdomain> <1151624293.6466.10.camel@localhost.localdomain> <44A524CE.1070205@city-fan.org> <44AA9CF1.6000601@city-fan.org> <1152125919.4843.141.camel@localhost.localdomain> <44B7D0DA.9090207@city-fan.org> Message-ID: <1153144713.4897.18.camel@localhost.localdomain> On Fri, 2006-07-14 at 18:14 +0100, Paul Howarth wrote: > I think I've got to the bottom of this now. I actually installed > perl-Razor-Agent myself (I'm using sendmail but that doesn't really > matter) to figure out what was happening. > > razor, like spamassassin, is written in perl. This allows spamassassin > to call razor directly by simply using the razor perl modules rather > than the razor client "binaries" in /usr/bin. Thus spamassassin runs a > razor client in its own domain, spamd_t. There is in fact no need for a > domain transition from spamd_t to razor_t. > > Now to get rid of the AVCs. Please update to the policy modules included > below. Then: > > # mkdir /var/log/spamassassin > # restorecon -v /var/log/spamassassin > > Edit /etc/mail/spamassassin/razor/razor-agent.conf and set: > > logfile = /var/log/spamassassin/razor-agent.log > > Then restart spamassassin. Thanks Paul. I appreciate your persistence with this. All done. > >> Any thoughts on why dccproc might be wanting to read > >> /root/.rh-fontconfig/.fonts.cache-2? > > > > No definitive answer. > > > > Checking the dcc source code tree using grep, the only references to > > 'font' are in the cgi-bin files (common and common.in) and then in the > > HTML files (FAQ.HTML and INSTALL.HTML). > > I think this is probably a leaked file descriptor. I don't know where > the leak is or what to do about it though. Latest avc's below, subsequent to the updates and reboots. I have tried to remove a lot of the dups. If you need more info, let me know. Marc type=AVC msg=audit(1153023605.343:2448): avc: denied { getattr } for pid=11448 comm="spamd" name="dccproc" dev=hdc7 ino=1245188 s context=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_exec_t:s0 tclass=file type=SYSCALL msg=audit(1153023605.343:2448): arch=40000003 syscall=195 success=no exit=-13 a0=999da10 a1=95f30c8 a2=4891eff4 a3=999d a10 items=1 pid=11448 auid=500 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd" exe="/usr/bin /perl" subj=system_u:system_r:spamd_t:s0 type=AVC_PATH msg=audit(1153023605.343:2448): path="/usr/local/bin/dccproc" type=CWD msg=audit(1153023605.343:2448): cwd="/" type=PATH msg=audit(1153023605.343:2448): item=0 name="/usr/local/bin/dccproc" inode=1245188 dev=16:07 mode=0104555 ouid=0 ogid=1 rd ev=00:00 obj=system_u:object_r:dcc_client_exec_t:s0 type=AVC msg=audit(1153023963.916:2467): avc: denied { getattr } for pid=11448 comm="spamd" name="dccproc" dev=hdc7 ino=1245188 s context=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_exec_t:s0 tclass=file type=SYSCALL msg=audit(1153023963.916:2467): arch=40000003 syscall=195 success=no exit=-13 a0=999da10 a1=95f30c8 a2=4891eff4 a3=999d a10 items=1 pid=11448 auid=500 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd" exe="/usr/bin /perl" subj=system_u:system_r:spamd_t:s0 type=AVC_PATH msg=audit(1153023963.916:2467): path="/usr/local/bin/dccproc" type=CWD msg=audit(1153023963.916:2467): cwd="/" type=PATH msg=audit(1153024204.542:2488): item=0 name="/usr/local/bin/dccproc" inode=1245188 dev=16:07 mode=0104555 ouid=0 ogid=1 rd ev=00:00 obj=system_u:object_r:dcc_client_exec_t:s0 type=AVC msg=audit(1153024564.267:2507): avc: denied { name_bind } for pid=11448 comm="spamd" src=7002 scontext=system_u:system_r :spamd_t:s0 tcontext=system_u:object_r:afs_pt_port_t:s0 tclass=udp_socket type=SYSCALL msg=audit(1153024564.267:2507): arch=40000003 syscall=102 success=no exit=-13 a0=2 a1=bfa7e6e0 a2=2b5b8c a3=10 items=0 pid=11448 auid=500 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd" exe="/usr/bin/perl" subj= system_u:system_r:spamd_t:s0 type=SOCKADDR msg=audit(1153024564.267:2507): saddr=02001B5A000000000000000000000000 type=SOCKETCALL msg=audit(1153024564.267:2507): nargs=3 a0=b a1=a238438 a2=10 type=PATH msg=audit(1153028525.987:2792): item=0 name="/usr/local/bin/dccproc" inode=1245188 dev=16:07 mode=0104555 ouid=0 ogid=1 rd ev=00:00 obj=system_u:object_r:dcc_client_exec_t:s0 type=AVC msg=audit(1153029648.965:2883): avc: denied { search } for pid=9095 comm="dccproc" name="dcc" dev=dm-1 ino=58510 scontex t=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_var_t:s0 tclass=dir type=SYSCALL msg=audit(1153029648.965:2883): arch=40000003 syscall=12 success=no exit=-13 a0=bfd65a42 a1=0 a2=4891eff4 a3=37 items=1 pid=9095 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 tty=(none) comm="dccproc" exe="/usr/local/bin/dcc proc" subj=system_u:system_r:spamd_t:s0 type=CWD msg=audit(1153029648.965:2883): cwd="/" type=PATH msg=audit(1153029648.965:2883): item=0 name="/var/dcc" inode=58510 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=syst em_u:object_r:dcc_var_t:s0 type=AVC msg=audit(1153030201.398:2924): avc: denied { read } for pid=11167 comm="restorecon" name="[220111]" dev=pipefs ino=2201 11 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file type=AVC msg=audit(1153030201.398:2924): avc: denied { write } for pid=11167 comm="restorecon" name="[220112]" dev=pipefs ino=220 112 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file type=AVC msg=audit(1153030201.398:2924): avc: denied { write } for pid=11167 comm="restorecon" name="[220112]" dev=pipefs ino=220 112 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file type=SYSCALL msg=audit(1153030201.398:2924): arch=40000003 syscall=11 success=yes exit=0 a0=89ad188 a1=89ad320 a2=89ad258 a3=89acfc0 items=2 pid=11167 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="restorecon" exe="/sbin/restorecon " subj=user_u:system_r:restorecon_t:s0 type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220112]" type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220112]" type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220111]" type=CWD msg=audit(1153030201.398:2924): cwd="/" type=PATH msg=audit(1153030201.398:2924): item=0 name="/sbin/restorecon" inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00 obj=system_u:object_r:restorecon_exec_t:s0 type=PATH msg=audit(1153030201.398:2924): item=1 name=(null) inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system _u:object_r:ld_so_t:s0 type=AVC msg=audit(1153030201.414:2925): avc: denied { sigchld } for pid=11161 comm="crond" scontext=user_u:system_r:restorecon_t :s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=process type=SYSCALL msg=audit(1153030201.414:2925): arch=40000003 syscall=114 success=no exit=-10 a0=ffffffff a1=bfbc27f0 a2=0 a3=0 items=0 pid=11161 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="crond" exe="/usr/sbin/crond" subj=system_ u:system_r:crond_t:s0-s0:c0.c255 type=AVC msg=audit(1153030261.495:2940): avc: denied { read } for pid=11202 comm="restorecon" name="[220497]" dev=pipefs ino=2204 97 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file type=AVC msg=audit(1153030261.495:2940): avc: denied { write } for pid=11202 comm="restorecon" name="[220498]" dev=pipefs ino=220 498 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file type=AVC msg=audit(1153030261.495:2940): avc: denied { write } for pid=11202 comm="restorecon" name="[220498]" dev=pipefs ino=220 498 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file type=AVC msg=audit(1153030261.515:2941): avc: denied { sigchld } for pid=11201 comm="crond" scontext=user_u:system_r:restorecon_t :s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=process type=SYSCALL msg=audit(1153030261.515:2941): arch=40000003 syscall=114 success=no exit=-10 a0=ffffffff a1=bfbc27f0 a2=0 a3=0 items=0 pid=11201 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="crond" exe="/usr/sbin/crond" subj=system_ u:system_r:crond_t:s0-s0:c0.c255 type=SYSCALL msg=audit(1153030261.495:2940): arch=40000003 syscall=11 success=yes exit=0 a0=84d91a0 a1=84d9340 a2=84d9278 a3=84d8fb8 items=2 pid=11202 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="restorecon" exe="/sbin/restorecon " subj=user_u:system_r:restorecon_t:s0 type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220498]" type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220498]" type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220497]" type=CWD msg=audit(1153030261.495:2940): cwd="/" type=PATH msg=audit(1153030261.495:2940): item=0 name="/sbin/restorecon" inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00 obj=system_u:object_r:restorecon_exec_t:s0 type=PATH msg=audit(1153030261.495:2940): item=1 name=(null) inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system _u:object_r:ld_so_t:s0 type=AVC msg=audit(1153030444.617:2952): avc: denied { getattr } for pid=11448 comm="spamd" name="dccproc" dev=hdc7 ino=3135647 s context=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_exec_t:s0 tclass=file type=SYSCALL msg=audit(1153030444.617:2952): arch=40000003 syscall=195 success=no exit=-13 a0=999da10 a1=95f30c8 a2=4891eff4 a3=999d a10 items=1 pid=11448 auid=500 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd" exe="/usr/bin /perl" subj=system_u:system_r:spamd_t:s0 type=AVC_PATH msg=audit(1153030444.617:2952): path="/usr/local/bin/dccproc" type=CWD msg=audit(1153030444.617:2952): cwd="/" type=PATH msg=audit(1153052884.204:4562): item=0 name="/usr/local/bin/dccproc" inode=3135647 dev=16:07 mode=0104555 ouid=0 ogid=1 rd ev=00:00 obj=system_u:object_r:dcc_client_exec_t:s0 type=AVC msg=audit(1153053408.030:4599): avc: denied { execmod } for pid=6019 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" d ev=hdc7 ino=3116816 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file type=SYSCALL msg=audit(1153053408.030:4599): arch=40000003 syscall=125 success=no exit=-13 a0=5c8000 a1=78e000 a2=5 a3=bf84c100 item s=0 pid=6019 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2" exe="/lib/ld-2.4.so" sub j=user_u:system_r:prelink_t:s0 type=AVC_PATH msg=audit(1153053408.030:4599): path="/usr/lib/libGLcore.so.1.0.8762" type=AVC msg=audit(1153053408.034:4600): avc: denied { execmod } for pid=6022 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.876 2" dev=hdc7 ino=3117829 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file type=SYSCALL msg=audit(1153053408.034:4600): arch=40000003 syscall=125 success=no exit=-13 a0=a3e000 a1=1000 a2=5 a3=bfc98d40 items= 0 pid=6022 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2" exe="/lib/ld-2.4.so" subj= user_u:system_r:prelink_t:s0 type=AVC_PATH msg=audit(1153053408.034:4600): path="/usr/lib/tls/libnvidia-tls.so.1.0.8762" type=AVC msg=audit(1153054263.049:4661): avc: denied { getattr } for pid=11448 comm="spamd" name="dccproc" dev=hdc7 ino=3135647 s context=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_exec_t:s0 tclass=file type=SYSCALL msg=audit(1153054263.049:4661): arch=40000003 syscall=195 success=no exit=-13 a0=999da10 a1=95f30c8 a2=4891eff4 a3=999d a10 items=1 pid=11448 auid=500 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd" exe="/usr/bin /perl" subj=system_u:system_r:spamd_t:s0 type=AVC_PATH msg=audit(1153054263.049:4661): path="/usr/local/bin/dccproc" type=CWD msg=audit(1153054263.049:4661): cwd="/" type=PATH msg=audit(1153116601.146:9086): item=0 name="/sbin/restorecon" inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00 obj=system_u:object_r:restorecon_exec_t:s0 type=PATH msg=audit(1153116601.146:9086): item=1 name=(null) inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system _u:object_r:ld_so_t:s0 type=AVC msg=audit(1153116605.562:9094): avc: denied { create } for pid=25363 comm="dccproc" scontext=system_u:system_r:spamd_t:s 0 tcontext=system_u:system_r:spamd_t:s0 tclass=netlink_route_socket type=SYSCALL msg=audit(1153116605.562:9094): arch=40000003 syscall=102 success=no exit=-13 a0=1 a1=bf9fbd58 a2=4891eff4 a3=806a0ff i tems=0 pid=25363 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 tty=(none) comm="dccproc" exe="/usr/local/ bin/dccproc" subj=system_u:system_r:spamd_t:s0 type=SOCKETCALL msg=audit(1153116605.562:9094): nargs=3 a0=10 a1=3 a2=0 type=AVC msg=audit(1153116605.562:9095): avc: denied { search } for pid=25363 comm="dccproc" name="dcc" dev=dm-1 ino=58510 sconte xt=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_var_t:s0 tclass=dir type=SYSCALL msg=audit(1153116605.562:9095): arch=40000003 syscall=12 success=no exit=-13 a0=bf9faec2 a1=0 a2=4891eff4 a3=806a0ff it ems=1 pid=25363 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 tty=(none) comm="dccproc" exe="/usr/local/b in/dccproc" subj=system_u:system_r:spamd_t:s0 type=CWD msg=audit(1153116605.562:9095): cwd="/" type=PATH msg=audit(1153116605.562:9095): item=0 name="/var/dcc" inode=58510 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=syst em_u:object_r:dcc_var_t:s0 type=PATH msg=audit(1153116661.743:9100): item=0 name="/sbin/restorecon" inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00 obj=system_u:object_r:restorecon_exec_t:s0 type=PATH msg=audit(1153116661.743:9100): item=1 name=(null) inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system _u:object_r:ld_so_t:s0 type=AVC msg=audit(1153116661.751:9101): avc: denied { sigchld } for pid=25592 comm="crond" scontext=user_u:system_r:restorecon_t :s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=process type=SYSCALL msg=audit(1153116661.751:9101): arch=40000003 syscall=114 success=no exit=-10 a0=ffffffff a1=bfbc27f0 a2=0 a3=0 items=0 pid=25592 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="crond" exe="/usr/sbin/crond" subj=system_ u:system_r:crond_t:s0-s0:c0.c255 type=AVC msg=audit(1153116905.512:9124): avc: denied { getattr } for pid=11448 comm="spamd" name="dccproc" dev=hdc7 ino=3135642 s context=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_exec_t:s0 tclass=file type=SYSCALL msg=audit(1153116905.512:9124): arch=40000003 syscall=195 success=no exit=-13 a0=999da10 a1=95f30c8 a2=4891eff4 a3=999d a10 items=1 pid=11448 auid=500 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd" exe="/usr/bin /perl" subj=system_u:system_r:spamd_t:s0 type=AVC_PATH msg=audit(1153116905.512:9124): path="/usr/local/bin/dccproc" type=CWD msg=audit(1153116905.512:9124): cwd="/" type=PATH msg=audit(1153138559.711:8): item=0 name="/var/run/utmp" inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj= system_u:object_r:init_var_run_t:s0 type=AVC msg=audit(1153138559.715:9): avc: denied { read } for pid=2374 comm="mingetty" name="utmp" dev=dm-1 ino=87750 scontext=s ystem_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file type=SYSCALL msg=audit(1153138559.715:9): arch=40000003 syscall=5 success=no exit=-13 a0=48909fd4 a1=0 a2=804a000 a3=48909fda items= 1 pid=2374 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty" exe="/sbin/mingetty" s ubj=system_u:system_r:getty_t:s0 type=CWD msg=audit(1153138559.715:9): cwd="/" type=PATH msg=audit(1153138559.715:9): item=0 name="/var/run/utmp" inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj= system_u:object_r:init_var_run_t:s0 type=AVC msg=audit(1153138559.715:10): avc: denied { read write } for pid=2374 comm="mingetty" name="utmp" dev=dm-1 ino=87750 sco ntext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file type=SYSCALL msg=audit(1153138559.715:10): arch=40000003 syscall=5 success=no exit=-13 a0=48909fd4 a1=2 a2=0 a3=48909fda items=1 pid =2374 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty" exe="/sbin/mingetty" subj=s ystem_u:system_r:getty_t:s0 type=CWD msg=audit(1153138559.715:10): cwd="/" From paul at city-fan.org Mon Jul 17 17:50:42 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 17 Jul 2006 18:50:42 +0100 Subject: Local Policy Module Introduction Message-ID: <44BBCDF2.6010802@city-fan.org> I put together a first pass of a mini-HOWTO on building local SELinux policy modules in FC5 onwards: http://www.city-fan.org/tips/BuildSeLinuxPolicyModules Feedback welcome. Paul. From sundaram at fedoraproject.org Mon Jul 17 17:57:57 2006 From: sundaram at fedoraproject.org (Rahul) Date: Mon, 17 Jul 2006 23:27:57 +0530 Subject: Local Policy Module Introduction In-Reply-To: <44BBCDF2.6010802@city-fan.org> References: <44BBCDF2.6010802@city-fan.org> Message-ID: <44BBCFA5.2050902@fedoraproject.org> Paul Howarth wrote: > I put together a first pass of a mini-HOWTO on building local SELinux > policy modules in FC5 onwards: > > http://www.city-fan.org/tips/BuildSeLinuxPolicyModules > Wouldnt it be better to put this information under SELinux pages in http://fedoraproject.org/wiki/SELinux? Rahul From jochen.wiedmann at gmail.com Mon Jul 17 19:05:00 2006 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Mon, 17 Jul 2006 21:05:00 +0200 Subject: CGI script calling sudo Message-ID: Hi, I have a CGI script with the following permissions: -rwxr-xr-x root root root:object_r:httpd_unconfined_script_exec_t mpver.cgi This script is internally invoking "sudo". Sudo itself is a wrapper for -rwxr-xr-x root root system_u:object_r:shell_exec_t /usr/sbin/sesh This invocation fails, however: Jul 17 20:51:35 fibudbserver kernel: audit(1153162295.966:6): avc: denied { transition } for pid=20441 comm="sudo" name="sesh" dev=sda1 ino=235570 scontext=user_u:system_r:httpd_unconfined_script_t tcontext=root:system_r:unconfined_t tclass=process What do I need to change? Regards, Jochen -- Whenever you find yourself on the side of the majority, it is time to pause and reflect. (Mark Twain) From mattdm at mattdm.org Mon Jul 17 19:15:23 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 17 Jul 2006 15:15:23 -0400 Subject: CGI script calling sudo In-Reply-To: References: Message-ID: <20060717191523.GA26518@jadzia.bu.edu> On Mon, Jul 17, 2006 at 09:05:00PM +0200, Jochen Wiedmann wrote: > Hi, > I have a CGI script with the following permissions: > -rwxr-xr-x root root > root:object_r:httpd_unconfined_script_exec_t mpver.cgi > This script is internally invoking "sudo". Sudo itself is a wrapper for > -rwxr-xr-x root root system_u:object_r:shell_exec_t > /usr/sbin/sesh > This invocation fails, however: > Jul 17 20:51:35 fibudbserver kernel: audit(1153162295.966:6): avc: > denied { transition } for pid=20441 comm="sudo" name="sesh" > dev=sda1 ino=235570 scontext=user_u:system_r:httpd_unconfined_script_t > tcontext=root:system_r:unconfined_t tclass=process > What do I need to change? Can you accomplish your task in some other way? This seems horribly dangerous. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From paul at city-fan.org Tue Jul 18 12:26:41 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 18 Jul 2006 13:26:41 +0100 Subject: Local Policy Module Introduction In-Reply-To: <20060717185731.GA17763@w-m-p.com> References: <44BBCDF2.6010802@city-fan.org> <20060717182936.GA5973@w-m-p.com> <20060717185731.GA17763@w-m-p.com> Message-ID: <44BCD381.70808@city-fan.org> Klaus Weidner wrote: > On Mon, Jul 17, 2006 at 01:29:36PM -0500, Klaus Weidner wrote: >> Are the changes persistent across reboots or do you need to add the >> "semodule -i" to a startup file? And do you need special steps if >> upgrading the policy RPM? > > Oops, just noticed that you do document that it's persistent > automatically. So that just leaves the second part ;-) > > Thanks again for the HOWTO, Thanks. I've added a new section at the end on Module Longevity. In short, policy modules will generally survive base policy updates too. Paul. From paul at city-fan.org Tue Jul 18 12:31:34 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 18 Jul 2006 13:31:34 +0100 Subject: Local Policy Module Introduction In-Reply-To: <44BBCFA5.2050902@fedoraproject.org> References: <44BBCDF2.6010802@city-fan.org> <44BBCFA5.2050902@fedoraproject.org> Message-ID: <44BCD4A6.3040204@city-fan.org> Rahul wrote: > Paul Howarth wrote: >> I put together a first pass of a mini-HOWTO on building local SELinux >> policy modules in FC5 onwards: >> >> http://www.city-fan.org/tips/BuildSeLinuxPolicyModules >> > > Wouldnt it be better to put this information under SELinux pages in > http://fedoraproject.org/wiki/SELinux? I intend to do that eventually. I didn't write the draft there because: 1. It's a draft for comments at the moment, 2. It references at least one other page on my site, so I'll need to tweak it a bit for the Fedora Wiki, and 3. I have recently found that I no longer have edit access to a number of pages on the Fedora Wiki that I've contributed to in the past. Whilst I understand why this was done, I don't think it was the best way to handle the problem and it's somewhat irritating to see things that need fixing and not being able to fix them without going through some red tape. I'd rather spend my time doing something more useful. Paul. From paul at city-fan.org Tue Jul 18 13:11:56 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 18 Jul 2006 14:11:56 +0100 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <1153144713.4897.18.camel@localhost.localdomain> References: <1151381464.13100.65.camel@localhost.localdomain> <44A15AC3.5090000@city-fan.org> <1151429665.4219.57.camel@localhost.localdomain> <1151503719.7470.12.camel@laurel.intra.city-fan.org> <1151522527.3438.52.camel@localhost.localdomain> <1151525638.7470.77.camel@laurel.intra.city-fan.org> <1151528181.3438.98.camel@localhost.localdomain> <1151529828.7470.92.camel@laurel.intra.city-fan.org> <1151530682.3438.108.camel@localhost.localdomain> <1151532794.7470.101.camel@laurel.intra.city-fan.org> <1151550925.6200.48.camel@localhost.localdomain> <1151566188.7470.111.camel@laurel.intra.city-fan.org> <1151587633.6200.56.camel@localhost.localdomain> <1151624293.6466.10.camel@localhost.localdomain> <44A524CE.1070205@city-fan.org> <44AA9CF1.6000601@city-fan.org> <1152125919.4843.141.camel@localhost.localdomain> <44B7D0DA.9090207@city-fan.org> <1153144713.4897.18.camel@localhost.localdomain> Message-ID: <44BCDE1C.8070409@city-fan.org> Marc Schwartz (via MN) wrote: > Latest avc's below, subsequent to the updates and reboots. I have tried > to remove a lot of the dups. If you need more info, let me know. > > Marc > > > type=AVC msg=audit(1153023605.343:2448): avc: denied { getattr } for pid=11448 comm="spamd" name="dccproc" dev=hdc7 ino=1245188 s context=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1153023605.343:2448): arch=40000003 syscall=195 success=no exit=-13 a0=999da10 a1=95f30c8 a2=4891eff4 a3=999d a10 items=1 pid=11448 auid=500 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd" exe="/usr/bin /perl" subj=system_u:system_r:spamd_t:s0 > type=AVC_PATH msg=audit(1153023605.343:2448): path="/usr/local/bin/dccproc" > type=CWD msg=audit(1153023605.343:2448): cwd="/" > type=PATH msg=audit(1153023605.343:2448): item=0 name="/usr/local/bin/dccproc" inode=1245188 dev=16:07 mode=0104555 ouid=0 ogid=1 rd ev=00:00 obj=system_u:object_r:dcc_client_exec_t:s0 > type=AVC msg=audit(1153023963.916:2467): avc: denied { getattr } for pid=11448 comm="spamd" name="dccproc" dev=hdc7 ino=1245188 s context=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1153023963.916:2467): arch=40000003 syscall=195 success=no exit=-13 a0=999da10 a1=95f30c8 a2=4891eff4 a3=999d a10 items=1 pid=11448 auid=500 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd" exe="/usr/bin /perl" subj=system_u:system_r:spamd_t:s0 > type=AVC_PATH msg=audit(1153023963.916:2467): path="/usr/local/bin/dccproc" > type=CWD msg=audit(1153023963.916:2467): cwd="/" > type=PATH msg=audit(1153024204.542:2488): item=0 name="/usr/local/bin/dccproc" inode=1245188 dev=16:07 mode=0104555 ouid=0 ogid=1 rd ev=00:00 obj=system_u:object_r:dcc_client_exec_t:s0 > type=AVC msg=audit(1153024564.267:2507): avc: denied { name_bind } for pid=11448 comm="spamd" src=7002 scontext=system_u:system_r :spamd_t:s0 tcontext=system_u:object_r:afs_pt_port_t:s0 tclass=udp_socket > type=SYSCALL msg=audit(1153024564.267:2507): arch=40000003 syscall=102 success=no exit=-13 a0=2 a1=bfa7e6e0 a2=2b5b8c a3=10 items=0 pid=11448 auid=500 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd" exe="/usr/bin/perl" subj= system_u:system_r:spamd_t:s0 > type=SOCKADDR msg=audit(1153024564.267:2507): saddr=02001B5A000000000000000000000000 > type=SOCKETCALL msg=audit(1153024564.267:2507): nargs=3 a0=b a1=a238438 a2=10 > type=PATH msg=audit(1153028525.987:2792): item=0 name="/usr/local/bin/dccproc" inode=1245188 dev=16:07 mode=0104555 ouid=0 ogid=1 rd ev=00:00 obj=system_u:object_r:dcc_client_exec_t:s0 > type=AVC msg=audit(1153029648.965:2883): avc: denied { search } for pid=9095 comm="dccproc" name="dcc" dev=dm-1 ino=58510 scontex t=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_var_t:s0 tclass=dir > type=SYSCALL msg=audit(1153029648.965:2883): arch=40000003 syscall=12 success=no exit=-13 a0=bfd65a42 a1=0 a2=4891eff4 a3=37 items=1 pid=9095 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 tty=(none) comm="dccproc" exe="/usr/local/bin/dcc proc" subj=system_u:system_r:spamd_t:s0 > type=CWD msg=audit(1153029648.965:2883): cwd="/" > type=PATH msg=audit(1153029648.965:2883): item=0 name="/var/dcc" inode=58510 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=syst em_u:object_r:dcc_var_t:s0 I think you're getting these because I removed the transition from spamd_t to dcc_client_t, since I thought that with the dcc policy now being included in the selinux-policy-targeted package, would already be included. > type=AVC msg=audit(1153030201.398:2924): avc: denied { read } for pid=11167 comm="restorecon" name="[220111]" dev=pipefs ino=2201 11 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file > type=AVC msg=audit(1153030201.398:2924): avc: denied { write } for pid=11167 comm="restorecon" name="[220112]" dev=pipefs ino=220 112 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file > type=AVC msg=audit(1153030201.398:2924): avc: denied { write } for pid=11167 comm="restorecon" name="[220112]" dev=pipefs ino=220 112 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file > type=SYSCALL msg=audit(1153030201.398:2924): arch=40000003 syscall=11 success=yes exit=0 a0=89ad188 a1=89ad320 a2=89ad258 a3=89acfc0 items=2 pid=11167 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="restorecon" exe="/sbin/restorecon " subj=user_u:system_r:restorecon_t:s0 > type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220112]" > type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220112]" > type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220111]" > type=CWD msg=audit(1153030201.398:2924): cwd="/" > type=PATH msg=audit(1153030201.398:2924): item=0 name="/sbin/restorecon" inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00 obj=system_u:object_r:restorecon_exec_t:s0 > type=PATH msg=audit(1153030201.398:2924): item=1 name=(null) inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system _u:object_r:ld_so_t:s0 > type=AVC msg=audit(1153030201.414:2925): avc: denied { sigchld } for pid=11161 comm="crond" scontext=user_u:system_r:restorecon_t :s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=process > type=SYSCALL msg=audit(1153030201.414:2925): arch=40000003 syscall=114 success=no exit=-10 a0=ffffffff a1=bfbc27f0 a2=0 a3=0 items=0 pid=11161 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="crond" exe="/usr/sbin/crond" subj=system_ u:system_r:crond_t:s0-s0:c0.c255 > type=AVC msg=audit(1153030261.495:2940): avc: denied { read } for pid=11202 comm="restorecon" name="[220497]" dev=pipefs ino=2204 97 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file > type=AVC msg=audit(1153030261.495:2940): avc: denied { write } for pid=11202 comm="restorecon" name="[220498]" dev=pipefs ino=220 498 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file > type=AVC msg=audit(1153030261.495:2940): avc: denied { write } for pid=11202 comm="restorecon" name="[220498]" dev=pipefs ino=220 498 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file > type=AVC msg=audit(1153030261.515:2941): avc: denied { sigchld } for pid=11201 comm="crond" scontext=user_u:system_r:restorecon_t :s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=process > type=SYSCALL msg=audit(1153030261.515:2941): arch=40000003 syscall=114 success=no exit=-10 a0=ffffffff a1=bfbc27f0 a2=0 a3=0 items=0 pid=11201 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="crond" exe="/usr/sbin/crond" subj=system_ u:system_r:crond_t:s0-s0:c0.c255 > type=SYSCALL msg=audit(1153030261.495:2940): arch=40000003 syscall=11 success=yes exit=0 a0=84d91a0 a1=84d9340 a2=84d9278 a3=84d8fb8 items=2 pid=11202 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="restorecon" exe="/sbin/restorecon " subj=user_u:system_r:restorecon_t:s0 > type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220498]" > type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220498]" > type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220497]" > type=CWD msg=audit(1153030261.495:2940): cwd="/" > type=PATH msg=audit(1153030261.495:2940): item=0 name="/sbin/restorecon" inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00 obj=system_u:object_r:restorecon_exec_t:s0 > type=PATH msg=audit(1153030261.495:2940): item=1 name=(null) inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system _u:object_r:ld_so_t:s0 These all appear to be due to running restorecon in a cron job. Probably your dcc client building script. I could add this to the dcc policy (or a separate local module for restorecon): cron_system_entry(restorecon_t) However, I think that the "right" way to fix this would be to use restorecond and add an entry to /etc/selinux/restorecond.conf (the manpage for restorecond suggests /etc/selinux/POLICYTYPE/restorconfiles.conf but that file doesn't seem to exist, and the restorecond binary includes the string /etc/selinux/restorecond.conf). Maybe Dan could comment on that? > type=AVC msg=audit(1153053408.030:4599): avc: denied { execmod } for pid=6019 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" d ev=hdc7 ino=3116816 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file > type=SYSCALL msg=audit(1153053408.030:4599): arch=40000003 syscall=125 success=no exit=-13 a0=5c8000 a1=78e000 a2=5 a3=bf84c100 item s=0 pid=6019 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2" exe="/lib/ld-2.4.so" sub j=user_u:system_r:prelink_t:s0 > type=AVC_PATH msg=audit(1153053408.030:4599): path="/usr/lib/libGLcore.so.1.0.8762" > type=AVC msg=audit(1153053408.034:4600): avc: denied { execmod } for pid=6022 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.876 2" dev=hdc7 ino=3117829 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file > type=SYSCALL msg=audit(1153053408.034:4600): arch=40000003 syscall=125 success=no exit=-13 a0=a3e000 a1=1000 a2=5 a3=bfc98d40 items= 0 pid=6022 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2" exe="/lib/ld-2.4.so" subj= user_u:system_r:prelink_t:s0 > type=AVC_PATH msg=audit(1153053408.034:4600): path="/usr/lib/tls/libnvidia-tls.so.1.0.8762" Do you have nvidia video drivers installed using the nvidia installer rather than an RPM package? If so, you should probably see: http://www.city-fan.org/tips/ProprietaryVideoDriverWarning > type=PATH msg=audit(1153138559.711:8): item=0 name="/var/run/utmp" inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj= system_u:object_r:init_var_run_t:s0 > type=AVC msg=audit(1153138559.715:9): avc: denied { read } for pid=2374 comm="mingetty" name="utmp" dev=dm-1 ino=87750 scontext=s ystem_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file > type=SYSCALL msg=audit(1153138559.715:9): arch=40000003 syscall=5 success=no exit=-13 a0=48909fd4 a1=0 a2=804a000 a3=48909fda items= 1 pid=2374 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty" exe="/sbin/mingetty" s ubj=system_u:system_r:getty_t:s0 > type=CWD msg=audit(1153138559.715:9): cwd="/" > type=PATH msg=audit(1153138559.715:9): item=0 name="/var/run/utmp" inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj= system_u:object_r:init_var_run_t:s0 > type=AVC msg=audit(1153138559.715:10): avc: denied { read write } for pid=2374 comm="mingetty" name="utmp" dev=dm-1 ino=87750 sco ntext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file > type=SYSCALL msg=audit(1153138559.715:10): arch=40000003 syscall=5 success=no exit=-13 a0=48909fd4 a1=2 a2=0 a3=48909fda items=1 pid =2374 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty" exe="/sbin/mingetty" subj=s ystem_u:system_r:getty_t:s0 > type=CWD msg=audit(1153138559.715:10): cwd="/" Your /var/run/utmp appears to be labelled init_var_run_t rather than initrc_var_run_t. :::::::::::::: myspamassassin.te :::::::::::::: policy_module(myspamassassin, 0.1.5) require { type spamd_t; } type spamd_log_t; logging_log_file(spamd_log_t) # These appear to be in selinux-policy-2.2.47-3.fc5 # but don't seem to be working. Perhaps they need to be # included in the base policy rather than as separate modules? dcc_domtrans_client(spamd_t) pyzor_domtrans(spamd_t) # Signal the dcc client (SIGTERM is used?) dcc_signal_client(spamd_t) # Use log files allow spamd_t spamd_log_t:file create_file_perms; allow spamd_t spamd_log_t:dir rw_dir_perms; logging_log_filetrans(spamd_t,spamd_log_t,{ file dir }) Paul. From paul at city-fan.org Tue Jul 18 13:32:27 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 18 Jul 2006 14:32:27 +0100 Subject: restorecond Message-ID: <44BCE2EB.4030106@city-fan.org> Just came across restorecond and noticed a few things: policycoreutils doesn't do "chkconfig --add restorecond" in %post, nor "chkconfig --del restorecond" in %preun (if the package is about to be deleted). If it did this, restorecond would be enabled by default, which is probably not what was wanted, but changing the initscript to have: # chkconfig: - 10 90 instead of: # chkconfig: 2345 10 90 then the service would not be enabled by default and could safely be "chkconfig --add"-ed. It would then show up properly in the output of "chkconfig --list" Is the config file /etc/selinux/restorecond.conf (as per the contents of the policycoreutils package and the string in the binary of restorecond), or /etc/selinux/POLICYTYPE/restorconfiles.conf (as per the manpage)? Why does the restorecond service sometimes take so long to start up? Well, it took a minute or so on one machine I have, and started almost immediately on another, slower machine. I suspect that the answer may be something to do with the fact that the fast machine has NFS-mounted home directories and it tried accessing ~/public_html for all of them. Which resulted in lots of these: type=AVC msg=audit(1153227661.751:51137): avc: denied { create } for pid=17967 comm="restorecond" scontext=user_u:system_r:restorecond_t:s0 tcontext=user_u:system_r:restorecond_t:s0 tclass=netlink_route_socket type=SYSCALL msg=audit(1153227661.751:51137): arch=40000003 syscall=102 success=no exit=-13 a0=1 a1=bfc93224 a2=d47ff4 a3=999c378 items=0 pid=17967 auid=1012 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="restorecond" exe="/usr/sbin/restorecond" type=SOCKETCALL msg=audit(1153227661.751:51137): nargs=3 a0=10 a1=3 a2=0 type=AVC msg=audit(1153227661.751:51138): avc: denied { create } for pid=17967 comm="restorecond" scontext=user_u:system_r:restorecond_t:s0 tcontext=user_u:system_r:restorecond_t:s0 tclass=tcp_socket type=SYSCALL msg=audit(1153227661.751:51138): arch=40000003 syscall=102 success=no exit=-13 a0=1 a1=bfc9336c a2=3bf0a8 a3=999c378 items=0 pid=17967 auid=1012 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="restorecond" exe="/usr/sbin/restorecond" Removing the home directory references from /etc/selinux/restorecond.conf certainly made it faster. Paul. From mschwartz at mn.rr.com Tue Jul 18 14:53:27 2006 From: mschwartz at mn.rr.com (Marc Schwartz (via MN)) Date: Tue, 18 Jul 2006 09:53:27 -0500 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <44BCDE1C.8070409@city-fan.org> References: <1151381464.13100.65.camel@localhost.localdomain> <44A15AC3.5090000@city-fan.org> <1151429665.4219.57.camel@localhost.localdomain> <1151503719.7470.12.camel@laurel.intra.city-fan.org> <1151522527.3438.52.camel@localhost.localdomain> <1151525638.7470.77.camel@laurel.intra.city-fan.org> <1151528181.3438.98.camel@localhost.localdomain> <1151529828.7470.92.camel@laurel.intra.city-fan.org> <1151530682.3438.108.camel@localhost.localdomain> <1151532794.7470.101.camel@laurel.intra.city-fan.org> <1151550925.6200.48.camel@localhost.localdomain> <1151566188.7470.111.camel@laurel.intra.city-fan.org> <1151587633.6200.56.camel@localhost.localdomain> <1151624293.6466.10.camel@localhost.localdomain> <44A524CE.1070205@city-fan.org> <44AA9CF1.6000601@city-fan.org> <1152125919.4843.141.camel@localhost.localdomain> <44B7D0DA.9090207@city-fan.org> <1153144713.4897.18.camel@localhost.localdomain> <44BCDE1C.8070409@city-fan.org> Message-ID: <1153234408.3796.12.camel@localhost.localdomain> On Tue, 2006-07-18 at 14:11 +0100, Paul Howarth wrote: > Marc Schwartz (via MN) wrote: > > Latest avc's below, subsequent to the updates and reboots. I have tried > > to remove a lot of the dups. If you need more info, let me know. > > > > Marc > > type=AVC msg=audit(1153030201.398:2924): avc: denied { read } for pid=11167 comm="restorecon" name="[220111]" dev=pipefs ino=2201 11 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file > > type=AVC msg=audit(1153030201.398:2924): avc: denied { write } for pid=11167 comm="restorecon" name="[220112]" dev=pipefs ino=220 112 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file > > type=AVC msg=audit(1153030201.398:2924): avc: denied { write } for pid=11167 comm="restorecon" name="[220112]" dev=pipefs ino=220 112 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file > > type=SYSCALL msg=audit(1153030201.398:2924): arch=40000003 syscall=11 success=yes exit=0 a0=89ad188 a1=89ad320 a2=89ad258 a3=89acfc0 items=2 pid=11167 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="restorecon" exe="/sbin/restorecon " subj=user_u:system_r:restorecon_t:s0 > > type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220112]" > > type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220112]" > > type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220111]" > > type=CWD msg=audit(1153030201.398:2924): cwd="/" > > type=PATH msg=audit(1153030201.398:2924): item=0 name="/sbin/restorecon" inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00 obj=system_u:object_r:restorecon_exec_t:s0 > > type=PATH msg=audit(1153030201.398:2924): item=1 name=(null) inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system _u:object_r:ld_so_t:s0 > > type=AVC msg=audit(1153030201.414:2925): avc: denied { sigchld } for pid=11161 comm="crond" scontext=user_u:system_r:restorecon_t :s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=process > > type=SYSCALL msg=audit(1153030201.414:2925): arch=40000003 syscall=114 success=no exit=-10 a0=ffffffff a1=bfbc27f0 a2=0 a3=0 items=0 pid=11161 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="crond" exe="/usr/sbin/crond" subj=system_ u:system_r:crond_t:s0-s0:c0.c255 > > type=AVC msg=audit(1153030261.495:2940): avc: denied { read } for pid=11202 comm="restorecon" name="[220497]" dev=pipefs ino=2204 97 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file > > type=AVC msg=audit(1153030261.495:2940): avc: denied { write } for pid=11202 comm="restorecon" name="[220498]" dev=pipefs ino=220 498 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file > > type=AVC msg=audit(1153030261.495:2940): avc: denied { write } for pid=11202 comm="restorecon" name="[220498]" dev=pipefs ino=220 498 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file > > type=AVC msg=audit(1153030261.515:2941): avc: denied { sigchld } for pid=11201 comm="crond" scontext=user_u:system_r:restorecon_t :s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=process > > type=SYSCALL msg=audit(1153030261.515:2941): arch=40000003 syscall=114 success=no exit=-10 a0=ffffffff a1=bfbc27f0 a2=0 a3=0 items=0 pid=11201 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="crond" exe="/usr/sbin/crond" subj=system_ u:system_r:crond_t:s0-s0:c0.c255 > > type=SYSCALL msg=audit(1153030261.495:2940): arch=40000003 syscall=11 success=yes exit=0 a0=84d91a0 a1=84d9340 a2=84d9278 a3=84d8fb8 items=2 pid=11202 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="restorecon" exe="/sbin/restorecon " subj=user_u:system_r:restorecon_t:s0 > > type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220498]" > > type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220498]" > > type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220497]" > > type=CWD msg=audit(1153030261.495:2940): cwd="/" > > type=PATH msg=audit(1153030261.495:2940): item=0 name="/sbin/restorecon" inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00 obj=system_u:object_r:restorecon_exec_t:s0 > > type=PATH msg=audit(1153030261.495:2940): item=1 name=(null) inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system _u:object_r:ld_so_t:s0 > > These all appear to be due to running restorecon in a cron job. Probably > your dcc client building script. Yep: # Run restorecon to restore the SELinux context after re-building 10 01 * * * root /sbin/restorecon -rv /var/dcc 11 01 * * * root /sbin/restorecon -v /usr/local/bin/dccproc > I could add this to the dcc policy (or a separate local module for > restorecon): > cron_system_entry(restorecon_t) > > However, I think that the "right" way to fix this would be to use > restorecond and add an entry to /etc/selinux/restorecond.conf (the > manpage for restorecond suggests > /etc/selinux/POLICYTYPE/restorconfiles.conf but that file doesn't seem > to exist, and the restorecond binary includes the string > /etc/selinux/restorecond.conf). > > Maybe Dan could comment on that? > > > type=AVC msg=audit(1153053408.030:4599): avc: denied { execmod } for pid=6019 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" d ev=hdc7 ino=3116816 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file > > type=SYSCALL msg=audit(1153053408.030:4599): arch=40000003 syscall=125 success=no exit=-13 a0=5c8000 a1=78e000 a2=5 a3=bf84c100 item s=0 pid=6019 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2" exe="/lib/ld-2.4.so" sub j=user_u:system_r:prelink_t:s0 > > type=AVC_PATH msg=audit(1153053408.030:4599): path="/usr/lib/libGLcore.so.1.0.8762" > > type=AVC msg=audit(1153053408.034:4600): avc: denied { execmod } for pid=6022 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.876 2" dev=hdc7 ino=3117829 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file > > type=SYSCALL msg=audit(1153053408.034:4600): arch=40000003 syscall=125 success=no exit=-13 a0=a3e000 a1=1000 a2=5 a3=bfc98d40 items= 0 pid=6022 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2" exe="/lib/ld-2.4.so" subj= user_u:system_r:prelink_t:s0 > > type=AVC_PATH msg=audit(1153053408.034:4600): path="/usr/lib/tls/libnvidia-tls.so.1.0.8762" > > Do you have nvidia video drivers installed using the nvidia installer > rather than an RPM package? If so, you should probably see: > http://www.city-fan.org/tips/ProprietaryVideoDriverWarning Yep. I have never had a problem with them (dating back to RH 8.0, all on Dell laptops) and this is the first time that I had noted any avc's related to them. I have a script that I ran when I first moved to FC5 to set the following: /usr/sbin/setsebool -P allow_execstack=1 /usr/sbin/setsebool -P allow_execmod=1 based upon documents that I had found elsewhere. I re-ran it just in case something changed after I re-built the driver with the latest kernel install (2157). I'll keep an eye out for any further avc's. I appreciate the caveats noted on the page you reference. > > type=PATH msg=audit(1153138559.711:8): item=0 name="/var/run/utmp" inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj= system_u:object_r:init_var_run_t:s0 > > type=AVC msg=audit(1153138559.715:9): avc: denied { read } for pid=2374 comm="mingetty" name="utmp" dev=dm-1 ino=87750 scontext=s ystem_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file > > type=SYSCALL msg=audit(1153138559.715:9): arch=40000003 syscall=5 success=no exit=-13 a0=48909fd4 a1=0 a2=804a000 a3=48909fda items= 1 pid=2374 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty" exe="/sbin/mingetty" s ubj=system_u:system_r:getty_t:s0 > > type=CWD msg=audit(1153138559.715:9): cwd="/" > > type=PATH msg=audit(1153138559.715:9): item=0 name="/var/run/utmp" inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj= system_u:object_r:init_var_run_t:s0 > > type=AVC msg=audit(1153138559.715:10): avc: denied { read write } for pid=2374 comm="mingetty" name="utmp" dev=dm-1 ino=87750 sco ntext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file > > type=SYSCALL msg=audit(1153138559.715:10): arch=40000003 syscall=5 success=no exit=-13 a0=48909fd4 a1=2 a2=0 a3=48909fda items=1 pid =2374 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty" exe="/sbin/mingetty" subj=s ystem_u:system_r:getty_t:s0 > > type=CWD msg=audit(1153138559.715:10): cwd="/" > > Your /var/run/utmp appears to be labelled init_var_run_t rather than > initrc_var_run_t. Yep: # ls -lZ /var/run/utmp -rw-rw-r-- root utmp system_u:object_r:init_var_run_t /var/run/utmp # restorecon /var/run/utmp # ls -lZ /var/run/utmp -rw-rw-r-- root utmp system_u:object_r:initrc_var_run_t /var/run/utmp > :::::::::::::: > myspamassassin.te > :::::::::::::: > policy_module(myspamassassin, 0.1.5) > > require { > type spamd_t; > } > > type spamd_log_t; > logging_log_file(spamd_log_t) > > # These appear to be in selinux-policy-2.2.47-3.fc5 > # but don't seem to be working. Perhaps they need to be > # included in the base policy rather than as separate modules? > dcc_domtrans_client(spamd_t) > pyzor_domtrans(spamd_t) > > # Signal the dcc client (SIGTERM is used?) > dcc_signal_client(spamd_t) > > # Use log files > allow spamd_t spamd_log_t:file create_file_perms; > allow spamd_t spamd_log_t:dir rw_dir_perms; > logging_log_filetrans(spamd_t,spamd_log_t,{ file dir }) All changed. I'll post back with any new avc's after a bit and a re-boot or two. Thanks, Marc From paul at city-fan.org Tue Jul 18 15:15:38 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 18 Jul 2006 16:15:38 +0100 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <1153234408.3796.12.camel@localhost.localdomain> References: <44A15AC3.5090000@city-fan.org> <1151429665.4219.57.camel@localhost.localdomain> <1151503719.7470.12.camel@laurel.intra.city-fan.org> <1151522527.3438.52.camel@localhost.localdomain> <1151525638.7470.77.camel@laurel.intra.city-fan.org> <1151528181.3438.98.camel@localhost.localdomain> <1151529828.7470.92.camel@laurel.intra.city-fan.org> <1151530682.3438.108.camel@localhost.localdomain> <1151532794.7470.101.camel@laurel.intra.city-fan.org> <1151550925.6200.48.camel@localhost.localdomain> <1151566188.7470.111.camel@laurel.intra.city-fan.org> <1151587633.6200.56.camel@localhost.localdomain> <1151624293.6466.10.camel@localhost.localdomain> <44A524CE.1070205@city-fan.org> <44AA9CF1.6000601@city-fan.org> <1152125919.4843.141.camel@localhost.localdomain> <44B7D0DA.9090207@city-fan.org> <1153144713.4897.18.camel@localhost.localdomain> <44BCDE1C.8070409@city-fan.org> <1153234408.3796.12.camel@localhost.localdomain> Message-ID: <44BCFB1A.8040909@city-fan.org> Marc Schwartz (via MN) wrote: > On Tue, 2006-07-18 at 14:11 +0100, Paul Howarth wrote: > # Run restorecon to restore the SELinux context after re-building > 10 01 * * * root /sbin/restorecon -rv /var/dcc > 11 01 * * * root /sbin/restorecon -v /usr/local/bin/dccproc > > >> I could add this to the dcc policy (or a separate local module for >> restorecon): >> cron_system_entry(restorecon_t) >> >> However, I think that the "right" way to fix this would be to use >> restorecond and add an entry to /etc/selinux/restorecond.conf (the >> manpage for restorecond suggests >> /etc/selinux/POLICYTYPE/restorconfiles.conf but that file doesn't seem >> to exist, and the restorecond binary includes the string >> /etc/selinux/restorecond.conf). >> >> Maybe Dan could comment on that? Try this instead of your cron jobs and see what happens: # chkconfig --add restorecond # chkconfig restorecond on Edit /etc/selinux/restorecond.conf and add a line: /usr/local/bin/dccproc (is the restorecon of /var/dcc actually needed?) If you have network-mounted home directories, you may want to remove the lines starting with "~" Then: # service restorecond start >>> type=AVC msg=audit(1153053408.030:4599): avc: denied { execmod } for pid=6019 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" d ev=hdc7 ino=3116816 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file >>> type=SYSCALL msg=audit(1153053408.030:4599): arch=40000003 syscall=125 success=no exit=-13 a0=5c8000 a1=78e000 a2=5 a3=bf84c100 item s=0 pid=6019 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2" exe="/lib/ld-2.4.so" sub j=user_u:system_r:prelink_t:s0 >>> type=AVC_PATH msg=audit(1153053408.030:4599): path="/usr/lib/libGLcore.so.1.0.8762" >>> type=AVC msg=audit(1153053408.034:4600): avc: denied { execmod } for pid=6022 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.876 2" dev=hdc7 ino=3117829 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file >>> type=SYSCALL msg=audit(1153053408.034:4600): arch=40000003 syscall=125 success=no exit=-13 a0=a3e000 a1=1000 a2=5 a3=bfc98d40 items= 0 pid=6022 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2" exe="/lib/ld-2.4.so" subj= user_u:system_r:prelink_t:s0 >>> type=AVC_PATH msg=audit(1153053408.034:4600): path="/usr/lib/tls/libnvidia-tls.so.1.0.8762" >> Do you have nvidia video drivers installed using the nvidia installer >> rather than an RPM package? If so, you should probably see: >> http://www.city-fan.org/tips/ProprietaryVideoDriverWarning > > Yep. I have never had a problem with them (dating back to RH 8.0, all > on Dell laptops) and this is the first time that I had noted any avc's > related to them. > > I have a script that I ran when I first moved to FC5 to set the > following: > > /usr/sbin/setsebool -P allow_execstack=1 > /usr/sbin/setsebool -P allow_execmod=1 > > based upon documents that I had found elsewhere. That's somewhat overkill and I wouldn't want to do that. Undo it with: # setsebool -P allow_execstack 0 # setsebool -P allow_execmod 0 Then fix the file contexts instead: # semanage fcontext -a -f -- -t textrel_shlib_t '/usr/lib/libGL(core)?\.so(\.[^/]*)*' # semanage fcontext -a -f -- -t textrel_shlib_t '/usr/lib/libnvidia.*\.so(\.[^/]*)*' # restorecon -v /usr/lib/libGL* /usr/lib/libnvidia* Please check that these files have context type textrel_shlib_t after doing this. The upstream policy has file contexts set for this but I fear they're falling foul of the file contexts ordering rules. >>> type=PATH msg=audit(1153138559.711:8): item=0 name="/var/run/utmp" inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj= system_u:object_r:init_var_run_t:s0 >>> type=AVC msg=audit(1153138559.715:9): avc: denied { read } for pid=2374 comm="mingetty" name="utmp" dev=dm-1 ino=87750 scontext=s ystem_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file >>> type=SYSCALL msg=audit(1153138559.715:9): arch=40000003 syscall=5 success=no exit=-13 a0=48909fd4 a1=0 a2=804a000 a3=48909fda items= 1 pid=2374 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty" exe="/sbin/mingetty" s ubj=system_u:system_r:getty_t:s0 >>> type=CWD msg=audit(1153138559.715:9): cwd="/" >>> type=PATH msg=audit(1153138559.715:9): item=0 name="/var/run/utmp" inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj= system_u:object_r:init_var_run_t:s0 >>> type=AVC msg=audit(1153138559.715:10): avc: denied { read write } for pid=2374 comm="mingetty" name="utmp" dev=dm-1 ino=87750 sco ntext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file >>> type=SYSCALL msg=audit(1153138559.715:10): arch=40000003 syscall=5 success=no exit=-13 a0=48909fd4 a1=2 a2=0 a3=48909fda items=1 pid =2374 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty" exe="/sbin/mingetty" subj=s ystem_u:system_r:getty_t:s0 >>> type=CWD msg=audit(1153138559.715:10): cwd="/" >> Your /var/run/utmp appears to be labelled init_var_run_t rather than >> initrc_var_run_t. > > Yep: > > # ls -lZ /var/run/utmp > -rw-rw-r-- root utmp system_u:object_r:init_var_run_t /var/run/utmp > > # restorecon /var/run/utmp > > # ls -lZ /var/run/utmp > -rw-rw-r-- root utmp system_u:object_r:initrc_var_run_t /var/run/utmp Running restorecond should stop this happening again. Paul. From MSchwartz at mn.rr.com Wed Jul 19 00:37:56 2006 From: MSchwartz at mn.rr.com (Marc Schwartz) Date: Tue, 18 Jul 2006 19:37:56 -0500 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <44BCFB1A.8040909@city-fan.org> References: <44A15AC3.5090000@city-fan.org> <1151429665.4219.57.camel@localhost.localdomain> <1151503719.7470.12.camel@laurel.intra.city-fan.org> <1151522527.3438.52.camel@localhost.localdomain> <1151525638.7470.77.camel@laurel.intra.city-fan.org> <1151528181.3438.98.camel@localhost.localdomain> <1151529828.7470.92.camel@laurel.intra.city-fan.org> <1151530682.3438.108.camel@localhost.localdomain> <1151532794.7470.101.camel@laurel.intra.city-fan.org> <1151550925.6200.48.camel@localhost.localdomain> <1151566188.7470.111.camel@laurel.intra.city-fan.org> <1151587633.6200.56.camel@localhost.localdomain> <1151624293.6466.10.camel@localhost.localdomain> <44A524CE.1070205@city-fan.org> <44AA9CF1.6000601@city-fan.org> <1152125919.4843.141.camel@localhost.localdomain> <44B7D0DA.9090207@city-fan.org> <1153144713.4897.18.camel@localhost.localdomain> <44BCDE1C.8070409@city-fan.org> <1153234408.3796.12.camel@localhost.localdomain> <44BCFB1A.8040909@city-fan.org> Message-ID: <1153269476.6132.15.camel@localhost.localdomain> On Tue, 2006-07-18 at 16:15 +0100, Paul Howarth wrote: > Marc Schwartz (via MN) wrote: > > On Tue, 2006-07-18 at 14:11 +0100, Paul Howarth wrote: > > # Run restorecon to restore the SELinux context after re-building > > 10 01 * * * root /sbin/restorecon -rv /var/dcc > > 11 01 * * * root /sbin/restorecon -v /usr/local/bin/dccproc > > > > > >> I could add this to the dcc policy (or a separate local module for > >> restorecon): > >> cron_system_entry(restorecon_t) > >> > >> However, I think that the "right" way to fix this would be to use > >> restorecond and add an entry to /etc/selinux/restorecond.conf (the > >> manpage for restorecond suggests > >> /etc/selinux/POLICYTYPE/restorconfiles.conf but that file doesn't seem > >> to exist, and the restorecond binary includes the string > >> /etc/selinux/restorecond.conf). > >> > >> Maybe Dan could comment on that? > > Try this instead of your cron jobs and see what happens: > > # chkconfig --add restorecond > # chkconfig restorecond on > > Edit /etc/selinux/restorecond.conf and add a line: > > /usr/local/bin/dccproc All the above done. > (is the restorecon of /var/dcc actually needed?) Hopefully not. We did that as a temp fix b/c the context would change after each nightly build. > If you have network-mounted home directories, you may want to remove the > lines starting with "~" > > Then: > # service restorecond start Done. > >>> type=AVC msg=audit(1153053408.030:4599): avc: denied { execmod } for pid=6019 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" d ev=hdc7 ino=3116816 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file > >>> type=SYSCALL msg=audit(1153053408.030:4599): arch=40000003 syscall=125 success=no exit=-13 a0=5c8000 a1=78e000 a2=5 a3=bf84c100 item s=0 pid=6019 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2" exe="/lib/ld-2.4.so" sub j=user_u:system_r:prelink_t:s0 > >>> type=AVC_PATH msg=audit(1153053408.030:4599): path="/usr/lib/libGLcore.so.1.0.8762" > >>> type=AVC msg=audit(1153053408.034:4600): avc: denied { execmod } for pid=6022 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.876 2" dev=hdc7 ino=3117829 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file > >>> type=SYSCALL msg=audit(1153053408.034:4600): arch=40000003 syscall=125 success=no exit=-13 a0=a3e000 a1=1000 a2=5 a3=bfc98d40 items= 0 pid=6022 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2" exe="/lib/ld-2.4.so" subj= user_u:system_r:prelink_t:s0 > >>> type=AVC_PATH msg=audit(1153053408.034:4600): path="/usr/lib/tls/libnvidia-tls.so.1.0.8762" > >> Do you have nvidia video drivers installed using the nvidia installer > >> rather than an RPM package? If so, you should probably see: > >> http://www.city-fan.org/tips/ProprietaryVideoDriverWarning > > > > Yep. I have never had a problem with them (dating back to RH 8.0, all > > on Dell laptops) and this is the first time that I had noted any avc's > > related to them. > > > > I have a script that I ran when I first moved to FC5 to set the > > following: > > > > /usr/sbin/setsebool -P allow_execstack=1 > > /usr/sbin/setsebool -P allow_execmod=1 > > > > based upon documents that I had found elsewhere. > > That's somewhat overkill and I wouldn't want to do that. Curiously, that approach is still noted in a variety of places, including FedoraFaq.org: http://www.fedorafaq.org/#nvidia and others: http://www.mjmwired.net/resources/mjm-fedora-fc5.html#nvidia http://stanton-finley.net/fedora_core_5_installation_notes.html#nVidia Though I noted that it has been updated similar to your recommendation in other places now, including the nVidia forums: http://www.nvnews.net/vbulletin/showthread.php?t=68681 > Undo it with: > # setsebool -P allow_execstack 0 > # setsebool -P allow_execmod 0 > > Then fix the file contexts instead: > > # semanage fcontext -a -f -- -t textrel_shlib_t > '/usr/lib/libGL(core)?\.so(\.[^/]*)*' > # semanage fcontext -a -f -- -t textrel_shlib_t > '/usr/lib/libnvidia.*\.so(\.[^/]*)*' > # restorecon -v /usr/lib/libGL* /usr/lib/libnvidia* > > Please check that these files have context type textrel_shlib_t after > doing this. # ls -lZ /usr/lib/libGL* lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libGLcore.so.1 -> libGLcore.so.1.0.8762 -rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/libGLcore.so.1.0.8762 -rw-r--r-- root root root:object_r:lib_t /usr/lib/libGL.la lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libGL.so -> libGL.so.1 lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libGL.so.1 -> libGL.so.1.0.8762 -rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/libGL.so.1.0.8762 lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libGLU.so -> libGLU.so.1 lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libGLU.so.1 -> libGLU.so.1.3.060402 -rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/libGLU.so.1.3.060402 lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libGLw.so -> libGLw.so.1 lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libGLw.so.1 -> libGLw.so.1.0.0 -rwxr-xr-x root root system_u:object_r:lib_t /usr/lib/libGLw.so.1.0.0 # ls -lZ /usr/lib/libnvidia* lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libnvidia-cfg.so -> libnvidia-cfg.so.1 lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libnvidia-cfg.so.1 -> libnvidia-cfg.so.1.0.8762 -rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/libnvidia-cfg.so.1.0.8762 lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libnvidia-tls.so.1 -> libnvidia-tls.so.1.0.8762 -rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/libnvidia-tls.so.1.0.8762 > The upstream policy has file contexts set for this but I fear they're > falling foul of the file contexts ordering rules. > > >>> type=PATH msg=audit(1153138559.711:8): item=0 name="/var/run/utmp" inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj= system_u:object_r:init_var_run_t:s0 > >>> type=AVC msg=audit(1153138559.715:9): avc: denied { read } for pid=2374 comm="mingetty" name="utmp" dev=dm-1 ino=87750 scontext=s ystem_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file > >>> type=SYSCALL msg=audit(1153138559.715:9): arch=40000003 syscall=5 success=no exit=-13 a0=48909fd4 a1=0 a2=804a000 a3=48909fda items= 1 pid=2374 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty" exe="/sbin/mingetty" s ubj=system_u:system_r:getty_t:s0 > >>> type=CWD msg=audit(1153138559.715:9): cwd="/" > >>> type=PATH msg=audit(1153138559.715:9): item=0 name="/var/run/utmp" inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj= system_u:object_r:init_var_run_t:s0 > >>> type=AVC msg=audit(1153138559.715:10): avc: denied { read write } for pid=2374 comm="mingetty" name="utmp" dev=dm-1 ino=87750 sco ntext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file > >>> type=SYSCALL msg=audit(1153138559.715:10): arch=40000003 syscall=5 success=no exit=-13 a0=48909fd4 a1=2 a2=0 a3=48909fda items=1 pid =2374 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty" exe="/sbin/mingetty" subj=s ystem_u:system_r:getty_t:s0 > >>> type=CWD msg=audit(1153138559.715:10): cwd="/" > >> Your /var/run/utmp appears to be labelled init_var_run_t rather than > >> initrc_var_run_t. > > > > Yep: > > > > # ls -lZ /var/run/utmp > > -rw-rw-r-- root utmp system_u:object_r:init_var_run_t /var/run/utmp > > > > # restorecon /var/run/utmp > > > > # ls -lZ /var/run/utmp > > -rw-rw-r-- root utmp system_u:object_r:initrc_var_run_t /var/run/utmp > > Running restorecond should stop this happening again. > > Paul. OK. All done. So far, no more avc's, but I'll keep track overnight and through a couple of re-boots tomorrow. Thanks, Marc From paul at city-fan.org Wed Jul 19 11:05:50 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 19 Jul 2006 12:05:50 +0100 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <1153269476.6132.15.camel@localhost.localdomain> References: <1151503719.7470.12.camel@laurel.intra.city-fan.org> <1151522527.3438.52.camel@localhost.localdomain> <1151525638.7470.77.camel@laurel.intra.city-fan.org> <1151528181.3438.98.camel@localhost.localdomain> <1151529828.7470.92.camel@laurel.intra.city-fan.org> <1151530682.3438.108.camel@localhost.localdomain> <1151532794.7470.101.camel@laurel.intra.city-fan.org> <1151550925.6200.48.camel@localhost.localdomain> <1151566188.7470.111.camel@laurel.intra.city-fan.org> <1151587633.6200.56.camel@localhost.localdomain> <1151624293.6466.10.camel@localhost.localdomain> <44A524CE.1070205@city-fan.org> <44AA9CF1.6000601@city-fan.org> <1152125919.4843.141.camel@localhost.localdomain> <44B7D0DA.9090207@city-fan.org> <1153144713.4897.18.camel@localhost.localdomain> <44BCDE1C.8070409@city-fan.org> <1153234408.3796.12.camel@localhost.localdomain> <44BCFB1A.8040909@city-fan.org> <1153269476.6132.15.camel@localhost.localdomain> Message-ID: <44BE120E.3050100@city-fan.org> Marc Schwartz wrote: > On Tue, 2006-07-18 at 16:15 +0100, Paul Howarth wrote: >>>>> type=AVC msg=audit(1153053408.030:4599): avc: denied { execmod } for pid=6019 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" d ev=hdc7 ino=3116816 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file >>>>> type=SYSCALL msg=audit(1153053408.030:4599): arch=40000003 syscall=125 success=no exit=-13 a0=5c8000 a1=78e000 a2=5 a3=bf84c100 item s=0 pid=6019 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2" exe="/lib/ld-2.4.so" sub j=user_u:system_r:prelink_t:s0 >>>>> type=AVC_PATH msg=audit(1153053408.030:4599): path="/usr/lib/libGLcore.so.1.0.8762" >>>>> type=AVC msg=audit(1153053408.034:4600): avc: denied { execmod } for pid=6022 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.876 2" dev=hdc7 ino=3117829 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file >>>>> type=SYSCALL msg=audit(1153053408.034:4600): arch=40000003 syscall=125 success=no exit=-13 a0=a3e000 a1=1000 a2=5 a3=bfc98d40 items= 0 pid=6022 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2" exe="/lib/ld-2.4.so" subj= user_u:system_r:prelink_t:s0 >>>>> type=AVC_PATH msg=audit(1153053408.034:4600): path="/usr/lib/tls/libnvidia-tls.so.1.0.8762" >>>> Do you have nvidia video drivers installed using the nvidia installer >>>> rather than an RPM package? If so, you should probably see: >>>> http://www.city-fan.org/tips/ProprietaryVideoDriverWarning >>> Yep. I have never had a problem with them (dating back to RH 8.0, all >>> on Dell laptops) and this is the first time that I had noted any avc's >>> related to them. >>> >>> I have a script that I ran when I first moved to FC5 to set the >>> following: >>> >>> /usr/sbin/setsebool -P allow_execstack=1 >>> /usr/sbin/setsebool -P allow_execmod=1 >>> >>> based upon documents that I had found elsewhere. >> That's somewhat overkill and I wouldn't want to do that. > > Curiously, that approach is still noted in a variety of places, > including FedoraFaq.org: > > http://www.fedorafaq.org/#nvidia > > and others: > > http://www.mjmwired.net/resources/mjm-fedora-fc5.html#nvidia > http://stanton-finley.net/fedora_core_5_installation_notes.html#nVidia > > Though I noted that it has been updated similar to your recommendation > in other places now, including the nVidia forums: > > http://www.nvnews.net/vbulletin/showthread.php?t=68681 I did discuss this with Max at fedorafaq and I thought he was going to update it after he tried it himself. I believe there's a similar issue with ATI drivers but neither of us have these so we can't test things for ourselves. Unfortunately the advice on the nvidia forum suggests using just "chcon" to change the contexts, so the fix might not survive a relabel (I'm not sure if customizable types get changed during a relabel). Using semanage and restorecon should certainly be robust though. > >> Undo it with: >> # setsebool -P allow_execstack 0 >> # setsebool -P allow_execmod 0 >> >> Then fix the file contexts instead: >> >> # semanage fcontext -a -f -- -t textrel_shlib_t >> '/usr/lib/libGL(core)?\.so(\.[^/]*)*' >> # semanage fcontext -a -f -- -t textrel_shlib_t >> '/usr/lib/libnvidia.*\.so(\.[^/]*)*' >> # restorecon -v /usr/lib/libGL* /usr/lib/libnvidia* >> >> Please check that these files have context type textrel_shlib_t after >> doing this. > > > # ls -lZ /usr/lib/libGL* > lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libGLcore.so.1 -> libGLcore.so.1.0.8762 > -rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/libGLcore.so.1.0.8762 > -rw-r--r-- root root root:object_r:lib_t /usr/lib/libGL.la > lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libGL.so -> libGL.so.1 > lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libGL.so.1 -> libGL.so.1.0.8762 > -rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/libGL.so.1.0.8762 > lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libGLU.so -> libGLU.so.1 > lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libGLU.so.1 -> libGLU.so.1.3.060402 > -rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/libGLU.so.1.3.060402 > lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libGLw.so -> libGLw.so.1 > lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libGLw.so.1 -> libGLw.so.1.0.0 > -rwxr-xr-x root root system_u:object_r:lib_t /usr/lib/libGLw.so.1.0.0 > > > > # ls -lZ /usr/lib/libnvidia* > lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libnvidia-cfg.so -> libnvidia-cfg.so.1 > lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libnvidia-cfg.so.1 -> libnvidia-cfg.so.1.0.8762 > -rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/libnvidia-cfg.so.1.0.8762 > lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libnvidia-tls.so.1 -> libnvidia-tls.so.1.0.8762 > -rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/libnvidia-tls.so.1.0.8762 That looks OK then. > So far, no more avc's, but I'll keep track overnight and through a > couple of re-boots tomorrow. Looks like it'll be time to switch back to enforcing mode soon then. Paul. From dsugar at tresys.com Wed Jul 19 15:19:05 2006 From: dsugar at tresys.com (Dave Sugar) Date: Wed, 19 Jul 2006 11:19:05 -0400 Subject: New projects on SELinux open source server Message-ID: <1153322345.3250.16.camel@localhost.localdomain> Tresys is happy to announce that we have moved our SELinux IDE (SLIDE) and CDS Framework projects to their new home on the Tresys Open Source website (http://oss.tresys.com). Information about each of the projects is available from there along with the ability to anonymously checkout source directly from the subversion tree. From Valdis.Kletnieks at vt.edu Wed Jul 19 15:27:52 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 19 Jul 2006 11:27:52 -0400 Subject: selinux-policy-strict-2.3.3-3 - definition conflict Message-ID: <200607191527.k6JFRqaZ009182@turing-police.cc.vt.edu> Seen during an update to 2.3.3-3: /etc/selinux/strict/contexts/files/file_contexts: Multiple different specifications for /usr/bin/apt-get (system_u:object_r:rpm_exec_t:s0 and system_u:object_r:apt_exec_t:s0). /etc/selinux/strict/contexts/files/file_contexts: Multiple different specifications for /usr/bin/apt-shell (system_u:object_r:rpm_exec_t:s0 and system_u:object_r:apt_exec_t:s0). Not a biggie to me, I don't have apt-get installed. Probably will matter to somebody trying to actually use it though. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From wart at kobold.org Wed Jul 19 21:38:03 2006 From: wart at kobold.org (Michael Thomas) Date: Wed, 19 Jul 2006 14:38:03 -0700 Subject: package review? Message-ID: <44BEA63B.7030105@kobold.org> A few packages (game server daemons) that I maintain in Fedora Extras would benefit from having a selinux security policy available. But since I'm new to writing selinux policies, I was hoping that someone from f-s-l could take a peek at what I did and let me know if I've done things correctly and in the 'recommended' way. I've already tested the policy on FC5 to make sure that it works and produces no 'avc denied' messages: http://www.kobold.org/~wart/fedora/crossfire-1.9.1-2.src.rpm I wasn't sure exactly which networking rules I would need. Most of the ones there were generated by policygentool. I also couldn't figure out why some of the rules at the end of crossfire.te were necessary. Thanks in advance! --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From peter.pun at gmail.com Thu Jul 20 06:11:50 2006 From: peter.pun at gmail.com (Peter Pun) Date: Thu, 20 Jul 2006 02:11:50 -0400 Subject: writing a firefox policy Message-ID: <3e2c91580607192311m4b1d9834nae211170a2bfad44@mail.gmail.com> Hi I want to write a policy for firefox, as to me, it is almost an always-on always-running network daemon. I think there will always be another vulnerability leading to remote code execution. But how can a policy protect against that? Using policygentool, I created a policy for firefox-bin. It created a domain. And I labeled the starter script /usr/bin/firefox as "initrc_exec_t" . The ".mozilla" dir became the log dir. I also created a dir labeled "download_t" so I can save files there. I think I should take away "read" for "user_home_t" too. So I guess the new domain will prevent transition into bin_t, sbin_t and others. But I notice the generated te allows exec of all "lib_t" libraries. That is an awful lot of libraries with lots of functions and probably a lot of bugs. Should I be worried? If I follow the doctrine of whitelisting everything and least privilege, I ought to label and specifically permit only the libraries that are needed, right? I am starting on identifying and labelling, but I have a feeling that it will become a maintenance nightmare. Maybe I don't fully understand "remote code execution". To me, it just means being able to conjure up a shell and running some hacker magic to gain root. Maybe the exploit doesn't even require a shell, and can wiggle its way through the vast lib_t for its own end. :( Apart from minimal library usage, what other correct behaviours should I restrict firefox to? Peter From Valdis.Kletnieks at vt.edu Thu Jul 20 09:38:49 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 20 Jul 2006 05:38:49 -0400 Subject: writing a firefox policy In-Reply-To: Your message of "Thu, 20 Jul 2006 02:11:50 EDT." <3e2c91580607192311m4b1d9834nae211170a2bfad44@mail.gmail.com> References: <3e2c91580607192311m4b1d9834nae211170a2bfad44@mail.gmail.com> Message-ID: <200607200938.k6K9cnrH019280@turing-police.cc.vt.edu> On Thu, 20 Jul 2006 02:11:50 EDT, Peter Pun said: > Apart from minimal library usage, what other correct behaviours should > I restrict firefox to? If I remember correctly, there's already a 'mozilla' policy which should serve as a starting point. One *big* constraint you can put on it is to prevent looking at any files in /home except ~/.mozilla and ~/Downloads (or whatever you decide to call it) (Some finessing to allow reading of ~ so you can get to ~/.mozilla is a Good Idea :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From mattdm at mattdm.org Thu Jul 20 14:28:09 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 20 Jul 2006 10:28:09 -0400 Subject: writing a firefox policy In-Reply-To: <200607200938.k6K9cnrH019280@turing-police.cc.vt.edu> References: <3e2c91580607192311m4b1d9834nae211170a2bfad44@mail.gmail.com> <200607200938.k6K9cnrH019280@turing-police.cc.vt.edu> Message-ID: <20060720142809.GA21571@jadzia.bu.edu> On Thu, Jul 20, 2006 at 05:38:49AM -0400, Valdis.Kletnieks at vt.edu wrote: > serve as a starting point. One *big* constraint you can put on it is > to prevent looking at any files in /home except ~/.mozilla and ~/Downloads > (or whatever you decide to call it) (Some finessing to allow reading of > ~ so you can get to ~/.mozilla is a Good Idea :) If Firefox is restricted to downloading to only specific directories, the option to change the default download directory should be removed from the UI. I'm not sure that's desirable. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From selinux at gmail.com Thu Jul 20 14:29:43 2006 From: selinux at gmail.com (Tom London) Date: Thu, 20 Jul 2006 07:29:43 -0700 Subject: setroubleshoot: syntax error... Message-ID: <4c4ba1530607200729t3aaafd13p19106dd92fe67e36@mail.gmail.com> Running latest rawhide, targeted/enforcing. >From /var/log/setroubleshoot/setroubleshoot.log (No setroubleshoot package listed in bugzilla): 2006-07-20 07:16:34,740 [avc.ERROR] Unexpected exception invalid syntax (secure_mode_insmod.py, line 35) Traceback (most recent call last): File "/usr/lib/audit/setroubleshoot_dispatcher", line 96, in ? analyze_thread = Analyze() File "/usr/lib/audit/setroubleshoot_dispatcher", line 19, in __init__ self.plugins = LoadPlugins() File "/usr/lib/python2.4/site-packages/setroubleshoot/util.py", line 175, in LoadPlugins mod = imp.load_module(moduleName, *imp.find_module(pluginName, [plugin_dir])) File "/usr/share/setroubleshoot/plugins/secure_mode_insmod.py", line 35 fix_cmd = 'setsebool -P secure_mode_insmod=0'. ^ SyntaxError: invalid syntax 2006-07-20 07:16:34,992 [avc.ERROR] Traceback (most recent call last): File "/usr/lib/audit/setroubleshoot_dispatcher", line 96, in ? analyze_thread = Analyze() File "/usr/lib/audit/setroubleshoot_dispatcher", line 19, in __init__ self.plugins = LoadPlugins() File "/usr/lib/python2.4/site-packages/setroubleshoot/util.py", line 175, in LoadPlugins mod = imp.load_module(moduleName, *imp.find_module(pluginName, [plugin_dir])) File "/usr/share/setroubleshoot/plugins/secure_mode_insmod.py", line 35 fix_cmd = 'setsebool -P secure_mode_insmod=0'. ^ SyntaxError: invalid syntax Traceback (most recent call last): File "/usr/lib/audit/setroubleshoot_dispatcher", line 96, in ? analyze_thread = Analyze() File "/usr/lib/audit/setroubleshoot_dispatcher", line 19, in __init__ self.plugins = LoadPlugins() File "/usr/lib/python2.4/site-packages/setroubleshoot/util.py", line 175, in LoadPlugins mod = imp.load_module(moduleName, *imp.find_module(pluginName, [plugin_dir])) File "/usr/share/setroubleshoot/plugins/secure_mode_insmod.py", line 35 fix_cmd = 'setsebool -P secure_mode_insmod=0'. ^ SyntaxError: invalid syntax ------- -- Tom London From Valdis.Kletnieks at vt.edu Thu Jul 20 14:38:40 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 20 Jul 2006 10:38:40 -0400 Subject: writing a firefox policy In-Reply-To: Your message of "Thu, 20 Jul 2006 10:28:09 EDT." <20060720142809.GA21571@jadzia.bu.edu> References: <3e2c91580607192311m4b1d9834nae211170a2bfad44@mail.gmail.com> <200607200938.k6K9cnrH019280@turing-police.cc.vt.edu> <20060720142809.GA21571@jadzia.bu.edu> Message-ID: <200607201438.k6KEceuH007410@turing-police.cc.vt.edu> On Thu, 20 Jul 2006 10:28:09 EDT, Matthew Miller said: > On Thu, Jul 20, 2006 at 05:38:49AM -0400, Valdis.Kletnieks at vt.edu wrote: > > serve as a starting point. One *big* constraint you can put on it is > > to prevent looking at any files in /home except ~/.mozilla and ~/Downloads > > (or whatever you decide to call it) (Some finessing to allow reading of > > ~ so you can get to ~/.mozilla is a Good Idea :) > > If Firefox is restricted to downloading to only specific directories, the > option to change the default download directory should be removed from the > UI. I'm not sure that's desirable. You're *still* going to need that option, because Firefox may not be restricted in all environments, and the actual directory name may not be cast in stone (in particular, the policy has this: HOME_DIR/\.mozilla(/.*)? gen_context(system_u:object_r:ROLE_mozilla_home_t,s0) Any other directory labelled as ROLE_mozilla_home_t will work as well (and in fact, I have several such directories - a ~/Downloads where most small stuff goes, and another directory on another filesystem for downloading .iso and similar....) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Thu Jul 20 14:45:30 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 20 Jul 2006 16:45:30 +0200 (CEST) Subject: writing a firefox policy In-Reply-To: <20060720142809.GA21571@jadzia.bu.edu> References: <3e2c91580607192311m4b1d9834nae211170a2bfad44@mail.gmail.com> <200607200938.k6K9cnrH019280@turing-police.cc.vt.edu> <20060720142809.GA21571@jadzia.bu.edu> Message-ID: <41001.192.54.193.51.1153406730.squirrel@rousalka.dyndns.org> Le Jeu 20 juillet 2006 16:28, Matthew Miller a ?crit : > On Thu, Jul 20, 2006 at 05:38:49AM -0400, Valdis.Kletnieks at vt.edu wrote: >> serve as a starting point. One *big* constraint you can put on it is >> to prevent looking at any files in /home except ~/.mozilla and >> ~/Downloads >> (or whatever you decide to call it) (Some finessing to allow reading of >> ~ so you can get to ~/.mozilla is a Good Idea :) > > If Firefox is restricted to downloading to only specific directories, the > option to change the default download directory should be removed from the > UI. I'm not sure that's desirable. yay for i18n -- Nicolas Mailhot From selinux at gmail.com Thu Jul 20 15:09:44 2006 From: selinux at gmail.com (Tom London) Date: Thu, 20 Jul 2006 08:09:44 -0700 Subject: /etc/named.rfc1912.zones - etc_t? Message-ID: <4c4ba1530607200809g947630aob35490de1fb8a3e6@mail.gmail.com> Running latest rawhide, targeted/enforcing. restorecon seems to want to relabel '/etc/named.rfc1912.zones' as etc_t: restorecon reset /etc/named.rfc1912.zones context system_u:object_r:named_conf_t:s0->system_u:object_r:etc_t:s0 That right? tom -- Tom London From selinux at gmail.com Thu Jul 20 17:27:26 2006 From: selinux at gmail.com (Tom London) Date: Thu, 20 Jul 2006 10:27:26 -0700 Subject: setroubleshoot: syntax error... In-Reply-To: <4c4ba1530607200729t3aaafd13p19106dd92fe67e36@mail.gmail.com> References: <4c4ba1530607200729t3aaafd13p19106dd92fe67e36@mail.gmail.com> Message-ID: <4c4ba1530607201027j498c5e8cnaa5eb4ed7a650056@mail.gmail.com> Fixed spurrious '.' at end of line 35 in secure_mode_insmod.py. Now get: 2006-07-20 10:17:48,314 [plugin.DEBUG] importing /usr/share/setroubleshoot/plugins/secure_mode_policyload as plugins.secure_mode_policyload 2006-07-20 10:17:48,315 [avc.ERROR] Unexpected exception expected an indented block (secure_mode_policyload.py, line 45) Traceback (most recent call last): File "/usr/lib/audit/setroubleshoot_dispatcher", line 96, in ? analyze_thread = Analyze() File "/usr/lib/audit/setroubleshoot_dispatcher", line 19, in __init__ self.plugins = LoadPlugins() File "/usr/lib/python2.4/site-packages/setroubleshoot/util.py", line 175, in LoadPlugins mod = imp.load_module(moduleName, *imp.find_module(pluginName, [plugin_dir])) IndentationError: expected an indented block (secure_mode_policyload.py, line 45) 2006-07-20 10:17:48,702 [avc.ERROR] Traceback (most recent call last): File "/usr/lib/audit/setroubleshoot_dispatcher", line 96, in ? analyze_thread = Analyze() File "/usr/lib/audit/setroubleshoot_dispatcher", line 19, in __init__ self.plugins = LoadPlugins() File "/usr/lib/python2.4/site-packages/setroubleshoot/util.py", line 175, in LoadPlugins mod = imp.load_module(moduleName, *imp.find_module(pluginName, [plugin_dir])) IndentationError: expected an indented block (secure_mode_policyload.py, line 45) Traceback (most recent call last): File "/usr/lib/audit/setroubleshoot_dispatcher", line 96, in ? analyze_thread = Analyze() File "/usr/lib/audit/setroubleshoot_dispatcher", line 19, in __init__ self.plugins = LoadPlugins() File "/usr/lib/python2.4/site-packages/setroubleshoot/util.py", line 175, in LoadPlugins mod = imp.load_module(moduleName, *imp.find_module(pluginName, [plugin_dir])) IndentationError: expected an indented block (secure_mode_policyload.py, line 45) From dwalsh at redhat.com Thu Jul 20 17:31:11 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 20 Jul 2006 13:31:11 -0400 Subject: /etc/named.rfc1912.zones - etc_t? In-Reply-To: <4c4ba1530607200809g947630aob35490de1fb8a3e6@mail.gmail.com> References: <4c4ba1530607200809g947630aob35490de1fb8a3e6@mail.gmail.com> Message-ID: <44BFBDDF.3000509@redhat.com> Tom London wrote: > Running latest rawhide, targeted/enforcing. > > restorecon seems to want to relabel '/etc/named.rfc1912.zones' as etc_t: > restorecon reset /etc/named.rfc1912.zones context > system_u:object_r:named_conf_t:s0->system_u:object_r:etc_t:s0 > > That right? > > tom Not sure what those files are? Should all /etc/named.*be labeled named_conf_t? From dwalsh at redhat.com Thu Jul 20 17:36:18 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 20 Jul 2006 13:36:18 -0400 Subject: package review? In-Reply-To: <44BEA63B.7030105@kobold.org> References: <44BEA63B.7030105@kobold.org> Message-ID: <44BFBF12.5080608@redhat.com> Michael Thomas wrote: > A few packages (game server daemons) that I maintain in Fedora Extras > would benefit from having a selinux security policy available. But > since I'm new to writing selinux policies, I was hoping that someone > from f-s-l could take a peek at what I did and let me know if I've done > things correctly and in the 'recommended' way. > > I've already tested the policy on FC5 to make sure that it works and > produces no 'avc denied' messages: > > http://www.kobold.org/~wart/fedora/crossfire-1.9.1-2.src.rpm > > I wasn't sure exactly which networking rules I would need. Most of the > ones there were generated by policygentool. I also couldn't figure out > why some of the rules at the end of crossfire.te were necessary. > > Thanks in advance! > > --Mike > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Please attach the te, fc and if files. From wart at kobold.org Thu Jul 20 17:38:38 2006 From: wart at kobold.org (Michael Thomas) Date: Thu, 20 Jul 2006 10:38:38 -0700 Subject: package review? In-Reply-To: <44BFBF12.5080608@redhat.com> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> Message-ID: <44BFBF9E.1090503@kobold.org> Daniel J Walsh wrote: > Michael Thomas wrote: > >> A few packages (game server daemons) that I maintain in Fedora Extras >> would benefit from having a selinux security policy available. But >> since I'm new to writing selinux policies, I was hoping that someone >> from f-s-l could take a peek at what I did and let me know if I've done >> things correctly and in the 'recommended' way. >> >> I've already tested the policy on FC5 to make sure that it works and >> produces no 'avc denied' messages: >> >> http://www.kobold.org/~wart/fedora/crossfire-1.9.1-2.src.rpm >> >> I wasn't sure exactly which networking rules I would need. Most of the >> ones there were generated by policygentool. I also couldn't figure out >> why some of the rules at the end of crossfire.te were necessary. >> >> Thanks in advance! >> >> --Mike >> >> ------------------------------------------------------------------------ >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Please attach the te, fc and if files. They are in the src.rpm, but I realize that's not the easiest way to pass them around. Here are direct links: http://www.kobold.org/~wart/fedora/crossfire.fc http://www.kobold.org/~wart/fedora/crossfire.if http://www.kobold.org/~wart/fedora/crossfire.te --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From dwalsh at redhat.com Thu Jul 20 19:11:17 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 20 Jul 2006 15:11:17 -0400 Subject: package review? In-Reply-To: <44BFBF9E.1090503@kobold.org> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> Message-ID: <44BFD555.3080500@redhat.com> Michael Thomas wrote: > Daniel J Walsh wrote: > >> Michael Thomas wrote: >> >> >>> A few packages (game server daemons) that I maintain in Fedora Extras >>> would benefit from having a selinux security policy available. But >>> since I'm new to writing selinux policies, I was hoping that someone >>> from f-s-l could take a peek at what I did and let me know if I've done >>> things correctly and in the 'recommended' way. >>> >>> I've already tested the policy on FC5 to make sure that it works and >>> produces no 'avc denied' messages: >>> >>> http://www.kobold.org/~wart/fedora/crossfire-1.9.1-2.src.rpm >>> >>> I wasn't sure exactly which networking rules I would need. Most of the >>> ones there were generated by policygentool. I also couldn't figure out >>> why some of the rules at the end of crossfire.te were necessary. >>> >>> Thanks in advance! >>> >>> --Mike >>> >>> ------------------------------------------------------------------------ >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> >> Please attach the te, fc and if files. >> > > They are in the src.rpm, but I realize that's not the easiest way to > pass them around. Here are direct links: > > http://www.kobold.org/~wart/fedora/crossfire.fc > > http://www.kobold.org/~wart/fedora/crossfire.if > http://www.kobold.org/~wart/fedora/crossfire.te > > I would not define crossfire_static_data_t, unless this is data you do not want other confined domains from reading. You can just let it use usr_t and give the application the ability to read usr_t. files_read_usr_files(crossfire_t) I do not like adding additional file_contexts unless the domain needs to write. Up until now, I think you are better off leaving read only files with the default context. (This might change as we move to more RBAC support). allow crossfire_t port_t:udp_socket send_msg; allow crossfire_t port_t:tcp_socket name_bind; You need to define a port for this socket and only allow name_bind to that port allow crossfire_t bin_t:file getattr; allow crossfire_t bin_t:dir search; Should use corecmd_getattr_bin_files(crossfire_t) corecmd_search_bin(crossfire_t) allow crossfire_t proc_t:dir search; allow crossfire_t sysctl_t:dir search; allow crossfire_t sysctl_kernel_t:dir search; allow crossfire_t sysctl_kernel_t:file read; Should use kernel_read_kernel_sysctls(crossfire_t) allow crossfire_t devpts_t:chr_file {read write}; Probably want to dontaudit term_dontaudit_use_generic_ptys(crossfire_t) allow crossfire_t proc_t:file {getattr read}; Shoudl use kernel_read_system_state(crossfire_t) If you are generating these additional AVC rules using audit2allow. use -R to attempt to find the reference policy macros to use. macros are available in /usr/share/selinux/devel/include directory. > --Mike > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From wart at kobold.org Thu Jul 20 19:43:20 2006 From: wart at kobold.org (Michael Thomas) Date: Thu, 20 Jul 2006 12:43:20 -0700 Subject: package review? In-Reply-To: <44BFD555.3080500@redhat.com> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> Message-ID: <44BFDCD8.8040900@kobold.org> Daniel J Walsh wrote: > Michael Thomas wrote: >> They are in the src.rpm, but I realize that's not the easiest way to >> pass them around. Here are direct links: >> >> http://www.kobold.org/~wart/fedora/crossfire.fc >> http://www.kobold.org/~wart/fedora/crossfire.if >> http://www.kobold.org/~wart/fedora/crossfire.te >> >> > > I would not define crossfire_static_data_t, unless this is data you do > not want other confined domains from reading. You can just let it use > usr_t and give the application the ability to read usr_t. > files_read_usr_files(crossfire_t) > I do not like adding additional file_contexts unless the domain needs to > write. Up until now, I think you are better off leaving > read only files with the default context. (This might change as we > move to more RBAC support). But this would also give the application read access to all of usr_t. If I put on my paranoia hat, then I'd want to make sure the application has limited read access as well as write access. > allow crossfire_t port_t:udp_socket send_msg; > allow crossfire_t port_t:tcp_socket name_bind; > You need to define a port for this socket and only allow name_bind to > that port Ok. If the server admin changes the application's port (not likely), then they would need to update the policy as well, right? > allow crossfire_t bin_t:file getattr; > allow crossfire_t bin_t:dir search; > Should use corecmd_getattr_bin_files(crossfire_t) > corecmd_search_bin(crossfire_t) Ok. I still need to track down why the application is trying to search here. > allow crossfire_t proc_t:dir search; > allow crossfire_t sysctl_t:dir search; > allow crossfire_t sysctl_kernel_t:dir search; > allow crossfire_t sysctl_kernel_t:file read; > Should use > kernel_read_kernel_sysctls(crossfire_t) Ok. Does this mean I can remove the require { type sysctl_t; }; from the .te file? Or does the kernel_read_kernel_sysctls() not perform this require{}? > allow crossfire_t devpts_t:chr_file {read write}; > Probably want to dontaudit > term_dontaudit_use_generic_ptys(crossfire_t) This will disallow the action, but not generate the avc denied messages, right? > allow crossfire_t proc_t:file {getattr read}; > Shoudl use > kernel_read_system_state(crossfire_t) Ok. > If you are generating these additional AVC rules using audit2allow. use > -R to attempt to find the reference policy macros to use. Ah, I didn't know that one. Thanks for the help, --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From selinux at gmail.com Thu Jul 20 22:06:58 2006 From: selinux at gmail.com (Tom London) Date: Thu, 20 Jul 2006 15:06:58 -0700 Subject: /etc/named.rfc1912.zones - etc_t? In-Reply-To: <44BFBDDF.3000509@redhat.com> References: <4c4ba1530607200809g947630aob35490de1fb8a3e6@mail.gmail.com> <44BFBDDF.3000509@redhat.com> Message-ID: <4c4ba1530607201506l700f7454hc143c39c94fad13b@mail.gmail.com> On 7/20/06, Daniel J Walsh wrote: > Tom London wrote: > > Running latest rawhide, targeted/enforcing. > > > > restorecon seems to want to relabel '/etc/named.rfc1912.zones' as etc_t: > > restorecon reset /etc/named.rfc1912.zones context > > system_u:object_r:named_conf_t:s0->system_u:object_r:etc_t:s0 > > > > That right? > > > > tom > Not sure what those files are? Should all /etc/named.*be labeled > named_conf_t? > Not 100% sure myself, but I checked and 'rpm -qif' says it comes from bind-config. Any particular reason to change its label recently? tom -- Tom London From wart at kobold.org Fri Jul 21 00:27:04 2006 From: wart at kobold.org (Wart) Date: Thu, 20 Jul 2006 17:27:04 -0700 Subject: package review? In-Reply-To: <44BFD555.3080500@redhat.com> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> Message-ID: <44C01F58.5080109@kobold.org> Daniel J Walsh wrote: > allow crossfire_t port_t:udp_socket send_msg; > allow crossfire_t port_t:tcp_socket name_bind; > You need to define a port for this socket and only allow name_bind to > that port I know I'm missing something obvious here, but which macro can I use to add this restriction? I saw references to http_port_t and ntp_port_t in corenetwork.if, but didn't see anything that actually defined it to be port 80 (http) or port 123 (ntp). --Mike From phaceton at gmail.com Fri Jul 21 06:58:37 2006 From: phaceton at gmail.com (Peter Harmsen) Date: Fri, 21 Jul 2006 08:58:37 +0200 Subject: package review? In-Reply-To: <44C01F58.5080109@kobold.org> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> Message-ID: <3655f5d90607202358w5f99f3a6y489f6603f413eb1d@mail.gmail.com> Is there any change a firefox policy will be included as default? On 7/21/06, Wart wrote: > Daniel J Walsh wrote: > > allow crossfire_t port_t:udp_socket send_msg; > > allow crossfire_t port_t:tcp_socket name_bind; > > You need to define a port for this socket and only allow name_bind to > > that port > > I know I'm missing something obvious here, but which macro can I use to > add this restriction? I saw references to http_port_t and ntp_port_t in > corenetwork.if, but didn't see anything that actually defined it to be > port 80 (http) or port 123 (ntp). > > --Mike > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- I have made this letter longer than usual, because i lack the time to make it short. From Valdis.Kletnieks at vt.edu Fri Jul 21 12:33:35 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 21 Jul 2006 08:33:35 -0400 Subject: package review? In-Reply-To: Your message of "Fri, 21 Jul 2006 08:58:37 +0200." <3655f5d90607202358w5f99f3a6y489f6603f413eb1d@mail.gmail.com> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> <3655f5d90607202358w5f99f3a6y489f6603f413eb1d@mail.gmail.com> Message-ID: <200607211233.k6LCXaQQ027387@turing-police.cc.vt.edu> On Fri, 21 Jul 2006 08:58:37 +0200, Peter Harmsen said: > Is there any change a firefox policy will be included > as default? serefpolicy-2.3.3/policy/modules/apps % grep firefox mozilla.* mozilla.fc:/usr/lib(64)?/firefox[^/]*/mozilla-.* -- gen_context(system_u:object_r:mozilla_exec_t,s0) mozilla.fc:/usr/lib(64)?/[^/]*firefox[^/]*/firefox-bin -- gen_context(system_u:object_r:mozilla_exec_t,s0) The already present mozilla pilicy seems to already cover it? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From paul at city-fan.org Fri Jul 21 13:04:11 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 21 Jul 2006 14:04:11 +0100 Subject: package review? In-Reply-To: <200607211233.k6LCXaQQ027387@turing-police.cc.vt.edu> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> <3655f5d90607202358w5f99f3a6y489f6603f413eb1d@mail.gmail.com> <200607211233.k6LCXaQQ027387@turing-police.cc.vt.edu> Message-ID: <44C0D0CB.2010904@city-fan.org> Valdis.Kletnieks at vt.edu wrote: > On Fri, 21 Jul 2006 08:58:37 +0200, Peter Harmsen said: >> Is there any change a firefox policy will be included >> as default? > > serefpolicy-2.3.3/policy/modules/apps % grep firefox mozilla.* > mozilla.fc:/usr/lib(64)?/firefox[^/]*/mozilla-.* -- gen_context(system_u:object_r:mozilla_exec_t,s0) > mozilla.fc:/usr/lib(64)?/[^/]*firefox[^/]*/firefox-bin -- gen_context(system_u:object_r:mozilla_exec_t,s0) > > The already present mozilla pilicy seems to already cover it? It doesn't appear to be enabled in the targeted policy though: # semanage fcontext -l | grep mozilla /usr/lib(64)?/mozilla.*\.so regular file system_u:object_r:textrel_shlib_t:s0 /usr/lib(64)?/[^/]*/run-mozilla\.sh regular file system_u:object_r:bin_t:s0 /usr/lib(64)?/[^/]*/mozilla-xremote-client regular file system_u:object_r:bin_t:s0 /usr/lib(64)?/thunderbird.*/mozilla-xremote-client regular file system_u:object_r:bin_t:s0 No mention of mozilla_exec_t Paul. From phaceton at gmail.com Fri Jul 21 13:12:28 2006 From: phaceton at gmail.com (Peter Harmsen) Date: Fri, 21 Jul 2006 15:12:28 +0200 Subject: package review? In-Reply-To: <44C0D0CB.2010904@city-fan.org> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> <3655f5d90607202358w5f99f3a6y489f6603f413eb1d@mail.gmail.com> <200607211233.k6LCXaQQ027387@turing-police.cc.vt.edu> <44C0D0CB.2010904@city-fan.org> Message-ID: <3655f5d90607210612v24ab1563ue7a583467b3051a4@mail.gmail.com> The firefox browser is an ideal attack vector . Could prevent a lot of mischief i think. On 7/21/06, Paul Howarth wrote: > Valdis.Kletnieks at vt.edu wrote: > > On Fri, 21 Jul 2006 08:58:37 +0200, Peter Harmsen said: > >> Is there any change a firefox policy will be included > >> as default? > > > > serefpolicy-2.3.3/policy/modules/apps % grep firefox mozilla.* > > mozilla.fc:/usr/lib(64)?/firefox[^/]*/mozilla-.* -- gen_context(system_u:object_r:mozilla_exec_t,s0) > > mozilla.fc:/usr/lib(64)?/[^/]*firefox[^/]*/firefox-bin -- gen_context(system_u:object_r:mozilla_exec_t,s0) > > > > The already present mozilla pilicy seems to already cover it? > > It doesn't appear to be enabled in the targeted policy though: > > # semanage fcontext -l | grep mozilla > /usr/lib(64)?/mozilla.*\.so regular file > system_u:object_r:textrel_shlib_t:s0 > /usr/lib(64)?/[^/]*/run-mozilla\.sh regular file > system_u:object_r:bin_t:s0 > /usr/lib(64)?/[^/]*/mozilla-xremote-client regular file > system_u:object_r:bin_t:s0 > /usr/lib(64)?/thunderbird.*/mozilla-xremote-client regular file > system_u:object_r:bin_t:s0 > > No mention of mozilla_exec_t > > Paul. > -- I have made this letter longer than usual, because i lack the time to make it short. From Valdis.Kletnieks at vt.edu Fri Jul 21 14:23:10 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 21 Jul 2006 10:23:10 -0400 Subject: package review? In-Reply-To: Your message of "Fri, 21 Jul 2006 14:04:11 BST." <44C0D0CB.2010904@city-fan.org> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> <3655f5d90607202358w5f99f3a6y489f6603f413eb1d@mail.gmail.com> <200607211233.k6LCXaQQ027387@turing-police.cc.vt.edu> <44C0D0CB.2010904@city-fan.org> Message-ID: <200607211423.k6LENAnZ004727@turing-police.cc.vt.edu> On Fri, 21 Jul 2006 14:04:11 BST, Paul Howarth said: > Valdis.Kletnieks at vt.edu wrote: > > > The already present mozilla pilicy seems to already cover it? > > It doesn't appear to be enabled in the targeted policy though: "D'Oh!" -- H. Simpson. I was looking at the strict policy.. I agree that mozilla/firefox/thunderbird/evolution should probably be included as "outward facing software" for targeted though. Unfortunately, I don't know the best way to integrate that while not basically ending up with 'strict' again. Certainly we're too late in the FC6 process for it. I think that would be a good FC7 target though, and make a good marketing bullet item: "Now with enhanced security for Internet tools" or some such. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From dwalsh at redhat.com Fri Jul 21 15:10:21 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 21 Jul 2006 11:10:21 -0400 Subject: package review? In-Reply-To: <3655f5d90607202358w5f99f3a6y489f6603f413eb1d@mail.gmail.com> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> <3655f5d90607202358w5f99f3a6y489f6603f413eb1d@mail.gmail.com> Message-ID: <44C0EE5D.4000009@redhat.com> Peter Harmsen wrote: > Is there any change a firefox policy will be included > as default? > I am thinking of adding a boolean for people who want to use firefox/thunderbird/evolution policy. So by default we would have disable trans. And force a relabel or use restorecond for labeling users homedirs. for .mozilla and .thunderbird directories. The problem with these policies is that these applications are Huge and are difficult to lock down in any meaning full way. For example: We could lock down Firefox to only be able to read pages. And perhaps only down load files to a particular directory. Which directory? What happens if the user changes the directory? Now what happens when they down load a .doc or .ppt file? Do you want me to lauch OpenOffice? If yes what context should OpenOffice run under? Should I treat the data as Untrusted? How does the user change it to trusted? How about if they download an RPM package? What about additional plugins. All these issues exist in Mailers also. > On 7/21/06, Wart wrote: >> Daniel J Walsh wrote: >> > allow crossfire_t port_t:udp_socket send_msg; >> > allow crossfire_t port_t:tcp_socket name_bind; >> > You need to define a port for this socket and only allow name_bind to >> > that port >> >> I know I'm missing something obvious here, but which macro can I use to >> add this restriction? I saw references to http_port_t and ntp_port_t in >> corenetwork.if, but didn't see anything that actually defined it to be >> port 80 (http) or port 123 (ntp). >> >> --Mike >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > > From tibbs at math.uh.edu Fri Jul 21 15:13:00 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 21 Jul 2006 10:13:00 -0500 Subject: package review? In-Reply-To: <200607211423.k6LENAnZ004727@turing-police.cc.vt.edu> (Valdis Kletnieks's message of "Fri, 21 Jul 2006 10:23:10 -0400") References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> <3655f5d90607202358w5f99f3a6y489f6603f413eb1d@mail.gmail.com> <200607211233.k6LCXaQQ027387@turing-police.cc.vt.edu> <44C0D0CB.2010904@city-fan.org> <200607211423.k6LENAnZ004727@turing-police.cc.vt.edu> Message-ID: >>>>> "VK" == Valdis Kletnieks writes: VK> I think that would be a good FC7 target though, and make a good VK> marketing bullet item: "Now with enhanced security for Internet VK> tools" or some such. Certainly someone could come up with a package that adds the additional policy at any time. I don't see any reason why something like that couldn't be added to extras so interested folks could easily test it out and work through all of the issues that crop up. Eventually after enough testing it could be considered for addition to the main policy during the FC7 cycle. - J< From dwalsh at redhat.com Fri Jul 21 15:14:42 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 21 Jul 2006 11:14:42 -0400 Subject: package review? In-Reply-To: <44BFDCD8.8040900@kobold.org> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44BFDCD8.8040900@kobold.org> Message-ID: <44C0EF62.40803@redhat.com> Michael Thomas wrote: > Daniel J Walsh wrote: > >> Michael Thomas wrote: >> >>> They are in the src.rpm, but I realize that's not the easiest way to >>> pass them around. Here are direct links: >>> >>> http://www.kobold.org/~wart/fedora/crossfire.fc >>> http://www.kobold.org/~wart/fedora/crossfire.if >>> http://www.kobold.org/~wart/fedora/crossfire.te >>> >>> >>> >> I would not define crossfire_static_data_t, unless this is data you do >> not want other confined domains from reading. You can just let it use >> usr_t and give the application the ability to read usr_t. >> files_read_usr_files(crossfire_t) >> > > > >> I do not like adding additional file_contexts unless the domain needs to >> write. Up until now, I think you are better off leaving >> read only files with the default context. (This might change as we >> move to more RBAC support). >> > > But this would also give the application read access to all of usr_t. > If I put on my paranoia hat, then I'd want to make sure the application > has limited read access as well as write access. > > That is fine, but most likely there is nothing secret in /usr that has a usr_t context, so you are adding complexity for little gain in security. >> allow crossfire_t port_t:udp_socket send_msg; >> allow crossfire_t port_t:tcp_socket name_bind; >> You need to define a port for this socket and only allow name_bind to >> that port >> > > Ok. If the server admin changes the application's port (not likely), > then they would need to update the policy as well, right? > > Users can modify ports using "semanage port" so that is not a problem. >> allow crossfire_t bin_t:file getattr; >> allow crossfire_t bin_t:dir search; >> Should use corecmd_getattr_bin_files(crossfire_t) >> corecmd_search_bin(crossfire_t) >> > > Ok. I still need to track down why the application is trying to search > here. > It is probably looking for itself? > >> allow crossfire_t proc_t:dir search; >> allow crossfire_t sysctl_t:dir search; >> allow crossfire_t sysctl_kernel_t:dir search; >> allow crossfire_t sysctl_kernel_t:file read; >> Should use >> kernel_read_kernel_sysctls(crossfire_t) >> > > Ok. Does this mean I can remove the require { type sysctl_t; }; from > the .te file? Or does the kernel_read_kernel_sysctls() not perform this > require{}? > > Yes the macros have all the appropriate requires in them. >> allow crossfire_t devpts_t:chr_file {read write}; >> Probably want to dontaudit >> term_dontaudit_use_generic_ptys(crossfire_t) >> > > This will disallow the action, but not generate the avc denied messages, > right? > > Yes >> allow crossfire_t proc_t:file {getattr read}; >> Shoudl use >> kernel_read_system_state(crossfire_t) >> > > Ok. > > >> If you are generating these additional AVC rules using audit2allow. use >> -R to attempt to find the reference policy macros to use. >> > > Ah, I didn't know that one. > > Thanks for the help, > > --Mike > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Fri Jul 21 15:21:36 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 21 Jul 2006 11:21:36 -0400 Subject: /etc/named.rfc1912.zones - etc_t? In-Reply-To: <4c4ba1530607201506l700f7454hc143c39c94fad13b@mail.gmail.com> References: <4c4ba1530607200809g947630aob35490de1fb8a3e6@mail.gmail.com> <44BFBDDF.3000509@redhat.com> <4c4ba1530607201506l700f7454hc143c39c94fad13b@mail.gmail.com> Message-ID: <44C0F100.2070704@redhat.com> Tom London wrote: > On 7/20/06, Daniel J Walsh wrote: >> Tom London wrote: >> > Running latest rawhide, targeted/enforcing. >> > >> > restorecon seems to want to relabel '/etc/named.rfc1912.zones' as >> etc_t: >> > restorecon reset /etc/named.rfc1912.zones context >> > system_u:object_r:named_conf_t:s0->system_u:object_r:etc_t:s0 >> > >> > That right? >> > >> > tom >> Not sure what those files are? Should all /etc/named.*be labeled >> named_conf_t? >> > Not 100% sure myself, but I checked and 'rpm -qif' says it comes from > bind-config. > > Any particular reason to change its label recently? > Nope. We did not change the labeling. But I will fix tonights update. > tom From paul at city-fan.org Fri Jul 21 15:23:59 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 21 Jul 2006 16:23:59 +0100 Subject: package review? In-Reply-To: <44C01F58.5080109@kobold.org> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> Message-ID: <44C0F18F.5030108@city-fan.org> Wart wrote: > Daniel J Walsh wrote: >> allow crossfire_t port_t:udp_socket send_msg; >> allow crossfire_t port_t:tcp_socket name_bind; >> You need to define a port for this socket and only allow name_bind to >> that port > > I know I'm missing something obvious here, but which macro can I use to > add this restriction? I saw references to http_port_t and ntp_port_t in > corenetwork.if, but didn't see anything that actually defined it to be > port 80 (http) or port 123 (ntp). policy/modules/kernel/corenetwork.te.in: ... network_port(ntp, udp,123,s0) ... network_port(http, tcp,80,s0, tcp,443,s0, tcp,488,s0, tcp,8008,s0, tcp,8009,s0) --- Paul. From paul at city-fan.org Fri Jul 21 15:46:28 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 21 Jul 2006 16:46:28 +0100 Subject: package review? In-Reply-To: <44BEA63B.7030105@kobold.org> References: <44BEA63B.7030105@kobold.org> Message-ID: <44C0F6D4.2060303@city-fan.org> Michael Thomas wrote: > A few packages (game server daemons) that I maintain in Fedora Extras > would benefit from having a selinux security policy available. But > since I'm new to writing selinux policies, I was hoping that someone > from f-s-l could take a peek at what I did and let me know if I've done > things correctly and in the 'recommended' way. > > I've already tested the policy on FC5 to make sure that it works and > produces no 'avc denied' messages: > > http://www.kobold.org/~wart/fedora/crossfire-1.9.1-2.src.rpm > > I wasn't sure exactly which networking rules I would need. Most of the > ones there were generated by policygentool. I also couldn't figure out > why some of the rules at the end of crossfire.te were necessary. I don't see any domain transition to crossfire_t in your policy; how does it get into that domain? Your policy file includes a comment about wanting to patch out use of temp files; another option would be to use your own domain for temp files, as you've done for the log files. Did you follow the guide on Packaging/SELinux on the wiki for actually building the module in your package? I've changed what I do for package building since I last updated that page (and I can't update it any more) and you'll find it won't build on rawhide as there is an selinux-policy-devel package you need as a buildreq there. An example of the way I'm currently doing SELinux module packaging can be found here: http://www.city-fan.org/~paul/extras/mod_fcgid/mod_fcgid.spec Paul. From jacliburn at bellsouth.net Fri Jul 21 15:54:42 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Fri, 21 Jul 2006 10:54:42 -0500 Subject: setroubleshoot: syntax error... In-Reply-To: <4c4ba1530607201027j498c5e8cnaa5eb4ed7a650056@mail.gmail.com> References: <4c4ba1530607200729t3aaafd13p19106dd92fe67e36@mail.gmail.com> <4c4ba1530607201027j498c5e8cnaa5eb4ed7a650056@mail.gmail.com> Message-ID: <44C0F8C2.2070301@bellsouth.net> Tom London wrote: > Fixed spurrious '.' at end of line 35 in secure_mode_insmod.py. > > Now get: > > 2006-07-20 10:17:48,314 [plugin.DEBUG] importing > /usr/share/setroubleshoot/plugins/secure_mode_policyload as > plugins.secure_mode_policyload > 2006-07-20 10:17:48,315 [avc.ERROR] Unexpected exception expected an > indented block (secure_mode_policyload.py, line 45) > Traceback (most recent call last): > File "/usr/lib/audit/setroubleshoot_dispatcher", line 96, in ? > analyze_thread = Analyze() > File "/usr/lib/audit/setroubleshoot_dispatcher", line 19, in __init__ > self.plugins = LoadPlugins() > File "/usr/lib/python2.4/site-packages/setroubleshoot/util.py", line > 175, in LoadPlugins > mod = imp.load_module(moduleName, *imp.find_module(pluginName, > [plugin_dir])) > IndentationError: expected an indented block > (secure_mode_policyload.py, line 45) > 2006-07-20 10:17:48,702 [avc.ERROR] Traceback (most recent call last): > File "/usr/lib/audit/setroubleshoot_dispatcher", line 96, in ? > analyze_thread = Analyze() > File "/usr/lib/audit/setroubleshoot_dispatcher", line 19, in __init__ > self.plugins = LoadPlugins() > File "/usr/lib/python2.4/site-packages/setroubleshoot/util.py", line > 175, in LoadPlugins > mod = imp.load_module(moduleName, *imp.find_module(pluginName, > [plugin_dir])) > IndentationError: expected an indented block > (secure_mode_policyload.py, line 45) > Traceback (most recent call last): > File "/usr/lib/audit/setroubleshoot_dispatcher", line 96, in ? > analyze_thread = Analyze() > File "/usr/lib/audit/setroubleshoot_dispatcher", line 19, in __init__ > self.plugins = LoadPlugins() > File "/usr/lib/python2.4/site-packages/setroubleshoot/util.py", line > 175, in LoadPlugins > mod = imp.load_module(moduleName, *imp.find_module(pluginName, > [plugin_dir])) > IndentationError: expected an indented block > (secure_mode_policyload.py, line 45) > I get a different error in setroubleshoot-0.9-1. Where should these be reported? [root at osprey setroubleshoot-0.9]# setroubleshoot /var/log/messages Traceback (most recent call last): File "/usr/sbin/setroubleshoot", line 74, in ? if plugin.analyze(avc): File "/usr/share/setroubleshoot/plugins/allow_java_execstack.py", line 52, in analyze if re.match("javaplugin_t$", avc.scontext.type) is not None \ File "/usr/lib64/python2.4/sre.py", line 129, in match return _compile(pattern, flags).match(string) TypeError: expected string or buffer Also, there appears to be a format bug in the Usage message: [root at osprey setroubleshoot-0.9]# setroubleshoot --help sys.argv[0] file [file ...] -h --help -p glob --plugin=glob load only plugin's whose name matches glob From selinux at gmail.com Fri Jul 21 16:23:51 2006 From: selinux at gmail.com (Tom London) Date: Fri, 21 Jul 2006 09:23:51 -0700 Subject: setroubleshoot: syntax error... In-Reply-To: <44C0F8C2.2070301@bellsouth.net> References: <4c4ba1530607200729t3aaafd13p19106dd92fe67e36@mail.gmail.com> <4c4ba1530607201027j498c5e8cnaa5eb4ed7a650056@mail.gmail.com> <44C0F8C2.2070301@bellsouth.net> Message-ID: <4c4ba1530607210923m74ff98e4u6a397d4ee2c840d7@mail.gmail.com> On 7/21/06, Jay Cliburn wrote: > Tom London wrote: > > Fixed spurrious '.' at end of line 35 in secure_mode_insmod.py. > > > > Now get: > > > > 2006-07-20 10:17:48,314 [plugin.DEBUG] importing > > /usr/share/setroubleshoot/plugins/secure_mode_policyload as > > plugins.secure_mode_policyload > > 2006-07-20 10:17:48,315 [avc.ERROR] Unexpected exception expected an > > indented block (secure_mode_policyload.py, line 45) > > Traceback (most recent call last): > > File "/usr/lib/audit/setroubleshoot_dispatcher", line 96, in ? > > analyze_thread = Analyze() > > File "/usr/lib/audit/setroubleshoot_dispatcher", line 19, in __init__ > > self.plugins = LoadPlugins() > > File "/usr/lib/python2.4/site-packages/setroubleshoot/util.py", line > > 175, in LoadPlugins > > mod = imp.load_module(moduleName, *imp.find_module(pluginName, > > [plugin_dir])) > > IndentationError: expected an indented block > > (secure_mode_policyload.py, line 45) > > 2006-07-20 10:17:48,702 [avc.ERROR] Traceback (most recent call last): > > File "/usr/lib/audit/setroubleshoot_dispatcher", line 96, in ? > > analyze_thread = Analyze() > > File "/usr/lib/audit/setroubleshoot_dispatcher", line 19, in __init__ > > self.plugins = LoadPlugins() > > File "/usr/lib/python2.4/site-packages/setroubleshoot/util.py", line > > 175, in LoadPlugins > > mod = imp.load_module(moduleName, *imp.find_module(pluginName, > > [plugin_dir])) > > IndentationError: expected an indented block > > (secure_mode_policyload.py, line 45) > > Traceback (most recent call last): > > File "/usr/lib/audit/setroubleshoot_dispatcher", line 96, in ? > > analyze_thread = Analyze() > > File "/usr/lib/audit/setroubleshoot_dispatcher", line 19, in __init__ > > self.plugins = LoadPlugins() > > File "/usr/lib/python2.4/site-packages/setroubleshoot/util.py", line > > 175, in LoadPlugins > > mod = imp.load_module(moduleName, *imp.find_module(pluginName, > > [plugin_dir])) > > IndentationError: expected an indented block > > (secure_mode_policyload.py, line 45) > > > > I get a different error in setroubleshoot-0.9-1. Where should these be > reported? > > [root at osprey setroubleshoot-0.9]# setroubleshoot /var/log/messages > Traceback (most recent call last): > File "/usr/sbin/setroubleshoot", line 74, in ? > if plugin.analyze(avc): > File "/usr/share/setroubleshoot/plugins/allow_java_execstack.py", > line 52, in analyze > if re.match("javaplugin_t$", avc.scontext.type) is not None \ > File "/usr/lib64/python2.4/sre.py", line 129, in match > return _compile(pattern, flags).match(string) > TypeError: expected string or buffer > > > > Also, there appears to be a format bug in the Usage message: > > [root at osprey setroubleshoot-0.9]# setroubleshoot --help > > sys.argv[0] file [file ...] > -h --help > -p glob --plugin=glob load only plugin's whose name matches glob > Here's a new one, also with 0.9-1: 2006-07-21 09:20:14,722 [avc.DEBUG] snap read: 'audit(1153498814.721:15): user pid=2792 uid=0 auid=500 subj=system_u:system_r:xdm_t:s0-s0:c0.c255 msg='uid=500: exe="/usr/sbin/gdm-binary" (hostname=localhost.localdomain, addr=2.0.0.0, terminal=:0 res=success)'' 2006-07-21 09:20:14,723 [avc.ERROR] Unexpected exception too many values to unpack Traceback (most recent call last): File "/usr/lib/audit/setroubleshoot_dispatcher", line 100, in ? snap.run() File "/usr/lib/audit/setroubleshoot_dispatcher", line 83, in run self.process(msg.get_msg_type(), msg.get_body()) File "/usr/lib/audit/setroubleshoot_dispatcher", line 66, in process var, val = i.split("=") ValueError: too many values to unpack 2006-07-21 09:20:14,726 [avc.ERROR] Traceback (most recent call last): File "/usr/lib/audit/setroubleshoot_dispatcher", line 100, in ? snap.run() File "/usr/lib/audit/setroubleshoot_dispatcher", line 83, in run self.process(msg.get_msg_type(), msg.get_body()) File "/usr/lib/audit/setroubleshoot_dispatcher", line 66, in process var, val = i.split("=") ValueError: too many values to unpack Traceback (most recent call last): File "/usr/lib/audit/setroubleshoot_dispatcher", line 100, in ? snap.run() File "/usr/lib/audit/setroubleshoot_dispatcher", line 83, in run self.process(msg.get_msg_type(), msg.get_body()) File "/usr/lib/audit/setroubleshoot_dispatcher", line 66, in process var, val = i.split("=") ValueError: too many values to unpack -- Tom London From dwalsh at redhat.com Fri Jul 21 16:32:21 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 21 Jul 2006 12:32:21 -0400 Subject: setroubleshoot: syntax error... In-Reply-To: <4c4ba1530607210923m74ff98e4u6a397d4ee2c840d7@mail.gmail.com> References: <4c4ba1530607200729t3aaafd13p19106dd92fe67e36@mail.gmail.com> <4c4ba1530607201027j498c5e8cnaa5eb4ed7a650056@mail.gmail.com> <44C0F8C2.2070301@bellsouth.net> <4c4ba1530607210923m74ff98e4u6a397d4ee2c840d7@mail.gmail.com> Message-ID: <44C10195.1060608@redhat.com> Tom London wrote: > On 7/21/06, Jay Cliburn wrote: >> Tom London wrote: >> > Fixed spurrious '.' at end of line 35 in secure_mode_insmod.py. >> > >> > Now get: >> > >> > 2006-07-20 10:17:48,314 [plugin.DEBUG] importing >> > /usr/share/setroubleshoot/plugins/secure_mode_policyload as >> > plugins.secure_mode_policyload >> > 2006-07-20 10:17:48,315 [avc.ERROR] Unexpected exception expected an >> > indented block (secure_mode_policyload.py, line 45) >> > Traceback (most recent call last): >> > File "/usr/lib/audit/setroubleshoot_dispatcher", line 96, in ? >> > analyze_thread = Analyze() >> > File "/usr/lib/audit/setroubleshoot_dispatcher", line 19, in __init__ >> > self.plugins = LoadPlugins() >> > File "/usr/lib/python2.4/site-packages/setroubleshoot/util.py", line >> > 175, in LoadPlugins >> > mod = imp.load_module(moduleName, *imp.find_module(pluginName, >> > [plugin_dir])) >> > IndentationError: expected an indented block >> > (secure_mode_policyload.py, line 45) >> > 2006-07-20 10:17:48,702 [avc.ERROR] Traceback (most recent call last): >> > File "/usr/lib/audit/setroubleshoot_dispatcher", line 96, in ? >> > analyze_thread = Analyze() >> > File "/usr/lib/audit/setroubleshoot_dispatcher", line 19, in __init__ >> > self.plugins = LoadPlugins() >> > File "/usr/lib/python2.4/site-packages/setroubleshoot/util.py", line >> > 175, in LoadPlugins >> > mod = imp.load_module(moduleName, *imp.find_module(pluginName, >> > [plugin_dir])) >> > IndentationError: expected an indented block >> > (secure_mode_policyload.py, line 45) >> > Traceback (most recent call last): >> > File "/usr/lib/audit/setroubleshoot_dispatcher", line 96, in ? >> > analyze_thread = Analyze() >> > File "/usr/lib/audit/setroubleshoot_dispatcher", line 19, in __init__ >> > self.plugins = LoadPlugins() >> > File "/usr/lib/python2.4/site-packages/setroubleshoot/util.py", line >> > 175, in LoadPlugins >> > mod = imp.load_module(moduleName, *imp.find_module(pluginName, >> > [plugin_dir])) >> > IndentationError: expected an indented block >> > (secure_mode_policyload.py, line 45) >> > >> >> I get a different error in setroubleshoot-0.9-1. Where should these be >> reported? >> >> [root at osprey setroubleshoot-0.9]# setroubleshoot /var/log/messages >> Traceback (most recent call last): >> File "/usr/sbin/setroubleshoot", line 74, in ? >> if plugin.analyze(avc): >> File "/usr/share/setroubleshoot/plugins/allow_java_execstack.py", >> line 52, in analyze >> if re.match("javaplugin_t$", avc.scontext.type) is not None \ >> File "/usr/lib64/python2.4/sre.py", line 129, in match >> return _compile(pattern, flags).match(string) >> TypeError: expected string or buffer >> >> >> >> Also, there appears to be a format bug in the Usage message: >> >> [root at osprey setroubleshoot-0.9]# setroubleshoot --help >> >> sys.argv[0] file [file ...] >> -h --help >> -p glob --plugin=glob load only plugin's whose name >> matches glob >> > Here's a new one, also with 0.9-1: > > 2006-07-21 09:20:14,722 [avc.DEBUG] snap read: > 'audit(1153498814.721:15): user pid=2792 uid=0 auid=500 > subj=system_u:system_r:xdm_t:s0-s0:c0.c255 msg='uid=500: > exe="/usr/sbin/gdm-binary" (hostname=localhost.localdomain, > addr=2.0.0.0, terminal=:0 res=success)'' > 2006-07-21 09:20:14,723 [avc.ERROR] Unexpected exception too many > values to unpack > Traceback (most recent call last): > File "/usr/lib/audit/setroubleshoot_dispatcher", line 100, in ? > snap.run() > File "/usr/lib/audit/setroubleshoot_dispatcher", line 83, in run > self.process(msg.get_msg_type(), msg.get_body()) > File "/usr/lib/audit/setroubleshoot_dispatcher", line 66, in process > var, val = i.split("=") > ValueError: too many values to unpack > 2006-07-21 09:20:14,726 [avc.ERROR] Traceback (most recent call last): > File "/usr/lib/audit/setroubleshoot_dispatcher", line 100, in ? > snap.run() > File "/usr/lib/audit/setroubleshoot_dispatcher", line 83, in run > self.process(msg.get_msg_type(), msg.get_body()) > File "/usr/lib/audit/setroubleshoot_dispatcher", line 66, in process > var, val = i.split("=") > ValueError: too many values to unpack > Traceback (most recent call last): > File "/usr/lib/audit/setroubleshoot_dispatcher", line 100, in ? > snap.run() > File "/usr/lib/audit/setroubleshoot_dispatcher", line 83, in run > self.process(msg.get_msg_type(), msg.get_body()) > File "/usr/lib/audit/setroubleshoot_dispatcher", line 66, in process > var, val = i.split("=") > ValueError: too many values to unpack Could you attach the /var/log/audit/audit.log? Dan From mschwartz at mn.rr.com Fri Jul 21 16:57:23 2006 From: mschwartz at mn.rr.com (Marc Schwartz (via MN)) Date: Fri, 21 Jul 2006 11:57:23 -0500 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <44BE120E.3050100@city-fan.org> References: <1151503719.7470.12.camel@laurel.intra.city-fan.org> <1151522527.3438.52.camel@localhost.localdomain> <1151525638.7470.77.camel@laurel.intra.city-fan.org> <1151528181.3438.98.camel@localhost.localdomain> <1151529828.7470.92.camel@laurel.intra.city-fan.org> <1151530682.3438.108.camel@localhost.localdomain> <1151532794.7470.101.camel@laurel.intra.city-fan.org> <1151550925.6200.48.camel@localhost.localdomain> <1151566188.7470.111.camel@laurel.intra.city-fan.org> <1151587633.6200.56.camel@localhost.localdomain> <1151624293.6466.10.camel@localhost.localdomain> <44A524CE.1070205@city-fan.org> <44AA9CF1.6000601@city-fan.org> <1152125919.4843.141.camel@localhost.localdomain> <44B7D0DA.9090207@city-fan.org> <1153144713.4897.18.camel@localhost.localdomain> <44BCDE1C.8070409@city-fan.org> <1153234408.3796.12.camel@localhost.localdomain> <44BCFB1A.8040909@city-fan.org> <1153269476.6132.15.camel@localhost.localdomain> <44BE120E.3050100@city-fan.org> Message-ID: <1153501044.3874.15.camel@localhost.localdomain> Well, after a couple of days and several re-boots, the following is the only avc so far: type=AVC msg=audit(1153435170.422:48): avc: denied { search } for pid=15586 comm="clamscan" name="marcs" dev=dm-0 ino=425153 scontext=system_u:system_r:clamscan_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0 tclass=dir type=SYSCALL msg=audit(1153435170.422:48): arch=40000003 syscall=10 success=no exit=-13 a0=9730020 a1=1 a2=448ce93c a3=972f7e0 items=1 pid=15586 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="clamscan" exe="/usr/bin/clamscan" subj=system_u:system_r:clamscan_t:s0 type=CWD msg=audit(1153435170.422:48): cwd="/home/marcs" type=PATH msg=audit(1153435170.422:48): item=0 name="tnef" parent=58512 dev=fd:02 mode=0100600 ouid=500 ogid=500 rdev=00:00 obj=system_u:object_r:clamscan_tmp_t:s0 I am running in Enforcing mode. Current policies: selinux-policy-2.3.2-1.fc5 selinux-policy-targeted-2.3.2-1.fc5 amavis 1.0.5 clamav 1.0.4 dcc 1.0.1 myclamav 0.1.5 mydcc 0.1.9 mypostfix 0.1.1 mypyzor 0.2.3 myspamassassin 0.1.5 procmail 0.5.4 pyzor 1.0.4 razor 1.0.1 Regards, Marc From paul at city-fan.org Fri Jul 21 17:06:23 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 21 Jul 2006 18:06:23 +0100 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <1153501044.3874.15.camel@localhost.localdomain> References: <1151525638.7470.77.camel@laurel.intra.city-fan.org> <1151528181.3438.98.camel@localhost.localdomain> <1151529828.7470.92.camel@laurel.intra.city-fan.org> <1151530682.3438.108.camel@localhost.localdomain> <1151532794.7470.101.camel@laurel.intra.city-fan.org> <1151550925.6200.48.camel@localhost.localdomain> <1151566188.7470.111.camel@laurel.intra.city-fan.org> <1151587633.6200.56.camel@localhost.localdomain> <1151624293.6466.10.camel@localhost.localdomain> <44A524CE.1070205@city-fan.org> <44AA9CF1.6000601@city-fan.org> <1152125919.4843.141.camel@localhost.localdomain> <44B7D0DA.9090207@city-fan.org> <1153144713.4897.18.camel@localhost.localdomain> <44BCDE1C.8070409@city-fan.org> <1153234408.3796.12.camel@localhost.localdomain> <44BCFB1A.8040909@city-fan.org> <1153269476.6132.15.camel@localhost.localdomain> <44BE120E.3050100@city-fan.org> <1153501044.3874.15.camel@localhost.localdomain> Message-ID: <44C1098F.60105@city-fan.org> Marc Schwartz (via MN) wrote: > Well, after a couple of days and several re-boots, the following is the > only avc so far: > > type=AVC msg=audit(1153435170.422:48): avc: denied { search } for pid=15586 comm="clamscan" name="marcs" dev=dm-0 ino=425153 scontext=system_u:system_r:clamscan_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0 tclass=dir > type=SYSCALL msg=audit(1153435170.422:48): arch=40000003 syscall=10 success=no exit=-13 a0=9730020 a1=1 a2=448ce93c a3=972f7e0 items=1 pid=15586 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="clamscan" exe="/usr/bin/clamscan" subj=system_u:system_r:clamscan_t:s0 > type=CWD msg=audit(1153435170.422:48): cwd="/home/marcs" > type=PATH msg=audit(1153435170.422:48): item=0 name="tnef" parent=58512 dev=fd:02 mode=0100600 ouid=500 ogid=500 rdev=00:00 obj=system_u:object_r:clamscan_tmp_t:s0 > > I am running in Enforcing mode. It appears to be trying to look in your home directory whilst scanning a temporary file called "tnef". The program appears to be running in your home directory, probably since it's running from your .procmailrc and clamassassin. I wonder if this can be dontaudited? Any idea whether the scan of this file worked or not? Paul. From mschwartz at mn.rr.com Fri Jul 21 17:22:57 2006 From: mschwartz at mn.rr.com (Marc Schwartz (via MN)) Date: Fri, 21 Jul 2006 12:22:57 -0500 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <44C1098F.60105@city-fan.org> References: <1151525638.7470.77.camel@laurel.intra.city-fan.org> <1151528181.3438.98.camel@localhost.localdomain> <1151529828.7470.92.camel@laurel.intra.city-fan.org> <1151530682.3438.108.camel@localhost.localdomain> <1151532794.7470.101.camel@laurel.intra.city-fan.org> <1151550925.6200.48.camel@localhost.localdomain> <1151566188.7470.111.camel@laurel.intra.city-fan.org> <1151587633.6200.56.camel@localhost.localdomain> <1151624293.6466.10.camel@localhost.localdomain> <44A524CE.1070205@city-fan.org> <44AA9CF1.6000601@city-fan.org> <1152125919.4843.141.camel@localhost.localdomain> <44B7D0DA.9090207@city-fan.org> <1153144713.4897.18.camel@localhost.localdomain> <44BCDE1C.8070409@city-fan.org> <1153234408.3796.12.camel@localhost.localdomain> <44BCFB1A.8040909@city-fan.org> <1153269476.6132.15.camel@localhost.localdomain> <44BE120E.3050100@city-fan.org> <1153501044.3874.15.camel@localhost.localdomain> <44C1098F.60105@city-fan.org> Message-ID: <1153502577.3874.25.camel@localhost.localdomain> On Fri, 2006-07-21 at 18:06 +0100, Paul Howarth wrote: > Marc Schwartz (via MN) wrote: > > Well, after a couple of days and several re-boots, the following is the > > only avc so far: > > > > type=AVC msg=audit(1153435170.422:48): avc: denied { search } for pid=15586 comm="clamscan" name="marcs" dev=dm-0 ino=425153 scontext=system_u:system_r:clamscan_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0 tclass=dir > > type=SYSCALL msg=audit(1153435170.422:48): arch=40000003 syscall=10 success=no exit=-13 a0=9730020 a1=1 a2=448ce93c a3=972f7e0 items=1 pid=15586 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="clamscan" exe="/usr/bin/clamscan" subj=system_u:system_r:clamscan_t:s0 > > type=CWD msg=audit(1153435170.422:48): cwd="/home/marcs" > > type=PATH msg=audit(1153435170.422:48): item=0 name="tnef" parent=58512 dev=fd:02 mode=0100600 ouid=500 ogid=500 rdev=00:00 obj=system_u:object_r:clamscan_tmp_t:s0 > > > > I am running in Enforcing mode. > > It appears to be trying to look in your home directory whilst scanning a > temporary file called "tnef". 'tnef' files (Transport Neutral Encapsulation Format) are a MIME type coming from Winders Outlook users. They tend to show up in Evolution as 'winmail.dat' attachments, which then require a tnef viewer such as tnef or KTnef or similar to open and view: http://sourceforge.net/projects/tnef I do occasionally get this from co-workers and others who are on Windows. > The program appears to be running in your home directory, probably since > it's running from your .procmailrc and clamassassin. I wonder if this > can be dontaudited? Any idea whether the scan of this file worked or not? I can confirm that I have received at least one 'tnef' type attachment in the past 48 hours, which came through to Evo without problem. These would not normally be picked up as a virus/worm, etc. via scanners. Marc From paul at city-fan.org Fri Jul 21 17:26:52 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 21 Jul 2006 18:26:52 +0100 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <1153502577.3874.25.camel@localhost.localdomain> References: <1151528181.3438.98.camel@localhost.localdomain> <1151529828.7470.92.camel@laurel.intra.city-fan.org> <1151530682.3438.108.camel@localhost.localdomain> <1151532794.7470.101.camel@laurel.intra.city-fan.org> <1151550925.6200.48.camel@localhost.localdomain> <1151566188.7470.111.camel@laurel.intra.city-fan.org> <1151587633.6200.56.camel@localhost.localdomain> <1151624293.6466.10.camel@localhost.localdomain> <44A524CE.1070205@city-fan.org> <44AA9CF1.6000601@city-fan.org> <1152125919.4843.141.camel@localhost.localdomain> <44B7D0DA.9090207@city-fan.org> <1153144713.4897.18.camel@localhost.localdomain> <44BCDE1C.8070409@city-fan.org> <1153234408.3796.12.camel@localhost.localdomain> <44BCFB1A.8040909@city-fan.org> <1153269476.6132.15.camel@localhost.localdomain> <44BE120E.3050100@city-fan.org> <1153501044.3874.15.camel@localhost.localdomain> <44C1098F.60105@city-fan.org> <1153502577.3874.25.camel@localhost.localdomain> Message-ID: <44C10E5C.1050902@city-fan.org> Marc Schwartz (via MN) wrote: > On Fri, 2006-07-21 at 18:06 +0100, Paul Howarth wrote: >> Marc Schwartz (via MN) wrote: >>> Well, after a couple of days and several re-boots, the following is the >>> only avc so far: >>> >>> type=AVC msg=audit(1153435170.422:48): avc: denied { search } for pid=15586 comm="clamscan" name="marcs" dev=dm-0 ino=425153 scontext=system_u:system_r:clamscan_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0 tclass=dir >>> type=SYSCALL msg=audit(1153435170.422:48): arch=40000003 syscall=10 success=no exit=-13 a0=9730020 a1=1 a2=448ce93c a3=972f7e0 items=1 pid=15586 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="clamscan" exe="/usr/bin/clamscan" subj=system_u:system_r:clamscan_t:s0 >>> type=CWD msg=audit(1153435170.422:48): cwd="/home/marcs" >>> type=PATH msg=audit(1153435170.422:48): item=0 name="tnef" parent=58512 dev=fd:02 mode=0100600 ouid=500 ogid=500 rdev=00:00 obj=system_u:object_r:clamscan_tmp_t:s0 >>> >>> I am running in Enforcing mode. >> It appears to be trying to look in your home directory whilst scanning a >> temporary file called "tnef". > > 'tnef' files (Transport Neutral Encapsulation Format) are a MIME type > coming from Winders Outlook users. They tend to show up in Evolution as > 'winmail.dat' attachments, which then require a tnef viewer such as tnef > or KTnef or similar to open and view: > > http://sourceforge.net/projects/tnef > > I do occasionally get this from co-workers and others who are on > Windows. > >> The program appears to be running in your home directory, probably since >> it's running from your .procmailrc and clamassassin. I wonder if this >> can be dontaudited? Any idea whether the scan of this file worked or not? > > I can confirm that I have received at least one 'tnef' type attachment > in the past 48 hours, which came through to Evo without problem. These > would not normally be picked up as a virus/worm, etc. via scanners. I'd expect you to get one of these AVCs for each scanned attachment; have you only seen the one instance? Could you try getting it to scan something that should be detected as "bad" and make sure it works? Paul. From mschwartz at mn.rr.com Fri Jul 21 18:19:20 2006 From: mschwartz at mn.rr.com (Marc Schwartz (via MN)) Date: Fri, 21 Jul 2006 13:19:20 -0500 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <44C10E5C.1050902@city-fan.org> References: <1151528181.3438.98.camel@localhost.localdomain> <1151529828.7470.92.camel@laurel.intra.city-fan.org> <1151530682.3438.108.camel@localhost.localdomain> <1151532794.7470.101.camel@laurel.intra.city-fan.org> <1151550925.6200.48.camel@localhost.localdomain> <1151566188.7470.111.camel@laurel.intra.city-fan.org> <1151587633.6200.56.camel@localhost.localdomain> <1151624293.6466.10.camel@localhost.localdomain> <44A524CE.1070205@city-fan.org> <44AA9CF1.6000601@city-fan.org> <1152125919.4843.141.camel@localhost.localdomain> <44B7D0DA.9090207@city-fan.org> <1153144713.4897.18.camel@localhost.localdomain> <44BCDE1C.8070409@city-fan.org> <1153234408.3796.12.camel@localhost.localdomain> <44BCFB1A.8040909@city-fan.org> <1153269476.6132.15.camel@localhost.localdomain> <44BE120E.3050100@city-fan.org> <1153501044.3874.15.camel@localhost.localdomain> <44C1098F.60105@city-fan.org> <1153502577.3874.25.camel@localhost.localdomain> <44C10E5C.1050902@city-fan.org> Message-ID: <1153505960.3874.52.camel@localhost.localdomain> On Fri, 2006-07-21 at 18:26 +0100, Paul Howarth wrote: > Marc Schwartz (via MN) wrote: > > On Fri, 2006-07-21 at 18:06 +0100, Paul Howarth wrote: > >> Marc Schwartz (via MN) wrote: > >>> Well, after a couple of days and several re-boots, the following is the > >>> only avc so far: > >>> > >>> type=AVC msg=audit(1153435170.422:48): avc: denied { search } for pid=15586 comm="clamscan" name="marcs" dev=dm-0 ino=425153 scontext=system_u:system_r:clamscan_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0 tclass=dir > >>> type=SYSCALL msg=audit(1153435170.422:48): arch=40000003 syscall=10 success=no exit=-13 a0=9730020 a1=1 a2=448ce93c a3=972f7e0 items=1 pid=15586 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="clamscan" exe="/usr/bin/clamscan" subj=system_u:system_r:clamscan_t:s0 > >>> type=CWD msg=audit(1153435170.422:48): cwd="/home/marcs" > >>> type=PATH msg=audit(1153435170.422:48): item=0 name="tnef" parent=58512 dev=fd:02 mode=0100600 ouid=500 ogid=500 rdev=00:00 obj=system_u:object_r:clamscan_tmp_t:s0 > >>> > >>> I am running in Enforcing mode. > >> It appears to be trying to look in your home directory whilst scanning a > >> temporary file called "tnef". > > > > 'tnef' files (Transport Neutral Encapsulation Format) are a MIME type > > coming from Winders Outlook users. They tend to show up in Evolution as > > 'winmail.dat' attachments, which then require a tnef viewer such as tnef > > or KTnef or similar to open and view: > > > > http://sourceforge.net/projects/tnef > > > > I do occasionally get this from co-workers and others who are on > > Windows. > > > >> The program appears to be running in your home directory, probably since > >> it's running from your .procmailrc and clamassassin. I wonder if this > >> can be dontaudited? Any idea whether the scan of this file worked or not? > > > > I can confirm that I have received at least one 'tnef' type attachment > > in the past 48 hours, which came through to Evo without problem. These > > would not normally be picked up as a virus/worm, etc. via scanners. > > I'd expect you to get one of these AVCs for each scanned attachment; > have you only seen the one instance? There has only been one in the past day or two that I can recall. > Could you try getting it to scan something that should be detected as > "bad" and make sure it works? An incoming external e-mail will be hard. Between the virus filters now on my personal ISP and those that my company has installed on the corporate mail server, it is virtually impossible to get one to get in the pipeline on my system to be scanned by clamav. Oh wait a minute, presuming that this works properly, mail path wise, I can use mutt to attach an EICAR signature file and then send that e-mail to my local user account (ie. marcs at localhost) via the CLI. OK. That appears to work. I do get the e-mails, with the subject header re-write "[***** VIRUS *****]" via clamassassin. So if the mail path of a locally sent e-mail (versus an incoming POP3 msg) is OK, we are good to go. OK on the avc's also. The only avc still output is the one that I sent earlier. HTH, Marc From wart at kobold.org Fri Jul 21 19:25:51 2006 From: wart at kobold.org (Michael Thomas) Date: Fri, 21 Jul 2006 12:25:51 -0700 Subject: package review? In-Reply-To: <44C0F6D4.2060303@city-fan.org> References: <44BEA63B.7030105@kobold.org> <44C0F6D4.2060303@city-fan.org> Message-ID: <44C12A3F.3080503@kobold.org> Paul Howarth wrote: > Michael Thomas wrote: > >> A few packages (game server daemons) that I maintain in Fedora Extras >> would benefit from having a selinux security policy available. But >> since I'm new to writing selinux policies, I was hoping that someone >> from f-s-l could take a peek at what I did and let me know if I've done >> things correctly and in the 'recommended' way. >> >> I've already tested the policy on FC5 to make sure that it works and >> produces no 'avc denied' messages: >> >> http://www.kobold.org/~wart/fedora/crossfire-1.9.1-2.src.rpm >> >> I wasn't sure exactly which networking rules I would need. Most of the >> ones there were generated by policygentool. I also couldn't figure out >> why some of the rules at the end of crossfire.te were necessary. > > > I don't see any domain transition to crossfire_t in your policy; how > does it get into that domain? It should be there in crossfire.if, no? > Your policy file includes a comment about wanting to patch out use of > temp files; another option would be to use your own domain for temp > files, as you've done for the log files. Good point. But it looks like changing to not use /tmp will be fairly straightforward. > Did you follow the guide on Packaging/SELinux on the wiki for actually > building the module in your package? I've changed what I do for package > building since I last updated that page (and I can't update it any more) > and you'll find it won't build on rawhide as there is an > selinux-policy-devel package you need as a buildreq there. Yes, I used policygentool to generate the policy files, then your SELinux page to put it in the package. I'd like to see an official packaging policy for selinux modules for Fedora Extras, but I'm not sure that there are many FE contributors looking at selinux yet. It looks like the page has also been copied to PackagingDrafts/SELinux, where you should be able to modify it. Some things that would be nice to clarify: Should selinux be added as a subpackage or automatically included in the base package? If selinux is added as a subpackage, what should its Requires: look like (or should there even be any?) Is a single targetted policy enough, or is it necessary to build for all selinux variants (mls, strict, targeted)? > An example of the way I'm currently doing SELinux module packaging can > be found here: > > http://www.city-fan.org/~paul/extras/mod_fcgid/mod_fcgid.spec /me runs screaming from the %defines :) --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From paul at city-fan.org Fri Jul 21 20:11:36 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 21 Jul 2006 21:11:36 +0100 Subject: package review? In-Reply-To: <44C12A3F.3080503@kobold.org> References: <44BEA63B.7030105@kobold.org> <44C0F6D4.2060303@city-fan.org> <44C12A3F.3080503@kobold.org> Message-ID: <1153512696.30083.17.camel@laurel.intra.city-fan.org> On Fri, 2006-07-21 at 12:25 -0700, Michael Thomas wrote: > Paul Howarth wrote: > > Michael Thomas wrote: > > > >> A few packages (game server daemons) that I maintain in Fedora Extras > >> would benefit from having a selinux security policy available. But > >> since I'm new to writing selinux policies, I was hoping that someone > >> from f-s-l could take a peek at what I did and let me know if I've done > >> things correctly and in the 'recommended' way. > >> > >> I've already tested the policy on FC5 to make sure that it works and > >> produces no 'avc denied' messages: > >> > >> http://www.kobold.org/~wart/fedora/crossfire-1.9.1-2.src.rpm > >> > >> I wasn't sure exactly which networking rules I would need. Most of the > >> ones there were generated by policygentool. I also couldn't figure out > >> why some of the rules at the end of crossfire.te were necessary. > > > > > > I don't see any domain transition to crossfire_t in your policy; how > > does it get into that domain? > > It should be there in crossfire.if, no? That's the interface used to transition to crossfire_t from some other domain. So if you wanted it to run confined when just started by a regular unconfined user, you'd need: crossfire_domtrans(unconfined_t) in a rules (.te) file. Interfaces are used so that rules and types defined for one domain can be used from another domain, so that everything relating to each domain can kept together. So if your policy was to get merged into upstream policy, this domain transition would go in the unconfined.te module. However, if you're providing a standalone module, it probably makes sense to include this in your own crossfire.te file. You should check that the transition has happened by running ps with the "-Z" option to show the process context when you're running the application. Note that most things running confined under targeted policy are started from initscripts and there is no transition from unconfined_t needed (or wanted). That's not the case here though. > > Did you follow the guide on Packaging/SELinux on the wiki for actually > > building the module in your package? I've changed what I do for package > > building since I last updated that page (and I can't update it any more) > > and you'll find it won't build on rawhide as there is an > > selinux-policy-devel package you need as a buildreq there. > > Yes, I used policygentool to generate the policy files, then your > SELinux page to put it in the package. I'd like to see an official > packaging policy for selinux modules for Fedora Extras, but I'm not sure > that there are many FE contributors looking at selinux yet. It looks > like the page has also been copied to PackagingDrafts/SELinux, where you > should be able to modify it. Yes, Tibbs contacted me privately about that. I've have a go at updating it, probably next week. > Some things that would be nice to clarify: > > Should selinux be added as a subpackage or automatically included in the > base package? I don't have a strong opinion either way on this. I've tended to stick to keeping everything together because I find it easier to manage that way. As long as the SELinux bits don't get in the way of people not using them, I don't think it's a problem. > If selinux is added as a subpackage, what should its Requires: look like > (or should there even be any?) I think that could depend on the particular relationship between the policy and the main package. For instance, if in your package you patched out the need for temp files and you didn't allow it to use them in the SELinux policy, the policy package would want to conflict with any version of the main package prior to the addition of the patch. I favour Conflicts: for these rather than Requires: because I can see reasons why people would want to install both parts independently of the other (non-SELinux users would want the main package without the policy, and people wanting to learn about SELinux might want the policy package without the main one). > Is a single targetted policy enough, or is it necessary to build for all > selinux variants (mls, strict, targeted)? If the built module is the same for all policies (which it will be if there's nothing policy-specific in it), you could just build one module and load it for all policies. > > An example of the way I'm currently doing SELinux module packaging can > > be found here: > > > > http://www.city-fan.org/~paul/extras/mod_fcgid/mod_fcgid.spec > > /me runs screaming from the %defines :) Understandable. I like to maintain one spec per package rather than separate ones for each branch. If you're happy to maintain separate specs for each branch, most of the defines can be hard-coded into the spec. Paul. From wart at kobold.org Fri Jul 21 21:14:15 2006 From: wart at kobold.org (Michael Thomas) Date: Fri, 21 Jul 2006 14:14:15 -0700 Subject: package review? In-Reply-To: <1153512696.30083.17.camel@laurel.intra.city-fan.org> References: <44BEA63B.7030105@kobold.org> <44C0F6D4.2060303@city-fan.org> <44C12A3F.3080503@kobold.org> <1153512696.30083.17.camel@laurel.intra.city-fan.org> Message-ID: <44C143A7.8070602@kobold.org> Paul Howarth wrote: > On Fri, 2006-07-21 at 12:25 -0700, Michael Thomas wrote: > >>Paul Howarth wrote: >>>I don't see any domain transition to crossfire_t in your policy; how >>>does it get into that domain? >> >>It should be there in crossfire.if, no? > > > That's the interface used to transition to crossfire_t from some other > domain. So if you wanted it to run confined when just started by a > regular unconfined user, you'd need: > > crossfire_domtrans(unconfined_t) > > in a rules (.te) file. Interfaces are used so that rules and types > defined for one domain can be used from another domain, so that > everything relating to each domain can kept together. So if your policy > was to get merged into upstream policy, this domain transition would go > in the unconfined.te module. > > However, if you're providing a standalone module, it probably makes > sense to include this in your own crossfire.te file. Yes, I'd like to avoid the need for modifications in the global policies if at all possible. > You should check that the transition has happened by running ps with the > "-Z" option to show the process context when you're running the > application. It shows up as crossfire_exec_t because... > Note that most things running confined under targeted policy are started > from initscripts and there is no transition from unconfined_t needed (or > wanted). That's not the case here though. ...it is started from an init script. Normal (unconfined) users should not be starting this by hand. Instead, normal users will run the client application which connects to this server. In this case, it sounds like I don't need the rule to transition from unconfined_t. >>Some things that would be nice to clarify: >> >>Should selinux be added as a subpackage or automatically included in the >>base package? > > > I don't have a strong opinion either way on this. I've tended to stick > to keeping everything together because I find it easier to manage that > way. As long as the SELinux bits don't get in the way of people not > using them, I don't think it's a problem. I think I would prefer to use a separate package (not integrated with the base package), so that the policy can be turned on and off by simply installing/uninstalling the -selinux package. >>If selinux is added as a subpackage, what should its Requires: look like >>(or should there even be any?) > > > I think that could depend on the particular relationship between the > policy and the main package. For instance, if in your package you > patched out the need for temp files and you didn't allow it to use them > in the SELinux policy, the policy package would want to conflict with > any version of the main package prior to the addition of the patch. I > favour Conflicts: for these rather than Requires: because I can see > reasons why people would want to install both parts independently of the > other (non-SELinux users would want the main package without the policy, > and people wanting to learn about SELinux might want the policy package > without the main one). I think I would prefer if they were separate packages, whether they are part of the same spec file or not. Your argument for using Conflicts: vs. Requires: makes a lot of sense. >>Is a single targetted policy enough, or is it necessary to build for all >>selinux variants (mls, strict, targeted)? > > > If the built module is the same for all policies (which it will be if > there's nothing policy-specific in it), you could just build one module > and load it for all policies. Ok. >>>An example of the way I'm currently doing SELinux module packaging can >>>be found here: >>> >>>http://www.city-fan.org/~paul/extras/mod_fcgid/mod_fcgid.spec >> >>/me runs screaming from the %defines :) > > > Understandable. I like to maintain one spec per package rather than > separate ones for each branch. If you're happy to maintain separate > specs for each branch, most of the defines can be hard-coded into the > spec. Yeah, I think I'll do that. :) --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From wart at kobold.org Sat Jul 22 03:45:20 2006 From: wart at kobold.org (Wart) Date: Fri, 21 Jul 2006 20:45:20 -0700 Subject: package review? In-Reply-To: <44C0F18F.5030108@city-fan.org> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> <44C0F18F.5030108@city-fan.org> Message-ID: <44C19F50.50408@kobold.org> Paul Howarth wrote: > Wart wrote: > >> Daniel J Walsh wrote: >> >>> allow crossfire_t port_t:udp_socket send_msg; >>> allow crossfire_t port_t:tcp_socket name_bind; >>> You need to define a port for this socket and only allow name_bind to >>> that port >> >> >> I know I'm missing something obvious here, but which macro can I use to >> add this restriction? I saw references to http_port_t and ntp_port_t in >> corenetwork.if, but didn't see anything that actually defined it to be >> port 80 (http) or port 123 (ntp). > > > policy/modules/kernel/corenetwork.te.in: > > ... > network_port(ntp, udp,123,s0) > ... > network_port(http, tcp,80,s0, tcp,443,s0, tcp,488,s0, tcp,8008,s0, > tcp,8009,s0) Thanks. This is just what I needed. I could have sworn that this syntax was working for me earlier today, but now I keep getting syntax errors on FC5: + make -f /usr/share/selinux/devel/Makefile cat: /selinux/mls: No such file or directory Compiling targeted crossfire module crossfire.te:67:ERROR 'syntax error' at token 'network_port' on line 59707: ## Networking basics (adjust to your needs!) network_port(crossfire, tcp,13327,s0) /usr/bin/checkmodule: error(s) encountered while parsing configuration /usr/bin/checkmodule: loading policy configuration from tmp/crossfire.tmp make: *** [tmp/crossfire.mod] Error 1 Is there something else that I need to include to be able to use network_port()? --Wart From paul at city-fan.org Sat Jul 22 12:05:31 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 22 Jul 2006 13:05:31 +0100 Subject: package review? In-Reply-To: <44C143A7.8070602@kobold.org> References: <44BEA63B.7030105@kobold.org> <44C0F6D4.2060303@city-fan.org> <44C12A3F.3080503@kobold.org> <1153512696.30083.17.camel@laurel.intra.city-fan.org> <44C143A7.8070602@kobold.org> Message-ID: <1153569931.30083.28.camel@laurel.intra.city-fan.org> On Fri, 2006-07-21 at 14:14 -0700, Michael Thomas wrote: > > You should check that the transition has happened by running ps with the > > "-Z" option to show the process context when you're running the > > application. > > It shows up as crossfire_exec_t because... crossfire_exec_t? Not crossfire_t? > > Note that most things running confined under targeted policy are started > > from initscripts and there is no transition from unconfined_t needed (or > > wanted). That's not the case here though. > > ...it is started from an init script. Normal (unconfined) users should > not be starting this by hand. Instead, normal users will run the client > application which connects to this server. In this case, it sounds like > I don't need the rule to transition from unconfined_t. Right; I must have missed the initscript in the files list. So yes, you are correct that you don't need (or even want) the transition from unconfined_t. > >>Some things that would be nice to clarify: > >> > >>Should selinux be added as a subpackage or automatically included in the > >>base package? > > > > > > I don't have a strong opinion either way on this. I've tended to stick > > to keeping everything together because I find it easier to manage that > > way. As long as the SELinux bits don't get in the way of people not > > using them, I don't think it's a problem. > > I think I would prefer to use a separate package (not integrated with > the base package), so that the policy can be turned on and off by simply > installing/uninstalling the -selinux package. Bear in mind that there should be a crossfire_disable_trans boolean that would turn off the policy (or rather the transition to crossfire_t) when set, without having to uninstall the policy. Paul. From phaceton at gmail.com Sat Jul 22 13:21:10 2006 From: phaceton at gmail.com (Peter Harmsen) Date: Sat, 22 Jul 2006 15:21:10 +0200 Subject: package review? In-Reply-To: <1153569931.30083.28.camel@laurel.intra.city-fan.org> References: <44BEA63B.7030105@kobold.org> <44C0F6D4.2060303@city-fan.org> <44C12A3F.3080503@kobold.org> <1153512696.30083.17.camel@laurel.intra.city-fan.org> <44C143A7.8070602@kobold.org> <1153569931.30083.28.camel@laurel.intra.city-fan.org> Message-ID: <3655f5d90607220621s4b7b239cq90058ee8e520ff91@mail.gmail.com> Perhaps a bit off topic. But since it is security related i might aswell ask it. What does the diverse exec-shield settings 3,11,9 mean? Default i have exec-shield =9, Setting it to 2 works too. kind regards, Peter On 7/22/06, Paul Howarth wrote: > On Fri, 2006-07-21 at 14:14 -0700, Michael Thomas wrote: > > > You should check that the transition has happened by running ps with the > > > "-Z" option to show the process context when you're running the > > > application. > > > > It shows up as crossfire_exec_t because... > > crossfire_exec_t? Not crossfire_t? > > > > Note that most things running confined under targeted policy are started > > > from initscripts and there is no transition from unconfined_t needed (or > > > wanted). That's not the case here though. > > > > ...it is started from an init script. Normal (unconfined) users should > > not be starting this by hand. Instead, normal users will run the client > > application which connects to this server. In this case, it sounds like > > I don't need the rule to transition from unconfined_t. > > Right; I must have missed the initscript in the files list. > > So yes, you are correct that you don't need (or even want) the transition from unconfined_t. > > > >>Some things that would be nice to clarify: > > >> > > >>Should selinux be added as a subpackage or automatically included in the > > >>base package? > > > > > > > > > I don't have a strong opinion either way on this. I've tended to stick > > > to keeping everything together because I find it easier to manage that > > > way. As long as the SELinux bits don't get in the way of people not > > > using them, I don't think it's a problem. > > > > I think I would prefer to use a separate package (not integrated with > > the base package), so that the policy can be turned on and off by simply > > installing/uninstalling the -selinux package. > > Bear in mind that there should be a crossfire_disable_trans boolean that > would turn off the policy (or rather the transition to crossfire_t) when > set, without having to uninstall the policy. > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- I have made this letter longer than usual, because i lack the time to make it short. From wart at kobold.org Sat Jul 22 17:38:08 2006 From: wart at kobold.org (Wart) Date: Sat, 22 Jul 2006 10:38:08 -0700 Subject: package review? In-Reply-To: <1153569931.30083.28.camel@laurel.intra.city-fan.org> References: <44BEA63B.7030105@kobold.org> <44C0F6D4.2060303@city-fan.org> <44C12A3F.3080503@kobold.org> <1153512696.30083.17.camel@laurel.intra.city-fan.org> <44C143A7.8070602@kobold.org> <1153569931.30083.28.camel@laurel.intra.city-fan.org> Message-ID: <44C26280.2090903@kobold.org> Paul Howarth wrote: > On Fri, 2006-07-21 at 14:14 -0700, Michael Thomas wrote: > >>>You should check that the transition has happened by running ps with the >>>"-Z" option to show the process context when you're running the >>>application. >> >>It shows up as crossfire_exec_t because... > > > crossfire_exec_t? Not crossfire_t? You're right, it is user_u:system_r:crossfire_t >>>>Some things that would be nice to clarify: >>>> >>>>Should selinux be added as a subpackage or automatically included in the >>>>base package? >>> >>> >>>I don't have a strong opinion either way on this. I've tended to stick >>>to keeping everything together because I find it easier to manage that >>>way. As long as the SELinux bits don't get in the way of people not >>>using them, I don't think it's a problem. >> >>I think I would prefer to use a separate package (not integrated with >>the base package), so that the policy can be turned on and off by simply >>installing/uninstalling the -selinux package. > > > Bear in mind that there should be a crossfire_disable_trans boolean that > would turn off the policy (or rather the transition to crossfire_t) when > set, without having to uninstall the policy. Is it enough to add the boolean to crossfire.te, or do I need to add anything in the .if file as well? type crossfire_t; type crossfire_exec_t; domain_type(crossfire_t) init_daemon_domain(crossfire_t, crossfire_exec_t) bool crossfire_disable_trans; --Mike From selinux at gmail.com Sun Jul 23 15:21:38 2006 From: selinux at gmail.com (Tom London) Date: Sun, 23 Jul 2006 08:21:38 -0700 Subject: AVC on restore from hibernation... Message-ID: <4c4ba1530607230821w7662a9c3h1d1f5aeea8718e88@mail.gmail.com> Running rawhide, targeted/enforcing. Follow AVC when restoring (I think) from hibernation: type=AVC msg=audit(1153604898.510:100): avc: denied { execmem } for pid=22517 comm="grub" scontext=system_u:system_r:hald_t:s0 tcontext=system_u:system_r:hald_t:s0 tclass=process type=SYSCALL msg=audit(1153604898.510:100): arch=40000003 syscall=192 success=no exit=-13 a0=0 a1=403000 a2=7 a3=1022 items=0 ppid=22508 pid=22517 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="grub" exe="/sbin/grub" subj=system_u:system_r:hald_t:s0 key=(null) tom -- Tom London From stefan at sf-net.com Sun Jul 23 18:30:57 2006 From: stefan at sf-net.com (Stefan) Date: Sun, 23 Jul 2006 20:30:57 +0200 Subject: problems with latest mls policy Message-ID: <18054BCE-FBFA-4564-A662-993ADC14BBBC@sf-net.com> Hi, since an update of the mls came out I have a problem loading a policy which worked correctly before the update. [data.te] policy_module(data,1.0.2) gen_require(` type user_t, staff_t, smbd_t, snmpd_t; ') type data_t; files_type(data_t); allow user_t data_t:dir { getattr read }; allow user_t data_t:file { getattr read }; allow staff_t data_t:dir { create rmdir rw_dir_perms setattr }; allow staff_t data_t:file { create rename rw_file_perms setattr unlink }; allow staff_t data_t:lnk_file { create rw_file_perms }; allow smbd_t data_t:dir { add_name create getattr read remove_name rename rmdir search setattr write }; allow smbd_t data_t:file { create getattr lock read rename setattr unlink write }; allow snmpd_t data_t:dir getattr; [data.fc] /data(/.*)? gen_context(system_u:object_r:data_t,s0) When I try to load the module (semodule -i data.pp) I get the following error message: libsepol.permission_copy_callback: Module data depends on permission setkeycreate in class process, not satisfied libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! I don't know what the error has to say. Any suggestions? ciao, Stefan PS: rpm -qa selinux-policy-mls selinux-policy-mls-2.3.2-1.fc5 From jacliburn at bellsouth.net Sun Jul 23 23:40:24 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Sun, 23 Jul 2006 18:40:24 -0500 Subject: 20060723 rawhide: sealert pegs my cpu Message-ID: <44C408E8.4030303@bellsouth.net> After applying rawhide updates for 20060723, sealert misbehaves. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2237 jcliburn 25 0 311m 23m 11m R 99.6 2.3 2:32.64 python 1 root 18 0 10284 688 572 S 0.0 0.1 0:00.76 init 2 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0 3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0 jcliburn 2237 1 90 18:32 ? 00:02:52 python /usr/sbin/sealert [jcliburn at osprey ~]$ rpm -qf /usr/sbin/sealert setroubleshoot-0.13-1 From lutfi at rg.co.id Mon Jul 24 02:06:39 2006 From: lutfi at rg.co.id (Lutfi) Date: Mon, 24 Jul 2006 09:06:39 +0700 Subject: SELinux and spamass-milter Message-ID: <44C42B2F.3040701@rg.co.id> It's like SELinux problem here. Cannot handle spamass-milter form Fedora Extras. Any help? Here log maillog n audit.log ==== /var/log/maillog Jul 24 08:58:31 beta spamd[2358]: spamd: connection from beta.rg.co.id [127.0.0.1] at port 39319 Jul 24 08:58:31 beta spamd[2358]: spamd: setuid to mail succeeded Jul 24 08:58:31 beta spamd[2358]: spamd: creating default_prefs: /var/spool/mail/.spamassassin/user_prefs Jul 24 08:58:31 beta spamd[2358]: mkdir /var/run/spamass-milter/.spamassassin: Permission denied at /usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin.pm line 1486 Jul 24 08:58:31 beta spamd[2358]: config: cannot write to /var/spool/mail/.spamassassin/user_prefs: Permission denied Jul 24 08:58:31 beta spamd[2358]: spamd: failed to create readable default_prefs: /var/spool/mail/.spamassassin/user_prefs Jul 24 08:58:31 beta spamd[2358]: spamd: processing message <008b01c6ad38$52a114e0$c000a8c0 at rbrana.co.id> for mail:8 Jul 24 08:58:36 beta spamd[2358]: locker: safe_lock: cannot create tmp lockfile /var/spool/mail/.spamassassin/auto-whitelist.lock.beta.rg.co.id.2358 for /var/spool/mail/.spamassassin/auto-whitelist.lock: Permission denied Jul 24 08:58:36 beta spamd[2358]: auto-whitelist: open of auto-whitelist file failed: locker: safe_lock: cannot create tmp lockfile /var/spool/mail/.spamassassin/auto-whitelist.lock.beta.rg.co.id.2358 for /var/spool/mail/.spamassassin/auto-whitelist.lock: Permission denied Jul 24 08:58:36 beta spamd[2358]: bayes: locker: safe_lock: cannot create tmp lockfile /var/spool/mail/.spamassassin/bayes.lock.beta.rg.co.id.2358 for /var/spool/mail/.spamassassin/bayes.lock: Permission denied Jul 24 08:58:36 beta spamd[2358]: spamd: clean message (-0.6/5.0) for mail:8 in 4.7 seconds, 21826 bytes. Jul 24 08:58:36 beta spamd[2358]: spamd: result: . 0 - ADVANCE_FEE_1,ALL_TRUSTED,HTML_MESSAGE,INFO_TLD scantime=4.7,size=21826,user=mail,uid=8,required_score=5.0,rhost=beta.rg.co.id,raddr=127.0.0.1,rport=39319,mid=<008b01c6ad38$52a114e0$c000a8c0 at rbrana.co.id>,autolearn=failed Jul 24 08:59:55 beta spamd[2358]: spamd: connection from beta.rg.co.id [127.0.0.1] at port 39352 Jul 24 08:59:55 beta spamd[2358]: spamd: setuid to mail succeeded Jul 24 08:59:55 beta spamd[2358]: spamd: creating default_prefs: /var/spool/mail/.spamassassin/user_prefs Jul 24 08:59:55 beta spamd[2358]: config: cannot write to /var/spool/mail/.spamassassin/user_prefs: Permission denied Jul 24 08:59:55 beta spamd[2358]: spamd: failed to create readable default_prefs: /var/spool/mail/.spamassassin/user_prefs Jul 24 08:59:55 beta spamd[2358]: spamd: processing message <200607220320.k6M3JtH9002594 at sigma.rbrana.co.id> for mail:8 Jul 24 09:00:00 beta spamd[2358]: locker: safe_lock: cannot create tmp lockfile /var/spool/mail/.spamassassin/auto-whitelist.lock.beta.rg.co.id.2358 for /var/spool/mail/.spamassassin/auto-whitelist.lock: Permission denied Jul 24 09:00:00 beta spamd[2358]: auto-whitelist: open of auto-whitelist file failed: locker: safe_lock: cannot create tmp lockfile /var/spool/mail/.spamassassin/auto-whitelist.lock.beta.rg.co.id.2358 for /var/spool/mail/.spamassassin/auto-whitelist.lock: Permission denied Jul 24 09:00:00 beta spamd[2358]: bayes: locker: safe_lock: cannot create tmp lockfile /var/spool/mail/.spamassassin/bayes.lock.beta.rg.co.id.2358 for /var/spool/mail/.spamassassin/bayes.lock: Permission denied Jul 24 09:00:00 beta spamd[2358]: spamd: clean message (-0.6/5.0) for mail:8 in 4.9 seconds, 40771 bytes. Jul 24 09:00:00 beta spamd[2358]: spamd: result: . 0 - ADVANCE_FEE_1,ALL_TRUSTED,HTML_MESSAGE,INFO_TLD scantime=4.9,size=40771,user=mail,uid=8,required_score=5.0,rhost=beta.rg.co.id,raddr=127.0.0.1,rport=39352,mid=<200607220320.k6M3JtH9002594 at sigma.rbrana.co.id>,autolearn=failed ==== /var/log/audit/audit.log type=AVC msg=audit(1153706398.439:33430): avc: denied { getattr } for pid=2358 comm="spamd" name="servers.catalogue.lst" dev=dm-0 ino=8800183 scontext=system_u:system_r:spamd_t:s0 tcontext=root:object_r:mail_spool_t:s0 tclass=file type=SYSCALL msg=audit(1153706398.439:33430): arch=40000003 syscall=195 success=no exit=-13 a0=9d931f0 a1=8c570c8 a2=c18ff4 a3=9d931f0 items=1 pid=2358 auid=4294967295 uid=0 gid=0 euid=8 suid=0 fsuid=8 egid=12 sgid=0 fsgid=12 tty=(none) comm="spamd" exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0 type=AVC_PATH msg=audit(1153706398.439:33430): path="/var/spool/mail/.razor/servers.catalogue.lst" type=CWD msg=audit(1153706398.439:33430): cwd="/" type=PATH msg=audit(1153706398.439:33430): item=0 name="/var/spool/mail/.razor/servers.catalogue.lst" inode=8800183 dev=fd:00 mode=0100644 ouid=8 ogid=12 rdev=00:00 obj=root:object_r:mail_spool_t:s0 type=AVC msg=audit(1153706398.443:33431): avc: denied { getattr } for pid=2358 comm="spamd" name="servers.catalogue.lst" dev=dm-0 ino=8800183 scontext=system_u:system_r:spamd_t:s0 tcontext=root:object_r:mail_spool_t:s0 tclass=file type=SYSCALL msg=audit(1153706398.443:33431): arch=40000003 syscall=195 success=no exit=-13 a0=9d931f0 a1=8c570c8 a2=c18ff4 a3=9d931f0 items=1 pid=2358 auid=4294967295 uid=0 gid=0 euid=8 suid=0 fsuid=8 egid=12 sgid=0 fsgid=12 tty=(none) comm="spamd" exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0 type=AVC_PATH msg=audit(1153706398.443:33431): path="/var/spool/mail/.razor/servers.catalogue.lst" type=CWD msg=audit(1153706398.443:33431): cwd="/" type=PATH msg=audit(1153706398.443:33431): item=0 name="/var/spool/mail/.razor/servers.catalogue.lst" inode=8800183 dev=fd:00 mode=0100644 ouid=8 ogid=12 rdev=00:00 obj=root:object_r:mail_spool_t:s0 type=AVC msg=audit(1153706399.375:33432): avc: denied { write } for pid=2358 comm="spamd" name=".razor" dev=dm-0 ino=8800180 scontext=system_u:system_r:spamd_t:s0 tcontext=root:object_r:mail_spool_t:s0 tclass=dir type=SYSCALL msg=audit(1153706399.375:33432): arch=40000003 syscall=5 success=no exit=-13 a0=a928610 a1=8241 a2=1b6 a3=8241 items=1 pid=2358 auid=4294967295 uid=0 gid=0 euid=8 suid=0 fsuid=8 egid=12 sgid=0 fsgid=12 tty=(none) comm="spamd" exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0 type=CWD msg=audit(1153706399.375:33432): cwd="/" type=PATH msg=audit(1153706399.375:33432): item=0 name="/var/spool/mail/.razor/servers.catalogue.lst.lock" parent=8800180 dev=fd:00 mode=040755 ouid=8 ogid=12 rdev=00:00 obj=root:object_r:mail_spool_t:s0 type=AVC msg=audit(1153706399.375:33433): avc: denied { write } for pid=2358 comm="spamd" name=".razor" dev=dm-0 ino=8800180 scontext=system_u:system_r:spamd_t:s0 tcontext=root:object_r:mail_spool_t:s0 tclass=dir type=SYSCALL msg=audit(1153706399.375:33433): arch=40000003 syscall=5 success=no exit=-13 a0=a9285d8 a1=8241 a2=1b6 a3=8241 items=1 pid=2358 auid=4294967295 uid=0 gid=0 euid=8 suid=0 fsuid=8 egid=12 sgid=0 fsgid=12 tty=(none) comm="spamd" exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0 type=CWD msg=audit(1153706399.375:33433): cwd="/" type=PATH msg=audit(1153706399.375:33433): item=0 name="/var/spool/mail/.razor/servers.nomination.lst.lock" parent=8800180 dev=fd:00 mode=040755 ouid=8 ogid=12 rdev=00:00 obj=root:object_r:mail_spool_t:s0 type=AVC msg=audit(1153706400.439:33434): avc: denied { write } for pid=2358 comm="spamd" name=".spamassassin" dev=dm-0 ino=7767101 scontext=system_u:system_r:spamd_t:s0 tcontext=root:object_r:mail_spool_t:s0 tclass=dir type=SYSCALL msg=audit(1153706400.439:33434): arch=40000003 syscall=5 success=no exit=-13 a0=a884720 a1=8241 a2=1b6 a3=8241 items=1 pid=2358 auid=4294967295 uid=0 gid=0 euid=8 suid=0 fsuid=8 egid=12 sgid=0 fsgid=12 tty=(none) comm="spamd" exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0 type=CWD msg=audit(1153706400.439:33434): cwd="/" type=PATH msg=audit(1153706400.439:33434): item=0 name="/var/spool/mail/.spamassassin/auto-whitelist.lock.beta.rg.co.id.2358" parent=7767101 dev=fd:00 mode=040700 ouid=8 ogid=12 rdev=00:00 obj=root:object_r:mail_spool_t:s0 type=AVC msg=audit(1153706400.463:33435): avc: denied { getattr } for pid=2358 comm="spamd" name="bayes_toks" dev=dm-0 ino=7767186 scontext=system_u:system_r:spamd_t:s0 tcontext=root:object_r:mail_spool_t:s0 tclass=file type=SYSCALL msg=audit(1153706400.463:33435): arch=40000003 syscall=195 success=no exit=-13 a0=9d931f0 a1=8c570c8 a2=c18ff4 a3=9d931f0 items=1 pid=2358 auid=4294967295 uid=0 gid=0 euid=8 suid=0 fsuid=8 egid=12 sgid=0 fsgid=12 tty=(none) comm="spamd" exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0 type=AVC_PATH msg=audit(1153706400.463:33435): path="/var/spool/mail/.spamassassin/bayes_toks" type=CWD msg=audit(1153706400.463:33435): cwd="/" type=PATH msg=audit(1153706400.463:33435): item=0 name="/var/spool/mail/.spamassassin/bayes_toks" inode=7767186 dev=fd:00 mode=0100600 ouid=8 ogid=12 rdev=00:00 obj=root:object_r:mail_spool_t:s0 type=AVC msg=audit(1153706400.463:33436): avc: denied { write } for pid=2358 comm="spamd" name=".spamassassin" dev=dm-0 ino=7767101 scontext=system_u:system_r:spamd_t:s0 tcontext=root:object_r:mail_spool_t:s0 tclass=dir type=SYSCALL msg=audit(1153706400.463:33436): arch=40000003 syscall=5 success=no exit=-13 a0=a79f970 a1=8241 a2=1b6 a3=8241 items=1 pid=2358 auid=4294967295 uid=0 gid=0 euid=8 suid=0 fsuid=8 egid=12 sgid=0 fsgid=12 tty=(none) comm="spamd" exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0 type=CWD msg=audit(1153706400.463:33436): cwd="/" type=PATH msg=audit(1153706400.463:33436): item=0 name="/var/spool/mail/.spamassassin/bayes.lock.beta.rg.co.id.2358" parent=7767101 dev=fd:00 mode=040700 ouid=8 ogid=12 rdev=00:00 obj=root:object_r:mail_spool_t:s0 From selinux at gmail.com Mon Jul 24 02:35:49 2006 From: selinux at gmail.com (Tom London) Date: Sun, 23 Jul 2006 19:35:49 -0700 Subject: setroubleshoot message in Anacron mail to root Message-ID: <4c4ba1530607231935i210c2d94v210a3f9398701f29@mail.gmail.com> Running latest rawhide, targeted/enforcing. Get this in Anacron email to root: /etc/cron.daily/logrotate: error: setroubleshoot:6 unknown option 'endscript' -- ignoring line Appears this is referring to line 6 of /etc/logrotate.d/setroubleshoot. tom -- Tom London From paul at city-fan.org Mon Jul 24 07:20:14 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 24 Jul 2006 08:20:14 +0100 Subject: SELinux and spamass-milter In-Reply-To: <44C42B2F.3040701@rg.co.id> References: <44C42B2F.3040701@rg.co.id> Message-ID: <1153725614.30083.41.camel@laurel.intra.city-fan.org> On Mon, 2006-07-24 at 09:06 +0700, Lutfi wrote: > It's like SELinux problem here. Cannot handle spamass-milter form Fedora > Extras. Any help? > Here log maillog n audit.log > > ==== /var/log/maillog > Jul 24 08:58:31 beta spamd[2358]: spamd: connection from beta.rg.co.id > [127.0.0.1] at port 39319 > Jul 24 08:58:31 beta spamd[2358]: spamd: setuid to mail succeeded > Jul 24 08:58:31 beta spamd[2358]: spamd: creating default_prefs: > /var/spool/mail/.spamassassin/user_prefs > Jul 24 08:58:31 beta spamd[2358]: mkdir > /var/run/spamass-milter/.spamassassin: Permission denied at > /usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin.pm line 1486 > Jul 24 08:58:31 beta spamd[2358]: config: cannot write to > /var/spool/mail/.spamassassin/user_prefs: Permission denied > Jul 24 08:58:31 beta spamd[2358]: spamd: failed to create readable > default_prefs: /var/spool/mail/.spamassassin/user_prefs > Jul 24 08:58:31 beta spamd[2358]: spamd: processing message > <008b01c6ad38$52a114e0$c000a8c0 at rbrana.co.id> for mail:8 > Jul 24 08:58:36 beta spamd[2358]: locker: safe_lock: cannot create tmp > lockfile > /var/spool/mail/.spamassassin/auto-whitelist.lock.beta.rg.co.id.2358 for > /var/spool/mail/.spamassassin/auto-whitelist.lock: Permission denied > Jul 24 08:58:36 beta spamd[2358]: auto-whitelist: open of auto-whitelist > file failed: locker: safe_lock: cannot create tmp lockfile > /var/spool/mail/.spamassassin/auto-whitelist.lock.beta.rg.co.id.2358 for > /var/spool/mail/.spamassassin/auto-whitelist.lock: Permission denied > Jul 24 08:58:36 beta spamd[2358]: bayes: locker: safe_lock: cannot > create tmp lockfile > /var/spool/mail/.spamassassin/bayes.lock.beta.rg.co.id.2358 for > /var/spool/mail/.spamassassin/bayes.lock: Permission denied > Jul 24 08:58:36 beta spamd[2358]: spamd: clean message (-0.6/5.0) for > mail:8 in 4.7 seconds, 21826 bytes. > Jul 24 08:58:36 beta spamd[2358]: spamd: result: . 0 - > ADVANCE_FEE_1,ALL_TRUSTED,HTML_MESSAGE,INFO_TLD > scantime=4.7,size=21826,user=mail,uid=8,required_score=5.0,rhost=beta.rg.co.id,raddr=127.0.0.1,rport=39319,mid=<008b01c6ad38$52a114e0$c000a8c0 at rbrana.co.id>,autolearn=failed > Jul 24 08:59:55 beta spamd[2358]: spamd: connection from beta.rg.co.id > [127.0.0.1] at port 39352 > Jul 24 08:59:55 beta spamd[2358]: spamd: setuid to mail succeeded > Jul 24 08:59:55 beta spamd[2358]: spamd: creating default_prefs: > /var/spool/mail/.spamassassin/user_prefs > Jul 24 08:59:55 beta spamd[2358]: config: cannot write to > /var/spool/mail/.spamassassin/user_prefs: Permission denied > Jul 24 08:59:55 beta spamd[2358]: spamd: failed to create readable > default_prefs: /var/spool/mail/.spamassassin/user_prefs > Jul 24 08:59:55 beta spamd[2358]: spamd: processing message > <200607220320.k6M3JtH9002594 at sigma.rbrana.co.id> for mail:8 > Jul 24 09:00:00 beta spamd[2358]: locker: safe_lock: cannot create tmp > lockfile > /var/spool/mail/.spamassassin/auto-whitelist.lock.beta.rg.co.id.2358 for > /var/spool/mail/.spamassassin/auto-whitelist.lock: Permission denied > Jul 24 09:00:00 beta spamd[2358]: auto-whitelist: open of auto-whitelist > file failed: locker: safe_lock: cannot create tmp lockfile > /var/spool/mail/.spamassassin/auto-whitelist.lock.beta.rg.co.id.2358 for > /var/spool/mail/.spamassassin/auto-whitelist.lock: Permission denied > Jul 24 09:00:00 beta spamd[2358]: bayes: locker: safe_lock: cannot > create tmp lockfile > /var/spool/mail/.spamassassin/bayes.lock.beta.rg.co.id.2358 for > /var/spool/mail/.spamassassin/bayes.lock: Permission denied > Jul 24 09:00:00 beta spamd[2358]: spamd: clean message (-0.6/5.0) for > mail:8 in 4.9 seconds, 40771 bytes. > Jul 24 09:00:00 beta spamd[2358]: spamd: result: . 0 - > ADVANCE_FEE_1,ALL_TRUSTED,HTML_MESSAGE,INFO_TLD > scantime=4.9,size=40771,user=mail,uid=8,required_score=5.0,rhost=beta.rg.co.id,raddr=127.0.0.1,rport=39352,mid=<200607220320.k6M3JtH9002594 at sigma.rbrana.co.id>,autolearn=failed I think that this is a spamassassin problem rather than a spamass-milter problem. Try having spamassassin write user preferences/bayes data to /var/spool/spamassassin instead of /var/spool/mail/.spamassassin. You may need to create /var/spool/spamassassin and run: # restorecon /var/spool/spamassassin I'm not sure what the exact configuration setting you need to adjust is; possibly add this to SPAMDOPTIONS in /etc/sysconfig/spamassassin: --virtual-config-dir=/var/spool/spamassassin You'd need to restart spamassassin for that to take effect. Paul. From dwalsh at redhat.com Mon Jul 24 11:18:11 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 24 Jul 2006 07:18:11 -0400 Subject: package review? In-Reply-To: <44C19F50.50408@kobold.org> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> <44C0F18F.5030108@city-fan.org> <44C19F50.50408@kobold.org> Message-ID: <44C4AC73.9050601@redhat.com> Wart wrote: > Paul Howarth wrote: > >> Wart wrote: >> >> >>> Daniel J Walsh wrote: >>> >>> >>>> allow crossfire_t port_t:udp_socket send_msg; >>>> allow crossfire_t port_t:tcp_socket name_bind; >>>> You need to define a port for this socket and only allow name_bind to >>>> that port >>>> >>> I know I'm missing something obvious here, but which macro can I use to >>> add this restriction? I saw references to http_port_t and ntp_port_t in >>> corenetwork.if, but didn't see anything that actually defined it to be >>> port 80 (http) or port 123 (ntp). >>> >> policy/modules/kernel/corenetwork.te.in: >> >> ... >> network_port(ntp, udp,123,s0) >> ... >> network_port(http, tcp,80,s0, tcp,443,s0, tcp,488,s0, tcp,8008,s0, >> tcp,8009,s0) >> > > Thanks. This is just what I needed. > > I could have sworn that this syntax was working for me earlier today, > but now I keep getting syntax errors on FC5: > > + make -f /usr/share/selinux/devel/Makefile > cat: /selinux/mls: No such file or directory > Compiling targeted crossfire module > crossfire.te:67:ERROR 'syntax error' at token 'network_port' on line 59707: > ## Networking basics (adjust to your needs!) > network_port(crossfire, tcp,13327,s0) > /usr/bin/checkmodule: error(s) encountered while parsing configuration > /usr/bin/checkmodule: loading policy configuration from tmp/crossfire.tmp > make: *** [tmp/crossfire.mod] Error 1 > > Is there something else that I need to include to be able to use > network_port()? > > This seems to be a bug in Reference policy. You are not allowed to define ports in loadable modules, at least that I can figure. I am in contact with upstream. This is a serious bug. > --Wart > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From paul at city-fan.org Mon Jul 24 12:01:13 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 24 Jul 2006 13:01:13 +0100 Subject: package review? In-Reply-To: <44C26280.2090903@kobold.org> References: <44BEA63B.7030105@kobold.org> <44C0F6D4.2060303@city-fan.org> <44C12A3F.3080503@kobold.org> <1153512696.30083.17.camel@laurel.intra.city-fan.org> <44C143A7.8070602@kobold.org> <1153569931.30083.28.camel@laurel.intra.city-fan.org> <44C26280.2090903@kobold.org> Message-ID: <44C4B689.1080808@city-fan.org> Wart wrote: > Paul Howarth wrote: >> Bear in mind that there should be a crossfire_disable_trans boolean that >> would turn off the policy (or rather the transition to crossfire_t) when >> set, without having to uninstall the policy. > > Is it enough to add the boolean to crossfire.te, or do I need to add > anything in the .if file as well? > > type crossfire_t; > type crossfire_exec_t; > domain_type(crossfire_t) > init_daemon_domain(crossfire_t, crossfire_exec_t) > bool crossfire_disable_trans; You shouldn't need to change anything; check the output of "getsebool -a" with your existing policy - you should already have the boolean, which should be defined because you used init_daemon_domain. Paul. From jbrindle at tresys.com Mon Jul 24 12:08:41 2006 From: jbrindle at tresys.com (Joshua Brindle) Date: Mon, 24 Jul 2006 08:08:41 -0400 Subject: package review? In-Reply-To: <44C4AC73.9050601@redhat.com> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> <44C0F18F.5030108@city-fan.org> <44C19F50.50408@kobold.org> <44C4AC73.9050601@redhat.com> Message-ID: <44C4B849.3080809@tresys.com> Daniel J Walsh wrote: > Wart wrote: >> Paul Howarth wrote: >> >>> Wart wrote: >>> >>> >>>> Daniel J Walsh wrote: >>>> >>>> >>>>> allow crossfire_t port_t:udp_socket send_msg; >>>>> allow crossfire_t port_t:tcp_socket name_bind; >>>>> You need to define a port for this socket and only allow name_bind to >>>>> that port >>>>> >>>> I know I'm missing something obvious here, but which macro can I >>>> use to >>>> add this restriction? I saw references to http_port_t and >>>> ntp_port_t in >>>> corenetwork.if, but didn't see anything that actually defined it to be >>>> port 80 (http) or port 123 (ntp). >>>> >>> policy/modules/kernel/corenetwork.te.in: >>> >>> ... >>> network_port(ntp, udp,123,s0) >>> ... >>> network_port(http, tcp,80,s0, tcp,443,s0, tcp,488,s0, tcp,8008,s0, >>> tcp,8009,s0) >>> >> >> Thanks. This is just what I needed. >> >> I could have sworn that this syntax was working for me earlier today, >> but now I keep getting syntax errors on FC5: >> >> + make -f /usr/share/selinux/devel/Makefile >> cat: /selinux/mls: No such file or directory >> Compiling targeted crossfire module >> crossfire.te:67:ERROR 'syntax error' at token 'network_port' on line >> 59707: >> ## Networking basics (adjust to your needs!) >> network_port(crossfire, tcp,13327,s0) >> /usr/bin/checkmodule: error(s) encountered while parsing configuration >> /usr/bin/checkmodule: loading policy configuration from >> tmp/crossfire.tmp >> make: *** [tmp/crossfire.mod] Error 1 >> >> Is there something else that I need to include to be able to use >> network_port()? >> >> > This seems to be a bug in Reference policy. You are not allowed to > define ports in loadable modules, at least that I can figure. > I am in contact with upstream. This is a serious bug. Eh, this is a limitation in the compiler, and a very intentional one at that. Since port ordering is important we chose not to allow them in the module language since a different linking order could result in a different result. Obviously refpolicy's solution to this is to include every port definition in corenetwork which is non-ideal in some ways but we also have semanage support for setting port contexts so I don't know that the module compiler should (or ever will) support this. From dwalsh at redhat.com Mon Jul 24 14:37:48 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 24 Jul 2006 10:37:48 -0400 Subject: package review? In-Reply-To: <44C4B849.3080809@tresys.com> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> <44C0F18F.5030108@city-fan.org> <44C19F50.50408@kobold.org> <44C4AC73.9050601@redhat.com> <44C4B849.3080809@tresys.com> Message-ID: <44C4DB3C.60608@redhat.com> Joshua Brindle wrote: > Daniel J Walsh wrote: >> Wart wrote: >>> Paul Howarth wrote: >>> >>>> Wart wrote: >>>> >>>> >>>>> Daniel J Walsh wrote: >>>>> >>>>> >>>>>> allow crossfire_t port_t:udp_socket send_msg; >>>>>> allow crossfire_t port_t:tcp_socket name_bind; >>>>>> You need to define a port for this socket and only allow >>>>>> name_bind to >>>>>> that port >>>>>> >>>>> I know I'm missing something obvious here, but which macro can I >>>>> use to >>>>> add this restriction? I saw references to http_port_t and >>>>> ntp_port_t in >>>>> corenetwork.if, but didn't see anything that actually defined it >>>>> to be >>>>> port 80 (http) or port 123 (ntp). >>>>> >>>> policy/modules/kernel/corenetwork.te.in: >>>> >>>> ... >>>> network_port(ntp, udp,123,s0) >>>> ... >>>> network_port(http, tcp,80,s0, tcp,443,s0, tcp,488,s0, tcp,8008,s0, >>>> tcp,8009,s0) >>>> >>> >>> Thanks. This is just what I needed. >>> >>> I could have sworn that this syntax was working for me earlier today, >>> but now I keep getting syntax errors on FC5: >>> >>> + make -f /usr/share/selinux/devel/Makefile >>> cat: /selinux/mls: No such file or directory >>> Compiling targeted crossfire module >>> crossfire.te:67:ERROR 'syntax error' at token 'network_port' on line >>> 59707: >>> ## Networking basics (adjust to your needs!) >>> network_port(crossfire, tcp,13327,s0) >>> /usr/bin/checkmodule: error(s) encountered while parsing configuration >>> /usr/bin/checkmodule: loading policy configuration from >>> tmp/crossfire.tmp >>> make: *** [tmp/crossfire.mod] Error 1 >>> >>> Is there something else that I need to include to be able to use >>> network_port()? >>> >>> >> This seems to be a bug in Reference policy. You are not allowed to >> define ports in loadable modules, at least that I can figure. >> I am in contact with upstream. This is a serious bug. > > Eh, this is a limitation in the compiler, and a very intentional one > at that. Since port ordering is important we chose not to allow them > in the module language since a different linking order could result in > a different result. > > Obviously refpolicy's solution to this is to include every port > definition in corenetwork which is non-ideal in some ways but we also > have semanage support for setting port contexts so I don't know that > the module compiler should (or ever will) support this. So the solution would be to add code like the following? gen_requires(` attribute port_type; ') type crossfire_port_t, port_type; allow crossfire_t crossfire_port_t:udp_socket send_msg; allow crossfire_t crossfire_port_t:tcp_socket name_bind; And in your install after the policy load semanage port -a -t crossfire_port_t -p tcp MYPORTNUM semanage port -a -t crossfire_port_t -p udp MYPORTNUM From jbrindle at tresys.com Mon Jul 24 14:41:34 2006 From: jbrindle at tresys.com (Joshua Brindle) Date: Mon, 24 Jul 2006 10:41:34 -0400 Subject: package review? In-Reply-To: <44C4DB3C.60608@redhat.com> Message-ID: <6FE441CD9F0C0C479F2D88F959B01588298C4C@exchange.columbia.tresys.com> > From: Daniel J Walsh [mailto:dwalsh at redhat.com] > > gen_requires(` > attribute port_type; > ') > > type crossfire_port_t, port_type; > > allow crossfire_t crossfire_port_t:udp_socket send_msg; allow > crossfire_t crossfire_port_t:tcp_socket name_bind; > > > > And in your install after the policy load > > semanage port -a -t crossfire_port_t -p tcp MYPORTNUM > semanage port -a -t crossfire_port_t -p udp MYPORTNUM > This looks fine to me. If we start doing this the rpm spec file should probably do it and should undo it on uninstall since the link will fail if the module is removed without these rules being removed. From Valdis.Kletnieks at vt.edu Mon Jul 24 15:47:47 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 24 Jul 2006 11:47:47 -0400 Subject: package review? In-Reply-To: Your message of "Mon, 24 Jul 2006 10:41:34 EDT." <6FE441CD9F0C0C479F2D88F959B01588298C4C@exchange.columbia.tresys.com> References: <6FE441CD9F0C0C479F2D88F959B01588298C4C@exchange.columbia.tresys.com> Message-ID: <200607241547.k6OFll95008546@turing-police.cc.vt.edu> On Mon, 24 Jul 2006 10:41:34 EDT, Joshua Brindle said: > > From: Daniel J Walsh [mailto:dwalsh at redhat.com] > > And in your install after the policy load > > > > semanage port -a -t crossfire_port_t -p tcp MYPORTNUM > > semanage port -a -t crossfire_port_t -p udp MYPORTNUM > > > > This looks fine to me. If we start doing this the rpm spec file should > probably do it and should undo it on uninstall since the link will fail > if the module is removed without these rules being removed. I'm an RPM idiot - will this still DTRT if another RPM package does an 'Obsoletes:' on this one? (ie. after all the 'port -a' and 'port -d', we'll end up with one defined if needed?) and if the RPM is force-installed a second time? (I've had more than one RPM that bombed in a post-install scriptlet because of trying to useradd an existing userid, etc...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From paul at city-fan.org Mon Jul 24 16:23:11 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 24 Jul 2006 17:23:11 +0100 Subject: package review? In-Reply-To: <200607241547.k6OFll95008546@turing-police.cc.vt.edu> References: <6FE441CD9F0C0C479F2D88F959B01588298C4C@exchange.columbia.tresys.com> <200607241547.k6OFll95008546@turing-police.cc.vt.edu> Message-ID: <44C4F3EF.1010406@city-fan.org> Valdis.Kletnieks at vt.edu wrote: > On Mon, 24 Jul 2006 10:41:34 EDT, Joshua Brindle said: >>> From: Daniel J Walsh [mailto:dwalsh at redhat.com] > >>> And in your install after the policy load >>> >>> semanage port -a -t crossfire_port_t -p tcp MYPORTNUM >>> semanage port -a -t crossfire_port_t -p udp MYPORTNUM >>> >> This looks fine to me. If we start doing this the rpm spec file should >> probably do it and should undo it on uninstall since the link will fail >> if the module is removed without these rules being removed. > > I'm an RPM idiot - will this still DTRT if another RPM package does > an 'Obsoletes:' on this one? Yes. This package would get uninstalled, and the pre/post uninstall scriptlet should remove the port definitions when the package is removed. However, the big problem with using semanage in scriptlets is that future versions of packages have to remember and be able to cope with anything that had ever been added using semanage in any previous version of the package. If file contexts or port numbers change over time, this could be a major hassle. Being able to do it in a policy module would be *much* better because the version numbering inherent in the modules would take care of updating and removing old rules. There would also be the problem of what do do when someone manually added another port of type crossfire_port_t outside of rpm. > (ie. after all the 'port -a' and 'port -d', > we'll end up with one defined if needed?) and if the RPM is force-installed > a second time? I have no sympathy for people force-installing things. In this case, I don't think it would break anything though, so long as the uninstall scriptlet was properly checking its parameters to ensure that it was an uninstall and not a package update. > (I've had more than one RPM that bombed in a post-install > scriptlet because of trying to useradd an existing userid, etc...) That would be a packaging bug; great care should be taken to avoid scriptlets returning non-zero exit codes and causing transaction failures. Paul. From dwalsh at redhat.com Mon Jul 24 17:08:10 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 24 Jul 2006 13:08:10 -0400 Subject: problems with latest mls policy In-Reply-To: <18054BCE-FBFA-4564-A662-993ADC14BBBC@sf-net.com> References: <18054BCE-FBFA-4564-A662-993ADC14BBBC@sf-net.com> Message-ID: <44C4FE7A.2080802@redhat.com> Stefan wrote: > Hi, > > since an update of the mls came out I have a problem loading a policy > which worked correctly before the update. > > [data.te] > policy_module(data,1.0.2) > > gen_require(` > type user_t, staff_t, smbd_t, snmpd_t; > ') > > type data_t; > files_type(data_t); > > allow user_t data_t:dir { getattr read }; > allow user_t data_t:file { getattr read }; > allow staff_t data_t:dir { create rmdir rw_dir_perms setattr }; > allow staff_t data_t:file { create rename rw_file_perms setattr unlink }; > allow staff_t data_t:lnk_file { create rw_file_perms }; > > allow smbd_t data_t:dir { add_name create getattr read remove_name > rename rmdir search setattr write }; > allow smbd_t data_t:file { create getattr lock read rename setattr > unlink write }; > > allow snmpd_t data_t:dir getattr; > > [data.fc] > /data(/.*)? gen_context(system_u:object_r:data_t,s0) > > When I try to load the module (semodule -i data.pp) I get the > following error message: > libsepol.permission_copy_callback: Module data depends on permission > setkeycreate in class process, not satisfied > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! > Did you recompile your policy package? > I don't know what the error has to say. Any suggestions? > > ciao, Stefan > > PS: rpm -qa selinux-policy-mls > selinux-policy-mls-2.3.2-1.fc5 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From stefan at sf-net.com Mon Jul 24 18:09:36 2006 From: stefan at sf-net.com (Stefan) Date: Mon, 24 Jul 2006 20:09:36 +0200 Subject: problems with latest mls policy In-Reply-To: <44C4FE7A.2080802@redhat.com> References: <18054BCE-FBFA-4564-A662-993ADC14BBBC@sf-net.com> <44C4FE7A.2080802@redhat.com> Message-ID: <3B1B6E9B-4B54-4620-B197-3D5DE362AACC@sf-net.com> > Did you recompile your policy package? No, BUT I reinstalled the package and now everything wents fine. Sometimes the yum daemon runs into some trouble when an update comes out a lot of avc denials will be shown. So I guess the problem was a bad update. ciao, Stefan From wart at kobold.org Tue Jul 25 00:01:33 2006 From: wart at kobold.org (Michael Thomas) Date: Mon, 24 Jul 2006 17:01:33 -0700 Subject: package review? In-Reply-To: <44C4DB3C.60608@redhat.com> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> <44C0F18F.5030108@city-fan.org> <44C19F50.50408@kobold.org> <44C4AC73.9050601@redhat.com> <44C4B849.3080809@tresys.com> <44C4DB3C.60608@redhat.com> Message-ID: <44C55F5D.5060808@kobold.org> Daniel J Walsh wrote: > Joshua Brindle wrote: >> Eh, this is a limitation in the compiler, and a very intentional one >> at that. Since port ordering is important we chose not to allow them >> in the module language since a different linking order could result in >> a different result. >> >> Obviously refpolicy's solution to this is to include every port >> definition in corenetwork which is non-ideal in some ways but we also >> have semanage support for setting port contexts so I don't know that >> the module compiler should (or ever will) support this. > > So the solution would be to add code like the following? > > gen_requires(` > attribute port_type; > ') This gen_requires() generates a syntax error in my .te file. I had to change it to a simple require(): require { type port_t; attribute port_type; }; > type crossfire_port_t, port_type; > > allow crossfire_t crossfire_port_t:udp_socket send_msg; > allow crossfire_t crossfire_port_t:tcp_socket name_bind; > > > > And in your install after the policy load > > semanage port -a -t crossfire_port_t -p tcp MYPORTNUM > semanage port -a -t crossfire_port_t -p udp MYPORTNUM I did this, but doesn't seem to fail when it ought to. To test, I installed the package and then used semanage to change the port definition for crossfire_port_t: # semanage port -l | grep crossfire crossfire_port_t tcp 13327 # semanage port -d -t crossfire_port_t -p tcp 13327 # semanage port -a -t crossfire_port_t -p tcp 13328 # semanage port -l | grep crossfire crossfire_port_t tcp 13328 But when I start up the service, it is still able to bind to port 13327 with no errors. I can even telnet to that port with no problem. I did verify that the service is running as user_u:system_r:crossfire_t. I had expected to see an avc: denied error when the service attempted to bind to the port. Is there some other step that I missed, or perhaps something else in my .te file that is giving it permission? The new policy and package files are available here: http://www.kobold.org/~wart/fedora/crossfire.te http://www.kobold.org/~wart/fedora/crossfire.if http://www.kobold.org/~wart/fedora/crossfire.fc http://www.kobold.org/~wart/fedora/crossfire.spec http://www.kobold.org/~wart/fedora/crossfire-1.9.1-1.2.src.rpm --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From paul at city-fan.org Tue Jul 25 06:23:16 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 25 Jul 2006 07:23:16 +0100 Subject: package review? In-Reply-To: <44C55F5D.5060808@kobold.org> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> <44C0F18F.5030108@city-fan.org> <44C19F50.50408@kobold.org> <44C4AC73.9050601@redhat.com> <44C4B849.3080809@tresys.com> <44C4DB3C.60608@redhat.com> <44C55F5D.5060808@kobold.org> Message-ID: <1153808597.24197.0.camel@laurel.intra.city-fan.org> On Mon, 2006-07-24 at 17:01 -0700, Michael Thomas wrote: > Daniel J Walsh wrote: > > Joshua Brindle wrote: > >> Eh, this is a limitation in the compiler, and a very intentional one > >> at that. Since port ordering is important we chose not to allow them > >> in the module language since a different linking order could result in > >> a different result. > >> > >> Obviously refpolicy's solution to this is to include every port > >> definition in corenetwork which is non-ideal in some ways but we also > >> have semanage support for setting port contexts so I don't know that > >> the module compiler should (or ever will) support this. > > > > So the solution would be to add code like the following? > > > > gen_requires(` > > attribute port_type; > > ') > > This gen_requires() generates a syntax error in my .te file. I had to > change it to a simple require(): > > require { > type port_t; > attribute port_type; > }; > > > > type crossfire_port_t, port_type; > > > > allow crossfire_t crossfire_port_t:udp_socket send_msg; > > allow crossfire_t crossfire_port_t:tcp_socket name_bind; > > > > > > > > And in your install after the policy load > > > > semanage port -a -t crossfire_port_t -p tcp MYPORTNUM > > semanage port -a -t crossfire_port_t -p udp MYPORTNUM > > I did this, but doesn't seem to fail when it ought to. To test, I > installed the package and then used semanage to change the port > definition for crossfire_port_t: > > # semanage port -l | grep crossfire > crossfire_port_t tcp 13327 > # semanage port -d -t crossfire_port_t -p tcp 13327 > # semanage port -a -t crossfire_port_t -p tcp 13328 > # semanage port -l | grep crossfire > crossfire_port_t tcp 13328 > > But when I start up the service, it is still able to bind to port 13327 > with no errors. I can even telnet to that port with no problem. I did > verify that the service is running as user_u:system_r:crossfire_t. I > had expected to see an avc: denied error when the service attempted to > bind to the port. Is there some other step that I missed, or perhaps > something else in my .te file that is giving it permission? corenet_tcp_bind_all_ports(crossfire_t) corenet_tcp_sendrecv_all_ports(crossfire_t) Paul. From paul at city-fan.org Tue Jul 25 09:14:59 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 25 Jul 2006 10:14:59 +0100 Subject: Directories for policy module packages Message-ID: <44C5E113.6070601@city-fan.org> Now that RPM packages are starting to include policy module packages (my mod_fcgid package was approved for Extras recently: http://bugzilla.redhat.com/195666), it would be nice to have a standard place for the .pp files to be dropped, and for that directory to be owned by the selinux-policy package (so that all the packages don't need to own it themselves). I propose the following: /usr/share/selinux/packages (container directory, separate from modules bundled with Core package) /usr/share/selinux/packages/mls (policy modules for use with the mls base policy) /usr/share/selinux/packages/strict (policy modules for use with the strict base policy) /usr/share/selinux/packages/targeted (policy modules for use with the targeted base policy) /usr/share/selinux/packages/share (policy modules that have no base-specific elements, and can be used with all base policies) Paul. From dwalsh at redhat.com Tue Jul 25 12:40:35 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 25 Jul 2006 08:40:35 -0400 Subject: package review? In-Reply-To: <44C55F5D.5060808@kobold.org> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> <44C0F18F.5030108@city-fan.org> <44C19F50.50408@kobold.org> <44C4AC73.9050601@redhat.com> <44C4B849.3080809@tresys.com> <44C4DB3C.60608@redhat.com> <44C55F5D.5060808@kobold.org> Message-ID: <44C61143.3050703@redhat.com> Michael Thomas wrote: > Daniel J Walsh wrote: > >> Joshua Brindle wrote: >> >>> Eh, this is a limitation in the compiler, and a very intentional one >>> at that. Since port ordering is important we chose not to allow them >>> in the module language since a different linking order could result in >>> a different result. >>> >>> Obviously refpolicy's solution to this is to include every port >>> definition in corenetwork which is non-ideal in some ways but we also >>> have semanage support for setting port contexts so I don't know that >>> the module compiler should (or ever will) support this. >>> >> So the solution would be to add code like the following? >> >> gen_requires(` >> attribute port_type; >> ') >> > > This gen_requires() generates a syntax error in my .te file. I had to > change it to a simple require(): > > require { > type port_t; > attribute port_type; > }; > > > Should be gen_require(). > >> type crossfire_port_t, port_type; >> >> allow crossfire_t crossfire_port_t:udp_socket send_msg; >> allow crossfire_t crossfire_port_t:tcp_socket name_bind; >> >> >> >> And in your install after the policy load >> >> semanage port -a -t crossfire_port_t -p tcp MYPORTNUM >> semanage port -a -t crossfire_port_t -p udp MYPORTNUM >> > > I did this, but doesn't seem to fail when it ought to. To test, I > installed the package and then used semanage to change the port > definition for crossfire_port_t: > > # semanage port -l | grep crossfire > crossfire_port_t tcp 13327 > # semanage port -d -t crossfire_port_t -p tcp 13327 > # semanage port -a -t crossfire_port_t -p tcp 13328 > # semanage port -l | grep crossfire > crossfire_port_t tcp 13328 > > But when I start up the service, it is still able to bind to port 13327 > with no errors. I can even telnet to that port with no problem. I did > verify that the service is running as user_u:system_r:crossfire_t. I > had expected to see an avc: denied error when the service attempted to > bind to the port. Is there some other step that I missed, or perhaps > something else in my .te file that is giving it permission? > > The new policy and package files are available here: > > http://www.kobold.org/~wart/fedora/crossfire.te > http://www.kobold.org/~wart/fedora/crossfire.if > http://www.kobold.org/~wart/fedora/crossfire.fc > http://www.kobold.org/~wart/fedora/crossfire.spec > http://www.kobold.org/~wart/fedora/crossfire-1.9.1-1.2.src.rpm > > --Mike > From cpebenito at tresys.com Tue Jul 25 13:08:46 2006 From: cpebenito at tresys.com (Christopher J. PeBenito) Date: Tue, 25 Jul 2006 09:08:46 -0400 Subject: Directories for policy module packages In-Reply-To: <44C5E113.6070601@city-fan.org> References: <44C5E113.6070601@city-fan.org> Message-ID: <1153832927.10011.3.camel@sgc> On Tue, 2006-07-25 at 10:14 +0100, Paul Howarth wrote: > Now that RPM packages are starting to include policy module packages (my > mod_fcgid package was approved for Extras recently: > http://bugzilla.redhat.com/195666), it would be nice to have a standard > place for the .pp files to be dropped, and for that directory to be > owned by the selinux-policy package (so that all the packages don't need > to own it themselves). > > I propose the following: > > /usr/share/selinux/packages > (container directory, separate from modules bundled with Core package) > > /usr/share/selinux/packages/mls > (policy modules for use with the mls base policy) > > /usr/share/selinux/packages/strict > (policy modules for use with the strict base policy) > > /usr/share/selinux/packages/targeted > (policy modules for use with the targeted base policy) > > /usr/share/selinux/packages/share > (policy modules that have no base-specific elements, and can be used > with all base policies) There already is a standard location: /usr/share/selinux/NAME/ where NAME is targeted, strict, mls, etc. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 From paul at city-fan.org Tue Jul 25 13:22:29 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 25 Jul 2006 14:22:29 +0100 Subject: Directories for policy module packages In-Reply-To: <1153832927.10011.3.camel@sgc> References: <44C5E113.6070601@city-fan.org> <1153832927.10011.3.camel@sgc> Message-ID: <44C61B15.2000503@city-fan.org> Christopher J. PeBenito wrote: > On Tue, 2006-07-25 at 10:14 +0100, Paul Howarth wrote: >> Now that RPM packages are starting to include policy module packages (my >> mod_fcgid package was approved for Extras recently: >> http://bugzilla.redhat.com/195666), it would be nice to have a standard >> place for the .pp files to be dropped, and for that directory to be >> owned by the selinux-policy package (so that all the packages don't need >> to own it themselves). >> >> I propose the following: >> >> /usr/share/selinux/packages >> (container directory, separate from modules bundled with Core package) >> >> /usr/share/selinux/packages/mls >> (policy modules for use with the mls base policy) >> >> /usr/share/selinux/packages/strict >> (policy modules for use with the strict base policy) >> >> /usr/share/selinux/packages/targeted >> (policy modules for use with the targeted base policy) >> >> /usr/share/selinux/packages/share >> (policy modules that have no base-specific elements, and can be used >> with all base policies) > > There already is a standard location: > > /usr/share/selinux/NAME/ > > where NAME is targeted, strict, mls, etc. I asked about this before and it was suggested that /usr/share/selinux/NAME would best be avoided because Core/base packages would install modules there and there might be name comflicts. I'm not convinced by that argument myself, but: * /usr/share/selinux/NAME/ is owned by selinux-policy-NAME; since most systems will have only targeted policy installed, this is an issue for packages wanting to include modules built for all base policies, which will have no directories to install strict/mls modules to. There is also no /usr/share/selinux/share directory to install policy module packages common to all base policies. I think wherever the directory is, it needs to be owned by the selinux-policy package itself and not the subpackages. Paul. From selinux at gmail.com Tue Jul 25 14:09:38 2006 From: selinux at gmail.com (Tom London) Date: Tue, 25 Jul 2006 07:09:38 -0700 Subject: setroubshoot...neat popup! Message-ID: <4c4ba1530607250709r5bf54981md165fb12bbe3867d@mail.gmail.com> Wow... Got neat popup and icon in notification area! Cool. Message may be a bit misleading, though. The following yielded a message about not being able to load a new policy, and that I should change secure_mode_policyload to 0 (it already is). Messages generated during yumex update of today's packages. tom type=AVC msg=audit(1153835929.352:30): avc: granted { load_policy } for pid=3362 comm="load_policy" scontext=system_u:system_r:load_policy_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security type=MAC_POLICY_LOAD msg=audit(1153835929.352:30): policy loaded auid=500 type=SYSCALL msg=audit(1153835929.352:30): arch=40000003 syscall=4 success=yes exit=892854 a0=4 a1=b7e16000 a2=d9fb6 a3=bfc9fe48 items=0 ppid=3361 pid=3362 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="load_policy" exe="/usr/sbin/load_policy" subj=system_u:system_r:load_policy_t:s0 key=(null) type=AVC msg=audit(1153835929.528:31): avc: denied { dac_override } for pid=1947 comm="python" capability=1 scontext=system_u:system_r:setroubleshoot_t:s0 tcontext=system_u:system_r:setroubleshoot_t:s0 tclass=capability type=SYSCALL msg=audit(1153835929.528:31): arch=40000003 syscall=33 success=no exit=-13 a0=9aa1848 a1=2 a2=966a64 a3=0 items=1 ppid=1886 pid=1947 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="python" exe="/usr/bin/python" subj=system_u:system_r:setroubleshoot_t:s0 key=(null) type=CWD msg=audit(1153835929.528:31): cwd="/" type=PATH msg=audit(1153835929.528:31): item=0 name="/var/lib/rpm" inode=2785283 dev=fd:00 mode=040755 ouid=37 ogid=37 rdev=00:00 obj=system_u:object_r:rpm_var_lib_t:s0 type=AVC msg=audit(1153835929.532:32): avc: denied { dac_override } for pid=1947 comm="python" capability=1 scontext=system_u:system_r:setroubleshoot_t:s0 tcontext=system_u:system_r:setroubleshoot_t:s0 tclass=capability type=SYSCALL msg=audit(1153835929.532:32): arch=40000003 syscall=33 success=no exit=-13 a0=9ad4a38 a1=2 a2=966a64 a3=0 items=1 ppid=1886 pid=1947 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="python" exe="/usr/bin/python" subj=system_u:system_r:setroubleshoot_t:s0 key=(null) type=CWD msg=audit(1153835929.532:32): cwd="/" type=PATH msg=audit(1153835929.532:32): item=0 name="/var/lib/rpm" inode=2785283 dev=fd:00 mode=040755 ouid=37 ogid=37 rdev=00:00 obj=system_u:object_r:rpm_var_lib_t:s0 type=AVC msg=audit(1153835929.540:33): avc: granted { load_policy } for pid=3362 comm="load_policy" scontext=system_u:system_r:load_policy_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security type=SYSCALL msg=audit(1153835929.540:33): arch=40000003 syscall=4 success=yes exit=2 a0=4 a1=bfca0f16 a2=2 a3=0 items=0 ppid=3361 pid=3362 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="load_policy" exe="/usr/sbin/load_policy" subj=system_u:system_r:load_policy_t:s0 key=(null) type=AVC msg=audit(1153835931.544:34): avc: denied { dac_override } for pid=1947 comm="python" capability=1 scontext=system_u:system_r:setroubleshoot_t:s0 tcontext=system_u:system_r:setroubleshoot_t:s0 tclass=capability type=SYSCALL msg=audit(1153835931.544:34): arch=40000003 syscall=33 success=no exit=-13 a0=9aa5470 a1=2 a2=966a64 a3=0 items=1 ppid=1886 pid=1947 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="python" exe="/usr/bin/python" subj=system_u:system_r:setroubleshoot_t:s0 key=(null) type=CWD msg=audit(1153835931.544:34): cwd="/" type=PATH msg=audit(1153835931.544:34): item=0 name="/var/lib/rpm" inode=2785283 dev=fd:00 mode=040755 ouid=37 ogid=37 rdev=00:00 obj=system_u:object_r:rpm_var_lib_t:s0 type=AVC msg=audit(1153835931.544:35): avc: denied { dac_override } for pid=1947 comm="python" capability=1 scontext=system_u:system_r:setroubleshoot_t:s0 tcontext=system_u:system_r:setroubleshoot_t:s0 tclass=capability type=SYSCALL msg=audit(1153835931.544:35): arch=40000003 syscall=33 success=no exit=-13 a0=9a91000 a1=2 a2=966a64 a3=0 items=1 ppid=1886 pid=1947 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="python" exe="/usr/bin/python" subj=system_u:system_r:setroubleshoot_t:s0 key=(null) type=CWD msg=audit(1153835931.544:35): cwd="/" type=PATH msg=audit(1153835931.544:35): item=0 name="/var/lib/rpm" inode=2785283 dev=fd:00 mode=040755 ouid=37 ogid=37 rdev=00:00 obj=system_u:object_r:rpm_var_lib_t:s0 type=AVC msg=audit(1153835931.552:36): avc: denied { dac_override } for pid=1947 comm="python" capability=1 scontext=system_u:system_r:setroubleshoot_t:s0 tcontext=system_u:system_r:setroubleshoot_t:s0 tclass=capability type=SYSCALL msg=audit(1153835931.552:36): arch=40000003 syscall=33 success=no exit=-13 a0=9aa14d0 a1=2 a2=966a64 a3=0 items=1 ppid=1886 pid=1947 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="python" exe="/usr/bin/python" subj=system_u:system_r:setroubleshoot_t:s0 key=(null) type=CWD msg=audit(1153835931.552:36): cwd="/" type=PATH msg=audit(1153835931.552:36): item=0 name="/var/lib/rpm" inode=2785283 dev=fd:00 mode=040755 ouid=37 ogid=37 rdev=00:00 obj=system_u:object_r:rpm_var_lib_t:s0 type=AVC msg=audit(1153835931.552:37): avc: denied { dac_override } for pid=1947 comm="python" capability=1 scontext=system_u:system_r:setroubleshoot_t:s0 tcontext=system_u:system_r:setroubleshoot_t:s0 tclass=capability type=SYSCALL msg=audit(1153835931.552:37): arch=40000003 syscall=33 success=no exit=-13 a0=9aea538 a1=2 a2=966a64 a3=0 items=1 ppid=1886 pid=1947 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="python" exe="/usr/bin/python" subj=system_u:system_r:setroubleshoot_t:s0 key=(null) type=CWD msg=audit(1153835931.552:37): cwd="/" type=PATH msg=audit(1153835931.552:37): item=0 name="/var/lib/rpm" inode=2785283 dev=fd:00 mode=040755 ouid=37 ogid=37 rdev=00:00 obj=system_u:object_r:rpm_var_lib_t:s0 -- Tom London From selinux at gmail.com Tue Jul 25 14:15:21 2006 From: selinux at gmail.com (Tom London) Date: Tue, 25 Jul 2006 07:15:21 -0700 Subject: setroubshoot...neat popup! In-Reply-To: <4c4ba1530607250709r5bf54981md165fb12bbe3867d@mail.gmail.com> References: <4c4ba1530607250709r5bf54981md165fb12bbe3867d@mail.gmail.com> Message-ID: <4c4ba1530607250715l625ce733i947b36d75dc6698b@mail.gmail.com> Attaching setroubleshoot.log tom -------------- next part -------------- A non-text attachment was scrubbed... Name: selog Type: application/octet-stream Size: 26907 bytes Desc: not available URL: From dwalsh at redhat.com Tue Jul 25 15:17:54 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 25 Jul 2006 11:17:54 -0400 Subject: setroubshoot...neat popup! In-Reply-To: <4c4ba1530607250709r5bf54981md165fb12bbe3867d@mail.gmail.com> References: <4c4ba1530607250709r5bf54981md165fb12bbe3867d@mail.gmail.com> Message-ID: <44C63622.6070204@redhat.com> Tom London wrote: > Wow... Got neat popup and icon in notification area! Cool. > Thanks we are still working out the rough edges. I will be blogging on this tool later today or tomorrow. > Message may be a bit misleading, though. The following yielded a > message about not being able to load a new policy, and that I should > change secure_mode_policyload to 0 (it already is). Yes this is a bug, it should be looking for the granted versus denied... :^( > > Messages generated during yumex update of today's packages. > > tom > > type=AVC msg=audit(1153835929.352:30): avc: granted { load_policy } > for pid=3362 comm="load_policy" > scontext=system_u:system_r:load_policy_t:s0 > tcontext=system_u:object_r:security_t:s0 tclass=security > type=MAC_POLICY_LOAD msg=audit(1153835929.352:30): policy loaded auid=500 > type=SYSCALL msg=audit(1153835929.352:30): arch=40000003 syscall=4 > success=yes exit=892854 a0=4 a1=b7e16000 a2=d9fb6 a3=bfc9fe48 items=0 > ppid=3361 pid=3362 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 comm="load_policy" exe="/usr/sbin/load_policy" > subj=system_u:system_r:load_policy_t:s0 key=(null) > type=AVC msg=audit(1153835929.528:31): avc: denied { dac_override } > for pid=1947 comm="python" capability=1 > scontext=system_u:system_r:setroubleshoot_t:s0 > tcontext=system_u:system_r:setroubleshoot_t:s0 tclass=capability > type=SYSCALL msg=audit(1153835929.528:31): arch=40000003 syscall=33 > success=no exit=-13 a0=9aa1848 a1=2 a2=966a64 a3=0 items=1 ppid=1886 > pid=1947 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=(none) comm="python" exe="/usr/bin/python" > subj=system_u:system_r:setroubleshoot_t:s0 key=(null) > type=CWD msg=audit(1153835929.528:31): cwd="/" > type=PATH msg=audit(1153835929.528:31): item=0 name="/var/lib/rpm" > inode=2785283 dev=fd:00 mode=040755 ouid=37 ogid=37 rdev=00:00 > obj=system_u:object_r:rpm_var_lib_t:s0 > type=AVC msg=audit(1153835929.532:32): avc: denied { dac_override } > for pid=1947 comm="python" capability=1 > scontext=system_u:system_r:setroubleshoot_t:s0 > tcontext=system_u:system_r:setroubleshoot_t:s0 tclass=capability > type=SYSCALL msg=audit(1153835929.532:32): arch=40000003 syscall=33 > success=no exit=-13 a0=9ad4a38 a1=2 a2=966a64 a3=0 items=1 ppid=1886 > pid=1947 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=(none) comm="python" exe="/usr/bin/python" > subj=system_u:system_r:setroubleshoot_t:s0 key=(null) > type=CWD msg=audit(1153835929.532:32): cwd="/" > type=PATH msg=audit(1153835929.532:32): item=0 name="/var/lib/rpm" > inode=2785283 dev=fd:00 mode=040755 ouid=37 ogid=37 rdev=00:00 > obj=system_u:object_r:rpm_var_lib_t:s0 > type=AVC msg=audit(1153835929.540:33): avc: granted { load_policy } > for pid=3362 comm="load_policy" > scontext=system_u:system_r:load_policy_t:s0 > tcontext=system_u:object_r:security_t:s0 tclass=security > type=SYSCALL msg=audit(1153835929.540:33): arch=40000003 syscall=4 > success=yes exit=2 a0=4 a1=bfca0f16 a2=2 a3=0 items=0 ppid=3361 > pid=3362 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=pts0 comm="load_policy" exe="/usr/sbin/load_policy" > subj=system_u:system_r:load_policy_t:s0 key=(null) > type=AVC msg=audit(1153835931.544:34): avc: denied { dac_override } > for pid=1947 comm="python" capability=1 > scontext=system_u:system_r:setroubleshoot_t:s0 > tcontext=system_u:system_r:setroubleshoot_t:s0 tclass=capability > type=SYSCALL msg=audit(1153835931.544:34): arch=40000003 syscall=33 > success=no exit=-13 a0=9aa5470 a1=2 a2=966a64 a3=0 items=1 ppid=1886 > pid=1947 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=(none) comm="python" exe="/usr/bin/python" > subj=system_u:system_r:setroubleshoot_t:s0 key=(null) > type=CWD msg=audit(1153835931.544:34): cwd="/" > type=PATH msg=audit(1153835931.544:34): item=0 name="/var/lib/rpm" > inode=2785283 dev=fd:00 mode=040755 ouid=37 ogid=37 rdev=00:00 > obj=system_u:object_r:rpm_var_lib_t:s0 > type=AVC msg=audit(1153835931.544:35): avc: denied { dac_override } > for pid=1947 comm="python" capability=1 > scontext=system_u:system_r:setroubleshoot_t:s0 > tcontext=system_u:system_r:setroubleshoot_t:s0 tclass=capability > type=SYSCALL msg=audit(1153835931.544:35): arch=40000003 syscall=33 > success=no exit=-13 a0=9a91000 a1=2 a2=966a64 a3=0 items=1 ppid=1886 > pid=1947 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=(none) comm="python" exe="/usr/bin/python" > subj=system_u:system_r:setroubleshoot_t:s0 key=(null) > type=CWD msg=audit(1153835931.544:35): cwd="/" > type=PATH msg=audit(1153835931.544:35): item=0 name="/var/lib/rpm" > inode=2785283 dev=fd:00 mode=040755 ouid=37 ogid=37 rdev=00:00 > obj=system_u:object_r:rpm_var_lib_t:s0 > type=AVC msg=audit(1153835931.552:36): avc: denied { dac_override } > for pid=1947 comm="python" capability=1 > scontext=system_u:system_r:setroubleshoot_t:s0 > tcontext=system_u:system_r:setroubleshoot_t:s0 tclass=capability > type=SYSCALL msg=audit(1153835931.552:36): arch=40000003 syscall=33 > success=no exit=-13 a0=9aa14d0 a1=2 a2=966a64 a3=0 items=1 ppid=1886 > pid=1947 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=(none) comm="python" exe="/usr/bin/python" > subj=system_u:system_r:setroubleshoot_t:s0 key=(null) > type=CWD msg=audit(1153835931.552:36): cwd="/" > type=PATH msg=audit(1153835931.552:36): item=0 name="/var/lib/rpm" > inode=2785283 dev=fd:00 mode=040755 ouid=37 ogid=37 rdev=00:00 > obj=system_u:object_r:rpm_var_lib_t:s0 > type=AVC msg=audit(1153835931.552:37): avc: denied { dac_override } > for pid=1947 comm="python" capability=1 > scontext=system_u:system_r:setroubleshoot_t:s0 > tcontext=system_u:system_r:setroubleshoot_t:s0 tclass=capability > type=SYSCALL msg=audit(1153835931.552:37): arch=40000003 syscall=33 > success=no exit=-13 a0=9aea538 a1=2 a2=966a64 a3=0 items=1 ppid=1886 > pid=1947 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=(none) comm="python" exe="/usr/bin/python" > subj=system_u:system_r:setroubleshoot_t:s0 key=(null) > type=CWD msg=audit(1153835931.552:37): cwd="/" > type=PATH msg=audit(1153835931.552:37): item=0 name="/var/lib/rpm" > inode=2785283 dev=fd:00 mode=040755 ouid=37 ogid=37 rdev=00:00 > obj=system_u:object_r:rpm_var_lib_t:s0 > > > From dwalsh at redhat.com Tue Jul 25 16:04:20 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 25 Jul 2006 12:04:20 -0400 Subject: Directories for policy module packages In-Reply-To: <44C61B15.2000503@city-fan.org> References: <44C5E113.6070601@city-fan.org> <1153832927.10011.3.camel@sgc> <44C61B15.2000503@city-fan.org> Message-ID: <44C64104.20206@redhat.com> Paul Howarth wrote: > Christopher J. PeBenito wrote: >> On Tue, 2006-07-25 at 10:14 +0100, Paul Howarth wrote: >>> Now that RPM packages are starting to include policy module packages >>> (my mod_fcgid package was approved for Extras recently: >>> http://bugzilla.redhat.com/195666), it would be nice to have a >>> standard place for the .pp files to be dropped, and for that >>> directory to be owned by the selinux-policy package (so that all the >>> packages don't need to own it themselves). >>> >>> I propose the following: >>> >>> /usr/share/selinux/packages >>> (container directory, separate from modules bundled with Core package) >>> >>> /usr/share/selinux/packages/mls >>> (policy modules for use with the mls base policy) >>> >>> /usr/share/selinux/packages/strict >>> (policy modules for use with the strict base policy) >>> >>> /usr/share/selinux/packages/targeted >>> (policy modules for use with the targeted base policy) >>> >>> /usr/share/selinux/packages/share >>> (policy modules that have no base-specific elements, and can be used >>> with all base policies) >> I think this is a good idea. >> There already is a standard location: >> >> /usr/share/selinux/NAME/ >> Currently the selinux-policy-TYPE package looks in this directory and installs all the pp files that are in this directory. It should probably change to only install the pp files that it is packaging. This is a management headache because we don't need to manage this now. If someone has a good solution to figuring out the pp files during the spec build this would be great. Trying to update the modules-TYPE.conf file and maintaining the spec file in sync would be a royal pain. >> where NAME is targeted, strict, mls, etc. > > I asked about this before and it was suggested that > /usr/share/selinux/NAME would best be avoided because Core/base > packages would install modules there and there might be name > comflicts. I'm not convinced by that argument myself, but: > > * /usr/share/selinux/NAME/ is owned by selinux-policy-NAME; since > most systems will have only targeted policy installed, this is an > issue for packages wanting to include modules built for all base > policies, which will have no directories to install strict/mls modules > to. There is also no /usr/share/selinux/share directory to install > policy module packages common to all base policies. > > I think wherever the directory is, it needs to be owned by the > selinux-policy package itself and not the subpackages. > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From wart at kobold.org Tue Jul 25 17:16:31 2006 From: wart at kobold.org (Michael Thomas) Date: Tue, 25 Jul 2006 10:16:31 -0700 Subject: package review? In-Reply-To: <44C61143.3050703@redhat.com> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> <44C0F18F.5030108@city-fan.org> <44C19F50.50408@kobold.org> <44C4AC73.9050601@redhat.com> <44C4B849.3080809@tresys.com> <44C4DB3C.60608@redhat.com> <44C55F5D.5060808@kobold.org> <44C61143.3050703@redhat.com> Message-ID: <44C651EF.8000103@kobold.org> Daniel J Walsh wrote: > Michael Thomas wrote: > >> Daniel J Walsh wrote: >>> So the solution would be to add code like the following? >>> >>> gen_requires(` >>> attribute port_type; >>> ') >>> >> >> >> This gen_requires() generates a syntax error in my .te file. I had to >> change it to a simple require(): >> >> require { >> type port_t; >> attribute port_type; >> }; >> >> >> > > Should be gen_require(). Yes, that did it. What's the difference between using gen_require() and the require{} statements? --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From wart at kobold.org Tue Jul 25 21:24:28 2006 From: wart at kobold.org (Michael Thomas) Date: Tue, 25 Jul 2006 14:24:28 -0700 Subject: package review? In-Reply-To: <1153808597.24197.0.camel@laurel.intra.city-fan.org> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> <44C0F18F.5030108@city-fan.org> <44C19F50.50408@kobold.org> <44C4AC73.9050601@redhat.com> <44C4B849.3080809@tresys.com> <44C4DB3C.60608@redhat.com> <44C55F5D.5060808@kobold.org> <1153808597.24197.0.camel@laurel.intra.city-fan.org> Message-ID: <44C68C0C.50003@kobold.org> Paul Howarth wrote: > On Mon, 2006-07-24 at 17:01 -0700, Michael Thomas wrote: > >>Daniel J Walsh wrote: >>>And in your install after the policy load >>> >>>semanage port -a -t crossfire_port_t -p tcp MYPORTNUM >>>semanage port -a -t crossfire_port_t -p udp MYPORTNUM >> >>I did this, but doesn't seem to fail when it ought to. To test, I >>installed the package and then used semanage to change the port >>definition for crossfire_port_t: >> >># semanage port -l | grep crossfire >>crossfire_port_t tcp 13327 >># semanage port -d -t crossfire_port_t -p tcp 13327 >># semanage port -a -t crossfire_port_t -p tcp 13328 >># semanage port -l | grep crossfire >>crossfire_port_t tcp 13328 >> >>But when I start up the service, it is still able to bind to port 13327 >>with no errors. I can even telnet to that port with no problem. I did >>verify that the service is running as user_u:system_r:crossfire_t. I >>had expected to see an avc: denied error when the service attempted to >>bind to the port. Is there some other step that I missed, or perhaps >>something else in my .te file that is giving it permission? > > > corenet_tcp_bind_all_ports(crossfire_t) > corenet_tcp_sendrecv_all_ports(crossfire_t) I removed corenet_tcp_bind_all_ports(), and that seems to have fixed it. But I had to leave corenet_tcp_sendrecv_all_ports, otherwise I would get avc: denied messages when data was read/written to the socket. I also tried replacing corenet_tcp_sendrecv_all_ports() with: allow crossfire_t crossfire_port_t:tcp_socket { name_bind send_msg recv_msg}; ...but it still avc:denied reads/writes. However, if I designated the _client_ ports as crossfire_port_t using semanage, the reads/writes worked. It appears to me, as odd as it might seem, that the send/recv port settings apply to the remote host ports, not the local server's ports. Can this be right? --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From wart at kobold.org Tue Jul 25 23:07:30 2006 From: wart at kobold.org (Michael Thomas) Date: Tue, 25 Jul 2006 16:07:30 -0700 Subject: package review? In-Reply-To: <44C4F3EF.1010406@city-fan.org> References: <6FE441CD9F0C0C479F2D88F959B01588298C4C@exchange.columbia.tresys.com> <200607241547.k6OFll95008546@turing-police.cc.vt.edu> <44C4F3EF.1010406@city-fan.org> Message-ID: <44C6A432.7030400@kobold.org> Paul Howarth wrote: > However, the big problem with using semanage in scriptlets is that > future versions of packages have to remember and be able to cope with > anything that had ever been added using semanage in any previous version > of the package. If file contexts or port numbers change over time, this > could be a major hassle. Being able to do it in a policy module would be > *much* better because the version numbering inherent in the modules > would take care of updating and removing old rules. > > There would also be the problem of what do do when someone manually > added another port of type crossfire_port_t outside of rpm. This could be mollified if semanage could remove all port settings based on the type[+protocol]: Add the ports: semanage port -a -t crossfire_port_t -p tcp 13327 semanage port -a -t crossfire_port_t -p udp 13328 To remove tcp ports: semanage port -d -t crossfire_port_t -p tcp To remove all port settings: semanage port -d -t crossfire_port_t --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From wart at kobold.org Tue Jul 25 23:34:22 2006 From: wart at kobold.org (Michael Thomas) Date: Tue, 25 Jul 2006 16:34:22 -0700 Subject: package review? In-Reply-To: <1153512696.30083.17.camel@laurel.intra.city-fan.org> References: <44BEA63B.7030105@kobold.org> <44C0F6D4.2060303@city-fan.org> <44C12A3F.3080503@kobold.org> <1153512696.30083.17.camel@laurel.intra.city-fan.org> Message-ID: <44C6AA7E.9010702@kobold.org> Paul Howarth wrote: > On Fri, 2006-07-21 at 12:25 -0700, Michael Thomas wrote: >>Paul Howarth wrote: >>>Did you follow the guide on Packaging/SELinux on the wiki for actually >>>building the module in your package? I've changed what I do for package >>>building since I last updated that page (and I can't update it any more) >>>and you'll find it won't build on rawhide as there is an >>>selinux-policy-devel package you need as a buildreq there. >> >>Yes, I used policygentool to generate the policy files, then your >>SELinux page to put it in the package. I'd like to see an official >>packaging policy for selinux modules for Fedora Extras, but I'm not sure >>that there are many FE contributors looking at selinux yet. It looks >>like the page has also been copied to PackagingDrafts/SELinux, where you >>should be able to modify it. > > > Yes, Tibbs contacted me privately about that. I've have a go at updating > it, probably next week. If you want, I can make some updates to the SELinux page now that I've got a working package for FC5 (no FC6 testing has been done yet). --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From paul at city-fan.org Wed Jul 26 12:07:30 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 26 Jul 2006 13:07:30 +0100 Subject: Directories for policy module packages In-Reply-To: <44C64104.20206@redhat.com> References: <44C5E113.6070601@city-fan.org> <1153832927.10011.3.camel@sgc> <44C61B15.2000503@city-fan.org> <44C64104.20206@redhat.com> Message-ID: <44C75B02.6020505@city-fan.org> Daniel J Walsh wrote: > Paul Howarth wrote: >> Christopher J. PeBenito wrote: >>> On Tue, 2006-07-25 at 10:14 +0100, Paul Howarth wrote: >>>> Now that RPM packages are starting to include policy module packages >>>> (my mod_fcgid package was approved for Extras recently: >>>> http://bugzilla.redhat.com/195666), it would be nice to have a >>>> standard place for the .pp files to be dropped, and for that >>>> directory to be owned by the selinux-policy package (so that all the >>>> packages don't need to own it themselves). >>>> >>>> I propose the following: >>>> >>>> /usr/share/selinux/packages >>>> (container directory, separate from modules bundled with Core package) >>>> >>>> /usr/share/selinux/packages/mls >>>> (policy modules for use with the mls base policy) >>>> >>>> /usr/share/selinux/packages/strict >>>> (policy modules for use with the strict base policy) >>>> >>>> /usr/share/selinux/packages/targeted >>>> (policy modules for use with the targeted base policy) >>>> >>>> /usr/share/selinux/packages/share >>>> (policy modules that have no base-specific elements, and can be used >>>> with all base policies) >>> > I think this is a good idea. Good, but you might change your mind... >>> There already is a standard location: >>> >>> /usr/share/selinux/NAME/ >>> > Currently the selinux-policy-TYPE package looks in this directory and > installs all the pp files that are in this directory. > It should probably change to only install the pp files that it is > packaging. This is a management headache because we > don't need to manage this now. If someone has a good solution to > figuring out the pp files during the spec build this would be > great. Trying to update the modules-TYPE.conf file and maintaining the > spec file in sync would be a royal pain. Try the attached patch which groks the module names from the modules-TYPE.conf file. It also moves the directory ownership of the /usr/share/selinux/NAME/ directory from the selinux-policy-NAME package to the selinux-policy package, so that RPMs containing policy module packages for all base policies will have properly-owned directories to install them into even on systems that only have one of the base policies installed. Regarding .pp files that are identical for each of the base policies, I think it's better not to have a "share" directory for them but instead to install them into one of the /usr/share/selinux/NAME/ directories and then link them to the other /usr/share/selinux/NAME/ directories. This could be done automagically with a bit of boilerplate scripting in the spec file that looks for identical .pp files and links them together. The advantage of doing it this way is that it'll still work properly even if some of the policy macros change and what was once a policy package that was identical across all base policies suddenly becomes different for each base policy, i.e. the module packager doesn't need to make any changes, just rebuild against the new policy. With the attached patch and the module packaging policy described above, all .pp files, from both the Core policy packages and others, will go in /usr/share/selinux/NAME/ and there is no need for the separate /usr/share/selinux/packages/ hierarchy. Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: selinux-policy.spec.patch Type: text/x-patch Size: 2615 bytes Desc: not available URL: From paul at city-fan.org Wed Jul 26 12:19:16 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 26 Jul 2006 13:19:16 +0100 Subject: package review? In-Reply-To: <44C6AA7E.9010702@kobold.org> References: <44BEA63B.7030105@kobold.org> <44C0F6D4.2060303@city-fan.org> <44C12A3F.3080503@kobold.org> <1153512696.30083.17.camel@laurel.intra.city-fan.org> <44C6AA7E.9010702@kobold.org> Message-ID: <44C75DC4.4080509@city-fan.org> Michael Thomas wrote: > Paul Howarth wrote: >> On Fri, 2006-07-21 at 12:25 -0700, Michael Thomas wrote: >>> Paul Howarth wrote: >>>> Did you follow the guide on Packaging/SELinux on the wiki for actually >>>> building the module in your package? I've changed what I do for package >>>> building since I last updated that page (and I can't update it any more) >>>> and you'll find it won't build on rawhide as there is an >>>> selinux-policy-devel package you need as a buildreq there. >>> Yes, I used policygentool to generate the policy files, then your >>> SELinux page to put it in the package. I'd like to see an official >>> packaging policy for selinux modules for Fedora Extras, but I'm not sure >>> that there are many FE contributors looking at selinux yet. It looks >>> like the page has also been copied to PackagingDrafts/SELinux, where you >>> should be able to modify it. >> >> Yes, Tibbs contacted me privately about that. I've have a go at updating >> it, probably next week. > > If you want, I can make some updates to the SELinux page now that I've > got a working package for FC5 (no FC6 testing has been done yet). It's on my to-do list but I'd like to get the directories sorted out first. Paul. From jacliburn at bellsouth.net Wed Jul 26 14:26:23 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Wed, 26 Jul 2006 09:26:23 -0500 Subject: 20060726 rawhide setroubleshoot error Message-ID: <44C77B8F.5050908@bellsouth.net> From /var/log/messages Jul 26 08:50:05 osprey setroubleshoot: 2006-07-26 08:50:05,204 [avc.ERROR] Type exception plugins.default: iterable argument required Traceback (most recent call last): File "/usr/lib/audit/setroubleshoot_dispatcher", line 28, in run if plugin.analyze(avc): File "/usr/share/setroubleshoot/plugins/default.py", line 45, in analyze if "path" in avc: TypeError: iterable argument required [root at osprey ~]# rpm -q setroubleshoot audit setroubleshoot-0.14-1 audit-1.2.5-4 The odd thing is, I've disabled setroubleshoot from running at boot. [root at osprey ~]# chkconfig --list | grep setroubleshoot setroubleshoot 0:off 1:off 2:off 3:off 4:off 5:off 6:off From dwalsh at redhat.com Wed Jul 26 14:50:25 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 26 Jul 2006 10:50:25 -0400 Subject: package review? In-Reply-To: <44C651EF.8000103@kobold.org> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> <44C0F18F.5030108@city-fan.org> <44C19F50.50408@kobold.org> <44C4AC73.9050601@redhat.com> <44C4B849.3080809@tresys.com> <44C4DB3C.60608@redhat.com> <44C55F5D.5060808@kobold.org> <44C61143.3050703@redhat.com> <44C651EF.8000103@kobold.org> Message-ID: <44C78131.3080806@redhat.com> Michael Thomas wrote: > Daniel J Walsh wrote: > >> Michael Thomas wrote: >> >> >>> Daniel J Walsh wrote: >>> >>>> So the solution would be to add code like the following? >>>> >>>> gen_requires(` >>>> attribute port_type; >>>> ') >>>> >>>> >>> This gen_requires() generates a syntax error in my .te file. I had to >>> change it to a simple require(): >>> >>> require { >>> type port_t; >>> attribute port_type; >>> }; >>> >>> >>> >>> >> Should be gen_require(). >> > > Yes, that did it. What's the difference between using gen_require() and > the require{} statements? > ############################## # # For use in interfaces, to optionally insert a require block # define(`gen_require',` ifdef(`self_contained_policy',` ifdef(`__in_optional_policy',` require { $1 } # end require ') ',` require { $1 } # end require ') ') So for your case not much. If you are using it in an interface file and it is in an Optional block it will be optional. Otherwise it is required. At least that is my reading of the macro. > --Mike > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Wed Jul 26 14:53:23 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 26 Jul 2006 10:53:23 -0400 Subject: package review? In-Reply-To: <44C6A432.7030400@kobold.org> References: <6FE441CD9F0C0C479F2D88F959B01588298C4C@exchange.columbia.tresys.com> <200607241547.k6OFll95008546@turing-police.cc.vt.edu> <44C4F3EF.1010406@city-fan.org> <44C6A432.7030400@kobold.org> Message-ID: <44C781E3.1020100@redhat.com> Michael Thomas wrote: > Paul Howarth wrote: > >> However, the big problem with using semanage in scriptlets is that >> future versions of packages have to remember and be able to cope with >> anything that had ever been added using semanage in any previous version >> of the package. If file contexts or port numbers change over time, this >> could be a major hassle. Being able to do it in a policy module would be >> *much* better because the version numbering inherent in the modules >> would take care of updating and removing old rules. >> >> There would also be the problem of what do do when someone manually >> added another port of type crossfire_port_t outside of rpm. >> > > > This could be mollified if semanage could remove all port settings based > on the type[+protocol]: > > Yes sounds like a nice enhancement for this situation. One problem is that we can not remove ports that are defined in the base policy. semanage port -d -p tcp 540 /usr/sbin/semanage: Port tcp/540 is defined in policy, cannot be deleted But having a command that said semanage port -d -p tcp -t crossfire_port_t Would be nice. Patches accepted. :^) > Add the ports: > semanage port -a -t crossfire_port_t -p tcp 13327 > semanage port -a -t crossfire_port_t -p udp 13328 > > To remove tcp ports: > semanage port -d -t crossfire_port_t -p tcp > > To remove all port settings: > semanage port -d -t crossfire_port_t > > --Mike > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From peter.pun at gmail.com Wed Jul 26 14:53:52 2006 From: peter.pun at gmail.com (Peter Pun) Date: Wed, 26 Jul 2006 10:53:52 -0400 Subject: firefox policy 2 Message-ID: <3e2c91580607260753q4d5834a2o3592a85dfcb5ead9@mail.gmail.com> Hi All, Is there a way to specify in a policy so that files created by firefox are automatically labelled as particular type? When a user starting up firefox for the first time and it creates the .mozilla dir. How can that .mozilla dir and contents be automatically labeled ? Or should I write a "make-new user" script that somehow starts a gnome-session for him, runs firefox and then label the .mozilla dir? Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Wed Jul 26 15:10:55 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 26 Jul 2006 11:10:55 -0400 Subject: Directories for policy module packages In-Reply-To: <44C75B02.6020505@city-fan.org> References: <44C5E113.6070601@city-fan.org> <1153832927.10011.3.camel@sgc> <44C61B15.2000503@city-fan.org> <44C64104.20206@redhat.com> <44C75B02.6020505@city-fan.org> Message-ID: <44C785FF.3040704@redhat.com> Paul Howarth wrote: > Daniel J Walsh wrote: >> Paul Howarth wrote: >>> Christopher J. PeBenito wrote: >>>> On Tue, 2006-07-25 at 10:14 +0100, Paul Howarth wrote: >>>>> Now that RPM packages are starting to include policy module >>>>> packages (my mod_fcgid package was approved for Extras recently: >>>>> http://bugzilla.redhat.com/195666), it would be nice to have a >>>>> standard place for the .pp files to be dropped, and for that >>>>> directory to be owned by the selinux-policy package (so that all >>>>> the packages don't need to own it themselves). >>>>> >>>>> I propose the following: >>>>> >>>>> /usr/share/selinux/packages >>>>> (container directory, separate from modules bundled with Core >>>>> package) >>>>> >>>>> /usr/share/selinux/packages/mls >>>>> (policy modules for use with the mls base policy) >>>>> >>>>> /usr/share/selinux/packages/strict >>>>> (policy modules for use with the strict base policy) >>>>> >>>>> /usr/share/selinux/packages/targeted >>>>> (policy modules for use with the targeted base policy) >>>>> >>>>> /usr/share/selinux/packages/share >>>>> (policy modules that have no base-specific elements, and can be >>>>> used with all base policies) >>>> >> I think this is a good idea. > > Good, but you might change your mind... > >>>> There already is a standard location: >>>> >>>> /usr/share/selinux/NAME/ >>>> >> Currently the selinux-policy-TYPE package looks in this directory and >> installs all the pp files that are in this directory. >> It should probably change to only install the pp files that it is >> packaging. This is a management headache because we >> don't need to manage this now. If someone has a good solution to >> figuring out the pp files during the spec build this would be >> great. Trying to update the modules-TYPE.conf file and maintaining >> the spec file in sync would be a royal pain. > > Try the attached patch which groks the module names from the > modules-TYPE.conf file. > > It also moves the directory ownership of the /usr/share/selinux/NAME/ > directory from the selinux-policy-NAME package to the selinux-policy > package, so that RPMs containing policy module packages for all base > policies will have properly-owned directories to install them into > even on systems that only have one of the base policies installed. > > Regarding .pp files that are identical for each of the base policies, > I think it's better not to have a "share" directory for them but > instead to install them into one of the /usr/share/selinux/NAME/ > directories and then link them to the other /usr/share/selinux/NAME/ > directories. This could be done automagically with a bit of > boilerplate scripting in the spec file that looks for identical .pp > files and links them together. The advantage of doing it this way is > that it'll still work properly even if some of the policy macros > change and what was once a policy package that was identical across > all base policies suddenly becomes different for each base policy, > i.e. the module packager doesn't need to make any changes, just > rebuild against the new policy. > > With the attached patch and the module packaging policy described > above, all .pp files, from both the Core policy packages and others, > will go in /usr/share/selinux/NAME/ and there is no need for the > separate /usr/share/selinux/packages/ hierarchy. > > Paul. > ------------------------------------------------------------------------ > > --- selinux-policy.spec 2006-07-26 10:22:24.000000000 +0100 > +++ selinux-policy.spec 2006-07-26 12:40:09.000000000 +0100 > @@ -58,6 +58,9 @@ > %{_usr}/share/selinux/devel/policygentool > %{_usr}/share/selinux/devel/example.* > %attr(755,root,root) %{_usr}/share/selinux/devel/policyhelp > +%dir %{_usr}/share/selinux/targeted > +%dir %{_usr}/share/selinux/strict > +%dir %{_usr}/share/selinux/mls > > %define setupCmds() \ > make NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=%{monolithic} POLY=%3 bare \ > @@ -65,6 +68,9 @@ > cp -f ${RPM_SOURCE_DIR}/modules-%1.conf ./policy/modules.conf \ > cp -f ${RPM_SOURCE_DIR}/booleans-%1.conf ./policy/booleans.conf \ > > +%define moduleList() %([ -f %{_sourcedir}/modules-%{1}.conf ] && \ > +sort %{_sourcedir}/modules-%{1}.conf | awk '$2 == "=" && $3 == "module" { printf "-i %%s.pp ", $1 }') > + > %define installCmds() \ > make NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=%{monolithic} POLY=%3 base.pp \ > make NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=%{monolithic} POLY=%3 modules \ > @@ -91,7 +97,6 @@ > > %define fileList() \ > %defattr(-,root,root) \ > -%dir %{_usr}/share/selinux/%1 \ > %{_usr}/share/selinux/%1/*.pp \ > %dir %{_sysconfdir}/selinux/%1 \ > %config(noreplace) %{_sysconfdir}/selinux/%1/setrans.conf \ > @@ -130,8 +135,7 @@ > > %define rebuildpolicy() \ > ( cd /usr/share/selinux/%1; \ > -x=`ls *.pp | grep -v -e base.pp -e enableaudit.pp | awk '{ print "-i " $1 }'`; \ > -semodule -b base.pp $x -s %1; \ > +semodule -b base.pp %{expand:%%moduleList %1} -s %1; \ > );\ > rm -f %{_sysconfdir}/selinux/%1/policy/policy.*.rpmnew > > @@ -160,6 +164,9 @@ > touch %{buildroot}%{_sysconfdir}/selinux/config > touch %{buildroot}%{_sysconfdir}/sysconfig/selinux > > +# Always create policy module package directories > +mkdir -p %{buildroot}%{_usr}/share/selinux/{targeted,strict,mls}/ > + > # Install devel > make clean > make NAME=targeted TYPE=targeted-mcs DISTRO=%{distro} DIRECT_INITRC=y MONOLITHIC=%{monolithic} DESTDIR=%{buildroot} PKGNAME=%{name}-%{version} POLY=%3 install-headers install-docs > @@ -281,7 +288,7 @@ > %relabel mls > > %triggerpostun mls -- mls <= 2.0.7 > -%{rebuildpolicy} mls > +%rebuildpolicy mls > > %files mls > %fileList mls > @@ -315,7 +322,7 @@ > semodule -b base.pp -r bootloader -r clock -r dpkg -r fstools -r hotplug -r init -r libraries -r locallogin -r logging -r lvm -r miscfiles -r modutils -r mount -r mta -r netutils -r selinuxutil -r storage -r sysnetwork -r udev -r userdomain -r vpnc -r xend $x -s strict > > %triggerpostun strict -- strict <= 2.0.7 > -%{rebuildpolicy} strict > +%rebuildpolicy strict > > %files strict > %fileList strict > Changing to use %define moduleList() %([ -f %{_sourcedir}/modules-%{1}.conf ] && \ awk '$1 !~ "#.*" && $2 == "=" && $3 == "module" { printf "-i %%s.pp ", $1 }' %{_sourcedir}/modules-%{1}.conf ) Any reason for the sort? Do not want to grab comment lines. From paul at city-fan.org Wed Jul 26 15:21:16 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 26 Jul 2006 16:21:16 +0100 Subject: Directories for policy module packages In-Reply-To: <44C785FF.3040704@redhat.com> References: <44C5E113.6070601@city-fan.org> <1153832927.10011.3.camel@sgc> <44C61B15.2000503@city-fan.org> <44C64104.20206@redhat.com> <44C75B02.6020505@city-fan.org> <44C785FF.3040704@redhat.com> Message-ID: <44C7886C.6050107@city-fan.org> Daniel J Walsh wrote: > Changing to use > > %define moduleList() %([ -f %{_sourcedir}/modules-%{1}.conf ] && \ > awk '$1 !~ "#.*" && $2 == "=" && $3 == "module" { printf "-i %%s.pp ", > $1 }' %{_sourcedir}/modules-%{1}.conf ) Could possibly use: $1 !~ /^#/ instead of $1 !~ "#.*" which might be marginally faster > Any reason for the sort? No particular reason other than it orders the list of modules in the same way that the original "ls *.pp" did, and it's easier to check that the list of modules matches what's in the package that way. > Do not want to grab comment lines. I didn't see it doing that but better safe than sorry. Paul. From paul at city-fan.org Wed Jul 26 16:04:27 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 26 Jul 2006 17:04:27 +0100 Subject: package review? In-Reply-To: <44C68C0C.50003@kobold.org> References: <44BEA63B.7030105@kobold.org> <44BFBF12.5080608@redhat.com> <44BFBF9E.1090503@kobold.org> <44BFD555.3080500@redhat.com> <44C01F58.5080109@kobold.org> <44C0F18F.5030108@city-fan.org> <44C19F50.50408@kobold.org> <44C4AC73.9050601@redhat.com> <44C4B849.3080809@tresys.com> <44C4DB3C.60608@redhat.com> <44C55F5D.5060808@kobold.org> <1153808597.24197.0.camel@laurel.intra.city-fan.org> <44C68C0C.50003@kobold.org> Message-ID: <44C7928B.8010205@city-fan.org> Michael Thomas wrote: > Paul Howarth wrote: >> On Mon, 2006-07-24 at 17:01 -0700, Michael Thomas wrote: >> >>> Daniel J Walsh wrote: >>>> And in your install after the policy load >>>> >>>> semanage port -a -t crossfire_port_t -p tcp MYPORTNUM >>>> semanage port -a -t crossfire_port_t -p udp MYPORTNUM >>> I did this, but doesn't seem to fail when it ought to. To test, I >>> installed the package and then used semanage to change the port >>> definition for crossfire_port_t: >>> >>> # semanage port -l | grep crossfire >>> crossfire_port_t tcp 13327 >>> # semanage port -d -t crossfire_port_t -p tcp 13327 >>> # semanage port -a -t crossfire_port_t -p tcp 13328 >>> # semanage port -l | grep crossfire >>> crossfire_port_t tcp 13328 >>> >>> But when I start up the service, it is still able to bind to port 13327 >>> with no errors. I can even telnet to that port with no problem. I did >>> verify that the service is running as user_u:system_r:crossfire_t. I >>> had expected to see an avc: denied error when the service attempted to >>> bind to the port. Is there some other step that I missed, or perhaps >>> something else in my .te file that is giving it permission? >> >> corenet_tcp_bind_all_ports(crossfire_t) >> corenet_tcp_sendrecv_all_ports(crossfire_t) > > I removed corenet_tcp_bind_all_ports(), and that seems to have fixed it. > But I had to leave corenet_tcp_sendrecv_all_ports, otherwise I would > get avc: denied messages when data was read/written to the socket. > > I also tried replacing corenet_tcp_sendrecv_all_ports() with: > > allow crossfire_t crossfire_port_t:tcp_socket { name_bind send_msg > recv_msg}; > > ...but it still avc:denied reads/writes. However, if I designated the > _client_ ports as crossfire_port_t using semanage, the reads/writes > worked. It appears to me, as odd as it might seem, that the send/recv > port settings apply to the remote host ports, not the local server's > ports. Can this be right? The use of corenet_tcp_sendrecv_all_ports is widespread in the reference policy, with only a few examples of anything more specific, such as: corenet_tcp_sendrecv_amavisd_recv_port(amavis_t) corenet_tcp_sendrecv_amavisd_send_port(amavis_t) So you're probably OK with corenet_tcp_sendrecv_all_ports(crossfire_t) Paul. From dwalsh at redhat.com Wed Jul 26 18:18:55 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 26 Jul 2006 14:18:55 -0400 Subject: firefox policy 2 In-Reply-To: <3e2c91580607260753q4d5834a2o3592a85dfcb5ead9@mail.gmail.com> References: <3e2c91580607260753q4d5834a2o3592a85dfcb5ead9@mail.gmail.com> Message-ID: <44C7B20F.1000302@redhat.com> Peter Pun wrote: > Hi All, > > Is there a way to specify in a policy so that files created by firefox > are automatically labelled as particular type? When a user starting > up firefox for the first time and it creates the .mozilla dir. How can > that .mozilla dir and contents be automatically labeled ? Or should I > write a "make-new user" script that somehow starts a gnome-session for > him, runs firefox and then label the .mozilla dir? Try type firefox_home_t; userdom_user_home_dir_filetrans(user, firefox_t, firefox_home_t, dir) Something like this in your file context HOME_DIR/\.mozilla(/.*)? gen_context(system_u:object_r:ROLE_firefox_home_t,s0) A lot of this is already done in reference policy if you install the src rpm,take a look at mozilla.* > > Peter > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From shin216 at xf7.so-net.ne.jp Thu Jul 27 12:08:01 2006 From: shin216 at xf7.so-net.ne.jp (Shintaro Fujiwara) Date: Thu, 27 Jul 2006 21:08:01 +0900 Subject: SELinux Policy Analizer on Web (SELPAW) Message-ID: <1154002082.2505.5.camel@mama.intrajp-yokosuka.co.jp> Hello everybody, I'm posting this from Japan. I've written a PHP script which generates a .te file from your audit.log. It will not save your file on my server but just echo allow sentences. Please try. http://intrajp.no-ip.com/selpaw/selpaw.php p.s. I'm ready to open my source at sourceforge. From fedora at grifent.com Thu Jul 27 19:40:55 2006 From: fedora at grifent.com (John Griffiths) Date: Thu, 27 Jul 2006 15:40:55 -0400 Subject: postfix, clamv, amavisd-new, spamassassin In-Reply-To: <20060727160011.B389A73D9C@hormel.redhat.com> References: <20060727160011.B389A73D9C@hormel.redhat.com> Message-ID: <44C916C7.1020603@grifent.com> I still notice lots of AVCs in the messages log regarding postfix, clamv, amavisd-new, spamassassin. I am using selinux-policy-targeted-2.3.2-1.fc5 and selinux-policy-2.3.2-1.fc5. In order to get amavisd-new and clamscan to work with these selinux versions, the booleans for clamscan_disable_trans and amavis_disable_trans have to be set to on. I have noticed a lot of traffic on the list regarding postfix, procmail, integration. Maybe the policies being developed could be expanded upon to take care of the postfix, amavis-new, clamv, spamassassin case. I ran the AVCs through audit2allow and came up with the rules. Here are the rules followed by the causing AVC: allow amavis_t clamd_var_run_t:sock_file write; Jul 26 18:43:18 somehostname kernel: audit(1153953798.370:869): avc: denied { write } for pid=17186 comm="amavisd" name="clamd.sock" dev=dm-0 ino=1333000 scontext=root:system_r:amavis_t:s0 tcontext=root:object_r:clamd_var_run_t:s0 tclass=sock_file allow amavis_t postfix_etc_t:dir search; Jul 25 16:26:56 somehostname kernel: audit(1153859216.437:772): avc: denied { search } for pid=4207 comm="amavisd" name="postfix" dev=dm-0 ino=359267 scontext=root:system_r:amavis_t:s0 tcontext=system_u:object_r:postfix_etc_t:s0 tclass=dir allow amavis_t razor_port_t:tcp_socket name_connect; Jul 26 16:42:14 somehostname kernel: audit(1153946534.516:865): avc: denied { name_connect } for pid=17183 comm="amavisd" dest=2703 scontext=root:system_r:amavis_t:s0 tcontext=system_u:object_r:razor_port_t:s0 tclass=tcp_socket allow clamd_t amavis_var_run_t:dir search; Jul 27 14:31:14 somehostname kernel: audit(1154025074.534:1208): avc: denied { search } for pid=26308 comm="clamd.amavisd" name="amavisd" dev=dm-0 ino=1334115 scontext=root:system_r:clamd_t:s0 tcontext=system_u:object_r:amavis_var_run_t:s0 tclass=dir allow clamd_t sysctl_kernel_t:dir search; Jul 27 14:31:11 somehostname kernel: audit(1154025071.062:1206): avc: denied { search } for pid=26307 comm="clamd.amavisd" scontext=root:system_r:clamd_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir allow clamd_t sysctl_t:dir search; Jul 27 14:31:11 somehostname kernel: audit(1154025071.062:1207): avc: denied { search } for pid=26307 comm="clamd.amavisd" name="sys" dev=proc ino=-268435429 scontext=root:system_r:clamd_t:s0 tcontext=system_u:object_r:sysctl_t:s0 tclass=dir allow postfix_cleanup_t bin_t:file getattr; Jul 26 14:10:52 somehostname kernel: audit(1153937452.370:819): avc: denied { getattr } for pid=15469 comm="sh" name="sleep" dev=dm-0 ino=1299281 scontext=root:system_r:postfix_cleanup_t:s0-s0:c0.c255 tcontext=system_u:object_r:bin_t:s0 tclass=file allow postfix_local_t clamd_var_lib_t:dir search; Jul 26 08:10:16 somehostname kernel: audit(1153915816.342:802): avc: denied { search } for pid=13112 comm="local" name="clamav" dev=dm-0 ino=1334110 scontext=root:system_r:postfix_local_t:s0 tcontext=system_u:object_r:clamd_var_lib_t:s0 tclass=dir allow postfix_map_t nscd_var_run_t:dir search; Jul 25 11:41:37 somehostname kernel: audit(1153842097.261:264): avc: denied { search } for pid=8233 comm="postmap" name="nscd" dev=dm-0 ino=1332052 scontext=root:system_r:postfix_map_t:s0-s0:c0.c255 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir allow postfix_pickup_t bin_t:file getattr; Jul 26 14:06:34 somehostname kernel: audit(1153937194.032:816): avc: denied { getattr } for pid=15411 comm="sh" name="sleep" dev=dm-0 ino=1299281 scontext=root:system_r:postfix_pickup_t:s0-s0:c0.c255 tcontext=system_u:object_r:bin_t:s0 tclass=file allow postfix_qmgr_t bin_t:file getattr; Jul 26 14:06:34 somehostname kernel: audit(1153937194.036:817): avc: denied { getattr } for pid=15409 comm="sh" name="sleep" dev=dm-0 ino=1299281 scontext=root:system_r:postfix_qmgr_t:s0-s0:c0.c255 tcontext=system_u:object_r:bin_t:s0 tclass=file allow postfix_smtpd_t bin_t:file getattr; Jul 26 14:08:02 somehostname kernel: audit(1153937282.152:818): avc: denied { getattr } for pid=15433 comm="sh" name="sleep" dev=dm-0 ino=1299281 scontext=root:system_r:postfix_smtpd_t:s0-s0:c0.c255 tcontext=system_u:object_r:bin_t:s0 tclass=file allow semanage_t postfix_etc_t:dir search; Jul 27 14:29:59 somehostname kernel: audit(1154024994.164:1204): avc: denied { search } for pid=26252 comm="genhomedircon" name="postfix" dev=dm-0 ino=359267 scontext=root:system_r:semanage_t:s0-s0:c0.c255 tcontext=system_u:object_r:postfix_etc_t:s0 tclass=dir allow spamd_t postfix_etc_t:dir search; Jul 27 14:31:21 somehostname kernel: audit(1154025077.106:1430): avc: denied { search } for pid=26384 comm="spamd" name="postfix" dev=dm-0 ino=359267 scontext=root:system_r:spamd_t:s0 tcontext=system_u:object_r:postfix_etc_t:s0 tclass=dir allow spamd_t root_t:dir write; Jul 27 14:31:21 somehostname kernel: audit(1154025078.575:1431): avc: denied { write } for pid=26386 comm="spamd" name="/" dev=dm-0 ino=2 scontext=root:system_r:spamd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir allow spamd_t user_home_dir_t:dir write; Jul 27 14:31:21 somehostname kernel: audit(1154025078.575:1432): avc: denied { write } for pid=26386 comm="spamd" name="root" dev=dm-0 ino=292321 scontext=root:system_r:spamd_t:s0 tcontext=root:object_r:user_home_dir_t:s0 tclass=dir The configuration for postfix, anavisd-new, clamv, and spamassassin are pretty plain vanilla with the only changes to configuration files being those necessary for host and to enable the content filter in postfix using the modifications outlined in the README.fedora and README.postfix for amavisd-new. Regards, John From wart at kobold.org Thu Jul 27 23:57:12 2006 From: wart at kobold.org (Michael Thomas) Date: Thu, 27 Jul 2006 16:57:12 -0700 Subject: package review? In-Reply-To: <1153512696.30083.17.camel@laurel.intra.city-fan.org> References: <44BEA63B.7030105@kobold.org> <44C0F6D4.2060303@city-fan.org> <44C12A3F.3080503@kobold.org> <1153512696.30083.17.camel@laurel.intra.city-fan.org> Message-ID: <44C952D8.2020908@kobold.org> Paul Howarth wrote: > I think that could depend on the particular relationship between the > policy and the main package. For instance, if in your package you > patched out the need for temp files and you didn't allow it to use them > in the SELinux policy, the policy package would want to conflict with > any version of the main package prior to the addition of the patch. I > favour Conflicts: for these rather than Requires: because I can see > reasons why people would want to install both parts independently of the > other (non-SELinux users would want the main package without the policy, > and people wanting to learn about SELinux might want the policy package > without the main one). I played around with this a bit, and I think that the -selinux subpackage should Requires: the package that it applies to. If you install the -selinux package first, then the base package, the newly installed base package files don't get relabeled and the policy won't have any effect. The solution would be to either add commands to relabel the files in the base package's %post script, or add the Requires: to the selinux subpackage. I'd prefer the latter as it is much simpler. If people want to learn about SELinux then they can grab the src rpm. --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From paul at city-fan.org Fri Jul 28 07:29:07 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 28 Jul 2006 08:29:07 +0100 Subject: package review? In-Reply-To: <44C952D8.2020908@kobold.org> References: <44BEA63B.7030105@kobold.org> <44C0F6D4.2060303@city-fan.org> <44C12A3F.3080503@kobold.org> <1153512696.30083.17.camel@laurel.intra.city-fan.org> <44C952D8.2020908@kobold.org> Message-ID: <1154071747.15492.19.camel@laurel.intra.city-fan.org> On Thu, 2006-07-27 at 16:57 -0700, Michael Thomas wrote: > Paul Howarth wrote: > > I think that could depend on the particular relationship between the > > policy and the main package. For instance, if in your package you > > patched out the need for temp files and you didn't allow it to use them > > in the SELinux policy, the policy package would want to conflict with > > any version of the main package prior to the addition of the patch. I > > favour Conflicts: for these rather than Requires: because I can see > > reasons why people would want to install both parts independently of the > > other (non-SELinux users would want the main package without the policy, > > and people wanting to learn about SELinux might want the policy package > > without the main one). > > I played around with this a bit, and I think that the -selinux > subpackage should Requires: the package that it applies to. If you > install the -selinux package first, then the base package, the newly > installed base package files don't get relabeled and the policy won't > have any effect. If the selinux package includes the appropriate file contexts in the .fc file, installing it first has the advantage that RPM will label the main package's files correctly at install time and no relabelling is necessary at all. Unfortunately it's still necessary to have relabelling in the %post script of the selinux package because file file contexts won't get set properly if both packages are installed in the same RPM transaction (a deficiency in rpm's transaction ordering). Paul. From paul at city-fan.org Fri Jul 28 10:07:09 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 28 Jul 2006 11:07:09 +0100 Subject: Directories for policy module packages In-Reply-To: <44C7886C.6050107@city-fan.org> References: <44C5E113.6070601@city-fan.org> <1153832927.10011.3.camel@sgc> <44C61B15.2000503@city-fan.org> <44C64104.20206@redhat.com> <44C75B02.6020505@city-fan.org> <44C785FF.3040704@redhat.com> <44C7886C.6050107@city-fan.org> Message-ID: <44C9E1CD.9020603@city-fan.org> Paul Howarth wrote: > Daniel J Walsh wrote: >> Changing to use >> >> %define moduleList() %([ -f %{_sourcedir}/modules-%{1}.conf ] && \ >> awk '$1 !~ "#.*" && $2 == "=" && $3 == "module" { printf "-i %%s.pp ", >> $1 }' %{_sourcedir}/modules-%{1}.conf ) I see the patch went in in today's rawhide report: * Wed Jul 26 2006 Dan Walsh 2.3.3-11 - Added Paul Howorth patch to only load policy packages shipped with this package My name's actually "Howarth", not "Howorth" by the way. Will this go into the next FC5 update too? Did you include the part moving the /usr/share/selinux/POLICYNAME directories to the main selinux-policy package? Paul. From dwalsh at redhat.com Fri Jul 28 12:59:55 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 28 Jul 2006 08:59:55 -0400 Subject: Directories for policy module packages In-Reply-To: <44C9E1CD.9020603@city-fan.org> References: <44C5E113.6070601@city-fan.org> <1153832927.10011.3.camel@sgc> <44C61B15.2000503@city-fan.org> <44C64104.20206@redhat.com> <44C75B02.6020505@city-fan.org> <44C785FF.3040704@redhat.com> <44C7886C.6050107@city-fan.org> <44C9E1CD.9020603@city-fan.org> Message-ID: <44CA0A4B.7000609@redhat.com> Paul Howarth wrote: > Paul Howarth wrote: >> Daniel J Walsh wrote: >>> Changing to use >>> >>> %define moduleList() %([ -f %{_sourcedir}/modules-%{1}.conf ] && \ >>> awk '$1 !~ "#.*" && $2 == "=" && $3 == "module" { printf "-i %%s.pp >>> ", $1 }' %{_sourcedir}/modules-%{1}.conf ) > > I see the patch went in in today's rawhide report: > > * Wed Jul 26 2006 Dan Walsh 2.3.3-11 > - Added Paul Howorth patch to only load policy packages shipped > with this package > > My name's actually "Howarth", not "Howorth" by the way. > Sorry, will be fixed tonight. > Will this go into the next FC5 update too? > Probably > Did you include the part moving the /usr/share/selinux/POLICYNAME > directories to the main selinux-policy package? > Yes > Paul. From wart at kobold.org Sat Jul 29 01:04:11 2006 From: wart at kobold.org (Michael Thomas) Date: Fri, 28 Jul 2006 18:04:11 -0700 Subject: package review? In-Reply-To: <1154071747.15492.19.camel@laurel.intra.city-fan.org> References: <44BEA63B.7030105@kobold.org> <44C0F6D4.2060303@city-fan.org> <44C12A3F.3080503@kobold.org> <1153512696.30083.17.camel@laurel.intra.city-fan.org> <44C952D8.2020908@kobold.org> <1154071747.15492.19.camel@laurel.intra.city-fan.org> Message-ID: <44CAB40B.2030202@kobold.org> Paul Howarth wrote: > On Thu, 2006-07-27 at 16:57 -0700, Michael Thomas wrote: >> I played around with this a bit, and I think that the -selinux >> subpackage should Requires: the package that it applies to. If you >> install the -selinux package first, then the base package, the >> newly installed base package files don't get relabeled and the >> policy won't have any effect. > > > If the selinux package includes the appropriate file contexts in the > .fc file, installing it first has the advantage that RPM will label > the main package's files correctly at install time and no relabelling > is necessary at all. This isn't working for me if the main package and -selinux package are in the same rpm transaction. I have a set of packages on FC5 with this: %post selinux semodule -i %{_datadir}/selinux/packages/xpilotd/xpilotd.pp || : /sbin/restorecon -R %{_bindir}/xpilot-ng-meta || : The rpm transaction installs the -selinux subpackage first, which installs the xpilot policy file which has a file context for /usr/bin/xpilot-ng-meta. But when rpm installs the main package next in the transaction, the xpilot-ng-meta file does not get labelled correctly. However, if I install these packages in separate transactions, then the file gets labelled correctly regardless of which order the packages get installed. It almost seems as if the selinux policy does not really take effect until after the rpm transaction has finished, even though semodule -i was called in %post. Adding 'Requires: %{name}' to the -selinux subpackage does seem to fix the problem, however, as it seems to force the installation of the -selinux package last, which relabels things correctly. --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From wart at kobold.org Sat Jul 29 01:35:03 2006 From: wart at kobold.org (Wart) Date: Fri, 28 Jul 2006 18:35:03 -0700 Subject: package review? In-Reply-To: <44CAB40B.2030202@kobold.org> References: <44BEA63B.7030105@kobold.org> <44C0F6D4.2060303@city-fan.org> <44C12A3F.3080503@kobold.org> <1153512696.30083.17.camel@laurel.intra.city-fan.org> <44C952D8.2020908@kobold.org> <1154071747.15492.19.camel@laurel.intra.city-fan.org> <44CAB40B.2030202@kobold.org> Message-ID: <44CABB47.5050704@kobold.org> Michael Thomas wrote: > Paul Howarth wrote: > >>On Thu, 2006-07-27 at 16:57 -0700, Michael Thomas wrote: >> >>>I played around with this a bit, and I think that the -selinux >>>subpackage should Requires: the package that it applies to. If you >>> install the -selinux package first, then the base package, the >>>newly installed base package files don't get relabeled and the >>>policy won't have any effect. >> >> >>If the selinux package includes the appropriate file contexts in the >>.fc file, installing it first has the advantage that RPM will label >>the main package's files correctly at install time and no relabelling >>is necessary at all. > > > This isn't working for me if the main package and -selinux package are > in the same rpm transaction. > > I have a set of packages on FC5 with this: > > %post selinux > semodule -i %{_datadir}/selinux/packages/xpilotd/xpilotd.pp || : > /sbin/restorecon -R %{_bindir}/xpilot-ng-meta || : > > The rpm transaction installs the -selinux subpackage first, which > installs the xpilot policy file which has a file context for > /usr/bin/xpilot-ng-meta. But when rpm installs the main package next in > the transaction, the xpilot-ng-meta file does not get labelled correctly. > > However, if I install these packages in separate transactions, then the > file gets labelled correctly regardless of which order the packages get > installed. It almost seems as if the selinux policy does not really > take effect until after the rpm transaction has finished, even though > semodule -i was called in %post. > > Adding 'Requires: %{name}' to the -selinux subpackage does seem to fix > the problem, however, as it seems to force the installation of the > -selinux package last, which relabels things correctly. ...and I can reliably reproduce the problem by forcing the incorrect ordering by adding 'Requires: %{name}-selinux' to the main package. --Mike From paul at city-fan.org Sat Jul 29 09:35:52 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 29 Jul 2006 10:35:52 +0100 Subject: package review? In-Reply-To: <44CAB40B.2030202@kobold.org> References: <44BEA63B.7030105@kobold.org> <44C0F6D4.2060303@city-fan.org> <44C12A3F.3080503@kobold.org> <1153512696.30083.17.camel@laurel.intra.city-fan.org> <44C952D8.2020908@kobold.org> <1154071747.15492.19.camel@laurel.intra.city-fan.org> <44CAB40B.2030202@kobold.org> Message-ID: <1154165752.23966.12.camel@laurel.intra.city-fan.org> On Fri, 2006-07-28 at 18:04 -0700, Michael Thomas wrote: > Paul Howarth wrote: > > On Thu, 2006-07-27 at 16:57 -0700, Michael Thomas wrote: > >> I played around with this a bit, and I think that the -selinux > >> subpackage should Requires: the package that it applies to. If you > >> install the -selinux package first, then the base package, the > >> newly installed base package files don't get relabeled and the > >> policy won't have any effect. > > > > > > If the selinux package includes the appropriate file contexts in the > > .fc file, installing it first has the advantage that RPM will label > > the main package's files correctly at install time and no relabelling > > is necessary at all. > > This isn't working for me if the main package and -selinux package are > in the same rpm transaction. > > I have a set of packages on FC5 with this: > > %post selinux > semodule -i %{_datadir}/selinux/packages/xpilotd/xpilotd.pp || : > /sbin/restorecon -R %{_bindir}/xpilot-ng-meta || : > > The rpm transaction installs the -selinux subpackage first, which > installs the xpilot policy file which has a file context for > /usr/bin/xpilot-ng-meta. But when rpm installs the main package next in > the transaction, the xpilot-ng-meta file does not get labelled correctly. > > However, if I install these packages in separate transactions, then the > file gets labelled correctly regardless of which order the packages get > installed. It almost seems as if the selinux policy does not really > take effect until after the rpm transaction has finished, even though > semodule -i was called in %post. > > Adding 'Requires: %{name}' to the -selinux subpackage does seem to fix > the problem, however, as it seems to force the installation of the > -selinux package last, which relabels things correctly. You're right. I've now followed suit and split off an selinux subpackage in my mod_fcgid example (this avoids having a dependency on selinux-policy in the main package). http://www.city-fan.org/~paul/extras/mod_fcgid/mod_fcgid.spec I think it's now in a fit state to start writing up the guidelines, which I'll make a start on soon. Paul. From Axel.Thimm at ATrpms.net Sat Jul 29 14:05:43 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 29 Jul 2006 16:05:43 +0200 Subject: Activating selinux: Relabeling before reboot possible? Message-ID: <20060729140543.GC13284@neu.nirvana> Hi, I upgraded an old system to FC5. Now I'd like to get selinux running, but I know that once I do it will relable the system upon reboot. Since this is a production system I'd like to keep downtime as low as possible. Can I relabel the system before the reboot or skip relabeling the system upon reboot and relabel on the fly later? If yes, how? :=) Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Sat Jul 29 14:30:51 2006 From: kwade at redhat.com (Karsten Wade) Date: Sat, 29 Jul 2006 07:30:51 -0700 Subject: Activating selinux: Relabeling before reboot possible? In-Reply-To: <20060729140543.GC13284@neu.nirvana> References: <20060729140543.GC13284@neu.nirvana> Message-ID: <1154183451.28960.130.camel@erato.phig.org> On Sat, 2006-07-29 at 16:05 +0200, Axel Thimm wrote: > Hi, > > I upgraded an old system to FC5. Now I'd like to get selinux running, > but I know that once I do it will relable the system upon > reboot. Since this is a production system I'd like to keep downtime as > low as possible. > > Can I relabel the system before the reboot or skip relabeling the > system upon reboot and relabel on the fly later? If yes, how? :=) I probably know only the "old" method here. restorecon would work, applied against the entire filesystem; the man page is helpful. You can see all the helpful commands here: http://fedoraproject.org/wiki/SELinux/Commands - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From selinux at gmail.com Sat Jul 29 17:07:57 2006 From: selinux at gmail.com (Tom London) Date: Sat, 29 Jul 2006 10:07:57 -0700 Subject: AVC on install of libutempter ? Message-ID: <4c4ba1530607291007w23e1c8f9u63060a44dc67fa8a@mail.gmail.com> After installing today's rawhide (selinux-policy-2.3.3-14), I 'yum install libutempter'. I believe the following occured then: type=USER_CHAUTHTOK msg=audit(07/29/2006 09:51:16.038:68) : user pid=4163 uid=root auid=tbl subj=user_u:system_r:groupadd_t:s0 msg='op=adding group acct=utempter exe=(hostname=?, addr=?, terminal=pts/0 res=success)' ---- type=PATH msg=audit(07/29/2006 09:51:16.042:69) : item=1 name=inode=7798798 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0 type=PATH msg=audit(07/29/2006 09:51:16.042:69) : item=0 name=inode=8303056 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:nscd_exec_t:s0 type=CWD msg=audit(07/29/2006 09:51:16.042:69) : cwd= type=EXECVE msg=audit(07/29/2006 09:51:16.042:69) : a0="/usr/sbin/nscd" a1="nscd" a2="-i" a3="group" type=AVC_PATH msg=audit(07/29/2006 09:51:16.042:69) : path= type=AVC_PATH msg=audit(07/29/2006 09:51:16.042:69) : path= type=SYSCALL msg=audit(07/29/2006 09:51:16.042:69) : arch=i386 syscall=execve success=yes exit=0 a0=804de0d a1=bf8131a4 a2=bf8131b8 a3=1 items=2 ppid=4163 pid=4164 auid=tbl uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 comm=exe=subj=user_u:system_r:nscd_t:s0 key=(null) type=AVC msg=audit(07/29/2006 09:51:16.042:69) : avc: denied { read write } for pid=4164 comm=name=dev=dm-0 ino=853755 scontext=user_u:system_r:nscd_t:s0 tcontext=system_u:object_r:shadow_t:s0 tclass=file type=AVC msg=audit(07/29/2006 09:51:16.042:69) : avc: denied { write } for pid=4164 comm=name=dev=dm-0 ino=854746 scontext=user_u:system_r:nscd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file tom -- Tom London From dragoran at feuerpokemon.de Sun Jul 30 17:04:41 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 30 Jul 2006 19:04:41 +0200 Subject: smb can't access its own logfiles? Message-ID: <44CCE6A9.9050806@feuerpokemon.de> I got this erros: audit(1154259027.504:4): avc: denied { create } for pid=2610 comm="smbd" name="cores" scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:samba_log_t:s0 tclass=dir audit(1154259027.996:5): avc: denied { create } for pid=2613 comm="nmbd" name="cores" scontext=system_u:system_r:nmbd_t:s0 tcontext=system_u:object_r:samba_log_t:s0 tclass=dir on a FC5 system running selinux-policy-targeted-2.3.2-1.fc5 and samba-3.0.23a-1.fc5.1 is this a known bug/regression or should I fill a bug report? From paul at city-fan.org Sun Jul 30 18:02:15 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 30 Jul 2006 19:02:15 +0100 Subject: smb can't access its own logfiles? In-Reply-To: <44CCE6A9.9050806@feuerpokemon.de> References: <44CCE6A9.9050806@feuerpokemon.de> Message-ID: <1154282536.23966.42.camel@laurel.intra.city-fan.org> On Sun, 2006-07-30 at 19:04 +0200, dragoran wrote: > I got this erros: > audit(1154259027.504:4): avc: denied { create } for pid=2610 > comm="smbd" name="cores" scontext=system_u:system_r:smbd_t:s0 > tcontext=system_u:object_r:samba_log_t:s0 tclass=dir > audit(1154259027.996:5): avc: denied { create } for pid=2613 > comm="nmbd" name="cores" scontext=system_u:system_r:nmbd_t:s0 > tcontext=system_u:object_r:samba_log_t:s0 tclass=dir > on a FC5 system running > selinux-policy-targeted-2.3.2-1.fc5 and samba-3.0.23a-1.fc5.1 > is this a known bug/regression or should I fill a bug report? I saw this too. Samba wants to create the directories: /var/log/samba/cores/smbd /var/log/samba/cores/nmbd and set their modes to 0700. It dumps core into these directories if it detects an internal error, as described here: http://samba.org/samba/docs/man/Samba-HOWTO-Collection/bugreport.html Paul. From paul at city-fan.org Sun Jul 30 18:04:06 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 30 Jul 2006 19:04:06 +0100 Subject: mount and context translations Message-ID: <1154282646.23966.45.camel@laurel.intra.city-fan.org> I found that fstab entries like these: /srv/softlib/fedora/stentz/FC4-i386-DVD.iso /srv/softlib/fedora/stentz/dvd iso9660 ro,loop,fscontext=system_u:object_r:public_content_t 0 0 weren't working at boot time but would work if I did "mount -a" (unconfined). The fix: policy_module(localmisc, 0.0.2) require { type mount_t; type security_t; } # Allow mount to do context translations allow mount_t security_t:dir search; allow mount_t security_t:file read; Paul. From daobrien at redhat.com Mon Jul 31 01:36:38 2006 From: daobrien at redhat.com (David O'Brien) Date: Mon, 31 Jul 2006 11:36:38 +1000 Subject: RHEL5 Security Guide draft TOC - Resend Message-ID: <200607311136.38367.daobrien@redhat.com> Sent it to "request" by mistake :-( ------- I've received a number of replies to this, offering suggestions and review time, etc. Thanks to all. I'll start collating comments and suggestions from everyone and put together a revised TOC. I have a number of volunteers for SELinux, which is great, so I'll have to ask that people nominate a "focus-area", be it Policy, Troubleshooting, End-user Control, Administrator Control, whatever. That way people can check out the appropriate file and have their way with it, without fear of treading on toes. thanks everyone for the feedback and offers to help. David On Friday 28 July 2006 11:51, David O'Brien wrote: > Firstly, apologies if you receive this twice. I'm casting a wide net... > > I've attached the draft TOC of the Red Hat Enterprise Linux 5 Security > Guide for all to review and comment on. (Despite appearances it's not > supposed to be a valid xml file; I wrote it that way for my own > convenience.) As mentioned in the Scope Statement (attached), this is the > integration of the RHEL4 Security Guide and the SELinux Guide. Our focus > for this release is on accuracy and use cases, at the expense of low-level > details. > > Please feel free to make any suggestions about structure, topics, etc., how > we could use/enhance this info from other areas (Training?) or vice versa. > > I have a few names down for reviewers, authors/editors, etc., (see comments > in file) but am looking for more. If there is an area where you feel you > could contribute, please put your hand up. All contributors will be > acknowledged and included in the colophon, and earn our undying gratitude. > :-) > > cheers -- David O'Brien Red Hat Asia Pacific Pty Ltd Tel: +61-7-3514-8189 Fax: +61-7-3514-8199 email: daobrien at redhat.com web: http://apac.redhat.com/ IRC: daobrien #docs #selinux #devel #doc-i18n From dwalsh at redhat.com Mon Jul 31 13:42:43 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Jul 2006 09:42:43 -0400 Subject: Activating selinux: Relabeling before reboot possible? In-Reply-To: <1154183451.28960.130.camel@erato.phig.org> References: <20060729140543.GC13284@neu.nirvana> <1154183451.28960.130.camel@erato.phig.org> Message-ID: <44CE08D3.5010708@redhat.com> Karsten Wade wrote: > On Sat, 2006-07-29 at 16:05 +0200, Axel Thimm wrote: > >> Hi, >> >> I upgraded an old system to FC5. Now I'd like to get selinux running, >> but I know that once I do it will relable the system upon >> reboot. Since this is a production system I'd like to keep downtime as >> low as possible. >> >> Can I relabel the system before the reboot or skip relabeling the >> system upon reboot and relabel on the fly later? If yes, how? :=) >> > > It will only do this on the initial boot. Not on every reboot. > I probably know only the "old" method here. > > restorecon would work, applied against the entire filesystem; the man > page is helpful. > > You can see all the helpful commands here: > > http://fedoraproject.org/wiki/SELinux/Commands > > - Karsten > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Mon Jul 31 13:46:02 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Jul 2006 09:46:02 -0400 Subject: AVC on install of libutempter ? In-Reply-To: <4c4ba1530607291007w23e1c8f9u63060a44dc67fa8a@mail.gmail.com> References: <4c4ba1530607291007w23e1c8f9u63060a44dc67fa8a@mail.gmail.com> Message-ID: <44CE099A.2030302@redhat.com> Tom London wrote: > After installing today's rawhide (selinux-policy-2.3.3-14), I 'yum > install libutempter'. I believe the following occured then: > > type=USER_CHAUTHTOK msg=audit(07/29/2006 09:51:16.038:68) : user > pid=4163 uid=root auid=tbl subj=user_u:system_r:groupadd_t:s0 > msg='op=adding group acct=utempter exe=(hostname=?, addr=?, > terminal=pts/0 res=success)' > ---- > type=PATH msg=audit(07/29/2006 09:51:16.042:69) : item=1 > name=inode=7798798 dev=fd:00 mode=file,755 ouid=root ogid=root > rdev=00:00 obj=system_u:object_r:ld_so_t:s0 > type=PATH msg=audit(07/29/2006 09:51:16.042:69) : item=0 > name=inode=8303056 dev=fd:00 mode=file,755 ouid=root ogid=root > rdev=00:00 obj=system_u:object_r:nscd_exec_t:s0 > type=CWD msg=audit(07/29/2006 09:51:16.042:69) : cwd= > type=EXECVE msg=audit(07/29/2006 09:51:16.042:69) : > a0="/usr/sbin/nscd" a1="nscd" a2="-i" a3="group" > type=AVC_PATH msg=audit(07/29/2006 09:51:16.042:69) : path= > type=AVC_PATH msg=audit(07/29/2006 09:51:16.042:69) : path= > type=SYSCALL msg=audit(07/29/2006 09:51:16.042:69) : arch=i386 > syscall=execve success=yes exit=0 a0=804de0d a1=bf8131a4 a2=bf8131b8 > a3=1 items=2 ppid=4163 pid=4164 auid=tbl uid=root gid=root euid=root > suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 > comm=exe=subj=user_u:system_r:nscd_t:s0 key=(null) > type=AVC msg=audit(07/29/2006 09:51:16.042:69) : avc: denied { read > write } for pid=4164 comm=name=dev=dm-0 ino=853755 > scontext=user_u:system_r:nscd_t:s0 > tcontext=system_u:object_r:shadow_t:s0 tclass=file > type=AVC msg=audit(07/29/2006 09:51:16.042:69) : avc: denied { write > } for pid=4164 comm=name=dev=dm-0 ino=854746 > scontext=user_u:system_r:nscd_t:s0 tcontext=system_u:object_r:etc_t:s0 > tclass=file > > tom This log file seems very screwed up. Any idea what happened to it? From Axel.Thimm at ATrpms.net Mon Jul 31 13:52:56 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 31 Jul 2006 15:52:56 +0200 Subject: Activating selinux: Relabeling before reboot possible? In-Reply-To: <44CE08D3.5010708@redhat.com> References: <20060729140543.GC13284@neu.nirvana> <1154183451.28960.130.camel@erato.phig.org> <44CE08D3.5010708@redhat.com> Message-ID: <20060731135256.GO19516@neu.nirvana> On Mon, Jul 31, 2006 at 09:42:43AM -0400, Daniel J Walsh wrote: > Karsten Wade wrote: > >On Sat, 2006-07-29 at 16:05 +0200, Axel Thimm wrote: > > > >>Hi, > >> > >>I upgraded an old system to FC5. Now I'd like to get selinux running, > >>but I know that once I do it will relable the system upon > >>reboot. Since this is a production system I'd like to keep downtime as > >>low as possible. > >> > >>Can I relabel the system before the reboot or skip relabeling the > >>system upon reboot and relabel on the fly later? If yes, how? :=) > >> > > > > > It will only do this on the initial boot. Not on every reboot. Yes, I was aware of that, the relabeling tool > 5 hours. I rm'd .autorelabel and did it by hand after the reboot. > >I probably know only the "old" method here. > > > >restorecon would work, applied against the entire filesystem; the man > >page is helpful. > > > >You can see all the helpful commands here: > > > >http://fedoraproject.org/wiki/SELinux/Commands > > > >- Karsten > > > >------------------------------------------------------------------------ > > > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Jul 31 13:54:45 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 31 Jul 2006 15:54:45 +0200 Subject: hotplug_t? Message-ID: <20060731135445.GP19516@neu.nirvana> Hi, after upgrading FC4 to FC5 and enabling selinux/targeted/permissive I see lot's of hotplug_t domains. Most prominently every bash login and the default ssh -l root domains (before newrole) are such. This doesn't look right, did the upgrade go wrong somewhere? Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From selinux at gmail.com Mon Jul 31 13:55:58 2006 From: selinux at gmail.com (Tom London) Date: Mon, 31 Jul 2006 06:55:58 -0700 Subject: AVC on install of libutempter ? In-Reply-To: <44CE099A.2030302@redhat.com> References: <4c4ba1530607291007w23e1c8f9u63060a44dc67fa8a@mail.gmail.com> <44CE099A.2030302@redhat.com> Message-ID: <4c4ba1530607310655r7b23fe25qd4bed33cf9e57d5e@mail.gmail.com> On 7/31/06, Daniel J Walsh wrote: > This log file seems very screwed up. Any idea what happened to it? > Sorry, I used the output of 'auseach -i'. Believe this is the 'raw' log file: type=DAEMON_START msg=audit(1154191808.923:9127) auditd start, ver=1.2.5, format=raw, auid=500 res=success, auditd pid=4138 type=CONFIG_CHANGE msg=audit(1154191809.155:65): audit_enabled=1 old=1 by auid=500 subj=system_u:system_r:auditd_t:s0 type=CONFIG_CHANGE msg=audit(1154191809.179:66): audit_backlog_limit=256 old=256 by auid=500 subj=system_u:system_r:auditctl_t:s0 type=USER_END msg=audit(1154191856.525:67): user pid=3912 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: session close acct=root : exe="/usr/sbin/userhelper" (hostname=?, addr=?, terminal=? res=success)' type=USER_CHAUTHTOK msg=audit(1154191876.038:68): user pid=4163 uid=0 auid=500 subj=user_u:system_r:groupadd_t:s0 msg='op=adding group acct=utempter exe="/usr/sbin/groupadd" (hostname=?, addr=?, terminal=pts/0 res=success)' type=AVC msg=audit(1154191876.042:69): avc: denied { write } for pid=4164 comm="nscd" name="group" dev=dm-0 ino=854746 scontext=user_u:system_r:nscd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file type=AVC msg=audit(1154191876.042:69): avc: denied { read write } for pid=4164 comm="nscd" name="gshadow" dev=dm-0 ino=853755 scontext=user_u:system_r:nscd_t:s0 tcontext=system_u:object_r:shadow_t:s0 tclass=file type=SYSCALL msg=audit(1154191876.042:69): arch=40000003 syscall=11 success=yes exit=0 a0=804de0d a1=bf8131a4 a2=bf8131b8 a3=1 items=2 ppid=4163 pid=4164 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="nscd" exe="/usr/sbin/nscd" subj=user_u:system_r:nscd_t:s0 key=(null) type=AVC_PATH msg=audit(1154191876.042:69): path="/etc/gshadow" type=AVC_PATH msg=audit(1154191876.042:69): path="/etc/group" type=EXECVE msg=audit(1154191876.042:69): a0="/usr/sbin/nscd" a1="nscd" a2="-i" a3="group" type=CWD msg=audit(1154191876.042:69): cwd="/" type=PATH msg=audit(1154191876.042:69): item=0 name="/usr/sbin/nscd" inode=8303056 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:nscd_exec_t:s0 type=PATH msg=audit(1154191876.042:69): item=1 name=(null) inode=7798798 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 type=USER_ACCT msg=audit(1154192461.127:70): user pid=4272 uid=0 auid=4294967295 subj=system_u:system_r:crond_t:s0-s0:c0.c255 msg='PAM: accounting acct=root : exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)' type=LOGIN msg=audit(1154192461.127:71): login pid=4272 uid=0 old auid=4294967295 new auid=0 tom -- Tom London From sds at tycho.nsa.gov Mon Jul 31 14:05:16 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 31 Jul 2006 10:05:16 -0400 Subject: hotplug_t? In-Reply-To: <20060731135445.GP19516@neu.nirvana> References: <20060731135445.GP19516@neu.nirvana> Message-ID: <1154354716.1447.34.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2006-07-31 at 15:54 +0200, Axel Thimm wrote: > Hi, > > after upgrading FC4 to FC5 and enabling selinux/targeted/permissive I > see lot's of hotplug_t domains. Most prominently every bash login and > the default ssh -l root domains (before newrole) are such. This > doesn't look right, did the upgrade go wrong somewhere? Presumably, as that definitely isn't correct. /usr/sbin/sestatus -v -- Stephen Smalley National Security Agency From dwalsh at redhat.com Mon Jul 31 14:41:42 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Jul 2006 10:41:42 -0400 Subject: hotplug_t? In-Reply-To: <20060731135445.GP19516@neu.nirvana> References: <20060731135445.GP19516@neu.nirvana> Message-ID: <44CE16A6.4050305@redhat.com> Axel Thimm wrote: > Hi, > > after upgrading FC4 to FC5 and enabling selinux/targeted/permissive I > see lot's of hotplug_t domains. Most prominently every bash login and > the default ssh -l root domains (before newrole) are such. This > doesn't look right, did the upgrade go wrong somewhere? > > Thanks! > Sounds like you have a major labeling problem. touch /.autorelabel; reboot > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From paul at city-fan.org Mon Jul 31 16:15:47 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 31 Jul 2006 17:15:47 +0100 Subject: Policy Module Packaging Guidelines (first draft) Message-ID: <44CE2CB3.7070509@city-fan.org> I've written up my thoughts on packaging policy modules with applications: http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules Fire away! Paul. From linux_4ever at yahoo.com Mon Jul 31 17:04:47 2006 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 31 Jul 2006 10:04:47 -0700 (PDT) Subject: AVC on install of libutempter ? In-Reply-To: <44CE099A.2030302@redhat.com> Message-ID: <20060731170447.31635.qmail@web51512.mail.yahoo.com> >This log file seems very screwed up. Any idea what happened to it? There is a bug in the audit package that is fixed in 1.2.6 which should be released today/tomorrow. Any "untrusted string" gets deleted in the output. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From wart at kobold.org Mon Jul 31 17:18:42 2006 From: wart at kobold.org (Wart) Date: Mon, 31 Jul 2006 10:18:42 -0700 Subject: Policy Module Packaging Guidelines (first draft) In-Reply-To: <44CE2CB3.7070509@city-fan.org> References: <44CE2CB3.7070509@city-fan.org> Message-ID: <44CE3B72.4010605@kobold.org> Paul Howarth wrote: > I've written up my thoughts on packaging policy modules with applications: > > http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules > > Fire away! Looks good! * s/scrope/scope/ * In the 'separate subpackage' section do you want to add a note about making the -selinux subpackage an entirely new package with its own specfile, instead of a subpackage in an existing spec file? Advantages: Keeps the spec files much simpler and easier to read. Allows for separate maintainers of the main and -selinux packages. selinux packages can be updated without pushing new builds of the main package Disadvantages: Care must be taken to make sure that the selinux package is updated with the main package as needed. What value should be given for the URL and License tags in the spec file? * I like the inclusion of the source files in %doc. That can be extremely useful. * You should note that you can't use 'service myapp condrestart' in %postun to transition a daemon process back to the unconfined domain after the module has been unloaded. You have to first transition the daemon domain, then remove the policy module. Otherwise the process will end up in an odd state and can't be killed until selinux is disabled: %postun selinux /usr/sbin/setsebool %{name}_disable_trans 1 /sbin/service %{name} condrestart > /dev/null 2>&1 || : for selinuxvariant in %{selinux_variants} ; do /usr/sbin/semodule -s ${selinuxvariant} -r mymodule &> /dev/null || : done * How should the selinux policy module be versioned? Should it match the application versioning? Are there any restrictions on policy module version numbers? * Using %{name} instead of 'myapp' in the templates would make it easier to copy/paste them into existing packages * Don't you want to call 'fixfiles -R' in the %post and %postun sections of the sample templates? You included it in the scriptlets section above. --Mike From mattdm at mattdm.org Mon Jul 31 17:26:46 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 31 Jul 2006 13:26:46 -0400 Subject: Policy Module Packaging Guidelines (first draft) In-Reply-To: <44CE3B72.4010605@kobold.org> References: <44CE2CB3.7070509@city-fan.org> <44CE3B72.4010605@kobold.org> Message-ID: <20060731172646.GA16097@jadzia.bu.edu> On Mon, Jul 31, 2006 at 10:18:42AM -0700, Wart wrote: > * s/scrope/scope/ It's a wiki, you know. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jbrindle at tresys.com Mon Jul 31 19:53:22 2006 From: jbrindle at tresys.com (Joshua Brindle) Date: Mon, 31 Jul 2006 15:53:22 -0400 Subject: 2007 SELinux Symposium dates and call for papers Message-ID: <6FE441CD9F0C0C479F2D88F959B0158832AA99@exchange.columbia.tresys.com> The Security Enhanced Linux (SELinux) Symposium announces that its third annual Symposium is scheduled for March 12-16, 2007, at the Wyndham Hotel, Baltimore, Maryland, USA. The Symposium also announces the opening of its call for papers. The event is the only of its kind to examine SELinux and the power of the flexible mandatory access control security it brings to Linux. The first two years of this annual event were a tremendous success providing the SELinux development and user community the opportunity to discuss related research results, development plans, and applications. The call for papers is open until October 9, 2006. Paper requirements and topics of interest are available on the Symposium web site at www.selinux-symposium.org.