From frankly3d at gmail.com Tue Jul 1 14:44:19 2008 From: frankly3d at gmail.com (Frank Murphy) Date: Tue, 01 Jul 2008 15:44:19 +0100 Subject: Mislabeled files Message-ID: <1214923459.12571.5.camel@frank-01> I have no idea which dir to relabel? and wouldl this dir relabel hold, after a full relabel? #locate comes up empty even after #updatedb $ rpm -qa | grep selinux selinux-policy-3.3.1-69.fc9.noarch libselinux-2.0.64-2.fc9.i386 libselinux-python-2.0.64-2.fc9.i386 selinux-policy-targeted-3.3.1-69.fc9.noarch ----------------------------------------------------------------------- Summary: SELinux is preventing the sendmail from using potentially mislabeled files (2F746D702F52734B6B436E774F202864656C6574656429). Detailed Description: SELinux has denied sendmail access to potentially mislabeled file(s) (2F746D702F52734B6B436E774F202864656C6574656429). This means that SELinux will not allow sendmail to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing Access: If you want sendmail to access this files, you need to relabel them using restorecon -v '2F746D702F52734B6B436E774F202864656C6574656429'. You might want to relabel the entire directory using restorecon -R -v ''. Additional Information: Source Context system_u:system_r:exim_t:s0 Target Context system_u:object_r:system_mail_tmp_t:s0 Target Objects 2F746D702F52734B6B436E774F202864656C6574656429 [ file ] Source sendmail Source Path /usr/sbin/exim Port Host frank-01 Source RPM Packages exim-4.69-4.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-69.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name home_tmp_bad_labels Host Name frank-01 Platform Linux frank-01 2.6.25.6-55.fc9.i686 #1 SMP Tue Jun 10 16:27:49 EDT 2008 i686 i686 Alert Count 1 First Seen Tue 01 Jul 2008 15:22:49 IST Last Seen Tue 01 Jul 2008 15:22:49 IST Local ID baefd44f-8e96-4353-8db7-badf98ef6335 Line Numbers Raw Audit Messages host=frank-01 type=AVC msg=audit(1214922169.332:32): avc: denied { read } for pid=11248 comm="sendmail" path=2F746D702F52734B6B436E774F202864656C6574656429 dev=dm-0 ino=34537 scontext=system_u:system_r:exim_t:s0 tcontext=system_u:object_r:system_mail_tmp_t:s0 tclass=file host=frank-01 type=SYSCALL msg=audit(1214922169.332:32): arch=40000003 syscall=11 success=yes exit=0 a0=8058e0b a1=9eb060c a2=bf93c6e8 a3=9eb060c items=0 ppid=11247 pid=11248 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sendmail" exe="/usr/sbin/exim" subj=system_u:system_r:exim_t:s0 key=(null) -- skype: Frankly3D http://www.frankly3d.com From jdennis at redhat.com Tue Jul 1 15:29:11 2008 From: jdennis at redhat.com (John Dennis) Date: Tue, 01 Jul 2008 11:29:11 -0400 Subject: Mislabeled files In-Reply-To: <1214923459.12571.5.camel@frank-01> References: <1214923459.12571.5.camel@frank-01> Message-ID: <486A4D47.8080904@redhat.com> Frank Murphy wrote: > I have no idea which dir to relabel? > and wouldl this dir relabel hold, after a full relabel? > > #locate comes up empty even after #updatedb > > $ rpm -qa | grep selinux > selinux-policy-3.3.1-69.fc9.noarch > libselinux-2.0.64-2.fc9.i386 > libselinux-python-2.0.64-2.fc9.i386 > selinux-policy-targeted-3.3.1-69.fc9.noarch > > > ----------------------------------------------------------------------- > > Summary: > > SELinux is preventing the sendmail from using potentially mislabeled > files > (2F746D702F52734B6B436E774F202864656C6574656429). > > Detailed Description: > > SELinux has denied sendmail access to potentially mislabeled file(s) > (2F746D702F52734B6B436E774F202864656C6574656429). This means that > SELinux will > not allow sendmail to use these files. It is common for users to edit > files in > their home directory or tmp directories and then move (mv) them to > system > directories. The problem is that the files end up with the wrong file > context > which confined applications are not allowed to access. > > Allowing Access: > > If you want sendmail to access this files, you need to relabel them > using > restorecon -v '2F746D702F52734B6B436E774F202864656C6574656429'. You > might want > to relabel the entire directory using restorecon -R -v ''. > > Additional Information: > > Source Context system_u:system_r:exim_t:s0 > Target Context system_u:object_r:system_mail_tmp_t:s0 > Target Objects > 2F746D702F52734B6B436E774F202864656C6574656429 [ > file ] > Source sendmail > Source Path /usr/sbin/exim > Port > Host frank-01 > Source RPM Packages exim-4.69-4.fc9 > Target RPM Packages > Policy RPM selinux-policy-3.3.1-69.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name home_tmp_bad_labels > Host Name frank-01 > Platform Linux frank-01 2.6.25.6-55.fc9.i686 #1 SMP > Tue Jun > 10 16:27:49 EDT 2008 i686 i686 > Alert Count 1 > First Seen Tue 01 Jul 2008 15:22:49 IST > Last Seen Tue 01 Jul 2008 15:22:49 IST > Local ID baefd44f-8e96-4353-8db7-badf98ef6335 > Line Numbers > > Raw Audit Messages > > host=frank-01 type=AVC msg=audit(1214922169.332:32): avc: denied > { read } for pid=11248 comm="sendmail" > path=2F746D702F52734B6B436E774F202864656C6574656429 dev=dm-0 ino=34537 > scontext=system_u:system_r:exim_t:s0 > tcontext=system_u:object_r:system_mail_tmp_t:s0 tclass=file > > host=frank-01 type=SYSCALL msg=audit(1214922169.332:32): arch=40000003 > syscall=11 success=yes exit=0 a0=8058e0b a1=9eb060c a2=bf93c6e8 > a3=9eb060c items=0 ppid=11247 pid=11248 auid=4294967295 uid=0 gid=0 > euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 > comm="sendmail" exe="/usr/sbin/exim" subj=system_u:system_r:exim_t:s0 > key=(null) > > > > The mysterious string is hexidecimal encoded, which decodes to: /tmp/RsKkCnwO (deleted) Which means by the time the kernel emitted the event the file /tmp/RsKkCnwO had been unlinked from the file system. Setroubleshoot should have decoded the hexidecimal representation, I'm not sure why it didn't. -- John Dennis From frankly3d at gmail.com Tue Jul 1 15:45:44 2008 From: frankly3d at gmail.com (Frank Murphy) Date: Tue, 01 Jul 2008 16:45:44 +0100 Subject: Mislabeled files In-Reply-To: <486A4D47.8080904@redhat.com> References: <1214923459.12571.5.camel@frank-01> <486A4D47.8080904@redhat.com> Message-ID: <1214927145.14027.0.camel@frank-01> On Tue, 2008-07-01 at 11:29 -0400, John Dennis wrote: > Frank Murphy wrote: > - > > > > Summary: > > > > SELinux is preventing the sendmail from using potentially mislabeled > > files > > (2F746D702F52734B6B436E774F202864656C6574656429). > > > > > > > The mysterious string is hexidecimal encoded, which decodes to: > > /tmp/RsKkCnwO (deleted) > > Which means by the time the kernel emitted the event the file > /tmp/RsKkCnwO had been unlinked from the file system. > > Setroubleshoot should have decoded the hexidecimal representation, I'm > not sure why it didn't. > > [root at frank-01 /]# restorecon -R -v '/tmp' restorecon reset /tmp/.X11-unix context system_u:object_r:xdm_xserver_tmp_t:s0->system_u:object_r:xdm_tmp_t:s0 That looks ok? Frank -- skype: Frankly3D http://www.frankly3d.com From drew.einhorn at gmail.com Tue Jul 1 18:32:58 2008 From: drew.einhorn at gmail.com (drew einhorn) Date: Tue, 1 Jul 2008 12:32:58 -0600 Subject: setroubleshoot Message-ID: I used to struggle with troubleshooting selinux problems, until I discovered setroubleshoot, a package that runs under X, that really makes it a lot easier, but I really don't want to run X on all my vms. Does anyone here know of an equivalent that doesn't require X? -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Tue Jul 1 19:15:32 2008 From: jdennis at redhat.com (John Dennis) Date: Tue, 01 Jul 2008 15:15:32 -0400 Subject: setroubleshoot In-Reply-To: References: Message-ID: <486A8254.4070605@redhat.com> drew einhorn wrote: > I used to struggle with troubleshooting selinux problems, > until I discovered setroubleshoot, a package that > runs under X, that really makes it a lot easier, but I really > don't want to run X on all my vms. > > Does anyone here know of an equivalent that doesn't > require X? setroubleshoot also runs without X, e.g. without a GUI. Instead of installing the package setroubleshoot install the package setroubleshoot-server. To see your alerts run 'sealert -l *' or to get email sent to you when an alert occurs edit /var/lib/setroubleshoot/email_alert_recipients, add a line containing your email address, if you only want email the first time an alert fires and not subsuequently add "filter_type=after_first" after the email address. -- John Dennis From rstory at sparta.com Tue Jul 1 23:37:04 2008 From: rstory at sparta.com (Robert Story) Date: Tue, 1 Jul 2008 19:37:04 -0400 Subject: kerberos server + enforcing mode? Message-ID: <20080701193704.36814ade@sparta.com> Hi, I'm trying to set up a kerberos KDC on a clean up-to-date F9 box in enforcing mode. I'm following an online tutorial, and I get to the point where I'm trying to set the default policy, and the command fails with "modify_principal: Insufficient access to lock database". Some googling turned up 2 suggestions: switcing to permissive mode, or stopping kadmin and restarting it manually, instead of using the service command. Both of those solutions worked. Is there some policy piece missing? Also, I get an error when starting krb5kdc: Starting Kerberos 5 KDC: Couldn't open log file /var/log/krb5kdc.log: Permission denied The accompanying avc is: Jul 1 18:04:55 tib kernel: type=1400 audit(1214949895.536:4): avc: denied { create } for pid=1839 comm="krb5kdc" name="krb5kdc.log" scontext=unconfined_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:krb5kdc_log_t:s0 tclass=file kadmind starts fine, and kadmind.log is created without a problem... -- Robert Story SPARTA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cra at WPI.EDU Wed Jul 2 03:44:47 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 1 Jul 2008 23:44:47 -0400 Subject: xinetd rsync --daemon problems: fix for F9 In-Reply-To: <20071011220125.GV4751@angus.ind.WPI.EDU> References: <20071011220125.GV4751@angus.ind.WPI.EDU> Message-ID: <20080702034447.GH20486@angus.ind.WPI.EDU> I still have a problem with rsyncd.lock on Fedora 9. The symptoms are that after "a while"--several days perhaps, rsync transfers fail with this message: @ERROR: failed to open lock file rsync error: error starting client-server protocol (code 5) at main.c(1296) [receiver=2.6.8] Here is the lock file: -rw------- root root system_u:object_r:var_run_t:s0 /var/run/rsyncd.lock AVC messages: type=AVC msg=audit(1214969369.745:4847): avc: denied { lock } for pid=32590 comm="rsync" path="/var/run/rsyncd.lock" dev=dm-3 ino=106537 scontext=unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file type=AVC msg=audit(1214969379.283:4850): avc: denied { read write } for pid=32594 comm="rsync" name="rsyncd.lock" dev=dm-3 ino=106537 scontext=unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file This policy module fixes the issue: module rsync 1.0; require { type var_run_t; type rsync_t; class file { read write lock }; } #============= rsync_t ============== allow rsync_t var_run_t:file { read write lock }; On Thu, Oct 11, 2007 at 06:01:25PM -0400, Chuck Anderson wrote: > I'm using Fedora Core 6, and trying to start a rsync daemon via > xinetd. > > type=AVC msg=audit(1192132336.713:3464): avc: denied { lock } for > pid=8488 comm="rsync" name="rsyncd.lock" dev=dm-4 ino=2064435 > scontext=user_u:system_r:rsync_t:s0 > tcontext=root:object_r:var_run_t:s0 tclass=file > > type=SYSCALL msg=audit(1192132336.713:3464): arch=40000003 syscall=221 > success=no exit=-13 a0=4 a1=d a2=bff80730 a3=bff80730 items=0 > ppid=8167 pid=8488 auid=10002 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=(none) comm="rsync" exe="/usr/bin/rsync" > subj=user_u:system_r:rsync_t:s0 key=(null) > type=AVC_PATH msg=audit(1192132336.713:3464): > path="/var/run/rsyncd.lock" From sundaram at fedoraproject.org Wed Jul 2 06:52:20 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 02 Jul 2008 12:22:20 +0530 Subject: Fedora SELinux FAQ Message-ID: <486B25A4.6060609@fedoraproject.org> Hi, The SELinux FAQ has been not updated from Fedora Core 5. I copied over and rewrote some of the common questions to https://fedoraproject.org/wiki/SELinux/FAQ If anyone wants to help, just edit the wiki directly. We can publish this in docs.fp.o if there is sufficient interest. Rahul From kuester at cs.uni-bonn.de Wed Jul 2 10:03:29 2008 From: kuester at cs.uni-bonn.de (Christian Kuester) Date: Wed, 02 Jul 2008 12:03:29 +0200 Subject: Adding local nodecons Message-ID: <486B5271.1080105@cs.uni-bonn.de> Hi List, I'm using Fedora 8 and would like to put types on various nodes. What would be the best way to do it since semanage seems to support doing nodecons on specific nodes. Do I have to rebuild the complete policy or is there some more convienent way to do it? For example in a new local policy? Kind regards, Chris From sds at tycho.nsa.gov Wed Jul 2 11:44:15 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 02 Jul 2008 07:44:15 -0400 Subject: Fedora SELinux FAQ In-Reply-To: <486B25A4.6060609@fedoraproject.org> References: <486B25A4.6060609@fedoraproject.org> Message-ID: <1214999055.22447.235.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-07-02 at 12:22 +0530, Rahul Sundaram wrote: > Hi, > > The SELinux FAQ has been not updated from Fedora Core 5. I copied over > and rewrote some of the common questions to > > https://fedoraproject.org/wiki/SELinux/FAQ > > If anyone wants to help, just edit the wiki directly. We can publish > this in docs.fp.o if there is sufficient interest. Thank you for reviving this FAQ! -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed Jul 2 11:51:07 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 02 Jul 2008 07:51:07 -0400 Subject: Fedora SELinux FAQ In-Reply-To: <1214999055.22447.235.camel@moss-spartans.epoch.ncsc.mil> References: <486B25A4.6060609@fedoraproject.org> <1214999055.22447.235.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1214999467.22447.243.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-07-02 at 07:44 -0400, Stephen Smalley wrote: > On Wed, 2008-07-02 at 12:22 +0530, Rahul Sundaram wrote: > > Hi, > > > > The SELinux FAQ has been not updated from Fedora Core 5. I copied over > > and rewrote some of the common questions to > > > > https://fedoraproject.org/wiki/SELinux/FAQ > > > > If anyone wants to help, just edit the wiki directly. We can publish > > this in docs.fp.o if there is sufficient interest. > > Thank you for reviving this FAQ! BTW, while a Fedora-specific FAQ may also be appropriate, it would be nice if the more general portions of this FAQ could be taken to selinuxproject.org and handled by the upstream selinux project. -- Stephen Smalley National Security Agency From sundaram at fedoraproject.org Wed Jul 2 11:57:58 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 02 Jul 2008 17:27:58 +0530 Subject: Fedora SELinux FAQ In-Reply-To: <1214999467.22447.243.camel@moss-spartans.epoch.ncsc.mil> References: <486B25A4.6060609@fedoraproject.org> <1214999055.22447.235.camel@moss-spartans.epoch.ncsc.mil> <1214999467.22447.243.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <486B6D46.3020803@fedoraproject.org> Stephen Smalley wrote: > On Wed, 2008-07-02 at 07:44 -0400, Stephen Smalley wrote: >> On Wed, 2008-07-02 at 12:22 +0530, Rahul Sundaram wrote: >>> Hi, >>> >>> The SELinux FAQ has been not updated from Fedora Core 5. I copied over >>> and rewrote some of the common questions to >>> >>> https://fedoraproject.org/wiki/SELinux/FAQ >>> >>> If anyone wants to help, just edit the wiki directly. We can publish >>> this in docs.fp.o if there is sufficient interest. >> Thank you for reviving this FAQ! > > BTW, while a Fedora-specific FAQ may also be appropriate, it would be > nice if the more general portions of this FAQ could be taken to > selinuxproject.org and handled by the upstream selinux project. After I get some revisions out, I can certainly send the non-Fedora specific portions upstream. Rahul From sds at tycho.nsa.gov Wed Jul 2 12:12:05 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 02 Jul 2008 08:12:05 -0400 Subject: Adding local nodecons In-Reply-To: <486B5271.1080105@cs.uni-bonn.de> References: <486B5271.1080105@cs.uni-bonn.de> Message-ID: <1215000725.22447.257.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-07-02 at 12:03 +0200, Christian Kuester wrote: > Hi List, > > I'm using Fedora 8 and would like to put types on various nodes. > What would be the best way to do it since semanage seems to support > doing nodecons on specific nodes. > > Do I have to rebuild the complete policy or is there some more convienent > way to do it? For example in a new local policy? I don't believe this is presently supported by semanage, although the libsemanage infrastructure exists. However, I think what you likely want is to use secmark instead. http://james-morris.livejournal.com/11010.html -- Stephen Smalley National Security Agency From frankly3d at gmail.com Wed Jul 2 12:40:14 2008 From: frankly3d at gmail.com (Frank Murphy) Date: Wed, 2 Jul 2008 13:40:14 +0100 Subject: gconf-2 creating > unlabelled_t files Message-ID: Do I run "cp -P /usr/libexec/gconfd-2" ----------------------------------------------------- Summary: SELinux is preventing gconfd-2 from creating a file with a context of unlabeled_t on a filesystem. Detailed Description: SELinux is preventing gconfd-2 from creating a file with a context of unlabeled_t on a filesystem. Usually this happens when you ask the cp command to maintain the context of a file when copying between file systems, "cp -a" for example. Not all file contexts should be maintained between the file systems. For example, a read-only file type like iso9660_t should not be placed on a r/w system. "cp -P" might be a better solution, as this will adopt the default file context for the destination. Allowing Access: Use a command like "cp -P" to preserve all permissions except SELinux context. Additional Information: Source Context unconfined_u:object_r:unlabeled_t:s0 Target Context system_u:object_r:fs_t:s0 Target Objects .testing.writeability [ filesystem ] Source gconfd-2 Source Path /usr/libexec/gconfd-2 Port Host frank-03 Source RPM Packages GConf2-2.22.0-1.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-72.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name filesystem_associate Host Name frank-03 Platform Linux frank-03 2.6.25.6-55.fc9.i686 #1 SMP Tue Jun 10 16:27:49 EDT 2008 i686 i686 Alert Count 1 First Seen Wed 02 Jul 2008 12:06:53 IST Last Seen Wed 02 Jul 2008 12:06:53 IST Local ID 9af5a524-6e39-40da-a8f0-146b28ebee10 Line Numbers Raw Audit Messages host=frank-03 type=AVC msg=audit(1214996813.541:52): avc: denied { associate } for pid=9827 comm="gconfd-2" name=".testing.writeability" scontext=unconfined_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem host=frank-03 type=SYSCALL msg=audit(1214996813.541:52): arch=40000003 syscall=5 success=no exit=-13 a0=8652d18 a1=41 a2=1c0 a3=8652d18 items=0 ppid=1 pid=9827 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="gconfd-2" exe="/usr/libexec/gconfd-2" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) From kuester at cs.uni-bonn.de Wed Jul 2 14:32:44 2008 From: kuester at cs.uni-bonn.de (Christian Kuester) Date: Wed, 02 Jul 2008 16:32:44 +0200 Subject: Adding local nodecons In-Reply-To: <1215000725.22447.257.camel@moss-spartans.epoch.ncsc.mil> References: <486B5271.1080105@cs.uni-bonn.de> <1215000725.22447.257.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <486B918C.4060008@cs.uni-bonn.de> Stephen Smalley schrieb: >> I'm using Fedora 8 and would like to put types on various nodes. >> What would be the best way to do it since semanage seems to support >> doing nodecons on specific nodes. >> > I don't believe this is presently supported by semanage, although the > libsemanage infrastructure exists. > I've seen a older discussion on the NSA-SELinux mailinglist about that. The patch for semanage wasn't commited though. > However, I think what you likely want is to use secmark instead. > http://james-morris.livejournal.com/11010.htm Interesting article. Perhaps I could use this instead of nodecon but it seems much more complex than that. The only thing I want to accomplish is to have a way to restrict node_binds, so that specific programs can only open sockets on 127.0.0.1 (f.i.). Kind regards, Chris From sds at tycho.nsa.gov Wed Jul 2 14:39:54 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 02 Jul 2008 10:39:54 -0400 Subject: Adding local nodecons In-Reply-To: <486B918C.4060008@cs.uni-bonn.de> References: <486B5271.1080105@cs.uni-bonn.de> <1215000725.22447.257.camel@moss-spartans.epoch.ncsc.mil> <486B918C.4060008@cs.uni-bonn.de> Message-ID: <1215009594.22447.278.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-07-02 at 16:32 +0200, Christian Kuester wrote: > Stephen Smalley schrieb: > >> I'm using Fedora 8 and would like to put types on various nodes. > >> What would be the best way to do it since semanage seems to support > >> doing nodecons on specific nodes. > >> > > I don't believe this is presently supported by semanage, although the > > libsemanage infrastructure exists. > > > I've seen a older discussion on the NSA-SELinux mailinglist about that. > The patch > for semanage wasn't commited though. > > However, I think what you likely want is to use secmark instead. > > http://james-morris.livejournal.com/11010.htm > Interesting article. Perhaps I could use this instead of nodecon but it > seems much more > complex than that. The only thing I want to accomplish is to have a way > to restrict > node_binds, so that specific programs can only open sockets on 127.0.0.1 > (f.i.). Ok - then you do want node contexts. As I recall, the patch posted to selinux list circa 2006 for adding semanage node context support didn't actually work correctly and no one chased it down. So if you want to revive it on selinux list and see if we can hunt down the underlying issue, that might be worthwhile. -- Stephen Smalley National Security Agency From cra at WPI.EDU Wed Jul 2 15:27:26 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 2 Jul 2008 11:27:26 -0400 Subject: auditd went crazy Message-ID: <20080702152726.GA32483@angus.ind.WPI.EDU> July 1st at 00:18:02, I started getting thousands of audit messages (hundreds per second). They didn't stop until I did "service auditd restart": I finally noticed the problem when logwatch told me this: audit: audit_backlog=262 > audit_backlog_limit=256 audit: audit_lost=1 audit_rate_limit=0 audit_backlog_limit=256 audit: backlog limit exceeded audit: audit_backlog=262 > audit_backlog_limit=256 audit: audit_lost=2 audit_rate_limit=0 audit_backlog_limit=256 audit: backlog limit exceeded audit: audit_backlog=262 > audit_backlog_limit=256 audit: audit_lost=3 audit_rate_limit=0 audit_backlog_limit=256 audit: backlog limit exceeded audit: audit_backlog=262 > audit_backlog_limit=256 Here is the start of the messages, with a few normal audit messages before it: type=LOGIN msg=audit(07/01/2008 00:10:01.754:139884) : login pid=24775 uid=root old auid=unset new auid=root ---- type=USER_START msg=audit(07/01/2008 00:10:01.755:139885) : user pid=24775 uid=root auid=root subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct=root exe=/usr/sbin/crond (hostname=?, addr=?, terminal=cron res=success)' ---- type=CRED_DISP msg=audit(07/01/2008 00:10:01.763:139886) : user pid=24773 uid=root auid=root subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct=root exe=/usr/sbin/crond (hostname=?, addr=?, terminal=cron res=success)' ---- type=USER_END msg=audit(07/01/2008 00:10:01.763:139887) : user pid=24773 uid=root auid=root subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_close acct=root exe=/usr/sbin/crond (hostname=?, addr=?, terminal=cron res=success)' ---- type=CRED_DISP msg=audit(07/01/2008 00:10:01.770:139888) : user pid=24775 uid=root auid=root subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct=root exe=/usr/sbin/crond (hostname=?, addr=?, terminal=cron res=success)' ---- type=USER_END msg=audit(07/01/2008 00:10:01.770:139889) : user pid=24775 uid=root auid=root subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_close acct=root exe=/usr/sbin/crond (hostname=?, addr=?, terminal=cron res=success)' ---- type=USER_ACCT msg=audit(07/01/2008 00:15:01.775:139890) : user pid=24781 uid=root auid=unset subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct=root exe=/usr/sbin/crond (hostname=?, addr=?, terminal=cron res=success)' ---- type=CRED_ACQ msg=audit(07/01/2008 00:15:01.776:139891) : user pid=24781 uid=root auid=unset subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct=root exe=/usr/sbin/crond (hostname=?, addr=?, terminal=cron res=success)' ---- type=LOGIN msg=audit(07/01/2008 00:15:01.776:139892) : login pid=24781 uid=root old auid=unset new auid=root ---- type=USER_START msg=audit(07/01/2008 00:15:01.777:139893) : user pid=24781 uid=root auid=root subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct=root exe=/usr/sbin/crond (hostname=?, addr=?, terminal=cron res=success)' ---- type=CRED_DISP msg=audit(07/01/2008 00:15:01.791:139894) : user pid=24781 uid=root auid=root subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct=root exe=/usr/sbin/crond (hostname=?, addr=?, terminal=cron res=success)' ---- type=USER_END msg=audit(07/01/2008 00:15:01.791:139895) : user pid=24781 uid=root auid=root subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_close acct=root exe=/usr/sbin/crond (hostname=?, addr=?, terminal=cron res=success)' ---- type=SYSCALL msg=audit(07/01/2008 00:18:02.766:139896) : arch=i386 syscall=execve success=yes exit=0 a0=9c0aa40 a1=9c069a8 a2=9c0ab08 a3=0 items=0 ppid=24821 pid=24826 auid=fs uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none$ type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13697886] dev=sockfs ino=13697886 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692415] dev=sockfs ino=13692415 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692404] dev=sockfs ino=13692404 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692402] dev=sockfs ino=13692402 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692400] dev=sockfs ino=13692400 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692398] dev=sockfs ino=13692398 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692396] dev=sockfs ino=13692396 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692394] dev=sockfs ino=13692394 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692392] dev=sockfs ino=13692392 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692390] dev=sockfs ino=13692390 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692388] dev=sockfs ino=13692388 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692386] dev=sockfs ino=13692386 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692380] dev=sockfs ino=13692380 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692377] dev=sockfs ino=13692377 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692375] dev=sockfs ino=13692375 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692326] dev=sockfs ino=13692326 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692301] dev=sockfs ino=13692301 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692299] dev=sockfs ino=13692299 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692297] dev=sockfs ino=13692297 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692226] dev=sockfs ino=13692226 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692219] dev=sockfs ino=13692219 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692217] dev=sockfs ino=13692217 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13648053] dev=sockfs ino=13648053 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692215] dev=sockfs ino=13692215 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13692087] dev=sockfs ino=13692087 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13698044] dev=sockfs ino=13698044 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13698042] dev=sockfs ino=13698042 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13698039] dev=sockfs ino=13698039 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13698037] dev=sockfs ino=13698037 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13698035] dev=sockfs ino=13698035 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13698033] dev=sockfs ino=13698033 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { read write } for pid=24826 comm=rndc path=socket:[13698029] dev=sockfs ino=13698029 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket ... type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { read write } for pid=9726 comm=rndc path=socket:[13830554] dev=sockfs ino=13830554 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { read write } for pid=9726 comm=rndc path=socket:[13830552] dev=sockfs ino=13830552 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { read write } for pid=9726 comm=rndc path=socket:[13830550] dev=sockfs ino=13830550 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { read write } for pid=9726 comm=rndc path=socket:[13830548] dev=sockfs ino=13830548 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { read write } for pid=9726 comm=rndc path=socket:[13830546] dev=sockfs ino=13830546 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { read write } for pid=9726 comm=rndc path=socket:[13830544] dev=sockfs ino=13830544 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { read write } for pid=9726 comm=rndc path=socket:[13830542] dev=sockfs ino=13830542 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { read write } for pid=9726 comm=rndc path=socket:[13830540] dev=sockfs ino=13830540 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { read write } for pid=9726 comm=rndc path=socket:[13830538] dev=sockfs ino=13830538 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { read write } for pid=9726 comm=rndc path=socket:[13830536] dev=sockfs ino=13830536 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { read write } for pid=9726 comm=rndc path=socket:[13830530] dev=sockfs ino=13830530 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { read write } for pid=9726 comm=rndc path=socket:[13830460] dev=sockfs ino=13830460 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { read write } for pid=9726 comm=rndc path=socket:[13830435] dev=sockfs ino=13830435 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { read write } for pid=9726 comm=rndc path=socket:[13830238] dev=sockfs ino=13830238 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { read write } for pid=9726 comm=rndc path=socket:[13830433] dev=sockfs ino=13830433 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { read write } for pid=9726 comm=rndc path=socket:[13830431] dev=sockfs ino=13830431 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { read write } for pid=9726 comm=rndc path=socket:[13830360] dev=sockfs ino=13830360 scontext=unconfined_u:system_r:ndc_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket Anyone know what happened? From rhally at mindspring.com Wed Jul 2 21:33:15 2008 From: rhally at mindspring.com (Richard Hally) Date: Wed, 02 Jul 2008 17:33:15 -0400 Subject: Fedora SELinux FAQ In-Reply-To: <486B6D46.3020803@fedoraproject.org> References: <486B25A4.6060609@fedoraproject.org> <1214999055.22447.235.camel@moss-spartans.epoch.ncsc.mil> <1214999467.22447.243.camel@moss-spartans.epoch.ncsc.mil> <486B6D46.3020803@fedoraproject.org> Message-ID: <486BF41B.1050406@mindspring.com> Rahul Sundaram wrote: > Stephen Smalley wrote: >> On Wed, 2008-07-02 at 07:44 -0400, Stephen Smalley wrote: >>> On Wed, 2008-07-02 at 12:22 +0530, Rahul Sundaram wrote: >>>> Hi, >>>> >>>> The SELinux FAQ has been not updated from Fedora Core 5. I copied >>>> over and rewrote some of the common questions to >>>> >>>> https://fedoraproject.org/wiki/SELinux/FAQ >>>> >>>> If anyone wants to help, just edit the wiki directly. We can publish >>>> this in docs.fp.o if there is sufficient interest. >>> Thank you for reviving this FAQ! >> >> BTW, while a Fedora-specific FAQ may also be appropriate, it would be >> nice if the more general portions of this FAQ could be taken to >> selinuxproject.org and handled by the upstream selinux project. > > After I get some revisions out, I can certainly send the non-Fedora > specific portions upstream. > > Rahul > speaking of documentation; here is a "how to" for SELinux that may need wider dissemination (in case you missed the link on IRC.) http://domg472.blogspot.com/2008/05/how-to-create-integrate-and-rebuild.html Richard From rhally at mindspring.com Thu Jul 3 04:55:42 2008 From: rhally at mindspring.com (Richard Hally) Date: Thu, 03 Jul 2008 00:55:42 -0400 Subject: Fedora SELinux FAQ In-Reply-To: <486B6D46.3020803@fedoraproject.org> References: <486B25A4.6060609@fedoraproject.org> <1214999055.22447.235.camel@moss-spartans.epoch.ncsc.mil> <1214999467.22447.243.camel@moss-spartans.epoch.ncsc.mil> <486B6D46.3020803@fedoraproject.org> Message-ID: <486C5BCE.6090009@mindspring.com> Rahul Sundaram wrote: > Stephen Smalley wrote: >> On Wed, 2008-07-02 at 07:44 -0400, Stephen Smalley wrote: >>> On Wed, 2008-07-02 at 12:22 +0530, Rahul Sundaram wrote: >>>> Hi, >>>> >>>> The SELinux FAQ has been not updated from Fedora Core 5. I copied >>>> over and rewrote some of the common questions to >>>> >>>> https://fedoraproject.org/wiki/SELinux/FAQ >>>> >>>> If anyone wants to help, just edit the wiki directly. We can publish >>>> this in docs.fp.o if there is sufficient interest. >>> Thank you for reviving this FAQ! >> >> BTW, while a Fedora-specific FAQ may also be appropriate, it would be >> nice if the more general portions of this FAQ could be taken to >> selinuxproject.org and handled by the upstream selinux project. > > After I get some revisions out, I can certainly send the non-Fedora > specific portions upstream. > > Rahul > speaking of documentation; here is a "how to" for SELinux that may need wider dissemination (in case you missed the link on IRC.) http://domg472.blogspot.com/2008/05/how-to-create-integrate-and-rebuild.html Richard From dwalsh at redhat.com Thu Jul 3 18:09:34 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 03 Jul 2008 14:09:34 -0400 Subject: xinetd rsync --daemon problems: fix for F9 In-Reply-To: <20080702034447.GH20486@angus.ind.WPI.EDU> References: <20071011220125.GV4751@angus.ind.WPI.EDU> <20080702034447.GH20486@angus.ind.WPI.EDU> Message-ID: <486D15DE.6030903@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck Anderson wrote: > I still have a problem with rsyncd.lock on Fedora 9. > > The symptoms are that after "a while"--several days perhaps, rsync > transfers fail with this message: > > @ERROR: failed to open lock file > rsync error: error starting client-server protocol (code 5) at > main.c(1296) > [receiver=2.6.8] > > Here is the lock file: > > -rw------- root root system_u:object_r:var_run_t:s0 /var/run/rsyncd.lock > > AVC messages: > > type=AVC msg=audit(1214969369.745:4847): avc: denied { lock } for > pid=32590 comm="rsync" path="/var/run/rsyncd.lock" dev=dm-3 ino=106537 > scontext=unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:var_run_t:s0 tclass=file > > type=AVC msg=audit(1214969379.283:4850): avc: denied { read write } > for pid=32594 comm="rsync" name="rsyncd.lock" dev=dm-3 ino=106537 > scontext=unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:var_run_t:s0 tclass=file > > This policy module fixes the issue: > > module rsync 1.0; > > require { > type var_run_t; > type rsync_t; > class file { read write lock }; > } > > #============= rsync_t ============== > allow rsync_t var_run_t:file { read write lock }; > > > On Thu, Oct 11, 2007 at 06:01:25PM -0400, Chuck Anderson wrote: >> I'm using Fedora Core 6, and trying to start a rsync daemon via >> xinetd. >> >> type=AVC msg=audit(1192132336.713:3464): avc: denied { lock } for >> pid=8488 comm="rsync" name="rsyncd.lock" dev=dm-4 ino=2064435 >> scontext=user_u:system_r:rsync_t:s0 >> tcontext=root:object_r:var_run_t:s0 tclass=file >> >> type=SYSCALL msg=audit(1192132336.713:3464): arch=40000003 syscall=221 >> success=no exit=-13 a0=4 a1=d a2=bff80730 a3=bff80730 items=0 >> ppid=8167 pid=8488 auid=10002 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 >> sgid=0 fsgid=0 tty=(none) comm="rsync" exe="/usr/bin/rsync" >> subj=user_u:system_r:rsync_t:s0 key=(null) >> type=AVC_PATH msg=audit(1192132336.713:3464): >> path="/var/run/rsyncd.lock" > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Chuck the problem here is labeling. chcon -t rsync_var_run_t /var/run/rsyncd.lock I will make this the default label in Update 76 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhtFd4ACgkQrlYvE4MpobNQXwCfUOQzUMAYCE0MJXBBtIPGt2gK kIcAniUHitExHVnxBjKr4GzKtNXDZ/Ma =/OtC -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Jul 3 18:38:32 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 03 Jul 2008 14:38:32 -0400 Subject: Creating a custom user role In-Reply-To: <20080630112643.20a8cad8@hzhangpg02.ph.man.ac.uk> References: <20080630112643.20a8cad8@hzhangpg02.ph.man.ac.uk> Message-ID: <486D1CA8.80609@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonathan Stott wrote: > Hi > > I'm on FC9, and I would like to create a user based on guest_u who is almost as unprivileged as that role, but is allowed to ssh out. > > So I opened up the polgengui tool kit and selected 'minimal terminal user role' > > I then also allowed it access to the guest role as an additional role. (I'm not sure if this step is required) > > I then allowed the role to connect to port 22 > > And then made the policy files. > > On running the script, I got the message '/usr/sbin/semanage: You must > specify a prefix', which lead me to look a little closer at the generated file. One thing I noticed was that amongst the roles to be assigned to the new role was 'system_r', which I believe is the system administration role, so removing that and adding a prefix of user, I could then run the script and install the role. > > Adding it as the role for the user I want to allow ssh access out to, I then tried to login, which got me the message > > Unable to get valid context for username > > Setting the user to guest_u or user_u works fine, though. What did I do wrong? > > Regards, > Jonathan. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Grab the policycoreutils in Fedora Updates. This item should be fixed there. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhtHFQACgkQrlYvE4MpobMnxQCgyYH4nWMPBfsknMFyUBQeyDNh oY8AoMUVFqxEimuWGl0JV2ZCSx7ER+mO =UdIt -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Jul 3 18:43:47 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 03 Jul 2008 14:43:47 -0400 Subject: Mislabeled files In-Reply-To: <1214923459.12571.5.camel@frank-01> References: <1214923459.12571.5.camel@frank-01> Message-ID: <486D1DE3.5030809@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank Murphy wrote: > I have no idea which dir to relabel? > and wouldl this dir relabel hold, after a full relabel? > > #locate comes up empty even after #updatedb > > $ rpm -qa | grep selinux > selinux-policy-3.3.1-69.fc9.noarch > libselinux-2.0.64-2.fc9.i386 > libselinux-python-2.0.64-2.fc9.i386 > selinux-policy-targeted-3.3.1-69.fc9.noarch > > > ----------------------------------------------------------------------- > > Summary: > > SELinux is preventing the sendmail from using potentially mislabeled > files > (2F746D702F52734B6B436E774F202864656C6574656429). > > Detailed Description: > > SELinux has denied sendmail access to potentially mislabeled file(s) > (2F746D702F52734B6B436E774F202864656C6574656429). This means that > SELinux will > not allow sendmail to use these files. It is common for users to edit > files in > their home directory or tmp directories and then move (mv) them to > system > directories. The problem is that the files end up with the wrong file > context > which confined applications are not allowed to access. > > Allowing Access: > > If you want sendmail to access this files, you need to relabel them > using > restorecon -v '2F746D702F52734B6B436E774F202864656C6574656429'. You > might want > to relabel the entire directory using restorecon -R -v ''. > > Additional Information: > > Source Context system_u:system_r:exim_t:s0 > Target Context system_u:object_r:system_mail_tmp_t:s0 > Target Objects > 2F746D702F52734B6B436E774F202864656C6574656429 [ > file ] > Source sendmail > Source Path /usr/sbin/exim > Port > Host frank-01 > Source RPM Packages exim-4.69-4.fc9 > Target RPM Packages > Policy RPM selinux-policy-3.3.1-69.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name home_tmp_bad_labels > Host Name frank-01 > Platform Linux frank-01 2.6.25.6-55.fc9.i686 #1 SMP > Tue Jun > 10 16:27:49 EDT 2008 i686 i686 > Alert Count 1 > First Seen Tue 01 Jul 2008 15:22:49 IST > Last Seen Tue 01 Jul 2008 15:22:49 IST > Local ID baefd44f-8e96-4353-8db7-badf98ef6335 > Line Numbers > > Raw Audit Messages > > host=frank-01 type=AVC msg=audit(1214922169.332:32): avc: denied > { read } for pid=11248 comm="sendmail" > path=2F746D702F52734B6B436E774F202864656C6574656429 dev=dm-0 ino=34537 > scontext=system_u:system_r:exim_t:s0 > tcontext=system_u:object_r:system_mail_tmp_t:s0 tclass=file > > host=frank-01 type=SYSCALL msg=audit(1214922169.332:32): arch=40000003 > syscall=11 success=yes exit=0 a0=8058e0b a1=9eb060c a2=bf93c6e8 > a3=9eb060c items=0 ppid=11247 pid=11248 auid=4294967295 uid=0 gid=0 > euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 > comm="sendmail" exe="/usr/sbin/exim" subj=system_u:system_r:exim_t:s0 > key=(null) > > > This is actually a bug in policy, and setroubleshoot should have told you to use audit2allow to allow it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhtHeMACgkQrlYvE4MpobMgFQCfdGq2S5vm9RpX+qJlwJTAVXnQ k6wAoK0Grmrl8OsrCKUu/AQKt6KwkgPr =ndY1 -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Jul 3 18:56:11 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 03 Jul 2008 14:56:11 -0400 Subject: kerberos server + enforcing mode? In-Reply-To: <20080701193704.36814ade@sparta.com> References: <20080701193704.36814ade@sparta.com> Message-ID: <486D20CB.2000502@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Story wrote: > Hi, > > I'm trying to set up a kerberos KDC on a clean up-to-date F9 box in > enforcing mode. I'm following an online tutorial, and I get to the > point where I'm trying to set the default policy, and the command fails > with "modify_principal: Insufficient access to lock database". Some > googling turned up 2 suggestions: switcing to permissive mode, or > stopping kadmin and restarting it manually, instead of using the > service command. Both of those solutions worked. Is there some policy > piece missing? > > Also, I get an error when starting krb5kdc: > > Starting Kerberos 5 KDC: Couldn't open log file /var/log/krb5kdc.log: Permission denied > > The accompanying avc is: > > Jul 1 18:04:55 tib kernel: type=1400 audit(1214949895.536:4): avc: denied { create } for pid=1839 comm="krb5kdc" name="krb5kdc.log" scontext=unconfined_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:krb5kdc_log_t:s0 tclass=file > > kadmind starts fine, and kadmind.log is created without a problem... > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Seems you stumbled upon a strange avc. If you type # touch /var/log/krb5kdc.log # restorecon /var/log/krb5kdc.log Then start the service, does it work? If I run your avc through audit2why # audit2allow -w -i /tmp/t ul 1 18:04:55 tib kernel: type=1400 audit(1214949895.536:4): avc: denied { create } for pid=1839 comm="krb5kdc" name="krb5kdc.log" scontext=unconfined_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:krb5kdc_log_t:s0 tclass=file Was caused by: Policy constraint violation. May require adding a type attribute to the domain or type to satisfy the constraint. Constraints are defined in the policy sources in policy/constraints (general), policy/mcs (MCS), and policy/mls (MLS). It tells me you have a constraint violation. Looking further at the context, I see that the krbkdc is running as unconfined_u:system_r:krb5kdc_t And trying to create system_u:system_r:krbkdc_log_t I notice the user parts are different, and I realize the Kerberos has SELinux knowledge in it. So the kerberos libraries are trying to set the file context directly to match what the system says it should be, but SELinux policy does not allow krbkdc_t to create files owned by a different SELinux user (system_u). This is a long way of saying I need to update the policy to allow krbkdc_t to create the file. Fixed in selinux-policy-3.3.1-76.fc9.noarch -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhtIMsACgkQrlYvE4MpobPOxgCfV/Cg9ox3OJMqhF0QXWTHKdnh VUkAnji49eoeoGxlmYwOItZPxRCwyzY/ =TEZb -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Jul 3 18:58:46 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 03 Jul 2008 14:58:46 -0400 Subject: gconf-2 creating > unlabelled_t files In-Reply-To: References: Message-ID: <486D2166.6070208@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank Murphy wrote: > Do I run "cp -P /usr/libexec/gconfd-2" > ----------------------------------------------------- > Summary: > > SELinux is preventing gconfd-2 from creating a file with a context of > unlabeled_t on a filesystem. > > Detailed Description: > > SELinux is preventing gconfd-2 from creating a file with a context of > unlabeled_t on a filesystem. Usually this happens when you ask the cp command to > maintain the context of a file when copying between file systems, "cp -a" for > example. Not all file contexts should be maintained between the file systems. > For example, a read-only file type like iso9660_t should not be placed on a r/w > system. "cp -P" might be a better solution, as this will adopt the default file > context for the destination. > > Allowing Access: > > Use a command like "cp -P" to preserve all permissions except SELinux context. > > Additional Information: > > Source Context unconfined_u:object_r:unlabeled_t:s0 > Target Context system_u:object_r:fs_t:s0 > Target Objects .testing.writeability [ filesystem ] > Source gconfd-2 > Source Path /usr/libexec/gconfd-2 > Port > Host frank-03 > Source RPM Packages GConf2-2.22.0-1.fc9 > Target RPM Packages > Policy RPM selinux-policy-3.3.1-72.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name filesystem_associate > Host Name frank-03 > Platform Linux frank-03 2.6.25.6-55.fc9.i686 #1 SMP Tue Jun > 10 16:27:49 EDT 2008 i686 i686 > Alert Count 1 > First Seen Wed 02 Jul 2008 12:06:53 IST > Last Seen Wed 02 Jul 2008 12:06:53 IST > Local ID 9af5a524-6e39-40da-a8f0-146b28ebee10 > Line Numbers > > Raw Audit Messages > > host=frank-03 type=AVC msg=audit(1214996813.541:52): avc: denied { > associate } for pid=9827 comm="gconfd-2" name=".testing.writeability" > scontext=unconfined_u:object_r:unlabeled_t:s0 > tcontext=system_u:object_r:fs_t:s0 tclass=filesystem > > host=frank-03 type=SYSCALL msg=audit(1214996813.541:52): arch=40000003 > syscall=5 success=no exit=-13 a0=8652d18 a1=41 a2=1c0 a3=8652d18 > items=0 ppid=1 pid=9827 auid=500 uid=500 gid=500 euid=500 suid=500 > fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="gconfd-2" > exe="/usr/libexec/gconfd-2" > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list restorecon -R -v ~/ Should fix this problem. Also have you udpated to the latest selinux-policy package? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhtIWYACgkQrlYvE4MpobPLOACdGdkv/sS07+C1pHZP5Da77GyR Gd0AnAw75m+PFQvgIztoKC+idJ283KB8 =tLgb -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Jul 3 19:05:08 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 03 Jul 2008 15:05:08 -0400 Subject: auditd went crazy In-Reply-To: <20080702152726.GA32483@angus.ind.WPI.EDU> References: <20080702152726.GA32483@angus.ind.WPI.EDU> Message-ID: <486D22E4.8080101@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck Anderson wrote: > July 1st at 00:18:02, I started getting thousands of audit messages > (hundreds per second). They didn't stop until I did "service auditd > restart": > > I finally noticed the problem when logwatch told me this: > > audit: audit_backlog=262 > audit_backlog_limit=256 > audit: audit_lost=1 audit_rate_limit=0 audit_backlog_limit=256 > audit: backlog limit exceeded > audit: audit_backlog=262 > audit_backlog_limit=256 > audit: audit_lost=2 audit_rate_limit=0 audit_backlog_limit=256 > audit: backlog limit exceeded > audit: audit_backlog=262 > audit_backlog_limit=256 > audit: audit_lost=3 audit_rate_limit=0 audit_backlog_limit=256 > audit: backlog limit exceeded > audit: audit_backlog=262 > audit_backlog_limit=256 > > > Here is the start of the messages, with a few normal audit messages > before it: > > type=LOGIN msg=audit(07/01/2008 00:10:01.754:139884) : login pid=24775 > uid=root old auid=unset new auid=root > ---- > type=USER_START msg=audit(07/01/2008 00:10:01.755:139885) : user > pid=24775 uid=root auid=root > subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open > acct=root exe=/usr/sbin/crond (hostname=?, addr=?, terminal=cron > res=success)' > ---- > type=CRED_DISP msg=audit(07/01/2008 00:10:01.763:139886) : user > pid=24773 uid=root auid=root > subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred > acct=root exe=/usr/sbin/crond (hostname=?, addr=?, terminal=cron > res=success)' > ---- > type=USER_END msg=audit(07/01/2008 00:10:01.763:139887) : user > pid=24773 uid=root auid=root > subj=system_u:system_r:crond_t:s0-s0:c0.c1023 > msg='op=PAM:session_close acct=root exe=/usr/sbin/crond (hostname=?, > addr=?, terminal=cron res=success)' > ---- > type=CRED_DISP msg=audit(07/01/2008 00:10:01.770:139888) : user > pid=24775 uid=root auid=root > subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred > acct=root exe=/usr/sbin/crond (hostname=?, addr=?, terminal=cron > res=success)' > ---- > type=USER_END msg=audit(07/01/2008 00:10:01.770:139889) : user > pid=24775 uid=root auid=root > subj=system_u:system_r:crond_t:s0-s0:c0.c1023 > msg='op=PAM:session_close acct=root exe=/usr/sbin/crond (hostname=?, > addr=?, terminal=cron res=success)' > ---- > type=USER_ACCT msg=audit(07/01/2008 00:15:01.775:139890) : user > pid=24781 uid=root auid=unset > subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:accounting > acct=root exe=/usr/sbin/crond (hostname=?, addr=?, terminal=cron > res=success)' > ---- > type=CRED_ACQ msg=audit(07/01/2008 00:15:01.776:139891) : user > pid=24781 uid=root auid=unset > subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred > acct=root exe=/usr/sbin/crond (hostname=?, addr=?, terminal=cron > res=success)' > ---- > type=LOGIN msg=audit(07/01/2008 00:15:01.776:139892) : login pid=24781 > uid=root old auid=unset new auid=root > ---- > type=USER_START msg=audit(07/01/2008 00:15:01.777:139893) : user > pid=24781 uid=root auid=root > subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open > acct=root exe=/usr/sbin/crond (hostname=?, addr=?, terminal=cron > res=success)' > ---- > type=CRED_DISP msg=audit(07/01/2008 00:15:01.791:139894) : user > pid=24781 uid=root auid=root > subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred > acct=root exe=/usr/sbin/crond (hostname=?, addr=?, terminal=cron > res=success)' > ---- > type=USER_END msg=audit(07/01/2008 00:15:01.791:139895) : user > pid=24781 uid=root auid=root > subj=system_u:system_r:crond_t:s0-s0:c0.c1023 > msg='op=PAM:session_close acct=root exe=/usr/sbin/crond (hostname=?, > addr=?, terminal=cron res=success)' > ---- > type=SYSCALL msg=audit(07/01/2008 00:18:02.766:139896) : arch=i386 > syscall=execve success=yes exit=0 a0=9c0aa40 a1=9c069a8 a2=9c0ab08 > a3=0 items=0 ppid=24821 pid=24826 auid=fs uid=root gid=root euid=root > suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none$ > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13697886] > dev=sockfs ino=13697886 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692415] > dev=sockfs ino=13692415 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692404] > dev=sockfs ino=13692404 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692402] > dev=sockfs ino=13692402 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692400] > dev=sockfs ino=13692400 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692398] > dev=sockfs ino=13692398 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692396] > dev=sockfs ino=13692396 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692394] > dev=sockfs ino=13692394 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692392] > dev=sockfs ino=13692392 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692390] > dev=sockfs ino=13692390 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692388] > dev=sockfs ino=13692388 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692386] > dev=sockfs ino=13692386 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692380] > dev=sockfs ino=13692380 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692377] > dev=sockfs ino=13692377 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692375] > dev=sockfs ino=13692375 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692326] > dev=sockfs ino=13692326 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692301] > dev=sockfs ino=13692301 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692299] > dev=sockfs ino=13692299 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692297] > dev=sockfs ino=13692297 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692226] > dev=sockfs ino=13692226 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692219] > dev=sockfs ino=13692219 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692217] > dev=sockfs ino=13692217 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13648053] > dev=sockfs ino=13648053 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692215] > dev=sockfs ino=13692215 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13692087] > dev=sockfs ino=13692087 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13698044] > dev=sockfs ino=13698044 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13698042] > dev=sockfs ino=13698042 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13698039] > dev=sockfs ino=13698039 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13698037] > dev=sockfs ino=13698037 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13698035] > dev=sockfs ino=13698035 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13698033] > dev=sockfs ino=13698033 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/01/2008 00:18:02.766:139896) : avc: denied { > read write } for pid=24826 comm=rndc path=socket:[13698029] > dev=sockfs ino=13698029 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > > ... > > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > read write } for pid=9726 comm=rndc path=socket:[13830554] dev=sockfs > ino=13830554 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > read write } for pid=9726 comm=rndc path=socket:[13830552] dev=sockfs > ino=13830552 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > read write } for pid=9726 comm=rndc path=socket:[13830550] dev=sockfs > ino=13830550 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > read write } for pid=9726 comm=rndc path=socket:[13830548] dev=sockfs > ino=13830548 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > read write } for pid=9726 comm=rndc path=socket:[13830546] dev=sockfs > ino=13830546 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > read write } for pid=9726 comm=rndc path=socket:[13830544] dev=sockfs > ino=13830544 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > read write } for pid=9726 comm=rndc path=socket:[13830542] dev=sockfs > ino=13830542 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > read write } for pid=9726 comm=rndc path=socket:[13830540] dev=sockfs > ino=13830540 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > read write } for pid=9726 comm=rndc path=socket:[13830538] dev=sockfs > ino=13830538 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > read write } for pid=9726 comm=rndc path=socket:[13830536] dev=sockfs > ino=13830536 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > read write } for pid=9726 comm=rndc path=socket:[13830530] dev=sockfs > ino=13830530 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > read write } for pid=9726 comm=rndc path=socket:[13830460] dev=sockfs > ino=13830460 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > read write } for pid=9726 comm=rndc path=socket:[13830435] dev=sockfs > ino=13830435 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > read write } for pid=9726 comm=rndc path=socket:[13830238] dev=sockfs > ino=13830238 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > read write } for pid=9726 comm=rndc path=socket:[13830433] dev=sockfs > ino=13830433 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > read write } for pid=9726 comm=rndc path=socket:[13830431] dev=sockfs > ino=13830431 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > read write } for pid=9726 comm=rndc path=socket:[13830360] dev=sockfs > ino=13830360 scontext=unconfined_u:system_r:ndc_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > > Anyone know what happened? > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Seems like you have a mislabeld program running as initrc_t? ps -eZ | grep initrc_t -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhtIuQACgkQrlYvE4MpobO4uwCfRufn9TZLpmnymeykpmNbv0e6 I3UAoK/8wKDksRLHuRP9As+goeZ4oe48 =vkoJ -----END PGP SIGNATURE----- From cra at WPI.EDU Thu Jul 3 20:42:02 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 3 Jul 2008 16:42:02 -0400 Subject: auditd went crazy In-Reply-To: <486D22E4.8080101@redhat.com> References: <20080702152726.GA32483@angus.ind.WPI.EDU> <486D22E4.8080101@redhat.com> Message-ID: <20080703204202.GE3137@angus.ind.WPI.EDU> On Thu, Jul 03, 2008 at 03:05:08PM -0400, Daniel J Walsh wrote: > > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > > read write } for pid=9726 comm=rndc path=socket:[13830433] dev=sockfs > > ino=13830433 scontext=unconfined_u:system_r:ndc_t:s0 > > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > > read write } for pid=9726 comm=rndc path=socket:[13830431] dev=sockfs > > ino=13830431 scontext=unconfined_u:system_r:ndc_t:s0 > > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > > type=AVC msg=audit(07/02/2008 10:54:46.348:144433) : avc: denied { > > read write } for pid=9726 comm=rndc path=socket:[13830360] dev=sockfs > > ino=13830360 scontext=unconfined_u:system_r:ndc_t:s0 > > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > > > > Anyone know what happened? > Seems like you have a mislabeld program running as initrc_t? > > ps -eZ | grep initrc_t No results currently, but I'll keep an eye on it. I see these AVC mostly from "rndc" (part of the bind name server package) and also sometimes from "ifconfig" which is strange because I'm not running a DHCP client, nor NetworkManager, nor any other program that I know of that should be running "ifconfig". type=AVC msg=audit(1214939740.621:142073): avc: denied { read write } for pid=1330 comm="ifconfig" path="socket:[13885742]" dev=sockfs ino=13885742 scontext=unconfined_u:system_r:ifconfig_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(1214939740.621:142073): avc: denied { read write } for pid=1330 comm="ifconfig" path="socket:[13885749]" dev=sockfs ino=13885749 scontext=unconfined_u:system_r:ifconfig_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=AVC msg=audit(1214939740.621:142073): avc: denied { read write } for pid=1330 comm="ifconfig" path="socket:[13885756]" dev=sockfs ino=13885756 scontext=unconfined_u:system_r:ifconfig_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=SYSCALL msg=audit(1214939740.621:142073): arch=40000003 syscall=11 success=yes exit=0 a0=bfe3a0e0 a1=bfe3a110 a2=bfe4ac84 a3=bfe3a0e0 items=0 ppid=1306 pid=1330 auid=10000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ifconfig" exe="/sbin/ifconfig" subj=unconfined_u:system_r:ifconfig_t:s0 key=(null) From dwalsh at redhat.com Thu Jul 3 20:50:15 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 03 Jul 2008 16:50:15 -0400 Subject: Mislabeled files In-Reply-To: <1214927145.14027.0.camel@frank-01> References: <1214923459.12571.5.camel@frank-01> <486A4D47.8080904@redhat.com> <1214927145.14027.0.camel@frank-01> Message-ID: <486D3B87.3070506@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank Murphy wrote: > On Tue, 2008-07-01 at 11:29 -0400, John Dennis wrote: >> Frank Murphy wrote: >> - >>> Summary: >>> >>> SELinux is preventing the sendmail from using potentially mislabeled >>> files >>> (2F746D702F52734B6B436E774F202864656C6574656429). >>> > >>> >> The mysterious string is hexidecimal encoded, which decodes to: >> >> /tmp/RsKkCnwO (deleted) >> >> Which means by the time the kernel emitted the event the file >> /tmp/RsKkCnwO had been unlinked from the file system. >> >> Setroubleshoot should have decoded the hexidecimal representation, I'm >> not sure why it didn't. >> >> > > [root at frank-01 /]# restorecon -R -v '/tmp' > restorecon reset /tmp/.X11-unix context > system_u:object_r:xdm_xserver_tmp_t:s0->system_u:object_r:xdm_tmp_t:s0 > > > That looks ok? > > Frank Frank you will have to add a custom policy module to allow this. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhtO4cACgkQrlYvE4MpobMKLwCguSaPTF/dvuUUMh9jJXlql7HO v9sAn1KV5u7R7ItpokRTqEJe12lJjwHt =ArQG -----END PGP SIGNATURE----- From frankly3d at gmail.com Fri Jul 4 09:51:31 2008 From: frankly3d at gmail.com (Frank Murphy) Date: Fri, 04 Jul 2008 10:51:31 +0100 Subject: Mislabeled files In-Reply-To: <486D1DE3.5030809@redhat.com> References: <1214923459.12571.5.camel@frank-01> <486D1DE3.5030809@redhat.com> Message-ID: <1215165091.23349.0.camel@frank-01> On Thu, 2008-07-03 at 14:43 -0400, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > > This is actually a bug in policy, and setroubleshoot should have told > you to use audit2allow to allow it. > Fully updated, Still getting these on a couple of boxes Fedora9 and (centos5.2) Similar to:- Target Objects: 2F746D702F5273497038477A34202864656C6574656429 [ file ] Frank From tmz at pobox.com Fri Jul 4 13:54:53 2008 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 4 Jul 2008 09:54:53 -0400 Subject: auditd went crazy In-Reply-To: <486D22E4.8080101@redhat.com> References: <20080702152726.GA32483@angus.ind.WPI.EDU> <486D22E4.8080101@redhat.com> Message-ID: <20080704135453.GI8285@inocybe.teonanacatl.org> Daniel J Walsh wrote: > Seems like you have a mislabeld program running as initrc_t? > > ps -eZ | grep initrc_t Are there some docs on how to fix up an programs running as initrc_t (and when it is required to do so)? I notice that puppetd is in this situation on my system, but I don't know if that's a potential problem nor how to correct it if it is. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sometimes I wonder whether the world is being run by smart people who are putting us on or by imbeciles who really mean it. -- Mark Twain -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From kuester at cs.uni-bonn.de Mon Jul 7 08:01:35 2008 From: kuester at cs.uni-bonn.de (Christian Kuester) Date: Mon, 07 Jul 2008 10:01:35 +0200 Subject: Packets are unlabeled over a labeled network interface Message-ID: <4871CD5F.2060108@cs.uni-bonn.de> Hi List, I'm trying to use network interface labeling with Fedora 8. But it doesn't behave like I would assume, so it seems that I'm doing something wrong. Here's the way I did it: I added a type blacknic_netifcon_t in a local module by type blacknic_netifcon_t; and # semanage interface -a -t blacknic_netifcon_t eth1 results of this command seem correct since: # seinfo --netif Netifcon: 2 netifcon eth1 system_u:object_r:blacknic_netifcon_t:s0 system_u:object_r:blacknic_netifcon_t:s0 netifcon lo system_u:object_r:lo_netif_t:s0 - s15:c0.c1023 system_u:object_r:unlabeled_t:s0 - s15:c0.c1023 But packets over this interface are still unlabeled: type=AVC msg=audit(1215170990.011:689777822): avc: denied { send } for pid=30988 comm="socat" saddr=192.168.100.54 src=3 daddr=78.xx.xx.xx dest=1024 netif=eth1 scontext=user_u:user_r:exe_t:s0 tcontext=system_u:object_r:unlabeled_t:s15:c0.c1023 tclass=packet Christian From frankly3d at gmail.com Mon Jul 7 09:02:38 2008 From: frankly3d at gmail.com (Frank Murphy) Date: Mon, 07 Jul 2008 10:02:38 +0100 Subject: audit2allow -M local < /tmp/avcs ? Message-ID: <1215421359.3207.3.camel@frank-01> [root at frank-01 ~]# audit2allow -M local < /tmp/avcs -bash: /tmp/avcs: No such file or directory Where to go next. The logs are mailed to "root at localhost" by exim. What and where need to be allowed. Have already done a /sbin/fixfiles relabel. (mislabelled stuff) To allow for future logs? Frank From frankly3d at gmail.com Mon Jul 7 09:13:12 2008 From: frankly3d at gmail.com (Frank Murphy) Date: Mon, 07 Jul 2008 10:13:12 +0100 Subject: audit2allow -M local < /tmp/avcs ? In-Reply-To: References: <1215421359.3207.3.camel@frank-01> Message-ID: <1215421992.3874.2.camel@frank-01> On Mon, 2008-07-07 at 11:08 +0200, drago01 wrote: > On Mon, Jul 7, 2008 at 11:02 AM, Frank Murphy wrote: > > [root at frank-01 ~]# audit2allow -M local < /tmp/avcs > > -bash: /tmp/avcs: No such file or directory > > > > > > Where to go next. > > > > The logs are mailed to "root at localhost" by exim. > > > > What and where need to be allowed. > > > > Have already done a /sbin/fixfiles relabel. (mislabelled stuff) > > > > To allow for future logs? > > /tmp/avcs ?? I took that verbatim from faq, rather new to this selinux thingey. > The logs are either in /var/log/audit.log (if audit is running) > otherwise in syslog (in this case passing -D to audit2allow will use > them) audit2allow /var/log/audit/audit.log? Frank From drago01 at gmail.com Mon Jul 7 09:08:02 2008 From: drago01 at gmail.com (drago01) Date: Mon, 7 Jul 2008 11:08:02 +0200 Subject: audit2allow -M local < /tmp/avcs ? In-Reply-To: <1215421359.3207.3.camel@frank-01> References: <1215421359.3207.3.camel@frank-01> Message-ID: On Mon, Jul 7, 2008 at 11:02 AM, Frank Murphy wrote: > [root at frank-01 ~]# audit2allow -M local < /tmp/avcs > -bash: /tmp/avcs: No such file or directory > > > Where to go next. > > The logs are mailed to "root at localhost" by exim. > > What and where need to be allowed. > > Have already done a /sbin/fixfiles relabel. (mislabelled stuff) > > To allow for future logs? /tmp/avcs ?? The logs are either in /var/log/audit.log (if audit is running) otherwise in syslog (in this case passing -D to audit2allow will use them) From drago01 at gmail.com Mon Jul 7 09:27:33 2008 From: drago01 at gmail.com (drago01) Date: Mon, 7 Jul 2008 11:27:33 +0200 Subject: audit2allow -M local < /tmp/avcs ? In-Reply-To: <1215421992.3874.2.camel@frank-01> References: <1215421359.3207.3.camel@frank-01> <1215421992.3874.2.camel@frank-01> Message-ID: On Mon, Jul 7, 2008 at 11:13 AM, Frank Murphy wrote: > On Mon, 2008-07-07 at 11:08 +0200, drago01 wrote: >> On Mon, Jul 7, 2008 at 11:02 AM, Frank Murphy wrote: >> > [root at frank-01 ~]# audit2allow -M local < /tmp/avcs >> > -bash: /tmp/avcs: No such file or directory >> > >> > >> > Where to go next. >> > >> > The logs are mailed to "root at localhost" by exim. >> > >> > What and where need to be allowed. >> > >> > Have already done a /sbin/fixfiles relabel. (mislabelled stuff) >> > >> > To allow for future logs? >> >> /tmp/avcs ?? > > I took that verbatim from faq, rather new to this selinux thingey. > >> The logs are either in /var/log/audit.log (if audit is running) >> otherwise in syslog (in this case passing -D to audit2allow will use >> them) > > audit2allow /var/log/audit/audit.log? yes just use this file instead of /tmp/avcs audit2allow -M local < /your/log/file From frankly3d at gmail.com Mon Jul 7 10:40:24 2008 From: frankly3d at gmail.com (Frank Murphy) Date: Mon, 07 Jul 2008 11:40:24 +0100 Subject: fixfiles -relabel error (frrank-01) Message-ID: <1215427224.11177.1.camel@frank-01> [frank at frank-01 ~]$ su - root Password: [root at frank-01 ~]# fixfiles relabel Files in the /tmp directory may be labeled incorrectly, this command can remove all files in /tmp. If you choose to remove files from /tmp, a reboot will be required after completion. Do you wish to clean out the /tmp directory [N]? y Cleaning out /tmp /sbin/setfiles: unable to stat file /home/frank/.gvfs: Permission denied /sbin/setfiles: error while labeling /home: Permission denied /sbin/setfiles: error while labeling /boot: Permission denied I'm guess /home has to be done as su - frank? /boot no idea. From paul at city-fan.org Mon Jul 7 11:05:19 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 07 Jul 2008 12:05:19 +0100 Subject: Upstream status of spamc_t local policy? Message-ID: <4871F86F.2030207@city-fan.org> The Fedora 9 spamassassin module has an interface `spamassassin_domtrans_spamc' and an extensive set of rules labelled as "spamc_t local policy". This is an interface/ruleset that I need to get policy for spamass-milter working again (Bug #447247), and to that end I've created a "milters" policy module (http://www.city-fan.org/~paul/spamass-milter/) that works very well for me. However, I can't really progress this upstream because the `spamassassin_domtrans_spamc' interface and "spamc_t local policy" aren't in upstream refpolicy svn yet. Strangely though, I see comments in the policy labelled "cjp:", which suggests that it's seen upstream review at some point. What's the status of this? For the moment I've encapsulated the non-upstream bits of policy that I need in a "my-sa" module (again at http://www.city-fan.org/~paul/spamass-milter/) and this works fine with my milters module on CentOS 5.2. Paul. From sds at tycho.nsa.gov Mon Jul 7 14:43:44 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 07 Jul 2008 10:43:44 -0400 Subject: Packets are unlabeled over a labeled network interface In-Reply-To: <4871CD5F.2060108@cs.uni-bonn.de> References: <4871CD5F.2060108@cs.uni-bonn.de> Message-ID: <1215441824.27975.80.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2008-07-07 at 10:01 +0200, Christian Kuester wrote: > Hi List, > > I'm trying to use network interface labeling with Fedora 8. But it > doesn't behave like I would assume, so it seems that I'm doing something > wrong. Here's the way I did it: > > I added a type blacknic_netifcon_t in a local module by > type blacknic_netifcon_t; > > and > > # semanage interface -a -t blacknic_netifcon_t eth1 > > results of this command seem correct since: > # seinfo --netif > Netifcon: 2 > netifcon eth1 system_u:object_r:blacknic_netifcon_t:s0 > system_u:object_r:blacknic_netifcon_t:s0 > netifcon lo system_u:object_r:lo_netif_t:s0 - s15:c0.c1023 > system_u:object_r:unlabeled_t:s0 - s15:c0.c1023 > > But packets over this interface are still unlabeled: > type=AVC msg=audit(1215170990.011:689777822): avc: denied { send } for > pid=30988 comm="socat" saddr=192.168.100.54 src=3 daddr=78.xx.xx.xx > dest=1024 netif=eth1 scontext=user_u:user_r:exe_t:s0 > tcontext=system_u:object_r:unlabeled_t:s15:c0.c1023 tclass=packet tclass=packet corresponds to secmark, which is independent/orthogonal of labeled networking. Also, the default message/packet SID on a netif is not presently used for anything. -- Stephen Smalley National Security Agency From linuxweb at gmail.com Mon Jul 7 17:01:55 2008 From: linuxweb at gmail.com (Johnny Tan) Date: Mon, 07 Jul 2008 13:01:55 -0400 Subject: rsyncd can't open log file, but there are no avc messages In-Reply-To: <48610E19.6040604@gmail.com> References: <48610E19.6040604@gmail.com> Message-ID: <48724C03.6070806@gmail.com> Johnny Tan wrote: > I'm stumped. > > I run a Java app called Solr, which does search indexing. My solr server > creates the index, then I have a bunch of solr clients that rsync that > index over. > > The rsync itself is fine, that works. The problem is it won't write to > the appropriate logfile, which is: > /opt/solr/logs/rsyncd.log > > /opt/solr/logs is a symlink to /var/log/store. A little bit more information that might help solve this... If I remove the symlink, and /opt/solr/bin/rsyncd-start runs (which basically starts rsyncd), then rsyncd can write to /opt/solr/logs/rsyncd.log with no problems. If I put the symlink back in (to /var/log/store), then it fails (again, with no AVC messages). The only difference I can see between /opt/solr/logs (as a directory) and /var/log/store is the default contexts, for /opt/solr/logs, it's root:object_r:usr_t, for /var/log/store it's root:object_r:var_log_t When I put the symlink back, I tried changing the context of /var/log/store to root:object_r:usr_t to match /opt/solr/logs, but that doesn't seem to make a difference. Max, a list member, suggested offline that it might have to do with type_transition, which does seem to make sense. I tried both: type_transition rsync_t var_log_t : file rsync_log_t; and type_transition rsync_t var_log_t : file usr_t; But neither worked (I have all the appropriate allows for those contexts). Am I going down the right path here (type_transition)? Or does anyone else have a suggestion in terms of how the symlink can be used? johnn From dwalsh at redhat.com Mon Jul 7 17:39:46 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 07 Jul 2008 13:39:46 -0400 Subject: fixfiles -relabel error (frrank-01) In-Reply-To: <1215427224.11177.1.camel@frank-01> References: <1215427224.11177.1.camel@frank-01> Message-ID: <487254E2.1030309@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank Murphy wrote: > [frank at frank-01 ~]$ su - root > Password: > [root at frank-01 ~]# fixfiles relabel > > Files in the /tmp directory may be labeled incorrectly, this > command > can remove all files in /tmp. If you choose to remove files > from /tmp, > a reboot will be required after completion. > > Do you wish to clean out the /tmp directory [N]? y > Cleaning out /tmp > /sbin/setfiles: unable to stat file /home/frank/.gvfs: Permission > denied > /sbin/setfiles: error while labeling /home: Permission denied > /sbin/setfiles: error while labeling /boot: Permission denied > > > I'm guess /home has to be done as su - frank? > /boot no idea. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Yes relabeling the entire file system needs to be done as root. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhyVOIACgkQrlYvE4MpobM8hQCeLBTVIVfVhJXVIQSkbfe+t5II pnwAnjlYhZtfXL9gFUjyigPO8LGs0kSn =9vpE -----END PGP SIGNATURE----- From paul at city-fan.org Mon Jul 7 22:30:20 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 7 Jul 2008 23:30:20 +0100 Subject: rsyncd can't open log file, but there are no avc messages In-Reply-To: <48724C03.6070806@gmail.com> References: <48610E19.6040604@gmail.com> <48724C03.6070806@gmail.com> Message-ID: <20080707233020.6f7fdfb0@metropolis.intra.city-fan.org> On Mon, 07 Jul 2008 13:01:55 -0400 Johnny Tan wrote: > Johnny Tan wrote: > > I'm stumped. > > > > I run a Java app called Solr, which does search indexing. My solr > > server creates the index, then I have a bunch of solr clients that > > rsync that index over. > > > > The rsync itself is fine, that works. The problem is it won't write > > to the appropriate logfile, which is: > > /opt/solr/logs/rsyncd.log > > > > /opt/solr/logs is a symlink to /var/log/store. > > A little bit more information that might help solve this... > > If I remove the symlink, and /opt/solr/bin/rsyncd-start runs > (which basically starts rsyncd), then rsyncd can write to > /opt/solr/logs/rsyncd.log with no problems. > > If I put the symlink back in (to /var/log/store), then it > fails (again, with no AVC messages). > > The only difference I can see between /opt/solr/logs (as a > directory) and /var/log/store is the default contexts, for > /opt/solr/logs, it's root:object_r:usr_t, for /var/log/store > it's root:object_r:var_log_t > > When I put the symlink back, I tried changing the context of > /var/log/store to root:object_r:usr_t to match > /opt/solr/logs, but that doesn't seem to make a difference. > > Max, a list member, suggested offline that it might have to > do with type_transition, which does seem to make sense. > > I tried both: > type_transition rsync_t var_log_t : file rsync_log_t; > and > type_transition rsync_t var_log_t : file usr_t; > > But neither worked (I have all the appropriate allows for > those contexts). > > > Am I going down the right path here (type_transition)? Or > does anyone else have a suggestion in terms of how the > symlink can be used? Can you try this policy module: :::::::::::::: solr.fc :::::::::::::: /var/log/store(/.*)? gen_context(system_u:object_r:rsync_log_t,s0) :::::::::::::: solr.te :::::::::::::: policy_module(solr, 0.0.1) # ====================================================== # Declarations # ====================================================== require { type rsync_t; type rsync_log_t; } # ====================================================== # Solr local policy # ====================================================== logging_log_file(rsync_log_t) logging_log_filetrans(rsync_t,rsync_log_t, { file dir } ) Followed by: # restorecon -rv /var/log/store See if that helps. Paul. From paul at city-fan.org Mon Jul 7 22:30:17 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 7 Jul 2008 23:30:17 +0100 Subject: rsyncd can't open log file, but there are no avc messages In-Reply-To: <48724C03.6070806@gmail.com> References: <48610E19.6040604@gmail.com> <48724C03.6070806@gmail.com> Message-ID: <20080707233017.76a13bc9@metropolis.intra.city-fan.org> On Mon, 07 Jul 2008 13:01:55 -0400 Johnny Tan wrote: > Johnny Tan wrote: > > I'm stumped. > > > > I run a Java app called Solr, which does search indexing. My solr > > server creates the index, then I have a bunch of solr clients that > > rsync that index over. > > > > The rsync itself is fine, that works. The problem is it won't write > > to the appropriate logfile, which is: > > /opt/solr/logs/rsyncd.log > > > > /opt/solr/logs is a symlink to /var/log/store. > > A little bit more information that might help solve this... > > If I remove the symlink, and /opt/solr/bin/rsyncd-start runs > (which basically starts rsyncd), then rsyncd can write to > /opt/solr/logs/rsyncd.log with no problems. > > If I put the symlink back in (to /var/log/store), then it > fails (again, with no AVC messages). > > The only difference I can see between /opt/solr/logs (as a > directory) and /var/log/store is the default contexts, for > /opt/solr/logs, it's root:object_r:usr_t, for /var/log/store > it's root:object_r:var_log_t > > When I put the symlink back, I tried changing the context of > /var/log/store to root:object_r:usr_t to match > /opt/solr/logs, but that doesn't seem to make a difference. > > Max, a list member, suggested offline that it might have to > do with type_transition, which does seem to make sense. > > I tried both: > type_transition rsync_t var_log_t : file rsync_log_t; > and > type_transition rsync_t var_log_t : file usr_t; > > But neither worked (I have all the appropriate allows for > those contexts). > > > Am I going down the right path here (type_transition)? Or > does anyone else have a suggestion in terms of how the > symlink can be used? Can you try this policy module: :::::::::::::: solr.fc :::::::::::::: /var/log/store(/.*)? gen_context(system_u:object_r:rsync_log_t,s0) :::::::::::::: solr.te :::::::::::::: policy_module(solr, 0.0.1) # ====================================================== # Declarations # ====================================================== require { type rsync_t; type rsync_log_t; } # ====================================================== # Solr local policy # ====================================================== logging_log_file(rsync_log_t) logging_log_filetrans(rsync_t,rsync_log_t, { file dir } ) Followed by: # restorecon -rv /var/log/store See if that helps. Paul. From frankly3d at gmail.com Tue Jul 8 06:42:36 2008 From: frankly3d at gmail.com (Frank Murphy) Date: Tue, 08 Jul 2008 07:42:36 +0100 Subject: audit2allow -M local < /tmp/avcs ? In-Reply-To: References: <1215421359.3207.3.camel@frank-01> <1215421992.3874.2.camel@frank-01> Message-ID: <1215499356.3191.3.camel@frank-01> On Mon, 2008-07-07 at 11:27 +0200, drago01 wrote: > >> The logs are either in /var/log/audit.log (if audit is running) > >> otherwise in syslog (in this case passing -D to audit2allow will use > >> them) > > > > audit2allow /var/log/audit/audit.log? > > yes just use this file instead of /tmp/avcs > audit2allow -M local < /your/log/file How long mush one give to the command? I cleared the log, waited for two avc alerts. ran: ?[root at frank-03 ~]# audit2allow -M local /var/log/audit/audit.log It's been an hour so far. Frank From paul at city-fan.org Tue Jul 8 08:37:15 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 08 Jul 2008 09:37:15 +0100 Subject: audit2allow -M local < /tmp/avcs ? In-Reply-To: <1215499356.3191.3.camel@frank-01> References: <1215421359.3207.3.camel@frank-01> <1215421992.3874.2.camel@frank-01> <1215499356.3191.3.camel@frank-01> Message-ID: <4873273B.7000407@city-fan.org> Frank Murphy wrote: > On Mon, 2008-07-07 at 11:27 +0200, drago01 wrote: > >>>> The logs are either in /var/log/audit.log (if audit is running) >>>> otherwise in syslog (in this case passing -D to audit2allow will use >>>> them) >>> audit2allow /var/log/audit/audit.log? >> yes just use this file instead of /tmp/avcs >> audit2allow -M local < /your/log/file > > How long mush one give to the command? > I cleared the log, waited for two avc alerts. > ran: ?[root at frank-03 ~]# audit2allow -M local /var/log/audit/audit.log > > It's been an hour so far. What you typed isn't what was suggested. You missed the "<". It's waiting for the end of file on stdin, which is your terminal. Paul. From frankly3d at gmail.com Tue Jul 8 08:48:45 2008 From: frankly3d at gmail.com (Frank Murphy) Date: Tue, 08 Jul 2008 09:48:45 +0100 Subject: audit2allow -M local < /tmp/avcs ? In-Reply-To: <4873273B.7000407@city-fan.org> References: <1215421359.3207.3.camel@frank-01> <1215421992.3874.2.camel@frank-01> <1215499356.3191.3.camel@frank-01> <4873273B.7000407@city-fan.org> Message-ID: <1215506925.6208.0.camel@frank-01> On Tue, 2008-07-08 at 09:37 +0100, Paul Howarth wrote: > Frank Murphy wrote: > >> audit2allow -M local < /your/log/file > > > > ran: ?[root at frank-03 ~]# audit2allow -M local /var/log/audit/audit.log > > > > It's been an hour so far. > > What you typed isn't what was suggested. You missed the "<". > > It's waiting for the end of file on stdin, which is your terminal. > > Paul. Good job the eye test is tomorrow ;( Frank From kas at fi.muni.cz Tue Jul 8 09:10:41 2008 From: kas at fi.muni.cz (Jan Kasprzak) Date: Tue, 8 Jul 2008 11:10:41 +0200 Subject: Enabling SELinux on a custom kernel Message-ID: <20080708091041.GY7614@fi.muni.cz> Hello, how do I enable SELinux on a custom kernel? I have looked into the system initrd, and it seems the policy is loaded by the "loadpolicy" command in nash. Is it possible to use SELinux with Fedora without having to use initrd? Thanks, -Yenya -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ | >> If you find yourself arguing with Alan Cox, you?re _probably_ wrong. << >> --James Morris in "How and Why You Should Become a Kernel Hacker" << From sds at tycho.nsa.gov Tue Jul 8 12:24:07 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 08 Jul 2008 08:24:07 -0400 Subject: Enabling SELinux on a custom kernel In-Reply-To: <20080708091041.GY7614@fi.muni.cz> References: <20080708091041.GY7614@fi.muni.cz> Message-ID: <1215519847.27975.223.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-07-08 at 11:10 +0200, Jan Kasprzak wrote: > Hello, > > how do I enable SELinux on a custom kernel? I have looked into > the system initrd, and it seems the policy is loaded by the "loadpolicy" > command in nash. Is it possible to use SELinux with Fedora without > having to use initrd? Prior to Fedora 9, Fedora used a patched /sbin/init program to perform the initial policy load (it would load policy and then re-exec itself in order to enter the correct domain). Fedora 9 switched over to loading policy from the initrd. Your options would seem to be: - use an initrd (easiest), - re-patch your /sbin/init program, - try to do it from inittab or rc.sysinit (but the problem there is that it doesn't get /sbin/init itself into the right domain). -- Stephen Smalley National Security Agency From kas at fi.muni.cz Tue Jul 8 13:17:45 2008 From: kas at fi.muni.cz (Jan Kasprzak) Date: Tue, 8 Jul 2008 15:17:45 +0200 Subject: Postfix avcs (Re: Enabling SELinux on a custom kernel) In-Reply-To: <1215519847.27975.223.camel@moss-spartans.epoch.ncsc.mil> References: <20080708091041.GY7614@fi.muni.cz> <1215519847.27975.223.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20080708131745.GA7614@fi.muni.cz> Stephen Smalley wrote: : Your options would seem to be: : - use an initrd (easiest), OK, I did the above. Thanks! Now I have problems running Postfix - sample avcs are the following: type=1400 audit(1215522639.630:102): avc: denied { sys_chroot } for pid=7367 comm="cleanup" capability=18 scontext=system_u:system_r:postfix_cleanup_t:s0 tcontext=system_u:system_r:postfix_cleanup_t:s0 tclass=capability type=1400 audit(1215522639.766:103): avc: denied { sys_chroot } for pid=7369 comm="trivial-rewrite" capability=18 scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_master_t:s0 tclass=capability type=1400 audit(1215522640.693:104): avc: denied { sys_chroot } for pid=7370 comm="smtp" capability=18 scontext=system_u:system_r:postfix_smtp_t:s0 tcontext=system_u:system_r:postfix_smtp_t:s0 tclass=capability type=1400 audit(1215522640.760:105): avc: denied { sys_chroot } for pid=7371 comm="bounce" capability=18 scontext=system_u:system_r:postfix_bounce_t:s0 tcontext=system_u:system_r:postfix_bounce_t:s0 tclass=capability I have ran it through audit2allow -m localpostfix > localpostfix.te, comp[iled it using checkmodule -M -m -o localpostfix.mod localpostfix.te semodule_package -o localpostfix.pp -m localpostfix.mod but when I try to load it using "semodule -i localpostfix.pp", the semodule command hangs for several minutes, eating almost 100 % CPU. After that, it fails with libsemanage.dbase_llist_query: could not query record value (No such file or directory). Tried with both "setenforce 0" and "setenforce 1". How can I fix it? Thanks, -Yenya -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ | >> If you find yourself arguing with Alan Cox, you?re _probably_ wrong. << >> --James Morris in "How and Why You Should Become a Kernel Hacker" << From sds at tycho.nsa.gov Tue Jul 8 13:23:48 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 08 Jul 2008 09:23:48 -0400 Subject: Postfix avcs (Re: Enabling SELinux on a custom kernel) In-Reply-To: <20080708131745.GA7614@fi.muni.cz> References: <20080708091041.GY7614@fi.muni.cz> <1215519847.27975.223.camel@moss-spartans.epoch.ncsc.mil> <20080708131745.GA7614@fi.muni.cz> Message-ID: <1215523428.27975.255.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-07-08 at 15:17 +0200, Jan Kasprzak wrote: > Stephen Smalley wrote: > : Your options would seem to be: > : - use an initrd (easiest), > > OK, I did the above. Thanks! > > Now I have problems running Postfix - sample avcs are the > following: > > type=1400 audit(1215522639.630:102): avc: denied { sys_chroot } for pid=7367 comm="cleanup" capability=18 scontext=system_u:system_r:postfix_cleanup_t:s0 tcontext=system_u:system_r:postfix_cleanup_t:s0 tclass=capability > type=1400 audit(1215522639.766:103): avc: denied { sys_chroot } for pid=7369 comm="trivial-rewrite" capability=18 scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_master_t:s0 tclass=capability > type=1400 audit(1215522640.693:104): avc: denied { sys_chroot } for pid=7370 comm="smtp" capability=18 scontext=system_u:system_r:postfix_smtp_t:s0 tcontext=system_u:system_r:postfix_smtp_t:s0 tclass=capability > type=1400 audit(1215522640.760:105): avc: denied { sys_chroot } for pid=7371 comm="bounce" capability=18 scontext=system_u:system_r:postfix_bounce_t:s0 tcontext=system_u:system_r:postfix_bounce_t:s0 tclass=capability > > I have ran it through audit2allow -m localpostfix > localpostfix.te, > comp[iled it using > > checkmodule -M -m -o localpostfix.mod localpostfix.te > semodule_package -o localpostfix.pp -m localpostfix.mod Easier way to do that is: audit2allow -M localpostfix That creates the .te file, runs it through checkmodule, and runs it through semodule_package, leaving you with the .pp file. > but when I try to load it using "semodule -i localpostfix.pp", > the semodule command hangs for several minutes, eating almost 100 % CPU. > After that, it fails with > > libsemanage.dbase_llist_query: could not query record value (No such file or directory). > > Tried with both "setenforce 0" and "setenforce 1". How can I fix it? > Thanks, Hmmm...that's interesting. Usually that means you are missing a config file in the policy store. Are you starting from the stock Fedora policy or your own custom policy? Also, did it actually fail or just issue that warning and proceed? -- Stephen Smalley National Security Agency From kas at fi.muni.cz Tue Jul 8 13:48:07 2008 From: kas at fi.muni.cz (Jan Kasprzak) Date: Tue, 8 Jul 2008 15:48:07 +0200 Subject: Postfix avcs (Re: Enabling SELinux on a custom kernel) In-Reply-To: <1215523428.27975.255.camel@moss-spartans.epoch.ncsc.mil> References: <20080708091041.GY7614@fi.muni.cz> <1215519847.27975.223.camel@moss-spartans.epoch.ncsc.mil> <20080708131745.GA7614@fi.muni.cz> <1215523428.27975.255.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20080708134807.GB7614@fi.muni.cz> Stephen Smalley wrote: : Easier way to do that is: : audit2allow -M localpostfix : That creates the .te file, runs it through checkmodule, and runs it : through semodule_package, leaving you with the .pp file. OK, thanks. : > but when I try to load it using "semodule -i localpostfix.pp", : > the semodule command hangs for several minutes, eating almost 100 % CPU. : > After that, it fails with : > : > libsemanage.dbase_llist_query: could not query record value (No such file or directory). : : Hmmm...that's interesting. Usually that means you are missing a config : file in the policy store. Are you starting from the stock Fedora policy : or your own custom policy? Also, did it actually fail or just issue : that warning and proceed? Well, this system has been running for several years and upgraded through several Fedora releases (altough SELinux has never been in use there). Now I have decided to enable SELinux (together with an upgrade to F9), so I have installed Fedora (or Fedora updates) packages of SELinux tools, targeted policy, etc. So yes, the starting point was the stock F9 setup, but I cannot say it is a fresh F9 install. Running find /etc/selinux -print on that system and on just installed and updated F9 system leads to this diff: diff /tmp/list.upgraded /tmp/list.fresh 70d69 < /etc/selinux/targeted/modules/active/modules/localpostfix.pp 115a115 > /etc/selinux/targeted/modules/active/seusers 117a118,119 > /etc/selinux/targeted/modules/active/users_extra.local > /etc/selinux/targeted/modules/active/users.local 120,207d121 < /etc/selinux/targeted/modules/tmp < /etc/selinux/targeted/modules/tmp/base.pp < /etc/selinux/targeted/modules/tmp/commit_num [... and lot other files in .../tmp, because semodule -i localpostfix.pp has been running at that time ...] Semodule -i does not fail per se - it returns 0 to the shell. However, Postfix still does not work, and AVCs similar to the original ones are still logged into the audit.log. -Yenya -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ | >> If you find yourself arguing with Alan Cox, you?re _probably_ wrong. << >> --James Morris in "How and Why You Should Become a Kernel Hacker" << From kas at fi.muni.cz Tue Jul 8 14:16:53 2008 From: kas at fi.muni.cz (Jan Kasprzak) Date: Tue, 8 Jul 2008 16:16:53 +0200 Subject: Postfix avcs (Re: Enabling SELinux on a custom kernel) In-Reply-To: <20080708134807.GB7614@fi.muni.cz> References: <20080708091041.GY7614@fi.muni.cz> <1215519847.27975.223.camel@moss-spartans.epoch.ncsc.mil> <20080708131745.GA7614@fi.muni.cz> <1215523428.27975.255.camel@moss-spartans.epoch.ncsc.mil> <20080708134807.GB7614@fi.muni.cz> Message-ID: <20080708141653.GC7614@fi.muni.cz> Jan Kasprzak wrote: : > /etc/selinux/targeted/modules/active/seusers : > /etc/selinux/targeted/modules/active/users_extra.local : > /etc/selinux/targeted/modules/active/users.local I have copied those three files from the fresh F9 system to the system in question, and it seems that after semodule -i localpostfix.pp Postfix finally works. However, the "semodule -i localpostfix.pp" command still takes 2-3 minutes of CPU time to finish. At least it doesn't complain anymore. # time semodule -i localpostfix.pp real 2m55.839s user 2m54.195s sys 0m1.593s # echo $? 0 -Yenya -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ | >> If you find yourself arguing with Alan Cox, you?re _probably_ wrong. << >> --James Morris in "How and Why You Should Become a Kernel Hacker" << From sds at tycho.nsa.gov Tue Jul 8 14:19:05 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 08 Jul 2008 10:19:05 -0400 Subject: Postfix avcs (Re: Enabling SELinux on a custom kernel) In-Reply-To: <20080708141653.GC7614@fi.muni.cz> References: <20080708091041.GY7614@fi.muni.cz> <1215519847.27975.223.camel@moss-spartans.epoch.ncsc.mil> <20080708131745.GA7614@fi.muni.cz> <1215523428.27975.255.camel@moss-spartans.epoch.ncsc.mil> <20080708134807.GB7614@fi.muni.cz> <20080708141653.GC7614@fi.muni.cz> Message-ID: <1215526745.27975.268.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-07-08 at 16:16 +0200, Jan Kasprzak wrote: > Jan Kasprzak wrote: > : > /etc/selinux/targeted/modules/active/seusers > : > /etc/selinux/targeted/modules/active/users_extra.local > : > /etc/selinux/targeted/modules/active/users.local > > I have copied those three files from the fresh F9 system > to the system in question, and it seems that after semodule -i localpostfix.pp > Postfix finally works. However, the "semodule -i localpostfix.pp" > command still takes 2-3 minutes of CPU time to finish. At least > it doesn't complain anymore. > > # time semodule -i localpostfix.pp > > real 2m55.839s > user 2m54.195s > sys 0m1.593s > # echo $? > 0 Can you check whether you have expand-check = 0 in /etc/selinux/semanage.conf? If not present or commented out, add it and retry. -- Stephen Smalley National Security Agency From serue at us.ibm.com Tue Jul 8 14:19:26 2008 From: serue at us.ibm.com (Serge E. Hallyn) Date: Tue, 8 Jul 2008 09:19:26 -0500 Subject: Enabling SELinux on a custom kernel In-Reply-To: <1215519847.27975.223.camel@moss-spartans.epoch.ncsc.mil> References: <20080708091041.GY7614@fi.muni.cz> <1215519847.27975.223.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20080708141925.GA13564@us.ibm.com> Quoting Stephen Smalley (sds at tycho.nsa.gov): > > On Tue, 2008-07-08 at 11:10 +0200, Jan Kasprzak wrote: > > Hello, > > > > how do I enable SELinux on a custom kernel? I have looked into > > the system initrd, and it seems the policy is loaded by the "loadpolicy" > > command in nash. Is it possible to use SELinux with Fedora without > > having to use initrd? > > Prior to Fedora 9, Fedora used a patched /sbin/init program to perform > the initial policy load (it would load policy and then re-exec itself in > order to enter the correct domain). Fedora 9 switched over to loading > policy from the initrd. > > Your options would seem to be: > - use an initrd (easiest), > - re-patch your /sbin/init program, > - try to do it from inittab or rc.sysinit (but the problem there is that > it doesn't get /sbin/init itself into the right domain). Aaaah. I was wondering why my new f9-based kvm image wasn't enabling selinux when I started it with "-kernel bzImage". That's going to be a bit of a pain, as I assume I'll have to import the kernel tree into the f9 image in order to create an initrd. -serge From dwalsh at redhat.com Tue Jul 8 18:30:56 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 08 Jul 2008 14:30:56 -0400 Subject: Mislabeled files In-Reply-To: <1215165091.23349.0.camel@frank-01> References: <1214923459.12571.5.camel@frank-01> <486D1DE3.5030809@redhat.com> <1215165091.23349.0.camel@frank-01> Message-ID: <4873B260.4060505@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank Murphy wrote: > On Thu, 2008-07-03 at 14:43 -0400, Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 > >>> >> This is actually a bug in policy, and setroubleshoot should have told >> you to use audit2allow to allow it. >> > > Fully updated, > Still getting these on a couple of boxes Fedora9 and (centos5.2) > > Similar to:- > Target Objects: 2F746D702F5273497038477A34202864656C6574656429 [ file ] > > Frank > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list # grep exim_t /var/log/audit/audit.log | audit2allow -M myexim # semodule -i myexim.pp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhzsmAACgkQrlYvE4MpobMa5gCeIr4HtX8AlbDFpf1TtrrsSgds CpAAoLGtkHFYteuwNKChSxRdmmZskI6p =ZXKm -----END PGP SIGNATURE----- From dwalsh at redhat.com Tue Jul 8 18:35:22 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 08 Jul 2008 14:35:22 -0400 Subject: auditd went crazy In-Reply-To: <20080704135453.GI8285@inocybe.teonanacatl.org> References: <20080702152726.GA32483@angus.ind.WPI.EDU> <486D22E4.8080101@redhat.com> <20080704135453.GI8285@inocybe.teonanacatl.org> Message-ID: <4873B36A.4040903@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Todd Zullinger wrote: > Daniel J Walsh wrote: >> Seems like you have a mislabeld program running as initrc_t? >> >> ps -eZ | grep initrc_t > > Are there some docs on how to fix up an programs running as initrc_t > (and when it is required to do so)? I notice that puppetd is in this > situation on my system, but I don't know if that's a potential problem > nor how to correct it if it is. > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list No any system daemon that does not have policy will run as initrc_t, if these daemons executed confined applications, you could see AVC's. But ordinarily an initrc_t domains will run as "unconfined". It is the equivalent of the unconfined_t domain for a logged in user. We could write policy for puppetd and it would run under a different context. Puppetd probably needs to do just about anything, so writing a standard policy for it to work everywhere is impossible, so it would have to be uncofined. A lot of times AVC's for a confined domain referrring to initrc_t indicates a leaked file descriptor. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhzs2oACgkQrlYvE4MpobObKQCffuDxLZZi8VO6fMN9YsgwL8ZF mCwAnjemACoAtARCctYhU13o2Lb7DuSm =8Mj3 -----END PGP SIGNATURE----- From linuxweb at gmail.com Tue Jul 8 20:36:13 2008 From: linuxweb at gmail.com (Johnny Tan) Date: Tue, 08 Jul 2008 16:36:13 -0400 Subject: rsyncd can't open log file, but there are no avc messages In-Reply-To: <20080707233020.6f7fdfb0@metropolis.intra.city-fan.org> References: <48610E19.6040604@gmail.com> <48724C03.6070806@gmail.com> <20080707233020.6f7fdfb0@metropolis.intra.city-fan.org> Message-ID: <4873CFBD.1080505@gmail.com> Paul Howarth wrote: > On Mon, 07 Jul 2008 13:01:55 -0400 > Johnny Tan wrote: > >> Johnny Tan wrote: >>> I'm stumped. >>> >>> I run a Java app called Solr, which does search indexing. My solr >>> server creates the index, then I have a bunch of solr clients that >>> rsync that index over. >>> >>> The rsync itself is fine, that works. The problem is it won't write >>> to the appropriate logfile, which is: >>> /opt/solr/logs/rsyncd.log >>> >>> /opt/solr/logs is a symlink to /var/log/store. >> A little bit more information that might help solve this... >> >> If I remove the symlink, and /opt/solr/bin/rsyncd-start runs >> (which basically starts rsyncd), then rsyncd can write to >> /opt/solr/logs/rsyncd.log with no problems. >> >> If I put the symlink back in (to /var/log/store), then it >> fails (again, with no AVC messages). >> >> The only difference I can see between /opt/solr/logs (as a >> directory) and /var/log/store is the default contexts, for >> /opt/solr/logs, it's root:object_r:usr_t, for /var/log/store >> it's root:object_r:var_log_t >> >> When I put the symlink back, I tried changing the context of >> /var/log/store to root:object_r:usr_t to match >> /opt/solr/logs, but that doesn't seem to make a difference. >> >> Max, a list member, suggested offline that it might have to >> do with type_transition, which does seem to make sense. >> >> I tried both: >> type_transition rsync_t var_log_t : file rsync_log_t; >> and >> type_transition rsync_t var_log_t : file usr_t; >> >> But neither worked (I have all the appropriate allows for >> those contexts). >> >> >> Am I going down the right path here (type_transition)? Or >> does anyone else have a suggestion in terms of how the >> symlink can be used? > > > Can you try this policy module: > > :::::::::::::: > solr.fc > :::::::::::::: > /var/log/store(/.*)? gen_context(system_u:object_r:rsync_log_t,s0) == # semanage fcontext -a -t rsync_log_t "/var/log/store(/.*)?" libsepol.context_from_record: type rsync_log_t is not defined libsepol.context_from_record: could not create context structure libsemanage.validate_handler: invalid context system_u:object_r:rsync_log_t:s0 specified for /var/log/store(/.*)? [all files] libsemanage.dbase_llist_iterate: could not iterate over records /usr/sbin/semanage: Could not add file context for /var/log/store(/.*)? == It seems rsync_log_t is not defined. Can I somehow do this without having rsync_log_t? It works fine when I don't use a symlink, so I assume rsync_log_t is not necessary for this to work. But I need the symlink because I need the files to be stored in /var/log/store, as opposed to /opt/solr/logs. johnn From paul at city-fan.org Tue Jul 8 20:38:42 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 8 Jul 2008 21:38:42 +0100 Subject: rsyncd can't open log file, but there are no avc messages In-Reply-To: <4873CFBD.1080505@gmail.com> References: <48610E19.6040604@gmail.com> <48724C03.6070806@gmail.com> <20080707233020.6f7fdfb0@metropolis.intra.city-fan.org> <4873CFBD.1080505@gmail.com> Message-ID: <20080708213842.1dc797e1@metropolis.intra.city-fan.org> On Tue, 08 Jul 2008 16:36:13 -0400 Johnny Tan wrote: > Paul Howarth wrote: > > On Mon, 07 Jul 2008 13:01:55 -0400 > > Johnny Tan wrote: > > > >> Johnny Tan wrote: > >>> I'm stumped. > >>> > >>> I run a Java app called Solr, which does search indexing. My solr > >>> server creates the index, then I have a bunch of solr clients that > >>> rsync that index over. > >>> > >>> The rsync itself is fine, that works. The problem is it won't > >>> write to the appropriate logfile, which is: > >>> /opt/solr/logs/rsyncd.log > >>> > >>> /opt/solr/logs is a symlink to /var/log/store. > >> A little bit more information that might help solve this... > >> > >> If I remove the symlink, and /opt/solr/bin/rsyncd-start runs > >> (which basically starts rsyncd), then rsyncd can write to > >> /opt/solr/logs/rsyncd.log with no problems. > >> > >> If I put the symlink back in (to /var/log/store), then it > >> fails (again, with no AVC messages). > >> > >> The only difference I can see between /opt/solr/logs (as a > >> directory) and /var/log/store is the default contexts, for > >> /opt/solr/logs, it's root:object_r:usr_t, for /var/log/store > >> it's root:object_r:var_log_t > >> > >> When I put the symlink back, I tried changing the context of > >> /var/log/store to root:object_r:usr_t to match > >> /opt/solr/logs, but that doesn't seem to make a difference. > >> > >> Max, a list member, suggested offline that it might have to > >> do with type_transition, which does seem to make sense. > >> > >> I tried both: > >> type_transition rsync_t var_log_t : file rsync_log_t; > >> and > >> type_transition rsync_t var_log_t : file usr_t; > >> > >> But neither worked (I have all the appropriate allows for > >> those contexts). > >> > >> > >> Am I going down the right path here (type_transition)? Or > >> does anyone else have a suggestion in terms of how the > >> symlink can be used? > > > > > > Can you try this policy module: > > > > :::::::::::::: > > solr.fc > > :::::::::::::: > > /var/log/store(/.*)? gen_context(system_u:object_r:rsync_log_t,s0) > > == > > # semanage fcontext -a -t rsync_log_t "/var/log/store(/.*)?" > libsepol.context_from_record: type rsync_log_t is not defined > libsepol.context_from_record: could not create context structure > libsemanage.validate_handler: invalid context > system_u:object_r:rsync_log_t:s0 specified for > /var/log/store(/.*)? [all files] > libsemanage.dbase_llist_iterate: could not iterate over records > /usr/sbin/semanage: Could not add file context for > /var/log/store(/.*)? > > == > > It seems rsync_log_t is not defined. Can I somehow do this > without having rsync_log_t? > > It works fine when I don't use a symlink, so I assume > rsync_log_t is not necessary for this to work. > > But I need the symlink because I need the files to be stored > in /var/log/store, as opposed to /opt/solr/logs. I thought from earlier messages you were on RHEL 5? I've tested this module with CentOS 5.2 and it loads just fine. Which policy version are you using? Paul. From linuxweb at gmail.com Tue Jul 8 20:51:24 2008 From: linuxweb at gmail.com (Johnny Tan) Date: Tue, 08 Jul 2008 16:51:24 -0400 Subject: rsyncd can't open log file, but there are no avc messages In-Reply-To: <20080708213842.1dc797e1@metropolis.intra.city-fan.org> References: <48610E19.6040604@gmail.com> <48724C03.6070806@gmail.com> <20080707233020.6f7fdfb0@metropolis.intra.city-fan.org> <4873CFBD.1080505@gmail.com> <20080708213842.1dc797e1@metropolis.intra.city-fan.org> Message-ID: <4873D34C.7030307@gmail.com> Paul Howarth wrote: > On Tue, 08 Jul 2008 16:36:13 -0400 > Johnny Tan wrote: > >> Paul Howarth wrote: >>> On Mon, 07 Jul 2008 13:01:55 -0400 >>> Johnny Tan wrote: >>> >>>> Johnny Tan wrote: >>>>> I'm stumped. >>>>> >>>>> I run a Java app called Solr, which does search indexing. My solr >>>>> server creates the index, then I have a bunch of solr clients that >>>>> rsync that index over. >>>>> >>>>> The rsync itself is fine, that works. The problem is it won't >>>>> write to the appropriate logfile, which is: >>>>> /opt/solr/logs/rsyncd.log >>>>> >>>>> /opt/solr/logs is a symlink to /var/log/store. >>>> A little bit more information that might help solve this... >>>> >>>> If I remove the symlink, and /opt/solr/bin/rsyncd-start runs >>>> (which basically starts rsyncd), then rsyncd can write to >>>> /opt/solr/logs/rsyncd.log with no problems. >>>> >>>> If I put the symlink back in (to /var/log/store), then it >>>> fails (again, with no AVC messages). >>>> >>>> The only difference I can see between /opt/solr/logs (as a >>>> directory) and /var/log/store is the default contexts, for >>>> /opt/solr/logs, it's root:object_r:usr_t, for /var/log/store >>>> it's root:object_r:var_log_t >>>> >>>> When I put the symlink back, I tried changing the context of >>>> /var/log/store to root:object_r:usr_t to match >>>> /opt/solr/logs, but that doesn't seem to make a difference. >>>> >>>> Max, a list member, suggested offline that it might have to >>>> do with type_transition, which does seem to make sense. >>>> >>>> I tried both: >>>> type_transition rsync_t var_log_t : file rsync_log_t; >>>> and >>>> type_transition rsync_t var_log_t : file usr_t; >>>> >>>> But neither worked (I have all the appropriate allows for >>>> those contexts). >>>> >>>> >>>> Am I going down the right path here (type_transition)? Or >>>> does anyone else have a suggestion in terms of how the >>>> symlink can be used? >>> >>> Can you try this policy module: >>> >>> :::::::::::::: >>> solr.fc >>> :::::::::::::: >>> /var/log/store(/.*)? gen_context(system_u:object_r:rsync_log_t,s0) >> == >> >> # semanage fcontext -a -t rsync_log_t "/var/log/store(/.*)?" >> libsepol.context_from_record: type rsync_log_t is not defined >> libsepol.context_from_record: could not create context structure >> libsemanage.validate_handler: invalid context >> system_u:object_r:rsync_log_t:s0 specified for >> /var/log/store(/.*)? [all files] >> libsemanage.dbase_llist_iterate: could not iterate over records >> /usr/sbin/semanage: Could not add file context for >> /var/log/store(/.*)? >> >> == >> >> It seems rsync_log_t is not defined. Can I somehow do this >> without having rsync_log_t? >> >> It works fine when I don't use a symlink, so I assume >> rsync_log_t is not necessary for this to work. >> >> But I need the symlink because I need the files to be stored >> in /var/log/store, as opposed to /opt/solr/logs. > > I thought from earlier messages you were on RHEL 5? I've tested this > module with CentOS 5.2 and it loads just fine. > > Which policy version are you using? selinux-policy-2.4.6-106.el5_1.3 I haven't updated yet to 5.2 johnn From paul at city-fan.org Tue Jul 8 21:01:55 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 8 Jul 2008 22:01:55 +0100 Subject: rsyncd can't open log file, but there are no avc messages In-Reply-To: <4873D34C.7030307@gmail.com> References: <48610E19.6040604@gmail.com> <48724C03.6070806@gmail.com> <20080707233020.6f7fdfb0@metropolis.intra.city-fan.org> <4873CFBD.1080505@gmail.com> <20080708213842.1dc797e1@metropolis.intra.city-fan.org> <4873D34C.7030307@gmail.com> Message-ID: <20080708220155.1b79a093@metropolis.intra.city-fan.org> On Tue, 08 Jul 2008 16:51:24 -0400 Johnny Tan wrote: > Paul Howarth wrote: > > On Tue, 08 Jul 2008 16:36:13 -0400 > > Johnny Tan wrote: > > > >> Paul Howarth wrote: > >>> On Mon, 07 Jul 2008 13:01:55 -0400 > >>> Johnny Tan wrote: > >>> > >>>> Johnny Tan wrote: > >>>>> I'm stumped. > >>>>> > >>>>> I run a Java app called Solr, which does search indexing. My > >>>>> solr server creates the index, then I have a bunch of solr > >>>>> clients that rsync that index over. > >>>>> > >>>>> The rsync itself is fine, that works. The problem is it won't > >>>>> write to the appropriate logfile, which is: > >>>>> /opt/solr/logs/rsyncd.log > >>>>> > >>>>> /opt/solr/logs is a symlink to /var/log/store. > >>>> A little bit more information that might help solve this... > >>>> > >>>> If I remove the symlink, and /opt/solr/bin/rsyncd-start runs > >>>> (which basically starts rsyncd), then rsyncd can write to > >>>> /opt/solr/logs/rsyncd.log with no problems. > >>>> > >>>> If I put the symlink back in (to /var/log/store), then it > >>>> fails (again, with no AVC messages). > >>>> > >>>> The only difference I can see between /opt/solr/logs (as a > >>>> directory) and /var/log/store is the default contexts, for > >>>> /opt/solr/logs, it's root:object_r:usr_t, for /var/log/store > >>>> it's root:object_r:var_log_t > >>>> > >>>> When I put the symlink back, I tried changing the context of > >>>> /var/log/store to root:object_r:usr_t to match > >>>> /opt/solr/logs, but that doesn't seem to make a difference. > >>>> > >>>> Max, a list member, suggested offline that it might have to > >>>> do with type_transition, which does seem to make sense. > >>>> > >>>> I tried both: > >>>> type_transition rsync_t var_log_t : file rsync_log_t; > >>>> and > >>>> type_transition rsync_t var_log_t : file usr_t; > >>>> > >>>> But neither worked (I have all the appropriate allows for > >>>> those contexts). > >>>> > >>>> > >>>> Am I going down the right path here (type_transition)? Or > >>>> does anyone else have a suggestion in terms of how the > >>>> symlink can be used? > >>> > >>> Can you try this policy module: > >>> > >>> :::::::::::::: > >>> solr.fc > >>> :::::::::::::: > >>> /var/log/store(/.*)? gen_context(system_u:object_r:rsync_log_t,s0) > >> == > >> > >> # semanage fcontext -a -t rsync_log_t "/var/log/store(/.*)?" > >> libsepol.context_from_record: type rsync_log_t is not defined > >> libsepol.context_from_record: could not create context structure > >> libsemanage.validate_handler: invalid context > >> system_u:object_r:rsync_log_t:s0 specified for > >> /var/log/store(/.*)? [all files] > >> libsemanage.dbase_llist_iterate: could not iterate over records > >> /usr/sbin/semanage: Could not add file context for > >> /var/log/store(/.*)? > >> > >> == > >> > >> It seems rsync_log_t is not defined. Can I somehow do this > >> without having rsync_log_t? > >> > >> It works fine when I don't use a symlink, so I assume > >> rsync_log_t is not necessary for this to work. > >> > >> But I need the symlink because I need the files to be stored > >> in /var/log/store, as opposed to /opt/solr/logs. > > > > I thought from earlier messages you were on RHEL 5? I've tested this > > module with CentOS 5.2 and it loads just fine. > > > > Which policy version are you using? > > selinux-policy-2.4.6-106.el5_1.3 > > I haven't updated yet to 5.2 Try adding the type definition to the top of the policy module (just after the "policy_module" line): type rsync_log_t; logging_log_file(rsync_log_t) Paul. > > johnn > From linuxweb at gmail.com Tue Jul 8 21:57:48 2008 From: linuxweb at gmail.com (Johnny Tan) Date: Tue, 08 Jul 2008 17:57:48 -0400 Subject: rsyncd can't open log file, but there are no avc messages In-Reply-To: <20080708220155.1b79a093@metropolis.intra.city-fan.org> References: <48610E19.6040604@gmail.com> <48724C03.6070806@gmail.com> <20080707233020.6f7fdfb0@metropolis.intra.city-fan.org> <4873CFBD.1080505@gmail.com> <20080708213842.1dc797e1@metropolis.intra.city-fan.org> <4873D34C.7030307@gmail.com> <20080708220155.1b79a093@metropolis.intra.city-fan.org> Message-ID: <4873E2DC.5080702@gmail.com> Paul Howarth wrote: >>>> It seems rsync_log_t is not defined. Can I somehow do this >>>> without having rsync_log_t? >>>> >>>> It works fine when I don't use a symlink, so I assume >>>> rsync_log_t is not necessary for this to work. >>>> >>>> But I need the symlink because I need the files to be stored >>>> in /var/log/store, as opposed to /opt/solr/logs. >>> I thought from earlier messages you were on RHEL 5? I've tested this >>> module with CentOS 5.2 and it loads just fine. >>> >>> Which policy version are you using? >> selinux-policy-2.4.6-106.el5_1.3 >> >> I haven't updated yet to 5.2 > > Try adding the type definition to the top of the policy module (just > after the "policy_module" line): > > type rsync_log_t; > logging_log_file(rsync_log_t) That still didn't recognize rsync_log_t. But I went ahead and upgraded to 5.2, and my original selinux policy works -- it doesn't use rsync_log_t at all. My (completely wild) guess is that something with symlinks ("class lnk_file") got fixed in the new policy, but I don't know what. Thanks for the help though! johnn From linuxweb at gmail.com Tue Jul 8 22:16:15 2008 From: linuxweb at gmail.com (Johnny Tan) Date: Tue, 08 Jul 2008 18:16:15 -0400 Subject: rsyncd can't open log file, but there are no avc messages In-Reply-To: <4873E2DC.5080702@gmail.com> References: <48610E19.6040604@gmail.com> <48724C03.6070806@gmail.com> <20080707233020.6f7fdfb0@metropolis.intra.city-fan.org> <4873CFBD.1080505@gmail.com> <20080708213842.1dc797e1@metropolis.intra.city-fan.org> <4873D34C.7030307@gmail.com> <20080708220155.1b79a093@metropolis.intra.city-fan.org> <4873E2DC.5080702@gmail.com> Message-ID: <4873E72F.7010504@gmail.com> Johnny Tan wrote: > Paul Howarth wrote: >>>>> It seems rsync_log_t is not defined. Can I somehow do this without >>>>> having rsync_log_t? >>>>> >>>>> It works fine when I don't use a symlink, so I assume rsync_log_t >>>>> is not necessary for this to work. >>>>> >>>>> But I need the symlink because I need the files to be stored in >>>>> /var/log/store, as opposed to /opt/solr/logs. >>>> I thought from earlier messages you were on RHEL 5? I've tested this >>>> module with CentOS 5.2 and it loads just fine. >>>> >>>> Which policy version are you using? >>> selinux-policy-2.4.6-106.el5_1.3 >>> >>> I haven't updated yet to 5.2 >> >> Try adding the type definition to the top of the policy module (just >> after the "policy_module" line): >> >> type rsync_log_t; >> logging_log_file(rsync_log_t) > > That still didn't recognize rsync_log_t. But I went ahead and upgraded > to 5.2, and my original selinux policy works -- it doesn't use > rsync_log_t at all. Question: Is it ok to update ONLY selinux-policy to the version that comes with 5.2 (and library, etc., dependencies) WITHOUT upgrading the kernel and everything else to their 5.2 versions? johnn From cra at WPI.EDU Wed Jul 9 00:17:46 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 8 Jul 2008 20:17:46 -0400 Subject: rsyncd can't open log file, but there are no avc messages In-Reply-To: <4873E2DC.5080702@gmail.com> References: <48610E19.6040604@gmail.com> <48724C03.6070806@gmail.com> <20080707233020.6f7fdfb0@metropolis.intra.city-fan.org> <4873CFBD.1080505@gmail.com> <20080708213842.1dc797e1@metropolis.intra.city-fan.org> <4873D34C.7030307@gmail.com> <20080708220155.1b79a093@metropolis.intra.city-fan.org> <4873E2DC.5080702@gmail.com> Message-ID: <20080709001746.GM32483@angus.ind.WPI.EDU> On Tue, Jul 08, 2008 at 05:57:48PM -0400, Johnny Tan wrote: > My (completely wild) guess is that something with symlinks ("class > lnk_file") got fixed in the new policy, but I don't know what. symlinks + SELinux are difficult to deal with. It is MUCH easier to just use bind mounts: mount --bind /opt/solr/logs /var/log/store in /etc/fstab: /opt/solr/logs /var/log/store none bind 0 0 From dwalsh at redhat.com Wed Jul 9 13:50:49 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 09 Jul 2008 09:50:49 -0400 Subject: rsyncd can't open log file, but there are no avc messages In-Reply-To: <4873E72F.7010504@gmail.com> References: <48610E19.6040604@gmail.com> <48724C03.6070806@gmail.com> <20080707233020.6f7fdfb0@metropolis.intra.city-fan.org> <4873CFBD.1080505@gmail.com> <20080708213842.1dc797e1@metropolis.intra.city-fan.org> <4873D34C.7030307@gmail.com> <20080708220155.1b79a093@metropolis.intra.city-fan.org> <4873E2DC.5080702@gmail.com> <4873E72F.7010504@gmail.com> Message-ID: <4874C239.2050903@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johnny Tan wrote: | Johnny Tan wrote: |> Paul Howarth wrote: |>>>>> It seems rsync_log_t is not defined. Can I somehow do this without |>>>>> having rsync_log_t? |>>>>> |>>>>> It works fine when I don't use a symlink, so I assume rsync_log_t |>>>>> is not necessary for this to work. |>>>>> |>>>>> But I need the symlink because I need the files to be stored in |>>>>> /var/log/store, as opposed to /opt/solr/logs. |>>>> I thought from earlier messages you were on RHEL 5? I've tested this |>>>> module with CentOS 5.2 and it loads just fine. |>>>> |>>>> Which policy version are you using? |>>> selinux-policy-2.4.6-106.el5_1.3 |>>> |>>> I haven't updated yet to 5.2 |>> |>> Try adding the type definition to the top of the policy module (just |>> after the "policy_module" line): |>> |>> type rsync_log_t; |>> logging_log_file(rsync_log_t) |> |> That still didn't recognize rsync_log_t. But I went ahead and upgraded |> to 5.2, and my original selinux policy works -- it doesn't use |> rsync_log_t at all. | | Question: | | Is it ok to update ONLY selinux-policy to the version that comes with | 5.2 (and library, etc., dependencies) WITHOUT upgrading the kernel and | everything else to their 5.2 versions? | Yes | johnn | | -- | fedora-selinux-list mailing list | fedora-selinux-list at redhat.com | https://www.redhat.com/mailman/listinfo/fedora-selinux-list -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh0wjkACgkQrlYvE4MpobOMlgCgg4t9GiG/3YDOTliINaaOuXMa gxIAn079tVvoEgMLQXmK2fxMfckroMEZ =y1mH -----END PGP SIGNATURE----- From kas at fi.muni.cz Wed Jul 9 14:05:37 2008 From: kas at fi.muni.cz (Jan Kasprzak) Date: Wed, 9 Jul 2008 16:05:37 +0200 Subject: Enabling SELinux on a custom kernel In-Reply-To: <20080708141925.GA13564@us.ibm.com> References: <20080708091041.GY7614@fi.muni.cz> <1215519847.27975.223.camel@moss-spartans.epoch.ncsc.mil> <20080708141925.GA13564@us.ibm.com> Message-ID: <20080709140537.GO7614@fi.muni.cz> Serge E. Hallyn wrote: : Quoting Stephen Smalley (sds at tycho.nsa.gov): : > Your options would seem to be: : > - use an initrd (easiest), : > - re-patch your /sbin/init program, : > - try to do it from inittab or rc.sysinit (but the problem there is that : > it doesn't get /sbin/init itself into the right domain). : : Aaaah. I was wondering why my new f9-based kvm image wasn't enabling : selinux when I started it with "-kernel bzImage". That's going to be : a bit of a pain, as I assume I'll have to import the kernel tree into : the f9 image in order to create an initrd. Mkinitrd does not need the kernel tree, just the modules installed in /lib/modules/`uname -r`, some libraries from /lib{,64}, and some configuration files (mdadm.conf, fstab, ld.so.conf). I had to iterate over mkinitrd /boot/initrd-2.6.25.10 2.6.25.10 adding --builtin=... options until it succeeded, and the resulting initrd worked (at least it did load the SELinux policy). -Yenya -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ | >> If you find yourself arguing with Alan Cox, you?re _probably_ wrong. << >> --James Morris in "How and Why You Should Become a Kernel Hacker" << From kas at fi.muni.cz Wed Jul 9 14:10:02 2008 From: kas at fi.muni.cz (Jan Kasprzak) Date: Wed, 9 Jul 2008 16:10:02 +0200 Subject: Postfix avcs (Re: Enabling SELinux on a custom kernel) In-Reply-To: <1215526745.27975.268.camel@moss-spartans.epoch.ncsc.mil> References: <20080708091041.GY7614@fi.muni.cz> <1215519847.27975.223.camel@moss-spartans.epoch.ncsc.mil> <20080708131745.GA7614@fi.muni.cz> <1215523428.27975.255.camel@moss-spartans.epoch.ncsc.mil> <20080708134807.GB7614@fi.muni.cz> <20080708141653.GC7614@fi.muni.cz> <1215526745.27975.268.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20080709141002.GP7614@fi.muni.cz> Stephen Smalley wrote: : Can you check whether you have expand-check = 0 : in /etc/selinux/semanage.conf? If not present or commented out, add it : and retry. There was no such option in semanage.conf. After adding it, semodule -i took 13.2 seconds (9.7 user, 3.5 sys) on an otherwise idle machine (2x dual-core opteron 2222 3.0 GHz). With this option commented out, it was 175.8 real, 174.2 user, 1.6 sys). -Yenya -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ | >> If you find yourself arguing with Alan Cox, you?re _probably_ wrong. << >> --James Morris in "How and Why You Should Become a Kernel Hacker" << From sds at tycho.nsa.gov Wed Jul 9 14:21:17 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 09 Jul 2008 10:21:17 -0400 Subject: Postfix avcs (Re: Enabling SELinux on a custom kernel) In-Reply-To: <20080709141002.GP7614@fi.muni.cz> References: <20080708091041.GY7614@fi.muni.cz> <1215519847.27975.223.camel@moss-spartans.epoch.ncsc.mil> <20080708131745.GA7614@fi.muni.cz> <1215523428.27975.255.camel@moss-spartans.epoch.ncsc.mil> <20080708134807.GB7614@fi.muni.cz> <20080708141653.GC7614@fi.muni.cz> <1215526745.27975.268.camel@moss-spartans.epoch.ncsc.mil> <20080709141002.GP7614@fi.muni.cz> Message-ID: <1215613277.24864.8.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-07-09 at 16:10 +0200, Jan Kasprzak wrote: > Stephen Smalley wrote: > : Can you check whether you have expand-check = 0 > : in /etc/selinux/semanage.conf? If not present or commented out, add it > : and retry. > > There was no such option in semanage.conf. After adding it, > semodule -i took 13.2 seconds (9.7 user, 3.5 sys) on an otherwise > idle machine (2x dual-core opteron 2222 3.0 GHz). With this option > commented out, it was 175.8 real, 174.2 user, 1.6 sys). If you did a clean install, expand-check=0 should be present by default in semanage.conf as of F9 and later I believe. Or they could even make it the default value in libsemanage in Fedora if they wanted to do so (defined by libsemanage/src/conf_parse.y:semanage_conf_init()) so that it doesn't even require the semanage.conf setting. With expand-check=1 (default in the absence of any semanage.conf option), neverallow rule checking and type hierarchy checking is applied on every transaction to revalidate the updated policy, which is quite expensive. Consequently, Fedora has switched to disabling it at runtime. They still ought to be doing it during policy build though, but I don't see that (requires running make validate during the refpolicy build). Dan? I'd actually be curious to see how much of that time is due to neverallow vs. hierarchy checking, given that we ought to disable hierarchy checking since it isn't being used presently and has to be reworked for explicit hierarchy anyway. -- Stephen Smalley National Security Agency From cms06017 at fh-hagenberg.at Wed Jul 9 16:59:35 2008 From: cms06017 at fh-hagenberg.at (David) Date: Wed, 09 Jul 2008 18:59:35 +0200 Subject: SELinux DoS? Message-ID: <4874EE77.4040702@fh-hagenberg.at> Hey Guys! Some colleagues and I tested the behavior of SELinux due to a project on the university. So we wrote a little test program and the necessary policies. Overall it works fine, but we build in a bug in our test program which offers the exploitation through a stack based buffer overflow. When we tried to getting a root shell based on this bug (the demo tool has set suid bit), SELinux prevents the execution of the shell, but the demo program will not be quitted. It hangs at the point of trying to open the shell and SELinux writes endless log entries to /var/log/audit/audit.log. We assumed that this behavior will occur due to following actions: - demo tool tries to open a shell via shellcode, occurred through a buffer overflow. - selinux prevents this execution. - the function-call in demo tool tries to jump back to the return address, - but the address is overwritten through the bof. - so, it jumps to the buffer and tries to open a shell again. All together in a endless loop. This behavior seems to be alright from technical aspect, but should this be the behavior of selinux? Or is there an option which instructs selinux to kill processes which tries pass over there contexts too often? For instance, this manner could be easy used for DoS Attacks. Our tests exhibits that the execution of many demo program instances will make the system unusable. Any ideas about this behavior, or any solution? David (Tested on FC9.) From sds at tycho.nsa.gov Wed Jul 9 18:12:52 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 09 Jul 2008 14:12:52 -0400 Subject: SELinux DoS? In-Reply-To: <4874EE77.4040702@fh-hagenberg.at> References: <4874EE77.4040702@fh-hagenberg.at> Message-ID: <1215627172.31554.27.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-07-09 at 18:59 +0200, David wrote: > Hey Guys! > > Some colleagues and I tested the behavior of SELinux due to a project on > the university. So we wrote a little test program and the necessary > policies. > Overall it works fine, but we build in a bug in our test program which > offers the exploitation through a stack based buffer overflow. > When we tried to getting a root shell based on this bug (the demo tool > has set suid bit), SELinux prevents the execution of the shell, but the > demo program will not be quitted. > It hangs at the point of trying to open the shell and SELinux writes > endless log entries to /var/log/audit/audit.log. > > We assumed that this behavior will occur due to following actions: > > - demo tool tries to open a shell via shellcode, occurred through a > buffer overflow. > - selinux prevents this execution. > - the function-call in demo tool tries to jump back to the return address, > - but the address is overwritten through the bof. > - so, it jumps to the buffer and tries to open a shell again. > All together in a endless loop. > > This behavior seems to be alright from technical aspect, but should this > be the behavior of selinux? Or is there an option which instructs > selinux to kill processes which tries pass over there contexts too often? > > For instance, this manner could be easy used for DoS Attacks. Our tests > exhibits that the execution of many demo program instances will make the > system unusable. > > Any ideas about this behavior, or any solution? That's not really a selinux issue per se, but rather an audit issue. auditctl does have a ratelimit option (-r) to throttle audit, and you can put default rules you want applied at startup into /etc/audit/audit.rules. You could also write an audit backend (using audispd to dispatch events to it) that would detect such flooding and possibly kill the responsible party, although danger lurks there. Executable stack should/could have been mitigated by execshield and by the selinux execmem/execstack controls if applied. -- Stephen Smalley National Security Agency From rstory at sparta.com Wed Jul 9 21:03:21 2008 From: rstory at sparta.com (Robert Story) Date: Wed, 9 Jul 2008 17:03:21 -0400 Subject: kerberos server + enforcing mode? In-Reply-To: <486D20CB.2000502@redhat.com> References: <20080701193704.36814ade@sparta.com> <486D20CB.2000502@redhat.com> Message-ID: <20080709170321.5675fa81@sparta.com> On Thu, 3 Jul 2008 14:56:11 -0400 Daniel wrote: DJW> Robert Story wrote: DJW> > DJW> > I'm trying to set up a kerberos KDC on a clean up-to-date F9 box in DJW> > enforcing mode. [...] Also, I get an error when starting krb5kdc: DJW> > DJW> > Starting Kerberos 5 KDC: Couldn't open log file /var/log/krb5kdc.log: Permission denied DJW> > DJW> > The accompanying avc is: DJW> > DJW> > Jul 1 18:04:55 tib kernel: type=1400 audit(1214949895.536:4): avc: denied { create } for pid=1839 comm="krb5kdc" name="krb5kdc.log" scontext=unconfined_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:krb5kdc_log_t:s0 tclass=file DJW> > DJW> Seems you stumbled upon a strange avc. DJW> DJW> If you type DJW> DJW> # touch /var/log/krb5kdc.log DJW> # restorecon /var/log/krb5kdc.log DJW> DJW> Then start the service, does it work? yep. DJW> This is a long way of saying I need to update the policy to allow DJW> krbkdc_t to create the file. DJW> DJW> Fixed in selinux-policy-3.3.1-76.fc9.noarch Ok.. while waiting for that, I used audit2allow to load the following policy: module mypolicy0807091636 1.0; require { type krb5kdc_t; type krb5kdc_log_t; class file { create }; } #============= krb5kdc_t ============== allow krb5kdc_t krb5kdc_log_t:file create; But I'm still getting the avc.. What else is missing? -- Robert Story SPARTA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rstory at sparta.com Wed Jul 9 21:20:00 2008 From: rstory at sparta.com (Robert Story) Date: Wed, 9 Jul 2008 17:20:00 -0400 Subject: kerberos server + enforcing mode? In-Reply-To: <20080701193704.36814ade@sparta.com> References: <20080701193704.36814ade@sparta.com> Message-ID: <20080709172000.69781057@sparta.com> I'm still getting "modify_principal: Insufficient access to lock database" error messages when trying to use kadmin in enforcing mode.I ran 'semodule -DB' to re-enable don't audit messages, and I've attached what I get when trying to run a kadmin command to add a principal (after starting kadmind/krb5kdc... kadmin.log seems to be ok). Any hint, tips or policy modules greatly appreciated... -- Robert Story SPARTA -------------- next part -------------- A non-text attachment was scrubbed... Name: avcs Type: application/octet-stream Size: 2515 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dant at cdkkt.com Thu Jul 10 00:47:03 2008 From: dant at cdkkt.com (Dan Thurman) Date: Wed, 09 Jul 2008 17:47:03 -0700 Subject: Problems with mod_mono on httpd Message-ID: <48755C07.7080406@cdkkt.com> The issue relates to using the mod_mono module (I think): Jul 9 17:28:31 bronze kernel: mono[8896]: segfault at 0 ip 08069d02 sp bf8a6540 error 6 in mono[8047000+1f4000] Jul 9 17:28:32 bronze setroubleshoot: SELinux is preventing mono (httpd_t) "execmem" to (httpd_t). For complete SELinux messages. run sealert -l 2cb69eb1-baf7-4631-936c-9f6c80436e2e Jul 9 17:28:32 bronze setroubleshoot: SELinux is preventing mono (httpd_t) "execmem" to (httpd_t). For complete SELinux messages. run sealert -l 2cb69eb1-baf7-4631-936c-9f6c80436e2e # sealert -l 2cb69eb1-baf7-4631-936c-9f6c80436e2e ========================================== Summary: SELinux is preventing mono (httpd_t) "execmem" to (httpd_t). Detailed Description: SELinux denied access requested by mono. It is not expected that this access is required by mono and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context system_u:system_r:httpd_t:s0 Target Objects None [ process ] Source mono Source Path /usr/bin/mono Port Host bronze.cdkkt.com Source RPM Packages mono-core-1.9.1-2.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-74.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name bronze.cdkkt.com Platform Linux bronze.cdkkt.com 2.6.25.9-76.fc9.i686 #1 SMP Fri Jun 27 16:14:35 EDT 2008 i686 i686 Alert Count 26 First Seen Tue Jul 8 16:54:41 2008 Last Seen Wed Jul 9 17:28:31 2008 Local ID 2cb69eb1-baf7-4631-936c-9f6c80436e2e Line Numbers Raw Audit Messages host=bronze.cdkkt.com type=AVC msg=audit(1215649711.436:45): avc: denied { execmem } for pid=8896 comm="mono" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=process host=bronze.cdkkt.com type=SYSCALL msg=audit(1215649711.436:45): arch=40000003 syscall=192 per=400000 success=no exit=-13 a0=0 a1=10000 a2=7 a3=22 items=0 ppid=1 pid=8896 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="mono" exe="/usr/bin/mono" subj=system_u:system_r:httpd_t:s0 key=(null) How can I fix this please? Dan From dant at cdkkt.com Thu Jul 10 01:53:05 2008 From: dant at cdkkt.com (Dan Thurman) Date: Wed, 09 Jul 2008 18:53:05 -0700 Subject: F9: Problems with named logging files Message-ID: <48756B81.10901@cdkkt.com> I have not been able to solve this issue but was able to 'get around' it via F8. Below is the named.conf, just for the logging group: ========================================= logging { channel my_syslog { file "/var/log/named/named.log" versions 25; severity info; print-category yes; print-time yes; }; channel my_lame { file "/var/log/named/lame.log" versions 25; severity info; print-category yes; print-time yes; // size 50M; }; channel my_xfer { file "/var/log/named/xfer.log" versions 25; severity info; print-category yes; print-time yes; // size 50M; }; channel my_update { file "/var/log/named/named.update" versions 25; severity info; print-category yes; print-time yes; // size 50M; }; channel my_db { file "/var/log/named/db.log" versions 25; severity info; print-category yes; print-time yes; // size 50M; }; channel my_query { file "/var/log/named/query.log" versions 25; severity info; print-category yes; print-time yes; // size 50M; }; channel my_security { file "/var/log/named/security.log" versions 99; severity info; print-category yes; print-time yes; // size 50M; }; channel my_debug { file "/var/log/named/named.debug" versions 20; severity dynamic; print-category yes; print-time yes; // size 50M; }; category security { my_security; }; category default { my_syslog; }; category queries { my_query; }; category lame-servers { my_lame; }; category update { my_update; }; // category db { my_db; }; category xfer-in { my_xfer; }; category xfer-out { my_xfer; }; // category packet { null; }; // category eventlib { my_syslog; }; }; ========================================= Please note that the pathname is chrooted and is actually found in: /var/named/chroot/var/log/named and the files are initially set there with proper context of named_log_t and the directory permissions set with user named with access and context set accordingly. Below is the selinux complaint: ========================================= From: /var/log/messages: ------------------------------- Jul 9 18:43:27 bronze named[10903]: unable to rename log file '/var/log/named/named.log' to '/var/log/named/named.log.0': permission denied Jul 9 18:43:27 bronze setroubleshoot: SELinux is preventing named (named_t) "write" to ./named (named_conf_t). For complete SELinux messages. run sealert -l ebd583dd-e96e-49ad-b6ce-72eda7273b09 # sealert -l ebd583dd-e96e-49ad-b6ce-72eda7273b09 ========================================= Summary: SELinux is preventing named (named_t) "write" to ./named (named_conf_t). Detailed Description: SELinux denied access requested by named. It is not expected that this access is required by named and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./named, restorecon -v './named' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context unconfined_u:system_r:named_t:s0 Target Context system_u:object_r:named_conf_t:s0 Target Objects ./named [ dir ] Source named Source Path /usr/sbin/named Port Host bronze.cdkkt.com Source RPM Packages bind-9.5.0-32.rc1.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-74.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name bronze.cdkkt.com Platform Linux bronze.cdkkt.com 2.6.25.9-76.fc9.i686 #1 SMP Fri Jun 27 16:14:35 EDT 2008 i686 i686 Alert Count 1 First Seen Wed Jul 9 18:43:27 2008 Last Seen Wed Jul 9 18:43:27 2008 Local ID ebd583dd-e96e-49ad-b6ce-72eda7273b09 Line Numbers Raw Audit Messages host=bronze.cdkkt.com type=AVC msg=audit(1215654207.611:139): avc: denied { write } for pid=10904 comm="named" name="named" dev=sda6 ino=2023442 scontext=unconfined_u:system_r:named_t:s0 tcontext=system_u:object_r:named_conf_t:s0 tclass=dir host=bronze.cdkkt.com type=SYSCALL msg=audit(1215654207.611:139): arch=40000003 syscall=38 success=no exit=-13 a0=b547a4e8 a1=b7ee488a a2=4932fc a3=b7ee488a items=0 ppid=10902 pid=10904 auid=500 uid=25 gid=25 euid=25 suid=25 fsuid=25 egid=25 sgid=25 fsgid=25 tty=(none) ses=2 comm="named" exe="/usr/sbin/named" subj=unconfined_u:system_r:named_t:s0 key=(null) ========================================= I have tried changing the context, permissions, restorecon and nothing seemed to help. Advice please? Thanks! Dan From paul at city-fan.org Thu Jul 10 06:33:41 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 10 Jul 2008 07:33:41 +0100 Subject: F9: Problems with named logging files In-Reply-To: <48756B81.10901@cdkkt.com> References: <48756B81.10901@cdkkt.com> Message-ID: <20080710073341.6eaf2385@metropolis.intra.city-fan.org> On Wed, 09 Jul 2008 18:53:05 -0700 Dan Thurman wrote: > I have not been able to solve this issue but was able to 'get around' > it via F8. > > Below is the named.conf, just for the logging group: > ========================================= > logging { > channel my_syslog { file "/var/log/named/named.log" versions 25; > severity info; > print-category yes; > print-time yes; > }; > channel my_lame { file "/var/log/named/lame.log" versions 25; > severity info; > print-category yes; > print-time yes; > // size 50M; > }; > channel my_xfer { file "/var/log/named/xfer.log" versions 25; > severity info; > print-category yes; > print-time yes; > // size 50M; > }; > channel my_update { file "/var/log/named/named.update" versions > 25; severity info; > print-category yes; > print-time yes; > // size 50M; > }; > channel my_db { file "/var/log/named/db.log" versions 25; > severity info; > print-category yes; > print-time yes; > // size 50M; > }; > channel my_query { file "/var/log/named/query.log" versions 25; > severity info; > print-category yes; > print-time yes; > // size 50M; > }; > channel my_security { file "/var/log/named/security.log" versions > 99; severity info; > print-category yes; > print-time yes; > // size 50M; > }; > channel my_debug { file "/var/log/named/named.debug" versions 20; > severity dynamic; > print-category yes; > print-time yes; > // size 50M; > }; > > category security { my_security; }; > category default { my_syslog; }; > category queries { my_query; }; > category lame-servers { my_lame; }; > category update { my_update; }; > // category db { my_db; }; > category xfer-in { my_xfer; }; > category xfer-out { my_xfer; }; > // category packet { null; }; > // category eventlib { my_syslog; }; > > }; > ========================================= > Please note that the pathname is chrooted and is actually > found in: /var/named/chroot/var/log/named and the files > are initially set there with proper context of named_log_t > and the directory permissions set with user named with > access and context set accordingly. > > Below is the selinux complaint: > ========================================= > From: /var/log/messages: > ------------------------------- > Jul 9 18:43:27 bronze named[10903]: unable to rename log file > '/var/log/named/named.log' to '/var/log/named/named.log.0': > permission denied > Jul 9 18:43:27 bronze setroubleshoot: SELinux is preventing named > (named_t) "write" to ./named (named_conf_t). For complete SELinux > messages. run sealert -l ebd583dd-e96e-49ad-b6ce-72eda7273b09 > > # sealert -l ebd583dd-e96e-49ad-b6ce-72eda7273b09 > ========================================= > Summary: > > SELinux is preventing named (named_t) "write" to ./named > (named_conf_t). > > Detailed Description: > > SELinux denied access requested by named. It is not expected that > this access is > required by named and this access may signal an intrusion attempt. It > is also > possible that the specific version or configuration of the > application is causing it to require additional access. > > Allowing Access: > > Sometimes labeling problems can cause SELinux denials. You could try > to restore > the default system file context for ./named, > > restorecon -v './named' > > If this does not work, there is currently no automatic way to allow > this access. > Instead, you can generate a local policy module to allow this access > - see FAQ > (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can > disable > SELinux protection altogether. Disabling SELinux protection is not > recommended. > Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this > package. > > Additional Information: > > Source Context unconfined_u:system_r:named_t:s0 > Target Context system_u:object_r:named_conf_t:s0 > Target Objects ./named [ dir ] > Source named > Source Path /usr/sbin/named > Port > Host bronze.cdkkt.com > Source RPM Packages bind-9.5.0-32.rc1.fc9 > Target RPM Packages > Policy RPM selinux-policy-3.3.1-74.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall_file > Host Name bronze.cdkkt.com > Platform Linux bronze.cdkkt.com > 2.6.25.9-76.fc9.i686 #1 SMP > Fri Jun 27 16:14:35 EDT 2008 i686 i686 > Alert Count 1 > First Seen Wed Jul 9 18:43:27 2008 > Last Seen Wed Jul 9 18:43:27 2008 > Local ID ebd583dd-e96e-49ad-b6ce-72eda7273b09 > Line Numbers > > Raw Audit Messages > > host=bronze.cdkkt.com type=AVC msg=audit(1215654207.611:139): avc: > denied { write } for pid=10904 comm="named" name="named" dev=sda6 > ino=2023442 scontext=unconfined_u:system_r:named_t:s0 > tcontext=system_u:object_r:named_conf_t:s0 tclass=dir > > host=bronze.cdkkt.com type=SYSCALL msg=audit(1215654207.611:139): > arch=40000003 syscall=38 success=no exit=-13 a0=b547a4e8 a1=b7ee488a > a2=4932fc a3=b7ee488a items=0 ppid=10902 pid=10904 auid=500 uid=25 > gid=25 euid=25 suid=25 fsuid=25 egid=25 sgid=25 fsgid=25 tty=(none) > ses=2 comm="named" exe="/usr/sbin/named" > subj=unconfined_u:system_r:named_t:s0 key=(null) > ========================================= > > I have tried changing the context, permissions, restorecon and > nothing seemed to help. > > Advice please? Does this help? # chcon -R -t named_log_t /var/named/chroot/var/log/named Paul. From dwalsh at redhat.com Thu Jul 10 15:33:38 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 10 Jul 2008 11:33:38 -0400 Subject: Problems with mod_mono on httpd In-Reply-To: <48755C07.7080406@cdkkt.com> References: <48755C07.7080406@cdkkt.com> Message-ID: <48762BD2.2010602@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Thurman wrote: > The issue relates to using the mod_mono module (I think): > > Jul 9 17:28:31 bronze kernel: mono[8896]: segfault at 0 ip 08069d02 sp > bf8a6540 error 6 in mono[8047000+1f4000] > Jul 9 17:28:32 bronze setroubleshoot: SELinux is preventing mono > (httpd_t) "execmem" to (httpd_t). For complete SELinux > messages. run sealert -l 2cb69eb1-baf7-4631-936c-9f6c80436e2e > Jul 9 17:28:32 bronze setroubleshoot: SELinux is preventing mono > (httpd_t) "execmem" to (httpd_t). For complete SELinux > messages. run sealert -l 2cb69eb1-baf7-4631-936c-9f6c80436e2e > > # sealert -l 2cb69eb1-baf7-4631-936c-9f6c80436e2e > ========================================== > Summary: > > SELinux is preventing mono (httpd_t) "execmem" to (httpd_t). > > Detailed Description: > > SELinux denied access requested by mono. It is not expected that this > access is > required by mono and this access may signal an intrusion attempt. It is > also > possible that the specific version or configuration of the application is > causing it to require additional access. > > Allowing Access: > > You can generate a local policy module to allow this access - see FAQ > (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can > disable > SELinux protection altogether. Disabling SELinux protection is not > recommended. > Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > against this package. > > Additional Information: > > Source Context system_u:system_r:httpd_t:s0 > Target Context system_u:system_r:httpd_t:s0 > Target Objects None [ process ] > Source mono > Source Path /usr/bin/mono > Port > Host bronze.cdkkt.com > Source RPM Packages mono-core-1.9.1-2.fc9 > Target RPM Packages Policy RPM > selinux-policy-3.3.1-74.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall > Host Name bronze.cdkkt.com > Platform Linux bronze.cdkkt.com > 2.6.25.9-76.fc9.i686 #1 SMP > Fri Jun 27 16:14:35 EDT 2008 i686 i686 > Alert Count 26 > First Seen Tue Jul 8 16:54:41 2008 > Last Seen Wed Jul 9 17:28:31 2008 > Local ID 2cb69eb1-baf7-4631-936c-9f6c80436e2e > Line Numbers > Raw Audit Messages > host=bronze.cdkkt.com type=AVC msg=audit(1215649711.436:45): avc: > denied { execmem } for pid=8896 comm="mono" > scontext=system_u:system_r:httpd_t:s0 > tcontext=system_u:system_r:httpd_t:s0 tclass=process > > host=bronze.cdkkt.com type=SYSCALL msg=audit(1215649711.436:45): > arch=40000003 syscall=192 per=400000 success=no exit=-13 a0=0 a1=10000 > a2=7 a3=22 items=0 ppid=1 pid=8896 auid=4294967295 uid=48 gid=48 euid=48 > suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 > comm="mono" exe="/usr/bin/mono" subj=system_u:system_r:httpd_t:s0 > key=(null) > > How can I fix this please? > Dan > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list You can add it using audit2allow # grep http /var/log/audit/audit.log | audit2allow -M myhttp # semodule -i myhttp.pp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh2K9IACgkQrlYvE4MpobPCzwCglYTzWFBP4PhbYBTtAjbVtvMy sZwAmgPtHe6O1Uub3w41R43SqLaslLlt =K5F9 -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Jul 10 19:31:12 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 10 Jul 2008 15:31:12 -0400 Subject: kerberos server + enforcing mode? In-Reply-To: <20080709172000.69781057@sparta.com> References: <20080701193704.36814ade@sparta.com> <20080709172000.69781057@sparta.com> Message-ID: <48766380.1050204@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Story wrote: > I'm still getting "modify_principal: Insufficient access to lock > database" error messages when trying to use kadmin in enforcing mode.I > ran 'semodule -DB' to re-enable don't audit messages, and I've attached > what I get when trying to run a kadmin command to add a principal > (after starting kadmind/krb5kdc... kadmin.log seems to be ok). Any > hint, tips or policy modules greatly appreciated... > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Looks like this one is causing your problem. Looks like the files were created with the wrong labels or kadmin is not allowed to create. restorecon -R -v /var/kerberos I am fixing the policy to allow the creation of the lock files with the correct label. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh2Y4AACgkQrlYvE4MpobOlUgCgguLXylG2BPmDBEaKvw+INpjk uz0AnR1POUQwI+KnWvwZuzZHxxEekK+p =scDr -----END PGP SIGNATURE----- From kas at fi.muni.cz Thu Jul 10 20:05:19 2008 From: kas at fi.muni.cz (Jan Kasprzak) Date: Thu, 10 Jul 2008 22:05:19 +0200 Subject: Local modifications best practices? Message-ID: <20080710200519.GD2189@fi.muni.cz> Hello, are there any best practices for storing local modifications to the security policy? Where to put local *.fc and *.te files and how to create and install the binary modules from them? For example - on my router I keep the state data (arpwatch, dhcpd.leases, etc) on a shared DRBD volume, so I need to add local *.fc file for this volume, in order arpwatch and dhcpd can access it. So far I have put the local *.te and *.fc files into /root/selinux, created /root/selinux/Makefile, and I use "make" for compiling the modules, and "make install" for installing them. Is there any canonical way of doing this on Fedora? Thanks, -Yenya -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ | >> If you find yourself arguing with Alan Cox, you?re _probably_ wrong. << >> --James Morris in "How and Why You Should Become a Kernel Hacker" << From sds at tycho.nsa.gov Thu Jul 10 20:15:24 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 10 Jul 2008 16:15:24 -0400 Subject: Local modifications best practices? In-Reply-To: <20080710200519.GD2189@fi.muni.cz> References: <20080710200519.GD2189@fi.muni.cz> Message-ID: <1215720924.31554.75.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-07-10 at 22:05 +0200, Jan Kasprzak wrote: > Hello, > > are there any best practices for storing local modifications to the > security policy? Where to put local *.fc and *.te files and how to > create and install the binary modules from them? > > For example - on my router I keep the state data > (arpwatch, dhcpd.leases, etc) on a shared DRBD volume, so I need > to add local *.fc file for this volume, in order arpwatch and dhcpd > can access it. > > So far I have put the local *.te and *.fc files into /root/selinux, > created /root/selinux/Makefile, and I use "make" for compiling the > modules, and "make install" for installing them. Is there any canonical > way of doing this on Fedora? I don't think so, yet. The policy packages install under /usr/share/selinux/$SELINUXTYPE. Looks like some packages are installing under /usr/share/selinux/packages/$PACKAGENAME, e.g. BackupPC is putting its module .pp file there. The recent semanage permissive support is dynamically creating permissive domain modules under /var/lib/selinux but those are just temporary files I think to generate a .pp file and install it - they don't need to keep the .te file around afterward. -- Stephen Smalley National Security Agency From dant at cdkkt.com Fri Jul 11 15:14:21 2008 From: dant at cdkkt.com (Dan Thurman) Date: Fri, 11 Jul 2008 08:14:21 -0700 Subject: ./xauth? Message-ID: <487778CD.8040305@cdkkt.com> I am not sure what this is, and /.xauth does not exist, but here is the log: ================================ Summary: SELinux is preventing su (initrc_su_t) "execute" to ./xauth (xauth_exec_t). Detailed Description: SELinux denied access requested by su. It is not expected that this access is required by su and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./xauth, restorecon -v './xauth' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:initrc_su_t:s0 Target Context system_u:object_r:xauth_exec_t:s0 Target Objects ./xauth [ file ] Source su Source Path /bin/su Port Host bronze.cdkkt.com Source RPM Packages coreutils-6.10-25.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-74.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name bronze.cdkkt.com Platform Linux bronze.cdkkt.com 2.6.25.9-76.fc9.i686 #1 SMP Fri Jun 27 16:14:35 EDT 2008 i686 i686 Alert Count 4 First Seen Thu 10 Jul 2008 10:55:02 AM PDT Last Seen Fri 11 Jul 2008 07:37:29 AM PDT Local ID bb7e73a6-b94e-4bf3-9ada-46a9ff2ad486 Line Numbers Raw Audit Messages host=bronze.cdkkt.com type=AVC msg=audit(1215787049.815:33): avc: denied { execute } for pid=8831 comm="su" name="xauth" dev=sda6 ino=3121978 scontext=system_u:system_r:initrc_su_t:s0 tcontext=system_u:object_r:xauth_exec_t:s0 tclass=file host=bronze.cdkkt.com type=SYSCALL msg=audit(1215787049.815:33): arch=40000003 syscall=33 success=no exit=-13 a0=160642 a1=1 a2=161b80 a3=160642 items=0 ppid=8823 pid=8831 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="su" exe="/bin/su" subj=system_u:system_r:initrc_su_t:s0 key=(null) From dant at cdkkt.com Fri Jul 11 15:16:11 2008 From: dant at cdkkt.com (Dan Thurman) Date: Fri, 11 Jul 2008 08:16:11 -0700 Subject: mod_mono_server_global Message-ID: <4877793B.7040502@cdkkt.com> I get this consistenly. What can I do to fix this? ===================================== Summary: SELinux is preventing the mono from using potentially mislabeled files (mod_mono_server_global). Detailed Description: SELinux has denied mono access to potentially mislabeled file(s) (mod_mono_server_global). This means that SELinux will not allow mono to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing Access: If you want mono to access this files, you need to relabel them using restorecon -v 'mod_mono_server_global'. You might want to relabel the entire directory using restorecon -R -v ''. Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context system_u:object_r:tmp_t:s0 Target Objects mod_mono_server_global [ sock_file ] Source mono Source Path /usr/bin/mono Port Host bronze.cdkkt.com Source RPM Packages mono-core-1.9.1-2.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-74.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name home_tmp_bad_labels Host Name bronze.cdkkt.com Platform Linux bronze.cdkkt.com 2.6.25.9-76.fc9.i686 #1 SMP Fri Jun 27 16:14:35 EDT 2008 i686 i686 Alert Count 4 First Seen Thu 10 Jul 2008 10:55:05 AM PDT Last Seen Fri 11 Jul 2008 07:37:33 AM PDT Local ID 96f5392e-305d-47db-8dc8-93a057a25b0e Line Numbers Raw Audit Messages host=bronze.cdkkt.com type=AVC msg=audit(1215787053.571:36): avc: denied { create } for pid=8865 comm="mono" name="mod_mono_server_global" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file host=bronze.cdkkt.com type=SYSCALL msg=audit(1215787053.571:36): arch=40000003 syscall=102 per=400000 success=no exit=-13 a0=2 a1=bfc83fe0 a2=823b524 a3=4 items=0 ppid=1 pid=8865 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="mono" exe="/usr/bin/mono" subj=system_u:system_r:httpd_t:s0 key=(null) From dant at cdkkt.com Fri Jul 11 15:22:22 2008 From: dant at cdkkt.com (Dan Thurman) Date: Fri, 11 Jul 2008 08:22:22 -0700 Subject: awstats Message-ID: <48777AAE.3090508@cdkkt.com> Not sure what to do with this one... a fix please? ====================================== Summary: SELinux is preventing sh (awstats_t) "getattr" to / (fs_t). Detailed Description: SELinux denied access requested by sh. It is not expected that this access is required by sh and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:awstats_t:s0-s0:c0.c1023 Target Context system_u:object_r:fs_t:s0 Target Objects / [ filesystem ] Source awstats.pl Source Path Port Host bronze.cdkkt.com Source RPM Packages Target RPM Packages filesystem-2.4.13-1.fc9 Policy RPM selinux-policy-3.3.1-74.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name bronze.cdkkt.com Platform Linux bronze.cdkkt.com 2.6.25.9-76.fc9.i686 #1 SMP Fri Jun 27 16:14:35 EDT 2008 i686 i686 Alert Count 4 First Seen Fri 11 Jul 2008 08:01:08 AM PDT Last Seen Fri 11 Jul 2008 08:01:09 AM PDT Local ID b2a086fa-2d4d-4819-a560-b8f0049272c6 Line Numbers Raw Audit Messages host=bronze.cdkkt.com type=AVC msg=audit(1215788469.468:354): avc: denied { getattr } for pid=14761 comm="sh" name="/" dev=sda6 ino=2 scontext=system_u:system_r:awstats_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem From dant at cdkkt.com Fri Jul 11 15:28:42 2008 From: dant at cdkkt.com (Dan Thurman) Date: Fri, 11 Jul 2008 08:28:42 -0700 Subject: F9: gam_server Message-ID: <48777C2A.8030200@cdkkt.com> Again, more issues. Suggested fix? ============================ Summary: SELinux is preventing gam_server (gamin_t) "dac_override" to (gamin_t). Detailed Description: SELinux denied access requested by gam_server. It is not expected that this access is required by gam_server and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:gamin_t:s0 Target Context system_u:system_r:gamin_t:s0 Target Objects None [ capability ] Source gam_server Source Path /usr/libexec/gam_server Port Host bronze.cdkkt.com Source RPM Packages gamin-0.1.9-5.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-74.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name bronze.cdkkt.com Platform Linux bronze.cdkkt.com 2.6.25.9-76.fc9.i686 #1 SMP Fri Jun 27 16:14:35 EDT 2008 i686 i686 Alert Count 20 First Seen Thu 10 Jul 2008 10:35:43 AM PDT Last Seen Thu 10 Jul 2008 11:11:40 AM PDT Local ID 5eb1bf77-5c10-4071-9892-bac42ca11adb Line Numbers Raw Audit Messages host=bronze.cdkkt.com type=AVC msg=audit(1215713500.169:272): avc: denied { dac_override } for pid=11637 comm="gam_server" capability=1 scontext=system_u:system_r:gamin_t:s0 tcontext=system_u:system_r:gamin_t:s0 tclass=capability host=bronze.cdkkt.com type=AVC msg=audit(1215713500.169:272): avc: denied { dac_read_search } for pid=11637 comm="gam_server" capability=2 scontext=system_u:system_r:gamin_t:s0 tcontext=system_u:system_r:gamin_t:s0 tclass=capability host=bronze.cdkkt.com type=SYSCALL msg=audit(1215713500.169:272): arch=40000003 syscall=33 success=no exit=-13 a0=96ca580 a1=0 a2=4b9264 a3=10 items=0 ppid=1 pid=11637 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="gam_server" exe="/usr/libexec/gam_server" subj=system_u:system_r:gamin_t:s0 key=(null) From roth at ursus.net Fri Jul 11 15:43:04 2008 From: roth at ursus.net (Carl D. Roth) Date: Fri, 11 Jul 2008 15:43:04 +0000 (UTC) Subject: ./xauth? References: <487778CD.8040305@cdkkt.com> Message-ID: On Fri, 11 Jul 2008 08:14:21 -0700, Dan Thurman wrote: > I am not sure what this is, and /.xauth does not exist, but here is the > log: > ================================ > Summary: > > SELinux is preventing su (initrc_su_t) "execute" to ./xauth > (xauth_exec_t). > > Detailed Description: > I had that happen on one of my systems too. It was starting a service in init.d that changed userid's via 'su'. Since it was a headless application (i.e. daemon) I chose to ignore the errors as follows: gen_require(` type initrc_su_t; type sshd_t; type xauth_exec_t; ') dontaudit initrc_su_t sshd_t:key { search }; dontaudit initrc_su_t xauth_exec_t:file { execute }; As you can see, the 'su' session also tried to grovel around for SSH keys. C From paul at city-fan.org Fri Jul 11 15:57:57 2008 From: paul at city-fan.org (Paul Howarth) Date: Fri, 11 Jul 2008 16:57:57 +0100 Subject: ./xauth? In-Reply-To: References: <487778CD.8040305@cdkkt.com> Message-ID: <48778305.6010205@city-fan.org> Carl D. Roth wrote: > On Fri, 11 Jul 2008 08:14:21 -0700, Dan Thurman wrote: > >> I am not sure what this is, and /.xauth does not exist, but here is the >> log: >> ================================ >> Summary: >> >> SELinux is preventing su (initrc_su_t) "execute" to ./xauth >> (xauth_exec_t). >> >> Detailed Description: >> > > I had that happen on one of my systems too. It was starting a service in > init.d that changed userid's via 'su'. Since it was a headless > application (i.e. daemon) I chose to ignore the errors as follows: > > gen_require(` > type initrc_su_t; > type sshd_t; > type xauth_exec_t; > ') > > dontaudit initrc_su_t sshd_t:key { search }; > dontaudit initrc_su_t xauth_exec_t:file { execute }; > > As you can see, the 'su' session also tried to grovel around for SSH keys. Does it behave better if you use "runuser" instead of "su"? Paul. From tmraz at redhat.com Fri Jul 11 16:00:42 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 11 Jul 2008 18:00:42 +0200 Subject: ./xauth? In-Reply-To: References: <487778CD.8040305@cdkkt.com> Message-ID: <1215792042.29451.1.camel@vespa.frost.loc> On Fri, 2008-07-11 at 15:43 +0000, Carl D. Roth wrote: > On Fri, 11 Jul 2008 08:14:21 -0700, Dan Thurman wrote: > > > I am not sure what this is, and /.xauth does not exist, but here is the > > log: > > ================================ > > Summary: > > > > SELinux is preventing su (initrc_su_t) "execute" to ./xauth > > (xauth_exec_t). > > > > Detailed Description: > > > > I had that happen on one of my systems too. It was starting a service in > init.d that changed userid's via 'su'. Since it was a headless > application (i.e. daemon) I chose to ignore the errors as follows: > > gen_require(` > type initrc_su_t; > type sshd_t; > type xauth_exec_t; > ') > > dontaudit initrc_su_t sshd_t:key { search }; > dontaudit initrc_su_t xauth_exec_t:file { execute }; > > As you can see, the 'su' session also tried to grovel around for SSH keys. If there is a service which runs su in init scripts it should be reported as bug on the package which owns the service. 'runuser' should be used instead of 'su' in init scripts. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From roth at ursus.net Sat Jul 12 18:49:53 2008 From: roth at ursus.net (Carl D. Roth) Date: Sat, 12 Jul 2008 18:49:53 +0000 (UTC) Subject: ./xauth? References: <487778CD.8040305@cdkkt.com> <48778305.6010205@city-fan.org> Message-ID: On Fri, 11 Jul 2008 16:57:57 +0100, Paul Howarth wrote: > Carl D. Roth wrote: >> On Fri, 11 Jul 2008 08:14:21 -0700, Dan Thurman wrote: >> >>> I am not sure what this is, and /.xauth does not exist, but here is >>> the log: >>> ================================ >>> Summary: >>> >>> SELinux is preventing su (initrc_su_t) "execute" to ./xauth >>> (xauth_exec_t). >>> >>> Detailed Description: >>> >>> >> I had that happen on one of my systems too. It was starting a service >> in init.d that changed userid's via 'su'. Since it was a headless >> application (i.e. daemon) I chose to ignore the errors as follows: >> >> gen_require(` >> type initrc_su_t; >> type sshd_t; >> type xauth_exec_t; >> ') >> >> dontaudit initrc_su_t sshd_t:key { search }; dontaudit initrc_su_t >> xauth_exec_t:file { execute }; >> >> As you can see, the 'su' session also tried to grovel around for SSH >> keys. > > Does it behave better if you use "runuser" instead of "su"? > > Paul. That fixed it, thanks. C From frankly3d at gmail.com Sun Jul 13 10:41:34 2008 From: frankly3d at gmail.com (Frank Murphy) Date: Sun, 13 Jul 2008 11:41:34 +0100 Subject: Can an ISO be specified allow mount "setsebool -P allow_mount_iso=1" insted of "setsebool -P allow_mount_anyfile=1" SE context samba share Message-ID: <1215945694.5240.3.camel@frank-01> Summary: SELinux prevented mount from mounting on the file or directory "./Fedora-9-Everything-i386-DVD1.iso" (type "samba_share_t"). Detailed Description: SELinux prevented mount from mounting a filesystem on the file or directory "./Fedora-9-Everything-i386-DVD1.iso" of type "samba_share_t". By default SELinux limits the mounting of filesystems to only some files or directories (those with types that have the mountpoint attribute). The type "samba_share_t" does not have this attribute. You can either relabel the file or directory or set the boolean "allow_mount_anyfile" to true to allow mounting on any file or directory. Allowing Access: Changing the "allow_mount_anyfile" boolean to true will allow this access: "setsebool -P allow_mount_anyfile=1." The following command will allow this access: setsebool -P allow_mount_anyfile=1 Additional Information: Source Context system_u:system_r:mount_t Target Context user_u:object_r:samba_share_t Target Objects ./Fedora-9-Everything-i386-DVD1.iso [ file ] Source mount Source Path /bin/mount Port Host server-01 Source RPM Packages util-linux-2.13-0.47.el5 Target RPM Packages Policy RPM selinux-policy-2.4.6-137.1.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name allow_mount_anyfile Host Name server-01 Platform Linux server-01 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 athlon Alert Count 3 First Seen Sun 13 Jul 2008 10:26:26 IST Last Seen Sun 13 Jul 2008 11:07:49 IST Local ID 268bdb54-5d8d-4c81-b7ba-0392b5cea34e Line Numbers Raw Audit Messages host=server-01 type=AVC msg=audit(1215943669.186:14): avc: denied { write } for pid=2898 comm="mount" name="Fedora-9-Everything-i386-DVD1.iso" dev=md2 ino=8585227 scontext=system_u:system_r:mount_t:s0 tcontext=user_u:object_r:samba_share_t:s0 tclass=file host=server-01 type=SYSCALL msg=audit(1215943669.186:14): arch=40000003 syscall=5 success=no exit=-13 a0=9fd5450 a1=8002 a2=0 a3=8002 items=0 ppid=2877 pid=2898 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mount" exe="/bin/mount" subj=system_u:system_r:mount_t:s0 key=(null) From paul at city-fan.org Sun Jul 13 19:57:27 2008 From: paul at city-fan.org (Paul Howarth) Date: Sun, 13 Jul 2008 20:57:27 +0100 Subject: Can an ISO be specified allow mount "setsebool -P allow_mount_iso=1" insted of "setsebool -P allow_mount_anyfile=1" SE context samba share In-Reply-To: <1215945694.5240.3.camel@frank-01> References: <1215945694.5240.3.camel@frank-01> Message-ID: <20080713205727.1f539aa9@metropolis.intra.city-fan.org> On Sun, 13 Jul 2008 11:41:34 +0100 Frank Murphy wrote: > Summary: > > SELinux prevented mount from mounting on the file or directory > "./Fedora-9-Everything-i386-DVD1.iso" (type "samba_share_t"). > > Detailed Description: > > SELinux prevented mount from mounting a filesystem on the file or > directory > "./Fedora-9-Everything-i386-DVD1.iso" of type "samba_share_t". By > default > SELinux limits the mounting of filesystems to only some files or > directories > (those with types that have the mountpoint attribute). The type > "samba_share_t" > does not have this attribute. You can either relabel the file or > directory or > set the boolean "allow_mount_anyfile" to true to allow mounting on any > file or > directory. > > Allowing Access: > > Changing the "allow_mount_anyfile" boolean to true will allow this > access: > "setsebool -P allow_mount_anyfile=1." > > The following command will allow this access: > > setsebool -P allow_mount_anyfile=1 > > Additional Information: > > Source Context system_u:system_r:mount_t > Target Context user_u:object_r:samba_share_t > Target Objects ./Fedora-9-Everything-i386-DVD1.iso > [ file ] > Source mount > Source Path /bin/mount > Port > Host server-01 > Source RPM Packages util-linux-2.13-0.47.el5 > Target RPM Packages > Policy RPM selinux-policy-2.4.6-137.1.el5 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name allow_mount_anyfile > Host Name server-01 > Platform Linux server-01 2.6.18-92.1.6.el5 #1 SMP > Wed Jun > 25 13:49:24 EDT 2008 i686 athlon > Alert Count 3 > First Seen Sun 13 Jul 2008 10:26:26 IST > Last Seen Sun 13 Jul 2008 11:07:49 IST > Local ID 268bdb54-5d8d-4c81-b7ba-0392b5cea34e > Line Numbers > > Raw Audit Messages > > host=server-01 type=AVC msg=audit(1215943669.186:14): avc: denied > { write } for pid=2898 comm="mount" > name="Fedora-9-Everything-i386-DVD1.iso" dev=md2 ino=8585227 > scontext=system_u:system_r:mount_t:s0 > tcontext=user_u:object_r:samba_share_t:s0 tclass=file > > host=server-01 type=SYSCALL msg=audit(1215943669.186:14): > arch=40000003 syscall=5 success=no exit=-13 a0=9fd5450 a1=8002 a2=0 > a3=8002 items=0 ppid=2877 pid=2898 auid=4294967295 uid=0 gid=0 euid=0 > suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 > comm="mount" exe="/bin/mount" subj=system_u:system_r:mount_t:s0 > key=(null) This is normal; you need to set the context type of the mountpoint directory to mnt_t. You may also want to set the context for the mounted ISO image too if you want to share it out using samba, http, etc. See http://www.city-fan.org/tips/SubsetRepositoriesFedora9 Paul. From frankly3d at gmail.com Mon Jul 14 08:24:37 2008 From: frankly3d at gmail.com (Frank Murphy) Date: Mon, 14 Jul 2008 09:24:37 +0100 Subject: Can an ISO be specified allow mount "setsebool -P allow_mount_iso=1" insted of "setsebool -P allow_mount_anyfile=1" SE context samba share In-Reply-To: <20080713205727.1f539aa9@metropolis.intra.city-fan.org> References: <1215945694.5240.3.camel@frank-01> <20080713205727.1f539aa9@metropolis.intra.city-fan.org> Message-ID: <1216023877.3343.5.camel@frank-01> On Sun, 2008-07-13 at 20:57 +0100, Paul Howarth wrote: > On Sun, 13 Jul 2008 11:41:34 +0100 > Frank Murphy wrote: > > This is normal; you need to set the context type of the mountpoint > directory to mnt_t. You may also want to set the context for the > mounted ISO image too if you want to share it out using samba, http, > etc. See http://www.city-fan.org/tips/SubsetRepositoriesFedora9 > > Paul. That did it thanks. the se stuff in fstab did it, along with mnt_t Clients can now see isos. Frank From dwalsh at redhat.com Mon Jul 14 12:57:14 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 14 Jul 2008 08:57:14 -0400 Subject: mod_mono_server_global In-Reply-To: <4877793B.7040502@cdkkt.com> References: <4877793B.7040502@cdkkt.com> Message-ID: <487B4D2A.4020209@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Thurman wrote: > I get this consistenly. What can I do to fix this? > ===================================== > Summary: > > SELinux is preventing the mono from using potentially mislabeled files > (mod_mono_server_global). > > Detailed Description: > > SELinux has denied mono access to potentially mislabeled file(s) > (mod_mono_server_global). This means that SELinux will not allow mono to > use > these files. It is common for users to edit files in their home > directory or tmp > directories and then move (mv) them to system directories. The problem > is that > the files end up with the wrong file context which confined applications > are not > allowed to access. > > Allowing Access: > > If you want mono to access this files, you need to relabel them using > restorecon > -v 'mod_mono_server_global'. You might want to relabel the entire directory > using restorecon -R -v ''. > > Additional Information: > > Source Context system_u:system_r:httpd_t:s0 > Target Context system_u:object_r:tmp_t:s0 > Target Objects mod_mono_server_global [ sock_file ] > Source mono > Source Path /usr/bin/mono > Port > Host bronze.cdkkt.com > Source RPM Packages mono-core-1.9.1-2.fc9 > Target RPM Packages Policy RPM > selinux-policy-3.3.1-74.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name home_tmp_bad_labels > Host Name bronze.cdkkt.com > Platform Linux bronze.cdkkt.com > 2.6.25.9-76.fc9.i686 #1 SMP > Fri Jun 27 16:14:35 EDT 2008 i686 i686 > Alert Count 4 > First Seen Thu 10 Jul 2008 10:55:05 AM PDT > Last Seen Fri 11 Jul 2008 07:37:33 AM PDT > Local ID 96f5392e-305d-47db-8dc8-93a057a25b0e > Line Numbers > Raw Audit Messages > host=bronze.cdkkt.com type=AVC msg=audit(1215787053.571:36): avc: > denied { create } for pid=8865 comm="mono" > name="mod_mono_server_global" scontext=system_u:system_r:httpd_t:s0 > tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file > > host=bronze.cdkkt.com type=SYSCALL msg=audit(1215787053.571:36): > arch=40000003 syscall=102 per=400000 success=no exit=-13 a0=2 > a1=bfc83fe0 a2=823b524 a3=4 items=0 ppid=1 pid=8865 auid=4294967295 > uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 > tty=(none) ses=4294967295 comm="mono" exe="/usr/bin/mono" > subj=system_u:system_r:httpd_t:s0 key=(null) > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list You can add policy to allow it by using audit2allow. Why does mod_mono_server_global create sock files in /tmp instead of /var/run? System applications should use /var/run instead of /tmp for creation of temporary files/sockets. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh7TSoACgkQrlYvE4MpobM9GgCbBmHdw/z9+Ic0I9FdUwq3Dx9+ sRgAn1kX8XmZFC4dG6OwkfAxP/8f/8VL =XADA -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Jul 14 13:05:27 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 14 Jul 2008 09:05:27 -0400 Subject: F9: gam_server In-Reply-To: <48777C2A.8030200@cdkkt.com> References: <48777C2A.8030200@cdkkt.com> Message-ID: <487B4F17.3050009@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Thurman wrote: > Again, more issues. Suggested fix? > ============================ > Summary: > > SELinux is preventing gam_server (gamin_t) "dac_override" to > (gamin_t). > > Detailed Description: > > SELinux denied access requested by gam_server. It is not expected that this > access is required by gam_server and this access may signal an intrusion > attempt. It is also possible that the specific version or configuration > of the > application is causing it to require additional access. > > Allowing Access: > > You can generate a local policy module to allow this access - see FAQ > (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can > disable > SELinux protection altogether. Disabling SELinux protection is not > recommended. > Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > against this package. > > Additional Information: > > Source Context system_u:system_r:gamin_t:s0 > Target Context system_u:system_r:gamin_t:s0 > Target Objects None [ capability ] > Source gam_server > Source Path /usr/libexec/gam_server > Port > Host bronze.cdkkt.com > Source RPM Packages gamin-0.1.9-5.fc9 > Target RPM Packages Policy RPM > selinux-policy-3.3.1-74.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall > Host Name bronze.cdkkt.com > Platform Linux bronze.cdkkt.com > 2.6.25.9-76.fc9.i686 #1 SMP > Fri Jun 27 16:14:35 EDT 2008 i686 i686 > Alert Count 20 > First Seen Thu 10 Jul 2008 10:35:43 AM PDT > Last Seen Thu 10 Jul 2008 11:11:40 AM PDT > Local ID 5eb1bf77-5c10-4071-9892-bac42ca11adb > Line Numbers > Raw Audit Messages > host=bronze.cdkkt.com type=AVC msg=audit(1215713500.169:272): avc: > denied { dac_override } for pid=11637 comm="gam_server" capability=1 > scontext=system_u:system_r:gamin_t:s0 > tcontext=system_u:system_r:gamin_t:s0 tclass=capability > > host=bronze.cdkkt.com type=AVC msg=audit(1215713500.169:272): avc: > denied { dac_read_search } for pid=11637 comm="gam_server" > capability=2 scontext=system_u:system_r:gamin_t:s0 > tcontext=system_u:system_r:gamin_t:s0 tclass=capability > > host=bronze.cdkkt.com type=SYSCALL msg=audit(1215713500.169:272): > arch=40000003 syscall=33 success=no exit=-13 a0=96ca580 a1=0 a2=4b9264 > a3=10 items=0 ppid=1 pid=11637 auid=4294967295 uid=0 gid=0 euid=0 suid=0 > fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 > comm="gam_server" exe="/usr/libexec/gam_server" > subj=system_u:system_r:gamin_t:s0 key=(null) > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list This is a bad domain and will be fixed in the next update. For now it is probably best to just relabel the gamin_exec_t to bin_t and stop the transition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh7TxYACgkQrlYvE4MpobMZoACgxpQqu7e/wSNBUJ6eNtmmR/yG 28cAoLpvykovrTIrThMTTGWdNMVWLAiR =ArZ/ -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Jul 14 13:07:02 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 14 Jul 2008 09:07:02 -0400 Subject: kerberos server + enforcing mode? In-Reply-To: <48766380.1050204@redhat.com> References: <20080701193704.36814ade@sparta.com> <20080709172000.69781057@sparta.com> <48766380.1050204@redhat.com> Message-ID: <487B4F76.4080204@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel J Walsh wrote: > Robert Story wrote: >> I'm still getting "modify_principal: Insufficient access to lock >> database" error messages when trying to use kadmin in enforcing mode.I >> ran 'semodule -DB' to re-enable don't audit messages, and I've attached >> what I get when trying to run a kadmin command to add a principal >> (after starting kadmind/krb5kdc... kadmin.log seems to be ok). Any >> hint, tips or policy modules greatly appreciated... > > > >> ------------------------------------------------------------------------ > >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Looks like this one is causing your problem. > > > Looks like the files were created with the wrong labels or kadmin is not > allowed to create. > > restorecon -R -v /var/kerberos > > I am fixing the policy to allow the creation of the lock files with the > correct label. We are working on this and should have a fix soon. For now you can use audit2allow to generate custom policy. - -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh7T3YACgkQrlYvE4MpobM9JACffs3fs+nam6RyGOB+j7XxqwKk l+wAn0pQjytMbwlWSm83qy/a8TrWxCLY =rpmB -----END PGP SIGNATURE----- From dant at cdkkt.com Mon Jul 14 23:58:35 2008 From: dant at cdkkt.com (Dan Thurman) Date: Mon, 14 Jul 2008 16:58:35 -0700 Subject: SELinux is preventing pidof (hotplug_t) "ptrace" to (hotplug_t) Message-ID: <487BE82B.4090806@cdkkt.com> The most recent yum update changed, and I have no clue what this is. Obtained from the system logs. I get: sealert -l 3f210834-3d3f-4247-a909-cd1219519138 ========================================== Summary: SELinux is preventing pidof (hotplug_t) "ptrace" to (hotplug_t). Detailed Description: SELinux denied access requested by pidof. It is not expected that this access is required by pidof and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:hotplug_t:s0 Target Context system_u:system_r:hotplug_t:s0 Target Objects None [ process ] Source pidof Source Path /sbin/killall5 Port Host bronze.cdkkt.com Source RPM Packages sysvinit-tools-2.86-24 Target RPM Packages Policy RPM selinux-policy-3.3.1-74.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name bronze.cdkkt.com Platform Linux bronze.cdkkt.com 2.6.25.9-76.fc9.i686 #1 SMP Fri Jun 27 16:14:35 EDT 2008 i686 i686 Alert Count 4 First Seen Mon Jul 14 08:07:44 2008 Last Seen Mon Jul 14 16:45:58 2008 Local ID 3f210834-3d3f-4247-a909-cd1219519138 Line Numbers Raw Audit Messages host=bronze.cdkkt.com type=AVC msg=audit(1216079158.438:534): avc: denied { ptrace } for pid=12710 comm="pidof" scontext=system_u:system_r:hotplug_t:s0 tcontext=system_u:system_r:hotplug_t:s0 tclass=process host=bronze.cdkkt.com type=SYSCALL msg=audit(1216079158.438:534): arch=40000003 syscall=85 success=no exit=-13 a0=bfe68728 a1=a022ba8 a2=1000 a3=bfe6862f items=0 ppid=12675 pid=12710 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="pidof" exe="/sbin/killall5" subj=system_u:system_r:hotplug_t:s0 key=(null) From dant at cdkkt.com Tue Jul 15 00:03:13 2008 From: dant at cdkkt.com (Dan Thurman) Date: Mon, 14 Jul 2008 17:03:13 -0700 Subject: SELinux is preventing pidof (hotplug_t) "ptrace" to (hotplug_t) In-Reply-To: <487BE82B.4090806@cdkkt.com> References: <487BE82B.4090806@cdkkt.com> Message-ID: <487BE941.6050609@cdkkt.com> Daniel B. Thurman wrote: > > The most recent yum update changed, and I have no > clue what this is. Obtained from the system logs. > > I get: > sealert -l 3f210834-3d3f-4247-a909-cd1219519138 > ========================================== > Summary: > > SELinux is preventing pidof (hotplug_t) "ptrace" to > (hotplug_t). > > Detailed Description: > > SELinux denied access requested by pidof. It is not expected that this > access is > required by pidof and this access may signal an intrusion attempt. It is > also > possible that the specific version or configuration of the application is > causing it to require additional access. > > Allowing Access: > > You can generate a local policy module to allow this access - see FAQ > (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can > disable > SELinux protection altogether. Disabling SELinux protection is not > recommended. > Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > against this package. > > Additional Information: > > Source Context system_u:system_r:hotplug_t:s0 > Target Context system_u:system_r:hotplug_t:s0 > Target Objects None [ process ] > Source pidof > Source Path /sbin/killall5 > Port > Host bronze.cdkkt.com > Source RPM Packages sysvinit-tools-2.86-24 > Target RPM Packages > Policy RPM selinux-policy-3.3.1-74.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall > Host Name bronze.cdkkt.com > Platform Linux bronze.cdkkt.com > 2.6.25.9-76.fc9.i686 #1 SMP > Fri Jun 27 16:14:35 EDT 2008 i686 i686 > Alert Count 4 > First Seen Mon Jul 14 08:07:44 2008 > Last Seen Mon Jul 14 16:45:58 2008 > Local ID 3f210834-3d3f-4247-a909-cd1219519138 > Line Numbers > > Raw Audit Messages > > host=bronze.cdkkt.com type=AVC msg=audit(1216079158.438:534): avc: > denied { ptrace } for pid=12710 comm="pidof" > scontext=system_u:system_r:hotplug_t:s0 > tcontext=system_u:system_r:hotplug_t:s0 tclass=process > > host=bronze.cdkkt.com type=SYSCALL msg=audit(1216079158.438:534): > arch=40000003 syscall=85 success=no exit=-13 a0=bfe68728 a1=a022ba8 > a2=1000 a3=bfe6862f items=0 ppid=12675 pid=12710 auid=4294967295 uid=0 > gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) > ses=4294967295 comm="pidof" exe="/sbin/killall5" > subj=system_u:system_r:hotplug_t:s0 key=(null) > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Please disreard this message. I think it was due to an unplugged Ethernet cable. Dan From dant at cdkkt.com Tue Jul 15 14:35:55 2008 From: dant at cdkkt.com (Dan Thurman) Date: Tue, 15 Jul 2008 07:35:55 -0700 Subject: Problems with logwatch, sagator and zope? Message-ID: <487CB5CB.6080509@cdkkt.com> My logs are reporting many errors, one which appears here: Jul 14 20:15:41 bronze setroubleshoot: SELinux is preventing 0logwatch (logwatch_t) "read" to sagator (var_log_t). For complete SELinux messages. run sealert -l 623798e3-17ec-4751-ae16-e2d92c397e72 .... And more here: Jul 14 20:20:06 bronze logrotate: ALERT exited abnormally with [1] Jul 14 20:22:02 bronze setroubleshoot: SELinux is preventing updatedb (locate_t) "getattr" to /usr/share/sagator (sagator_t). For complete SELinux messages. run sealert -l 54affa1b-dd31-4c24-b021-3e5ce8da3fe4 Jul 14 20:27:49 bronze setroubleshoot: SELinux is preventing logrotate (logrotate_t) "getattr" to /var/lib/zope/etc/logrotate.conf (var_lib_t). For complete SELinux messages. run sealert -l 0851295f-58e7-43d8-940c-614514dcfdad ================================================================= # sealert -l 623798e3-17ec-4751-ae16-e2d92c397e72 ========================================== Summary: SELinux is preventing 0logwatch (logwatch_t) "read" to sagator (var_log_t). Detailed Description: SELinux denied access requested by 0logwatch. It is not expected that this access is required by 0logwatch and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for sagator, restorecon -v 'sagator' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:logwatch_t:s0 Target Context system_u:object_r:var_log_t:s0 Target Objects sagator [ lnk_file ] Source 0logwatch Source Path /usr/bin/perl Port Host bronze.cdkkt.com Source RPM Packages perl-5.10.0-30.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-74.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name bronze.cdkkt.com Platform Linux bronze.cdkkt.com 2.6.25.9-76.fc9.i686 #1 SMP Fri Jun 27 16:14:35 EDT 2008 i686 i686 Alert Count 8 First Seen Mon Jul 14 20:15:41 2008 Last Seen Mon Jul 14 20:15:41 2008 Local ID 623798e3-17ec-4751-ae16-e2d92c397e72 Line Numbers Raw Audit Messages host=bronze.cdkkt.com type=AVC msg=audit(1216091741.414:1543): avc: denied { read } for pid=19074 comm="0logwatch" name="sagator" dev=sda6 ino=86871 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=lnk_file host=bronze.cdkkt.com type=SYSCALL msg=audit(1216091741.414:1543): arch=40000003 syscall=5 success=no exit=-13 a0=bf87c1c8 a1=98800 a2=8a67e30 a3=bf87c1c8 items=0 ppid=15038 pid=19074 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="0logwatch" exe="/usr/bin/perl" subj=system_u:system_r:logwatch_t:s0 key=(null) ================================================================= # sealert -l 0851295f-58e7-43d8-940c-614514dcfdad # ls -lZ /var/lib/zope/etc/logrotate.conf -rw-r--r-- root zope system_u:object_r:var_lib_t:s0 /var/lib/zope/etc/logrotate.conf ========================================== Summary: SELinux is preventing logrotate (logrotate_t) "getattr" to /var/lib/zope/etc/logrotate.conf (var_lib_t). Detailed Description: SELinux denied access requested by logrotate. It is not expected that this access is required by logrotate and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /var/lib/zope/etc/logrotate.conf, restorecon -v '/var/lib/zope/etc/logrotate.conf' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:logrotate_t:s0 Target Context system_u:object_r:var_lib_t:s0 Target Objects /var/lib/zope/etc/logrotate.conf [ file ] Source logrotate Source Path /usr/sbin/logrotate Port Host bronze.cdkkt.com Source RPM Packages logrotate-3.7.6-5.fc9 Target RPM Packages compat-zope-2.10.5-3.lvn9 Policy RPM selinux-policy-3.3.1-74.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name bronze.cdkkt.com Platform Linux bronze.cdkkt.com 2.6.25.9-76.fc9.i686 #1 SMP Fri Jun 27 16:14:35 EDT 2008 i686 i686 Alert Count 1 First Seen Mon Jul 14 20:27:49 2008 Last Seen Mon Jul 14 20:27:49 2008 Local ID 0851295f-58e7-43d8-940c-614514dcfdad Line Numbers Raw Audit Messages host=bronze.cdkkt.com type=AVC msg=audit(1216092469.664:1690): avc: denied { getattr } for pid=6689 comm="logrotate" path="/var/lib/zope/etc/logrotate.conf" dev=sda6 ino=2220768 scontext=system_u:system_r:logrotate_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file host=bronze.cdkkt.com type=SYSCALL msg=audit(1216092469.664:1690): arch=40000003 syscall=195 success=no exit=-13 a0=bfb60ec5 a1=bfb5fa2c a2=bcbff4 a3=bfb5fac4 items=0 ppid=6687 pid=6689 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0 key=(null) ================================================================= From dwalsh at redhat.com Wed Jul 16 13:59:37 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 16 Jul 2008 09:59:37 -0400 Subject: Problems with logwatch, sagator and zope? In-Reply-To: <487CB5CB.6080509@cdkkt.com> References: <487CB5CB.6080509@cdkkt.com> Message-ID: <487DFEC9.6040204@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Thurman wrote: > > My logs are reporting many errors, one which appears here: > Jul 14 20:15:41 bronze setroubleshoot: SELinux is preventing 0logwatch > (logwatch_t) "read" to sagator (var_log_t). For complete SELinux > messages. run sealert -l 623798e3-17ec-4751-ae16-e2d92c397e72 > > .... And more here: > Jul 14 20:20:06 bronze logrotate: ALERT exited abnormally with [1] > Jul 14 20:22:02 bronze setroubleshoot: SELinux is preventing updatedb > (locate_t) "getattr" to /usr/share/sagator (sagator_t). For complete > SELinux messages. run sealert -l 54affa1b-dd31-4c24-b021-3e5ce8da3fe4 > > Jul 14 20:27:49 bronze setroubleshoot: SELinux is preventing logrotate > (logrotate_t) "getattr" to /var/lib/zope/etc/logrotate.conf (var_lib_t). > For complete SELinux messages. run sealert -l > 0851295f-58e7-43d8-940c-614514dcfdad > > ================================================================= > # sealert -l 623798e3-17ec-4751-ae16-e2d92c397e72 > ========================================== > Summary: > > SELinux is preventing 0logwatch (logwatch_t) "read" to sagator (var_log_t). > > Detailed Description: > > SELinux denied access requested by 0logwatch. It is not expected that this > access is required by 0logwatch and this access may signal an intrusion > attempt. > It is also possible that the specific version or configuration of the > application is causing it to require additional access. > > Allowing Access: > > Sometimes labeling problems can cause SELinux denials. You could try to > restore > the default system file context for sagator, > > restorecon -v 'sagator' > > If this does not work, there is currently no automatic way to allow this > access. > Instead, you can generate a local policy module to allow this access - > see FAQ > (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can > disable > SELinux protection altogether. Disabling SELinux protection is not > recommended. > Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > against this package. > > Additional Information: > > Source Context system_u:system_r:logwatch_t:s0 > Target Context system_u:object_r:var_log_t:s0 > Target Objects sagator [ lnk_file ] > Source 0logwatch > Source Path /usr/bin/perl > Port > Host bronze.cdkkt.com > Source RPM Packages perl-5.10.0-30.fc9 > Target RPM Packages Policy RPM > selinux-policy-3.3.1-74.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall_file > Host Name bronze.cdkkt.com > Platform Linux bronze.cdkkt.com > 2.6.25.9-76.fc9.i686 #1 SMP > Fri Jun 27 16:14:35 EDT 2008 i686 i686 > Alert Count 8 > First Seen Mon Jul 14 20:15:41 2008 > Last Seen Mon Jul 14 20:15:41 2008 > Local ID 623798e3-17ec-4751-ae16-e2d92c397e72 > Line Numbers > Raw Audit Messages > host=bronze.cdkkt.com type=AVC msg=audit(1216091741.414:1543): avc: > denied { read } for pid=19074 comm="0logwatch" name="sagator" dev=sda6 > ino=86871 scontext=system_u:system_r:logwatch_t:s0 > tcontext=system_u:object_r:var_log_t:s0 tclass=lnk_file > > host=bronze.cdkkt.com type=SYSCALL msg=audit(1216091741.414:1543): > arch=40000003 syscall=5 success=no exit=-13 a0=bf87c1c8 a1=98800 > a2=8a67e30 a3=bf87c1c8 items=0 ppid=15038 pid=19074 auid=4294967295 > uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) > ses=4294967295 comm="0logwatch" exe="/usr/bin/perl" > subj=system_u:system_r:logwatch_t:s0 key=(null) > > ================================================================= > # sealert -l 0851295f-58e7-43d8-940c-614514dcfdad > # ls -lZ /var/lib/zope/etc/logrotate.conf > -rw-r--r-- root zope system_u:object_r:var_lib_t:s0 > /var/lib/zope/etc/logrotate.conf > ========================================== > Summary: > > SELinux is preventing logrotate (logrotate_t) "getattr" to > /var/lib/zope/etc/logrotate.conf (var_lib_t). > > Detailed Description: > > SELinux denied access requested by logrotate. It is not expected that this > access is required by logrotate and this access may signal an intrusion > attempt. > It is also possible that the specific version or configuration of the > application is causing it to require additional access. > > Allowing Access: > > Sometimes labeling problems can cause SELinux denials. You could try to > restore > the default system file context for /var/lib/zope/etc/logrotate.conf, > > restorecon -v '/var/lib/zope/etc/logrotate.conf' > > If this does not work, there is currently no automatic way to allow this > access. > Instead, you can generate a local policy module to allow this access - > see FAQ > (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can > disable > SELinux protection altogether. Disabling SELinux protection is not > recommended. > Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > against this package. > > Additional Information: > > Source Context system_u:system_r:logrotate_t:s0 > Target Context system_u:object_r:var_lib_t:s0 > Target Objects /var/lib/zope/etc/logrotate.conf [ file ] > Source logrotate > Source Path /usr/sbin/logrotate > Port > Host bronze.cdkkt.com > Source RPM Packages logrotate-3.7.6-5.fc9 > Target RPM Packages compat-zope-2.10.5-3.lvn9 > Policy RPM selinux-policy-3.3.1-74.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall_file > Host Name bronze.cdkkt.com > Platform Linux bronze.cdkkt.com > 2.6.25.9-76.fc9.i686 #1 SMP > Fri Jun 27 16:14:35 EDT 2008 i686 i686 > Alert Count 1 > First Seen Mon Jul 14 20:27:49 2008 > Last Seen Mon Jul 14 20:27:49 2008 > Local ID 0851295f-58e7-43d8-940c-614514dcfdad > Line Numbers > Raw Audit Messages > host=bronze.cdkkt.com type=AVC msg=audit(1216092469.664:1690): avc: > denied { getattr } for pid=6689 comm="logrotate" > path="/var/lib/zope/etc/logrotate.conf" dev=sda6 ino=2220768 > scontext=system_u:system_r:logrotate_t:s0 > tcontext=system_u:object_r:var_lib_t:s0 tclass=file > > host=bronze.cdkkt.com type=SYSCALL msg=audit(1216092469.664:1690): > arch=40000003 syscall=195 success=no exit=-13 a0=bfb60ec5 a1=bfb5fa2c > a2=bcbff4 a3=bfb5fac4 items=0 ppid=6687 pid=6689 auid=4294967295 uid=0 > gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) > ses=4294967295 comm="logrotate" exe="/usr/sbin/logrotate" > subj=system_u:system_r:logrotate_t:s0 key=(null) > ================================================================= > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Open buzilla's on Zope to put their stuff in normal locations. /var/lib/zope/etc/logrotate.conf jeesh... CC me on the bugzilla. You can add these rules using audit2allow # grep log /var/log/audit/audit.log | myzopeinweirddir.pp # semodule -i myzopeinweirddir.pp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh9/skACgkQrlYvE4MpobOZVgCgsJ/uyGIpEG4kmEPgfASUJlGr f2QAoNrr8+UyAYv6b3LORpjHEn7quJO4 =bySZ -----END PGP SIGNATURE----- From yiruli at ccsl.carleton.ca Wed Jul 16 16:29:02 2008 From: yiruli at ccsl.carleton.ca (yiruli at ccsl.carleton.ca) Date: Wed, 16 Jul 2008 12:29:02 -0400 Subject: where is targeted-policy-source package for FC9? Message-ID: <20080716122902.xjg13p91s8cckwwg@www.ccsl.carleton.ca> Where can I find targeted-policy-source package for FC9? I have tried to search it using yum and rpm, and can not find it. I downloaded reference policy from http://oss.tresys.com/projects/refpolicy/wiki/DownloadRelease, and compiled and loaded it as instructed in the website. The newly-loaded policy resulted in the failure of re-booting. thanks. From dwalsh at redhat.com Wed Jul 16 16:33:52 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 16 Jul 2008 12:33:52 -0400 Subject: where is targeted-policy-source package for FC9? In-Reply-To: <20080716122902.xjg13p91s8cckwwg@www.ccsl.carleton.ca> References: <20080716122902.xjg13p91s8cckwwg@www.ccsl.carleton.ca> Message-ID: <487E22F0.40206@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 yiruli at ccsl.carleton.ca wrote: > Where can I find targeted-policy-source package for FC9? > I have tried to search it using yum and rpm, and can not find it. > > I downloaded reference policy from > http://oss.tresys.com/projects/refpolicy/wiki/DownloadRelease, and > compiled and loaded it as instructed in the website. > The newly-loaded policy resulted in the failure of re-booting. > > thanks. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list It does not exist. We now use a srpm. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh+IvAACgkQrlYvE4MpobPj+ACbBitWpJ5PlBJPN3B8jHNpRsNG hAkAoM2lCjKf+RrGgG8ieSqy3viXDVn1 =ak9+ -----END PGP SIGNATURE----- From dant at cdkkt.com Thu Jul 17 03:02:27 2008 From: dant at cdkkt.com (Dan Thurman) Date: Wed, 16 Jul 2008 20:02:27 -0700 Subject: mod_mono_server_global In-Reply-To: <487B4D2A.4020209@redhat.com> References: <4877793B.7040502@cdkkt.com> <487B4D2A.4020209@redhat.com> Message-ID: <487EB643.6070907@cdkkt.com> Daniel J Walsh wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dan Thurman wrote: > > I get this consistenly. What can I do to fix this? > > ===================================== > > Summary: > > > > SELinux is preventing the mono from using potentially mislabeled files > > (mod_mono_server_global). > > > > Detailed Description: > > > > SELinux has denied mono access to potentially mislabeled file(s) > > (mod_mono_server_global). This means that SELinux will not allow > mono to > > use > > these files. It is common for users to edit files in their home > > directory or tmp > > directories and then move (mv) them to system directories. The problem > > is that > > the files end up with the wrong file context which confined > applications > > are not > > allowed to access. > > > > Allowing Access: > > > > If you want mono to access this files, you need to relabel them using > > restorecon > > -v 'mod_mono_server_global'. You might want to relabel the entire > directory > > using restorecon -R -v ''. > > > > Additional Information: > > > > Source Context system_u:system_r:httpd_t:s0 > > Target Context system_u:object_r:tmp_t:s0 > > Target Objects mod_mono_server_global [ sock_file ] > > Source mono > > Source Path /usr/bin/mono > > Port > > Host bronze.cdkkt.com > > Source RPM Packages mono-core-1.9.1-2.fc9 > > Target RPM Packages Policy RPM > > selinux-policy-3.3.1-74.fc9 > > Selinux Enabled True > > Policy Type targeted > > MLS Enabled True > > Enforcing Mode Enforcing > > Plugin Name home_tmp_bad_labels > > Host Name bronze.cdkkt.com > > Platform Linux bronze.cdkkt.com > > 2.6.25.9-76.fc9.i686 #1 SMP > > Fri Jun 27 16:14:35 EDT 2008 i686 i686 > > Alert Count 4 > > First Seen Thu 10 Jul 2008 10:55:05 AM PDT > > Last Seen Fri 11 Jul 2008 07:37:33 AM PDT > > Local ID 96f5392e-305d-47db-8dc8-93a057a25b0e > > Line Numbers > > Raw Audit Messages > > host=bronze.cdkkt.com type=AVC msg=audit(1215787053.571:36): avc: > > denied { create } for pid=8865 comm="mono" > > name="mod_mono_server_global" scontext=system_u:system_r:httpd_t:s0 > > tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file > > > > host=bronze.cdkkt.com type=SYSCALL msg=audit(1215787053.571:36): > > arch=40000003 syscall=102 per=400000 success=no exit=-13 a0=2 > > a1=bfc83fe0 a2=823b524 a3=4 items=0 ppid=1 pid=8865 auid=4294967295 > > uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 > > tty=(none) ses=4294967295 comm="mono" exe="/usr/bin/mono" > > subj=system_u:system_r:httpd_t:s0 key=(null) > > > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > You can add policy to allow it by using audit2allow. > > Why does mod_mono_server_global create sock files in /tmp instead of > /var/run? System applications should use /var/run instead of /tmp for > creation of temporary files/sockets. > Are you asking me? I have NO CLUE why mono is creating sockets in /tmp and I know this is improper. Do you think that I need to look into some configuration file somewhere that is mis-configured? I couldn't find it so far. From caixianchao at cn.fujitsu.com Thu Jul 17 06:12:05 2008 From: caixianchao at cn.fujitsu.com (Cai Xianchao) Date: Thu, 17 Jul 2008 14:12:05 +0800 Subject: How can i create a new role in the targeted policy Message-ID: <487EE2B5.5070700@cn.fujitsu.com> Hi all, I'm using RHEL 5.2GA and working in the targeted policy. There are only two roles in the targeted policy: system_r and object_r.I want to create a new role, how can i? Best regards From rstory at sparta.com Thu Jul 17 21:24:16 2008 From: rstory at sparta.com (Robert Story) Date: Thu, 17 Jul 2008 17:24:16 -0400 Subject: ldap server + enforcing mode? Message-ID: <20080717172416.3f1fb7d4@sparta.com> I'm trying to get ldap (from openldap-servers-2.4.8-6) running in enforcing mode on a F9 server. When I try in enforcing mode, it fails. I've attaced the AVCs from the audit log, for 'service ldap start' in enforcing and permissive mode (with don't audit disabled), along with the avcs after the first round were passed through audit2allow and loaded.. After those are added and loaded, it starts up fine with no AVCs... Should I file a bug report in bugzilla, or is this message sufficient? -- Robert Story SPARTA -------------- next part -------------- A non-text attachment was scrubbed... Name: ldap.avcs Type: application/octet-stream Size: 3549 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stuart at sjsears.com Thu Jul 17 22:02:40 2008 From: stuart at sjsears.com (Stuart Sears) Date: Thu, 17 Jul 2008 23:02:40 +0100 Subject: ldap server + enforcing mode? In-Reply-To: <20080717172416.3f1fb7d4@sparta.com> References: <20080717172416.3f1fb7d4@sparta.com> Message-ID: <487FC180.1060003@sjsears.com> Sending to the list as well. I hate reply-to: :) Robert Story wrote: > I'm trying to get ldap (from openldap-servers-2.4.8-6) running in > enforcing mode on a F9 server. When I try in enforcing mode, it fails. > I've attaced the AVCs from the audit log, for 'service ldap start' in > enforcing and permissive mode (with don't audit disabled), along with > the avcs after the first round were passed through audit2allow and > loaded.. After those are added and loaded, it starts up fine with no > AVCs... what exactly did audit2allow tell you to add? From the AVCs this looks like a mislabelled cert - /etc/openldap/cacerts/cacert.pem which is labelled as user_tmp_t what is reported by this: # restorecon -Rnv /etc/openldap/cacerts The CA certificate you have there wasn't moved from /tmp by any chance? Stuart -- Stuart Sears RHCA etc. "It's today!" said Piglet. "My favourite day," said Pooh. From eparis at redhat.com Fri Jul 18 03:30:40 2008 From: eparis at redhat.com (Eric Paris) Date: Thu, 17 Jul 2008 23:30:40 -0400 Subject: ldap server + enforcing mode? In-Reply-To: <20080717172416.3f1fb7d4@sparta.com> References: <20080717172416.3f1fb7d4@sparta.com> Message-ID: <1216351840.2898.5.camel@localhost.localdomain> On Thu, 2008-07-17 at 17:24 -0400, Robert Story wrote: > I'm trying to get ldap (from openldap-servers-2.4.8-6) running in > enforcing mode on a F9 server. When I try in enforcing mode, it fails. > I've attaced the AVCs from the audit log, for 'service ldap start' in > enforcing and permissive mode (with don't audit disabled), along with > the avcs after the first round were passed through audit2allow and > loaded.. After those are added and loaded, it starts up fine with no > AVCs... > > Should I file a bug report in bugzilla, or is this message sufficient? Just to make sure it can't possibly get lost I usually file a BZ. But: Most of these are 'bogus' The majority of them are some form of slapd is trying to read files in /selinux and /etc/selinux. I don't know why slapd would be trolling around in either of those directories but I can't imagine it would cause an actual problem in the operation of slapd. The real issue are these: type=AVC msg=audit(1216329419.086:433): avc: denied { getattr } for pid=2886 comm="slapd" path="/etc/openldap/cacerts/cacert.pem" dev=dm-4 ino=204805 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file type=AVC msg=audit(1216329419.220:434): avc: denied { getattr } for pid=2886 comm="slapd" path="/etc/openldap/cacerts/cacert.pem" dev=dm-4 ino=204805 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file type=AVC msg=audit(1216329419.223:435): avc: denied { getattr } for pid=2886 comm="slapd" path="/etc/openldap/slapd.pem" dev=dm-4 ino=204830 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file These indicate to me that cacert.pem and slapd.pem were both created in /tmp/and moved to /etc/openldap. This is a labeling issue. slapd doesn't normally need access to files created in /tmp and since those files have been moved you need to reset their attributes approprietely to their new location. restorecon -R -v /etc/openldap After doing that can you send up the denials you get (with dontaudits) and if it gives you any more trouble? Also can you help us understand how these two .pem files were created and how the got into /etc/openldap so we can try to fix this for others? -Eric From mmcallis at redhat.com Fri Jul 18 06:43:21 2008 From: mmcallis at redhat.com (Murray McAllister) Date: Fri, 18 Jul 2008 16:43:21 +1000 Subject: SELinux User Guide Message-ID: <48803B89.6030605@redhat.com> Hi, Apologies if this doubles up for anyone. My name is Murray McAllister and I am working as a content author for Red Hat. I have recently started a new project -- an SELinux User Guide -- with Daniel Walsh, Michael Smith, and a few other people from Red Hat. There are a few SELinux books, but these are very technical. We want to create a guide that people with no previous SELinux experience can use, to allow them to do what they want without turning SELinux off. I have started a rough information plan that includes the current schedule, information sources, and some ideas for the content that may be included. The information plan is located at . The main project page is located at . Among other things, we are going to try to cover the following topics from the current SELinux project documentation todo list (http://selinuxproject.org/page/Documentation_TODO): * "Explain how to interpret an AVC message and how to get additional information via SYSCALL audit, including how to add a simple syscall audit filter to enable collection of PATH information". * Document Confined Users". * "Update FC5 FAQ". * "Document the use of the mount command for overriding file context". * "Describe Audit2allow and how it can just Fix the machine". * "Update and organize the Fedora SELinux FAQ". If anyone has any ideas about what they would like to see in the guide, or any corrections to the current topics we would like to include, please let us know. As well, user feedback and comments can be left at . A Fedora account (https://admin.fedoraproject.org/accounts/) is required to use the Wiki - if you do not have one, please do not hesitate to mail me directly, or respond to this thread. Thanks for your time, Murray. From dwalsh at redhat.com Fri Jul 18 13:06:32 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 18 Jul 2008 09:06:32 -0400 Subject: ldap server + enforcing mode? In-Reply-To: <1216351840.2898.5.camel@localhost.localdomain> References: <20080717172416.3f1fb7d4@sparta.com> <1216351840.2898.5.camel@localhost.localdomain> Message-ID: <48809558.8060601@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Paris wrote: > On Thu, 2008-07-17 at 17:24 -0400, Robert Story wrote: >> I'm trying to get ldap (from openldap-servers-2.4.8-6) running in >> enforcing mode on a F9 server. When I try in enforcing mode, it fails. >> I've attaced the AVCs from the audit log, for 'service ldap start' in >> enforcing and permissive mode (with don't audit disabled), along with >> the avcs after the first round were passed through audit2allow and >> loaded.. After those are added and loaded, it starts up fine with no >> AVCs... >> >> Should I file a bug report in bugzilla, or is this message sufficient? > > Just to make sure it can't possibly get lost I usually file a BZ. But: > > Most of these are 'bogus' The majority of them are some form of slapd > is trying to read files in /selinux and /etc/selinux. I don't know why > slapd would be trolling around in either of those directories but I > can't imagine it would cause an actual problem in the operation of > slapd. > > The real issue are these: > type=AVC msg=audit(1216329419.086:433): avc: denied { getattr } for pid=2886 comm="slapd" path="/etc/openldap/cacerts/cacert.pem" dev=dm-4 ino=204805 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file > type=AVC msg=audit(1216329419.220:434): avc: denied { getattr } for pid=2886 comm="slapd" path="/etc/openldap/cacerts/cacert.pem" dev=dm-4 ino=204805 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file > type=AVC msg=audit(1216329419.223:435): avc: denied { getattr } for pid=2886 comm="slapd" path="/etc/openldap/slapd.pem" dev=dm-4 ino=204830 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file > > These indicate to me that cacert.pem and slapd.pem were both created > in /tmp/and moved to /etc/openldap. This is a labeling issue. slapd > doesn't normally need access to files created in /tmp and since those > files have been moved you need to reset their attributes approprietely > to their new location. > > restorecon -R -v /etc/openldap > > After doing that can you send up the denials you get (with dontaudits) > and if it gives you any more trouble? > > Also can you help us understand how these two .pem files were created > and how the got into /etc/openldap so we can try to fix this for others? > > -Eric > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list setroubleshoot says: Summary: SELinux is preventing the slapd from using potentially mislabeled files (/etc/openldap/slapd.pem). Detailed Description: [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] SELinux has denied slapd access to potentially mislabeled file(s) (/etc/openldap/slapd.pem). This means that SELinux will not allow slapd to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing Access: If you want slapd to access this files, you need to relabel them using restorecon -v '/etc/openldap/slapd.pem'. You might want to relabel the entire directory using restorecon -R -v '/etc/openldap'. Additional Information: Source Context unconfined_u:system_r:slapd_t:s0 Target Context unconfined_u:object_r:user_tmp_t:s0 Target Objects /etc/openldap/slapd.pem [ file ] Source slapd Source Path Port Host Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.5.0-2.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name home_tmp_bad_labels Host Name redsox.boston.devel.redhat.com Platform Linux redsox.boston.devel.redhat.com 2.6.26-0.124.rc9.git5.fc10.x86_64 #1 SMP Wed Jul 9 17:11:05 EDT 2008 x86_64 x86_64 Alert Count 1 First Seen Thu Jul 17 17:16:59 2008 Last Seen Thu Jul 17 17:16:59 2008 Local ID d667d771-5046-4373-a911-7fccd8ae0e81 Line Numbers 1 Raw Audit Messages type=AVC msg=audit(1216329419.223:435): avc: denied { getattr } for pid=2886 comm="slapd" path="/etc/openldap/slapd.pem" dev=dm-4 ino=204830 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiAlVgACgkQrlYvE4MpobNITgCgyBjCCqO1fdsVQQtHisIT1mKr x90AnRgVLFJIs6kqzp62H550wtoU6f1i =FhG3 -----END PGP SIGNATURE----- From dwalsh at redhat.com Fri Jul 18 14:04:54 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 18 Jul 2008 10:04:54 -0400 Subject: mod_mono_server_global In-Reply-To: <487EB643.6070907@cdkkt.com> References: <4877793B.7040502@cdkkt.com> <487B4D2A.4020209@redhat.com> <487EB643.6070907@cdkkt.com> Message-ID: <4880A306.30007@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Thurman wrote: > Daniel J Walsh wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Dan Thurman wrote: >> > I get this consistenly. What can I do to fix this? >> > ===================================== >> > Summary: >> > >> > SELinux is preventing the mono from using potentially mislabeled files >> > (mod_mono_server_global). >> > >> > Detailed Description: >> > >> > SELinux has denied mono access to potentially mislabeled file(s) >> > (mod_mono_server_global). This means that SELinux will not allow >> mono to >> > use >> > these files. It is common for users to edit files in their home >> > directory or tmp >> > directories and then move (mv) them to system directories. The problem >> > is that >> > the files end up with the wrong file context which confined >> applications >> > are not >> > allowed to access. >> > >> > Allowing Access: >> > >> > If you want mono to access this files, you need to relabel them using >> > restorecon >> > -v 'mod_mono_server_global'. You might want to relabel the entire >> directory >> > using restorecon -R -v ''. >> > >> > Additional Information: >> > >> > Source Context system_u:system_r:httpd_t:s0 >> > Target Context system_u:object_r:tmp_t:s0 >> > Target Objects mod_mono_server_global [ sock_file ] >> > Source mono >> > Source Path /usr/bin/mono >> > Port >> > Host bronze.cdkkt.com >> > Source RPM Packages mono-core-1.9.1-2.fc9 >> > Target RPM Packages Policy RPM > >> selinux-policy-3.3.1-74.fc9 >> > Selinux Enabled True >> > Policy Type targeted >> > MLS Enabled True >> > Enforcing Mode Enforcing >> > Plugin Name home_tmp_bad_labels >> > Host Name bronze.cdkkt.com >> > Platform Linux bronze.cdkkt.com >> > 2.6.25.9-76.fc9.i686 #1 SMP >> > Fri Jun 27 16:14:35 EDT 2008 i686 i686 >> > Alert Count 4 >> > First Seen Thu 10 Jul 2008 10:55:05 AM PDT >> > Last Seen Fri 11 Jul 2008 07:37:33 AM PDT >> > Local ID 96f5392e-305d-47db-8dc8-93a057a25b0e >> > Line Numbers > Raw Audit Messages > >> host=bronze.cdkkt.com type=AVC msg=audit(1215787053.571:36): avc: >> > denied { create } for pid=8865 comm="mono" >> > name="mod_mono_server_global" scontext=system_u:system_r:httpd_t:s0 >> > tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file >> > >> > host=bronze.cdkkt.com type=SYSCALL msg=audit(1215787053.571:36): >> > arch=40000003 syscall=102 per=400000 success=no exit=-13 a0=2 >> > a1=bfc83fe0 a2=823b524 a3=4 items=0 ppid=1 pid=8865 auid=4294967295 >> > uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 >> > tty=(none) ses=4294967295 comm="mono" exe="/usr/bin/mono" >> > subj=system_u:system_r:httpd_t:s0 key=(null) >> > >> > >> > -- >> > fedora-selinux-list mailing list >> > fedora-selinux-list at redhat.com >> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> You can add policy to allow it by using audit2allow. >> >> Why does mod_mono_server_global create sock files in /tmp instead of >> /var/run? System applications should use /var/run instead of /tmp for >> creation of temporary files/sockets. >> > Are you asking me? I have NO CLUE why mono is > creating sockets in /tmp and I know this is improper. > Do you think that I need to look into some configuration > file somewhere that is mis-configured? I couldn't find > it so far. > No, I will open a bugzilla with the mod mono people. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiAowYACgkQrlYvE4MpobPmqgCfQuIbcyNUg5KR+Ly1VOdeR2JL UdkAn00L7F4SQkL5HBIQRfxBRY8R0bLe =YTew -----END PGP SIGNATURE----- From colin.murray at dit.ie Fri Jul 18 14:49:48 2008 From: colin.murray at dit.ie (Colly Murray) Date: Fri, 18 Jul 2008 15:49:48 +0100 Subject: Selinux & Apache Message-ID: <007101c8e8e5$86a7fc50$6402fc93@IMGXPDX2000CM> Hi there, I'm having some problems with apache and selinux. Yesterday in /var/log/httpd/error_log I had: [Thu Jul 17 16:34:26 2008] [notice] SELinux policy enabled; httpd running as context user_u:system_r:httpd_t [Thu Jul 17 16:34:26 2008] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Thu Jul 17 16:34:26 2008] [notice] Digest: generating secret for digest authentication ... [Thu Jul 17 16:34:26 2008] [notice] Digest: done [Thu Jul 17 16:34:26 2008] [warn] pid file /var/www/ditsite/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? [Thu Jul 17 16:34:26 2008] [notice] Apache configured -- resuming normal operations It happened a couple of times on a production site, so I decided to try disabling protection for httpd Daemon: # setsebool -P httpd_disable_trans 1 # service httpd restart Message in /var/log/messages Jul 18 13:37:46 localhost dbus: avc: received policyload notice (seqno=3) Jul 18 13:37:47 localhost setsebool: The httpd_disable_trans policy boolean was changed to 1 by root Jul 18 13:37:48 localhost setroubleshoot: SELinux is preventing setsebool (semanage_t) "sys_admin" to (semanage_t). For complete SELinux messages. run sealert -l dbc64b3f-71be-48c7-aa07-03264440576c Sealert says the following: Summary: SELinux is preventing httpd (httpd_t) "sys_admin" to (httpd_t). Detailed Description: [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] SELinux denied access requested by httpd. It is not expected that this access is required by httpd and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context root:system_r:httpd_t Target Context root:system_r:httpd_t Target Objects None [ capability ] Source httpd Source Path /usr/sbin/httpd Port Host OSTRAIS Source RPM Packages httpd-2.2.3-11.el5_1.3 Target RPM Packages Policy RPM selinux-policy-2.4.6-137.1.el5_2 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name catchall Host Name OSTRAIS Platform Linux OSTRAIS 2.6.18-92.1.1.el5 #1 SMP Thu May 22 09:01:47 EDT 2008 x86_64 x86_64 Alert Count 10 First Seen Thu Jul 17 17:20:02 2008 Last Seen Fri Jul 18 13:33:30 2008 Local ID b22d5d55-1982-4c69-820e-7df4dbd33842 Line Numbers Raw Audit Messages host=OSTRAIS type=AVC msg=audit(1216384410.773:2490): avc: denied { sys_admin } for pid=24960 comm="httpd" capability=21 scontext=root:system_r:httpd_t:s0 tcontext=root:system_r:httpd_t:s0 tclass=capability 1.) Why is selinux preventing me from changing this value? 2.) Am I taking the correct approach? httpd-2.2.3-11.el5_1.3/ Linux 2.6.18-92.1.1.el5 x86_64 GNU/Linux Red Hat Enterprise Linux Server release 5.2 (Tikanga) Thanks Colly This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Fri Jul 18 15:01:54 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 18 Jul 2008 11:01:54 -0400 Subject: Selinux & Apache In-Reply-To: <007101c8e8e5$86a7fc50$6402fc93@IMGXPDX2000CM> References: <007101c8e8e5$86a7fc50$6402fc93@IMGXPDX2000CM> Message-ID: <4880B062.60207@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Colly Murray wrote: > Hi there, > > > > I'm having some problems with apache and selinux. > > > > Yesterday in /var/log/httpd/error_log I had: > > > > [Thu Jul 17 16:34:26 2008] [notice] SELinux policy enabled; httpd running as > context user_u:system_r:httpd_t > > [Thu Jul 17 16:34:26 2008] [notice] suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > > [Thu Jul 17 16:34:26 2008] [notice] Digest: generating secret for digest > authentication ... > > [Thu Jul 17 16:34:26 2008] [notice] Digest: done > > [Thu Jul 17 16:34:26 2008] [warn] pid file /var/www/ditsite/logs/httpd.pid > overwritten -- Unclean shutdown of previous Apache run? > > [Thu Jul 17 16:34:26 2008] [notice] Apache configured -- resuming normal > operations > > > I don't see any errors here? > > > It happened a couple of times on a production site, so I decided to try > disabling protection for httpd Daemon: > > SELinux was not preventing you from doing anything. I believe. You restarted the service using service apache restart. Which would change apache from running as system_u:system_r:httpd_t to user_u:system_r:httpd_t (user_u is the user who restarted apache) apache must be watching this and reporting this as a warning. But it would not prevent apache from doing any thing. > > # setsebool -P httpd_disable_trans 1 > > # service httpd restart > > > > Message in /var/log/messages > > > > Jul 18 13:37:46 localhost dbus: avc: received policyload notice (seqno=3) > > Jul 18 13:37:47 localhost setsebool: The httpd_disable_trans policy boolean > was changed to 1 by root > > Jul 18 13:37:48 localhost setroubleshoot: SELinux is preventing setsebool > (semanage_t) "sys_admin" to (semanage_t). For complete SELinux > messages. run sealert -l dbc64b3f-71be-48c7-aa07-03264440576c > > > > Sealert says the following: > > > > Summary: > > > > SELinux is preventing httpd (httpd_t) "sys_admin" to (httpd_t). > > > > Detailed Description: > > > > [SELinux is in permissive mode, the operation would have been denied but was > > permitted due to permissive mode.] > > > > SELinux denied access requested by httpd. It is not expected that this > access is > > required by httpd and this access may signal an intrusion attempt. It is > also > > possible that the specific version or configuration of the application is > > causing it to require additional access. > > > > Allowing Access: > > > > You can generate a local policy module to allow this access - see FAQ > > (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can > disable > > SELinux protection altogether. Disabling SELinux protection is not > recommended. > > Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > > against this package. > > > > Additional Information: > > > > Source Context root:system_r:httpd_t > > Target Context root:system_r:httpd_t > > Target Objects None [ capability ] > > Source httpd > > Source Path /usr/sbin/httpd > > Port > > Host OSTRAIS > > Source RPM Packages httpd-2.2.3-11.el5_1.3 > > Target RPM Packages > > Policy RPM selinux-policy-2.4.6-137.1.el5_2 > > Selinux Enabled True > > Policy Type targeted > > MLS Enabled True > > Enforcing Mode Permissive > > Plugin Name catchall > > Host Name OSTRAIS > > Platform Linux OSTRAIS 2.6.18-92.1.1.el5 #1 SMP Thu May > 22 > > 09:01:47 EDT 2008 x86_64 x86_64 > > Alert Count 10 > > First Seen Thu Jul 17 17:20:02 2008 > > Last Seen Fri Jul 18 13:33:30 2008 > > Local ID b22d5d55-1982-4c69-820e-7df4dbd33842 > > Line Numbers > > > > Raw Audit Messages > > > > host=OSTRAIS type=AVC msg=audit(1216384410.773:2490): avc: denied { > sys_admin } for pid=24960 comm="httpd" capability=21 > scontext=root:system_r:httpd_t:s0 tcontext=root:system_r:httpd_t:s0 > tclass=capability > > > > > > > > > > > > > > > > > > 1.) Why is selinux preventing me from changing this value? > SELinux did not prevent you from changing the value. It seems apache is still running httpd_t though. Not sure why. > 2.) Am I taking the correct approach? No. Why did you disable SELinux protection on apache when it was not failing? If it is failing, what is it trying to do? > > > > > > > > > > > > > > httpd-2.2.3-11.el5_1.3/ > > Linux 2.6.18-92.1.1.el5 x86_64 GNU/Linux > > Red Hat Enterprise Linux Server release 5.2 (Tikanga) > > > > Thanks > > > > Colly > > > This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiAsGIACgkQrlYvE4MpobPC6gCfTHASpamsztuXz6+HfiZaSlEF KqAAoKFwKK/B6pvhVkeFeT40mqz/Mzjc =Sgqg -----END PGP SIGNATURE----- From rstory at sparta.com Fri Jul 18 16:09:40 2008 From: rstory at sparta.com (Robert Story) Date: Fri, 18 Jul 2008 12:09:40 -0400 Subject: ldap server + enforcing mode? In-Reply-To: <1216351840.2898.5.camel@localhost.localdomain> References: <20080717172416.3f1fb7d4@sparta.com> <1216351840.2898.5.camel@localhost.localdomain> Message-ID: <20080718120940.05e7942e@sparta.com> On Thu, 17 Jul 2008 23:30:40 -0400 Eric wrote: EP> These indicate to me that cacert.pem and slapd.pem were both created EP> in /tmp/and moved to /etc/openldap. [...] EP> EP> restorecon -R -v /etc/openldap EP> EP> After doing that can you send up the denials you get (with dontaudits) EP> and if it gives you any more trouble? No more trouble after that... Sorry for the noise.. EP> Also can you help us understand how these two .pem files were created EP> and how the got into /etc/openldap so we can try to fix this for others? It was just a manual process... generated the certificates on a another machine and scp'd them to /tmp/ because it's short and easier than trying to remember the real path from the HOWTO on another machine... -- Robert Story SPARTA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwalsh at redhat.com Fri Jul 18 17:22:47 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 18 Jul 2008 13:22:47 -0400 Subject: ldap server + enforcing mode? In-Reply-To: <20080718120940.05e7942e@sparta.com> References: <20080717172416.3f1fb7d4@sparta.com> <1216351840.2898.5.camel@localhost.localdomain> <20080718120940.05e7942e@sparta.com> Message-ID: <4880D167.5020509@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Story wrote: > On Thu, 17 Jul 2008 23:30:40 -0400 Eric wrote: > EP> These indicate to me that cacert.pem and slapd.pem were both created > EP> in /tmp/and moved to /etc/openldap. [...] > EP> > EP> restorecon -R -v /etc/openldap > EP> > EP> After doing that can you send up the denials you get (with dontaudits) > EP> and if it gives you any more trouble? > > No more trouble after that... Sorry for the noise.. > > EP> Also can you help us understand how these two .pem files were created > EP> and how the got into /etc/openldap so we can try to fix this for others? > > It was just a manual process... generated the certificates on a another > machine and scp'd them to /tmp/ because it's short and easier than > trying to remember the real path from the HOWTO on another machine... > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list I guess this is the number one thing we need to teach unix administrators. With SELinux when you get a permission denied message there are 3 things to check. Ownership, Permissions which all admins have ingrained into them, and SELinux Label. chown OWNER PATH chmod PERM PATH restorecon PATH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiA0WcACgkQrlYvE4MpobOdRwCePpu7qYVywjz2LRMgK1ln+6jc mKoAoJA08lWO5iojf6fSbtguuOX9oiLM =rUwL -----END PGP SIGNATURE----- From tony.molloy at ul.ie Fri Jul 18 17:36:14 2008 From: tony.molloy at ul.ie (Tony Molloy) Date: Fri, 18 Jul 2008 18:36:14 +0100 Subject: Running a script from Samba Message-ID: <200807181836.14111.tony.molloy@ul.ie> This is on Centos not Fedora but that shouldn't matter. If I want Samba to run a script ( logon logout scripts ) what context should I set the scripts to. Thanks,, Tony From dwalsh at redhat.com Fri Jul 18 17:51:46 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 18 Jul 2008 13:51:46 -0400 Subject: Running a script from Samba In-Reply-To: <200807181836.14111.tony.molloy@ul.ie> References: <200807181836.14111.tony.molloy@ul.ie> Message-ID: <4880D832.3070406@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony Molloy wrote: > This is on Centos not Fedora but that shouldn't matter. > > If I want Samba to run a script ( logon logout scripts ) what context should I > set the scripts to. > > Thanks,, > > Tony > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list /var/lib/samba/scripts(/.*)? system_u:object_r:samba_unconfined_script_exec_t:s0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiA2DIACgkQrlYvE4MpobP4RgCgn/bb+/7Sib1X9I4j6/yiNaZt eSMAn0rvmr9llM0CdeOIISjN+FfE/Nq0 =oCfz -----END PGP SIGNATURE----- From mmcallis at redhat.com Sat Jul 19 10:06:58 2008 From: mmcallis at redhat.com (Murray McAllister) Date: Sat, 19 Jul 2008 20:06:58 +1000 Subject: SELinux User Guide In-Reply-To: <48803B89.6030605@redhat.com> References: <48803B89.6030605@redhat.com> Message-ID: <4881BCC2.9020006@redhat.com> Murray McAllister wrote: > Hi, > > Apologies if this doubles up for anyone. > > My name is Murray McAllister and I am working as a content author for > Red Hat. I have recently started a new project -- an SELinux User Guide > -- with Daniel Walsh, Michael Smith, and a few other people from Red Hat. > > There are a few SELinux books, but these are very technical. We want to > create a guide that people with no previous SELinux experience can use, > to allow them to do what they want without turning SELinux off. > > I have started a rough information plan that includes the current > schedule, information sources, and some ideas for the content that may > be included. The information plan is located at > . > The main project page is located at > . If anyone is interested in the progress of this, I am going to send weekly reports to . How to join and archives for this list can be found at . Thanks, Murray. From yiruli at ccsl.carleton.ca Sat Jul 19 19:26:55 2008 From: yiruli at ccsl.carleton.ca (yiruli at ccsl.carleton.ca) Date: Sat, 19 Jul 2008 15:26:55 -0400 Subject: writing a policy. Confused about domain transition. Message-ID: <20080719152655.9bedk1i44kws8koo@www.ccsl.carleton.ca> Hi, I am practising to write a policy for a music player called soundjuicer. Policy Tool I used: selinux-polgengui The beginning part of soundjuicer1.te is as follows: ---------------------------------------------------- type soundjuicer1_t; type soundjuicer1_exec_t; application_domain(soundjuicer1_t, soundjuicer1_exec_t) role user_r types soundjuicer1_t; ..... ------------------------------------------------------- The context of login id is (id -Z): user_u:user_r:user_t I loaded the module. And then I run the music player both from terminal and GUI. I checked the context of the soundjuicer process. The context of the process is : user_u:user_r:user_t Question: With the context for the process, user_u:user_r:user_t, can I say that the security policy for the program is not being enforced, because of the failure of domain transition? Should the context of the process be: user_u:user_r:soundjuicer1_t? thanks Yiru Li From adam.huffman at gmail.com Mon Jul 21 11:42:42 2008 From: adam.huffman at gmail.com (Adam Huffman) Date: Mon, 21 Jul 2008 12:42:42 +0100 Subject: F9: gam_server In-Reply-To: <487B4F17.3050009@redhat.com> References: <48777C2A.8030200@cdkkt.com> <487B4F17.3050009@redhat.com> Message-ID: <48847632.2050604@gmail.com> Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dan Thurman wrote: > >> Again, more issues. Suggested fix? >> ============================ >> Summary: >> >> SELinux is preventing gam_server (gamin_t) "dac_override" to >> (gamin_t). >> >> Detailed Description: >> >> SELinux denied access requested by gam_server. It is not expected that this >> access is required by gam_server and this access may signal an intrusion >> attempt. It is also possible that the specific version or configuration >> of the >> application is causing it to require additional access. >> >> Allowing Access: >> >> You can generate a local policy module to allow this access - see FAQ >> (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can >> disable >> SELinux protection altogether. Disabling SELinux protection is not >> recommended. >> Please file a bug report >> (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) >> against this package. >> >> Additional Information: >> >> Source Context system_u:system_r:gamin_t:s0 >> Target Context system_u:system_r:gamin_t:s0 >> Target Objects None [ capability ] >> Source gam_server >> Source Path /usr/libexec/gam_server >> Port >> Host bronze.cdkkt.com >> Source RPM Packages gamin-0.1.9-5.fc9 >> Target RPM Packages Policy RPM >> selinux-policy-3.3.1-74.fc9 >> Selinux Enabled True >> Policy Type targeted >> MLS Enabled True >> Enforcing Mode Enforcing >> Plugin Name catchall >> Host Name bronze.cdkkt.com >> Platform Linux bronze.cdkkt.com >> 2.6.25.9-76.fc9.i686 #1 SMP >> Fri Jun 27 16:14:35 EDT 2008 i686 i686 >> Alert Count 20 >> First Seen Thu 10 Jul 2008 10:35:43 AM PDT >> Last Seen Thu 10 Jul 2008 11:11:40 AM PDT >> Local ID 5eb1bf77-5c10-4071-9892-bac42ca11adb >> Line Numbers >> Raw Audit Messages >> host=bronze.cdkkt.com type=AVC msg=audit(1215713500.169:272): avc: >> denied { dac_override } for pid=11637 comm="gam_server" capability=1 >> scontext=system_u:system_r:gamin_t:s0 >> tcontext=system_u:system_r:gamin_t:s0 tclass=capability >> >> host=bronze.cdkkt.com type=AVC msg=audit(1215713500.169:272): avc: >> denied { dac_read_search } for pid=11637 comm="gam_server" >> capability=2 scontext=system_u:system_r:gamin_t:s0 >> tcontext=system_u:system_r:gamin_t:s0 tclass=capability >> >> host=bronze.cdkkt.com type=SYSCALL msg=audit(1215713500.169:272): >> arch=40000003 syscall=33 success=no exit=-13 a0=96ca580 a1=0 a2=4b9264 >> a3=10 items=0 ppid=1 pid=11637 auid=4294967295 uid=0 gid=0 euid=0 suid=0 >> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 >> comm="gam_server" exe="/usr/libexec/gam_server" >> subj=system_u:system_r:gamin_t:s0 key=(null) >> >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > This is a bad domain and will be fixed in the next update. For now it > is probably best to just relabel the gamin_exec_t to bin_t and stop the > transition. > > After updating today I'm seeing thousands of these, to the extent that I had to stop the setroubleshoot service: Source RPM Packages gamin-0.1.9-5.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-78.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file 2.6.25.10-86.fc9.x86_64 #1 SMP Mon Jul 7 20:23:46 EDT 2008 x86_64 x86_64 Alert Count 2565 First Seen Mon 21 Jul 2008 12:32:35 BST Last Seen Mon 21 Jul 2008 12:38:10 BST Local ID 6ec7acfe-2373-4bb0-b598-ed8c37265ac9 Line Numbers Raw Audit Messages type=AVC msg=audit(1216640290.738:969906): avc: denied { read } for pid=3319 comm="gam_server" path="inotify" dev=inotifyfs ino=1 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:inotifyfs_t:s0 tclass=dir type=SYSCALL msg=audit(1216640290.738:969906): arch=c000003e syscall=0 success=no exit=-13 a0=3 a1=23d9210 a2=400 a3=0 items=0 ppid=1 pid=3319 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="gam_server" exe="/usr/libexec/gam_server" subj=system_u:object_r:unlabeled_t:s0 key=(null) From zephod at cfl.rr.com Mon Jul 21 14:50:41 2008 From: zephod at cfl.rr.com (Steve Blackwell) Date: Mon, 21 Jul 2008 10:50:41 -0400 Subject: Can't export samba share Message-ID: <20080721105041.1fd67e05@steve.blackwell> I have a dual boot F8/XP machine and I want to export, via samba, the NTFS partition so that I can use it to back up my wife's Vista machine. It seems that selinux is preventing this from happening. Here is the summary message from setroubleshoot: SELinux is preventing the samba daemon from serving r/o local files to remote clients. and the Allowing Access section says: If you want to export file systems using samba you need to turn on the samba_export_all_ro boolean: "setsebool -P samba_export_all_ro=1". The following command will allow this access:setsebool -P samba_export_all_ro=1 There seems to be 2 problems here; 1) The filesystem that I'm trying to export is read-write not read-only and 2) I have already set samba_export_all_ro=1. In fact I also set samba_export_all_rw=1 and I even set samba_run_unconfined=1 and I still get the same messages. Here is the filesystem I'm trying to export: # cat /etc/fstab | grep ntfs /dev/sdb1 /mnt/c_drive ntfs-3g rw,defaults,umask=0000 0 0 # ls -lZ /mnt drwxrwxrwx root root system_u:object_r:fusefs_t:s0 c_drive Here is the /etc/samba/smb.conf stanza: [Kellie] comment = Winblows backup path = /mnt/c_drive writable = yes browseable = yes valid users = Kellie User Kellie can see the Kellie share from her Vista computer but whenever she tries to use it, I get an AVC. # rpm -qa | grep selinux libselinux-python-2.0.43-1.fc8 selinux-policy-devel-3.0.8-109.fc8 libselinux-devel-2.0.43-1.fc8 selinux-policy-3.0.8-109.fc8 libselinux-2.0.43-1.fc8 selinux-policy-targeted-3.0.8-109.fc8 # uname -sr Linux 2.6.25.10-47.fc8 I suppose I could go back to permissive mode but I'd like to get this to work. Any suggestion? Thanks, Steve From warner at rubix.com Mon Jul 21 15:12:13 2008 From: warner at rubix.com (Andrew Warner) Date: Mon, 21 Jul 2008 17:12:13 +0200 Subject: question on persistent security context storage Message-ID: <4884A74D.2020703@rubix.com> Hello, I am currently developing an "SELinux aware" DBMS (primarily TE and MLS) that is characterized by: 1. The need to store a security context (in some recoverable form) in our persistent database (storage size of the context is an important factor) 2. The need to frequently perform a high number of security access checks in a performance sensitive way My question relates to the first characteristic from above. I am having trouble deciding on the best way to store the security context in the database. From my research I see (I think!) three different representations for a security context: 1) string; 2) raw; 3) SID. The string representation, generally, seems clear as this is what is shown in all documentation as the context representation that exists in user space. My only question regarding the string representation is: is there is any hard limit to the length of the security context string? Do I need to allow for no theoretical size limit on a context string if I choose to store it? I am inferring the the raw representation exists from seeing *_raw functions (e.g., security_compute_create_raw) referenced in selinux header files. Other than seeing these functions declared I am having trouble finding out much about a raw representation. Is there any advantage to storing/manipulating a context in its raw representation? That is, are they more suited for a fast security access check, are they smaller in size, or do they have a fixed or maximum length? The SID I have also seen mentioned in various documentations but can determine little about them. My guess is that they are an integer value that is used for fast internal access, particularly for the AVC. Are SIDs indeed integer values? Are they persistent or are they meaningful only for a particular OS session? I have also considered maintaining my own internal, persistent mapping between string based contexts and an integer representation, the mapping being stored/indexed inside the DBMS. This gives me a small storage overhead with a fixed size. Any answers, pointers to documentation, or other help would be greatly appreciated! Andy Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Mon Jul 21 15:13:37 2008 From: jdennis at redhat.com (John Dennis) Date: Mon, 21 Jul 2008 11:13:37 -0400 Subject: SELinux User Guide In-Reply-To: <48803B89.6030605@redhat.com> References: <48803B89.6030605@redhat.com> Message-ID: <4884A7A1.4020301@redhat.com> Murray McAllister wrote: > If anyone has any ideas about what they would like to see in the guide Yes, you should include a section on setroubleshoot. -- John Dennis From maximilianbianco at gmail.com Mon Jul 21 15:40:06 2008 From: maximilianbianco at gmail.com (max) Date: Mon, 21 Jul 2008 11:40:06 -0400 Subject: [Fwd: Re: Can't export samba share] Message-ID: <4884ADD6.7010704@gmail.com> That reply/reply all is a blessing and a curse :^) -------- Original Message -------- Subject: Re: Can't export samba share Date: Mon, 21 Jul 2008 11:26:12 -0400 From: max To: Steve Blackwell References: <20080721105041.1fd67e05 at steve.blackwell> Steve Blackwell wrote: > I have a dual boot F8/XP machine and I want to export, via samba, the > NTFS partition so that I can use it to back up my wife's Vista machine. > It seems that selinux is preventing this from happening. Here is the > summary message from setroubleshoot: > > SELinux is preventing the samba daemon from serving r/o local files to > remote clients. > > and the Allowing Access section says: > > If you want to export file systems using samba you need to turn on the > samba_export_all_ro boolean: "setsebool -P samba_export_all_ro=1". The > following command will allow this access:setsebool -P > samba_export_all_ro=1 > > There seems to be 2 problems here; 1) The filesystem that I'm trying to > export is read-write not read-only and 2) I have already set > samba_export_all_ro=1. In fact I also set samba_export_all_rw=1 and I > even set samba_run_unconfined=1 and I still get the same messages. I would try setting samba_export_all_ro=0, leave samba_export_all_rw=1 Those two settings will conflict and denials should always win out over allows. > > Here is the filesystem I'm trying to export: > > # cat /etc/fstab | grep ntfs > /dev/sdb1 /mnt/c_drive ntfs-3g rw,defaults,umask=0000 0 0 > > # ls -lZ /mnt > drwxrwxrwx root root system_u:object_r:fusefs_t:s0 c_drive > > Here is the /etc/samba/smb.conf stanza: > [Kellie] > comment = Winblows backup > path = /mnt/c_drive > writable = yes > browseable = yes > valid users = Kellie > > User Kellie can see the Kellie share from her Vista computer but > whenever she tries to use it, I get an AVC. > > # rpm -qa | grep selinux > libselinux-python-2.0.43-1.fc8 > selinux-policy-devel-3.0.8-109.fc8 > libselinux-devel-2.0.43-1.fc8 > selinux-policy-3.0.8-109.fc8 > libselinux-2.0.43-1.fc8 > selinux-policy-targeted-3.0.8-109.fc8 > > # uname -sr > Linux 2.6.25.10-47.fc8 > > I suppose I could go back to permissive mode but I'd like to get this > to work. > > Any suggestion? > Thanks, > Steve > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From maximilianbianco at gmail.com Mon Jul 21 15:41:04 2008 From: maximilianbianco at gmail.com (max) Date: Mon, 21 Jul 2008 11:41:04 -0400 Subject: [Fwd: Re: Can't export samba share] Message-ID: <4884AE10.9010401@gmail.com> CURSES!! If it weren't for those damn kids I would have gotten away with it too... -------- Original Message -------- Subject: Re: Can't export samba share Date: Mon, 21 Jul 2008 11:38:06 -0400 From: max To: Steve Blackwell References: <20080721105041.1fd67e05 at steve.blackwell> <4884AA94.1010409 at gmail.com> max wrote: > Steve Blackwell wrote: >> I have a dual boot F8/XP machine and I want to export, via samba, the >> NTFS partition so that I can use it to back up my wife's Vista machine. >> It seems that selinux is preventing this from happening. Here is the >> summary message from setroubleshoot: >> >> SELinux is preventing the samba daemon from serving r/o local files to >> remote clients. >> and the Allowing Access section says: >> >> If you want to export file systems using samba you need to turn on the >> samba_export_all_ro boolean: "setsebool -P samba_export_all_ro=1". The >> following command will allow this access:setsebool -P >> samba_export_all_ro=1 >> >> There seems to be 2 problems here; 1) The filesystem that I'm trying to >> export is read-write not read-only and 2) I have already set >> samba_export_all_ro=1. In fact I also set samba_export_all_rw=1 and I >> even set samba_run_unconfined=1 and I still get the same messages. > > I would try setting samba_export_all_ro=0, leave samba_export_all_rw=1 > > Those two settings will conflict and denials should always win out over > allows. Just to be clear. I am saying where two settings conflict a denial should not be surprising, it makes good sense, at least to me. I am not sure you need samba_run_unconfined here either. Checkout man ausearch, this can help pull all the AVC's related to this together, it has many search options. It is worth reading. Max -- Fortune favors the BOLD From zephod at cfl.rr.com Mon Jul 21 16:18:58 2008 From: zephod at cfl.rr.com (Steve) Date: Mon, 21 Jul 2008 12:18:58 -0400 Subject: [Fwd: Re: Can't export samba share] Message-ID: <10745567.263771216657138368.JavaMail.root@cdptpa-web24-z02> ---- max wrote: > CURSES!! If it weren't for those damn kids I would have gotten away with > it too... > > -------- Original Message -------- > Subject: Re: Can't export samba share > Date: Mon, 21 Jul 2008 11:38:06 -0400 > From: max > To: Steve Blackwell > References: <20080721105041.1fd67e05 at steve.blackwell> > <4884AA94.1010409 at gmail.com> > > max wrote: > > Steve Blackwell wrote: > >> I have a dual boot F8/XP machine and I want to export, via samba, the > >> NTFS partition so that I can use it to back up my wife's Vista machine. > >> It seems that selinux is preventing this from happening. Here is the > >> summary message from setroubleshoot: > >> > >> SELinux is preventing the samba daemon from serving r/o local files to > >> remote clients. > >> and the Allowing Access section says: > >> > >> If you want to export file systems using samba you need to turn on the > >> samba_export_all_ro boolean: "setsebool -P samba_export_all_ro=1". The > >> following command will allow this access:setsebool -P > >> samba_export_all_ro=1 > >> > >> There seems to be 2 problems here; 1) The filesystem that I'm trying to > >> export is read-write not read-only and 2) I have already set > >> samba_export_all_ro=1. In fact I also set samba_export_all_rw=1 and I > >> even set samba_run_unconfined=1 and I still get the same messages. > > > > I would try setting samba_export_all_ro=0, leave samba_export_all_rw=1 > > > > Those two settings will conflict and denials should always win out over > > allows. Tried that. No luck. > Just to be clear. I am saying where two settings conflict a denial > should not be surprising, it makes good sense, at least to me. > > I am not sure you need samba_run_unconfined here either. Here is what I have set now: # getsebool -a | grep samba samba_domain_controller --> on samba_enable_home_dirs --> on samba_export_all_ro --> off samba_export_all_rw --> on samba_run_unconfined --> off samba_share_nfs --> off use_samba_home_dirs --> on > Checkout man ausearch, this can help pull all the AVC's related to this > together, it has many search options. It is worth reading. Will do. Thanks, Steve From zephod at cfl.rr.com Mon Jul 21 16:58:41 2008 From: zephod at cfl.rr.com (Steve Blackwell) Date: Mon, 21 Jul 2008 12:58:41 -0400 Subject: backups and selinux Message-ID: <20080721125841.1ff32fb1@steve.blackwell> Are any of the common linux backup utilities, eg Amanda or Backup-pc, selinux aware? Do they need to be? In other words, if I backup a file with a particular set of selinux attributes using one of these utilities, delete the file and then restore it, will the restored file have the correct attributes? I read somewhere on the selinux wiki that there was a special backup utility required but I can't find that page again. Thanks, Steve From sundaram at fedoraproject.org Mon Jul 21 17:49:50 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 21 Jul 2008 23:19:50 +0530 Subject: backups and selinux In-Reply-To: <20080721125841.1ff32fb1@steve.blackwell> References: <20080721125841.1ff32fb1@steve.blackwell> Message-ID: <4884CC3E.1080808@fedoraproject.org> Steve Blackwell wrote: > Are any of the common linux backup utilities, eg Amanda or > Backup-pc, selinux aware? Do they need to be? > > In other words, if I backup a file with a particular set of selinux > attributes using one of these utilities, delete the file and then > restore it, will the restored file have the correct attributes? > > I read somewhere on the selinux wiki that there was a special backup > utility required but I can't find that page again. Tar previously didn't support extended attributes (xattr) so star was needed but in newer version tar does so a special utility isn't required. I am not sure if any of the regular backup utilities do support xattr either. Rahul From mmcallis at redhat.com Mon Jul 21 22:39:49 2008 From: mmcallis at redhat.com (Murray McAllister) Date: Tue, 22 Jul 2008 08:39:49 +1000 Subject: Can't export samba share In-Reply-To: <20080721105041.1fd67e05@steve.blackwell> References: <20080721105041.1fd67e05@steve.blackwell> Message-ID: <48851035.60904@redhat.com> Steve Blackwell wrote: > I have a dual boot F8/XP machine and I want to export, via samba, the > NTFS partition so that I can use it to back up my wife's Vista machine. > It seems that selinux is preventing this from happening. Here is the > summary message from setroubleshoot: > > SELinux is preventing the samba daemon from serving r/o local files to > remote clients. > > and the Allowing Access section says: > > If you want to export file systems using samba you need to turn on the > samba_export_all_ro boolean: "setsebool -P samba_export_all_ro=1". The > following command will allow this access:setsebool -P > samba_export_all_ro=1 > > There seems to be 2 problems here; 1) The filesystem that I'm trying to > export is read-write not read-only and 2) I have already set > samba_export_all_ro=1. In fact I also set samba_export_all_rw=1 and I > even set samba_run_unconfined=1 and I still get the same messages. > > Here is the filesystem I'm trying to export: > > # cat /etc/fstab | grep ntfs > /dev/sdb1 /mnt/c_drive ntfs-3g rw,defaults,umask=0000 0 0 > > # ls -lZ /mnt > drwxrwxrwx root root system_u:object_r:fusefs_t:s0 c_drive > > Here is the /etc/samba/smb.conf stanza: > [Kellie] > comment = Winblows backup > path = /mnt/c_drive > writable = yes > browseable = yes > valid users = Kellie > > User Kellie can see the Kellie share from her Vista computer but > whenever she tries to use it, I get an AVC. > > # rpm -qa | grep selinux > libselinux-python-2.0.43-1.fc8 > selinux-policy-devel-3.0.8-109.fc8 > libselinux-devel-2.0.43-1.fc8 > selinux-policy-3.0.8-109.fc8 > libselinux-2.0.43-1.fc8 > selinux-policy-targeted-3.0.8-109.fc8 > > # uname -sr > Linux 2.6.25.10-47.fc8 > > I suppose I could go back to permissive mode but I'd like to get this > to work. > > Any suggestion? > Thanks, > Steve If you're still having problems, on "Confining Samba with SELinux" might help. Cheers. From zephod at cfl.rr.com Tue Jul 22 02:12:09 2008 From: zephod at cfl.rr.com (Steve) Date: Mon, 21 Jul 2008 22:12:09 -0400 Subject: Can't export samba share Message-ID: <32188329.368361216692729383.JavaMail.root@cdptpa-web24-z02> ---- Murray McAllister wrote: > Steve Blackwell wrote: > > I have a dual boot F8/XP machine and I want to export, via samba, the > > NTFS partition so that I can use it to back up my wife's Vista machine. > > It seems that selinux is preventing this from happening. Here is the > > summary message from setroubleshoot: > > > > SELinux is preventing the samba daemon from serving r/o local files to > > remote clients. ... > > If you're still having problems, > on "Confining Samba with > SELinux" might help. > Thanks for the link but I didn't learn anything new from that. Steve From wart at kobold.org Wed Jul 23 05:58:05 2008 From: wart at kobold.org (Wart) Date: Tue, 22 Jul 2008 22:58:05 -0700 Subject: custom policy guidelines Message-ID: <4886C86D.1040306@kobold.org> The proposed guidelines on the wiki recommend a %define macro to embed the build-time selinux-policy version in the resulting -selinux subpackage Requires: https://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules#Runtime_Dependencies This has worked fine for me in F-8 and F-9, but when I try to build the package (crossfire) in rawhide, mock now gives the error below. Is this a temporary rawhide problem, or do the guidelines need to be updated? --Wart Executing command: ['bash', '--login', '-c', 'rpmbuild -bs --target i386 --nodeps builddir/build/SPECS/crossfire.spec'] /etc/profile: line 38: /bin/hostname: No such file or directory sed: can't read /usr/share/selinux/devel/policyhelp: No such file or directory error: syntax error in expression error: /builddir/build/SPECS/crossfire.spec:91: parseExpressionBoolean returns -1 Building target platforms: i386 Building for target i386 Child returncode was: 1 EXCEPTION: Command failed. See logs for output. From wart at kobold.org Thu Jul 24 02:23:47 2008 From: wart at kobold.org (Wart) Date: Wed, 23 Jul 2008 19:23:47 -0700 Subject: custom policy guidelines In-Reply-To: <4886C86D.1040306@kobold.org> References: <4886C86D.1040306@kobold.org> Message-ID: <4887E7B3.7010903@kobold.org> Wart wrote: > The proposed guidelines on the wiki recommend a %define macro to embed > the build-time selinux-policy version in the resulting -selinux > subpackage Requires: > > https://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules#Runtime_Dependencies > > This has worked fine for me in F-8 and F-9, but when I try to build the > package (crossfire) in rawhide, mock now gives the error below. Is this > a temporary rawhide problem, or do the guidelines need to be updated? > > --Wart > > Executing command: ['bash', '--login', '-c', 'rpmbuild -bs --target i386 > --nodeps builddir/build/SPECS/crossfire.spec'] > /etc/profile: line 38: /bin/hostname: No such file or directory > sed: can't read /usr/share/selinux/devel/policyhelp: No such file or > directory > error: > syntax error in expression > error: > /builddir/build/SPECS/crossfire.spec:91: parseExpressionBoolean returns -1 > Building target platforms: i386 > Building for target i386 > Child returncode was: 1 > EXCEPTION: Command failed. See logs for output. For what it's worth, I get the same failure when building in koji: http://koji.fedoraproject.org/koji/getfile?taskID=735236&name=build.log --Wart From paul at city-fan.org Thu Jul 24 16:04:17 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 24 Jul 2008 17:04:17 +0100 Subject: custom policy guidelines In-Reply-To: <4886C86D.1040306@kobold.org> References: <4886C86D.1040306@kobold.org> Message-ID: <4888A801.1020202@city-fan.org> Wart wrote: > The proposed guidelines on the wiki recommend a %define macro to embed > the build-time selinux-policy version in the resulting -selinux > subpackage Requires: > > https://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules#Runtime_Dependencies > > This has worked fine for me in F-8 and F-9, but when I try to build the > package (crossfire) in rawhide, mock now gives the error below. Is this > a temporary rawhide problem, or do the guidelines need to be updated? I've updated the guidelines to something that works in both Rawhide and older releases. It's still a horrible hack of course. %global selinux_policyver %(%{__sed} -e 's,.*selinux-policy-\\([^/]*\\)/.*,\\1,' /usr/share/selinux/devel/policyhelp || echo 0.0.0) Requires: selinux-policy >= %{selinux_policyver} There's no longer any need for the %if clause around the Requires: line. Cheers, Paul. From mike.cloaked at gmail.com Thu Jul 24 21:04:45 2008 From: mike.cloaked at gmail.com (Mike) Date: Thu, 24 Jul 2008 21:04:45 +0000 (UTC) Subject: SELinux concerning /home symlink? Message-ID: I have had a thread running on Fedora list about a specific SELinux issue I have hit with F9. The history is that I did a clean install on a machine that was previously running F8, keeping /opt as an untouched partition and installed F9, leaving the SELinux enforcing on. On that /opt partition I keep the user area as /opt/Local/home, and as previously after the install I do cd / mv home home.dist ln -s /opt/Local/home . This then previously set my home areas to the way they were - On the machine in question this worked fine initially until I tried to ssh in to the machine from another in my local LAN. I was only able to login but could not change directory to the user home directory. There was a sealert message in /var/log/messages which indicated that I should restorecon -v /opt/* which I did - The contexts that are relevant were previously as follows: [mike lapmike2 mike]$ ls -Zd /opt/Local/home drwxr-xr-x root root system_u:object_r:file_t:s0 /opt/Local/home [mike lapmike2 mike]$ ls -Zd /home lrwxrwxrwx root root unconfined_u:object_r:root_t:s0 /home -> /opt/Local/home [mike lapmike2 mike]$ ls -Zd /home/mike drwx------ mike mike system_u:object_r:user_home_dir_t:s0 /home/mike [mike lapmike2 mike]$ ls -Zd /opt/Local/home/mike drwx------ mike mike system_u:object_r:user_home_dir_t:s0 /opt/Local/home/mike [mike lapmike2 mike]$ ls -Zd /home/mike/.bash_profile -rw-r--r-- mike mike system_u:object_r:user_home_t:s0 /home/mike/.bash_profile I noticed that my /opt/Local/home has a type file_t whereas a posting in fedora list indicated it should be home_root_t I ran restorecon -v /opt/* The context for /opt/Local/home then had a type usr_t So I did chcon -t home_root_t At this point I could login to the machine using ssh as user mike. However I could not use passwordless ssh login even though I did have the previously working ~/.ssh directory. The sealert message suggested that the context of the authorized_keys2 file was wrong and I should run restorecon -v /opt/Local/home/mike/.ssh/authorized_keys2 After doing this the context seemed the same as before and ssh remains only with a password for access and no passwordless login was possible. I found that another user reported a similar issue: http://www.mjmwired.net/linux/2008/06/16/ selinux-preventing-ssh-passwordless-login/ (This url should be on a single line) So how do I proceed? Is the problem caused by the fact that the home area is symlinked from /home to /opt/Local/home ? I have seen some suggestion in a blog elsewhere that symlinks are problematic in SELinux? Maybe I need to create a directory /home and then bind mount /opt/Local/home onto it? Any advice would be appreciated as I am very new to SELinux, but would like to make it work rather than switching it off as I have done up to now. Thanks Mike From mike.cloaked at gmail.com Thu Jul 24 21:41:07 2008 From: mike.cloaked at gmail.com (Mike) Date: Thu, 24 Jul 2008 21:41:07 +0000 (UTC) Subject: SELinux concerning /home symlink? References: Message-ID: Mike gmail.com> writes: > Is the problem caused by the fact that the home area is symlinked from > /home to /opt/Local/home ? It turned out that I have managed to fix the issue by changing the contexts of the files in /opt/Local/home/mike/.ssh to type user_home_t - and now the ssh problem has gone away. I was told by a helpful poster in Fedora list that the fact that my home areas are on /opt would have resulted in inappropriate contexts for /opt/Local/home since this would have been different if the partition had been /home and not under /opt - this was indeed the case and changing to user_home_t fixed this. I therefore suspect that I should change all the contexts to the same type in /opt/Local/home Anyway problem solved for the moment... this kind of information may well be useful to others who have atypical home areas for ease of doing upgrades. From craigwhite at azapple.com Thu Jul 24 22:00:05 2008 From: craigwhite at azapple.com (Craig White) Date: Thu, 24 Jul 2008 15:00:05 -0700 Subject: SELinux concerning /home symlink? In-Reply-To: References: Message-ID: <1216936805.25414.233.camel@lin-workstation.azapple.com> On Thu, 2008-07-24 at 21:41 +0000, Mike wrote: > Mike gmail.com> writes: > > > Is the problem caused by the fact that the home area is symlinked from > > /home to /opt/Local/home ? > > It turned out that I have managed to fix the issue by changing the contexts > of the files in /opt/Local/home/mike/.ssh to type user_home_t - and now > the ssh problem has gone away. > > I was told by a helpful poster in Fedora list that the fact that my home > areas are on /opt would have resulted in inappropriate contexts for > /opt/Local/home since this would have been different if the partition had > been /home and not under /opt - this was indeed the case and changing > to user_home_t fixed this. > > I therefore suspect that I should change all the contexts to the same type > in /opt/Local/home > > Anyway problem solved for the moment... this kind of information may well > be useful to others who have atypical home areas for ease of doing upgrades. ---- I would suggest that you would be far better off mounting the partition you now called /opt as /home and then move stuff around... i.e. init 1 umount /opt # then edit /etc/fstab so whatever partition mounts at /opt mounts at /home mount /home cd /home mv Local/home/* . # then mv everything that belongs in /opt to /opt # then init 3/5 Craig From tmz at pobox.com Thu Jul 24 22:57:40 2008 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 24 Jul 2008 18:57:40 -0400 Subject: SELinux concerning /home symlink? In-Reply-To: <1216936805.25414.233.camel@lin-workstation.azapple.com> References: <1216936805.25414.233.camel@lin-workstation.azapple.com> Message-ID: <20080724225740.GM5655@inocybe.teonanacatl.org> Craig White wrote: > I would suggest that you would be far better off mounting the > partition you now called /opt as /home and then move stuff around... Or bind mount /home to /opt/Local/home and then run restorecon -R /home to apply the proper labels to /home. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The downside of being better than everyone else is that people tend to assume you're pretentious. -- Demotivators (www.despair.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From wart at kobold.org Fri Jul 25 00:01:06 2008 From: wart at kobold.org (Michael Thomas) Date: Thu, 24 Jul 2008 17:01:06 -0700 Subject: custom policy guidelines In-Reply-To: <4888A801.1020202@city-fan.org> References: <4886C86D.1040306@kobold.org> <4888A801.1020202@city-fan.org> Message-ID: <488917C2.5080206@kobold.org> Paul Howarth wrote: > Wart wrote: >> The proposed guidelines on the wiki recommend a %define macro to embed >> the build-time selinux-policy version in the resulting -selinux >> subpackage Requires: >> >> https://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules#Runtime_Dependencies >> >> >> This has worked fine for me in F-8 and F-9, but when I try to build the >> package (crossfire) in rawhide, mock now gives the error below. Is this >> a temporary rawhide problem, or do the guidelines need to be updated? > > I've updated the guidelines to something that works in both Rawhide and > older releases. It's still a horrible hack of course. > > %global selinux_policyver %(%{__sed} -e > 's,.*selinux-policy-\\([^/]*\\)/.*,\\1,' > /usr/share/selinux/devel/policyhelp || echo 0.0.0) > Requires: selinux-policy >= %{selinux_policyver} > > There's no longer any need for the %if clause around the Requires: line. That fixed the issue. Thanks! --Wart From mike.cloaked at gmail.com Fri Jul 25 07:10:22 2008 From: mike.cloaked at gmail.com (Mike) Date: Fri, 25 Jul 2008 07:10:22 +0000 (UTC) Subject: SELinux concerning /home symlink? References: <1216936805.25414.233.camel@lin-workstation.azapple.com> <20080724225740.GM5655@inocybe.teonanacatl.org> Message-ID: Todd Zullinger pobox.com> writes: > Or bind mount /home to /opt/Local/home and then run restorecon -R > /home to apply the proper labels to /home. Thanks everyone - I will try bind mounting this evening.... Mike From mike.cloaked at gmail.com Fri Jul 25 21:54:51 2008 From: mike.cloaked at gmail.com (Mike) Date: Fri, 25 Jul 2008 21:54:51 +0000 (UTC) Subject: SELinux concerning /home symlink? References: <1216936805.25414.233.camel@lin-workstation.azapple.com> <20080724225740.GM5655@inocybe.teonanacatl.org> Message-ID: Mike gmail.com> writes: > Thanks everyone - I will try bind mounting this evening.... I got the /home pointing to /opt/Local/home just fine - but ...now doing mail: Having just been pretty pleased with myself for getting my system running I now find a problem.... This question was also posted to Fedora list. First I have my home directory bind mounted from /home to /opt/Local/home with no problems, and I bind mount using an fstab entry like /opt/Local/home /home ext3 bind 0 0 The context for /home is system_u:object_r:home_root_t:s0 and for /opt/Local/home it is the same. The mount works fine during boot - so I tried the same with my mail. I have an fstab entry /opt/Local/spool/mail /var/spool/mail ext3 bind 0 0 The context for /var/spool/mail is system_u:object_r:mail_spool_t:s0 and for /opt/Local/spool/mail it is also the same. I can manually do mount /var/spool/mail and the bind mount works fine. However on boot I get an avc denial, with kernel: type=1400 and and avc: denied {mounton} .... comm="mount" path="/var/spool/mail" dev=sda5 ino=419655 scontext=system_u:system_r:mount_t:so tcontext=system_u:object_r:mail_spool_t:so class=dir I am not sure what to change to make this work? From zephod at cfl.rr.com Fri Jul 25 23:27:11 2008 From: zephod at cfl.rr.com (Steve Blackwell) Date: Fri, 25 Jul 2008 19:27:11 -0400 Subject: Can't export samba share Message-ID: <20080725192711.09897d64@steve.blackwell> I've been out of town for a few days but there were no new postings while I was away and I still don't have a solution for this. Steve Blackwell wrote: > I have a dual boot F8/XP machine and I want to export, via samba, the > NTFS partition so that I can use it to back up my wife's Vista > machine. It seems that selinux is preventing this from happening. > Here is the summary message from setroubleshoot: > > SELinux is preventing the samba daemon from serving r/o local files > to remote clients. > > and the Allowing Access section says: > > If you want to export file systems using samba you need to turn on > the samba_export_all_ro boolean: "setsebool -P > samba_export_all_ro=1". The following command will allow this > access:setsebool -P samba_export_all_ro=1 > > There seems to be 2 problems here; 1) The filesystem that I'm trying > to export is read-write not read-only and 2) I have already set > samba_export_all_ro=1. In fact I also set samba_export_all_rw=1 and I > even set samba_run_unconfined=1 and I still get the same messages. > > Here is the filesystem I'm trying to export: > > # cat /etc/fstab | grep ntfs > /dev/sdb1 /mnt/c_drive ntfs-3g rw,defaults,umask=0000 0 0 > > # ls -lZ /mnt > drwxrwxrwx root root system_u:object_r:fusefs_t:s0 c_drive > > Here is the /etc/samba/smb.conf stanza: > [Kellie] > comment = Winblows backup > path = /mnt/c_drive > writable = yes > browseable = yes > valid users = Kellie > > User Kellie can see the Kellie share from her Vista computer but > whenever she tries to use it, I get an AVC. > > # rpm -qa | grep selinux > libselinux-python-2.0.43-1.fc8 > selinux-policy-devel-3.0.8-109.fc8 > libselinux-devel-2.0.43-1.fc8 > selinux-policy-3.0.8-109.fc8 > libselinux-2.0.43-1.fc8 > selinux-policy-targeted-3.0.8-109.fc8 > > # uname -sr > Linux 2.6.25.10-47.fc8 > > I suppose I could go back to permissive mode but I'd like to get this > to work. > > Any suggestion? > Thanks, > Steve From paul at city-fan.org Sat Jul 26 00:18:27 2008 From: paul at city-fan.org (Paul Howarth) Date: Sat, 26 Jul 2008 01:18:27 +0100 Subject: SELinux concerning /home symlink? In-Reply-To: References: <1216936805.25414.233.camel@lin-workstation.azapple.com> <20080724225740.GM5655@inocybe.teonanacatl.org> Message-ID: <20080726011827.751b6ccf@metropolis.intra.city-fan.org> On Fri, 25 Jul 2008 21:54:51 +0000 (UTC) Mike wrote: > Mike gmail.com> writes: > > > Thanks everyone - I will try bind mounting this evening.... > > I got the /home pointing to /opt/Local/home just fine - but ...now > doing mail: > > Having just been pretty pleased with myself for getting my system > running I now find a problem.... This question was also posted to > Fedora list. > > First I have my home directory bind mounted from /home > to /opt/Local/home with no problems, and I bind mount using an fstab > entry like /opt/Local/home /home ext3 bind 0 0 > > The context for /home is system_u:object_r:home_root_t:s0 > and for /opt/Local/home it is the same. > > The mount works fine during boot - so I tried the same with my mail. > > I have an fstab entry > /opt/Local/spool/mail /var/spool/mail ext3 bind 0 0 > > The context for /var/spool/mail is system_u:object_r:mail_spool_t:s0 > and for /opt/Local/spool/mail it is also the same. > > I can manually do > mount /var/spool/mail and the bind mount works fine. > > However on boot I get an avc denial, with kernel: type=1400 and > and avc: denied {mounton} .... comm="mount" path="/var/spool/mail" > dev=sda5 ino=419655 scontext=system_u:system_r:mount_t:so > tcontext=system_u:object_r:mail_spool_t:so class=dir > > I am not sure what to change to make this work? First temporarily unmount the bind mount: # umount /var/spool/mail Then change the context of the original /var/spool/mail to make it suitable for use as a mount point: # chcon -t mnt_t /var/spool/mail Mount at boot should now work. You can simulate this without actually rebooting by doing: # service netfs start Cheers, Paul. From mike.cloaked at gmail.com Sat Jul 26 08:27:48 2008 From: mike.cloaked at gmail.com (Mike) Date: Sat, 26 Jul 2008 08:27:48 +0000 (UTC) Subject: SELinux concerning /home symlink? References: <1216936805.25414.233.camel@lin-workstation.azapple.com> <20080724225740.GM5655@inocybe.teonanacatl.org> <20080726011827.751b6ccf@metropolis.intra.city-fan.org> Message-ID: Paul Howarth city-fan.org> writes: temporarily unmount the bind mount: > # umount /var/spool/mail > > Then change the context of the original /var/spool/mail to make it > suitable for use as a mount point: > # chcon -t mnt_t /var/spool/mail > > Mount at boot should now work. You can simulate this without actually > rebooting by doing: > # service netfs start Thank you Paul I'll do this later today when I get back to the machine.... Much appreciated Mike From mike.cloaked at gmail.com Sat Jul 26 09:16:11 2008 From: mike.cloaked at gmail.com (Mike) Date: Sat, 26 Jul 2008 09:16:11 +0000 (UTC) Subject: SELinux concerning /home symlink? - Resolved References: <1216936805.25414.233.camel@lin-workstation.azapple.com> <20080724225740.GM5655@inocybe.teonanacatl.org> <20080726011827.751b6ccf@metropolis.intra.city-fan.org> Message-ID: Mike gmail.com> writes: > > Paul Howarth city-fan.org> writes: > > # chcon -t mnt_t /var/spool/mail Excellent - this works just fine - many thanks for your help. From zephod at cfl.rr.com Sat Jul 26 18:25:07 2008 From: zephod at cfl.rr.com (Steve Blackwell) Date: Sat, 26 Jul 2008 14:25:07 -0400 Subject: Can't export samba share In-Reply-To: References: <20080725192711.09897d64@steve.blackwell> Message-ID: <20080726142507.786093f6@steve.blackwell> > On Fri, Jul 25, 2008 at 7:27 PM, Steve Blackwell > wrote: >> I've been out of town for a few days but there were no new postings >> while I was away and I still don't have a solution for this. >> > > Might I suggest posting the AVC's so that everyone can see what is > going on.\ I'm going to give it one more day and after that I'm going to have to turn selinux off. This is from audit.log: type=AVC msg=audit(1217030414.315:34): avc: denied { read } for pid=7099 comm="smbd" name="/" dev=sdb1 ino=5 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:fusefs_t:s0 tclass=dir type=SYSCALL msg=audit(1217030414.315:34): arch=40000003 syscall=5 success=no exit=-13 a0=b926ff00 a1=98800 a2=379d9c a3=b9293478 items=0 ppid=2649 pid=7099 auid=4294967295 uid=501 gid=0 euid=501 suid=0 fsuid=501 egid=501 sgid=0 fsgid=501 tty=(none) ses=4294967295 comm="smbd" exe="/usr/sbin/smbd" subj=system_u:system_r:smbd_t:s0 key=(null) type=AVC msg=audit(1217030414.317:35): avc: denied { read } for pid=7099 comm="smbd" name="/" dev=sdb1 ino=5 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:fusefs_t:s0 tclass=dir Steve From mike.cloaked at gmail.com Sun Jul 27 08:58:00 2008 From: mike.cloaked at gmail.com (Mike) Date: Sun, 27 Jul 2008 08:58:00 +0000 (UTC) Subject: SELinux from disabled to enforcing - is it possible? Message-ID: Having got one machine running with SELinux enabled very recently I decided to try to turn SELinux back on for a machine on which I had installed F9 a few weeks ago and set SELinux to disabled. That was a definite no-no - it would not boot once I set SELinux back to enforcing unless I added "selinux=0" to the kernel line for boot. I resorted to re-installing F9 and it works fone now with SELinux enabled. However I now wonder if it was in fact possible to go from SELinux disabled to enforcing or if this is something which is not possible? If it is impossible then there perhaps ought to be a health warning asking the user if they really want to switch to disabled - saying that reversing the change is not going to work. I thought I would ask here if the process is actually possible? From drago01 at gmail.com Sun Jul 27 10:11:20 2008 From: drago01 at gmail.com (drago01) Date: Sun, 27 Jul 2008 12:11:20 +0200 Subject: SELinux from disabled to enforcing - is it possible? In-Reply-To: References: Message-ID: On Sun, Jul 27, 2008 at 10:58 AM, Mike wrote: > Having got one machine running with SELinux enabled very recently I decided to > try to turn SELinux back on for a machine on which I had installed F9 a few > weeks ago and set SELinux to disabled. > > That was a definite no-no - it would not boot once I set SELinux back to > enforcing unless I added "selinux=0" to the kernel line for boot. > > I resorted to re-installing F9 and it works fone now with SELinux enabled. > > However I now wonder if it was in fact possible to go from SELinux disabled > to enforcing or if this is something which is not possible? > > If it is impossible then there perhaps ought to be a health warning asking > the user if they really want to switch to disabled - saying that reversing > the change is not going to work. > > I thought I would ask here if the process is actually possible? do touch /.autorelabel boot with enforcing=0 after the relabling is done it should work. From selinux.list at troodos.demon.co.uk Sun Jul 27 19:24:58 2008 From: selinux.list at troodos.demon.co.uk (Arthur Dent) Date: Sun, 27 Jul 2008 20:24:58 +0100 Subject: Clamd getting out of hand... Message-ID: <20080727192458.GA7621@localhost.localdomain> Hello All, I have been using SELinux in enforcing mode on my F8 box for some time now. I had to go through a bit of pain to get clamassassin working with clamd to scan my emails but it worked OK. This weekend I upgraded to F9 and have now had about a gazillion AVC denials related to clamd. I have therefore been forced to use audit2allow to add to the already pretty cumbersome local policy I had with F8. I list the policy below. All of the entries are as a result of some denial and subsequent audit2allow policy generation. My question is basically - can one of you gurus tell me if all this stuff is still necessary? Is there a policy in the works that might avoid all this? Thanks in advance AD ########################################## # cat myclamd.te policy_module(myclamd, 1.1.11) require { type clamscan_t; type clamd_t; class tcp_socket { write create connect }; type var_run_t; type user_home_t; class sock_file { write unlink create }; class file append; type unlabeled_t; class association recvfrom; } #============= clamd_t ============== allow clamd_t var_run_t:sock_file { unlink create }; corenet_tcp_bind_generic_port(clamd_t) userdom_read_generic_user_home_content_files(clamd_t) #============= clamscan_t ============== allow clamscan_t self:tcp_socket { write create connect }; allow clamscan_t user_home_t:file append; allow clamscan_t var_run_t:sock_file write; corenet_tcp_connect_generic_port(clamscan_t) corenet_sendrecv_unlabeled_packets(clamscan_t) mta_read_queue(clamscan_t) procmail_rw_tmp_files(clamscan_t) userdom_read_generic_user_home_content_files(clamscan_t) allow clamscan_t unlabeled_t:association recvfrom; ########################################## -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maximilianbianco at gmail.com Sun Jul 27 19:38:45 2008 From: maximilianbianco at gmail.com (max bianco) Date: Sun, 27 Jul 2008 15:38:45 -0400 Subject: Can't export samba share In-Reply-To: <20080726142507.786093f6@steve.blackwell> References: <20080725192711.09897d64@steve.blackwell> <20080726142507.786093f6@steve.blackwell> Message-ID: On Sat, Jul 26, 2008 at 2:25 PM, Steve Blackwell wrote: >> On Fri, Jul 25, 2008 at 7:27 PM, Steve Blackwell >> wrote: >>> I've been out of town for a few days but there were no new postings >>> while I was away and I still don't have a solution for this. >>> >> >> Might I suggest posting the AVC's so that everyone can see what is >> going on.\ > > I'm going to give it one more day and after that I'm going to have to > turn selinux off. > This seems a bit extreme. Have you tried looking at the tools available to help you? audit2why and audit2allow I have used these in the past to help me resolve my issues. It would help if you could say you had tried these, if you could at least show the output they provide you. I will help you as much as I can because I am interested in learning more, getting others to help is usually easier if they can see you are trying to resolve it yourself rather than relying on them to just provide an easy answer which incidentally will teach you nothing. > This is from audit.log: > > type=AVC msg=audit(1217030414.315:34): avc: denied { read } for > pid=7099 comm="smbd" name="/" dev=sdb1 ino=5 > scontext=system_u:system_r:smbd_t:s0 > tcontext=system_u:object_r:fusefs_t:s0 tclass=dir > This says that smbd is being denied the read permission for files of the type fusefs the _t is a convention that says "This is a type" So you need a rule that allows smbd_t to read fusefs_t. So try something like this: ausearch -a 34 | audit2allow what this will do is search the audit log for all the AVC's related to this particular instance of smbd attempting its read access and feed them to audit2allow. Audit2allow will generate some rule(s) based on these AVC's. It doesn't mean you should blindly implement them but if you can show the output , it can help in the process of fixing the denial, if nothing else it will show the more experienced hands that you have used the tools provided to at least try. You could substitute audit2why in place of audit2allow and it will attempt to explain what caused the denial. Can you post this to the list? -Max -- We start decomposing the day we are born From kris_s at atmyhome.org Wed Jul 30 02:19:10 2008 From: kris_s at atmyhome.org (Kristen Reitz) Date: Tue, 29 Jul 2008 18:19:10 -0800 Subject: qmail labeling Message-ID: <1EC831E0-43CA-45C5-B043-FA4D35796004@atmyhome.org> List I have had some trouble with qmail and SELinux. Following my installation of qmail and running restorecon on the /var/qmail directory tree I ran into AVC denial messages upon reboots. When my server boots the smart daemon is trying to send mail stating that I have a drive which is failing. (true, it's the one that caused me to have CentOS 5.2 on a new drive). The smartd error messages follow: Jul 24 14:31:39 host smartd[2598]: Monitoring 2 ATA and 0 SCSI devices Jul 24 14:31:39 host smartd[2598]: Device: /dev/hdb, FAILED SMART self-check. BACK UP DATA NOW! Jul 24 14:31:39 host smartd[2598]: Sending warning via mail to root ... Jul 24 14:31:39 host smartd[2598]: Warning via mail to root produced unexpected output (32 bytes) to STDOUT/STDERR: qmail-inject: fatal: read error Jul 24 14:31:39 host smartd[2598]: Warning via mail to root: successful Jul 24 14:31:39 host smartd[2598]: Device: /dev/hdb, 1522 Currently unreadable (pending) sectors Jul 24 14:31:39 host smartd[2598]: Sending warning via mail to root ... Jul 24 14:31:39 host smartd[2598]: Warning via mail to root produced unexpected output (32 bytes) to STDOUT/STDERR: qmail-inject: fatal: read error Jul 24 14:31:39 host smartd[2598]: Warning via mail to root: successful Jul 24 14:31:39 host smartd[2606]: smartd has fork()ed into background mode. New PID=2606. Below is the reason for the fatal read error which is listed above as being successful, but isn't. (AVC message not specific to the above smartd error, it's just one of many related to the smartd error) type=AVC msg=audit(1215375080.575:15): avc: denied { read } for pid=2585 comm="qmail-inject" name="me" dev=dm-4 ino=3170476 scontext=system_u:system_r:system_mail_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=SYSCALL msg=audit(1215375080.575:15): arch=40000003 syscall=5 success=no exit=-13 a0=804e45b a1=800 a2=0 a3=bfe68128 items=0 ppid=2584 pid=2585 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="qmail-inject" exe="/var/qmail/bin/qmail-inject" subj=system_u:system_r:system_mail_t:s0 key=(null) The "me" file is in the /var/qmail/control/ directory, a directory which hasn't any content labeling when I view a recent strict policy file. /var/qmail/bin(/.*)? system_u:object_r:bin_t:s0 /var/qmail/supervise(/.*)? system_u:object_r:svc_svc_t:s0 /var/qmail/supervise/.*/run -- system_u:object_r:svc_run_exec_t:s0 /var/qmail/supervise/.*/log/run -- system_u:object_r:svc_run_exec_t:s0 /var/qmail/rc -- system_u:object_r:bin_t:s0 /var/qmail/bin -d system_u:object_r:bin_t:s0 /var/qmail/bin/sendmail -- system_u:object_r:sendmail_exec_t:s0 The problem is when the system boots, the smartd finds my bad drive and tries to email me about it. No emails arrive and I find rather messages in my audit log. I ran audit2why to study this, then audit2allow to create te rules. Below are the rules created which I have implemented. allow system_mail_t var_t:dir { write remove_name add_name }; allow system_mail_t var_t:fifo_file write; allow system_mail_t var_t:file { write getattr link read create unlink }; I now received email ( 2 messages total ) from the smartd following a reboot. The question I have is this. Should I even be making allow rules at all? Should not the policy file have the right labeling for a qmail install? And since it appears to me it does not, should I be making a policy file which I can then use restorecon to adjust my system labeling with? Or are type enforcement rules truly the way to go? I must admit I am new to SELinux and it's management so this is all about learning. I am not seeking a 'fix' so much but rather an understanding leading to a proper fix. I have read that relabeling has security risk and should be avoided entirely. Perhaps that's another subject all together? Kristen From paul at city-fan.org Wed Jul 30 11:18:00 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 30 Jul 2008 12:18:00 +0100 Subject: SELinux concerning /home symlink? In-Reply-To: References: <1216936805.25414.233.camel@lin-workstation.azapple.com> <20080724225740.GM5655@inocybe.teonanacatl.org> <20080726011827.751b6ccf@metropolis.intra.city-fan.org> Message-ID: <48904DE8.6050903@city-fan.org> max bianco wrote: > On Fri, Jul 25, 2008 at 8:18 PM, Paul Howarth wrote: >> On Fri, 25 Jul 2008 21:54:51 +0000 (UTC) >> Mike wrote: >> >>> Mike gmail.com> writes: >>> >>>> Thanks everyone - I will try bind mounting this evening.... >>> I got the /home pointing to /opt/Local/home just fine - but ...now >>> doing mail: >>> >>> Having just been pretty pleased with myself for getting my system >>> running I now find a problem.... This question was also posted to >>> Fedora list. >>> >>> First I have my home directory bind mounted from /home >>> to /opt/Local/home with no problems, and I bind mount using an fstab >>> entry like /opt/Local/home /home ext3 bind 0 0 >>> >>> The context for /home is system_u:object_r:home_root_t:s0 >>> and for /opt/Local/home it is the same. >>> >>> The mount works fine during boot - so I tried the same with my mail. >>> >>> I have an fstab entry >>> /opt/Local/spool/mail /var/spool/mail ext3 bind 0 0 >>> >>> The context for /var/spool/mail is system_u:object_r:mail_spool_t:s0 >>> and for /opt/Local/spool/mail it is also the same. >>> >>> I can manually do >>> mount /var/spool/mail and the bind mount works fine. >>> >>> However on boot I get an avc denial, with kernel: type=1400 and >>> and avc: denied {mounton} .... comm="mount" path="/var/spool/mail" >>> dev=sda5 ino=419655 scontext=system_u:system_r:mount_t:so >>> tcontext=system_u:object_r:mail_spool_t:so class=dir >>> >>> I am not sure what to change to make this work? >> First temporarily unmount the bind mount: >> # umount /var/spool/mail >> >> Then change the context of the original /var/spool/mail to make it >> suitable for use as a mount point: >> # chcon -t mnt_t /var/spool/mail >> >> Mount at boot should now work. You can simulate this without actually >> rebooting by doing: >> # service netfs start >> >> Cheers, Paul. >> > Could I trouble you to be slightly more verbose so novices like myself > can get a better handle on the solution, because otherwise every > situation even remotely like this is going to get this solution > applied and this may not always be appropriate or suitable. Sure. The underlying problem is that "mount", when run confined by SELinux, is only allowed to mount filesystems on mount points that have specific context types, such as mnt_t. If you set up your partitioning at install time, the installer generally sets the context types of the directories to be used as mount points correctly. However, if you change your filesystem arrangement at a later date then the mount point directory you're using will probably have some other context type, such as mail_spool_t in this case, which mount isn't normally allowed to use as a mount point, and you get the AVC denials and failure to mount as a result. The fix is simply to label the mount point directory appropriately for a mount point. The other issue is why the original setup fails at boot time when it works just fine manually. The reason for this is that if you run "mount" manually, it runs unconfined (as do most programs, e.g. httpd) but if you run it from an initscript (as happens at boot time), the mount process transitions to the correct confined domain. So you get the denials at boot time but not when running "mount" manually. For this reason, I always now use "service netfs start" rather than "mount -a" after making changes to my filesystem layouts to check for SELinux issues. Hope that clears it up. Cheers, Paul. From eparis at redhat.com Wed Jul 30 13:47:09 2008 From: eparis at redhat.com (Eric Paris) Date: Wed, 30 Jul 2008 09:47:09 -0400 Subject: SELinux concerning /home symlink? In-Reply-To: <48904DE8.6050903@city-fan.org> References: <1216936805.25414.233.camel@lin-workstation.azapple.com> <20080724225740.GM5655@inocybe.teonanacatl.org> <20080726011827.751b6ccf@metropolis.intra.city-fan.org> <48904DE8.6050903@city-fan.org> Message-ID: <1217425629.2902.51.camel@localhost.localdomain> On Wed, 2008-07-30 at 12:18 +0100, Paul Howarth wrote: > The underlying problem is that "mount", when run confined by SELinux, is > only allowed to mount filesystems on mount points that have specific > context types, such as mnt_t. If you set up your partitioning at install > time, the installer generally sets the context types of the directories > to be used as mount points correctly. However, if you change your > filesystem arrangement at a later date then the mount point directory > you're using will probably have some other context type, such as > mail_spool_t in this case, which mount isn't normally allowed to use as > a mount point, and you get the AVC denials and failure to mount as a > result. The fix is simply to label the mount point directory > appropriately for a mount point. setsebool -P allow_mount_anyfile 1 should let him mount without any labeling changes right? You should be able to find this boolean in system-config-selinux and setroubleshoot should have suggested toggling this boolean. -Eric From paul at city-fan.org Wed Jul 30 14:05:45 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 30 Jul 2008 15:05:45 +0100 Subject: SELinux concerning /home symlink? In-Reply-To: <1217425629.2902.51.camel@localhost.localdomain> References: <1216936805.25414.233.camel@lin-workstation.azapple.com> <20080724225740.GM5655@inocybe.teonanacatl.org> <20080726011827.751b6ccf@metropolis.intra.city-fan.org> <48904DE8.6050903@city-fan.org> <1217425629.2902.51.camel@localhost.localdomain> Message-ID: <48907539.2000706@city-fan.org> Eric Paris wrote: > On Wed, 2008-07-30 at 12:18 +0100, Paul Howarth wrote: > >> The underlying problem is that "mount", when run confined by SELinux, is >> only allowed to mount filesystems on mount points that have specific >> context types, such as mnt_t. If you set up your partitioning at install >> time, the installer generally sets the context types of the directories >> to be used as mount points correctly. However, if you change your >> filesystem arrangement at a later date then the mount point directory >> you're using will probably have some other context type, such as >> mail_spool_t in this case, which mount isn't normally allowed to use as >> a mount point, and you get the AVC denials and failure to mount as a >> result. The fix is simply to label the mount point directory >> appropriately for a mount point. > > setsebool -P allow_mount_anyfile 1 > > should let him mount without any labeling changes right? You should be > able to find this boolean in system-config-selinux and setroubleshoot > should have suggested toggling this boolean. Yes, that should work too but would be more permissive than fixing the mountpoint context. Paul. From init at kth.se Wed Jul 30 14:10:26 2008 From: init at kth.se (Ingemar Nilsson) Date: Wed, 30 Jul 2008 16:10:26 +0200 Subject: Apache Httpd, PHP, Smarty and SELinux Message-ID: <48907652.8010503@kth.se> Hi. Yesterday I set up a small PHP web service on one of our CentOS 5 servers. It uses Smarty for templating, with the dynamically compiled templates being stored in a directory with SELinux context root:object_r:httpd_sys_content_t. The system runs with SELinux in enforcing mode, with httpd using the context root:system_u:httpd_t. For the fun of it, I looked through the SELinux policy allow rules, but I couldn't find a rule that says that processes in the httpd_t domain can write to files labeled httpd_sys_content_t, but it does anyway. I got the (supposedly) complete list of active policy rules using the command sesearch -a Running the command sesearch -a | grep 'httpd_t ' | grep httpd_sys_content_t produces the following list: allow httpd_t httpd_sys_content_t : file { ioctl read getattr lock }; allow httpd_t httpd_sys_content_t : dir { ioctl read getattr lock search }; allow httpd_t httpd_sys_content_t : lnk_file { ioctl read getattr lock }; allow httpd_t httpd_sys_content_t : file { ioctl read getattr lock }; allow httpd_t httpd_sys_content_t : dir { ioctl read getattr lock search }; allow httpd_t httpd_sys_content_t : lnk_file { read getattr }; type_transition httpd_t httpd_sys_content_t : process httpd_sys_script_t; I don't see any rule that allows httpd_t processes to write to httpd_sys_content_t directories. What is going on? Regards Ingemar From dwalsh at redhat.com Wed Jul 30 14:51:12 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 30 Jul 2008 10:51:12 -0400 Subject: SELinux concerning /home symlink? In-Reply-To: <48907539.2000706@city-fan.org> References: <1216936805.25414.233.camel@lin-workstation.azapple.com> <20080724225740.GM5655@inocybe.teonanacatl.org> <20080726011827.751b6ccf@metropolis.intra.city-fan.org> <48904DE8.6050903@city-fan.org> <1217425629.2902.51.camel@localhost.localdomain> <48907539.2000706@city-fan.org> Message-ID: <48907FE0.6060902@redhat.com> Paul Howarth wrote: > Eric Paris wrote: >> On Wed, 2008-07-30 at 12:18 +0100, Paul Howarth wrote: >> >>> The underlying problem is that "mount", when run confined by SELinux, >>> is only allowed to mount filesystems on mount points that have >>> specific context types, such as mnt_t. If you set up your >>> partitioning at install time, the installer generally sets the >>> context types of the directories to be used as mount points >>> correctly. However, if you change your filesystem arrangement at a >>> later date then the mount point directory you're using will probably >>> have some other context type, such as mail_spool_t in this case, >>> which mount isn't normally allowed to use as a mount point, and you >>> get the AVC denials and failure to mount as a result. The fix is >>> simply to label the mount point directory appropriately for a mount >>> point. >> >> setsebool -P allow_mount_anyfile 1 >> >> should let him mount without any labeling changes right? You should be >> able to find this boolean in system-config-selinux and setroubleshoot >> should have suggested toggling this boolean. > > Yes, that should work too but would be more permissive than fixing the > mountpoint context. > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list I have decided to make these directories a mountpoint files_mountpoint(mail_spool_t) You could have generated a policy module with this and mount would have been allowed also. policy_module(myspool, 1.0.0) gen_requires(` type mail_spool_t; ') files_mountpoint(mail_spool_t) The beauty of SELinux, three ways to solve the same problem. :^) From dwalsh at redhat.com Wed Jul 30 15:24:47 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 30 Jul 2008 11:24:47 -0400 Subject: Clamd getting out of hand... In-Reply-To: <20080727192458.GA7621@localhost.localdomain> References: <20080727192458.GA7621@localhost.localdomain> Message-ID: <489087BF.2060708@redhat.com> Arthur Dent wrote: > Hello All, > > I have been using SELinux in enforcing mode on my F8 box for some time > now. I had to go through a bit of pain to get clamassassin working with > clamd to scan my emails but it worked OK. > > This weekend I upgraded to F9 and have now had about a gazillion AVC > denials related to clamd. > > I have therefore been forced to use audit2allow to add to the already > pretty cumbersome local policy I had with F8. > > I list the policy below. All of the entries are as a result of some > denial and subsequent audit2allow policy generation. > > My question is basically - can one of you gurus tell me if all this > stuff is still necessary? Is there a policy in the works that might > avoid all this? > > Thanks in advance > > AD > > > ########################################## > # cat myclamd.te > policy_module(myclamd, 1.1.11) > require { > type clamscan_t; > type clamd_t; > class tcp_socket { write create connect }; > type var_run_t; > type user_home_t; > class sock_file { write unlink create }; > class file append; > type unlabeled_t; > class association recvfrom; > > } > > #============= clamd_t ============== > allow clamd_t var_run_t:sock_file { unlink create }; Looks like a labeling problem. > corenet_tcp_bind_generic_port(clamd_t) What port did it bind to? > userdom_read_generic_user_home_content_files(clamd_t) > > #============= clamscan_t ============== > allow clamscan_t self:tcp_socket { write create connect }; > allow clamscan_t user_home_t:file append; Labeling? > allow clamscan_t var_run_t:sock_file write; > corenet_tcp_connect_generic_port(clamscan_t) > corenet_sendrecv_unlabeled_packets(clamscan_t) > mta_read_queue(clamscan_t) > procmail_rw_tmp_files(clamscan_t) > userdom_read_generic_user_home_content_files(clamscan_t) > allow clamscan_t unlabeled_t:association recvfrom; > ########################################## > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Please attach the avc's used to create this policy? From maximilianbianco at gmail.com Wed Jul 30 15:40:50 2008 From: maximilianbianco at gmail.com (max) Date: Wed, 30 Jul 2008 11:40:50 -0400 Subject: SELinux concerning /home symlink? In-Reply-To: <48904DE8.6050903@city-fan.org> References: <1216936805.25414.233.camel@lin-workstation.azapple.com> <20080724225740.GM5655@inocybe.teonanacatl.org> <20080726011827.751b6ccf@metropolis.intra.city-fan.org> <48904DE8.6050903@city-fan.org> Message-ID: <48908B82.3040709@gmail.com> Paul Howarth wrote: > > Sure. > > The underlying problem is that "mount", when run confined by SELinux, is > only allowed to mount filesystems on mount points that have specific > context types, such as mnt_t. If you set up your partitioning at install > time, the installer generally sets the context types of the directories > to be used as mount points correctly. However, if you change your > filesystem arrangement at a later date then the mount point directory > you're using will probably have some other context type, such as > mail_spool_t in this case, which mount isn't normally allowed to use as > a mount point, and you get the AVC denials and failure to mount as a > result. The fix is simply to label the mount point directory > appropriately for a mount point. > > The other issue is why the original setup fails at boot time when it > works just fine manually. The reason for this is that if you run "mount" > manually, it runs unconfined (as do most programs, e.g. httpd) but if > you run it from an initscript (as happens at boot time), the mount > process transitions to the correct confined domain. So you get the > denials at boot time but not when running "mount" manually. For this > reason, I always now use "service netfs start" rather than "mount -a" > after making changes to my filesystem layouts to check for SELinux issues. > > Hope that clears it up. > > Cheers, Paul. Yes. Thanks. I did have another question but the replies below have given me sufficient food for thought...for now :^) Thanks again, Max From dwalsh at redhat.com Wed Jul 30 15:41:26 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 30 Jul 2008 11:41:26 -0400 Subject: qmail labeling In-Reply-To: <1EC831E0-43CA-45C5-B043-FA4D35796004@atmyhome.org> References: <1EC831E0-43CA-45C5-B043-FA4D35796004@atmyhome.org> Message-ID: <48908BA6.2010404@redhat.com> Kristen Reitz wrote: > List > > I have had some trouble with qmail and SELinux. Following my > installation of qmail and running restorecon on the /var/qmail directory > tree I ran into AVC denial messages upon reboots. > > When my server boots the smart daemon is trying to send mail stating > that I have a drive which is failing. (true, it's the one that caused me > to have CentOS 5.2 on a new drive). The smartd error messages follow: > > Jul 24 14:31:39 host smartd[2598]: Monitoring 2 ATA and 0 SCSI devices > Jul 24 14:31:39 host smartd[2598]: Device: /dev/hdb, FAILED SMART > self-check. BACK UP DATA NOW! > Jul 24 14:31:39 host smartd[2598]: Sending warning via mail to root ... > Jul 24 14:31:39 host smartd[2598]: Warning via mail to root produced > unexpected output (32 bytes) to STDOUT/STDERR: qmail-inject: fatal: > read error > Jul 24 14:31:39 host smartd[2598]: Warning via mail to root: successful > Jul 24 14:31:39 host smartd[2598]: Device: /dev/hdb, 1522 Currently > unreadable (pending) sectors > Jul 24 14:31:39 host smartd[2598]: Sending warning via mail to root ... > Jul 24 14:31:39 host smartd[2598]: Warning via mail to root produced > unexpected output (32 bytes) to STDOUT/STDERR: qmail-inject: fatal: > read error > Jul 24 14:31:39 host smartd[2598]: Warning via mail to root: successful > Jul 24 14:31:39 host smartd[2606]: smartd has fork()ed into background > mode. New PID=2606. > > Below is the reason for the fatal read error which is listed above as > being successful, but isn't. (AVC message not specific to the above > smartd error, it's just one of many related to the smartd error) > > type=AVC msg=audit(1215375080.575:15): avc: denied { read } for > pid=2585 comm="qmail-inject" name="me" dev=dm-4 ino=3170476 > scontext=system_u:system_r:system_mail_t:s0 > tcontext=user_u:object_r:var_t:s0 tclass=file > type=SYSCALL msg=audit(1215375080.575:15): arch=40000003 syscall=5 > success=no exit=-13 a0=804e45b a1=800 a2=0 a3=bfe68128 items=0 ppid=2584 > pid=2585 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=(none) ses=4294967295 comm="qmail-inject" > exe="/var/qmail/bin/qmail-inject" > subj=system_u:system_r:system_mail_t:s0 key=(null) > > The "me" file is in the /var/qmail/control/ directory, a directory which > hasn't any content labeling when I view a recent strict policy file. > > /var/qmail/bin(/.*)? system_u:object_r:bin_t:s0 > /var/qmail/supervise(/.*)? system_u:object_r:svc_svc_t:s0 > /var/qmail/supervise/.*/run -- system_u:object_r:svc_run_exec_t:s0 > /var/qmail/supervise/.*/log/run -- system_u:object_r:svc_run_exec_t:s0 > /var/qmail/rc -- system_u:object_r:bin_t:s0 > /var/qmail/bin -d system_u:object_r:bin_t:s0 > /var/qmail/bin/sendmail -- system_u:object_r:sendmail_exec_t:s0 > > The problem is when the system boots, the smartd finds my bad drive and > tries to email me about it. No emails arrive and I find rather messages > in my audit log. I ran audit2why to study this, then audit2allow to > create te rules. Below are the rules created which I have implemented. > > allow system_mail_t var_t:dir { write remove_name add_name }; > allow system_mail_t var_t:fifo_file write; > allow system_mail_t var_t:file { write getattr link read create unlink }; > > I now received email ( 2 messages total ) from the smartd following a > reboot. The question I have is this. Should I even be making allow rules > at all? Should not the policy file have the right labeling for a qmail > install? And since it appears to me it does not, should I be making a > policy file which I can then use restorecon to adjust my system labeling > with? Or are type enforcement rules truly the way to go? I must admit I > am new to SELinux and it's management so this is all about learning. I > am not seeking a 'fix' so much but rather an understanding leading to a > proper fix. I have read that relabeling has security risk and should be > avoided entirely. Perhaps that's another subject all together? > > Kristen > > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Could you try to label the directory mail_spool_t chcon -R -t mail_spool_t /var/qmail If that fixes the problem, you could execute this command to make it survive a relabel semanage fcontext -a -t mail_spool_t /var/qmail(/.*)? From dwalsh at redhat.com Wed Jul 30 15:51:06 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 30 Jul 2008 11:51:06 -0400 Subject: Apache Httpd, PHP, Smarty and SELinux In-Reply-To: <48907652.8010503@kth.se> References: <48907652.8010503@kth.se> Message-ID: <48908DEA.2040602@redhat.com> Ingemar Nilsson wrote: > Hi. > > Yesterday I set up a small PHP web service on one of our CentOS 5 > servers. It uses Smarty for templating, with the dynamically compiled > templates being stored in a directory with SELinux context > root:object_r:httpd_sys_content_t. The system runs with SELinux in > enforcing mode, with httpd using the context root:system_u:httpd_t. > > For the fun of it, I looked through the SELinux policy allow rules, but > I couldn't find a rule that says that processes in the httpd_t domain > can write to files labeled httpd_sys_content_t, but it does anyway. > > I got the (supposedly) complete list of active policy rules using the > command > > sesearch -a > > Running the command > > sesearch -a | grep 'httpd_t ' | grep httpd_sys_content_t > > produces the following list: > > allow httpd_t httpd_sys_content_t : file { ioctl read getattr lock }; > allow httpd_t httpd_sys_content_t : dir { ioctl read getattr lock > search }; > allow httpd_t httpd_sys_content_t : lnk_file { ioctl read getattr > lock }; > allow httpd_t httpd_sys_content_t : file { ioctl read getattr lock }; > allow httpd_t httpd_sys_content_t : dir { ioctl read getattr lock > search }; > allow httpd_t httpd_sys_content_t : lnk_file { read getattr }; > type_transition httpd_t httpd_sys_content_t : process > httpd_sys_script_t; > > I don't see any rule that allows httpd_t processes to write to > httpd_sys_content_t directories. What is going on? > > Regards > Ingemar > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list sesearch does not give you attributes. Could be a line like the following allow @ttr1154 @ttr0504 : file { ioctl read write create getattr setattr lock append unlink link rename open }; What is the context of the files that get created? From mike.cloaked at gmail.com Wed Jul 30 16:58:09 2008 From: mike.cloaked at gmail.com (Mike) Date: Wed, 30 Jul 2008 16:58:09 +0000 (UTC) Subject: SELinux concerning /home symlink? References: <1216936805.25414.233.camel@lin-workstation.azapple.com> <20080724225740.GM5655@inocybe.teonanacatl.org> <20080726011827.751b6ccf@metropolis.intra.city-fan.org> <48904DE8.6050903@city-fan.org> <1217425629.2902.51.camel@localhost.localdomain> <48907539.2000706@city-fan.org> <48907FE0.6060902@redhat.com> Message-ID: Daniel J Walsh redhat.com> writes: > I have decided to make these directories a mountpoint > > files_mountpoint(mail_spool_t) > > You could have generated a policy module with this and mount would have > been allowed also. > > policy_module(myspool, 1.0.0) > > gen_requires(` > type mail_spool_t; > ') > > files_mountpoint(mail_spool_t) > > The beauty of SELinux, three ways to solve the same problem. :^) Thanks for all these replies - I have learned a lot in the past few days... ... about SELinux... well at least a little less green than I was, and the benefit is that I now have two f9 boxes with SELinux set to enforcing.... Mike From selinux.list at troodos.demon.co.uk Wed Jul 30 17:29:23 2008 From: selinux.list at troodos.demon.co.uk (Arthur Dent) Date: Wed, 30 Jul 2008 18:29:23 +0100 Subject: Clamd getting out of hand... In-Reply-To: <489087BF.2060708@redhat.com> References: <20080727192458.GA7621@localhost.localdomain> <489087BF.2060708@redhat.com> Message-ID: <20080730172923.GA4400@localhost.localdomain> On Wed, Jul 30, 2008 at 11:24:47AM -0400, Daniel J Walsh wrote: > Arthur Dent wrote: > > Hello All, > > > > I have been using SELinux in enforcing mode on my F8 box for some time > > now. I had to go through a bit of pain to get clamassassin working with > > clamd to scan my emails but it worked OK. > > > > This weekend I upgraded to F9 and have now had about a gazillion AVC > > denials related to clamd. > > > > I have therefore been forced to use audit2allow to add to the already > > pretty cumbersome local policy I had with F8. > > > > I list the policy below. All of the entries are as a result of some > > denial and subsequent audit2allow policy generation. > > > > My question is basically - can one of you gurus tell me if all this > > stuff is still necessary? Is there a policy in the works that might > > avoid all this? > > > > Thanks in advance > > > > AD > > > > > > ########################################## > > # cat myclamd.te > > policy_module(myclamd, 1.1.11) > > require { > > type clamscan_t; > > type clamd_t; > > class tcp_socket { write create connect }; > > type var_run_t; > > type user_home_t; > > class sock_file { write unlink create }; > > class file append; > > type unlabeled_t; > > class association recvfrom; > > > > } > > > > #============= clamd_t ============== > > allow clamd_t var_run_t:sock_file { unlink create }; > Looks like a labeling problem. Well I did run touch /.autorelabel; reboot > > corenet_tcp_bind_generic_port(clamd_t) > What port did it bind to? In case it helps I have posted my entire clamd.conf file here: http://pastebin.com/m72927397 > > userdom_read_generic_user_home_content_files(clamd_t) > > > > #============= clamscan_t ============== > > allow clamscan_t self:tcp_socket { write create connect }; > > allow clamscan_t user_home_t:file append; > Labeling? > > allow clamscan_t var_run_t:sock_file write; > > corenet_tcp_connect_generic_port(clamscan_t) > > corenet_sendrecv_unlabeled_packets(clamscan_t) > > mta_read_queue(clamscan_t) > > procmail_rw_tmp_files(clamscan_t) > > userdom_read_generic_user_home_content_files(clamscan_t) > > allow clamscan_t unlabeled_t:association recvfrom; > > ########################################## > > > Please attach the avc's used to create this policy? Well I no longer have many of the older ones - much of the above was generated when I was running F8. If it's really important I could try to recover them from the backup archive - but that would be quite a lot of work... A selection of some of the 500 or so recent ones (since my upgrade to F9) can be found here: http://pastebin.com/m7b60d46a My current policy (now up to version 14!) looks like this (below), though with it in place everything now works fine. I have one other problem (with VMWare and unrelated to this) which merits its own thread and which I will post later. In the meantime time, thank you very much for your help. It's much appreciated... AD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From selinux.list at troodos.demon.co.uk Wed Jul 30 17:41:10 2008 From: selinux.list at troodos.demon.co.uk (Arthur Dent) Date: Wed, 30 Jul 2008 18:41:10 +0100 Subject: Clamd getting out of hand... In-Reply-To: <20080730172923.GA4400@localhost.localdomain> References: <20080727192458.GA7621@localhost.localdomain> <489087BF.2060708@redhat.com> <20080730172923.GA4400@localhost.localdomain> Message-ID: <20080730174110.GA5262@localhost.localdomain> On Wed, Jul 30, 2008 at 06:29:23PM +0100, Arthur Dent wrote: > > My current policy (now up to version 14!) looks like this (below), Ooopps. Forgot to include that... Here it is: ########################################## # cat myclamd.te policy_module(myclamd, 1.1.14) require { type clamscan_t; type clamd_t; class tcp_socket { write create connect }; type var_run_t; type user_home_t; class sock_file { write unlink create }; class file append; type unlabeled_t; class association recvfrom; type procmail_log_t; } #============= clamd_t ============== allow clamd_t var_run_t:sock_file { unlink create }; corenet_tcp_bind_generic_port(clamd_t) #corenet_tcp_bind_mail_port(clamd_t) #corenet_tcp_bind_msnp_port(clamd_t) #corenet_tcp_bind_asterisk_port(clamd_t) userdom_read_generic_user_home_content_files(clamd_t) #============= clamscan_t ============== allow clamscan_t self:tcp_socket { write create connect }; allow clamscan_t user_home_t:file append; allow clamscan_t var_run_t:sock_file write; corenet_tcp_connect_generic_port(clamscan_t) corenet_sendrecv_unlabeled_packets(clamscan_t) mta_read_queue(clamscan_t) procmail_rw_tmp_files(clamscan_t) userdom_read_generic_user_home_content_files(clamscan_t) allow clamscan_t unlabeled_t:association recvfrom; sendmail_rw_pipes(clamscan_t) allow clamscan_t procmail_log_t:file append; ########################################## Thanks again! AD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dsugar at tresys.com Wed Jul 30 18:08:39 2008 From: dsugar at tresys.com (Dave Sugar) Date: Wed, 30 Jul 2008 14:08:39 -0400 Subject: ANN: CDS Framework version 3.0 Message-ID: <1217441319.3863.5.camel@localhost.localdomain> Version 3.0 of the CDS Framework Toolkit from Tresys Technology is now available for download from the Tresys Open Source website at http://oss.tresys.com The CDS Framework Toolkit is an Eclipse plug-in that allows engineers to leverage the power of SELinux when designing and implementing cross domain solutions without requiring that they have in depth knowledge of the complex details of underlying SELinux security policies. In particular the CDS Framework Toolkit provides the following benefits to CDS developers on SELinux systems: * An integrated development environment for creating security policy * Graphical editing of information flow for developing security policy * SELinux policy generation * Integration with SLIDE and Reference Policy (also available on http://oss.tresys.com) Version 3.0 highlights: * Support for Multi-Level Security (MLS), as well as the previously supported type enforcement and Role-Based Access Control (RBAC) mechanisms * Support for labeled networking to allow for inter-system interactions * Enhanced usability by providing better end user customization of generated SELinux policy and an increase in the granularity of what can be specified within the Framework * Addition of form editors to edit linkage files * Display of custom additions (linkage and dictionary files) in the framework navigator * Display of backflow information with ability to customize in dictionary * Ability to hide enters and entrypoints * Enhancements to the new resource wizard * Bug fixes including problems with nested control resources, accesses to base domains, dictionary problems Dave Sugar Tresys Technology, LLC From init at kth.se Wed Jul 30 18:19:36 2008 From: init at kth.se (Ingemar Nilsson) Date: Wed, 30 Jul 2008 20:19:36 +0200 Subject: Apache Httpd, PHP, Smarty and SELinux In-Reply-To: <48908DEA.2040602@redhat.com> References: <48907652.8010503@kth.se> <48908DEA.2040602@redhat.com> Message-ID: <4890B0B8.7010907@kth.se> Daniel J Walsh wrote: > sesearch does not give you attributes. Attributes? Is there maybe some document explaining them that you can point me to? Actually it does give me attributes: sesearch -a | grep -P '@ttr\d{4} @ttr\d{4}' | grep ' file ' allow @ttr0269 @ttr0360 : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton execute_no_trans entrypoint execmod }; allow @ttr1170 @ttr1669 : file { ioctl read write getattr lock append }; allow @ttr0098 @ttr0115 : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton execute_no_trans entrypoint execmod }; allow @ttr0098 @ttr0359 : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton execute_no_trans entrypoint execmod }; allow @ttr0240 @ttr0078 : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton execute_no_trans entrypoint }; allow @ttr0240 @ttr0078 : file execmod ; > Could be a line like the following > allow @ttr1154 @ttr0504 : file { ioctl read write create getattr > setattr lock append unlink link rename open }; Your exact line could not be found above, but you might have meant it as an example? > What is the context of the files that get created? The files all get the context of the parent directory, that is root:object_r:httpd_sys_content_t. Regards Ingemar From dwalsh at redhat.com Wed Jul 30 18:44:28 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 30 Jul 2008 14:44:28 -0400 Subject: writing a policy. Confused about domain transition. In-Reply-To: <20080719152655.9bedk1i44kws8koo@www.ccsl.carleton.ca> References: <20080719152655.9bedk1i44kws8koo@www.ccsl.carleton.ca> Message-ID: <4890B68C.6040204@redhat.com> yiruli at ccsl.carleton.ca wrote: > Hi, > I am practising to write a policy for a music player called soundjuicer. > > Policy Tool I used: selinux-polgengui > > The beginning part of soundjuicer1.te is as follows: > ---------------------------------------------------- > type soundjuicer1_t; > type soundjuicer1_exec_t; > application_domain(soundjuicer1_t, soundjuicer1_exec_t) > role user_r types soundjuicer1_t; > ..... > ------------------------------------------------------- > > The context of login id is (id -Z): > user_u:user_r:user_t > > I loaded the module. And then I run the music player both from terminal > and GUI. I checked the context of the soundjuicer process. > The context of the process is : user_u:user_r:user_t > > Question: > With the context for the process, user_u:user_r:user_t, can I say that > the security policy for the program is not being enforced, because of > the failure of domain transition? > > Should the context of the process be: user_u:user_r:soundjuicer1_t? > > thanks > Yiru Li > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list You need to write a rule like gen_require(` type user_t; role user_r; type user_tty_device_t, user_devpts_t; ') soundjuicer1_run(user_t, user_r, { user_tty_device_t user_devpts_t }) From dwalsh at redhat.com Wed Jul 30 18:47:44 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 30 Jul 2008 14:47:44 -0400 Subject: Can't export samba share In-Reply-To: References: <20080725192711.09897d64@steve.blackwell> <20080726142507.786093f6@steve.blackwell> Message-ID: <4890B750.3020306@redhat.com> max bianco wrote: > On Sat, Jul 26, 2008 at 2:25 PM, Steve Blackwell wrote: >>> On Fri, Jul 25, 2008 at 7:27 PM, Steve Blackwell >>> wrote: >>>> I've been out of town for a few days but there were no new postings >>>> while I was away and I still don't have a solution for this. >>>> >>> Might I suggest posting the AVC's so that everyone can see what is >>> going on.\ >> I'm going to give it one more day and after that I'm going to have to >> turn selinux off. >> > This seems a bit extreme. Have you tried looking at the tools > available to help you? > audit2why and audit2allow > I have used these in the past to help me resolve my issues. It would > help if you could say you had tried these, if you could at least show > the output they provide you. I will help you as much as I can because > I am interested in learning more, getting others to help is usually > easier if they can see you are trying to resolve it yourself rather > than relying on them to just provide an easy answer which incidentally > will teach you nothing. > > >> This is from audit.log: >> >> type=AVC msg=audit(1217030414.315:34): avc: denied { read } for >> pid=7099 comm="smbd" name="/" dev=sdb1 ino=5 >> scontext=system_u:system_r:smbd_t:s0 >> tcontext=system_u:object_r:fusefs_t:s0 tclass=dir >> > This says that smbd is being denied the read permission for files of > the type fusefs > the _t is a convention that says "This is a type" > > So you need a rule that allows smbd_t to read fusefs_t. > So try something like this: > > ausearch -a 34 | audit2allow > > what this will do is search the audit log for all the AVC's related to > this particular instance of smbd attempting its read access and feed > them to audit2allow. Audit2allow will generate some rule(s) based on > these AVC's. It doesn't mean you should blindly implement them but if > you can show the output , it can help in the process of fixing the > denial, if nothing else it will show the more experienced hands that > you have used the tools provided to at least try. You could substitute > audit2why in place of audit2allow and it will attempt to explain what > caused the denial. Can you post this to the list? > > -Max > > Sorry I was away at OLS last week and am just getting back though the emails. What OS are you running? samba_share_fusefs is a boolean in Fedora 9 and Rawhide that allows the sharing of fusefs file systems in samba with selinux. setsebool -P samba_share_fusefs 1 From dwalsh at redhat.com Wed Jul 30 19:31:49 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 30 Jul 2008 15:31:49 -0400 Subject: Clamd getting out of hand... In-Reply-To: <20080730174110.GA5262@localhost.localdomain> References: <20080727192458.GA7621@localhost.localdomain> <489087BF.2060708@redhat.com> <20080730172923.GA4400@localhost.localdomain> <20080730174110.GA5262@localhost.localdomain> Message-ID: <4890C1A5.1050204@redhat.com> Arthur Dent wrote: > On Wed, Jul 30, 2008 at 06:29:23PM +0100, Arthur Dent wrote: >> My current policy (now up to version 14!) looks like this (below), > > Ooopps. Forgot to include that... > > Here it is: > ########################################## > # cat myclamd.te > policy_module(myclamd, 1.1.14) > require { > type clamscan_t; > type clamd_t; > class tcp_socket { write create connect }; > type var_run_t; > type user_home_t; > class sock_file { write unlink create }; > class file append; > type unlabeled_t; > class association recvfrom; > type procmail_log_t; > > } > > #============= clamd_t ============== > allow clamd_t var_run_t:sock_file { unlink create }; > corenet_tcp_bind_generic_port(clamd_t) > #corenet_tcp_bind_mail_port(clamd_t) > #corenet_tcp_bind_msnp_port(clamd_t) > #corenet_tcp_bind_asterisk_port(clamd_t) > userdom_read_generic_user_home_content_files(clamd_t) > > #============= clamscan_t ============== > allow clamscan_t self:tcp_socket { write create connect }; > allow clamscan_t user_home_t:file append; > allow clamscan_t var_run_t:sock_file write; > corenet_tcp_connect_generic_port(clamscan_t) > corenet_sendrecv_unlabeled_packets(clamscan_t) > mta_read_queue(clamscan_t) > procmail_rw_tmp_files(clamscan_t) > userdom_read_generic_user_home_content_files(clamscan_t) > allow clamscan_t unlabeled_t:association recvfrom; > sendmail_rw_pipes(clamscan_t) > allow clamscan_t procmail_log_t:file append; > ########################################## > > Thanks again! > > AD > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list If you change the labeling on /var/run/clamd to clamd_var_run_t chcon -R -t clamd_var_run_t /var/run/clamd It should eliminate a couple of allow rules on /var/run above. From dwalsh at redhat.com Wed Jul 30 19:33:14 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 30 Jul 2008 15:33:14 -0400 Subject: Clamd getting out of hand... In-Reply-To: <20080730172923.GA4400@localhost.localdomain> References: <20080727192458.GA7621@localhost.localdomain> <489087BF.2060708@redhat.com> <20080730172923.GA4400@localhost.localdomain> Message-ID: <4890C1FA.3030804@redhat.com> Arthur Dent wrote: > On Wed, Jul 30, 2008 at 11:24:47AM -0400, Daniel J Walsh wrote: >> Arthur Dent wrote: >>> Hello All, >>> >>> I have been using SELinux in enforcing mode on my F8 box for some time >>> now. I had to go through a bit of pain to get clamassassin working with >>> clamd to scan my emails but it worked OK. >>> >>> This weekend I upgraded to F9 and have now had about a gazillion AVC >>> denials related to clamd. >>> >>> I have therefore been forced to use audit2allow to add to the already >>> pretty cumbersome local policy I had with F8. >>> >>> I list the policy below. All of the entries are as a result of some >>> denial and subsequent audit2allow policy generation. >>> >>> My question is basically - can one of you gurus tell me if all this >>> stuff is still necessary? Is there a policy in the works that might >>> avoid all this? >>> >>> Thanks in advance >>> >>> AD >>> >>> >>> ########################################## >>> # cat myclamd.te >>> policy_module(myclamd, 1.1.11) >>> require { >>> type clamscan_t; >>> type clamd_t; >>> class tcp_socket { write create connect }; >>> type var_run_t; >>> type user_home_t; >>> class sock_file { write unlink create }; >>> class file append; >>> type unlabeled_t; >>> class association recvfrom; >>> >>> } >>> >>> #============= clamd_t ============== >>> allow clamd_t var_run_t:sock_file { unlink create }; >> Looks like a labeling problem. > > Well I did run touch /.autorelabel; reboot > >>> corenet_tcp_bind_generic_port(clamd_t) >> What port did it bind to? > > In case it helps I have posted my entire clamd.conf file here: > http://pastebin.com/m72927397 > >>> userdom_read_generic_user_home_content_files(clamd_t) >>> >>> #============= clamscan_t ============== >>> allow clamscan_t self:tcp_socket { write create connect }; >>> allow clamscan_t user_home_t:file append; >> Labeling? >>> allow clamscan_t var_run_t:sock_file write; >>> corenet_tcp_connect_generic_port(clamscan_t) >>> corenet_sendrecv_unlabeled_packets(clamscan_t) >>> mta_read_queue(clamscan_t) >>> procmail_rw_tmp_files(clamscan_t) >>> userdom_read_generic_user_home_content_files(clamscan_t) >>> allow clamscan_t unlabeled_t:association recvfrom; >>> ########################################## >>> >> Please attach the avc's used to create this policy? > > Well I no longer have many of the older ones - much of the above was > generated when I was running F8. If it's really important I could try > to recover them from the backup archive - but that would be quite a lot > of work... > > A selection of some of the 500 or so recent ones (since my upgrade > to F9) can be found here: > http://pastebin.com/m7b60d46a > > My current policy (now up to version 14!) looks like this (below), > though with it in place everything now works fine. I have one other > problem (with VMWare and unrelated to this) which merits its own thread > and which I will post later. > > In the meantime time, thank you very much for your help. It's much > appreciated... > > AD > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list But do you have the original avc messages used to generate the policy. I want to see if we are missing transitions? What port is it communicating with etc. From olivares14031 at yahoo.com Thu Jul 31 19:17:39 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Thu, 31 Jul 2008 12:17:39 -0700 (PDT) Subject: selinux and denied gconf errors Message-ID: <844219.47264.qm@web52607.mail.re2.yahoo.com> Dear all, A group of selinux errors and denied avcs follows: Summary: SELinux is preventing updatedb (locate_t) "getattr" to /home/olivares/.gconfd (unlabeled_t). Detailed Description: SELinux denied access requested by updatedb. It is not expected that this access is required by updatedb and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /home/olivares/.gconfd, restorecon -v '/home/olivares/.gconfd' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:locate_t Target Context system_u:object_r:unlabeled_t Target Objects /home/olivares/.gconfd [ dir ] Source updatedb Source Path /usr/bin/updatedb Port Host localhost.localdomain Source RPM Packages mlocate-0.21-1.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.1-3.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.26-0.44.rc4.git2.fc10.i686 #1 SMP Thu May 29 13:44:38 EDT 2008 i686 i686 Alert Count 2 First Seen Wed 30 Jul 2008 09:26:20 PM CDT Last Seen Thu 31 Jul 2008 01:31:21 PM CDT Local ID 01cdf1be-4f1a-4058-bc41-81cc1c834598 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1217529081.437:33): avc: denied { getattr } for pid=10222 comm="updatedb" path="/home/olivares/.gconfd" dev=dm-0 ino=476292 scontext=system_u:system_r:locate_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir host=localhost.localdomain type=SYSCALL msg=audit(1217529081.437:33): arch=40000003 syscall=196 success=no exit=-13 a0=9893169 a1=bfcfd748 a2=c1cff4 a3=9893169 items=0 ppid=10216 pid=10222 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="updatedb" exe="/usr/bin/updatedb" subj=system_u:system_r:locate_t:s0 key=(null) Summary: SELinux is preventing updatedb (locate_t) "getattr" to /home/olivares/.gconf (unlabeled_t). Detailed Description: SELinux denied access requested by updatedb. It is not expected that this access is required by updatedb and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /home/olivares/.gconf, restorecon -v '/home/olivares/.gconf' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:locate_t Target Context system_u:object_r:unlabeled_t Target Objects /home/olivares/.gconf [ dir ] Source updatedb Source Path /usr/bin/updatedb Port Host localhost.localdomain Source RPM Packages mlocate-0.21-1.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.1-3.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.26-0.44.rc4.git2.fc10.i686 #1 SMP Thu May 29 13:44:38 EDT 2008 i686 i686 Alert Count 2 First Seen Wed 30 Jul 2008 09:26:20 PM CDT Last Seen Thu 31 Jul 2008 01:31:21 PM CDT Local ID 62d1f886-f58a-4fa3-8222-c3ba79bf4989 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1217529081.436:32): avc: denied { getattr } for pid=10222 comm="updatedb" path="/home/olivares/.gconf" dev=dm-0 ino=476270 scontext=system_u:system_r:locate_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir host=localhost.localdomain type=SYSCALL msg=audit(1217529081.436:32): arch=40000003 syscall=196 success=no exit=-13 a0=9892f89 a1=bfcfd748 a2=c1cff4 a3=9892f89 items=0 ppid=10216 pid=10222 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="updatedb" exe="/usr/bin/updatedb" subj=system_u:system_r:locate_t:s0 key=(null) Summary: SELinux is preventing updatedb (locate_t) "getattr" to /home/olivares/.config/gtk-2.0 (unlabeled_t). Detailed Description: SELinux denied access requested by updatedb. It is not expected that this access is required by updatedb and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /home/olivares/.config/gtk-2.0, restorecon -v '/home/olivares/.config/gtk-2.0' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:locate_t Target Context system_u:object_r:unlabeled_t Target Objects /home/olivares/.config/gtk-2.0 [ dir ] Source updatedb Source Path /usr/bin/updatedb Port Host localhost.localdomain Source RPM Packages mlocate-0.21-1.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.1-3.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.26-0.44.rc4.git2.fc10.i686 #1 SMP Thu May 29 13:44:38 EDT 2008 i686 i686 Alert Count 2 First Seen Wed 30 Jul 2008 09:26:19 PM CDT Last Seen Thu 31 Jul 2008 01:31:21 PM CDT Local ID e551c492-3193-4a8b-9885-2c0a9330caf8 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1217529081.12:31): avc: denied { getattr } for pid=10222 comm="updatedb" path="/home/olivares/.config/gtk-2.0" dev=dm-0 ino=426550 scontext=system_u:system_r:locate_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir host=localhost.localdomain type=SYSCALL msg=audit(1217529081.12:31): arch=40000003 syscall=196 success=no exit=-13 a0=9893509 a1=bfcfd5c8 a2=c1cff4 a3=9893509 items=0 ppid=10216 pid=10222 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="updatedb" exe="/usr/bin/updatedb" subj=system_u:system_r:locate_t:s0 key=(null) Summary: SELinux is preventing updatedb (locate_t) "getattr" to /root/.gconfd (unlabeled_t). Detailed Description: SELinux denied access requested by updatedb. It is not expected that this access is required by updatedb and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /root/.gconfd, restorecon -v '/root/.gconfd' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:locate_t Target Context system_u:object_r:unlabeled_t Target Objects /root/.gconfd [ dir ] Source updatedb Source Path /usr/bin/updatedb Port Host localhost.localdomain Source RPM Packages mlocate-0.21-1.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.1-3.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.26-0.44.rc4.git2.fc10.i686 #1 SMP Thu May 29 13:44:38 EDT 2008 i686 i686 Alert Count 2 First Seen Wed 30 Jul 2008 09:26:40 PM CDT Last Seen Thu 31 Jul 2008 01:31:31 PM CDT Local ID 9abda88c-0b21-4d95-914b-8a8e43658f2b Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1217529091.176:37): avc: denied { getattr } for pid=10222 comm="updatedb" path="/root/.gconfd" dev=dm-0 ino=33243 scontext=system_u:system_r:locate_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir host=localhost.localdomain type=SYSCALL msg=audit(1217529091.176:37): arch=40000003 syscall=196 success=no exit=-13 a0=9892f15 a1=bfcfd8c8 a2=c1cff4 a3=9892f15 items=0 ppid=10216 pid=10222 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="updatedb" exe="/usr/bin/updatedb" subj=system_u:system_r:locate_t:s0 key=(null) Summary: SELinux is preventing updatedb (locate_t) "getattr" to /root/.gnome2 (unlabeled_t). Detailed Description: SELinux denied access requested by updatedb. It is not expected that this access is required by updatedb and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /root/.gnome2, restorecon -v '/root/.gnome2' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:locate_t Target Context system_u:object_r:unlabeled_t Target Objects /root/.gnome2 [ dir ] Source updatedb Source Path /usr/bin/updatedb Port Host localhost.localdomain Source RPM Packages mlocate-0.21-1.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.1-3.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.26-0.44.rc4.git2.fc10.i686 #1 SMP Thu May 29 13:44:38 EDT 2008 i686 i686 Alert Count 2 First Seen Wed 30 Jul 2008 09:26:40 PM CDT Last Seen Thu 31 Jul 2008 01:31:31 PM CDT Local ID 94a6e1e9-462b-4288-a2c9-9678abafa22c Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1217529091.179:38): avc: denied { getattr } for pid=10222 comm="updatedb" path="/root/.gnome2" dev=dm-0 ino=33245 scontext=system_u:system_r:locate_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir host=localhost.localdomain type=SYSCALL msg=audit(1217529091.179:38): arch=40000003 syscall=196 success=no exit=-13 a0=9892e95 a1=bfcfd8c8 a2=c1cff4 a3=9892e95 items=0 ppid=10216 pid=10222 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="updatedb" exe="/usr/bin/updatedb" subj=system_u:system_r:locate_t:s0 key=(null) Summary: SELinux is preventing updatedb (locate_t) "getattr" to /root/.gconf (unlabeled_t). Detailed Description: SELinux denied access requested by updatedb. It is not expected that this access is required by updatedb and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /root/.gconf, restorecon -v '/root/.gconf' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:locate_t Target Context system_u:object_r:unlabeled_t Target Objects /root/.gconf [ dir ] Source updatedb Source Path /usr/bin/updatedb Port Host localhost.localdomain Source RPM Packages mlocate-0.21-1.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.1-3.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.26-0.44.rc4.git2.fc10.i686 #1 SMP Thu May 29 13:44:38 EDT 2008 i686 i686 Alert Count 2 First Seen Wed 30 Jul 2008 09:26:40 PM CDT Last Seen Thu 31 Jul 2008 01:31:31 PM CDT Local ID 72df776e-7cd5-4444-bfd7-173e26d0814c Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1217529091.174:36): avc: denied { getattr } for pid=10222 comm="updatedb" path="/root/.gconf" dev=dm-0 ino=33242 scontext=system_u:system_r:locate_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir host=localhost.localdomain type=SYSCALL msg=audit(1217529091.174:36): arch=40000003 syscall=196 success=no exit=-13 a0=9892e21 a1=bfcfd8c8 a2=c1cff4 a3=9892e21 items=0 ppid=10216 pid=10222 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="updatedb" exe="/usr/bin/updatedb" subj=system_u:system_r:locate_t:s0 key=(null) Summary: SELinux is preventing updatedb (locate_t) "getattr" to /root/.config/gtk-2.0 (unlabeled_t). Detailed Description: SELinux denied access requested by updatedb. It is not expected that this access is required by updatedb and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /root/.config/gtk-2.0, restorecon -v '/root/.config/gtk-2.0' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:locate_t Target Context system_u:object_r:unlabeled_t Target Objects /root/.config/gtk-2.0 [ dir ] Source updatedb Source Path /usr/bin/updatedb Port Host localhost.localdomain Source RPM Packages mlocate-0.21-1.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.1-3.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.26-0.44.rc4.git2.fc10.i686 #1 SMP Thu May 29 13:44:38 EDT 2008 i686 i686 Alert Count 2 First Seen Wed 30 Jul 2008 09:26:40 PM CDT Last Seen Thu 31 Jul 2008 01:31:31 PM CDT Local ID fe2c17eb-dbce-4a97-9cb8-77588b788ab7 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1217529091.123:35): avc: denied { getattr } for pid=10222 comm="updatedb" path="/root/.config/gtk-2.0" dev=dm-0 ino=35023 scontext=system_u:system_r:locate_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir host=localhost.localdomain type=SYSCALL msg=audit(1217529091.123:35): arch=40000003 syscall=196 success=no exit=-13 a0=98930d1 a1=bfcfd748 a2=c1cff4 a3=98930d1 items=0 ppid=10216 pid=10222 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="updatedb" exe="/usr/bin/updatedb" subj=system_u:system_r:locate_t:s0 key=(null) Thanks in Advance, Antonio From eparis at redhat.com Thu Jul 31 21:23:53 2008 From: eparis at redhat.com (Eric Paris) Date: Thu, 31 Jul 2008 17:23:53 -0400 Subject: selinux and denied gconf errors In-Reply-To: <844219.47264.qm@web52607.mail.re2.yahoo.com> References: <844219.47264.qm@web52607.mail.re2.yahoo.com> Message-ID: <1217539433.2902.128.camel@localhost.localdomain> On Thu, 2008-07-31 at 12:17 -0700, Antonio Olivares wrote: All labeling issues, either things on disk have no label (they were created on a machine not running SELinux), they have an old label (I don't remember us changing .gconfd anytime recently) or any number of other things. Easiest is: touch /.autorelabel; reboot You also might fix all/most of these with restorecon -R -v /home /root -Eric