From gizmo at giz-works.com Tue Dec 1 14:44:35 2009 From: gizmo at giz-works.com (Chris Richards) Date: Tue, 01 Dec 2009 08:44:35 -0600 Subject: AVC Denials on UDEV Message-ID: <4B152BD3.60109@giz-works.com> First, my apologies if I'm in the wrong place or this has been asked before (I'm sure it has, but I haven't turned up anything with Google). I'm running a Gentoo system. This is a fresh build, so not everything is installed yet. Basically, I've got the stage 3 tarball, the Selinux stuff, syslog-ng and vixie-cron, and that's about it. When I boot my sysem, I'm getting the following messages in my kernel log: * Mounting /dev /etc/init.d/udev-mount: line 63: /dev/null: Permission denied /etc/init.d/udev: line 69: /dev/null: Permission denied * Starting udevd * Populating /dev with existing devices through uevents ... # Waiting for uevents to be processed ... error sending message: Permission denied error sending message: Permission denied udevadm[601]: errorsending message: Permission denied Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.208:3): avc: denied { read } for pid=1 comm="init" name="ld.so.cache" dev=sda3 ino=737384 scontext=system_u:system_r:init_t tcontext=system_u:object_r:file_t tclass=file Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.215:4): avc: denied { getattr } for pid=1 comm="init" path="/etc/ld.so.cache" dev=sda3 ino=737384 scontext=system_u:system_r:init_t tcontext=system_u:object_r:file_t tclass=file The pattern of denials above repeats for a number of comm= types, including consoletype, dmesg, hwclock, hostname, ifconfig Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.221:5): avc: denied { read } for pid=1 comm="init" name="urandom" dev=sda3 ino=140683 scontext=system_u:system_r:init_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file As above, I get a number of denials on different comm= types. I'm also seeing a buttload of these in my avc.log: Dec 1 13:48:41 aoaforums kernel: type=1400 audit(1259675321.237:1614490880): avc: denied { read } for pid=477 comm="udevd" path="anon_inode:[signalfd]" dev=anon_inodefs ino=9 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:anon_inodefs_t tclass=file This one in particular is bad: my log is full to overflowing with this one, and when I'm in enforcing mode udevd is pulling 100% cpu. Finally, a related question: Gentoo is currently running what is labeled as "selinux-base-policy-20080525". This seems to bear little resemblance to the policy and tools that I see discussed here: http://oss.tresys.com/projects/refpolicy/wiki/GettingStarted In particular, a lot of the booleans don't exist. As near as I can tell, this is pretty much the policy that was used in RHEL 4. However, I can find precious little in the way of documentation on the older policy setup. Can anyone provide any guidance on resources to look at for this? Referring me to the current base policy and tools really doesn't help me in understanding what my system is doing..... Many thanks in advance for any guidance you can offer. Later, Chris From domg472 at gmail.com Tue Dec 1 15:47:24 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 01 Dec 2009 16:47:24 +0100 Subject: AVC Denials on UDEV In-Reply-To: <4B152BD3.60109@giz-works.com> References: <4B152BD3.60109@giz-works.com> Message-ID: <4B153A8C.8050609@gmail.com> On 12/01/2009 03:44 PM, Chris Richards wrote: > First, my apologies if I'm in the wrong place or this has been asked > before (I'm sure it has, but I haven't turned up anything with Google). > > I'm running a Gentoo system. This is a fresh build, so not everything > is installed yet. Basically, I've got the stage 3 tarball, the Selinux > stuff, syslog-ng and vixie-cron, and that's about it. > > When I boot my sysem, I'm getting the following messages in my kernel log: > * Mounting /dev > /etc/init.d/udev-mount: line 63: /dev/null: Permission denied > /etc/init.d/udev: line 69: /dev/null: Permission denied > * Starting udevd > * Populating /dev with existing devices through uevents ... > # Waiting for uevents to be processed ... > error sending message: Permission denied > error sending message: Permission denied > udevadm[601]: errorsending message: Permission denied > > Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.208:3): > avc: denied { read } for pid=1 comm="init" name="ld.so.cache" dev=sda3 > ino=737384 scontext=system_u:system_r:init_t > tcontext=system_u:object_r:file_t tclass=file > Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.215:4): > avc: denied { getattr } for pid=1 comm="init" path="/etc/ld.so.cache" > dev=sda3 ino=737384 scontext=system_u:system_r:init_t > tcontext=system_u:object_r:file_t tclass=file looks like the file is mislabeled. what does matchpathcon /etc/ld.so.cache say? make sure that your file system labeling is correct. > The pattern of denials above repeats for a number of comm= types, > including consoletype, dmesg, hwclock, hostname, ifconfig > > Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.221:5): > avc: denied { read } for pid=1 comm="init" name="urandom" dev=sda3 > ino=140683 scontext=system_u:system_r:init_t > tcontext=system_u:object_r:urandom_device_t tclass=chr_file > > As above, I get a number of denials on different comm= types. > > > I'm also seeing a buttload of these in my avc.log: > Dec 1 13:48:41 aoaforums kernel: type=1400 > audit(1259675321.237:1614490880): avc: denied { read } for pid=477 > comm="udevd" path="anon_inode:[signalfd]" dev=anon_inodefs ino=9 > scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:anon_inodefs_t tclass=file > This one in particular is bad: my log is full to overflowing with this > one, and when I'm in enforcing mode udevd is pulling 100% cpu. If the types in this interaction are correct. Run the avc denial through audit2why. If audit2why says "missing TE rule"; then consider adding policy to allow it using audit2allow and semodule. > Finally, a related question: > Gentoo is currently running what is labeled as > "selinux-base-policy-20080525". That policy is old. See if you can implement some newer policy. > This seems to bear little resemblance to the policy and tools that I see > discussed here: > http://oss.tresys.com/projects/refpolicy/wiki/GettingStarted > > In particular, a lot of the booleans don't exist. As near as I can > tell, this is pretty much the policy that was used in RHEL 4. However, > I can find precious little in the way of documentation on the older > policy setup. Can anyone provide any guidance on resources to look at > for this? Referring me to the current base policy and tools really > doesn't help me in understanding what my system is doing..... > > Many thanks in advance for any guidance you can offer. Overall it is good to appreciate that SELinux is a framework and that policy is configuration. The framework allows you to define policy. The process of adding policy is always on going. In my view no policy will ever be perfect. There are simply to many variables. Learn how to implement policy, make security decisions and solve interaction problems. Theres a few things to consider: 1. are the types in an interaction the expected types. (mislabeled objects?) 2. is there some tunable policy available to allow an interaction that is currently denied? (audit2why) 3. is a denial caused by misconfiguration of one of the parties in an interaction? (check config of app) 4. is a denial signalling an intrusion. (break in?) 5. is a denials signalling a bug in one of the parties in an interaction? (bug in app) 6. is it a bug in selinux-policy( are rules to allow it missing?) > > Later, > Chris > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From domg472 at gmail.com Tue Dec 1 16:17:17 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 01 Dec 2009 17:17:17 +0100 Subject: libcgroup policy (concept) In-Reply-To: <4B0D8CF2.1040907@gmail.com> References: <4B0D8CF2.1040907@gmail.com> Message-ID: <4B15418D.5030804@gmail.com> On 11/25/2009 09:00 PM, Dominick Grift wrote: > Attached policy targets some libcgroup stuff. The policy is largely > untested (i do have it running on a few servers here but i get some avc > denials that i am not quite sure what to do with) > virtd_t also needs access to cgroup_t: i heard people suggest this is a el6 blocker bug. see my selinux-modules.git repository for fixes for this. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From Moray.Henderson at ict-software.org Wed Dec 2 13:41:28 2009 From: Moray.Henderson at ict-software.org (Moray Henderson) Date: Wed, 2 Dec 2009 13:41:28 +0000 Subject: Is this an selinux system? Message-ID: <000101ca7355$27379950$75a6cbf0$@Henderson@ict-software.org> I'm trying to solve a problem on an old EL4 box. /etc/sysconfig/selinux says: SELINUX=enforcing SELINUXTYPE=targeted sestatus says: SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 18 Policy from config file:targeted seinfo and sesearch say: Default policy search failed: This is not an selinux system. It clearly is an SELinux system - I see SELinux initializing during boot, it has an /selinux file system, files and processes have contexts, I get avc errors when I violate policy. What could be confusing seinfo and sesearch? # ls -lZ /etc/selinux/targeted/policy -rw-r--r-- root root system_u:object_r:policy_config_t policy.18 # rpm -qf /usr/bin/seinfo /usr/sbin/sestatus setools-1.5.1-5 policycoreutils-1.18.1-4.7 # rpm -V setools policycoreutils # Moray. "To err is human. To purr, feline." From domg472 at gmail.com Wed Dec 2 14:05:46 2009 From: domg472 at gmail.com (Dominick Grift) Date: Wed, 2 Dec 2009 15:05:46 +0100 Subject: Is this an selinux system? In-Reply-To: <000101ca7355$27379950$75a6cbf0$@Henderson@ict-software.org> References: <000101ca7355$27379950$75a6cbf0$@Henderson@ict-software.org> Message-ID: <20091202140545.GA3347@localhost.localdomain> On Wed, Dec 02, 2009 at 01:41:28PM +0000, Moray Henderson wrote: > I'm trying to solve a problem on an old EL4 box. > > /etc/sysconfig/selinux says: > SELINUX=enforcing > SELINUXTYPE=targeted > > sestatus says: > SELinux status: enabled > SELinuxfs mount: /selinux > Current mode: enforcing > Mode from config file: enforcing > Policy version: 18 > Policy from config file:targeted > > seinfo and sesearch say: > Default policy search failed: This is not an selinux system. > > It clearly is an SELinux system - I see SELinux initializing during > boot, it has an /selinux file system, files and processes have contexts, > I get avc errors when I violate policy. > > What could be confusing seinfo and sesearch? Might be related to the nature of the policy, which is monolithic. > > # ls -lZ /etc/selinux/targeted/policy > -rw-r--r-- root root system_u:object_r:policy_config_t > policy.18 > # rpm -qf /usr/bin/seinfo /usr/sbin/sestatus > setools-1.5.1-5 > policycoreutils-1.18.1-4.7 > # rpm -V setools policycoreutils > # > > > Moray. > "To err is human. To purr, feline." > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From gizmo at giz-works.com Wed Dec 2 17:46:15 2009 From: gizmo at giz-works.com (Chris Richards) Date: Wed, 02 Dec 2009 11:46:15 -0600 Subject: AVC Denials on UDEV In-Reply-To: <4B15A855.6030305@aoaforums.com> References: <4B152BD3.60109@giz-works.com> <4B153A8C.8050609@gmail.com> <4B15A4FD.5080508@giz-works.com> <4B15A855.6030305@aoaforums.com> Message-ID: <4B16A7E7.9070104@giz-works.com> On 12/01/2009 09:47 AM, Dominick Grift wrote: > On 12/01/2009 03:44 PM, Chris Richards wrote: >> First, my apologies if I'm in the wrong place or this has been asked >> before (I'm sure it has, but I haven't turned up anything with Google). >> >> I'm running a Gentoo system. This is a fresh build, so not everything >> is installed yet. Basically, I've got the stage 3 tarball, the Selinux >> stuff, syslog-ng and vixie-cron, and that's about it. >> >> When I boot my sysem, I'm getting the following messages in my kernel >> log: >> * Mounting /dev >> /etc/init.d/udev-mount: line 63: /dev/null: Permission denied >> /etc/init.d/udev: line 69: /dev/null: Permission denied >> * Starting udevd >> * Populating /dev with existing devices through uevents ... >> # Waiting for uevents to be processed ... >> error sending message: Permission denied >> error sending message: Permission denied >> udevadm[601]: errorsending message: Permission denied >> >> Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.208:3): >> avc: denied { read } for pid=1 comm="init" name="ld.so.cache" dev=sda3 >> ino=737384 scontext=system_u:system_r:init_t >> tcontext=system_u:object_r:file_t tclass=file >> Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.215:4): >> avc: denied { getattr } for pid=1 comm="init" path="/etc/ld.so.cache" >> dev=sda3 ino=737384 scontext=system_u:system_r:init_t >> tcontext=system_u:object_r:file_t tclass=file > looks like the file is mislabeled. what does matchpathcon > /etc/ld.so.cache say? > > make sure that your file system labeling is correct. > I've relabled like 15 times with rlpkg -a -r. LOL matchpathcon /etc/ld.so.cache /etc/ld.so.cache system_u:object_r:ld_so_cache_t ls -Z /etc/ld.so.cache root:object_r:ld_so_cache_t Based on the above, I did chcon -u system_u /etc/ld.so.cache That seems to have resolved the issues that were plaguing me there. >> The pattern of denials above repeats for a number of comm= types, >> including consoletype, dmesg, hwclock, hostname, ifconfig >> >> Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.221:5): >> avc: denied { read } for pid=1 comm="init" name="urandom" dev=sda3 >> ino=140683 scontext=system_u:system_r:init_t >> tcontext=system_u:object_r:urandom_device_t tclass=chr_file >> >> As above, I get a number of denials on different comm= types. >> >> >> I'm also seeing a buttload of these in my avc.log: >> Dec 1 13:48:41 aoaforums kernel: type=1400 >> audit(1259675321.237:1614490880): avc: denied { read } for pid=477 >> comm="udevd" path="anon_inode:[signalfd]" dev=anon_inodefs ino=9 >> scontext=system_u:system_r:udev_t >> tcontext=system_u:object_r:anon_inodefs_t tclass=file >> This one in particular is bad: my log is full to overflowing with this >> one, and when I'm in enforcing mode udevd is pulling 100% cpu. > If the types in this interaction are correct. Run the avc denial through > audit2why. If audit2why says "missing TE rule"; then consider adding > policy to allow it using audit2allow and semodule. > That's exactly what it says. When I do the following: # grep udev /var/log/avc.log > local # audit2allow -m local > local.te # checkmodule -M -m -o local.mod local.te checkmodule: loading policy configuration from local.te checkmodule: policy configuration loaded checkmodule: writing binary representation (version 8) to local.mod # semodule_package -o local.pp -m local.mod # semodule -i ./local.pp Everything goes fine up to the semodule -i command, and then I get: libsepol.link_modules: Tried to link in an MLS module with a non-MLS base. libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! Based on all the weird problems and heartburn I've had, I'm really starting to wonder if ANYONE in recent history has gotten a strict Selinux profile running in enforcing mode on hardened-gentoo according to the instructions in the Gentoo Selinux Handbook. Getting even to this point has been frustrating beyond belief. And before I give anyone the wrong impression, I really do appreciate the hard work that has gone into this; I'm just suffering from a steep learning curve, and documentation that I not only don't understand, but doesn't seem to correspond to my system when I DO understand it. >> Finally, a related question: >> Gentoo is currently running what is labeled as >> "selinux-base-policy-20080525". > That policy is old. See if you can implement some newer policy. > That's default gentoo-hardened policy. V2 policy horridly breaks a hardened gentoo system at this stage from what I understand (as in, it won't even boot). >> This seems to bear little resemblance to the policy and tools that I see >> discussed here: >> http://oss.tresys.com/projects/refpolicy/wiki/GettingStarted >> >> In particular, a lot of the booleans don't exist. As near as I can >> tell, this is pretty much the policy that was used in RHEL 4. However, >> I can find precious little in the way of documentation on the older >> policy setup. Can anyone provide any guidance on resources to look at >> for this? Referring me to the current base policy and tools really >> doesn't help me in understanding what my system is doing..... >> >> Many thanks in advance for any guidance you can offer. > Overall it is good to appreciate that SELinux is a framework and that > policy is configuration. The framework allows you to define policy. > > The process of adding policy is always on going. In my view no policy > will ever be perfect. There are simply to many variables. > > Learn how to implement policy, make security decisions and solve > interaction problems. > > Theres a few things to consider: > > 1. are the types in an interaction the expected types. (mislabeled > objects?) > 2. is there some tunable policy available to allow an interaction that > is currently denied? (audit2why) > 3. is a denial caused by misconfiguration of one of the parties in an > interaction? (check config of app) > 4. is a denial signalling an intrusion. (break in?) > 5. is a denials signalling a bug in one of the parties in an > interaction? (bug in app) > 6. is it a bug in selinux-policy( are rules to allow it missing?) > Thanks for your response and help. Later, Chris From domg472 at gmail.com Wed Dec 2 18:36:51 2009 From: domg472 at gmail.com (Dominick Grift) Date: Wed, 2 Dec 2009 19:36:51 +0100 Subject: AVC Denials on UDEV In-Reply-To: <4B16A7E7.9070104@giz-works.com> References: <4B152BD3.60109@giz-works.com> <4B153A8C.8050609@gmail.com> <4B15A4FD.5080508@giz-works.com> <4B15A855.6030305@aoaforums.com> <4B16A7E7.9070104@giz-works.com> Message-ID: <20091202183648.GB3347@localhost.localdomain> On Wed, Dec 02, 2009 at 11:46:15AM -0600, Chris Richards wrote: > On 12/01/2009 09:47 AM, Dominick Grift wrote: > >On 12/01/2009 03:44 PM, Chris Richards wrote: > >>First, my apologies if I'm in the wrong place or this has been asked > >>before (I'm sure it has, but I haven't turned up anything with Google). > >> > >>I'm running a Gentoo system. This is a fresh build, so not everything > >>is installed yet. Basically, I've got the stage 3 tarball, the Selinux > >>stuff, syslog-ng and vixie-cron, and that's about it. > >> > >>When I boot my sysem, I'm getting the following messages in my > >>kernel log: > >>* Mounting /dev > >>/etc/init.d/udev-mount: line 63: /dev/null: Permission denied > >>/etc/init.d/udev: line 69: /dev/null: Permission denied > >>* Starting udevd > >>* Populating /dev with existing devices through uevents ... > >># Waiting for uevents to be processed ... > >>error sending message: Permission denied > >>error sending message: Permission denied > >>udevadm[601]: errorsending message: Permission denied > >> > >>Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.208:3): > >>avc: denied { read } for pid=1 comm="init" name="ld.so.cache" dev=sda3 > >>ino=737384 scontext=system_u:system_r:init_t > >>tcontext=system_u:object_r:file_t tclass=file > >>Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.215:4): > >>avc: denied { getattr } for pid=1 comm="init" path="/etc/ld.so.cache" > >>dev=sda3 ino=737384 scontext=system_u:system_r:init_t > >>tcontext=system_u:object_r:file_t tclass=file > >looks like the file is mislabeled. what does matchpathcon > >/etc/ld.so.cache say? > > > >make sure that your file system labeling is correct. > > > I've relabled like 15 times with rlpkg -a -r. LOL > > matchpathcon /etc/ld.so.cache > /etc/ld.so.cache system_u:object_r:ld_so_cache_t > > ls -Z /etc/ld.so.cache > root:object_r:ld_so_cache_t > > Based on the above, I did > chcon -u system_u /etc/ld.so.cache The -u system_u isnt responsible for the denial. In the avc denials above the type for the file was etc_t. That was mislabeled because matchpatchcon said it should have been ld_so_cache_t. So i think restoration (relabeling) fixed it. > > That seems to have resolved the issues that were plaguing me there. > > >>The pattern of denials above repeats for a number of comm= types, > >>including consoletype, dmesg, hwclock, hostname, ifconfig > >> > >>Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.221:5): > >>avc: denied { read } for pid=1 comm="init" name="urandom" dev=sda3 > >>ino=140683 scontext=system_u:system_r:init_t > >>tcontext=system_u:object_r:urandom_device_t tclass=chr_file > >> > >>As above, I get a number of denials on different comm= types. > >> > >> > >>I'm also seeing a buttload of these in my avc.log: > >>Dec 1 13:48:41 aoaforums kernel: type=1400 > >>audit(1259675321.237:1614490880): avc: denied { read } for pid=477 > >>comm="udevd" path="anon_inode:[signalfd]" dev=anon_inodefs ino=9 > >>scontext=system_u:system_r:udev_t > >>tcontext=system_u:object_r:anon_inodefs_t tclass=file > >>This one in particular is bad: my log is full to overflowing with this > >>one, and when I'm in enforcing mode udevd is pulling 100% cpu. > >If the types in this interaction are correct. Run the avc denial through > >audit2why. If audit2why says "missing TE rule"; then consider adding > >policy to allow it using audit2allow and semodule. > > > That's exactly what it says. > > When I do the following: > # grep udev /var/log/avc.log > local > # audit2allow -m local > local.te > # checkmodule -M -m -o local.mod local.te > checkmodule: loading policy configuration from local.te > checkmodule: policy configuration loaded > checkmodule: writing binary representation (version 8) to local.mod > # semodule_package -o local.pp -m local.mod > # semodule -i ./local.pp > > Everything goes fine up to the semodule -i command, and then I get: The checkmodule command has some bugs i think. in fedora we use the make file: make -f /usr/share/selinux/devel/Makefile myudevfix.pp semodule -i myudevfix.pp > > libsepol.link_modules: Tried to link in an MLS module with a non-MLS base. > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! > > Based on all the weird problems and heartburn I've had, I'm really > starting to wonder if ANYONE in recent history has gotten a strict > Selinux profile running in enforcing mode on hardened-gentoo > according to the instructions in the Gentoo Selinux Handbook. > Getting even to this point has been frustrating beyond belief. Well i have seen some people who have it in the #selinux irc chan, but i think they used newer policy. > > And before I give anyone the wrong impression, I really do > appreciate the hard work that has gone into this; I'm just suffering > from a steep learning curve, and documentation that I not only don't > understand, but doesn't seem to correspond to my system when I DO > understand it. Well there are certainly some basics one needs to be familair with , with regard to policy, but when you have that its pretty easy. SELinux is a framework that lets one define types and assign these types to subjects and objects in a system. The framework also lets on define policy that governs how types can interact with eashother. To make this possible, the kernel provides classes and permission. if you put that together you get something like this: allow subjecttype_t objecttype_t:objectclass permissions; then theres the concept of (subject and object) type transitions. ( go from one type to another type ) Those are the basics of type enforcement. Then youll alsoo need to get familair with how policy is structured upstream (they have some guidelines that make maintenance easier) Then get to know the tools, and youre halfway there. > > >>Finally, a related question: > >>Gentoo is currently running what is labeled as > >>"selinux-base-policy-20080525". > >That policy is old. See if you can implement some newer policy. > > > That's default gentoo-hardened policy. V2 policy horridly breaks a > hardened gentoo system at this stage from what I understand (as in, > it won't even boot). > > >>This seems to bear little resemblance to the policy and tools that I see > >>discussed here: > >>http://oss.tresys.com/projects/refpolicy/wiki/GettingStarted > >> > >>In particular, a lot of the booleans don't exist. As near as I can > >>tell, this is pretty much the policy that was used in RHEL 4. However, > >>I can find precious little in the way of documentation on the older > >>policy setup. Can anyone provide any guidance on resources to look at > >>for this? Referring me to the current base policy and tools really > >>doesn't help me in understanding what my system is doing..... > >> > >>Many thanks in advance for any guidance you can offer. > >Overall it is good to appreciate that SELinux is a framework and that > >policy is configuration. The framework allows you to define policy. > > > >The process of adding policy is always on going. In my view no policy > >will ever be perfect. There are simply to many variables. > > > >Learn how to implement policy, make security decisions and solve > >interaction problems. > > > >Theres a few things to consider: > > > >1. are the types in an interaction the expected types. (mislabeled > >objects?) > >2. is there some tunable policy available to allow an interaction that > >is currently denied? (audit2why) > >3. is a denial caused by misconfiguration of one of the parties in an > >interaction? (check config of app) > >4. is a denial signalling an intrusion. (break in?) > >5. is a denials signalling a bug in one of the parties in an > >interaction? (bug in app) > >6. is it a bug in selinux-policy( are rules to allow it missing?) > > > > Thanks for your response and help. > > Later, > Chris > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dwalsh at redhat.com Wed Dec 2 20:09:00 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 02 Dec 2009 15:09:00 -0500 Subject: Is this an selinux system? In-Reply-To: <000101ca7355$27379950$75a6cbf0$@Henderson@ict-software.org> References: <000101ca7355$27379950$75a6cbf0$@Henderson@ict-software.org> Message-ID: <4B16C95C.3090309@redhat.com> On 12/02/2009 08:41 AM, Moray Henderson wrote: > I'm trying to solve a problem on an old EL4 box. > > /etc/sysconfig/selinux says: > SELINUX=enforcing > SELINUXTYPE=targeted > > sestatus says: > SELinux status: enabled > SELinuxfs mount: /selinux > Current mode: enforcing > Mode from config file: enforcing > Policy version: 18 > Policy from config file:targeted > > seinfo and sesearch say: > Default policy search failed: This is not an selinux system. > > It clearly is an SELinux system - I see SELinux initializing during > boot, it has an /selinux file system, files and processes have contexts, > I get avc errors when I violate policy. > > What could be confusing seinfo and sesearch? > > # ls -lZ /etc/selinux/targeted/policy > -rw-r--r-- root root system_u:object_r:policy_config_t > policy.18 > # rpm -qf /usr/bin/seinfo /usr/sbin/sestatus > setools-1.5.1-5 > policycoreutils-1.18.1-4.7 > # rpm -V setools policycoreutils > # > > > Moray. > "To err is human. To purr, feline." > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > It might be a version mismatch between seinfo and sesearch and the RHEL4 policy that is confusing it. From roland at astrofoto.org Wed Dec 2 20:22:34 2009 From: roland at astrofoto.org (Roland Roberts) Date: Wed, 02 Dec 2009 15:22:34 -0500 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B13239B.7060708@astrofoto.org> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org> <4B1248EC.2060403@penguinpee.nl> <4B13239B.7060708@astrofoto.org> Message-ID: <4B16CC8A.4070104@astrofoto.org> On 11/29/2009 08:44 PM, Roland Roberts wrote: > On 11/29/2009 05:11 AM, Sandro Janke wrote: >> Actually, you don't need to have any of the setroubleshoot packages >> installed to get AVC messages logged. What you need is auditd running >> and it will log AVC messages to /var/log/audit/audit.log >> >> With setroubleshoot-server installed you can watch the logged >> messages using: >> >> # sealert -a /var/log/audit/audit.log >> >> The output will be long and in the style of setroubleshoot browser, >> so take your measures. >> >> Another tool - from the audit package - that can prove very useful is >> ausearch. It will search the audit logs for messages matching the >> given criteria. > > But I'm not getting any messages there. And changing enforcing mode > fixes the problem, so it seems like it has to be SELinux, but with no > log, I can't figure out what rule needs to be changed. > > At the suggestion of Daniel Walsh, I ran semodule -DB then restarted dovecot and got my messages. I've used those to create policy, but can't load it. I've configured dovecot to use a local socket connection to postgres. Here is what I for SELinux: grep 'Dec 2.*dovecot-auth' /var/log/messages| audit2allow -m local > local.te 328 root> cat local.te module local 1.0; require { type dovecot_auth_t; type unlabeled_t; type postgresql_tmp_t; class sock_file write; class unix_stream_socket read; } #============= dovecot_auth_t ============== allow dovecot_auth_t postgresql_tmp_t:sock_file write; #============= unlabeled_t ============== allow unlabeled_t self:unix_stream_socket read; 329 root> make -f /usr/share/selinux/devel/Makefile local.pp Compiling targeted local module /usr/bin/checkmodule: loading policy configuration from tmp/local.tmp /usr/bin/checkmodule: policy configuration loaded /usr/bin/checkmodule: writing binary representation (version 10) to tmp/local.mod Creating targeted local.pp policy package rm tmp/local.mod.fc tmp/local.mod 330 root> semodule -i local.pp libsepol.print_missing_requirements: local's global requirements were not met: type/attribute dovecot_auth_t libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! I'm at a loss on what to do here. Suggestions on why it would tell me this? roland -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhD RL Enterprises roland at rlenter.com 6818 Madeline Court roland at astrofoto.org Brooklyn, NY 11220 From bandan.das at stratus.com Wed Dec 2 20:44:50 2009 From: bandan.das at stratus.com (Bandan Das) Date: Wed, 02 Dec 2009 15:44:50 -0500 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: 4B16CC8A.4070104@astrofoto.org References: <4B11FA2C.8040000@astrofoto.org><4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org><4B1248EC.2060403@penguinpee.nl> <4B13239B.7060708@astrofoto.org> 4B16CC8A.4070104@astrofoto.org Message-ID: <1259786690.2082.31.camel@aqua.mno.stratus.com> On Wed, 2009-12-02 at 15:22 -0500, Roland Roberts wrote: > On 11/29/2009 08:44 PM, Roland Roberts wrote: > > On 11/29/2009 05:11 AM, Sandro Janke wrote: > >> Actually, you don't need to have any of the setroubleshoot packages > > >> installed to get AVC messages logged. What you need is auditd > running > >> and it will log AVC messages to /var/log/audit/audit.log > >> > >> With setroubleshoot-server installed you can watch the logged > >> messages using: > >> > >> # sealert -a /var/log/audit/audit.log > >> > >> The output will be long and in the style of setroubleshoot browser, > > >> so take your measures. > >> > >> Another tool - from the audit package - that can prove very useful > is > >> ausearch. It will search the audit logs for messages matching the > >> given criteria. > > > > But I'm not getting any messages there. And changing enforcing mode > > > fixes the problem, so it seems like it has to be SELinux, but with > no > > log, I can't figure out what rule needs to be changed. > > > > > > At the suggestion of Daniel Walsh, I ran > > semodule -DB > > then restarted dovecot and got my messages. I've used those to > create > policy, but can't load it. > > I've configured dovecot to use a local socket connection to postgres. > > Here is what I for SELinux: > > grep 'Dec 2.*dovecot-auth' /var/log/messages| audit2allow -m local > > local.te > 328 root> cat local.te > > module local 1.0; > > require { > type dovecot_auth_t; > type unlabeled_t; > type postgresql_tmp_t; > class sock_file write; > class unix_stream_socket read; > } > > #============= dovecot_auth_t ============== > allow dovecot_auth_t postgresql_tmp_t:sock_file write; > > #============= unlabeled_t ============== > allow unlabeled_t self:unix_stream_socket read; > 329 root> make -f /usr/share/selinux/devel/Makefile local.pp > Compiling targeted local module > /usr/bin/checkmodule: loading policy configuration from tmp/local.tmp > /usr/bin/checkmodule: policy configuration loaded > /usr/bin/checkmodule: writing binary representation (version 10) to > tmp/local.mod > Creating targeted local.pp policy package > rm tmp/local.mod.fc tmp/local.mod > 330 root> semodule -i local.pp > libsepol.print_missing_requirements: local's global requirements were > not met: type/attribute dovecot_auth_t > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! > > I'm at a loss on what to do here. Suggestions on why it would tell me > this? I guess dovecot_auth_t should have been defined in dovecot.te. Are you sure you have dovecot.pp loaded ? > roland > From dwalsh at redhat.com Wed Dec 2 21:37:19 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 02 Dec 2009 16:37:19 -0500 Subject: SELinux won't let dovecot connect to postgresql In-Reply-To: <4B16CC8A.4070104@astrofoto.org> References: <4B11FA2C.8040000@astrofoto.org> <4B120280.40406@nybeta.com> <4B1206B3.5050304@astrofoto.org> <4B1248EC.2060403@penguinpee.nl> <4B13239B.7060708@astrofoto.org> <4B16CC8A.4070104@astrofoto.org> Message-ID: <4B16DE0F.2070803@redhat.com> On 12/02/2009 03:22 PM, Roland Roberts wrote: > On 11/29/2009 08:44 PM, Roland Roberts wrote: >> On 11/29/2009 05:11 AM, Sandro Janke wrote: >>> Actually, you don't need to have any of the setroubleshoot packages >>> installed to get AVC messages logged. What you need is auditd running >>> and it will log AVC messages to /var/log/audit/audit.log >>> >>> With setroubleshoot-server installed you can watch the logged >>> messages using: >>> >>> # sealert -a /var/log/audit/audit.log >>> >>> The output will be long and in the style of setroubleshoot browser, >>> so take your measures. >>> >>> Another tool - from the audit package - that can prove very useful is >>> ausearch. It will search the audit logs for messages matching the >>> given criteria. >> >> But I'm not getting any messages there. And changing enforcing mode >> fixes the problem, so it seems like it has to be SELinux, but with no >> log, I can't figure out what rule needs to be changed. >> >> > > At the suggestion of Daniel Walsh, I ran > > semodule -DB > > then restarted dovecot and got my messages. I've used those to create > policy, but can't load it. > > I've configured dovecot to use a local socket connection to postgres. > Here is what I for SELinux: > > grep 'Dec 2.*dovecot-auth' /var/log/messages| audit2allow -m local > > local.te > 328 root> cat local.te > > module local 1.0; > > require { > type dovecot_auth_t; > type unlabeled_t; > type postgresql_tmp_t; > class sock_file write; > class unix_stream_socket read; > } > > #============= dovecot_auth_t ============== > allow dovecot_auth_t postgresql_tmp_t:sock_file write; > > #============= unlabeled_t ============== > allow unlabeled_t self:unix_stream_socket read; > 329 root> make -f /usr/share/selinux/devel/Makefile local.pp > Compiling targeted local module > /usr/bin/checkmodule: loading policy configuration from tmp/local.tmp > /usr/bin/checkmodule: policy configuration loaded > /usr/bin/checkmodule: writing binary representation (version 10) to > tmp/local.mod > Creating targeted local.pp policy package > rm tmp/local.mod.fc tmp/local.mod > 330 root> semodule -i local.pp > libsepol.print_missing_requirements: local's global requirements were > not met: type/attribute dovecot_auth_t > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! > > I'm at a loss on what to do here. Suggestions on why it would tell me > this? > > roland > Did you replace the dovecot.pp when you first tried this? From gizmo at giz-works.com Wed Dec 2 23:13:41 2009 From: gizmo at giz-works.com (Chris Richards) Date: Wed, 02 Dec 2009 17:13:41 -0600 Subject: AVC Denials on UDEV In-Reply-To: <20091202183648.GB3347@localhost.localdomain> References: <4B152BD3.60109@giz-works.com> <4B153A8C.8050609@gmail.com> <4B15A4FD.5080508@giz-works.com> <4B15A855.6030305@aoaforums.com> <4B16A7E7.9070104@giz-works.com> <20091202183648.GB3347@localhost.localdomain> Message-ID: <4B16F4A5.8030903@giz-works.com> On 12/02/2009 12:36 PM, Dominick Grift wrote: >>>> Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.208:3): >>>> avc: denied { read } for pid=1 comm="init" name="ld.so.cache" dev=sda3 >>>> ino=737384 scontext=system_u:system_r:init_t >>>> tcontext=system_u:object_r:file_t tclass=file >>>> Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.215:4): >>>> avc: denied { getattr } for pid=1 comm="init" path="/etc/ld.so.cache" >>>> dev=sda3 ino=737384 scontext=system_u:system_r:init_t >>>> tcontext=system_u:object_r:file_t tclass=file >>>> >>> looks like the file is mislabeled. what does matchpathcon >>> /etc/ld.so.cache say? >>> >>> make sure that your file system labeling is correct. >>> >>> >> I've relabled like 15 times with rlpkg -a -r. LOL >> >> matchpathcon /etc/ld.so.cache >> /etc/ld.so.cache system_u:object_r:ld_so_cache_t >> >> ls -Z /etc/ld.so.cache >> root:object_r:ld_so_cache_t >> >> Based on the above, I did >> chcon -u system_u /etc/ld.so.cache >> > The -u system_u isnt responsible for the denial. In the avc denials above the type for the file was etc_t. That was mislabeled because matchpatchcon said it should have been ld_so_cache_t. So i think restoration (relabeling) fixed it. > Eh? I'm not understanding something: I thought the source context was init_t and that target was file_t? Now I'm really confused again. In any case, I didn't relabel, all I did for that one was the chcon mentioned above, and the error no longer exists. Again, I'm really confused. >> When I do the following: >> # grep udev /var/log/avc.log> local >> # audit2allow -m local> local.te >> # checkmodule -M -m -o local.mod local.te >> checkmodule: loading policy configuration from local.te >> checkmodule: policy configuration loaded >> checkmodule: writing binary representation (version 8) to local.mod >> # semodule_package -o local.pp -m local.mod >> # semodule -i ./local.pp >> >> Everything goes fine up to the semodule -i command, and then I get: >> > The checkmodule command has some bugs i think. > in fedora we use the make file: > > make -f /usr/share/selinux/devel/Makefile myudevfix.pp > semodule -i myudevfix.pp > That would be wonderful, except that I don't have the make file. I don't even have the source files. Gentoo policy is distributed as binaries only, to the best of my knowledge. >> libsepol.link_modules: Tried to link in an MLS module with a non-MLS base. >> libsemanage.semanage_link_sandbox: Link packages failed >> semodule: Failed! >> >> Based on all the weird problems and heartburn I've had, I'm really >> starting to wonder if ANYONE in recent history has gotten a strict >> Selinux profile running in enforcing mode on hardened-gentoo >> according to the instructions in the Gentoo Selinux Handbook. >> Getting even to this point has been frustrating beyond belief. >> > Well i have seen some people who have it in the #selinux irc chan, but i think they used newer policy. > > >> And before I give anyone the wrong impression, I really do >> appreciate the hard work that has gone into this; I'm just suffering >> from a steep learning curve, and documentation that I not only don't >> understand, but doesn't seem to correspond to my system when I DO >> understand it. >> > Well there are certainly some basics one needs to be familair with , with regard to policy, but when you have that its pretty easy. > > That's possible. There's a v2refpolicy profile in the Portage tree, but the Gentoo Selinux Handbook specifically says to ONLY use the Portage profile I'm using right now. Perhaps I need to see if I can pick Christopher PeBenito's brain, as I gather he has some involvement both in the SELinux community and the Gentoo community. > SELinux is a framework that lets one define types and assign these types to subjects and objects in a system. The framework also lets on define policy that governs how types can interact with eashother. To make this possible, the kernel provides classes and permission. if you put that together you get something like this: > > allow subjecttype_t objecttype_t:objectclass permissions; > > then theres the concept of (subject and object) type transitions. ( go from one type to another type ) > > Those are the basics of type enforcement. Then youll alsoo need to get familair with how policy is structured upstream (they have some guidelines that make maintenance easier) > > Then get to know the tools, and youre halfway there. > Ah, but therein seems to lie the rub for me: near as I can tell, there were some major changes made in how the policy is written somewhere around the late May/early June timeframe. All of the documentation that I can find refers to the new framework, whereas the policy I'm using appears to be based on the old framework. As a consequence, just about the time I think I'm starting to get a handle on what works how, I run into something that doesn't correspond to what the SELinux docs are telling me. A good is example is refpolicy itself: the policy explained at the tresys site: http://oss.tresys.com/projects/refpolicy/wiki/UseRefpolicy Seems to be rather well thought ought, and reasonably logical and orthoginal. It also seems to bear little resemblance to what I'm using. The instructions for the tools that I come across seem to mostly reference things that don't even exist for me, or if they did exist would be absolutely useless to me because they are GUI tools, and my systems don't even have X installed. I realize that a good deal of this is almost certainly due to the fact that I'm on Gentoo. I'd much rather be part of the solution than part of the problem, so I want to get to where I can start helping with Gentoo's SELinux implementation, but I'm so blasted confused I don't even rightly know how to start. As I've said previously, Gentoo SEEMS to be using policy and tools from RHEL 4's incarnation of SELinux. That's all well and good, EXCEPT that the documentation describing the policies and tools seems to have gone wandering, so those of use poor schmucks stuck schlepping through the muck of the previous generation's tools have no clue where we are or where we are going, and since I don't even have the source for the policies that I AM using, I'm stuck with my finger up my nose going "Whuh?" And now, I think I've done enough whining for one day. ;) Once again, thanks for your time. Later, Chris From domg472 at gmail.com Wed Dec 2 23:21:02 2009 From: domg472 at gmail.com (Dominick Grift) Date: Thu, 3 Dec 2009 00:21:02 +0100 Subject: AVC Denials on UDEV In-Reply-To: <4B16F4A5.8030903@giz-works.com> References: <4B152BD3.60109@giz-works.com> <4B153A8C.8050609@gmail.com> <4B15A4FD.5080508@giz-works.com> <4B15A855.6030305@aoaforums.com> <4B16A7E7.9070104@giz-works.com> <20091202183648.GB3347@localhost.localdomain> <4B16F4A5.8030903@giz-works.com> Message-ID: <20091202232101.GC3347@localhost.localdomain> On Wed, Dec 02, 2009 at 05:13:41PM -0600, Chris Richards wrote: > On 12/02/2009 12:36 PM, Dominick Grift wrote: > >>>>Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.208:3): > >>>>avc: denied { read } for pid=1 comm="init" name="ld.so.cache" dev=sda3 > >>>>ino=737384 scontext=system_u:system_r:init_t > >>>>tcontext=system_u:object_r:file_t tclass=file > >>>>Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.215:4): > >>>>avc: denied { getattr } for pid=1 comm="init" path="/etc/ld.so.cache" > >>>>dev=sda3 ino=737384 scontext=system_u:system_r:init_t > >>>>tcontext=system_u:object_r:file_t tclass=file > >>>looks like the file is mislabeled. what does matchpathcon > >>>/etc/ld.so.cache say? > >>> > >>>make sure that your file system labeling is correct. > >>> > >>I've relabled like 15 times with rlpkg -a -r. LOL > >> > >>matchpathcon /etc/ld.so.cache > >>/etc/ld.so.cache system_u:object_r:ld_so_cache_t > >> > >>ls -Z /etc/ld.so.cache > >>root:object_r:ld_so_cache_t > >> > >>Based on the above, I did > >>chcon -u system_u /etc/ld.so.cache > >The -u system_u isnt responsible for the denial. In the avc denials above the type for the file was etc_t. That was mislabeled because matchpatchcon said it should have been ld_so_cache_t. So i think restoration (relabeling) fixed it. > Eh? I'm not understanding something: I thought the source context > was init_t and that target was file_t? Now I'm really confused > again. Yes sorry i meant to say file_t. > > In any case, I didn't relabel, all I did for that one was the chcon > mentioned above, and the error no longer exists. Again, I'm really > confused. whatever happend the type changed and thats what counts. > >>When I do the following: > >># grep udev /var/log/avc.log> local > >># audit2allow -m local> local.te > >># checkmodule -M -m -o local.mod local.te > >>checkmodule: loading policy configuration from local.te > >>checkmodule: policy configuration loaded > >>checkmodule: writing binary representation (version 8) to local.mod > >># semodule_package -o local.pp -m local.mod > >># semodule -i ./local.pp > >> > >>Everything goes fine up to the semodule -i command, and then I get: > >The checkmodule command has some bugs i think. > >in fedora we use the make file: > > > >make -f /usr/share/selinux/devel/Makefile myudevfix.pp > >semodule -i myudevfix.pp > That would be wonderful, except that I don't have the make file. I > don't even have the source files. Gentoo policy is distributed as > binaries only, to the best of my knowledge. > > >>libsepol.link_modules: Tried to link in an MLS module with a non-MLS base. > >>libsemanage.semanage_link_sandbox: Link packages failed > >>semodule: Failed! > >> > >>Based on all the weird problems and heartburn I've had, I'm really > >>starting to wonder if ANYONE in recent history has gotten a strict > >>Selinux profile running in enforcing mode on hardened-gentoo > >>according to the instructions in the Gentoo Selinux Handbook. > >>Getting even to this point has been frustrating beyond belief. > >Well i have seen some people who have it in the #selinux irc chan, but i think they used newer policy. > > > >>And before I give anyone the wrong impression, I really do > >>appreciate the hard work that has gone into this; I'm just suffering > >>from a steep learning curve, and documentation that I not only don't > >>understand, but doesn't seem to correspond to my system when I DO > >>understand it. > >Well there are certainly some basics one needs to be familair with , with regard to policy, but when you have that its pretty easy. > > > That's possible. There's a v2refpolicy profile in the Portage tree, > but the Gentoo Selinux Handbook specifically says to ONLY use the > Portage profile I'm using right now. Perhaps I need to see if I can > pick Christopher PeBenito's brain, as I gather he has some > involvement both in the SELinux community and the Gentoo community. Yes he is both maintainer for gentoo selinux policy as well as upstream tresys refpolicy > > >SELinux is a framework that lets one define types and assign these types to subjects and objects in a system. The framework also lets on define policy that governs how types can interact with eashother. To make this possible, the kernel provides classes and permission. if you put that together you get something like this: > > > >allow subjecttype_t objecttype_t:objectclass permissions; > > > >then theres the concept of (subject and object) type transitions. ( go from one type to another type ) > > > >Those are the basics of type enforcement. Then youll alsoo need to get familair with how policy is structured upstream (they have some guidelines that make maintenance easier) > > > >Then get to know the tools, and youre halfway there. > Ah, but therein seems to lie the rub for me: near as I can tell, > there were some major changes made in how the policy is written > somewhere around the late May/early June timeframe. All of the > documentation that I can find refers to the new framework, whereas > the policy I'm using appears to be based on the old framework. As a > consequence, just about the time I think I'm starting to get a > handle on what works how, I run into something that doesn't > correspond to what the SELinux docs are telling me. > > A good is example is refpolicy itself: the policy explained at the > tresys site: > > http://oss.tresys.com/projects/refpolicy/wiki/UseRefpolicy > > Seems to be rather well thought ought, and reasonably logical and > orthoginal. It also seems to bear little resemblance to what I'm > using. The instructions for the tools that I come across seem to > mostly reference things that don't even exist for me, or if they did > exist would be absolutely useless to me because they are GUI tools, > and my systems don't even have X installed. As far is a know the structure is pretty much the same > > I realize that a good deal of this is almost certainly due to the > fact that I'm on Gentoo. I'd much rather be part of the solution > than part of the problem, so I want to get to where I can start > helping with Gentoo's SELinux implementation, but I'm so blasted > confused I don't even rightly know how to start. > > As I've said previously, Gentoo SEEMS to be using policy and tools > from RHEL 4's incarnation of SELinux. That's all well and good, > EXCEPT that the documentation describing the policies and tools > seems to have gone wandering, so those of use poor schmucks stuck > schlepping through the muck of the previous generation's tools have > no clue where we are or where we are going, and since I don't even > have the source for the policies that I AM using, I'm stuck with my > finger up my nose going "Whuh?" Well i am not sure but it is unlikely like El4. Any open source project should make the source available so it should be somewhere.. > And now, I think I've done enough whining for one day. ;) > > Once again, thanks for your time. > > Later, > Chris > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From roland at astrofoto.org Wed Dec 2 23:57:51 2009 From: roland at astrofoto.org (Roland Roberts) Date: Wed, 02 Dec 2009 18:57:51 -0500 Subject: SELinux won't let dovecot connect to postgresql (SOLVED!) In-Reply-To: <4B11FA2C.8040000@astrofoto.org> References: <4B11FA2C.8040000@astrofoto.org> Message-ID: <4B16FEFF.1070103@astrofoto.org> Roland Roberts wrote: > I'm running Fedora 11 x86_64 with the dovecot and dovecot-pgsql RPMs > installed. I have a small user database set up for email authentication. > The issue I'm having is that when I am in enforcing mode, dovecot > can't connect to the database. Turning off enforcing mode lets it > work. I'm having trouble diagnosing where the denial is taking place > as I don't see any avc messages in /var/log/messages that relate to > dovecot. The only messages I'm getting are in /var/log/maillog from > dovecot like this: > > Nov 28 22:23:11 fred dovecot: auth(default): pgsql: Connect failed to > maildb: could not connect to server: Permission denied > Nov 28 22:23:11 fred dovecot: auth(default): #011Is the server running > on host "fred.flinstone.org" and accepting > Nov 28 22:23:11 fred dovecot: auth(default): #011TCP/IP connections on > port 5432? > > The answer to the questions is "yes" it is running and accepting > connections. Whether or not enforcing mode is on, when logged in, I > can connect to the database via > > $ psql -h fred.flinstone.org maildb > > I *think* this is a result of updating on Nov 18. I have not changed > the default selinux mode since the host was set up back in September. > At that point, I set it to enforcing mode after working out a few > issues. On Nov 18, a lot of things were updated, but among there were > > Nov 18 10:00:02 Updated: kernel-firmware-2.6.30.9-96.fc11.noarch > Nov 18 10:00:15 Updated: kernel-headers-2.6.30.9-96.fc11.x86_64 > Nov 18 10:00:28 Installed: kernel-devel-2.6.30.9-96.fc11.x86_64 > Nov 18 10:01:30 Installed: kernel-2.6.30.9-96.fc11.x86_64 > Nov 18 10:02:01 Updated: selinux-policy-3.6.12-86.fc11.noarch > Nov 18 10:02:46 Updated: selinux-policy-targeted-3.6.12-86.fc11.noarch > > Today, I did another update, hoping it would cure the problem and got > these revisions > > Nov 28 10:57:33 Updated: selinux-policy-3.6.12-88.fc11.noarch > Nov 28 10:57:47 Updated: selinux-policy-targeted-3.6.12-88.fc11.noarch > > but the behavior is unchanged, I still have to turn off enforcing mode. > > Any clues on what I need to do to get this to work? Or where to look > for clues since, as I mentioned, I can't even find log entries that > would clue me in. > > roland Okay, here's what I finally ended up with that have me running in enforcing mode. I have both dovecot and exim using PostgreSQL for authentication. I had originally had them connecting via tcp, but changed them to use the unix domain socket. The policies below allow either. I also ran into a problem with httpd needing access to PostgreSQL since I'm running Drupal with PostgreSQL as the backend. And I have SquirrelMail running so httpd needs access to the imap/pop port. I don't think this is complete as I'm using the tcp port for PostgreSQL and the policy only allows that, not the unix domain socket (which I should probably configure instead). But at least I can now run in enforcing mode. 365 root> cat *.te module dovecotauthfixes 1.0; require { type dovecot_auth_t; type postgresql_port_t; type postgresql_tmp_t; type postgresql_t; class sock_file write; class tcp_socket name_connect; class unix_stream_socket connectto; } #============= dovecot_auth_t ============== allow dovecot_auth_t postgresql_port_t:tcp_socket name_connect; allow dovecot_auth_t postgresql_t:unix_stream_socket connectto; allow dovecot_auth_t postgresql_tmp_t:sock_file write; module eximfixes 1.0; require { type postgresql_tmp_t; type exim_t; type postgresql_t; class sock_file write; class unix_stream_socket connectto; } #============= exim_t ============== allow exim_t postgresql_t:unix_stream_socket connectto; allow exim_t postgresql_tmp_t:sock_file write; module httpdfixes 1.0; require { type postgresql_port_t; type httpd_t; type pop_port_t; class tcp_socket { name_bind name_connect }; } #============= httpd_t ============== allow httpd_t pop_port_t:tcp_socket { name_bind name_connect }; allow httpd_t postgresql_port_t:tcp_socket name_connect; roland -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhD RL Enterprises roland at rlenter.com 6818 Madeline Court roland at astrofoto.org Brooklyn, NY 11220 From justinmattock at gmail.com Thu Dec 3 01:00:18 2009 From: justinmattock at gmail.com (Justin P. Mattock) Date: Wed, 02 Dec 2009 17:00:18 -0800 Subject: SELinux won't let dovecot connect to postgresql (SOLVED!) In-Reply-To: <4B16FEFF.1070103@astrofoto.org> References: <4B11FA2C.8040000@astrofoto.org> <4B16FEFF.1070103@astrofoto.org> Message-ID: <4B170DA2.4050907@gmail.com> On 12/02/09 15:57, Roland Roberts wrote: > Roland Roberts wrote: >> I'm running Fedora 11 x86_64 with the dovecot and dovecot-pgsql RPMs >> installed. I have a small user database set up for email authentication. >> The issue I'm having is that when I am in enforcing mode, dovecot >> can't connect to the database. Turning off enforcing mode lets it >> work. I'm having trouble diagnosing where the denial is taking place >> as I don't see any avc messages in /var/log/messages that relate to >> dovecot. The only messages I'm getting are in /var/log/maillog from >> dovecot like this: >> >> Nov 28 22:23:11 fred dovecot: auth(default): pgsql: Connect failed to >> maildb: could not connect to server: Permission denied >> Nov 28 22:23:11 fred dovecot: auth(default): #011Is the server running >> on host "fred.flinstone.org" and accepting >> Nov 28 22:23:11 fred dovecot: auth(default): #011TCP/IP connections on >> port 5432? >> >> The answer to the questions is "yes" it is running and accepting >> connections. Whether or not enforcing mode is on, when logged in, I >> can connect to the database via >> >> $ psql -h fred.flinstone.org maildb >> >> I *think* this is a result of updating on Nov 18. I have not changed >> the default selinux mode since the host was set up back in September. >> At that point, I set it to enforcing mode after working out a few >> issues. On Nov 18, a lot of things were updated, but among there were >> >> Nov 18 10:00:02 Updated: kernel-firmware-2.6.30.9-96.fc11.noarch >> Nov 18 10:00:15 Updated: kernel-headers-2.6.30.9-96.fc11.x86_64 >> Nov 18 10:00:28 Installed: kernel-devel-2.6.30.9-96.fc11.x86_64 >> Nov 18 10:01:30 Installed: kernel-2.6.30.9-96.fc11.x86_64 >> Nov 18 10:02:01 Updated: selinux-policy-3.6.12-86.fc11.noarch >> Nov 18 10:02:46 Updated: selinux-policy-targeted-3.6.12-86.fc11.noarch >> >> Today, I did another update, hoping it would cure the problem and got >> these revisions >> >> Nov 28 10:57:33 Updated: selinux-policy-3.6.12-88.fc11.noarch >> Nov 28 10:57:47 Updated: selinux-policy-targeted-3.6.12-88.fc11.noarch >> >> but the behavior is unchanged, I still have to turn off enforcing mode. >> >> Any clues on what I need to do to get this to work? Or where to look >> for clues since, as I mentioned, I can't even find log entries that >> would clue me in. >> >> roland > > Okay, here's what I finally ended up with that have me running in > enforcing mode. I have both dovecot and exim using PostgreSQL for > authentication. I had originally had them connecting via tcp, but > changed them to use the unix domain socket. The policies below allow > either. > > I also ran into a problem with httpd needing access to PostgreSQL since > I'm running Drupal with PostgreSQL as the backend. And I have > SquirrelMail running so httpd needs access to the imap/pop port. I don't > think this is complete as I'm using the tcp port for PostgreSQL and the > policy only allows that, not the unix domain socket (which I should > probably configure instead). But at least I can now run in enforcing mode. > > 365 root> cat *.te > > module dovecotauthfixes 1.0; > > require { > type dovecot_auth_t; > type postgresql_port_t; > type postgresql_tmp_t; > type postgresql_t; > class sock_file write; > class tcp_socket name_connect; > class unix_stream_socket connectto; > } > > #============= dovecot_auth_t ============== > allow dovecot_auth_t postgresql_port_t:tcp_socket name_connect; > allow dovecot_auth_t postgresql_t:unix_stream_socket connectto; > allow dovecot_auth_t postgresql_tmp_t:sock_file write; > > module eximfixes 1.0; > > require { > type postgresql_tmp_t; > type exim_t; > type postgresql_t; > class sock_file write; > class unix_stream_socket connectto; > } > > #============= exim_t ============== > allow exim_t postgresql_t:unix_stream_socket connectto; > allow exim_t postgresql_tmp_t:sock_file write; > > module httpdfixes 1.0; > > require { > type postgresql_port_t; > type httpd_t; > type pop_port_t; > class tcp_socket { name_bind name_connect }; > } > > #============= httpd_t ============== > allow httpd_t pop_port_t:tcp_socket { name_bind name_connect }; > allow httpd_t postgresql_port_t:tcp_socket name_connect; > > roland > cool, so your up and running.. Justin P. Mattock From phangbyte at gmail.com Thu Dec 3 03:22:03 2009 From: phangbyte at gmail.com (Tyler Durvik) Date: Wed, 2 Dec 2009 22:22:03 -0500 Subject: Tutorial on setting up SELinux / X Server Message-ID: Greetings, I am looking for a tutorial, or instructions, on how to set up an X Server to work with SELinux. I have fedora 12 installed and ready to go. Does anyone have links/pages to where I may find this information? Thanks From dhighley at highley-recommended.com Thu Dec 3 05:33:02 2009 From: dhighley at highley-recommended.com (David Highley) Date: Wed, 2 Dec 2009 21:33:02 -0800 (PST) Subject: Fedora 12 and unconfined_u sshdfilter Message-ID: <200912030533.nB35X2Mh005401@douglas.highley-recommended.com> I'm trying to get sshdfilter a Perl wrapper around sshd to work in Fedora 12. The script needs to be able to call iptables to drop in new rejection rules detected hacking connections. I used "semanage fcontext -a -t sshd_exec_t" which gave it the same context as sshd. I have not been able to change the unconfined_u to system_u: lz -Z /usr/sbin/sshdfilter unconfined_u:object_r:sshd_exec_t:s0 I was getting avc errors so I created an allow policy: module mysshdfilter 1.0; require { type iptables_exec_t; type iptables_t; type sshd_t; class file execute; class fifo_file read; } #============= iptables_t ============== allow iptables_t self:fifo_file read; #============= sshd_t ============== allow sshd_t iptables_exec_t:file execute; Now I'm getting: time->Wed Dec 2 21:07:04 2009 type=USER_ROLE_CHANGE msg=audit(1259816824.474:201): user pid=3664 uid=0 auid=0 ses=12 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=?: exe= "/usr/sbin/sshd" hostname=? addr=? terminal=? res=failed' From domg472 at gmail.com Thu Dec 3 10:05:47 2009 From: domg472 at gmail.com (Dominick Grift) Date: Thu, 3 Dec 2009 11:05:47 +0100 Subject: Tutorial on setting up SELinux / X Server In-Reply-To: References: Message-ID: <20091203100546.GA10843@localhost.localdomain> On Wed, Dec 02, 2009 at 10:22:03PM -0500, Tyler Durvik wrote: > Greetings, > > I am looking for a tutorial, or instructions, on how to set up an X > Server to work with SELinux. I have fedora 12 installed and ready to > go. Does anyone have links/pages to where I may find this > information? setsebool -P xserver_object_manager on shutdown -r now Might not work with every graphics card. See Xorg.0.log about its status. > > Thanks > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Thu Dec 3 10:10:57 2009 From: domg472 at gmail.com (Dominick Grift) Date: Thu, 3 Dec 2009 11:10:57 +0100 Subject: Fedora 12 and unconfined_u sshdfilter In-Reply-To: <200912030533.nB35X2Mh005401@douglas.highley-recommended.com> References: <200912030533.nB35X2Mh005401@douglas.highley-recommended.com> Message-ID: <20091203101056.GB10843@localhost.localdomain> On Wed, Dec 02, 2009 at 09:33:02PM -0800, David Highley wrote: > I'm trying to get sshdfilter a Perl wrapper around sshd to work in > Fedora 12. The script needs to be able to call iptables to drop in new > rejection rules detected hacking connections. I used "semanage fcontext > -a -t sshd_exec_t" which gave it the same context as sshd. I have not > been able to change the unconfined_u to system_u: the _u part in a context is not important. It just shows which selinux users created the subject or object. > lz -Z /usr/sbin/sshdfilter unconfined_u:object_r:sshd_exec_t:s0 > > I was getting avc errors so I created an allow policy: > module mysshdfilter 1.0; > > require { > type iptables_exec_t; > type iptables_t; > type sshd_t; > class file execute; > class fifo_file read; > } > > #============= iptables_t ============== > allow iptables_t self:fifo_file read; > > #============= sshd_t ============== > allow sshd_t iptables_exec_t:file execute; > > > Now I'm getting: > time->Wed Dec 2 21:07:04 2009 > type=USER_ROLE_CHANGE msg=audit(1259816824.474:201): user pid=3664 uid=0 > auid=0 ses=12 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=?: exe= "/usr/sbin/sshd" hostname=? addr=? terminal=? res=failed' Looks to me like sshdfilter is not SELinux aware or that there is an error in sshdfilter/pam configuration. pam_selinux failed. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dwalsh at redhat.com Thu Dec 3 15:51:22 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 03 Dec 2009 10:51:22 -0500 Subject: SELinux won't let dovecot connect to postgresql (SOLVED!) In-Reply-To: <4B16FEFF.1070103@astrofoto.org> References: <4B11FA2C.8040000@astrofoto.org> <4B16FEFF.1070103@astrofoto.org> Message-ID: <4B17DE7A.5040901@redhat.com> On 12/02/2009 06:57 PM, Roland Roberts wrote: > Roland Roberts wrote: >> I'm running Fedora 11 x86_64 with the dovecot and dovecot-pgsql RPMs >> installed. I have a small user database set up for email authentication. >> The issue I'm having is that when I am in enforcing mode, dovecot >> can't connect to the database. Turning off enforcing mode lets it >> work. I'm having trouble diagnosing where the denial is taking place >> as I don't see any avc messages in /var/log/messages that relate to >> dovecot. The only messages I'm getting are in /var/log/maillog from >> dovecot like this: >> >> Nov 28 22:23:11 fred dovecot: auth(default): pgsql: Connect failed to >> maildb: could not connect to server: Permission denied >> Nov 28 22:23:11 fred dovecot: auth(default): #011Is the server running >> on host "fred.flinstone.org" and accepting >> Nov 28 22:23:11 fred dovecot: auth(default): #011TCP/IP connections on >> port 5432? >> >> The answer to the questions is "yes" it is running and accepting >> connections. Whether or not enforcing mode is on, when logged in, I >> can connect to the database via >> >> $ psql -h fred.flinstone.org maildb >> >> I *think* this is a result of updating on Nov 18. I have not changed >> the default selinux mode since the host was set up back in September. >> At that point, I set it to enforcing mode after working out a few >> issues. On Nov 18, a lot of things were updated, but among there were >> >> Nov 18 10:00:02 Updated: kernel-firmware-2.6.30.9-96.fc11.noarch >> Nov 18 10:00:15 Updated: kernel-headers-2.6.30.9-96.fc11.x86_64 >> Nov 18 10:00:28 Installed: kernel-devel-2.6.30.9-96.fc11.x86_64 >> Nov 18 10:01:30 Installed: kernel-2.6.30.9-96.fc11.x86_64 >> Nov 18 10:02:01 Updated: selinux-policy-3.6.12-86.fc11.noarch >> Nov 18 10:02:46 Updated: selinux-policy-targeted-3.6.12-86.fc11.noarch >> >> Today, I did another update, hoping it would cure the problem and got >> these revisions >> >> Nov 28 10:57:33 Updated: selinux-policy-3.6.12-88.fc11.noarch >> Nov 28 10:57:47 Updated: selinux-policy-targeted-3.6.12-88.fc11.noarch >> >> but the behavior is unchanged, I still have to turn off enforcing mode. >> >> Any clues on what I need to do to get this to work? Or where to look >> for clues since, as I mentioned, I can't even find log entries that >> would clue me in. >> >> roland > > Okay, here's what I finally ended up with that have me running in > enforcing mode. I have both dovecot and exim using PostgreSQL for > authentication. I had originally had them connecting via tcp, but > changed them to use the unix domain socket. The policies below allow > either. > > I also ran into a problem with httpd needing access to PostgreSQL since > I'm running Drupal with PostgreSQL as the backend. And I have > SquirrelMail running so httpd needs access to the imap/pop port. I don't > think this is complete as I'm using the tcp port for PostgreSQL and the > policy only allows that, not the unix domain socket (which I should > probably configure instead). But at least I can now run in enforcing mode. > > 365 root> cat *.te > > module dovecotauthfixes 1.0; > > require { > type dovecot_auth_t; > type postgresql_port_t; > type postgresql_tmp_t; > type postgresql_t; > class sock_file write; > class tcp_socket name_connect; > class unix_stream_socket connectto; > } > > #============= dovecot_auth_t ============== > allow dovecot_auth_t postgresql_port_t:tcp_socket name_connect; > allow dovecot_auth_t postgresql_t:unix_stream_socket connectto; > allow dovecot_auth_t postgresql_tmp_t:sock_file write; > > module eximfixes 1.0; > > require { > type postgresql_tmp_t; > type exim_t; > type postgresql_t; > class sock_file write; > class unix_stream_socket connectto; > } > > #============= exim_t ============== > allow exim_t postgresql_t:unix_stream_socket connectto; > allow exim_t postgresql_tmp_t:sock_file write; > > module httpdfixes 1.0; > > require { > type postgresql_port_t; > type httpd_t; > type pop_port_t; > class tcp_socket { name_bind name_connect }; > } > > #============= httpd_t ============== > allow httpd_t pop_port_t:tcp_socket { name_bind name_connect }; > allow httpd_t postgresql_port_t:tcp_socket name_connect; > > roland > You can also just set the booleans # setsebool -P httpd_can_network_connect_db=1 httpd_can_sendmail=1 Please read: http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_things.pdf This explains the four things SELinux is trying to tell you. In order of most common to least 1 You have a labeling problem (restorecon/semanage fcontext) 2 You have a selinux confiuration problem (booleans, semanage selinux settings) 3 Bug in selinux-policy or application (audit2allow -M localpolicy) 4 You have been hacked. In the case of what you are reporting most fall into category 2. From rchapman at aardvark.com.au Fri Dec 4 01:59:20 2009 From: rchapman at aardvark.com.au (Richard Chapman) Date: Fri, 04 Dec 2009 09:59:20 +0800 Subject: Tutorial on setting up SELinux / X Server In-Reply-To: <20091203100546.GA10843@localhost.localdomain> References: <20091203100546.GA10843@localhost.localdomain> Message-ID: <4B186CF8.2040300@aardvark.com.au> I have a Cetos 5.4 system ruining x - and I also have some boot time x related denials. I therefore tried the below setsebool but got the following errors: setsebool -P xserver_object_manager on ibsemanage.dbase_llist_set: record not found in the database libsemanage.dbase_llist_set: could not set record value Could not change boolean xserver_object_manager Could not change policy booleans Is this because Centos is different - or is there a typo in the above command? Richard. Dominick Grift wrote: > On Wed, Dec 02, 2009 at 10:22:03PM -0500, Tyler Durvik wrote: > >> Greetings, >> >> I am looking for a tutorial, or instructions, on how to set up an X >> Server to work with SELinux. I have fedora 12 installed and ready to >> go. Does anyone have links/pages to where I may find this >> information? >> > > setsebool -P xserver_object_manager on > shutdown -r now > > Might not work with every graphics card. See Xorg.0.log about its status. > >> Thanks >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> ------------------------------------------------------------------------ >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list From ewalsh at tycho.nsa.gov Fri Dec 4 02:25:41 2009 From: ewalsh at tycho.nsa.gov (Eamon Walsh) Date: Thu, 03 Dec 2009 21:25:41 -0500 Subject: Tutorial on setting up SELinux / X Server In-Reply-To: <4B186CF8.2040300@aardvark.com.au> References: <20091203100546.GA10843@localhost.localdomain> <4B186CF8.2040300@aardvark.com.au> Message-ID: <4B187325.7010304@tycho.nsa.gov> On 12/03/2009 08:59 PM, Richard Chapman wrote: > I have a Cetos 5.4 system ruining x - and I also have some boot time x > related denials. I therefore tried the below setsebool but got the > following errors: > > setsebool -P xserver_object_manager on > > ibsemanage.dbase_llist_set: record not found in the database > libsemanage.dbase_llist_set: could not set record value > Could not change boolean xserver_object_manager > Could not change policy booleans > > > Is this because Centos is different - or is there a typo in the above > command? > > Richard. > > I don't think that RHEL 5.4 has this boolean. Look in /selinux/booleans and see if there is a file called xserver_object_manager. However, if you are getting boot-time X denials then it's probably not anything to do with the X object manager. That sounds like a kernel policy problem. What are the denials? -- Eamon Walsh National Security Agency From rchapman at aardvark.com.au Fri Dec 4 02:56:35 2009 From: rchapman at aardvark.com.au (Richard Chapman) Date: Fri, 04 Dec 2009 10:56:35 +0800 Subject: Tutorial on setting up SELinux / X Server In-Reply-To: <4B187325.7010304@tycho.nsa.gov> References: <20091203100546.GA10843@localhost.localdomain> <4B186CF8.2040300@aardvark.com.au> <4B187325.7010304@tycho.nsa.gov> Message-ID: <4B187A63.5080502@aardvark.com.au> Eamon Walsh wrote: > On 12/03/2009 08:59 PM, Richard Chapman wrote: > >> I have a Cetos 5.4 system ruining x - and I also have some boot time x >> related denials. I therefore tried the below setsebool but got the >> following errors: >> >> setsebool -P xserver_object_manager on >> >> ibsemanage.dbase_llist_set: record not found in the database >> libsemanage.dbase_llist_set: could not set record value >> Could not change boolean xserver_object_manager >> Could not change policy booleans >> >> >> Is this because Centos is different - or is there a typo in the above >> command? >> >> Richard. >> >> >> > > > I don't think that RHEL 5.4 has this boolean. Look in /selinux/booleans > and see if there is a file called xserver_object_manager. > > However, if you are getting boot-time X denials then it's probably not > anything to do with the X object manager. That sounds like a kernel > policy problem. What are the denials? > > > Hi Eamon You are right - that there is no such file in /selinux/booleans on my rhel 5.4 system. I have been getting these for ages - and have discussed with Daniel - but not found the problem: Here is the first - and the others are similar. I have tried the suggested re-labelling, and moved /tmp to a tmpfs volume - but still the errors persist: Summary SELinux is preventing the setxkbmap from using potentially mislabeled files (./.X11-unix). Detailed Description [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] SELinux has denied setxkbmap access to potentially mislabeled file(s) (./.X11-unix). This means that SELinux will not allow setxkbmap 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 setxkbmap to access this files, you need to relabel them using restorecon -v './.X11-unix'. You might want to relabel the entire directory using restorecon -R -v './.X11-unix'. Additional Information Source Context: system_u:system_r:rhgb_t Target Context: system_u:object_r:initrc_tmp_t Target Objects: ./.X11-unix [ dir ] Source: setxkbmap Source Path: /usr/bin/setxkbmap Port: Host: C5.aardvark.com.au Source RPM Packages: xorg-x11-xkb-utils-1.0.2-2.1 Target RPM Packages: Policy RPM: selinux-policy-2.4.6-225.el5 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Permissive Plugin Name: home_tmp_bad_labels Host Name: C5.aardvark.com.au Platform: Linux C5.aardvark.com.au 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 Alert Count: 43 First Seen: Sun Jan 11 17:55:13 2009 Last Seen: Tue Sep 29 12:03:49 2009 Local ID: 0950df01-cfad-420a-9e84-4996a8d31942 Line Numbers: Raw Audit Messages : host=C5.aardvark.com.au type=AVC msg=audit(1254197029.941:12): avc: denied { search } for pid=4172 comm="setxkbmap" name=".X11-unix" dev=tmpfs ino=13452 scontext=system_u:system_r:rhgb_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir host=C5.aardvark.com.au type=AVC msg=audit(1254197029.941:12): avc: denied { search } for pid=4172 comm="setxkbmap" name=".X11-unix" dev=tmpfs ino=13452 scontext=system_u:system_r:rhgb_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir host=C5.aardvark.com.au type=SYSCALL msg=audit(1254197029.941:12): arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fffd604c2a0 a2=13 a3=3be2b51a30 items=0 ppid=4171 pid=4172 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setxkbmap" exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) host=C5.aardvark.com.au type=SYSCALL msg=audit(1254197029.941:12): arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fffd604c2a0 a2=13 a3=3be2b51a30 items=0 ppid=4171 pid=4172 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setxkbmap" exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) Richard From ewalsh at tycho.nsa.gov Fri Dec 4 03:07:53 2009 From: ewalsh at tycho.nsa.gov (Eamon Walsh) Date: Thu, 03 Dec 2009 22:07:53 -0500 Subject: Tutorial on setting up SELinux / X Server In-Reply-To: References: Message-ID: <4B187D09.90508@tycho.nsa.gov> On 12/02/2009 10:22 PM, Tyler Durvik wrote: > Greetings, > > I am looking for a tutorial, or instructions, on how to set up an X > Server to work with SELinux. I have fedora 12 installed and ready to > go. Does anyone have links/pages to where I may find this > information? > > Thanks > Turn on the xserver_object_manager boolean and restart X, as described by Dominick. AVC's generated by X will go in Xorg.0.log as well as audit.log (as type "USER_AVC"). The current X policy in F12 probably will generate AVC's on a full desktop session. There is a much improved X policy upstream that is not in F12 yet. I will bug Dan to ship it in his next update. If you want to run the X server in permissive mode but keep the rest of the system enforcing put the following in xorg.conf: Section "Module" SubSection "extmod" Option "SELinux mode permissive" EndSubSection EndSection -- Eamon Walsh National Security Agency From dhighley at highley-recommended.com Fri Dec 4 04:35:56 2009 From: dhighley at highley-recommended.com (David Highley) Date: Thu, 3 Dec 2009 20:35:56 -0800 (PST) Subject: Virtual http hosting and selinux Message-ID: <200912040435.nB44ZurN023224@douglas.highley-recommended.com> A common virtual web hosting set up would be a web root directory location with the following sub directories: ftp logs pages pages/cgi-bin Under ftp you would have all that is needed for a chroot ftp sandbox. Since each virtual host would be a different user and or company how does one change sebool httpd_unified to off and get it all to work with selinux? From dhighley at highley-recommended.com Fri Dec 4 04:40:23 2009 From: dhighley at highley-recommended.com (David Highley) Date: Thu, 3 Dec 2009 20:40:23 -0800 (PST) Subject: Fedora 12 and unconfined_u sshdfilter In-Reply-To: <4B17DBFE.7010502@redhat.com> Message-ID: <200912040440.nB44eNDY023317@douglas.highley-recommended.com> "Daniel J Walsh wrote:" > > On 12/03/2009 12:33 AM, David Highley wrote: > > I'm trying to get sshdfilter a Perl wrapper around sshd to work in > > Fedora 12. The script needs to be able to call iptables to drop in new > > rejection rules detected hacking connections. I used "semanage fcontext > > -a -t sshd_exec_t" which gave it the same context as sshd. I have not > > been able to change the unconfined_u to system_u: > > lz -Z /usr/sbin/sshdfilter unconfined_u:object_r:sshd_exec_t:s0 > > > > I was getting avc errors so I created an allow policy: > > module mysshdfilter 1.0; > > > > require { > > type iptables_exec_t; > > type iptables_t; > > type sshd_t; > > class file execute; > > class fifo_file read; > > } > > > > #============= iptables_t ============== > > allow iptables_t self:fifo_file read; > > > > #============= sshd_t ============== > > allow sshd_t iptables_exec_t:file execute; > > > > > > Now I'm getting: > > time->Wed Dec 2 21:07:04 2009 > > type=USER_ROLE_CHANGE msg=audit(1259816824.474:201): user pid=3664 uid=0 > > auid=0 ses=12 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=?: exe= "/usr/sbin/sshd" hostname=? addr=? terminal=? res=failed' > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > You probably want > > iptables_domtrans(sshd_t) I tried adding this statement to the file, but checkmodule gave syntax error. I tried searching through the selinux files but did not find an example of how to use the above statement. > > The ROLE_CHANGE is not an SELinux error, it is just an audit message. > > I will add the fifo_file rule to iptables policy > > Fixed in selinux-policy-3.6.32-54.fc12 > > If you want to get real crazy you could write policy for > /usr/sbin/sshdfilter > > > policy_module(sshdfilter, 1.0) > > ssh_server_template(sshdfilter) > iptables_domtrans(sshdfilter_t) > > > -- Regards, David Highley Highley Recommended, Inc. Phone: (206) 669-0081 2927 SW 339th Street WEB: http://www.highley-recommended.com Federal Way, WA 98023-7732 From roland at astrofoto.org Fri Dec 4 04:53:37 2009 From: roland at astrofoto.org (Roland Roberts) Date: Thu, 03 Dec 2009 23:53:37 -0500 Subject: SELinux won't let dovecot connect to postgresql (SOLVED!) In-Reply-To: <4B16FEFF.1070103@astrofoto.org> References: <4B11FA2C.8040000@astrofoto.org> <4B16FEFF.1070103@astrofoto.org> Message-ID: <4B1895D1.8070502@astrofoto.org> On 12/02/2009 06:57 PM, Roland Roberts wrote: > Okay, here's what I finally ended up with that have me running in > enforcing mode. I have both dovecot and exim using PostgreSQL for > authentication. I had originally had them connecting via tcp, but > changed them to use the unix domain socket. The policies below allow > either. > > [...] > module eximfixes 1.0; > > require { > type postgresql_tmp_t; > type exim_t; > type postgresql_t; > class sock_file write; > class unix_stream_socket connectto; > } > > #============= exim_t ============== > allow exim_t postgresql_t:unix_stream_socket connectto; > allow exim_t postgresql_tmp_t:sock_file write; > > module httpdfixes 1.0; > > require { > type postgresql_port_t; > type httpd_t; > type pop_port_t; > class tcp_socket { name_bind name_connect }; > } > > #============= httpd_t ============== > allow httpd_t pop_port_t:tcp_socket { name_bind name_connect }; > allow httpd_t postgresql_port_t:tcp_socket name_connect; The above are not actually necessary; only the dovecot fix was needed. Daniel Walsh pointed out that there were booleans I could set for the other problems, namely # setsebool -P httpd_can_network_connect_db=1 httpd_can_sendmail=1 exim_can_connect_db=1 replaces all of the above. roland -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhD RL Enterprises roland at rlenter.com 6818 Madeline Court roland at astrofoto.org Brooklyn, NY 11220 From domg472 at gmail.com Fri Dec 4 09:42:23 2009 From: domg472 at gmail.com (Dominick Grift) Date: Fri, 4 Dec 2009 10:42:23 +0100 Subject: Virtual http hosting and selinux In-Reply-To: <200912040435.nB44ZurN023224@douglas.highley-recommended.com> References: <200912040435.nB44ZurN023224@douglas.highley-recommended.com> Message-ID: <20091204094222.GC13162@localhost.localdomain> On Thu, Dec 03, 2009 at 08:35:56PM -0800, David Highley wrote: > A common virtual web hosting set up would be a web root directory > location with the following sub directories: > ftp > logs > pages > pages/cgi-bin > > Under ftp you would have all that is needed for a chroot ftp sandbox. > Since each virtual host would be a different user and or company how > does one change sebool httpd_unified to off and get it all to work with > selinux? Well PHP needs httpd_unified but if you use CGI like perl or c or bash or whatever then basically you would set httpd_enable_cgi and httpd_builtin_scripting booleans. Then label the locations with a proper type. for example: # ftp: /srv/ftproot(/.*)? public_content_rw_t setsebool -P allow_ftpd_anon_write on (allow ftpd to write to /srv/ftproot setsebool -P allow_httpd_anon_write on (allow httpd to write to /srv/ftproot) (for php/httpd unified) setsebool -P allow_httpd_sys_script_anon_write on (allow httpd system cgi scripts to write to /srv/ftproot (other cgi) # logs /srv/www/logs(/.*)? httpd_sys_content_ra_t # static content /srv/www/html(/.*)? httpd_sys_content_t # cgi /srv/www/cgi-bin(/.*)? httpd_sys_script_exec_t The above is just an example. It may or may not be what you would want. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From Moray.Henderson at ict-software.org Fri Dec 4 09:57:53 2009 From: Moray.Henderson at ict-software.org (Moray Henderson) Date: Fri, 4 Dec 2009 09:57:53 +0000 Subject: Fedora 12 and unconfined_u sshdfilter In-Reply-To: <200912040440.nB44eNDY023317@douglas.highley-recommended.com> References: <4B17DBFE.7010502@redhat.com> <200912040440.nB44eNDY023317@douglas.highley-recommended.com> Message-ID: <000001ca74c8$400dfc20$c029f460$@Henderson@ict-software.org> David Highley wrote: >"Daniel J Walsh wrote:" >> >> On 12/03/2009 12:33 AM, David Highley wrote: >> > I'm trying to get sshdfilter a Perl wrapper around sshd to work in >> > Fedora 12. The script needs to be able to call iptables to drop in new >> > rejection rules detected hacking connections. I used "semanage >fcontext >> > -a -t sshd_exec_t" which gave it the same context as sshd. I have not >> > been able to change the unconfined_u to system_u: >> > lz -Z /usr/sbin/sshdfilter unconfined_u:object_r:sshd_exec_t:s0 >> > >> > I was getting avc errors so I created an allow policy: >> > module mysshdfilter 1.0; >> > >> > require { >> > type iptables_exec_t; >> > type iptables_t; >> > type sshd_t; >> > class file execute; >> > class fifo_file read; >> > } >> > >> > #============= iptables_t ============== >> > allow iptables_t self:fifo_file read; >> > >> > #============= sshd_t ============== >> > allow sshd_t iptables_exec_t:file execute; >> > >> > >> > Now I'm getting: >> > time->Wed Dec 2 21:07:04 2009 >> > type=USER_ROLE_CHANGE msg=audit(1259816824.474:201): user pid=3664 >uid=0 >> > auid=0 ses=12 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 >msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0- >s0:c0.c1023 selected-context=?: exe= "/usr/sbin/sshd" hostname=? addr=? >terminal=? res=failed' >> > >> > -- >> > fedora-selinux-list mailing list >> > fedora-selinux-list at redhat.com >> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > >> > >> You probably want >> >> iptables_domtrans(sshd_t) > >I tried adding this statement to the file, but checkmodule gave syntax >error. I tried searching through the selinux files but did not find an >example of how to use the above statement. > >> >> The ROLE_CHANGE is not an SELinux error, it is just an audit message. >> >> I will add the fifo_file rule to iptables policy >> >> Fixed in selinux-policy-3.6.32-54.fc12 >> >> If you want to get real crazy you could write policy for >> /usr/sbin/sshdfilter >> >> >> policy_module(sshdfilter, 1.0) >> >> ssh_server_template(sshdfilter) >> iptables_domtrans(sshdfilter_t) Your original policy "module mysshdfilter 1.0;" is written in the old-fashioned way: requirements declaration followed by allow rules. This is how I write my policy, too. Daniel's example uses the new way - a whole new policy programming language which needs to be pre-processed and compiled. You can't mix the old and new ways. To compile with the new way (on EL5 - hopefully Fedora 12 is similar) you need the selinux-policy-devel package. Simply use the checkmodule command to build a .mod module file from the .te file, and then the semanage_module command to combine the .mod file with any .fc file to produce the loadable .pp module file which you can load with semodule. You can also have a .if file, but I'm not sure where that fits in to things yet. checkmodule [ -M ] -m mysshdfilter.te -o mysshdfilter.mod semanage_module -m mysshdfilter.mod -o rsyslogd.pp [ -f mysshdfilter.fc ] semodule -i mysshdfilter.pp Which leads me to a question I have been meaning to ask for a while now: if I compile my policy the old way, I get a module of a certain size. If I build exactly the same policy using the m4 macros and examine the pre-processed files, there is a whole lot of extra stuff that has been added. What is all that? What is the advantage of having it added to each module? Moray. "To err is human.? To purr, feline" From dhighley at highley-recommended.com Fri Dec 4 14:45:39 2009 From: dhighley at highley-recommended.com (David Highley) Date: Fri, 4 Dec 2009 06:45:39 -0800 (PST) Subject: Virtual http hosting and selinux In-Reply-To: <20091204094222.GC13162@localhost.localdomain> Message-ID: <200912041445.nB4EjdnJ029926@douglas.highley-recommended.com> "Dominick Grift wrote:" > > > --===============0256136332== > Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; boundary="Fig2xvG2VGoz8o/s" > Content-Disposition: inline > > > --Fig2xvG2VGoz8o/s > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Thu, Dec 03, 2009 at 08:35:56PM -0800, David Highley wrote: > > A common virtual web hosting set up would be a web root directory > > location with the following sub directories: > > ftp > > logs > > pages > > pages/cgi-bin > >=20 > > Under ftp you would have all that is needed for a chroot ftp sandbox. > > Since each virtual host would be a different user and or company how > > does one change sebool httpd_unified to off and get it all to work with > > selinux? > > Well PHP needs httpd_unified but if you use CGI like perl or c or bash or w= > hatever then basically you would set httpd_enable_cgi and httpd_builtin_scr= > ipting booleans. Then label the locations with a proper type. I'm not sure the statement that PHP needs httpd_unified on is correct in Fedora 12. I just finished doing some testing of Mythtv with this setting turned off. I tested all TV recording, weather, and streaming video available through the web interace and it all seems to be working now. Granted there is a lot more to full backend Mythtv setup but it was looking pretty good. Dan has put in two policy updates which should be out pretty soon. I'm not done, but I also ran a quick test of squirrelmail with dovecot for off site email access and that appears to be working. Squirrelmail is all PHP. > > for example: > > # ftp: > /srv/ftproot(/.*)? public_content_rw_t > setsebool -P allow_ftpd_anon_write on (allow ftpd to write to /srv/ftproot > setsebool -P allow_httpd_anon_write on (allow httpd to write to /srv/ftproo= > t) (for php/httpd unified) > setsebool -P allow_httpd_sys_script_anon_write on (allow httpd system cgi s= > cripts to write to /srv/ftproot (other cgi) > > # logs > /srv/www/logs(/.*)? httpd_sys_content_ra_t=20 > > # static content > /srv/www/html(/.*)? httpd_sys_content_t > > # cgi > /srv/www/cgi-bin(/.*)? httpd_sys_script_exec_t > > The above is just an example. It may or may not be what you would want. > > >=20 > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > --Fig2xvG2VGoz8o/s > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAksY2X4ACgkQMlxVo39jgT84SgCffFYU9S9JDB05qOuelRkKZgxR > PO8AoKssSIRvpVYEuZXCZOYZUXd9SZ0r > =nF/1 > -----END PGP SIGNATURE----- > > --Fig2xvG2VGoz8o/s-- > > > --===============0256136332== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > --===============0256136332==-- > -- Regards, David Highley Highley Recommended, Inc. Phone: (206) 669-0081 2927 SW 339th Street WEB: http://www.highley-recommended.com Federal Way, WA 98023-7732 From domg472 at gmail.com Fri Dec 4 14:57:35 2009 From: domg472 at gmail.com (Dominick Grift) Date: Fri, 4 Dec 2009 15:57:35 +0100 Subject: Virtual http hosting and selinux In-Reply-To: <200912041445.nB4EjdnJ029926@douglas.highley-recommended.com> References: <20091204094222.GC13162@localhost.localdomain> <200912041445.nB4EjdnJ029926@douglas.highley-recommended.com> Message-ID: <20091204145734.GD13162@localhost.localdomain> On Fri, Dec 04, 2009 at 06:45:39AM -0800, David Highley wrote: > "Dominick Grift wrote:" > > > > > > --===============0256136332== > > Content-Type: multipart/signed; micalg=pgp-sha1; > > protocol="application/pgp-signature"; boundary="Fig2xvG2VGoz8o/s" > > Content-Disposition: inline > > > > > > --Fig2xvG2VGoz8o/s > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > > > > On Thu, Dec 03, 2009 at 08:35:56PM -0800, David Highley wrote: > > > A common virtual web hosting set up would be a web root directory > > > location with the following sub directories: > > > ftp > > > logs > > > pages > > > pages/cgi-bin > > >=20 > > > Under ftp you would have all that is needed for a chroot ftp sandbox. > > > Since each virtual host would be a different user and or company how > > > does one change sebool httpd_unified to off and get it all to work with > > > selinux? > > > > Well PHP needs httpd_unified but if you use CGI like perl or c or bash or w= > > hatever then basically you would set httpd_enable_cgi and httpd_builtin_scr= > > ipting booleans. Then label the locations with a proper type. > > I'm not sure the statement that PHP needs httpd_unified on is correct in > Fedora 12. I just finished doing some testing of Mythtv with this > setting turned off. I tested all TV recording, weather, and streaming > video available through the web interace and it all seems to be working > now. Granted there is a lot more to full backend Mythtv setup but it was > looking pretty good. Dan has put in two policy updates which should be > out pretty soon. > > I'm not done, but I also ran a quick test of squirrelmail with dovecot > for off site email access and that appears to be working. Squirrelmail > is all PHP. Do your php scripts run with the httpd_sys_script_t or with the httpd_t type? > > > > > for example: > > > > # ftp: > > /srv/ftproot(/.*)? public_content_rw_t > > setsebool -P allow_ftpd_anon_write on (allow ftpd to write to /srv/ftproot > > setsebool -P allow_httpd_anon_write on (allow httpd to write to /srv/ftproo= > > t) (for php/httpd unified) > > setsebool -P allow_httpd_sys_script_anon_write on (allow httpd system cgi s= > > cripts to write to /srv/ftproot (other cgi) > > > > # logs > > /srv/www/logs(/.*)? httpd_sys_content_ra_t=20 > > > > # static content > > /srv/www/html(/.*)? httpd_sys_content_t > > > > # cgi > > /srv/www/cgi-bin(/.*)? httpd_sys_script_exec_t > > > > The above is just an example. It may or may not be what you would want. > > > > >=20 > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > --Fig2xvG2VGoz8o/s > > Content-Type: application/pgp-signature > > Content-Disposition: inline > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.10 (GNU/Linux) > > > > iEYEARECAAYFAksY2X4ACgkQMlxVo39jgT84SgCffFYU9S9JDB05qOuelRkKZgxR > > PO8AoKssSIRvpVYEuZXCZOYZUXd9SZ0r > > =nF/1 > > -----END PGP SIGNATURE----- > > > > --Fig2xvG2VGoz8o/s-- > > > > > > --===============0256136332== > > Content-Type: text/plain; charset="us-ascii" > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > --===============0256136332==-- > > > > > -- > > Regards, > > David Highley > Highley Recommended, Inc. Phone: (206) 669-0081 > 2927 SW 339th Street WEB: http://www.highley-recommended.com > Federal Way, WA 98023-7732 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dhighley at highley-recommended.com Fri Dec 4 15:26:02 2009 From: dhighley at highley-recommended.com (David Highley) Date: Fri, 4 Dec 2009 07:26:02 -0800 (PST) Subject: Virtual http hosting and selinux In-Reply-To: <20091204145734.GD13162@localhost.localdomain> Message-ID: <200912041526.nB4FQ2dp030340@douglas.highley-recommended.com> "Dominick Grift wrote:" > > > --===============1080715742== > Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; boundary="llIrKcgUOe3dCx0c" > Content-Disposition: inline > > > --llIrKcgUOe3dCx0c > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Fri, Dec 04, 2009 at 06:45:39AM -0800, David Highley wrote: > > "Dominick Grift wrote:" > > >=20 > > >=20 > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0256136332=3D=3D > > > Content-Type: multipart/signed; micalg=3Dpgp-sha1; > > > protocol=3D"application/pgp-signature"; boundary=3D"Fig2xvG2VGoz8o/s" > > > Content-Disposition: inline > > >=20 > > >=20 > > > --Fig2xvG2VGoz8o/s > > > Content-Type: text/plain; charset=3Dus-ascii > > > Content-Disposition: inline > > > Content-Transfer-Encoding: quoted-printable > > >=20 > > > On Thu, Dec 03, 2009 at 08:35:56PM -0800, David Highley wrote: > > > > A common virtual web hosting set up would be a web root directory > > > > location with the following sub directories: > > > > ftp > > > > logs > > > > pages > > > > pages/cgi-bin > > > >=3D20 > > > > Under ftp you would have all that is needed for a chroot ftp sandbox. > > > > Since each virtual host would be a different user and or company how > > > > does one change sebool httpd_unified to off and get it all to work wi= > th > > > > selinux? > > >=20 > > > Well PHP needs httpd_unified but if you use CGI like perl or c or bash = > or w=3D > > > hatever then basically you would set httpd_enable_cgi and httpd_builtin= > _scr=3D > > > ipting booleans. Then label the locations with a proper type. > >=20 > > I'm not sure the statement that PHP needs httpd_unified on is correct in > > Fedora 12. I just finished doing some testing of Mythtv with this > > setting turned off. I tested all TV recording, weather, and streaming > > video available through the web interace and it all seems to be working > > now. Granted there is a lot more to full backend Mythtv setup but it was > > looking pretty good. Dan has put in two policy updates which should be > > out pretty soon. > >=20 > > I'm not done, but I also ran a quick test of squirrelmail with dovecot > > for off site email access and that appears to be working. Squirrelmail > > is all PHP. > > Do your php scripts run with the httpd_sys_script_t or with the httpd_t typ= > e? I have not had to change any labels for the PHP files. When I look at squirrelmail, ls -Z /usr/share/squirrelmail/class. I see: system_u:object_r:usr_t:s0 For all files. I do have httpd_builtin_scripting turned on and httpd_can_network_connect is on. For Mythtv I need to change /usr/share/mythtvweb/mythweb.pl to httpd_sys_script_exec_t and also /usr/share/mythtv/mythweather/scripts. Last it needed /usr/mythweb/data to be httpd_sys_content_t and the recording library storage area if you want to be able to stream video or play with other video players. > >=20 > > >=20 > > > for example: > > >=20 > > > # ftp: > > > /srv/ftproot(/.*)? public_content_rw_t > > > setsebool -P allow_ftpd_anon_write on (allow ftpd to write to /srv/ftpr= > oot > > > setsebool -P allow_httpd_anon_write on (allow httpd to write to /srv/ft= > proo=3D > > > t) (for php/httpd unified) > > > setsebool -P allow_httpd_sys_script_anon_write on (allow httpd system c= > gi s=3D > > > cripts to write to /srv/ftproot (other cgi) > > >=20 > > > # logs > > > /srv/www/logs(/.*)? httpd_sys_content_ra_t=3D20 > > >=20 > > > # static content > > > /srv/www/html(/.*)? httpd_sys_content_t > > >=20 > > > # cgi > > > /srv/www/cgi-bin(/.*)? httpd_sys_script_exec_t > > >=20 > > > The above is just an example. It may or may not be what you would want. > > >=20 > > > >=3D20 > > > > -- > > > > fedora-selinux-list mailing list > > > > fedora-selinux-list at redhat.com > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > >=20 > > > --Fig2xvG2VGoz8o/s > > > Content-Type: application/pgp-signature > > > Content-Disposition: inline > > >=20 > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1.4.10 (GNU/Linux) > > >=20 > > > iEYEARECAAYFAksY2X4ACgkQMlxVo39jgT84SgCffFYU9S9JDB05qOuelRkKZgxR > > > PO8AoKssSIRvpVYEuZXCZOYZUXd9SZ0r > > > =3DnF/1 > > > -----END PGP SIGNATURE----- > > >=20 > > > --Fig2xvG2VGoz8o/s-- > > >=20 > > >=20 > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0256136332=3D=3D > > > Content-Type: text/plain; charset=3D"us-ascii" > > > MIME-Version: 1.0 > > > Content-Transfer-Encoding: 7bit > > > Content-Disposition: inline > > >=20 > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0256136332=3D=3D-- > > >=20 > >=20 > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > --llIrKcgUOe3dCx0c > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAksZI14ACgkQMlxVo39jgT9eaACgyrpSQQw1T+mq+YBpylkmK46G > sTcAoJk0a7npKP8NHG5/ZkKzhXUp40WV > =5+Ix > -----END PGP SIGNATURE----- > > --llIrKcgUOe3dCx0c-- > > > --===============1080715742== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > --===============1080715742==-- > From phangbyte at gmail.com Fri Dec 4 15:59:29 2009 From: phangbyte at gmail.com (Tyler Durvik) Date: Fri, 4 Dec 2009 10:59:29 -0500 Subject: Tutorial on setting up SELinux / X Server In-Reply-To: <4B187D09.90508@tycho.nsa.gov> References: <4B187D09.90508@tycho.nsa.gov> Message-ID: I turned on the boolean: setsebool -P xserver_object_manager on and now I get the following in my Xorg.0.log file: SELinux: Invalid object class mapping, disabling SELinux support. Should I try the latest policy from oss.tresys.com? Would the upstream reference policy fix this error? Thanks, Mark On Thu, Dec 3, 2009 at 10:07 PM, Eamon Walsh wrote: > On 12/02/2009 10:22 PM, Tyler Durvik wrote: >> Greetings, >> >> I am looking for a tutorial, or instructions, on how to set up an X >> Server to work with SELinux. ?I have fedora 12 installed and ready to >> go. ?Does anyone have links/pages to where I may find this >> information? >> >> Thanks >> > > > Turn on the xserver_object_manager boolean and restart X, as described > by Dominick. ?AVC's generated by X will go in Xorg.0.log as well as > audit.log (as type "USER_AVC"). > > The current X policy in F12 probably will generate AVC's on a full > desktop session. ?There is a much improved X policy upstream that is not > in F12 yet. ?I will bug Dan to ship it in his next update. > > If you want to run the X server in permissive mode but keep the rest of > the system enforcing put the following in xorg.conf: > > Section "Module" > ? ? ? ?SubSection "extmod" > ? ? ? ? ? ? ? ?Option "SELinux mode permissive" > ? ? ? ?EndSubSection > EndSection > > > > > -- > > Eamon Walsh > National Security Agency > > From Mark.Dyson at ngc.com Fri Dec 4 18:15:07 2009 From: Mark.Dyson at ngc.com (Dyson, Mark L (IS)) Date: Fri, 4 Dec 2009 12:15:07 -0600 Subject: Obtaining MLS policy package for RHEL5? Message-ID: <834B41F71BFB1D4385FC5E62CF526DCE01C59D8E@XMBIL123.northgrum.com> Hello, For a test machine I was provided a SunFire X2200 (AMD processors) with RHEL5 pre-installed. I wasn't provided the install media. It currently only has the targeted policy package installed. Is there a source from which I can download and install the multi-level security package(s)? I had been pointed to some "LSPP" information based on an earlier question but, aside from my system type not being represented, from appearances those packages were intended for a fresh install based on a strictly limited hardware/software architecture. I'm not sure how I would be able to use them in my case. Thanks in advance! Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From justinmattock at gmail.com Fri Dec 4 18:31:37 2009 From: justinmattock at gmail.com (Justin P. Mattock) Date: Fri, 04 Dec 2009 10:31:37 -0800 Subject: Obtaining MLS policy package for RHEL5? In-Reply-To: <834B41F71BFB1D4385FC5E62CF526DCE01C59D8E@XMBIL123.northgrum.com> References: <834B41F71BFB1D4385FC5E62CF526DCE01C59D8E@XMBIL123.northgrum.com> Message-ID: <4B195589.3020600@gmail.com> On 12/04/09 10:15, Dyson, Mark L (IS) wrote: > Hello, > > For a test machine I was provided a SunFire X2200 (AMD processors) with > RHEL5 pre-installed. I wasn't provided the install media. It currently > only has the targeted policy package installed. Is there a source from > which I can download and install the multi-level security package(s)? > > I had been pointed to some "LSPP" information based on an earlier > question but, aside from my system type not being represented, from > appearances those packages were intended for a fresh install based on a > strictly limited hardware/software architecture. I'm not sure how I > would be able to use them in my case. > > Thanks in advance! > Mark > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list can;t remember, but they do offer a policy-strict which might be similiar to mls, but if you want the full fledged mls you will need to load refpolicy from tresys, and change build.conf to use mls. keep in mind mls doesn't really work well with the xserver if that at all. Justin P. Mattock From domg472 at gmail.com Fri Dec 4 20:56:12 2009 From: domg472 at gmail.com (Dominick Grift) Date: Fri, 4 Dec 2009 21:56:12 +0100 Subject: Obtaining MLS policy package for RHEL5? In-Reply-To: <834B41F71BFB1D4385FC5E62CF526DCE01C59D8E@XMBIL123.northgrum.com> References: <834B41F71BFB1D4385FC5E62CF526DCE01C59D8E@XMBIL123.northgrum.com> Message-ID: <20091204205611.GA2965@localhost.localdomain> On Fri, Dec 04, 2009 at 12:15:07PM -0600, Dyson, Mark L (IS) wrote: > Hello, > > For a test machine I was provided a SunFire X2200 (AMD processors) with > RHEL5 pre-installed. I wasn't provided the install media. It currently > only has the targeted policy package installed. Is there a source from > which I can download and install the multi-level security package(s)? yum install selinux-policy-mls edit /etc/selinux/config (replace SELINUXTYPE (targeted by mls) touch /.autorelabel && reboot You might want to boot with enforcing=0 in kernel boot line so that relabeling can go ahead and that you can log into the system. you might also want to check this out: http://oss.tresys.com/projects/clip > > I had been pointed to some "LSPP" information based on an earlier > question but, aside from my system type not being represented, from > appearances those packages were intended for a fresh install based on a > strictly limited hardware/software architecture. I'm not sure how I > would be able to use them in my case. > > Thanks in advance! > Mark > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From gizmo at giz-works.com Fri Dec 4 22:38:39 2009 From: gizmo at giz-works.com (Chris Richards) Date: Fri, 04 Dec 2009 16:38:39 -0600 Subject: AVC Denials on UDEV In-Reply-To: <20091202232101.GC3347@localhost.localdomain> References: <4B152BD3.60109@giz-works.com> <4B153A8C.8050609@gmail.com> <4B15A4FD.5080508@giz-works.com> <4B15A855.6030305@aoaforums.com> <4B16A7E7.9070104@giz-works.com> <20091202183648.GB3347@localhost.localdomain> <4B16F4A5.8030903@giz-works.com> <20091202232101.GC3347@localhost.localdomain> Message-ID: <4B198F6F.8070305@giz-works.com> On 12/02/2009 05:21 PM, Dominick Grift wrote: >> Ah, but therein seems to lie the rub for me: near as I can tell, >> there were some major changes made in how the policy is written >> somewhere around the late May/early June timeframe. All of the >> documentation that I can find refers to the new framework, whereas >> the policy I'm using appears to be based on the old framework. As a >> consequence, just about the time I think I'm starting to get a >> handle on what works how, I run into something that doesn't >> correspond to what the SELinux docs are telling me. >> >> A good is example is refpolicy itself: the policy explained at the >> tresys site: >> >> http://oss.tresys.com/projects/refpolicy/wiki/UseRefpolicy >> >> Seems to be rather well thought ought, and reasonably logical and >> orthoginal. It also seems to bear little resemblance to what I'm >> using. The instructions for the tools that I come across seem to >> mostly reference things that don't even exist for me, or if they did >> exist would be absolutely useless to me because they are GUI tools, >> and my systems don't even have X installed. >> > As far is a know the structure is pretty much the same > There are a good many types, transitions, and helper macros that don't seem to exist in the Gentoo policy. >> I realize that a good deal of this is almost certainly due to the >> fact that I'm on Gentoo. I'd much rather be part of the solution >> than part of the problem, so I want to get to where I can start >> helping with Gentoo's SELinux implementation, but I'm so blasted >> confused I don't even rightly know how to start. >> >> As I've said previously, Gentoo SEEMS to be using policy and tools >> from RHEL 4's incarnation of SELinux. That's all well and good, >> EXCEPT that the documentation describing the policies and tools >> seems to have gone wandering, so those of use poor schmucks stuck >> schlepping through the muck of the previous generation's tools have >> no clue where we are or where we are going, and since I don't even >> have the source for the policies that I AM using, I'm stuck with my >> finger up my nose going "Whuh?" >> > Well i am not sure but it is unlikely like El4. Any open source project should make the source available so it should be somewhere.. > Good point. And pursuing that angle, I have in fact found the source for the Gentoo policy. I'm digging through it now. Fortunately, the M4 macro language is pretty simple. ;) Later, Chris From ewalsh at tycho.nsa.gov Fri Dec 4 22:51:26 2009 From: ewalsh at tycho.nsa.gov (Eamon Walsh) Date: Fri, 04 Dec 2009 17:51:26 -0500 Subject: Tutorial on setting up SELinux / X Server In-Reply-To: References: <4B187D09.90508@tycho.nsa.gov> Message-ID: <4B19926E.9080500@tycho.nsa.gov> On 12/04/2009 10:59 AM, Tyler Durvik wrote: > I turned on the boolean: > > setsebool -P xserver_object_manager on > > and now I get the following in my Xorg.0.log file: > > SELinux: Invalid object class mapping, disabling SELinux support. > > Should I try the latest policy from oss.tresys.com? Would the > upstream reference policy fix this error? > > Thanks, > Mark > > OK, that error is because the x_pointer and x_keyboard object classes haven't made it into F-12 policy yet. You could try the upstream policy. I'd recommend sticking with the Fedora policy though, because I'm getting AVC's from upstream (at least on rawhide) and upstream is not tuned for Fedora. If you do compile from upstream make sure to set the "init_upstart" boolean to true or everything gets out of whack at boot time. If you're willing to rebuild the F-12 policy, you can add the attached patch which will fix the error above and allow the SELinux extension to run. As soon as I can get the rest of the new X policy ported I'll send it to Dan. -- Eamon Walsh National Security Agency -------------- next part -------------- A non-text attachment was scrubbed... Name: policy-X1.patch Type: text/x-patch Size: 1398 bytes Desc: not available URL: From frankly3d at gmail.com Sat Dec 5 09:07:16 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3D)) Date: Sat, 05 Dec 2009 09:07:16 +0000 Subject: Selinux > Hipl Message-ID: <4B1A22C4.8000901@gmail.com> http://infrahip.hiit.fi/index.php?index=download Would it be possible to install hipl-all, and get a it to work with selinux enabled. Asking in advance, or should I just try it first, then look for help? -- Regards, Frank Murphy UTF_8 Encoded. From wolfy at nobugconsulting.ro Sat Dec 5 09:25:27 2009 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sat, 05 Dec 2009 11:25:27 +0200 Subject: Selinux > Hipl In-Reply-To: <4B1A22C4.8000901@gmail.com> References: <4B1A22C4.8000901@gmail.com> Message-ID: <4B1A2707.7090802@nobugconsulting.ro> On 12/05/2009 11:07 AM, Frank Murphy (Frankly3D) wrote: > http://infrahip.hiit.fi/index.php?index=download > > Would it be possible to install hipl-all, > and get a it to work with selinux enabled. > > Asking in advance, or should I just try it first, > then look for help? > Those instructions are purely idiotic. Just install it, go to permissive mode and create a policy based on the AVCs that get logged. Note that installing the rpm packages should never trigger any selinux denials. From frankly3d at gmail.com Sat Dec 5 09:36:31 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3D)) Date: Sat, 05 Dec 2009 09:36:31 +0000 Subject: Selinux > Hipl In-Reply-To: <4B1A2707.7090802@nobugconsulting.ro> References: <4B1A22C4.8000901@gmail.com> <4B1A2707.7090802@nobugconsulting.ro> Message-ID: <4B1A299F.2090609@gmail.com> On 05/12/09 09:25, Manuel Wolfshant wrote: > On 12/05/2009 11:07 AM, Frank Murphy (Frankly3D) wrote: >> http://infrahip.hiit.fi/index.php?index=download >> >> Would it be possible to install hipl-all, >> and get a it to work with selinux enabled. >> >> Asking in advance, or should I just try it first, >> then look for help? >> > Those instructions are purely idiotic. Just install it, go to permissive > mode and create a policy based on the AVCs that get logged. Cool, thanks. -- Regards, Frank Murphy UTF_8 Encoded. From wolfy at nobugconsulting.ro Sat Dec 5 09:42:41 2009 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sat, 05 Dec 2009 11:42:41 +0200 Subject: Selinux > Hipl In-Reply-To: <4B1A2707.7090802@nobugconsulting.ro> References: <4B1A22C4.8000901@gmail.com> <4B1A2707.7090802@nobugconsulting.ro> Message-ID: <4B1A2B11.3050608@nobugconsulting.ro> On 12/05/2009 11:25 AM, Manuel Wolfshant wrote: > On 12/05/2009 11:07 AM, Frank Murphy (Frankly3D) wrote: >> http://infrahip.hiit.fi/index.php?index=download >> >> Would it be possible to install hipl-all, >> and get a it to work with selinux enabled. >> >> Asking in advance, or should I just try it first, >> then look for help? >> > Those instructions are purely idiotic. Just install it, go to > permissive mode and create a policy based on the AVCs that get logged. > Note that installing the rpm packages should never trigger any selinux > denials. And once we (that is you :) ) have a correct policy, it would be polite to send it to them and ask them to fix the instructions. And eventually post the policy on their website (because we can include it in fedora, but for sure RHEL and, by matter of consequence Centos will not . At least not in a foreseeable future.) From justinmattock at gmail.com Sat Dec 5 10:00:59 2009 From: justinmattock at gmail.com (Justin P. Mattock) Date: Sat, 05 Dec 2009 02:00:59 -0800 Subject: Selinux > Hipl In-Reply-To: <4B1A22C4.8000901@gmail.com> References: <4B1A22C4.8000901@gmail.com> Message-ID: <4B1A2F5B.7070101@gmail.com> On 12/05/09 01:07, Frank Murphy (Frankly3D) wrote: > http://infrahip.hiit.fi/index.php?index=download > > Would it be possible to install hipl-all, > and get a it to work with selinux enabled. > > Asking in advance, or should I just try it first, > then look for help? > from what it looks like(not sure what the software is), but by a quick glance it seems to be similar to wireshark, so yes you can have that work with the policy in enforce mode, as well as tcpdump,etherape, and even a honeypot on top.. (just make sure you define the avc's if any are created); Justin P. Mattock From frankly3d at gmail.com Sat Dec 5 10:06:27 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3D)) Date: Sat, 05 Dec 2009 10:06:27 +0000 Subject: Selinux > Hipl In-Reply-To: <4B1A2B11.3050608@nobugconsulting.ro> References: <4B1A22C4.8000901@gmail.com> <4B1A2707.7090802@nobugconsulting.ro> <4B1A2B11.3050608@nobugconsulting.ro> Message-ID: <4B1A30A3.6000305@gmail.com> On 05/12/09 09:42, Manuel Wolfshant wrote: --snip-- > And once we (that is you :) ) have a correct policy, Does this look ok? audit2allow -M myhipd01 < /var/log/audit/audit.log module myhipd01 1.0; require { type unconfined_t; type ifconfig_t; type unconfined_java_t; type chrome_sandbox_t; type root_t; type admin_home_t; type null_device_t; type iptables_t; type abrt_t; type initrc_t; type ftp_port_t; type var_lock_t; type xauth_t; type device_t; type setroubleshootd_t; type wine_t; type rpm_var_cache_t; type rpcd_t; type system_mail_t; type plymouthd_t; class capability sys_ptrace; class netlink_ip6fw_socket { read write }; class process execmem; class memprotect mmap_zero; class netlink_firewall_socket { read write }; class chr_file unlink; class netlink_xfrm_socket { read write }; class tcp_socket name_connect; class file { read write }; class rawip_socket { read write }; class netlink_route_socket { read write }; class udp_socket { read write }; class dir { write remove_name create }; role system_r; role unconfined_r; } #============= abrt_t ============== allow abrt_t ftp_port_t:tcp_socket name_connect; allow abrt_t rpm_var_cache_t:dir create; #============= chrome_sandbox_t ============== allow chrome_sandbox_t self:capability sys_ptrace; #============= ifconfig_t ============== allow ifconfig_t initrc_t:netlink_route_socket { read write }; allow ifconfig_t initrc_t:netlink_xfrm_socket { read write }; allow ifconfig_t initrc_t:udp_socket { read write }; allow ifconfig_t var_lock_t:file { read write }; #============= iptables_t ============== allow iptables_t initrc_t:netlink_firewall_socket { read write }; allow iptables_t initrc_t:netlink_ip6fw_socket { read write }; allow iptables_t initrc_t:rawip_socket { read write }; allow iptables_t initrc_t:udp_socket { read write }; allow iptables_t var_lock_t:file { read write }; #============= plymouthd_t ============== allow plymouthd_t device_t:dir { write remove_name }; allow plymouthd_t null_device_t:chr_file unlink; #============= setroubleshootd_t ============== allow setroubleshootd_t device_t:file write; #============= system_mail_t ============== allow system_mail_t root_t:dir write; #============= unconfined_t ============== allow unconfined_t self:process execmem; #============= wine_t ============== allow wine_t self:memprotect mmap_zero; #============= xauth_t ============== allow xauth_t admin_home_t:file { write read }; #============= ROLES ============== role system_r types unconfined_java_t; role unconfined_r types rpcd_t; -- Regards, Frank Murphy UTF_8 Encoded. From justinmattock at gmail.com Sat Dec 5 10:09:02 2009 From: justinmattock at gmail.com (Justin P. Mattock) Date: Sat, 05 Dec 2009 02:09:02 -0800 Subject: Selinux > Hipl In-Reply-To: <4B1A30A3.6000305@gmail.com> References: <4B1A22C4.8000901@gmail.com> <4B1A2707.7090802@nobugconsulting.ro> <4B1A2B11.3050608@nobugconsulting.ro> <4B1A30A3.6000305@gmail.com> Message-ID: <4B1A313E.7060808@gmail.com> On 12/05/09 02:06, Frank Murphy (Frankly3D) wrote: > On 05/12/09 09:42, Manuel Wolfshant wrote: > --snip-- > >> And once we (that is you :) ) have a correct policy, > > Does this look ok? > > audit2allow -M myhipd01 < /var/log/audit/audit.log > > module myhipd01 1.0; > > require { > type unconfined_t; > type ifconfig_t; > type unconfined_java_t; > type chrome_sandbox_t; > type root_t; > type admin_home_t; > type null_device_t; > type iptables_t; > type abrt_t; > type initrc_t; > type ftp_port_t; > type var_lock_t; > type xauth_t; > type device_t; > type setroubleshootd_t; > type wine_t; > type rpm_var_cache_t; > type rpcd_t; > type system_mail_t; > type plymouthd_t; > class capability sys_ptrace; > class netlink_ip6fw_socket { read write }; > class process execmem; > class memprotect mmap_zero; > class netlink_firewall_socket { read write }; > class chr_file unlink; > class netlink_xfrm_socket { read write }; > class tcp_socket name_connect; > class file { read write }; > class rawip_socket { read write }; > class netlink_route_socket { read write }; > class udp_socket { read write }; > class dir { write remove_name create }; > role system_r; > role unconfined_r; > } > > #============= abrt_t ============== > allow abrt_t ftp_port_t:tcp_socket name_connect; > allow abrt_t rpm_var_cache_t:dir create; > > #============= chrome_sandbox_t ============== > allow chrome_sandbox_t self:capability sys_ptrace; > > #============= ifconfig_t ============== > allow ifconfig_t initrc_t:netlink_route_socket { read write }; > allow ifconfig_t initrc_t:netlink_xfrm_socket { read write }; > allow ifconfig_t initrc_t:udp_socket { read write }; > allow ifconfig_t var_lock_t:file { read write }; > > #============= iptables_t ============== > allow iptables_t initrc_t:netlink_firewall_socket { read write }; > allow iptables_t initrc_t:netlink_ip6fw_socket { read write }; > allow iptables_t initrc_t:rawip_socket { read write }; > allow iptables_t initrc_t:udp_socket { read write }; > allow iptables_t var_lock_t:file { read write }; > > #============= plymouthd_t ============== > allow plymouthd_t device_t:dir { write remove_name }; > allow plymouthd_t null_device_t:chr_file unlink; > > #============= setroubleshootd_t ============== > allow setroubleshootd_t device_t:file write; > > #============= system_mail_t ============== > allow system_mail_t root_t:dir write; > > #============= unconfined_t ============== > allow unconfined_t self:process execmem; > > #============= wine_t ============== > allow wine_t self:memprotect mmap_zero; > > #============= xauth_t ============== > allow xauth_t admin_home_t:file { write read }; > #============= ROLES ============== > role system_r types unconfined_java_t; > role unconfined_r types rpcd_t; > sure.. now install your binary!! Justin P. Mattock From domg472 at gmail.com Sat Dec 5 10:54:29 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 5 Dec 2009 11:54:29 +0100 Subject: Selinux > Hipl In-Reply-To: <4B1A313E.7060808@gmail.com> References: <4B1A22C4.8000901@gmail.com> <4B1A2707.7090802@nobugconsulting.ro> <4B1A2B11.3050608@nobugconsulting.ro> <4B1A30A3.6000305@gmail.com> <4B1A313E.7060808@gmail.com> Message-ID: <20091205105428.GB2965@localhost.localdomain> On Sat, Dec 05, 2009 at 02:09:02AM -0800, Justin P. Mattock wrote: > On 12/05/09 02:06, Frank Murphy (Frankly3D) wrote: > >On 05/12/09 09:42, Manuel Wolfshant wrote: > >--snip-- > > > >>And once we (that is you :) ) have a correct policy, > > > >Does this look ok? > > > >audit2allow -M myhipd01 < /var/log/audit/audit.log > > > >module myhipd01 1.0; > > > >require { > >type unconfined_t; > >type ifconfig_t; > >type unconfined_java_t; > >type chrome_sandbox_t; > >type root_t; > >type admin_home_t; > >type null_device_t; > >type iptables_t; > >type abrt_t; > >type initrc_t; > >type ftp_port_t; > >type var_lock_t; > >type xauth_t; > >type device_t; > >type setroubleshootd_t; > >type wine_t; > >type rpm_var_cache_t; > >type rpcd_t; > >type system_mail_t; > >type plymouthd_t; > >class capability sys_ptrace; > >class netlink_ip6fw_socket { read write }; > >class process execmem; > >class memprotect mmap_zero; > >class netlink_firewall_socket { read write }; > >class chr_file unlink; > >class netlink_xfrm_socket { read write }; > >class tcp_socket name_connect; > >class file { read write }; > >class rawip_socket { read write }; > >class netlink_route_socket { read write }; > >class udp_socket { read write }; > >class dir { write remove_name create }; > >role system_r; > >role unconfined_r; > >} > > > >#============= abrt_t ============== > >allow abrt_t ftp_port_t:tcp_socket name_connect; > >allow abrt_t rpm_var_cache_t:dir create; probably bugs in abrt policy > > > >#============= chrome_sandbox_t ============== > >allow chrome_sandbox_t self:capability sys_ptrace; > > probably bug in chrome policy > >#============= ifconfig_t ============== > >allow ifconfig_t initrc_t:netlink_route_socket { read write }; > >allow ifconfig_t initrc_t:netlink_xfrm_socket { read write }; > >allow ifconfig_t initrc_t:udp_socket { read write }; > >allow ifconfig_t var_lock_t:file { read write }; > > > >#============= iptables_t ============== > >allow iptables_t initrc_t:netlink_firewall_socket { read write }; > >allow iptables_t initrc_t:netlink_ip6fw_socket { read write }; > >allow iptables_t initrc_t:rawip_socket { read write }; > >allow iptables_t initrc_t:udp_socket { read write }; > >allow iptables_t var_lock_t:file { read write }; whatever runs initrc_t needs policy imho: ps auxZ | grep initrc > > > >#============= plymouthd_t ============== > >allow plymouthd_t device_t:dir { write remove_name }; > >allow plymouthd_t null_device_t:chr_file unlink; > > > >#============= setroubleshootd_t ============== > >allow setroubleshootd_t device_t:file write; Looks like this file is mislabeled. ausearch -m avc -ts today | grep device_t | grep file | grep avc | head -n 1 > > > >#============= system_mail_t ============== > >allow system_mail_t root_t:dir write; why is it writing to / > > > >#============= unconfined_t ============== > >allow unconfined_t self:process execmem; allow_execmem boolean or label the executable of the execmem program execmem_exec_t; > > > >#============= wine_t ============== > >allow wine_t self:memprotect mmap_zero; There is a boolean you can set for this. getsebool -a | grep mmap > > > >#============= xauth_t ============== > >allow xauth_t admin_home_t:file { write read }; > >#============= ROLES ============== > >role system_r types unconfined_java_t; Looks like this is what you get when you run user applications with system role > >role unconfined_r types rpcd_t; If this is a daemon as the type suggests then it should not be run with unconfined role. > > > > sure.. now install your binary!! > > Justin P. Mattock > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From misc.lists at blueyonder.co.uk Sun Dec 6 09:38:32 2009 From: misc.lists at blueyonder.co.uk (Arthur Dent) Date: Sun, 06 Dec 2009 09:38:32 +0000 Subject: Logrotate frustration Message-ID: <1260092312.3083.10.camel@localhost> Hello all, Its seems that almost every week logrotate is throwing up a new AVC. I have an almost vanilla F11 install with most packages installed via yum and yet I keep getting these. Each time I audit2allow and build a new policy. My "mylogr.te" is now at version 7. Am I missing a bool or is there something else I'm lacking? Here is the latest version of my policy: ===============8<================================================== module mylogr 11.1.7; require { type mail_spool_t; type logrotate_t; type fail2ban_var_run_t; type initrc_t; type squid_log_t; class dir {read open write remove_name}; class file { getattr read write open}; class file setattr; class sock_file write; class unix_stream_socket connectto; class lnk_file rename; } #============= logrotate_t ============== allow logrotate_t mail_spool_t:file { getattr read write open }; allow logrotate_t mail_spool_t:dir { read open write remove_name}; allow logrotate_t mail_spool_t:file setattr; allow logrotate_t fail2ban_var_run_t:sock_file write; allow logrotate_t initrc_t:unix_stream_socket connectto; allow logrotate_t squid_log_t:lnk_file rename; ===============8<================================================== This was today's AVC that necessitated the inclusion of the squid stuff: ===============8<================================================== Raw Audit Messages : node=mydomain.org.uk type=AVC msg=audit(1260069452.494:45041): avc: denied { rename } for pid=12302 comm="logrotate" name="squidGuard.log" dev=sda5 ino=387195 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:squid_log_t:s0 tclass=lnk_file node=mydomain.org.uk type=SYSCALL msg=audit(1260069452.494:45041): arch=40000003 syscall=38 success=no exit=-13 a0=890b130 a1=8908760 a2=890b060 a3=0 items=0 ppid=12300 pid=12302 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2275 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null) ===============8<================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From justinmattock at gmail.com Sun Dec 6 09:49:07 2009 From: justinmattock at gmail.com (Justin P. Mattock) Date: Sun, 06 Dec 2009 01:49:07 -0800 Subject: Logrotate frustration In-Reply-To: <1260092312.3083.10.camel@localhost> References: <1260092312.3083.10.camel@localhost> Message-ID: <4B1B7E13.7030407@gmail.com> On 12/06/09 01:38, Arthur Dent wrote: > Hello all, > > Its seems that almost every week logrotate is throwing up a new AVC. I > have an almost vanilla F11 install with most packages installed via yum > and yet I keep getting these. Each time I audit2allow and build a new > policy. My "mylogr.te" is now at version 7. Am I missing a bool or is > there something else I'm lacking? > > Here is the latest version of my policy: > > > ===============8<================================================== > > module mylogr 11.1.7; > > require { > type mail_spool_t; > type logrotate_t; > type fail2ban_var_run_t; > type initrc_t; > type squid_log_t; > class dir {read open write remove_name}; > class file { getattr read write open}; > class file setattr; > class sock_file write; > class unix_stream_socket connectto; > class lnk_file rename; > } > > #============= logrotate_t ============== > allow logrotate_t mail_spool_t:file { getattr read write open }; > allow logrotate_t mail_spool_t:dir { read open write remove_name}; > allow logrotate_t mail_spool_t:file setattr; > allow logrotate_t fail2ban_var_run_t:sock_file write; > allow logrotate_t initrc_t:unix_stream_socket connectto; > allow logrotate_t squid_log_t:lnk_file rename; > > ===============8<================================================== > > > This was today's AVC that necessitated the inclusion of the squid stuff: > > ===============8<================================================== > Raw Audit Messages : > > node=mydomain.org.uk type=AVC msg=audit(1260069452.494:45041): avc: denied { rename } for pid=12302 comm="logrotate" name="squidGuard.log" dev=sda5 ino=387195 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:squid_log_t:s0 tclass=lnk_file > node=mydomain.org.uk type=SYSCALL msg=audit(1260069452.494:45041): arch=40000003 syscall=38 success=no exit=-13 a0=890b130 a1=8908760 a2=890b060 a3=0 items=0 ppid=12300 pid=12302 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2275 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null) > ===============8<================================================== > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list I dont use logrotate over here(not sure of the label), but looking at the avc's you supplied seems it's a label issue. (but correct me if I'm wrong); Justin P. Mattock From domg472 at gmail.com Sun Dec 6 11:59:11 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sun, 6 Dec 2009 12:59:11 +0100 Subject: Logrotate frustration In-Reply-To: <1260092312.3083.10.camel@localhost> References: <1260092312.3083.10.camel@localhost> Message-ID: <20091206115908.GA2886@localhost.localdomain> On Sun, Dec 06, 2009 at 09:38:32AM +0000, Arthur Dent wrote: > Hello all, > > Its seems that almost every week logrotate is throwing up a new AVC. I > have an almost vanilla F11 install with most packages installed via yum > and yet I keep getting these. Each time I audit2allow and build a new > policy. My "mylogr.te" is now at version 7. Am I missing a bool or is > there something else I'm lacking? > > Here is the latest version of my policy: > > > ===============8<================================================== > > module mylogr 11.1.7; > > require { > type mail_spool_t; > type logrotate_t; > type fail2ban_var_run_t; > type initrc_t; > type squid_log_t; > class dir {read open write remove_name}; > class file { getattr read write open}; > class file setattr; > class sock_file write; > class unix_stream_socket connectto; > class lnk_file rename; > } > > #============= logrotate_t ============== > allow logrotate_t mail_spool_t:file { getattr read write open }; > allow logrotate_t mail_spool_t:dir { read open write remove_name}; > allow logrotate_t mail_spool_t:file setattr; > allow logrotate_t fail2ban_var_run_t:sock_file write; > allow logrotate_t initrc_t:unix_stream_socket connectto; > allow logrotate_t squid_log_t:lnk_file rename; > > ===============8<================================================== > > > This was today's AVC that necessitated the inclusion of the squid stuff: > > ===============8<================================================== > Raw Audit Messages : > > node=mydomain.org.uk type=AVC msg=audit(1260069452.494:45041): avc: denied { rename } for pid=12302 comm="logrotate" name="squidGuard.log" dev=sda5 ino=387195 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:squid_log_t:s0 tclass=lnk_file > node=mydomain.org.uk type=SYSCALL msg=audit(1260069452.494:45041): arch=40000003 syscall=38 success=no exit=-13 a0=890b130 a1=8908760 a2=890b060 a3=0 items=0 ppid=12300 pid=12302 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2275 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null) > ===============8<================================================== The rule with the initrc_t type is due to missing policy. It is encouraged to implement policy for all init daemons. With regard to the other rules you can, i guess, basically allow the access required, But always go through the checklist: 1. are the parties in an interaction labeled correctly? (matchpatchcon/restorecon/semanage/chcon) 2. are there any booleans or types that facilitate a certain interaction? (audit2allow) 3. is there a misconfiguration in some application? (see if a program should be able to do what it wants) 3. is there a bug in some application? (is the denial due to a bug in an application?) 4. is there a bug in the selinux policy? (missing policy to allow a certain interaction?) 5. is it a break in attempt (is the application compromised. taking these 5 golden rules into concideration. i have some questions: allow logrotate_t fail2ban_var_run_t:sock_file write - why would logrotate have to write to a fail2ban sock file? (this may be a bug in fail2ban, maybe leaked file descriptor. does this denial cause any loss in functionality? if not consider silently denying it) allow logrotate_t squid_log_t:lnk_file rename; - why does squidgaurd, or whatever managed squid_log_t lnk_file, create a lnk_file in /var/log/... This is obviously not common behaviour afaik. That may be the reason why is denied. withregard to the rules with mail_spool_t type i would like to know if and why logrotate wants to rotate spool files. is this expeected behaviour of logrotate or are the mail_spool_t object mislabeled? so in conclusion the only denial that i am somewhat comfortable with is the squid link file denial. This may be some uncommon behaviour of squid/squidgaurd that selinux policy currently does not support (when confirmed that squidgaurd indeed creates a lnk file in /var/log for some reason , then implement policy to allow logrotate to rename the link (and what else it may need to do with the lnk_file.) See what runs initrc_t (ps auxZ) and consider writing policy for this init daemon. By implementing policy for init daemon you prtect the system plus you achive that confined domain do not have to interact with the unconfined initrc_t domain. > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From misc.lists at blueyonder.co.uk Sun Dec 6 21:44:21 2009 From: misc.lists at blueyonder.co.uk (Arthur Dent) Date: Sun, 06 Dec 2009 21:44:21 +0000 Subject: Logrotate frustration - Selinux & Fail2Ban In-Reply-To: <20091206115908.GA2886@localhost.localdomain> References: <1260092312.3083.10.camel@localhost> <20091206115908.GA2886@localhost.localdomain> Message-ID: <1260135861.3083.37.camel@localhost> On Sun, 2009-12-06 at 12:59 +0100, Dominick Grift wrote: > On Sun, Dec 06, 2009 at 09:38:32AM +0000, Arthur Dent wrote: > > [Snip] > The rule with the initrc_t type is due to missing policy. It is encouraged to implement policy for all init daemons. > > With regard to the other rules you can, i guess, basically allow the access required, > > But always go through the checklist: > > 1. are the parties in an interaction labeled correctly? (matchpatchcon/restorecon/semanage/chcon) > 2. are there any booleans or types that facilitate a certain interaction? (audit2allow) > 3. is there a misconfiguration in some application? (see if a program should be able to do what it wants) > 3. is there a bug in some application? (is the denial due to a bug in an application?) > 4. is there a bug in the selinux policy? (missing policy to allow a certain interaction?) > 5. is it a break in attempt (is the application compromised. > > taking these 5 golden rules into concideration. i have some questions: > > allow logrotate_t fail2ban_var_run_t:sock_file write > - why would logrotate have to write to a fail2ban sock file? (this may be a bug in fail2ban, maybe leaked file descriptor. does this denial cause any loss in functionality? if not consider silently denying it) > > allow logrotate_t squid_log_t:lnk_file rename; > - why does squidgaurd, or whatever managed squid_log_t lnk_file, create a lnk_file in /var/log/... This is obviously not common behaviour afaik. That may be the reason why is denied. > > withregard to the rules with mail_spool_t type i would like to know if and why logrotate wants to rotate spool files. is this expeected behaviour of logrotate or are the mail_spool_t object mislabeled? > > so in conclusion the only denial that i am somewhat comfortable with is the squid link file denial. This may be some uncommon behaviour of squid/squidgaurd that selinux policy currently does not support (when confirmed that squidgaurd indeed creates a lnk file in /var/log for some reason , then implement policy to allow logrotate to rename the link (and what else it may need to do with the lnk_file.) > > See what runs initrc_t (ps auxZ) and consider writing policy for this init daemon. By implementing policy for init daemon you prtect the system plus you achive that confined domain do not have to interact with the unconfined initrc_t domain. OK - I'm going to change the focus of this question slightly here. Many of my AVCs do in fact relate to Fail2Ban and in fact running ps auxZ shows the following: # ps auxZ | grep init system_u:system_r:init_t:s0 root 1 0.0 0.0 2008 164 ? Ss Dec02 0:03 /sbin/init system_u:system_r:initrc_t:s0 ddclient 1673 0.0 0.7 10228 2956 ? S Dec02 1:00 ddclient - sleeping for 130 seconds system_u:system_r:initrc_t:s0 root 1827 0.1 0.5 75940 2156 ? Sl Dec02 6:52 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -x system_u:system_r:initrc_t:s0 root 1830 0.0 0.0 2904 348 ? S Dec02 0:17 /usr/libexec/gam_server unconfined_u:system_r:initrc_t:s0 clamav 13149 0.3 28.8 220652 109928 ? Ssl 05:50 1:30 /usr/local/sbin/clamd unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 14886 1.0 0.1 4200 720 pts/0 S+ 12:08 0:00 grep init My Fail2Ban policy has also grown over the months and now looks like this: ===============8<==================================================== module myfail2ban 11.1.3; require { type iptables_t; type system_mail_t; type fail2ban_t; type usr_t; type syslogd_t; type sendmail_t; type initrc_t; class file read; class unix_stream_socket { read write }; class unix_dgram_socket { read write sendto }; } #============= fail2ban_t ============== allow fail2ban_t self:unix_dgram_socket write; allow fail2ban_t syslogd_t:unix_dgram_socket sendto; #============= iptables_t ============== allow iptables_t fail2ban_t:unix_stream_socket { read write }; allow iptables_t fail2ban_t:unix_dgram_socket { read write }; allow iptables_t initrc_t:unix_dgram_socket { read write }; #============= system_mail_t ============== allow system_mail_t fail2ban_t:unix_stream_socket { read write }; allow system_mail_t fail2ban_t:unix_dgram_socket { read write }; allow system_mail_t usr_t:file read; #============= sendmail_t ============== allow sendmail_t initrc_t:unix_dgram_socket { read write }; ===============8<==================================================== I am concious that this is not ideal and so I have asked on the fail2ban list if someone with more technical expertise than me can help clean up fail2ban with respect to selinux. Fortunately Arturo "Buanzo" Busleiman, one of the developers, has offered to take a look at this. (I am also copying this email to the fail2ban list). I would very much appreciate it if Dominick, Daniel, and anyone else who can help, could liaise with Arturo so that this important security package could work cleanly with selinux. I will do what I can too - but I should just point out that I can just about spell "patch" and only if I'm really desperate would I ever try to apply one! Thanks in advance. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mgrepl at redhat.com Mon Dec 7 11:40:46 2009 From: mgrepl at redhat.com (Miroslav Grepl) Date: Mon, 07 Dec 2009 12:40:46 +0100 Subject: Selinux > Hipl In-Reply-To: <4B1A30A3.6000305@gmail.com> References: <4B1A22C4.8000901@gmail.com> <4B1A2707.7090802@nobugconsulting.ro> <4B1A2B11.3050608@nobugconsulting.ro> <4B1A30A3.6000305@gmail.com> Message-ID: <4B1CE9BE.7060502@redhat.com> On 12/05/2009 11:06 AM, Frank Murphy (Frankly3D) wrote: > On 05/12/09 09:42, Manuel Wolfshant wrote: > --snip-- > >> And once we (that is you :) ) have a correct policy, > > Does this look ok? > > audit2allow -M myhipd01 < /var/log/audit/audit.log > > > Frank, what is your version of selinux-policy ? # rpm -q selinux-policy selinux-policy-targeted From domg472 at gmail.com Mon Dec 7 11:49:49 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 7 Dec 2009 12:49:49 +0100 Subject: Logrotate frustration - Selinux & Fail2Ban In-Reply-To: <1260135861.3083.37.camel@localhost> References: <1260092312.3083.10.camel@localhost> <20091206115908.GA2886@localhost.localdomain> <1260135861.3083.37.camel@localhost> Message-ID: <20091207114947.GB2942@localhost.localdomain> On Sun, Dec 06, 2009 at 09:44:21PM +0000, Arthur Dent wrote: > On Sun, 2009-12-06 at 12:59 +0100, Dominick Grift wrote: > > On Sun, Dec 06, 2009 at 09:38:32AM +0000, Arthur Dent wrote: > > > > > [Snip] > > > The rule with the initrc_t type is due to missing policy. It is encouraged to implement policy for all init daemons. > > > > With regard to the other rules you can, i guess, basically allow the access required, > > > > But always go through the checklist: > > > > 1. are the parties in an interaction labeled correctly? (matchpatchcon/restorecon/semanage/chcon) > > 2. are there any booleans or types that facilitate a certain interaction? (audit2allow) > > 3. is there a misconfiguration in some application? (see if a program should be able to do what it wants) > > 3. is there a bug in some application? (is the denial due to a bug in an application?) > > 4. is there a bug in the selinux policy? (missing policy to allow a certain interaction?) > > 5. is it a break in attempt (is the application compromised. > > > > taking these 5 golden rules into concideration. i have some questions: > > > > allow logrotate_t fail2ban_var_run_t:sock_file write > > - why would logrotate have to write to a fail2ban sock file? (this may be a bug in fail2ban, maybe leaked file descriptor. does this denial cause any loss in functionality? if not consider silently denying it) > > > > allow logrotate_t squid_log_t:lnk_file rename; > > - why does squidgaurd, or whatever managed squid_log_t lnk_file, create a lnk_file in /var/log/... This is obviously not common behaviour afaik. That may be the reason why is denied. > > > > withregard to the rules with mail_spool_t type i would like to know if and why logrotate wants to rotate spool files. is this expeected behaviour of logrotate or are the mail_spool_t object mislabeled? > > > > so in conclusion the only denial that i am somewhat comfortable with is the squid link file denial. This may be some uncommon behaviour of squid/squidgaurd that selinux policy currently does not support (when confirmed that squidgaurd indeed creates a lnk file in /var/log for some reason , then implement policy to allow logrotate to rename the link (and what else it may need to do with the lnk_file.) > > > > See what runs initrc_t (ps auxZ) and consider writing policy for this init daemon. By implementing policy for init daemon you prtect the system plus you achive that confined domain do not have to interact with the unconfined initrc_t domain. > > OK - I'm going to change the focus of this question slightly here. > > Many of my AVCs do in fact relate to Fail2Ban and in fact running ps > auxZ shows the following: > > # ps auxZ | grep init > system_u:system_r:init_t:s0 root 1 0.0 0.0 2008 164 ? Ss Dec02 0:03 /sbin/init > system_u:system_r:initrc_t:s0 ddclient 1673 0.0 0.7 10228 2956 ? S Dec02 1:00 ddclient - sleeping for 130 seconds > system_u:system_r:initrc_t:s0 root 1827 0.1 0.5 75940 2156 ? Sl Dec02 6:52 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -x > system_u:system_r:initrc_t:s0 root 1830 0.0 0.0 2904 348 ? S Dec02 0:17 /usr/libexec/gam_server > unconfined_u:system_r:initrc_t:s0 clamav 13149 0.3 28.8 220652 109928 ? Ssl 05:50 1:30 /usr/local/sbin/clamd > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 14886 1.0 0.1 4200 720 pts/0 S+ 12:08 0:00 grep init You are using old policy. [root at localhost ~]# semanage fcontext -l | grep fail2ban /etc/rc\.d/init\.d/fail2ban regular file system_u:object_r:fail2ban_initrc_exec_t:s0 /usr/bin/fail2ban regular file system_u:object_r:fail2ban_exec_t:s0 /usr/bin/fail2ban-server regular file system_u:object_r:fail2ban_exec_t:s0 /var/lib/fail2ban(/.*)? all files system_u:object_r:fail2ban_var_lib_t:s0 /var/log/fail2ban\.log regular file system_u:object_r:fail2ban_log_t:s0 /var/run/fail2ban.* all files system_u:object_r:fail2ban_var_run_t:s0 But anyways with regard to SELinux issues: SELinux is a framework that lets you configure the access that various processes have. It just like iptables/netfilter where a particular port is not open. The netfilter framework allows you to open it and the iptables frontend is a way to implement it. No policy is ever perfect. So for professionals it is a good idea to just learn how to manage an SELinux environment. One thing to keep in mind is that processes running initrc_r do not have policy (in your case ddclient, gameserver, clamd, and fail2ban-server). To fix this in a managable way it is encourage to confine these init daemons first. Writing/implementing policy for a init daemon is not particularly hard and you do not have to be a programmer to do so. With regard to fail2ban-server, you could start by trying to label the fail2ban executable (/usr/bin/fail2ban-server) with the fail2ban executable type (semanage fcontext -a -t fail2ban_exec_t /usr/bin/fail2ban-server; restorecon -v /usr/bin/fail2ban-server). This should atleast get the fail2ban-server process out of the initrc_t domain and into the fail2ban domain. From there on, youre on the right track. As for ddclient, gam_server and clamd it may require that you write a policy from scratch. Also usually not hard to do. In a nutshell: 1. create a type for the process 2. create a type for the executable file 3. declare the two types init_daemon_domain(). 4. label the executable file with the type you declared executable file. 5. start service (if needed in permissive mode during policy development stage) and see whether the process runs with the declared type for the process. 6. use ausearch/audit2allow to write rule that define how you process type can interact with other types. 7. make sure that interacting with type initrc_t means its trying to interact with a process that is not confined (does not have policy yet) after that, its just the five golden rules i mentioned in a previous post. 1. make sure parties in an interaction have the expected type. 2. make sure you check for any booleans/custom types that may provide the access it needs. 3. make sure you app is configured properly. 4. make sure you dont allow access that your app needs because it has a bug. 5. implement policy. > > My Fail2Ban policy has also grown over the months and now looks like > this: > ===============8<==================================================== > module myfail2ban 11.1.3; > > require { > type iptables_t; > type system_mail_t; > type fail2ban_t; > type usr_t; > type syslogd_t; > type sendmail_t; > type initrc_t; > class file read; > class unix_stream_socket { read write }; > class unix_dgram_socket { read write sendto }; > } > > #============= fail2ban_t ============== > allow fail2ban_t self:unix_dgram_socket write; > allow fail2ban_t syslogd_t:unix_dgram_socket sendto; > > #============= iptables_t ============== > allow iptables_t fail2ban_t:unix_stream_socket { read write }; > allow iptables_t fail2ban_t:unix_dgram_socket { read write }; > allow iptables_t initrc_t:unix_dgram_socket { read write }; > > #============= system_mail_t ============== > allow system_mail_t fail2ban_t:unix_stream_socket { read write }; > allow system_mail_t fail2ban_t:unix_dgram_socket { read write }; > allow system_mail_t usr_t:file read; > > #============= sendmail_t ============== > allow sendmail_t initrc_t:unix_dgram_socket { read write }; > > ===============8<==================================================== > > I am concious that this is not ideal and so I have asked on the fail2ban > list if someone with more technical expertise than me can help clean up > fail2ban with respect to selinux. > > Fortunately Arturo "Buanzo" Busleiman, one of the developers, has > offered to take a look at this. (I am also copying this email to the > fail2ban list). > > I would very much appreciate it if Dominick, Daniel, and anyone else who > can help, could liaise with Arturo so that this important security > package could work cleanly with selinux. > > I will do what I can too - but I should just point out that I can just > about spell "patch" and only if I'm really desperate would I ever try to > apply one! > > Thanks in advance. > > Mark > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From Moray.Henderson at ict.om.org Mon Dec 7 12:01:09 2009 From: Moray.Henderson at ict.om.org (Moray Henderson (ICT)) Date: Mon, 7 Dec 2009 12:01:09 +0000 Subject: Fedora 12 and unconfined_u sshdfilter In-Reply-To: <1259939702.2144.29.camel@localhost> References: <4B17DBFE.7010502@redhat.com> <200912040440.nB44eNDY023317@douglas.highley-recommended.com> <000001ca74c8$400dfc20$c029f460$@Henderson@ict-software.org> <1259939702.2144.29.camel@localhost> Message-ID: <000e01ca7734$f9796e10$ec6c4a30$@Henderson@ict.om.org> James Carter wrote: >Dan's example used Refpolicy interfaces. Interfaces are very useful and >provide a better layer of abstraction, but they are just m4 macros, >which have always been used in SELinux policy. > >Interfaces should be used as much as possible, but it is not true that >you can't mix the old and new ways. Mixing the plain rules and the m4 macros didn't work when I tried it - but perhaps I just wasn?t writing it right. Is there a Refpolicy tutorial anywhere? Moray. "To err is human. To purr, feline" From domg472 at gmail.com Mon Dec 7 12:11:18 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 7 Dec 2009 13:11:18 +0100 Subject: Fedora 12 and unconfined_u sshdfilter In-Reply-To: <000e01ca7734$f9796e10$ec6c4a30$@Henderson@ict.om.org> References: <4B17DBFE.7010502@redhat.com> <200912040440.nB44eNDY023317@douglas.highley-recommended.com> <000001ca74c8$400dfc20$c029f460$@Henderson@ict-software.org> <1259939702.2144.29.camel@localhost> <000e01ca7734$f9796e10$ec6c4a30$@Henderson@ict.om.org> Message-ID: <20091207121116.GC2942@localhost.localdomain> On Mon, Dec 07, 2009 at 12:01:09PM +0000, Moray Henderson (ICT) wrote: > James Carter wrote: > >Dan's example used Refpolicy interfaces. Interfaces are very useful and > >provide a better layer of abstraction, but they are just m4 macros, > >which have always been used in SELinux policy. > > > >Interfaces should be used as much as possible, but it is not true that > >you can't mix the old and new ways. > > Mixing the plain rules and the m4 macros didn't work when I tried it - but perhaps I just wasn?t writing it right. Is there a Refpolicy tutorial anywhere? There is www.selinuxbyexample.com (book) but its not free and a bit dated. I want to do a video tutorial about it for Fedora 12 (i have some interesting ideas about what to demonstrate) unfortunatly i cannot find a working screen capture software for Fedora 12 (both istanbul and recordmydesktop are currently too buggy to use) > > > Moray. > "To err is human. To purr, feline" > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From frankly3d at gmail.com Mon Dec 7 12:13:16 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3D)) Date: Mon, 07 Dec 2009 12:13:16 +0000 Subject: Selinux > Hipl In-Reply-To: <4B1CE9BE.7060502@redhat.com> References: <4B1A22C4.8000901@gmail.com> <4B1A2707.7090802@nobugconsulting.ro> <4B1A2B11.3050608@nobugconsulting.ro> <4B1A30A3.6000305@gmail.com> <4B1CE9BE.7060502@redhat.com> Message-ID: <4B1CF15C.8040906@gmail.com> On 07/12/09 11:40, Miroslav Grepl wrote: > pm -q selinux-policy selinux-policy-targeted selinux-policy-3.6.32-49.fc12.noarch selinux-policy-targeted-3.6.32-49.fc12.noarch -- Regards, Frank Murphy UTF_8 Encoded. From Mark.Dyson at ngc.com Mon Dec 7 12:33:38 2009 From: Mark.Dyson at ngc.com (Dyson, Mark L (IS)) Date: Mon, 7 Dec 2009 06:33:38 -0600 Subject: Obtaining MLS policy package for RHEL5? In-Reply-To: <20091204205611.GA2965@localhost.localdomain> References: <834B41F71BFB1D4385FC5E62CF526DCE01C59D8E@XMBIL123.northgrum.com> <20091204205611.GA2965@localhost.localdomain> Message-ID: <834B41F71BFB1D4385FC5E62CF526DCE01C59D8F@XMBIL123.northgrum.com> Dominic, Many thanks. Could you point me to where I can get that policy file? The help info I've seen just points me to the RHEL install media, which I don't have available right now. The Clip site looks extremely interesting, definitely going to spend some time there. Thanks again! Mark -----Original Message----- From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list-bounces at redhat.com] On Behalf Of Dominick Grift Sent: Friday, December 04, 2009 3:56 PM To: fedora-selinux-list at redhat.com Subject: Re: Obtaining MLS policy package for RHEL5? On Fri, Dec 04, 2009 at 12:15:07PM -0600, Dyson, Mark L (IS) wrote: > Hello, > > For a test machine I was provided a SunFire X2200 (AMD processors) > with > RHEL5 pre-installed. I wasn't provided the install media. It > currently only has the targeted policy package installed. Is there a > source from which I can download and install the multi-level security package(s)? yum install selinux-policy-mls edit /etc/selinux/config (replace SELINUXTYPE (targeted by mls) touch /.autorelabel && reboot You might want to boot with enforcing=0 in kernel boot line so that relabeling can go ahead and that you can log into the system. you might also want to check this out: http://oss.tresys.com/projects/clip > > I had been pointed to some "LSPP" information based on an earlier > question but, aside from my system type not being represented, from > appearances those packages were intended for a fresh install based on > a strictly limited hardware/software architecture. I'm not sure how I > would be able to use them in my case. > > Thanks in advance! > Mark > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From domg472 at gmail.com Mon Dec 7 12:41:54 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 7 Dec 2009 13:41:54 +0100 Subject: Obtaining MLS policy package for RHEL5? In-Reply-To: <834B41F71BFB1D4385FC5E62CF526DCE01C59D8F@XMBIL123.northgrum.com> References: <834B41F71BFB1D4385FC5E62CF526DCE01C59D8E@XMBIL123.northgrum.com> <20091204205611.GA2965@localhost.localdomain> <834B41F71BFB1D4385FC5E62CF526DCE01C59D8F@XMBIL123.northgrum.com> Message-ID: <20091207124153.GD2942@localhost.localdomain> On Mon, Dec 07, 2009 at 06:33:38AM -0600, Dyson, Mark L (IS) wrote: > Dominic, > > Many thanks. Could you point me to where I can get that policy file? > The help info I've seen just points me to the RHEL install media, which > I don't have available right now. The source policy is here: ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS (look for selinux-policy-{your.version} The binary representation is available on the the official redhat distribution channel (i dont have a subscription thus i cannot point you to it) > > The Clip site looks extremely interesting, definitely going to spend > some time there. > > Thanks again! > Mark > > -----Original Message----- > From: fedora-selinux-list-bounces at redhat.com > [mailto:fedora-selinux-list-bounces at redhat.com] On Behalf Of Dominick > Grift > Sent: Friday, December 04, 2009 3:56 PM > To: fedora-selinux-list at redhat.com > Subject: Re: Obtaining MLS policy package for RHEL5? > > On Fri, Dec 04, 2009 at 12:15:07PM -0600, Dyson, Mark L (IS) wrote: > > Hello, > > > > For a test machine I was provided a SunFire X2200 (AMD processors) > > with > > RHEL5 pre-installed. I wasn't provided the install media. It > > currently only has the targeted policy package installed. Is there a > > source from which I can download and install the multi-level security > package(s)? > > yum install selinux-policy-mls > edit /etc/selinux/config (replace SELINUXTYPE (targeted by mls) touch > /.autorelabel && reboot > > You might want to boot with enforcing=0 in kernel boot line so that > relabeling can go ahead and that you can log into the system. > > you might also want to check this out: > > http://oss.tresys.com/projects/clip > > > > I had been pointed to some "LSPP" information based on an earlier > > question but, aside from my system type not being represented, from > > appearances those packages were intended for a fresh install based on > > a strictly limited hardware/software architecture. I'm not sure how I > > > would be able to use them in my case. > > > > Thanks in advance! > > Mark > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mgrepl at redhat.com Mon Dec 7 12:50:38 2009 From: mgrepl at redhat.com (Miroslav Grepl) Date: Mon, 07 Dec 2009 13:50:38 +0100 Subject: Logrotate frustration - Selinux & Fail2Ban In-Reply-To: <1260135861.3083.37.camel@localhost> References: <1260092312.3083.10.camel@localhost> <20091206115908.GA2886@localhost.localdomain> <1260135861.3083.37.camel@localhost> Message-ID: <4B1CFA1E.4010504@redhat.com> On 12/06/2009 10:44 PM, Arthur Dent wrote: > On Sun, 2009-12-06 at 12:59 +0100, Dominick Grift wrote: > >> On Sun, Dec 06, 2009 at 09:38:32AM +0000, Arthur Dent wrote: >> >>> > [Snip] > > >> The rule with the initrc_t type is due to missing policy. It is encouraged to implement policy for all init daemons. >> >> With regard to the other rules you can, i guess, basically allow the access required, >> >> But always go through the checklist: >> >> 1. are the parties in an interaction labeled correctly? (matchpatchcon/restorecon/semanage/chcon) >> 2. are there any booleans or types that facilitate a certain interaction? (audit2allow) >> 3. is there a misconfiguration in some application? (see if a program should be able to do what it wants) >> 3. is there a bug in some application? (is the denial due to a bug in an application?) >> 4. is there a bug in the selinux policy? (missing policy to allow a certain interaction?) >> 5. is it a break in attempt (is the application compromised. >> >> taking these 5 golden rules into concideration. i have some questions: >> >> allow logrotate_t fail2ban_var_run_t:sock_file write >> - why would logrotate have to write to a fail2ban sock file? (this may be a bug in fail2ban, maybe leaked file descriptor. does this denial cause any loss in functionality? if not consider silently denying it) >> >> allow logrotate_t squid_log_t:lnk_file rename; >> - why does squidgaurd, or whatever managed squid_log_t lnk_file, create a lnk_file in /var/log/... This is obviously not common behaviour afaik. That may be the reason why is denied. >> >> withregard to the rules with mail_spool_t type i would like to know if and why logrotate wants to rotate spool files. is this expeected behaviour of logrotate or are the mail_spool_t object mislabeled? >> >> so in conclusion the only denial that i am somewhat comfortable with is the squid link file denial. This may be some uncommon behaviour of squid/squidgaurd that selinux policy currently does not support (when confirmed that squidgaurd indeed creates a lnk file in /var/log for some reason , then implement policy to allow logrotate to rename the link (and what else it may need to do with the lnk_file.) >> >> See what runs initrc_t (ps auxZ) and consider writing policy for this init daemon. By implementing policy for init daemon you prtect the system plus you achive that confined domain do not have to interact with the unconfined initrc_t domain. >> > OK - I'm going to change the focus of this question slightly here. > > Many of my AVCs do in fact relate to Fail2Ban and in fact running ps > auxZ shows the following: > > # ps auxZ | grep init > system_u:system_r:init_t:s0 root 1 0.0 0.0 2008 164 ? Ss Dec02 0:03 /sbin/init > system_u:system_r:initrc_t:s0 ddclient 1673 0.0 0.7 10228 2956 ? S Dec02 1:00 ddclient - sleeping for 130 seconds > system_u:system_r:initrc_t:s0 root 1827 0.1 0.5 75940 2156 ? Sl Dec02 6:52 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -x > system_u:system_r:initrc_t:s0 root 1830 0.0 0.0 2904 348 ? S Dec02 0:17 /usr/libexec/gam_server > unconfined_u:system_r:initrc_t:s0 clamav 13149 0.3 28.8 220652 109928 ? Ssl 05:50 1:30 /usr/local/sbin/clamd > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 14886 1.0 0.1 4200 720 pts/0 S+ 12:08 0:00 grep init > > Arthur, what's your version of selinux-policy ? # rpm -q selinux-policy selinux-policy-targeted What is the output of the following command: # matchpathcon /usr/bin/fail2ban-server > My Fail2Ban policy has also grown over the months and now looks like > this: > ===============8<==================================================== > module myfail2ban 11.1.3; > > require { > type iptables_t; > type system_mail_t; > type fail2ban_t; > type usr_t; > type syslogd_t; > type sendmail_t; > type initrc_t; > class file read; > class unix_stream_socket { read write }; > class unix_dgram_socket { read write sendto }; > } > > #============= fail2ban_t ============== > allow fail2ban_t self:unix_dgram_socket write; > allow fail2ban_t syslogd_t:unix_dgram_socket sendto; > > #============= iptables_t ============== > allow iptables_t fail2ban_t:unix_stream_socket { read write }; > allow iptables_t fail2ban_t:unix_dgram_socket { read write }; > allow iptables_t initrc_t:unix_dgram_socket { read write }; > > #============= system_mail_t ============== > allow system_mail_t fail2ban_t:unix_stream_socket { read write }; > allow system_mail_t fail2ban_t:unix_dgram_socket { read write }; > allow system_mail_t usr_t:file read; > > #============= sendmail_t ============== > allow sendmail_t initrc_t:unix_dgram_socket { read write }; > > ===============8<==================================================== > > Actually fail2ban leaking file descriptors. # rpm -q fail2ban Also do not use gam_server with fail2ban, change it to polling mode please. > I am concious that this is not ideal and so I have asked on the fail2ban > list if someone with more technical expertise than me can help clean up > fail2ban with respect to selinux. > > Fortunately Arturo "Buanzo" Busleiman, one of the developers, has > offered to take a look at this. (I am also copying this email to the > fail2ban list). > > I would very much appreciate it if Dominick, Daniel, and anyone else who > can help, could liaise with Arturo so that this important security > package could work cleanly with selinux. > > I will do what I can too - but I should just point out that I can just > about spell "patch" and only if I'm really desperate would I ever try to > apply one! > > Thanks in advance. > > Mark > > > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From rchapman at aardvark.com.au Mon Dec 7 14:26:22 2009 From: rchapman at aardvark.com.au (Richard Chapman) Date: Mon, 07 Dec 2009 22:26:22 +0800 Subject: Tutorial on setting up SELinux / X Server In-Reply-To: <4B187A63.5080502@aardvark.com.au> References: <20091203100546.GA10843@localhost.localdomain> <4B186CF8.2040300@aardvark.com.au> <4B187325.7010304@tycho.nsa.gov> <4B187A63.5080502@aardvark.com.au> Message-ID: <4B1D108E.4050204@aardvark.com.au> Richard Chapman wrote: > Eamon Walsh wrote: >> On 12/03/2009 08:59 PM, Richard Chapman wrote: >> >>> I have a Cetos 5.4 system ruining x - and I also have some boot time >>> x related denials. I therefore tried the below setsebool but got the >>> following errors: >>> >>> setsebool -P xserver_object_manager on >>> >>> ibsemanage.dbase_llist_set: record not found in the database >>> libsemanage.dbase_llist_set: could not set record value >>> Could not change boolean xserver_object_manager >>> Could not change policy booleans >>> >>> >>> Is this because Centos is different - or is there a typo in the >>> above command? >>> >>> Richard. >>> >>> >> >> >> I don't think that RHEL 5.4 has this boolean. Look in /selinux/booleans >> and see if there is a file called xserver_object_manager. >> >> However, if you are getting boot-time X denials then it's probably not >> anything to do with the X object manager. That sounds like a kernel >> policy problem. What are the denials? >> >> >> Hi Eamon I think my previous attempt to send this probably failed. It looks like your mail srver didn't want to talk to mine - so here goes again... You are right - that there is no such file in /selinux/booleans on my rhel 5.4 system. I have been getting these for ages - and have discussed with Daniel - but not found the problem: Here is the first - and the others are similar. I have tried the suggested re-labelling, and moved /tmp to a tmpfs volume - but still the errors persist: Summary SELinux is preventing the setxkbmap from using potentially mislabeled files (./.X11-unix). Detailed Description [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] SELinux has denied setxkbmap access to potentially mislabeled file(s) (./.X11-unix). This means that SELinux will not allow setxkbmap 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 setxkbmap to access this files, you need to relabel them using restorecon -v './.X11-unix'. You might want to relabel the entire directory using restorecon -R -v './.X11-unix'. Additional Information Source Context: system_u:system_r:rhgb_t Target Context: system_u:object_r:initrc_tmp_t Target Objects: ./.X11-unix [ dir ] Source: setxkbmap Source Path: /usr/bin/setxkbmap Port: Host: C5.aardvark.com.au Source RPM Packages: xorg-x11-xkb-utils-1.0.2-2.1 Target RPM Packages: Policy RPM: selinux-policy-2.4.6-225.el5 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Permissive Plugin Name: home_tmp_bad_labels Host Name: C5.aardvark.com.au Platform: Linux C5.aardvark.com.au 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 Alert Count: 43 First Seen: Sun Jan 11 17:55:13 2009 Last Seen: Tue Sep 29 12:03:49 2009 Local ID: 0950df01-cfad-420a-9e84-4996a8d31942 Line Numbers: Raw Audit Messages : host=C5.aardvark.com.au type=AVC msg=audit(1254197029.941:12): avc: denied { search } for pid=4172 comm="setxkbmap" name=".X11-unix" dev=tmpfs ino=13452 scontext=system_u:system_r:rhgb_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir host=C5.aardvark.com.au type=AVC msg=audit(1254197029.941:12): avc: denied { search } for pid=4172 comm="setxkbmap" name=".X11-unix" dev=tmpfs ino=13452 scontext=system_u:system_r:rhgb_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir host=C5.aardvark.com.au type=SYSCALL msg=audit(1254197029.941:12): arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fffd604c2a0 a2=13 a3=3be2b51a30 items=0 ppid=4171 pid=4172 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setxkbmap" exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) host=C5.aardvark.com.au type=SYSCALL msg=audit(1254197029.941:12): arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fffd604c2a0 a2=13 a3=3be2b51a30 items=0 ppid=4171 pid=4172 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setxkbmap" exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) Richard From domg472 at gmail.com Mon Dec 7 20:28:30 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 7 Dec 2009 21:28:30 +0100 Subject: Fedora 12 and unconfined_u sshdfilter In-Reply-To: <000e01ca7734$f9796e10$ec6c4a30$@Henderson@ict.om.org> References: <4B17DBFE.7010502@redhat.com> <200912040440.nB44eNDY023317@douglas.highley-recommended.com> <000001ca74c8$400dfc20$c029f460$@Henderson@ict-software.org> <1259939702.2144.29.camel@localhost> <000e01ca7734$f9796e10$ec6c4a30$@Henderson@ict.om.org> Message-ID: <20091207202828.GA6387@localhost.localdomain> On Mon, Dec 07, 2009 at 12:01:09PM +0000, Moray Henderson (ICT) wrote: > James Carter wrote: > >Dan's example used Refpolicy interfaces. Interfaces are very useful and > >provide a better layer of abstraction, but they are just m4 macros, > >which have always been used in SELinux policy. > > > >Interfaces should be used as much as possible, but it is not true that > >you can't mix the old and new ways. > > Mixing the plain rules and the m4 macros didn't work when I tried it - but perhaps I just wasn?t writing it right. Is there a Refpolicy tutorial anywhere? I spend a little time today writing about the policy structure in Fedora. Maybe it can help you or others: http://82.197.205.60/~dgrift/stuff/Managing_a_SELinux_environment_with_Fedora_12.pdf > > > Moray. > "To err is human. To purr, feline" > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dwalsh at redhat.com Mon Dec 7 21:24:05 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 07 Dec 2009 16:24:05 -0500 Subject: Logrotate frustration In-Reply-To: <1260092312.3083.10.camel@localhost> References: <1260092312.3083.10.camel@localhost> Message-ID: <4B1D7275.6020400@redhat.com> On 12/06/2009 04:38 AM, Arthur Dent wrote: > Hello all, > > Its seems that almost every week logrotate is throwing up a new AVC. I > have an almost vanilla F11 install with most packages installed via yum > and yet I keep getting these. Each time I audit2allow and build a new > policy. My "mylogr.te" is now at version 7. Am I missing a bool or is > there something else I'm lacking? > > Here is the latest version of my policy: > > > ===============8<================================================== > > module mylogr 11.1.7; > > require { > type mail_spool_t; > type logrotate_t; > type fail2ban_var_run_t; > type initrc_t; > type squid_log_t; > class dir {read open write remove_name}; > class file { getattr read write open}; > class file setattr; > class sock_file write; > class unix_stream_socket connectto; > class lnk_file rename; > } > > #============= logrotate_t ============== > allow logrotate_t mail_spool_t:file { getattr read write open }; > allow logrotate_t mail_spool_t:dir { read open write remove_name}; > allow logrotate_t mail_spool_t:file setattr; > allow logrotate_t fail2ban_var_run_t:sock_file write; > allow logrotate_t initrc_t:unix_stream_socket connectto; > allow logrotate_t squid_log_t:lnk_file rename; > > ===============8<================================================== > > > This was today's AVC that necessitated the inclusion of the squid stuff: > > ===============8<================================================== > Raw Audit Messages : > > node=mydomain.org.uk type=AVC msg=audit(1260069452.494:45041): avc: denied { rename } for pid=12302 comm="logrotate" name="squidGuard.log" dev=sda5 ino=387195 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:squid_log_t:s0 tclass=lnk_file > node=mydomain.org.uk type=SYSCALL msg=audit(1260069452.494:45041): arch=40000003 syscall=38 success=no exit=-13 a0=890b130 a1=8908760 a2=890b060 a3=0 items=0 ppid=12300 pid=12302 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2275 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null) > ===============8<================================================== > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list I can allow logrotate to manage log lnk_files, and allow it to write to the fail2ban socket. Are you using a custom logrotate to rotate mail_spool? Why is From misc.lists at blueyonder.co.uk Mon Dec 7 22:11:46 2009 From: misc.lists at blueyonder.co.uk (Arthur Dent) Date: Mon, 07 Dec 2009 22:11:46 +0000 Subject: Logrotate frustration - Selinux & Fail2Ban In-Reply-To: <20091207114947.GB2942@localhost.localdomain> References: <1260092312.3083.10.camel@localhost> <20091206115908.GA2886@localhost.localdomain> <1260135861.3083.37.camel@localhost> <20091207114947.GB2942@localhost.localdomain> Message-ID: <1260223906.3056.24.camel@localhost> On Mon, 2009-12-07 at 12:49 +0100, Dominick Grift wrote: > On Sun, Dec 06, 2009 at 09:44:21PM +0000, Arthur Dent wrote: > > On Sun, 2009-12-06 at 12:59 +0100, Dominick Grift wrote: > > > On Sun, Dec 06, 2009 at 09:38:32AM +0000, Arthur Dent wrote: > > > > > > > > [Snip] > > > > > The rule with the initrc_t type is due to missing policy. It is encouraged to implement policy for all init daemons. > > > > > > With regard to the other rules you can, i guess, basically allow the access required, > > > > > > But always go through the checklist: > > > > > > 1. are the parties in an interaction labeled correctly? (matchpatchcon/restorecon/semanage/chcon) > > > 2. are there any booleans or types that facilitate a certain interaction? (audit2allow) > > > 3. is there a misconfiguration in some application? (see if a program should be able to do what it wants) > > > 3. is there a bug in some application? (is the denial due to a bug in an application?) > > > 4. is there a bug in the selinux policy? (missing policy to allow a certain interaction?) > > > 5. is it a break in attempt (is the application compromised. > > > > > > taking these 5 golden rules into concideration. i have some questions: > > > > > > allow logrotate_t fail2ban_var_run_t:sock_file write > > > - why would logrotate have to write to a fail2ban sock file? (this may be a bug in fail2ban, maybe leaked file descriptor. does this denial cause any loss in functionality? if not consider silently denying it) > > > > > > allow logrotate_t squid_log_t:lnk_file rename; > > > - why does squidgaurd, or whatever managed squid_log_t lnk_file, create a lnk_file in /var/log/... This is obviously not common behaviour afaik. That may be the reason why is denied. > > > > > > withregard to the rules with mail_spool_t type i would like to know if and why logrotate wants to rotate spool files. is this expeected behaviour of logrotate or are the mail_spool_t object mislabeled? > > > > > > so in conclusion the only denial that i am somewhat comfortable with is the squid link file denial. This may be some uncommon behaviour of squid/squidgaurd that selinux policy currently does not support (when confirmed that squidgaurd indeed creates a lnk file in /var/log for some reason , then implement policy to allow logrotate to rename the link (and what else it may need to do with the lnk_file.) > > > > > > See what runs initrc_t (ps auxZ) and consider writing policy for this init daemon. By implementing policy for init daemon you prtect the system plus you achive that confined domain do not have to interact with the unconfined initrc_t domain. > > > > OK - I'm going to change the focus of this question slightly here. > > > > Many of my AVCs do in fact relate to Fail2Ban and in fact running ps > > auxZ shows the following: > > > > # ps auxZ | grep init > > system_u:system_r:init_t:s0 root 1 0.0 0.0 2008 164 ? Ss Dec02 0:03 /sbin/init > > system_u:system_r:initrc_t:s0 ddclient 1673 0.0 0.7 10228 2956 ? S Dec02 1:00 ddclient - sleeping for 130 seconds > > system_u:system_r:initrc_t:s0 root 1827 0.1 0.5 75940 2156 ? Sl Dec02 6:52 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -x > > system_u:system_r:initrc_t:s0 root 1830 0.0 0.0 2904 348 ? S Dec02 0:17 /usr/libexec/gam_server > > unconfined_u:system_r:initrc_t:s0 clamav 13149 0.3 28.8 220652 109928 ? Ssl 05:50 1:30 /usr/local/sbin/clamd > > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 14886 1.0 0.1 4200 720 pts/0 S+ 12:08 0:00 grep init > > You are using old policy. Am I? # rpm -q selinux-policy selinux-policy-targeted selinux-policy-3.6.12-88.fc11.noarch selinux-policy-targeted-3.6.12-88.fc11.noarch > [root at localhost ~]# semanage fcontext -l | grep fail2ban > /etc/rc\.d/init\.d/fail2ban regular file system_u:object_r:fail2ban_initrc_exec_t:s0 > /usr/bin/fail2ban regular file system_u:object_r:fail2ban_exec_t:s0 > /usr/bin/fail2ban-server regular file system_u:object_r:fail2ban_exec_t:s0 > /var/lib/fail2ban(/.*)? all files system_u:object_r:fail2ban_var_lib_t:s0 > /var/log/fail2ban\.log regular file system_u:object_r:fail2ban_log_t:s0 > /var/run/fail2ban.* all files system_u:object_r:fail2ban_var_run_t:s0 # semanage fcontext -l | grep fail2ban /etc/rc\.d/init\.d/fail2ban regular file system_u:object_r:fail2ban_initrc_exec_t:s0 /usr/bin/fail2ban regular file system_u:object_r:fail2ban_exec_t:s0 /usr/bin/fail2ban-server regular file system_u:object_r:fail2ban_exec_t:s0 /var/lib/fail2ban(/.*)? all files system_u:object_r:fail2ban_var_lib_t:s0 /var/log/fail2ban\.log regular file system_u:object_r:fail2ban_log_t:s0 /var/run/fail2ban.* all files system_u:object_r:fail2ban_var_run_t:s0 I may be wrong, but to me my results look the same? > > But anyways with regard to SELinux issues: SELinux is a framework that lets you configure the access that various processes have. > It just like iptables/netfilter where a particular port is not open. The netfilter framework allows you to open it and the iptables frontend is a way to implement it. > > No policy is ever perfect. So for professionals it is a good idea to just learn how to manage an SELinux environment. > > One thing to keep in mind is that processes running initrc_r do not have policy (in your case ddclient, gameserver, clamd, and fail2ban-server). To fix this in a managable way it is encourage to confine these init daemons first. > > Writing/implementing policy for a init daemon is not particularly hard and you do not have to be a programmer to do so. > > With regard to fail2ban-server, you could start by trying to label the fail2ban executable (/usr/bin/fail2ban-server) with the fail2ban executable type (semanage fcontext -a -t fail2ban_exec_t /usr/bin/fail2ban-server; restorecon -v /usr/bin/fail2ban-server). This should atleast get the fail2ban-server process out of the initrc_t domain and into the fail2ban domain. From there on, youre on the right track. Do I still need to do this given the results of my semanage command above? If not, why should I need all the rules in my policy? Actually - I may answer that myself. I keep up to date with selinux policies using yum. On the other hand, I create local policies each time an AVC rears its head, but what I DON'T do - and perhaps I should - is revisit my local rules each time a new policy is issued. I guess I just add and add and add my rules as they are needed. This means that my local policy only ever grows. I'm afraid I don't have the detailed understanding (or the time) to investigate the effects of each new policy... Should I perhaps just remove my "myfail2ban" policy and see what AVCs arise? What I tend to do is to leave my policies grow this way until a new version of Fedora is released - I usually upgrade during my Christmas and summer holidays - and start a new policy from scratch then (this explains the naming convention I use "myfail2ban 11.1.3" is the third minor revision of the second major revision of my fail2ban policy on F11 - When I uprade to F12 I will start with "myfail2ban 12.0.1") > As for ddclient, gam_server and clamd it may require that you write a policy from scratch. Also usually not hard to do. In a nutshell: > > 1. create a type for the process > 2. create a type for the executable file > 3. declare the two types init_daemon_domain(). > 4. label the executable file with the type you declared executable file. > 5. start service (if needed in permissive mode during policy development stage) and see whether the process runs with the declared type for the process. > 6. use ausearch/audit2allow to write rule that define how you process type can interact with other types. > 7. make sure that interacting with type initrc_t means its trying to interact with a process that is not confined (does not have policy yet) This is very helpful advice. Thank you. However, should I need to do this? ddclient was installed using yum - surely the package maintainer should have done this? It's true though that gam_server came with fail2ban and I installed that from source (I think I need to look at that - especially given Miroslav Grepl's post below. Clamd is also installed from source, but surely, as this is an application in such a widespread use, should it not be included in selinux-policy-targeted? > after that, its just the five golden rules i mentioned in a previous post. > > 1. make sure parties in an interaction have the expected type. > 2. make sure you check for any booleans/custom types that may provide the access it needs. > 3. make sure you app is configured properly. > 4. make sure you dont allow access that your app needs because it has a bug. > 5. implement policy. > > > > > My Fail2Ban policy has also grown over the months and now looks like > > this: > > ===============8<==================================================== > > module myfail2ban 11.1.3; > > > > require { > > type iptables_t; > > type system_mail_t; > > type fail2ban_t; > > type usr_t; > > type syslogd_t; > > type sendmail_t; > > type initrc_t; > > class file read; > > class unix_stream_socket { read write }; > > class unix_dgram_socket { read write sendto }; > > } > > > > #============= fail2ban_t ============== > > allow fail2ban_t self:unix_dgram_socket write; > > allow fail2ban_t syslogd_t:unix_dgram_socket sendto; > > > > #============= iptables_t ============== > > allow iptables_t fail2ban_t:unix_stream_socket { read write }; > > allow iptables_t fail2ban_t:unix_dgram_socket { read write }; > > allow iptables_t initrc_t:unix_dgram_socket { read write }; > > > > #============= system_mail_t ============== > > allow system_mail_t fail2ban_t:unix_stream_socket { read write }; > > allow system_mail_t fail2ban_t:unix_dgram_socket { read write }; > > allow system_mail_t usr_t:file read; > > > > #============= sendmail_t ============== > > allow sendmail_t initrc_t:unix_dgram_socket { read write }; > > > > ===============8<==================================================== > > > > I am concious that this is not ideal and so I have asked on the fail2ban > > list if someone with more technical expertise than me can help clean up > > fail2ban with respect to selinux. > > > > Fortunately Arturo "Buanzo" Busleiman, one of the developers, has > > offered to take a look at this. (I am also copying this email to the > > fail2ban list). > > > > I would very much appreciate it if Dominick, Daniel, and anyone else who > > can help, could liaise with Arturo so that this important security > > package could work cleanly with selinux. > > > > I will do what I can too - but I should just point out that I can just > > about spell "patch" and only if I'm really desperate would I ever try to > > apply one! > > > > Thanks in advance. > > Thanks again for your help. I'm going to try to spend some time looking into these issues. Best regards Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From misc.lists at blueyonder.co.uk Mon Dec 7 22:17:26 2009 From: misc.lists at blueyonder.co.uk (Arthur Dent) Date: Mon, 07 Dec 2009 22:17:26 +0000 Subject: Logrotate frustration - Selinux & Fail2Ban In-Reply-To: <4B1CFA1E.4010504@redhat.com> References: <1260092312.3083.10.camel@localhost> <20091206115908.GA2886@localhost.localdomain> <1260135861.3083.37.camel@localhost> <4B1CFA1E.4010504@redhat.com> Message-ID: <1260224246.3056.29.camel@localhost> On Mon, 2009-12-07 at 13:50 +0100, Miroslav Grepl wrote: > On 12/06/2009 10:44 PM, Arthur Dent wrote: > > On Sun, 2009-12-06 at 12:59 +0100, Dominick Grift wrote: > > > > > On Sun, Dec 06, 2009 at 09:38:32AM +0000, Arthur Dent wrote: > > > > > [Snip] > > > > > > > The rule with the initrc_t type is due to missing policy. It is encouraged to implement policy for all init daemons. > > > > > > With regard to the other rules you can, i guess, basically allow the access required, > > > > > > But always go through the checklist: > > > > > > 1. are the parties in an interaction labeled correctly? (matchpatchcon/restorecon/semanage/chcon) > > > 2. are there any booleans or types that facilitate a certain interaction? (audit2allow) > > > 3. is there a misconfiguration in some application? (see if a program should be able to do what it wants) > > > 3. is there a bug in some application? (is the denial due to a bug in an application?) > > > 4. is there a bug in the selinux policy? (missing policy to allow a certain interaction?) > > > 5. is it a break in attempt (is the application compromised. > > > > > > taking these 5 golden rules into concideration. i have some questions: > > > > > > allow logrotate_t fail2ban_var_run_t:sock_file write > > > - why would logrotate have to write to a fail2ban sock file? (this may be a bug in fail2ban, maybe leaked file descriptor. does this denial cause any loss in functionality? if not consider silently denying it) > > > > > > allow logrotate_t squid_log_t:lnk_file rename; > > > - why does squidgaurd, or whatever managed squid_log_t lnk_file, create a lnk_file in /var/log/... This is obviously not common behaviour afaik. That may be the reason why is denied. > > > > > > withregard to the rules with mail_spool_t type i would like to know if and why logrotate wants to rotate spool files. is this expeected behaviour of logrotate or are the mail_spool_t object mislabeled? > > > > > > so in conclusion the only denial that i am somewhat comfortable with is the squid link file denial. This may be some uncommon behaviour of squid/squidgaurd that selinux policy currently does not support (when confirmed that squidgaurd indeed creates a lnk file in /var/log for some reason , then implement policy to allow logrotate to rename the link (and what else it may need to do with the lnk_file.) > > > > > > See what runs initrc_t (ps auxZ) and consider writing policy for this init daemon. By implementing policy for init daemon you prtect the system plus you achive that confined domain do not have to interact with the unconfined initrc_t domain. > > > > > OK - I'm going to change the focus of this question slightly here. > > > > Many of my AVCs do in fact relate to Fail2Ban and in fact running ps > > auxZ shows the following: > > > > # ps auxZ | grep init > > system_u:system_r:init_t:s0 root 1 0.0 0.0 2008 164 ? Ss Dec02 0:03 /sbin/init > > system_u:system_r:initrc_t:s0 ddclient 1673 0.0 0.7 10228 2956 ? S Dec02 1:00 ddclient - sleeping for 130 seconds > > system_u:system_r:initrc_t:s0 root 1827 0.1 0.5 75940 2156 ? Sl Dec02 6:52 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -x > > system_u:system_r:initrc_t:s0 root 1830 0.0 0.0 2904 348 ? S Dec02 0:17 /usr/libexec/gam_server > > unconfined_u:system_r:initrc_t:s0 clamav 13149 0.3 28.8 220652 109928 ? Ssl 05:50 1:30 /usr/local/sbin/clamd > > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 14886 1.0 0.1 4200 720 pts/0 S+ 12:08 0:00 grep init > > > > > Arthur, > > what's your version of selinux-policy ? > # rpm -q selinux-policy selinux-policy-targeted > > What is the output of the following command: > > # matchpathcon /usr/bin/fail2ban-server > # rpm -q selinux-policy selinux-policy-targeted selinux-policy-3.6.12-88.fc11.noarch # matchpathcon /usr/bin/fail2ban-server /usr/bin/fail2ban-server system_u:object_r:fail2ban_exec_t:s0 > > My Fail2Ban policy has also grown over the months and now looks like > > this: > > ===============8<==================================================== > > module myfail2ban 11.1.3; > > > > require { > > type iptables_t; > > type system_mail_t; > > type fail2ban_t; > > type usr_t; > > type syslogd_t; > > type sendmail_t; > > type initrc_t; > > class file read; > > class unix_stream_socket { read write }; > > class unix_dgram_socket { read write sendto }; > > } > > > > #============= fail2ban_t ============== > > allow fail2ban_t self:unix_dgram_socket write; > > allow fail2ban_t syslogd_t:unix_dgram_socket sendto; > > > > #============= iptables_t ============== > > allow iptables_t fail2ban_t:unix_stream_socket { read write }; > > allow iptables_t fail2ban_t:unix_dgram_socket { read write }; > > allow iptables_t initrc_t:unix_dgram_socket { read write }; > > > > #============= system_mail_t ============== > > allow system_mail_t fail2ban_t:unix_stream_socket { read write }; > > allow system_mail_t fail2ban_t:unix_dgram_socket { read write }; > > allow system_mail_t usr_t:file read; > > > > #============= sendmail_t ============== > > allow sendmail_t initrc_t:unix_dgram_socket { read write }; > > > > ===============8<==================================================== > > > > > Actually fail2ban leaking file descriptors. > # rpm -q fail2ban > Also do not use gam_server with fail2ban, change it to polling mode please. I used to use the version of fail2ban from yum - but a recent perl update caused a bug. To get the fixed version in a timely manner I had to install F2B from source. I guess the rpm has now been updated and I could go back to it... > > I am concious that this is not ideal and so I have asked on the fail2ban > > list if someone with more technical expertise than me can help clean up > > fail2ban with respect to selinux. > > > > Fortunately Arturo "Buanzo" Busleiman, one of the developers, has > > offered to take a look at this. (I am also copying this email to the > > fail2ban list). > > > > I would very much appreciate it if Dominick, Daniel, and anyone else who > > can help, could liaise with Arturo so that this important security > > package could work cleanly with selinux. > > > > I will do what I can too - but I should just point out that I can just > > about spell "patch" and only if I'm really desperate would I ever try to > > apply one! > > > > Thanks in advance. > > > > Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From domg472 at gmail.com Mon Dec 7 22:17:58 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 7 Dec 2009 23:17:58 +0100 Subject: Logrotate frustration - Selinux & Fail2Ban In-Reply-To: <1260223906.3056.24.camel@localhost> References: <1260092312.3083.10.camel@localhost> <20091206115908.GA2886@localhost.localdomain> <1260135861.3083.37.camel@localhost> <20091207114947.GB2942@localhost.localdomain> <1260223906.3056.24.camel@localhost> Message-ID: <20091207221757.GB6387@localhost.localdomain> On Mon, Dec 07, 2009 at 10:11:46PM +0000, Arthur Dent wrote: > On Mon, 2009-12-07 at 12:49 +0100, Dominick Grift wrote: > > On Sun, Dec 06, 2009 at 09:44:21PM +0000, Arthur Dent wrote: > > > On Sun, 2009-12-06 at 12:59 +0100, Dominick Grift wrote: > > > > On Sun, Dec 06, 2009 at 09:38:32AM +0000, Arthur Dent wrote: > > > > > > > > > > > [Snip] > > > > > > > The rule with the initrc_t type is due to missing policy. It is encouraged to implement policy for all init daemons. > > > > > > > > With regard to the other rules you can, i guess, basically allow the access required, > > > > > > > > But always go through the checklist: > > > > > > > > 1. are the parties in an interaction labeled correctly? (matchpatchcon/restorecon/semanage/chcon) > > > > 2. are there any booleans or types that facilitate a certain interaction? (audit2allow) > > > > 3. is there a misconfiguration in some application? (see if a program should be able to do what it wants) > > > > 3. is there a bug in some application? (is the denial due to a bug in an application?) > > > > 4. is there a bug in the selinux policy? (missing policy to allow a certain interaction?) > > > > 5. is it a break in attempt (is the application compromised. > > > > > > > > taking these 5 golden rules into concideration. i have some questions: > > > > > > > > allow logrotate_t fail2ban_var_run_t:sock_file write > > > > - why would logrotate have to write to a fail2ban sock file? (this may be a bug in fail2ban, maybe leaked file descriptor. does this denial cause any loss in functionality? if not consider silently denying it) > > > > > > > > allow logrotate_t squid_log_t:lnk_file rename; > > > > - why does squidgaurd, or whatever managed squid_log_t lnk_file, create a lnk_file in /var/log/... This is obviously not common behaviour afaik. That may be the reason why is denied. > > > > > > > > withregard to the rules with mail_spool_t type i would like to know if and why logrotate wants to rotate spool files. is this expeected behaviour of logrotate or are the mail_spool_t object mislabeled? > > > > > > > > so in conclusion the only denial that i am somewhat comfortable with is the squid link file denial. This may be some uncommon behaviour of squid/squidgaurd that selinux policy currently does not support (when confirmed that squidgaurd indeed creates a lnk file in /var/log for some reason , then implement policy to allow logrotate to rename the link (and what else it may need to do with the lnk_file.) > > > > > > > > See what runs initrc_t (ps auxZ) and consider writing policy for this init daemon. By implementing policy for init daemon you prtect the system plus you achive that confined domain do not have to interact with the unconfined initrc_t domain. > > > > > > OK - I'm going to change the focus of this question slightly here. > > > > > > Many of my AVCs do in fact relate to Fail2Ban and in fact running ps > > > auxZ shows the following: > > > > > > # ps auxZ | grep init > > > system_u:system_r:init_t:s0 root 1 0.0 0.0 2008 164 ? Ss Dec02 0:03 /sbin/init > > > system_u:system_r:initrc_t:s0 ddclient 1673 0.0 0.7 10228 2956 ? S Dec02 1:00 ddclient - sleeping for 130 seconds > > > system_u:system_r:initrc_t:s0 root 1827 0.1 0.5 75940 2156 ? Sl Dec02 6:52 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -x > > > system_u:system_r:initrc_t:s0 root 1830 0.0 0.0 2904 348 ? S Dec02 0:17 /usr/libexec/gam_server > > > unconfined_u:system_r:initrc_t:s0 clamav 13149 0.3 28.8 220652 109928 ? Ssl 05:50 1:30 /usr/local/sbin/clamd > > > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 14886 1.0 0.1 4200 720 pts/0 S+ 12:08 0:00 grep init > > > > You are using old policy. > > Am I? > # rpm -q selinux-policy selinux-policy-targeted > selinux-policy-3.6.12-88.fc11.noarch > selinux-policy-targeted-3.6.12-88.fc11.noarch > > > > [root at localhost ~]# semanage fcontext -l | grep fail2ban > > /etc/rc\.d/init\.d/fail2ban regular file system_u:object_r:fail2ban_initrc_exec_t:s0 > > /usr/bin/fail2ban regular file system_u:object_r:fail2ban_exec_t:s0 > > /usr/bin/fail2ban-server regular file system_u:object_r:fail2ban_exec_t:s0 > > /var/lib/fail2ban(/.*)? all files system_u:object_r:fail2ban_var_lib_t:s0 > > /var/log/fail2ban\.log regular file system_u:object_r:fail2ban_log_t:s0 > > /var/run/fail2ban.* all files system_u:object_r:fail2ban_var_run_t:s0 > > # semanage fcontext -l | grep fail2ban > /etc/rc\.d/init\.d/fail2ban regular file system_u:object_r:fail2ban_initrc_exec_t:s0 > /usr/bin/fail2ban regular file system_u:object_r:fail2ban_exec_t:s0 > /usr/bin/fail2ban-server regular file system_u:object_r:fail2ban_exec_t:s0 > /var/lib/fail2ban(/.*)? all files system_u:object_r:fail2ban_var_lib_t:s0 > /var/log/fail2ban\.log regular file system_u:object_r:fail2ban_log_t:s0 > /var/run/fail2ban.* all files system_u:object_r:fail2ban_var_run_t:s0 > > I may be wrong, but to me my results look the same? They look the same indeed. question remains, why does fail2ban-server runs in the init script domain? matchpathcon /usr/bin/fail2ban-server ( could it be that the file is mislabeled? ) > > > > > But anyways with regard to SELinux issues: SELinux is a framework that lets you configure the access that various processes have. > > It just like iptables/netfilter where a particular port is not open. The netfilter framework allows you to open it and the iptables frontend is a way to implement it. > > > > No policy is ever perfect. So for professionals it is a good idea to just learn how to manage an SELinux environment. > > > > One thing to keep in mind is that processes running initrc_r do not have policy (in your case ddclient, gameserver, clamd, and fail2ban-server). To fix this in a managable way it is encourage to confine these init daemons first. > > > > Writing/implementing policy for a init daemon is not particularly hard and you do not have to be a programmer to do so. > > > > With regard to fail2ban-server, you could start by trying to label the fail2ban executable (/usr/bin/fail2ban-server) with the fail2ban executable type (semanage fcontext -a -t fail2ban_exec_t /usr/bin/fail2ban-server; restorecon -v /usr/bin/fail2ban-server). This should atleast get the fail2ban-server process out of the initrc_t domain and into the fail2ban domain. From there on, youre on the right track. > > Do I still need to do this given the results of my semanage command > above? > > If not, why should I need all the rules in my policy? > > Actually - I may answer that myself. I keep up to date with selinux > policies using yum. On the other hand, I create local policies each time > an AVC rears its head, but what I DON'T do - and perhaps I should - is > revisit my local rules each time a new policy is issued. I guess I just > add and add and add my rules as they are needed. This means that my > local policy only ever grows. I'm afraid I don't have the detailed > understanding (or the time) to investigate the effects of each new > policy... > > Should I perhaps just remove my "myfail2ban" policy and see what AVCs > arise? > > What I tend to do is to leave my policies grow this way until a new > version of Fedora is released - I usually upgrade during my Christmas > and summer holidays - and start a new policy from scratch then (this > explains the naming convention I use "myfail2ban 11.1.3" is the third > minor revision of the second major revision of my fail2ban policy on F11 > - When I uprade to F12 I will start with "myfail2ban 12.0.1") > > > > As for ddclient, gam_server and clamd it may require that you write a policy from scratch. Also usually not hard to do. In a nutshell: > > > > 1. create a type for the process > > 2. create a type for the executable file > > 3. declare the two types init_daemon_domain(). > > 4. label the executable file with the type you declared executable file. > > 5. start service (if needed in permissive mode during policy development stage) and see whether the process runs with the declared type for the process. > > 6. use ausearch/audit2allow to write rule that define how you process type can interact with other types. > > 7. make sure that interacting with type initrc_t means its trying to interact with a process that is not confined (does not have policy yet) > > This is very helpful advice. Thank you. > > However, should I need to do this? ddclient was installed using yum - > surely the package maintainer should have done this? > > It's true though that gam_server came with fail2ban and I installed that > from source (I think I need to look at that - especially given Miroslav > Grepl's post below. > > Clamd is also installed from source, but surely, as this is an > application in such a widespread use, should it not be included in > selinux-policy-targeted? > > > > after that, its just the five golden rules i mentioned in a previous post. > > > > 1. make sure parties in an interaction have the expected type. > > 2. make sure you check for any booleans/custom types that may provide the access it needs. > > 3. make sure you app is configured properly. > > 4. make sure you dont allow access that your app needs because it has a bug. > > 5. implement policy. > > > > > > > > My Fail2Ban policy has also grown over the months and now looks like > > > this: > > > ===============8<==================================================== > > > module myfail2ban 11.1.3; > > > > > > require { > > > type iptables_t; > > > type system_mail_t; > > > type fail2ban_t; > > > type usr_t; > > > type syslogd_t; > > > type sendmail_t; > > > type initrc_t; > > > class file read; > > > class unix_stream_socket { read write }; > > > class unix_dgram_socket { read write sendto }; > > > } > > > > > > #============= fail2ban_t ============== > > > allow fail2ban_t self:unix_dgram_socket write; > > > allow fail2ban_t syslogd_t:unix_dgram_socket sendto; > > > > > > #============= iptables_t ============== > > > allow iptables_t fail2ban_t:unix_stream_socket { read write }; > > > allow iptables_t fail2ban_t:unix_dgram_socket { read write }; > > > allow iptables_t initrc_t:unix_dgram_socket { read write }; > > > > > > #============= system_mail_t ============== > > > allow system_mail_t fail2ban_t:unix_stream_socket { read write }; > > > allow system_mail_t fail2ban_t:unix_dgram_socket { read write }; > > > allow system_mail_t usr_t:file read; > > > > > > #============= sendmail_t ============== > > > allow sendmail_t initrc_t:unix_dgram_socket { read write }; > > > > > > ===============8<==================================================== > > > > > > I am concious that this is not ideal and so I have asked on the fail2ban > > > list if someone with more technical expertise than me can help clean up > > > fail2ban with respect to selinux. > > > > > > Fortunately Arturo "Buanzo" Busleiman, one of the developers, has > > > offered to take a look at this. (I am also copying this email to the > > > fail2ban list). > > > > > > I would very much appreciate it if Dominick, Daniel, and anyone else who > > > can help, could liaise with Arturo so that this important security > > > package could work cleanly with selinux. > > > > > > I will do what I can too - but I should just point out that I can just > > > about spell "patch" and only if I'm really desperate would I ever try to > > > apply one! > > > > > > Thanks in advance. > > > > > Thanks again for your help. > > I'm going to try to spend some time looking into these issues. > > Best regards > > Mark > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From misc.lists at blueyonder.co.uk Mon Dec 7 22:30:22 2009 From: misc.lists at blueyonder.co.uk (Arthur Dent) Date: Mon, 07 Dec 2009 22:30:22 +0000 Subject: Logrotate frustration In-Reply-To: <4B1D7275.6020400@redhat.com> References: <1260092312.3083.10.camel@localhost> <4B1D7275.6020400@redhat.com> Message-ID: <1260225022.3056.40.camel@localhost> On Mon, 2009-12-07 at 16:24 -0500, Daniel J Walsh wrote: > On 12/06/2009 04:38 AM, Arthur Dent wrote: > > Hello all, > > > > Its seems that almost every week logrotate is throwing up a new AVC. I > > have an almost vanilla F11 install with most packages installed via yum > > and yet I keep getting these. Each time I audit2allow and build a new > > policy. My "mylogr.te" is now at version 7. Am I missing a bool or is > > there something else I'm lacking? > > > > Here is the latest version of my policy: > > > > > > ===============8<================================================== > > > > module mylogr 11.1.7; > > > > require { > > type mail_spool_t; > > type logrotate_t; > > type fail2ban_var_run_t; > > type initrc_t; > > type squid_log_t; > > class dir {read open write remove_name}; > > class file { getattr read write open}; > > class file setattr; > > class sock_file write; > > class unix_stream_socket connectto; > > class lnk_file rename; > > } > > > > #============= logrotate_t ============== > > allow logrotate_t mail_spool_t:file { getattr read write open }; > > allow logrotate_t mail_spool_t:dir { read open write remove_name}; > > allow logrotate_t mail_spool_t:file setattr; > > allow logrotate_t fail2ban_var_run_t:sock_file write; > > allow logrotate_t initrc_t:unix_stream_socket connectto; > > allow logrotate_t squid_log_t:lnk_file rename; > > > > ===============8<================================================== > > > > > > This was today's AVC that necessitated the inclusion of the squid stuff: > > > > ===============8<================================================== > > Raw Audit Messages : > > > > node=mydomain.org.uk type=AVC msg=audit(1260069452.494:45041): avc: denied { rename } for pid=12302 comm="logrotate" name="squidGuard.log" dev=sda5 ino=387195 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:squid_log_t:s0 tclass=lnk_file > > node=mydomain.org.uk type=SYSCALL msg=audit(1260069452.494:45041): arch=40000003 syscall=38 success=no exit=-13 a0=890b130 a1=8908760 a2=890b060 a3=0 items=0 ppid=12300 pid=12302 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2275 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null) > > ===============8<================================================== > > > > > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > I can allow logrotate to manage log lnk_files, and allow it to write to the fail2ban socket. > > Are you using a custom logrotate to rotate mail_spool? > > Why is I think that my problem with mailspool/logrotate is that it relates to my mail backup system in which procmail places a copy of every mail (in mbox format) onto a separate partition on the same machine. This seemed to cause labelling problems and we went round the houses on this issue a while back ("Partitions Mounted by fstab" 5 March 2008 - https://www.redhat.com/archives/fedora-selinux-list/2008-March/msg00030.html) Thanks for your help - much appreciated... Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From domg472 at gmail.com Mon Dec 7 22:32:58 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 7 Dec 2009 23:32:58 +0100 Subject: Logrotate frustration - Selinux & Fail2Ban In-Reply-To: <1260223906.3056.24.camel@localhost> References: <1260092312.3083.10.camel@localhost> <20091206115908.GA2886@localhost.localdomain> <1260135861.3083.37.camel@localhost> <20091207114947.GB2942@localhost.localdomain> <1260223906.3056.24.camel@localhost> Message-ID: <20091207223257.GC6387@localhost.localdomain> On Mon, Dec 07, 2009 at 10:11:46PM +0000, Arthur Dent wrote: > On Mon, 2009-12-07 at 12:49 +0100, Dominick Grift wrote: > > On Sun, Dec 06, 2009 at 09:44:21PM +0000, Arthur Dent wrote: > > > On Sun, 2009-12-06 at 12:59 +0100, Dominick Grift wrote: > > > > On Sun, Dec 06, 2009 at 09:38:32AM +0000, Arthur Dent wrote: > > > > > > > > > > > [Snip] > > > > > > > The rule with the initrc_t type is due to missing policy. It is encouraged to implement policy for all init daemons. > > > > > > > > With regard to the other rules you can, i guess, basically allow the access required, > > > > > > > > But always go through the checklist: > > > > > > > > 1. are the parties in an interaction labeled correctly? (matchpatchcon/restorecon/semanage/chcon) > > > > 2. are there any booleans or types that facilitate a certain interaction? (audit2allow) > > > > 3. is there a misconfiguration in some application? (see if a program should be able to do what it wants) > > > > 3. is there a bug in some application? (is the denial due to a bug in an application?) > > > > 4. is there a bug in the selinux policy? (missing policy to allow a certain interaction?) > > > > 5. is it a break in attempt (is the application compromised. > > > > > > > > taking these 5 golden rules into concideration. i have some questions: > > > > > > > > allow logrotate_t fail2ban_var_run_t:sock_file write > > > > - why would logrotate have to write to a fail2ban sock file? (this may be a bug in fail2ban, maybe leaked file descriptor. does this denial cause any loss in functionality? if not consider silently denying it) > > > > > > > > allow logrotate_t squid_log_t:lnk_file rename; > > > > - why does squidgaurd, or whatever managed squid_log_t lnk_file, create a lnk_file in /var/log/... This is obviously not common behaviour afaik. That may be the reason why is denied. > > > > > > > > withregard to the rules with mail_spool_t type i would like to know if and why logrotate wants to rotate spool files. is this expeected behaviour of logrotate or are the mail_spool_t object mislabeled? > > > > > > > > so in conclusion the only denial that i am somewhat comfortable with is the squid link file denial. This may be some uncommon behaviour of squid/squidgaurd that selinux policy currently does not support (when confirmed that squidgaurd indeed creates a lnk file in /var/log for some reason , then implement policy to allow logrotate to rename the link (and what else it may need to do with the lnk_file.) > > > > > > > > See what runs initrc_t (ps auxZ) and consider writing policy for this init daemon. By implementing policy for init daemon you prtect the system plus you achive that confined domain do not have to interact with the unconfined initrc_t domain. > > > > > > OK - I'm going to change the focus of this question slightly here. > > > > > > Many of my AVCs do in fact relate to Fail2Ban and in fact running ps > > > auxZ shows the following: > > > > > > # ps auxZ | grep init > > > system_u:system_r:init_t:s0 root 1 0.0 0.0 2008 164 ? Ss Dec02 0:03 /sbin/init > > > system_u:system_r:initrc_t:s0 ddclient 1673 0.0 0.7 10228 2956 ? S Dec02 1:00 ddclient - sleeping for 130 seconds > > > system_u:system_r:initrc_t:s0 root 1827 0.1 0.5 75940 2156 ? Sl Dec02 6:52 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -x > > > system_u:system_r:initrc_t:s0 root 1830 0.0 0.0 2904 348 ? S Dec02 0:17 /usr/libexec/gam_server > > > unconfined_u:system_r:initrc_t:s0 clamav 13149 0.3 28.8 220652 109928 ? Ssl 05:50 1:30 /usr/local/sbin/clamd > > > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 14886 1.0 0.1 4200 720 pts/0 S+ 12:08 0:00 grep init > > > > You are using old policy. > > Am I? > # rpm -q selinux-policy selinux-policy-targeted > selinux-policy-3.6.12-88.fc11.noarch > selinux-policy-targeted-3.6.12-88.fc11.noarch > > > > [root at localhost ~]# semanage fcontext -l | grep fail2ban > > /etc/rc\.d/init\.d/fail2ban regular file system_u:object_r:fail2ban_initrc_exec_t:s0 > > /usr/bin/fail2ban regular file system_u:object_r:fail2ban_exec_t:s0 > > /usr/bin/fail2ban-server regular file system_u:object_r:fail2ban_exec_t:s0 > > /var/lib/fail2ban(/.*)? all files system_u:object_r:fail2ban_var_lib_t:s0 > > /var/log/fail2ban\.log regular file system_u:object_r:fail2ban_log_t:s0 > > /var/run/fail2ban.* all files system_u:object_r:fail2ban_var_run_t:s0 > > # semanage fcontext -l | grep fail2ban > /etc/rc\.d/init\.d/fail2ban regular file system_u:object_r:fail2ban_initrc_exec_t:s0 > /usr/bin/fail2ban regular file system_u:object_r:fail2ban_exec_t:s0 > /usr/bin/fail2ban-server regular file system_u:object_r:fail2ban_exec_t:s0 > /var/lib/fail2ban(/.*)? all files system_u:object_r:fail2ban_var_lib_t:s0 > /var/log/fail2ban\.log regular file system_u:object_r:fail2ban_log_t:s0 > /var/run/fail2ban.* all files system_u:object_r:fail2ban_var_run_t:s0 > > I may be wrong, but to me my results look the same? > > > > > But anyways with regard to SELinux issues: SELinux is a framework that lets you configure the access that various processes have. > > It just like iptables/netfilter where a particular port is not open. The netfilter framework allows you to open it and the iptables frontend is a way to implement it. > > > > No policy is ever perfect. So for professionals it is a good idea to just learn how to manage an SELinux environment. > > > > One thing to keep in mind is that processes running initrc_r do not have policy (in your case ddclient, gameserver, clamd, and fail2ban-server). To fix this in a managable way it is encourage to confine these init daemons first. > > > > Writing/implementing policy for a init daemon is not particularly hard and you do not have to be a programmer to do so. > > > > With regard to fail2ban-server, you could start by trying to label the fail2ban executable (/usr/bin/fail2ban-server) with the fail2ban executable type (semanage fcontext -a -t fail2ban_exec_t /usr/bin/fail2ban-server; restorecon -v /usr/bin/fail2ban-server). This should atleast get the fail2ban-server process out of the initrc_t domain and into the fail2ban domain. From there on, youre on the right track. > > Do I still need to do this given the results of my semanage command > above? Well the specification for /usr/bin/fail2ban-server looks good. but the context in which fail2ban-server is running does not correspond to the spec. So i suspect the file may be mislabeled. a restorecon -v /usr/bin/fail2ban-server would clear that up. The type of that location should not be bin_t. > > If not, why should I need all the rules in my policy? > > Actually - I may answer that myself. I keep up to date with selinux > policies using yum. On the other hand, I create local policies each time > an AVC rears its head, but what I DON'T do - and perhaps I should - is > revisit my local rules each time a new policy is issued. I guess I just > add and add and add my rules as they are needed. This means that my > local policy only ever grows. I'm afraid I don't have the detailed > understanding (or the time) to investigate the effects of each new > policy... > > Should I perhaps just remove my "myfail2ban" policy and see what AVCs > arise? Well you can always try, given that you have the source policy, and given that you can reinstall that if the avcs turn out to be identical programs evolve (fix bugs) policy should in my view evolve with the program. > > What I tend to do is to leave my policies grow this way until a new > version of Fedora is released - I usually upgrade during my Christmas > and summer holidays - and start a new policy from scratch then (this > explains the naming convention I use "myfail2ban 11.1.3" is the third > minor revision of the second major revision of my fail2ban policy on F11 > - When I uprade to F12 I will start with "myfail2ban 12.0.1") > > > > As for ddclient, gam_server and clamd it may require that you write a policy from scratch. Also usually not hard to do. In a nutshell: > > > > 1. create a type for the process > > 2. create a type for the executable file > > 3. declare the two types init_daemon_domain(). > > 4. label the executable file with the type you declared executable file. > > 5. start service (if needed in permissive mode during policy development stage) and see whether the process runs with the declared type for the process. > > 6. use ausearch/audit2allow to write rule that define how you process type can interact with other types. > > 7. make sure that interacting with type initrc_t means its trying to interact with a process that is not confined (does not have policy yet) > > This is very helpful advice. Thank you. > > However, should I need to do this? ddclient was installed using yum - Not all everything has policy yet and package maintainers arent responsible for providing selinux policy although it is a plus if they do provide policy for their package. It does not change the fact that the selinux framework allows you to implement policy yourself. > surely the package maintainer should have done this? > > It's true though that gam_server came with fail2ban and I installed that > from source (I think I need to look at that - especially given Miroslav > Grepl's post below. > > Clamd is also installed from source, but surely, as this is an > application in such a widespread use, should it not be included in > selinux-policy-targeted? The problem is the path where clamd executable file is. There may be policy for clamd but the policy expects the executable to be elsewhere. So if that is the case you could just label the executable with the clamd executable type. semanage fcontext -a -t clamd_exec_t /usr/local/sbin/clamd restorecon -v /usr/local/sbin/clamd ls -alZ /usr/local/sbin/clamd > > > > after that, its just the five golden rules i mentioned in a previous post. > > > > 1. make sure parties in an interaction have the expected type. > > 2. make sure you check for any booleans/custom types that may provide the access it needs. > > 3. make sure you app is configured properly. > > 4. make sure you dont allow access that your app needs because it has a bug. > > 5. implement policy. > > > > > > > > My Fail2Ban policy has also grown over the months and now looks like > > > this: > > > ===============8<==================================================== > > > module myfail2ban 11.1.3; > > > > > > require { > > > type iptables_t; > > > type system_mail_t; > > > type fail2ban_t; > > > type usr_t; > > > type syslogd_t; > > > type sendmail_t; > > > type initrc_t; > > > class file read; > > > class unix_stream_socket { read write }; > > > class unix_dgram_socket { read write sendto }; > > > } > > > > > > #============= fail2ban_t ============== > > > allow fail2ban_t self:unix_dgram_socket write; > > > allow fail2ban_t syslogd_t:unix_dgram_socket sendto; > > > > > > #============= iptables_t ============== > > > allow iptables_t fail2ban_t:unix_stream_socket { read write }; > > > allow iptables_t fail2ban_t:unix_dgram_socket { read write }; > > > allow iptables_t initrc_t:unix_dgram_socket { read write }; > > > > > > #============= system_mail_t ============== > > > allow system_mail_t fail2ban_t:unix_stream_socket { read write }; > > > allow system_mail_t fail2ban_t:unix_dgram_socket { read write }; > > > allow system_mail_t usr_t:file read; > > > > > > #============= sendmail_t ============== > > > allow sendmail_t initrc_t:unix_dgram_socket { read write }; > > > > > > ===============8<==================================================== > > > > > > I am concious that this is not ideal and so I have asked on the fail2ban > > > list if someone with more technical expertise than me can help clean up > > > fail2ban with respect to selinux. > > > > > > Fortunately Arturo "Buanzo" Busleiman, one of the developers, has > > > offered to take a look at this. (I am also copying this email to the > > > fail2ban list). > > > > > > I would very much appreciate it if Dominick, Daniel, and anyone else who > > > can help, could liaise with Arturo so that this important security > > > package could work cleanly with selinux. > > > > > > I will do what I can too - but I should just point out that I can just > > > about spell "patch" and only if I'm really desperate would I ever try to > > > apply one! > > > > > > Thanks in advance. > > > > > Thanks again for your help. > > I'm going to try to spend some time looking into these issues. > > Best regards > > Mark > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From misc.lists at blueyonder.co.uk Mon Dec 7 22:34:21 2009 From: misc.lists at blueyonder.co.uk (Arthur Dent) Date: Mon, 07 Dec 2009 22:34:21 +0000 Subject: Logrotate frustration - Selinux & Fail2Ban In-Reply-To: <20091207221757.GB6387@localhost.localdomain> References: <1260092312.3083.10.camel@localhost> <20091206115908.GA2886@localhost.localdomain> <1260135861.3083.37.camel@localhost> <20091207114947.GB2942@localhost.localdomain> <1260223906.3056.24.camel@localhost> <20091207221757.GB6387@localhost.localdomain> Message-ID: <1260225261.3056.43.camel@localhost> On Mon, 2009-12-07 at 23:17 +0100, Dominick Grift wrote: > On Mon, Dec 07, 2009 at 10:11:46PM +0000, Arthur Dent wrote: > > On Mon, 2009-12-07 at 12:49 +0100, Dominick Grift wrote: > > > On Sun, Dec 06, 2009 at 09:44:21PM +0000, Arthur Dent wrote: > > > > On Sun, 2009-12-06 at 12:59 +0100, Dominick Grift wrote: > > > > > On Sun, Dec 06, 2009 at 09:38:32AM +0000, Arthur Dent wrote: > > > > > > > > > > > > > > [Snip] > > > > > > > > > The rule with the initrc_t type is due to missing policy. It is encouraged to implement policy for all init daemons. > > > > > > > > > > With regard to the other rules you can, i guess, basically allow the access required, > > > > > > > > > > But always go through the checklist: > > > > > > > > > > 1. are the parties in an interaction labeled correctly? (matchpatchcon/restorecon/semanage/chcon) > > > > > 2. are there any booleans or types that facilitate a certain interaction? (audit2allow) > > > > > 3. is there a misconfiguration in some application? (see if a program should be able to do what it wants) > > > > > 3. is there a bug in some application? (is the denial due to a bug in an application?) > > > > > 4. is there a bug in the selinux policy? (missing policy to allow a certain interaction?) > > > > > 5. is it a break in attempt (is the application compromised. > > > > > > > > > > taking these 5 golden rules into concideration. i have some questions: > > > > > > > > > > allow logrotate_t fail2ban_var_run_t:sock_file write > > > > > - why would logrotate have to write to a fail2ban sock file? (this may be a bug in fail2ban, maybe leaked file descriptor. does this denial cause any loss in functionality? if not consider silently denying it) > > > > > > > > > > allow logrotate_t squid_log_t:lnk_file rename; > > > > > - why does squidgaurd, or whatever managed squid_log_t lnk_file, create a lnk_file in /var/log/... This is obviously not common behaviour afaik. That may be the reason why is denied. > > > > > > > > > > withregard to the rules with mail_spool_t type i would like to know if and why logrotate wants to rotate spool files. is this expeected behaviour of logrotate or are the mail_spool_t object mislabeled? > > > > > > > > > > so in conclusion the only denial that i am somewhat comfortable with is the squid link file denial. This may be some uncommon behaviour of squid/squidgaurd that selinux policy currently does not support (when confirmed that squidgaurd indeed creates a lnk file in /var/log for some reason , then implement policy to allow logrotate to rename the link (and what else it may need to do with the lnk_file.) > > > > > > > > > > See what runs initrc_t (ps auxZ) and consider writing policy for this init daemon. By implementing policy for init daemon you prtect the system plus you achive that confined domain do not have to interact with the unconfined initrc_t domain. > > > > > > > > OK - I'm going to change the focus of this question slightly here. > > > > > > > > Many of my AVCs do in fact relate to Fail2Ban and in fact running ps > > > > auxZ shows the following: > > > > > > > > # ps auxZ | grep init > > > > system_u:system_r:init_t:s0 root 1 0.0 0.0 2008 164 ? Ss Dec02 0:03 /sbin/init > > > > system_u:system_r:initrc_t:s0 ddclient 1673 0.0 0.7 10228 2956 ? S Dec02 1:00 ddclient - sleeping for 130 seconds > > > > system_u:system_r:initrc_t:s0 root 1827 0.1 0.5 75940 2156 ? Sl Dec02 6:52 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -x > > > > system_u:system_r:initrc_t:s0 root 1830 0.0 0.0 2904 348 ? S Dec02 0:17 /usr/libexec/gam_server > > > > unconfined_u:system_r:initrc_t:s0 clamav 13149 0.3 28.8 220652 109928 ? Ssl 05:50 1:30 /usr/local/sbin/clamd > > > > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 14886 1.0 0.1 4200 720 pts/0 S+ 12:08 0:00 grep init > > > > > > You are using old policy. > > > > Am I? > > # rpm -q selinux-policy selinux-policy-targeted > > selinux-policy-3.6.12-88.fc11.noarch > > selinux-policy-targeted-3.6.12-88.fc11.noarch > > > > > > > [root at localhost ~]# semanage fcontext -l | grep fail2ban > > > /etc/rc\.d/init\.d/fail2ban regular file system_u:object_r:fail2ban_initrc_exec_t:s0 > > > /usr/bin/fail2ban regular file system_u:object_r:fail2ban_exec_t:s0 > > > /usr/bin/fail2ban-server regular file system_u:object_r:fail2ban_exec_t:s0 > > > /var/lib/fail2ban(/.*)? all files system_u:object_r:fail2ban_var_lib_t:s0 > > > /var/log/fail2ban\.log regular file system_u:object_r:fail2ban_log_t:s0 > > > /var/run/fail2ban.* all files system_u:object_r:fail2ban_var_run_t:s0 > > > > # semanage fcontext -l | grep fail2ban > > /etc/rc\.d/init\.d/fail2ban regular file system_u:object_r:fail2ban_initrc_exec_t:s0 > > /usr/bin/fail2ban regular file system_u:object_r:fail2ban_exec_t:s0 > > /usr/bin/fail2ban-server regular file system_u:object_r:fail2ban_exec_t:s0 > > /var/lib/fail2ban(/.*)? all files system_u:object_r:fail2ban_var_lib_t:s0 > > /var/log/fail2ban\.log regular file system_u:object_r:fail2ban_log_t:s0 > > /var/run/fail2ban.* all files system_u:object_r:fail2ban_var_run_t:s0 > > > > I may be wrong, but to me my results look the same? > > They look the same indeed. question remains, why does fail2ban-server runs in the init script domain? > > matchpathcon /usr/bin/fail2ban-server > > ( could it be that the file is mislabeled? ) # matchpathcon /usr/bin/fail2ban-server /usr/bin/fail2ban-server system_u:object_r:fail2ban_exec_t:s0 Is that what you would expect to see? Thanks for your help - much appreciated... Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From domg472 at gmail.com Mon Dec 7 22:36:40 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 7 Dec 2009 23:36:40 +0100 Subject: Logrotate frustration - Selinux & Fail2Ban In-Reply-To: <1260225261.3056.43.camel@localhost> References: <1260092312.3083.10.camel@localhost> <20091206115908.GA2886@localhost.localdomain> <1260135861.3083.37.camel@localhost> <20091207114947.GB2942@localhost.localdomain> <1260223906.3056.24.camel@localhost> <20091207221757.GB6387@localhost.localdomain> <1260225261.3056.43.camel@localhost> Message-ID: <20091207223639.GD6387@localhost.localdomain> On Mon, Dec 07, 2009 at 10:34:21PM +0000, Arthur Dent wrote: > On Mon, 2009-12-07 at 23:17 +0100, Dominick Grift wrote: > > On Mon, Dec 07, 2009 at 10:11:46PM +0000, Arthur Dent wrote: > > > On Mon, 2009-12-07 at 12:49 +0100, Dominick Grift wrote: > > > > On Sun, Dec 06, 2009 at 09:44:21PM +0000, Arthur Dent wrote: > > > > > On Sun, 2009-12-06 at 12:59 +0100, Dominick Grift wrote: > > > > > > On Sun, Dec 06, 2009 at 09:38:32AM +0000, Arthur Dent wrote: > > > > > > > > > > > > > > > > > [Snip] > > > > > > > > > > > The rule with the initrc_t type is due to missing policy. It is encouraged to implement policy for all init daemons. > > > > > > > > > > > > With regard to the other rules you can, i guess, basically allow the access required, > > > > > > > > > > > > But always go through the checklist: > > > > > > > > > > > > 1. are the parties in an interaction labeled correctly? (matchpatchcon/restorecon/semanage/chcon) > > > > > > 2. are there any booleans or types that facilitate a certain interaction? (audit2allow) > > > > > > 3. is there a misconfiguration in some application? (see if a program should be able to do what it wants) > > > > > > 3. is there a bug in some application? (is the denial due to a bug in an application?) > > > > > > 4. is there a bug in the selinux policy? (missing policy to allow a certain interaction?) > > > > > > 5. is it a break in attempt (is the application compromised. > > > > > > > > > > > > taking these 5 golden rules into concideration. i have some questions: > > > > > > > > > > > > allow logrotate_t fail2ban_var_run_t:sock_file write > > > > > > - why would logrotate have to write to a fail2ban sock file? (this may be a bug in fail2ban, maybe leaked file descriptor. does this denial cause any loss in functionality? if not consider silently denying it) > > > > > > > > > > > > allow logrotate_t squid_log_t:lnk_file rename; > > > > > > - why does squidgaurd, or whatever managed squid_log_t lnk_file, create a lnk_file in /var/log/... This is obviously not common behaviour afaik. That may be the reason why is denied. > > > > > > > > > > > > withregard to the rules with mail_spool_t type i would like to know if and why logrotate wants to rotate spool files. is this expeected behaviour of logrotate or are the mail_spool_t object mislabeled? > > > > > > > > > > > > so in conclusion the only denial that i am somewhat comfortable with is the squid link file denial. This may be some uncommon behaviour of squid/squidgaurd that selinux policy currently does not support (when confirmed that squidgaurd indeed creates a lnk file in /var/log for some reason , then implement policy to allow logrotate to rename the link (and what else it may need to do with the lnk_file.) > > > > > > > > > > > > See what runs initrc_t (ps auxZ) and consider writing policy for this init daemon. By implementing policy for init daemon you prtect the system plus you achive that confined domain do not have to interact with the unconfined initrc_t domain. > > > > > > > > > > OK - I'm going to change the focus of this question slightly here. > > > > > > > > > > Many of my AVCs do in fact relate to Fail2Ban and in fact running ps > > > > > auxZ shows the following: > > > > > > > > > > # ps auxZ | grep init > > > > > system_u:system_r:init_t:s0 root 1 0.0 0.0 2008 164 ? Ss Dec02 0:03 /sbin/init > > > > > system_u:system_r:initrc_t:s0 ddclient 1673 0.0 0.7 10228 2956 ? S Dec02 1:00 ddclient - sleeping for 130 seconds > > > > > system_u:system_r:initrc_t:s0 root 1827 0.1 0.5 75940 2156 ? Sl Dec02 6:52 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -x > > > > > system_u:system_r:initrc_t:s0 root 1830 0.0 0.0 2904 348 ? S Dec02 0:17 /usr/libexec/gam_server > > > > > unconfined_u:system_r:initrc_t:s0 clamav 13149 0.3 28.8 220652 109928 ? Ssl 05:50 1:30 /usr/local/sbin/clamd > > > > > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 14886 1.0 0.1 4200 720 pts/0 S+ 12:08 0:00 grep init > > > > > > > > You are using old policy. > > > > > > Am I? > > > # rpm -q selinux-policy selinux-policy-targeted > > > selinux-policy-3.6.12-88.fc11.noarch > > > selinux-policy-targeted-3.6.12-88.fc11.noarch > > > > > > > > > > [root at localhost ~]# semanage fcontext -l | grep fail2ban > > > > /etc/rc\.d/init\.d/fail2ban regular file system_u:object_r:fail2ban_initrc_exec_t:s0 > > > > /usr/bin/fail2ban regular file system_u:object_r:fail2ban_exec_t:s0 > > > > /usr/bin/fail2ban-server regular file system_u:object_r:fail2ban_exec_t:s0 > > > > /var/lib/fail2ban(/.*)? all files system_u:object_r:fail2ban_var_lib_t:s0 > > > > /var/log/fail2ban\.log regular file system_u:object_r:fail2ban_log_t:s0 > > > > /var/run/fail2ban.* all files system_u:object_r:fail2ban_var_run_t:s0 > > > > > > # semanage fcontext -l | grep fail2ban > > > /etc/rc\.d/init\.d/fail2ban regular file system_u:object_r:fail2ban_initrc_exec_t:s0 > > > /usr/bin/fail2ban regular file system_u:object_r:fail2ban_exec_t:s0 > > > /usr/bin/fail2ban-server regular file system_u:object_r:fail2ban_exec_t:s0 > > > /var/lib/fail2ban(/.*)? all files system_u:object_r:fail2ban_var_lib_t:s0 > > > /var/log/fail2ban\.log regular file system_u:object_r:fail2ban_log_t:s0 > > > /var/run/fail2ban.* all files system_u:object_r:fail2ban_var_run_t:s0 > > > > > > I may be wrong, but to me my results look the same? > > > > They look the same indeed. question remains, why does fail2ban-server runs in the init script domain? > > > > matchpathcon /usr/bin/fail2ban-server > > > > ( could it be that the file is mislabeled? ) > > # matchpathcon /usr/bin/fail2ban-server > /usr/bin/fail2ban-server system_u:object_r:fail2ban_exec_t:s0 > > Is that what you would expect to see? yes, now the question is, is the path labeled the way it should be: ls -alZ /usr/bin/fail2ban-server > > Thanks for your help - much appreciated... > > Mark > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From misc.lists at blueyonder.co.uk Mon Dec 7 22:44:15 2009 From: misc.lists at blueyonder.co.uk (Arthur Dent) Date: Mon, 07 Dec 2009 22:44:15 +0000 Subject: Logrotate frustration - Selinux & Fail2Ban In-Reply-To: <20091207223639.GD6387@localhost.localdomain> References: <1260092312.3083.10.camel@localhost> <20091206115908.GA2886@localhost.localdomain> <1260135861.3083.37.camel@localhost> <20091207114947.GB2942@localhost.localdomain> <1260223906.3056.24.camel@localhost> <20091207221757.GB6387@localhost.localdomain> <1260225261.3056.43.camel@localhost> <20091207223639.GD6387@localhost.localdomain> Message-ID: <1260225855.3056.47.camel@localhost> On Mon, 2009-12-07 at 23:36 +0100, Dominick Grift wrote: > On Mon, Dec 07, 2009 at 10:34:21PM +0000, Arthur Dent wrote: > > On Mon, 2009-12-07 at 23:17 +0100, Dominick Grift wrote: > > > On Mon, Dec 07, 2009 at 10:11:46PM +0000, Arthur Dent wrote: > > > > On Mon, 2009-12-07 at 12:49 +0100, Dominick Grift wrote: > > > > > On Sun, Dec 06, 2009 at 09:44:21PM +0000, Arthur Dent wrote: > > > > > > On Sun, 2009-12-06 at 12:59 +0100, Dominick Grift wrote: > > > > > > > On Sun, Dec 06, 2009 at 09:38:32AM +0000, Arthur Dent wrote: > > > > > > > > > > > > > > > > > > > > [Snip] > > > > > > > > > > > > > The rule with the initrc_t type is due to missing policy. It is encouraged to implement policy for all init daemons. > > > > > > > > > > > > > > With regard to the other rules you can, i guess, basically allow the access required, > > > > > > > > > > > > > > But always go through the checklist: > > > > > > > > > > > > > > 1. are the parties in an interaction labeled correctly? (matchpatchcon/restorecon/semanage/chcon) > > > > > > > 2. are there any booleans or types that facilitate a certain interaction? (audit2allow) > > > > > > > 3. is there a misconfiguration in some application? (see if a program should be able to do what it wants) > > > > > > > 3. is there a bug in some application? (is the denial due to a bug in an application?) > > > > > > > 4. is there a bug in the selinux policy? (missing policy to allow a certain interaction?) > > > > > > > 5. is it a break in attempt (is the application compromised. > > > > > > > > > > > > > > taking these 5 golden rules into concideration. i have some questions: > > > > > > > > > > > > > > allow logrotate_t fail2ban_var_run_t:sock_file write > > > > > > > - why would logrotate have to write to a fail2ban sock file? (this may be a bug in fail2ban, maybe leaked file descriptor. does this denial cause any loss in functionality? if not consider silently denying it) > > > > > > > > > > > > > > allow logrotate_t squid_log_t:lnk_file rename; > > > > > > > - why does squidgaurd, or whatever managed squid_log_t lnk_file, create a lnk_file in /var/log/... This is obviously not common behaviour afaik. That may be the reason why is denied. > > > > > > > > > > > > > > withregard to the rules with mail_spool_t type i would like to know if and why logrotate wants to rotate spool files. is this expeected behaviour of logrotate or are the mail_spool_t object mislabeled? > > > > > > > > > > > > > > so in conclusion the only denial that i am somewhat comfortable with is the squid link file denial. This may be some uncommon behaviour of squid/squidgaurd that selinux policy currently does not support (when confirmed that squidgaurd indeed creates a lnk file in /var/log for some reason , then implement policy to allow logrotate to rename the link (and what else it may need to do with the lnk_file.) > > > > > > > > > > > > > > See what runs initrc_t (ps auxZ) and consider writing policy for this init daemon. By implementing policy for init daemon you prtect the system plus you achive that confined domain do not have to interact with the unconfined initrc_t domain. > > > > > > > > > > > > OK - I'm going to change the focus of this question slightly here. > > > > > > > > > > > > Many of my AVCs do in fact relate to Fail2Ban and in fact running ps > > > > > > auxZ shows the following: > > > > > > > > > > > > # ps auxZ | grep init > > > > > > system_u:system_r:init_t:s0 root 1 0.0 0.0 2008 164 ? Ss Dec02 0:03 /sbin/init > > > > > > system_u:system_r:initrc_t:s0 ddclient 1673 0.0 0.7 10228 2956 ? S Dec02 1:00 ddclient - sleeping for 130 seconds > > > > > > system_u:system_r:initrc_t:s0 root 1827 0.1 0.5 75940 2156 ? Sl Dec02 6:52 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -x > > > > > > system_u:system_r:initrc_t:s0 root 1830 0.0 0.0 2904 348 ? S Dec02 0:17 /usr/libexec/gam_server > > > > > > unconfined_u:system_r:initrc_t:s0 clamav 13149 0.3 28.8 220652 109928 ? Ssl 05:50 1:30 /usr/local/sbin/clamd > > > > > > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 14886 1.0 0.1 4200 720 pts/0 S+ 12:08 0:00 grep init > > > > > > > > > > You are using old policy. > > > > > > > > Am I? > > > > # rpm -q selinux-policy selinux-policy-targeted > > > > selinux-policy-3.6.12-88.fc11.noarch > > > > selinux-policy-targeted-3.6.12-88.fc11.noarch > > > > > > > > > > > > > [root at localhost ~]# semanage fcontext -l | grep fail2ban > > > > > /etc/rc\.d/init\.d/fail2ban regular file system_u:object_r:fail2ban_initrc_exec_t:s0 > > > > > /usr/bin/fail2ban regular file system_u:object_r:fail2ban_exec_t:s0 > > > > > /usr/bin/fail2ban-server regular file system_u:object_r:fail2ban_exec_t:s0 > > > > > /var/lib/fail2ban(/.*)? all files system_u:object_r:fail2ban_var_lib_t:s0 > > > > > /var/log/fail2ban\.log regular file system_u:object_r:fail2ban_log_t:s0 > > > > > /var/run/fail2ban.* all files system_u:object_r:fail2ban_var_run_t:s0 > > > > > > > > # semanage fcontext -l | grep fail2ban > > > > /etc/rc\.d/init\.d/fail2ban regular file system_u:object_r:fail2ban_initrc_exec_t:s0 > > > > /usr/bin/fail2ban regular file system_u:object_r:fail2ban_exec_t:s0 > > > > /usr/bin/fail2ban-server regular file system_u:object_r:fail2ban_exec_t:s0 > > > > /var/lib/fail2ban(/.*)? all files system_u:object_r:fail2ban_var_lib_t:s0 > > > > /var/log/fail2ban\.log regular file system_u:object_r:fail2ban_log_t:s0 > > > > /var/run/fail2ban.* all files system_u:object_r:fail2ban_var_run_t:s0 > > > > > > > > I may be wrong, but to me my results look the same? > > > > > > They look the same indeed. question remains, why does fail2ban-server runs in the init script domain? > > > > > > matchpathcon /usr/bin/fail2ban-server > > > > > > ( could it be that the file is mislabeled? ) > > > > # matchpathcon /usr/bin/fail2ban-server > > /usr/bin/fail2ban-server system_u:object_r:fail2ban_exec_t:s0 > > > > Is that what you would expect to see? > > yes, now the question is, is the path labeled the way it should be: > > ls -alZ /usr/bin/fail2ban-server # ls -alZ /usr/bin/fail2ban-server -rwxr-xr-x. root root unconfined_u:object_r:bin_t:s0 /usr/bin/fail2ban-server Hmmmm... # restorecon -v /usr/bin/fail2ban-server restorecon reset /usr/bin/fail2ban-server context unconfined_u:object_r:bin_t:s0->system_u:object_r:fail2ban_exec_t:s0 # ls -alZ /usr/bin/fail2ban-server -rwxr-xr-x. root root system_u:object_r:fail2ban_exec_t:s0 /usr/bin/fail2ban-server Ahhh... Is that more like it? Thanks again! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From domg472 at gmail.com Mon Dec 7 22:51:37 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 7 Dec 2009 23:51:37 +0100 Subject: Logrotate frustration - Selinux & Fail2Ban In-Reply-To: <1260225855.3056.47.camel@localhost> References: <1260092312.3083.10.camel@localhost> <20091206115908.GA2886@localhost.localdomain> <1260135861.3083.37.camel@localhost> <20091207114947.GB2942@localhost.localdomain> <1260223906.3056.24.camel@localhost> <20091207221757.GB6387@localhost.localdomain> <1260225261.3056.43.camel@localhost> <20091207223639.GD6387@localhost.localdomain> <1260225855.3056.47.camel@localhost> Message-ID: <20091207225136.GE6387@localhost.localdomain> On Mon, Dec 07, 2009 at 10:44:15PM +0000, Arthur Dent wrote: > On Mon, 2009-12-07 at 23:36 +0100, Dominick Grift wrote: > > On Mon, Dec 07, 2009 at 10:34:21PM +0000, Arthur Dent wrote: > > > On Mon, 2009-12-07 at 23:17 +0100, Dominick Grift wrote: > > > > On Mon, Dec 07, 2009 at 10:11:46PM +0000, Arthur Dent wrote: > > > > > On Mon, 2009-12-07 at 12:49 +0100, Dominick Grift wrote: > > > > > > On Sun, Dec 06, 2009 at 09:44:21PM +0000, Arthur Dent wrote: > > > > > > > On Sun, 2009-12-06 at 12:59 +0100, Dominick Grift wrote: > > > > > > > > On Sun, Dec 06, 2009 at 09:38:32AM +0000, Arthur Dent wrote: > > > > > > > > > > > > > > > > > > > > > > > [Snip] > > > > > > > > > > > > > > > The rule with the initrc_t type is due to missing policy. It is encouraged to implement policy for all init daemons. > > > > > > > > > > > > > > > > With regard to the other rules you can, i guess, basically allow the access required, > > > > > > > > > > > > > > > > But always go through the checklist: > > > > > > > > > > > > > > > > 1. are the parties in an interaction labeled correctly? (matchpatchcon/restorecon/semanage/chcon) > > > > > > > > 2. are there any booleans or types that facilitate a certain interaction? (audit2allow) > > > > > > > > 3. is there a misconfiguration in some application? (see if a program should be able to do what it wants) > > > > > > > > 3. is there a bug in some application? (is the denial due to a bug in an application?) > > > > > > > > 4. is there a bug in the selinux policy? (missing policy to allow a certain interaction?) > > > > > > > > 5. is it a break in attempt (is the application compromised. > > > > > > > > > > > > > > > > taking these 5 golden rules into concideration. i have some questions: > > > > > > > > > > > > > > > > allow logrotate_t fail2ban_var_run_t:sock_file write > > > > > > > > - why would logrotate have to write to a fail2ban sock file? (this may be a bug in fail2ban, maybe leaked file descriptor. does this denial cause any loss in functionality? if not consider silently denying it) > > > > > > > > > > > > > > > > allow logrotate_t squid_log_t:lnk_file rename; > > > > > > > > - why does squidgaurd, or whatever managed squid_log_t lnk_file, create a lnk_file in /var/log/... This is obviously not common behaviour afaik. That may be the reason why is denied. > > > > > > > > > > > > > > > > withregard to the rules with mail_spool_t type i would like to know if and why logrotate wants to rotate spool files. is this expeected behaviour of logrotate or are the mail_spool_t object mislabeled? > > > > > > > > > > > > > > > > so in conclusion the only denial that i am somewhat comfortable with is the squid link file denial. This may be some uncommon behaviour of squid/squidgaurd that selinux policy currently does not support (when confirmed that squidgaurd indeed creates a lnk file in /var/log for some reason , then implement policy to allow logrotate to rename the link (and what else it may need to do with the lnk_file.) > > > > > > > > > > > > > > > > See what runs initrc_t (ps auxZ) and consider writing policy for this init daemon. By implementing policy for init daemon you prtect the system plus you achive that confined domain do not have to interact with the unconfined initrc_t domain. > > > > > > > > > > > > > > OK - I'm going to change the focus of this question slightly here. > > > > > > > > > > > > > > Many of my AVCs do in fact relate to Fail2Ban and in fact running ps > > > > > > > auxZ shows the following: > > > > > > > > > > > > > > # ps auxZ | grep init > > > > > > > system_u:system_r:init_t:s0 root 1 0.0 0.0 2008 164 ? Ss Dec02 0:03 /sbin/init > > > > > > > system_u:system_r:initrc_t:s0 ddclient 1673 0.0 0.7 10228 2956 ? S Dec02 1:00 ddclient - sleeping for 130 seconds > > > > > > > system_u:system_r:initrc_t:s0 root 1827 0.1 0.5 75940 2156 ? Sl Dec02 6:52 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -x > > > > > > > system_u:system_r:initrc_t:s0 root 1830 0.0 0.0 2904 348 ? S Dec02 0:17 /usr/libexec/gam_server > > > > > > > unconfined_u:system_r:initrc_t:s0 clamav 13149 0.3 28.8 220652 109928 ? Ssl 05:50 1:30 /usr/local/sbin/clamd > > > > > > > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 14886 1.0 0.1 4200 720 pts/0 S+ 12:08 0:00 grep init > > > > > > > > > > > > You are using old policy. > > > > > > > > > > Am I? > > > > > # rpm -q selinux-policy selinux-policy-targeted > > > > > selinux-policy-3.6.12-88.fc11.noarch > > > > > selinux-policy-targeted-3.6.12-88.fc11.noarch > > > > > > > > > > > > > > > > [root at localhost ~]# semanage fcontext -l | grep fail2ban > > > > > > /etc/rc\.d/init\.d/fail2ban regular file system_u:object_r:fail2ban_initrc_exec_t:s0 > > > > > > /usr/bin/fail2ban regular file system_u:object_r:fail2ban_exec_t:s0 > > > > > > /usr/bin/fail2ban-server regular file system_u:object_r:fail2ban_exec_t:s0 > > > > > > /var/lib/fail2ban(/.*)? all files system_u:object_r:fail2ban_var_lib_t:s0 > > > > > > /var/log/fail2ban\.log regular file system_u:object_r:fail2ban_log_t:s0 > > > > > > /var/run/fail2ban.* all files system_u:object_r:fail2ban_var_run_t:s0 > > > > > > > > > > # semanage fcontext -l | grep fail2ban > > > > > /etc/rc\.d/init\.d/fail2ban regular file system_u:object_r:fail2ban_initrc_exec_t:s0 > > > > > /usr/bin/fail2ban regular file system_u:object_r:fail2ban_exec_t:s0 > > > > > /usr/bin/fail2ban-server regular file system_u:object_r:fail2ban_exec_t:s0 > > > > > /var/lib/fail2ban(/.*)? all files system_u:object_r:fail2ban_var_lib_t:s0 > > > > > /var/log/fail2ban\.log regular file system_u:object_r:fail2ban_log_t:s0 > > > > > /var/run/fail2ban.* all files system_u:object_r:fail2ban_var_run_t:s0 > > > > > > > > > > I may be wrong, but to me my results look the same? > > > > > > > > They look the same indeed. question remains, why does fail2ban-server runs in the init script domain? > > > > > > > > matchpathcon /usr/bin/fail2ban-server > > > > > > > > ( could it be that the file is mislabeled? ) > > > > > > # matchpathcon /usr/bin/fail2ban-server > > > /usr/bin/fail2ban-server system_u:object_r:fail2ban_exec_t:s0 > > > > > > Is that what you would expect to see? > > > > yes, now the question is, is the path labeled the way it should be: > > > > ls -alZ /usr/bin/fail2ban-server > > # ls -alZ /usr/bin/fail2ban-server > -rwxr-xr-x. root root unconfined_u:object_r:bin_t:s0 /usr/bin/fail2ban-server > > Hmmmm... > > # restorecon -v /usr/bin/fail2ban-server > restorecon reset /usr/bin/fail2ban-server context unconfined_u:object_r:bin_t:s0->system_u:object_r:fail2ban_exec_t:s0 > > # ls -alZ /usr/bin/fail2ban-server > -rwxr-xr-x. root root system_u:object_r:fail2ban_exec_t:s0 /usr/bin/fail2ban-server > > Ahhh... > > Is that more like it? Yes that should get you atleast a little closer. I am wondering what else may be mislabeled on your system. maybe a relabel/fixfiles restore is in order... > > Thanks again! > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From Moray.Henderson at ict.om.org Tue Dec 8 09:32:42 2009 From: Moray.Henderson at ict.om.org (Moray Henderson (ICT)) Date: Tue, 8 Dec 2009 09:32:42 +0000 Subject: Policy structure in Fedora In-Reply-To: <20091207202828.GA6387@localhost.localdomain> References: <4B17DBFE.7010502@redhat.com> <200912040440.nB44eNDY023317@douglas.highley-recommended.com> <000001ca74c8$400dfc20$c029f460$@Henderson@ict-software.org> <1259939702.2144.29.camel@localhost> <000e01ca7734$f9796e10$ec6c4a30$@Henderson@ict.om.org> <20091207202828.GA6387@localhost.localdomain> Message-ID: <000001ca77e9$66acb3c0$34061b40$@Henderson@ict.om.org> Dominic Grift wrote (in RE: Fedora 12 and unconfined_u sshdfilter): >> Mixing the plain rules and the m4 macros didn't work when I tried it - >> but perhaps I just wasn?t writing it right. Is there a Refpolicy >> tutorial anywhere? > >I spend a little time today writing about the policy structure in Fedora. >Maybe it can help you or others: > >http://82.197.205.60/~dgrift/stuff/Managing_a_SELinux_environment_with_Fedora_12.pdf Thank you - that is helpful. Moray. "To err is human. To purr, feline" From jorge.fabregas at gmail.com Tue Dec 8 12:21:41 2009 From: jorge.fabregas at gmail.com (Jorge =?iso-8859-1?q?F=E1bregas?=) Date: Tue, 8 Dec 2009 08:21:41 -0400 Subject: Targeted Daemons/Apps- Fedora 12 Message-ID: <200912080821.42031.jorge.fabregas@gmail.com> Hello everyone, Where can I find a list of all the targeted daemons/apps that are protected by the current policy on Fedora 12? Thanks, Jorge From domg472 at gmail.com Tue Dec 8 12:45:34 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 8 Dec 2009 13:45:34 +0100 Subject: Targeted Daemons/Apps- Fedora 12 In-Reply-To: <200912080821.42031.jorge.fabregas@gmail.com> References: <200912080821.42031.jorge.fabregas@gmail.com> Message-ID: <20091208124532.GA3462@localhost.localdomain> On Tue, Dec 08, 2009 at 08:21:41AM -0400, Jorge F?bregas wrote: > Hello everyone, > > Where can I find a list of all the targeted daemons/apps that are protected by > the current policy on Fedora 12? That is not so easy to list. You can list installed modules that are not part of the base policy: semodule -l That will give you atleast some impression about what may be targeted. But that impression is distorted. One reason is that a policy for a daemon or app may be built into the base policy. Base policy is a group of mandatory modules. Another reason why listing targeted daemons/apps is not so easy is because of how policy is structured. A policy module can have policy for several daemons and apps. For example: The irc policy module has policy for several different irc clients. They are grouped into one module because they share the property that they are all irc clients. Another example is the git module. This module has policy for the git daemon but it also has policy for the cgit web application. Another way to approach this issue is to run the following command: sesearch --allow -s domain This will list all interactions that are allowed where the source of an interaction is a type with the domain attribute (think of attributes as if they are tags) The problem here is that this shows all domain types. One program can be sometimes run with various domain types. So this is also a distorted view. Besides that, it is not always easy to determine what daemon or app a type is for, just by looking at a type. To really get an answer to your question , i believe you would probably need to inspect the source policy. Since you want to know the daemons targeted you would probably inspect the policy/modules/services directory carefully and determine there which daemons may be targeted. For app you would look into the policy/modules/apps directory. But even that is not accurate.. Since policy may be available but not installed. or may be installed but not instantiated. > > Thanks, > Jorge > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From zaina.afoulki at ensi-bourges.fr Tue Dec 8 15:04:27 2009 From: zaina.afoulki at ensi-bourges.fr (Zaina AFOULKI) Date: Tue, 8 Dec 2009 16:04:27 +0100 (CET) Subject: Sample logs of alert types Message-ID: <5637ca9f516f183c6110c6bab00f95e7.squirrel@webmail.ensi-bourges.fr> Hello, We are trying to develop a graphical interface for SELinux alerts... We noticed that each log for a specific alert is different from the one of other types. For example: type=AVC msg=audit(12/03/2007 12:44:48.301:140) : avc: denied { getattr } for pid=2816 comm=vi path=/root/xorg.conf.new dev=sda1 ino=131104 scontext=staff_u:staff_r:staff_sudo_t:s0 tcontext=root:object_r:sysadm_home_t:s0 tclass=file type=SYSCALL msg=audit(12/03/2007 12:44:48.325:141) : arch=i386 syscall=access success=yes exit=0 a0=88caaa8 a1=2 a2=1a4 a3=1 items=0 ppid=2784 pid=2816 auid=gmarzot uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 comm=vi exe=/bin/vi subj=staff_u:staff_r:staff_sudo_t:s0 key=(null) Currently we know how the log looks like for the following types: DAEMON_START ANOM_ABEND AVC CONFIG_CHANGE CRED_ACQ CRED_DISP DAEMON_END LOGIN MAC_STATUS SELINUX_ERR SYSCALL SYSTEM_RUNLEVEL SYSTEM_SHUTDOWN USER_ACCT USER_AUTH USER_AVC USER_CHAUTHTOK USER_CMD USER_END USER_ERR USER_LOGIN USER_ROLE_CHANGE USER_START We really need to know the look of each alert in the log file. Is there a way we can get a sample of each log type? Your help will be greatly appreciated. Thanks in advance, -- Zaina AFOULKI ?tudiante ? l'Ecole Nationale Sup?rieure d'Ing?nieurs de Bourges. 1?re ann?e S?curit? et Technologies Informatiques From jdennis at redhat.com Tue Dec 8 15:32:07 2009 From: jdennis at redhat.com (John Dennis) Date: Tue, 08 Dec 2009 10:32:07 -0500 Subject: Sample logs of alert types In-Reply-To: <5637ca9f516f183c6110c6bab00f95e7.squirrel@webmail.ensi-bourges.fr> References: <5637ca9f516f183c6110c6bab00f95e7.squirrel@webmail.ensi-bourges.fr> Message-ID: <4B1E7177.5060802@redhat.com> On 12/08/2009 10:04 AM, Zaina AFOULKI wrote: > Hello, > > We are trying to develop a graphical interface for SELinux alerts... > We noticed that each log for a specific alert is different from the one of > other types. For example: > > type=AVC msg=audit(12/03/2007 12:44:48.301:140) : avc: denied { getattr > } for pid=2816 comm=vi path=/root/xorg.conf.new dev=sda1 ino=131104 > scontext=staff_u:staff_r:staff_sudo_t:s0 > tcontext=root:object_r:sysadm_home_t:s0 tclass=file > > > type=SYSCALL msg=audit(12/03/2007 12:44:48.325:141) : arch=i386 > syscall=access success=yes exit=0 a0=88caaa8 a1=2 a2=1a4 a3=1 items=0 > ppid=2784 pid=2816 auid=gmarzot uid=root gid=root euid=root suid=root > fsuid=root egid=root sgid=root fsgid=root tty=pts0 comm=vi exe=/bin/vi > subj=staff_u:staff_r:staff_sudo_t:s0 key=(null) > > Currently we know how the log looks like for the following types: > DAEMON_START ANOM_ABEND AVC CONFIG_CHANGE CRED_ACQ CRED_DISP DAEMON_END > LOGIN MAC_STATUS SELINUX_ERR SYSCALL SYSTEM_RUNLEVEL SYSTEM_SHUTDOWN > USER_ACCT USER_AUTH USER_AVC USER_CHAUTHTOK USER_CMD USER_END USER_ERR > USER_LOGIN USER_ROLE_CHANGE USER_START > > We really need to know the look of each alert in the log file. > Is there a way we can get a sample of each log type? > Your help will be greatly appreciated. > > Thanks in advance, > > No, there is no such library of every possible AVC message. The problem is further compounded by the following issues: * it depends on the kernel version * messages are not emitted atomically or sequentially by the audit system, by this I mean all the information concerning a given AVC arrives as a collection of audit messages which must be reassembled by matching the audit ID associated with each message, that constitutes an "event" as opposed to individual messages. * parsing of the audit messages should be done with auparse as there are some odd behaviors with certain fields which auparse compensates for, in particular string values. The last time I checked, which was over a year ago, auparse did not assemble non-sequential messages into events. setroubleshoot has addressed many of these issues and provides a GUI, are you aware of that? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From michael.madore at gmail.com Tue Dec 8 18:27:34 2009 From: michael.madore at gmail.com (Michael Madore) Date: Tue, 8 Dec 2009 13:27:34 -0500 Subject: cp -Z in Fedora 12 Message-ID: Hi, I have been reading through the Fedora 12 selinux documentation: http://docs.fedoraproject.org/selinux-user-guide/f12/en-US/ In section 5.10.1 (Copying Files and Directories), the following example is used to demonstrate changing the context of a file when copying: $ touch file1 $ cp -Z system_u:object_r:samba_share_t:s0 file1 file2 $ ls -Z file1 file2 -rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1 -rw-rw-r-- user1 group1 system_u:object_r:samba_share_t:s0 file2 However, when I try this on my Fedora 12 system i get the following: ls -Z file1 file2 -rw-rw-r--. mmadore mmadore unconfined_u:object_r:user_home_t:s0 file1 -rw-rw-r--. mmadore mmadore unconfined_u:object_r:user_home_t:s0 file2 On CentOS 5.4 and Fedora 11, I see the documented behaviour. Is this a bug, or am I doing something wrong? Thanks Mike Madore From domg472 at gmail.com Tue Dec 8 18:34:51 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 8 Dec 2009 19:34:51 +0100 Subject: cp -Z in Fedora 12 In-Reply-To: References: Message-ID: <20091208183450.GA5911@localhost.localdomain> On Tue, Dec 08, 2009 at 01:27:34PM -0500, Michael Madore wrote: > Hi, > > I have been reading through the Fedora 12 selinux documentation: > > http://docs.fedoraproject.org/selinux-user-guide/f12/en-US/ > > In section 5.10.1 (Copying Files and Directories), the following > example is used to demonstrate changing the context of a file when > copying: > > $ touch file1 > $ cp -Z system_u:object_r:samba_share_t:s0 file1 file2 > $ ls -Z file1 file2 > -rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1 > -rw-rw-r-- user1 group1 system_u:object_r:samba_share_t:s0 file2 > > However, when I try this on my Fedora 12 system i get the following: > > ls -Z file1 file2 > -rw-rw-r--. mmadore mmadore unconfined_u:object_r:user_home_t:s0 file1 > -rw-rw-r--. mmadore mmadore unconfined_u:object_r:user_home_t:s0 file2 > > On CentOS 5.4 and Fedora 11, I see the documented behaviour. Is this > a bug, or am I doing something wrong? I think this is due to restorecond -u running in f12. Restorecond -u checks files in the home directory of a user and resets any files context that does not match the system wide context specification. [root at localhost Desktop]# cd / [root at localhost /]# touch file1 [root at localhost /]# cp -Z system_u:object_r:samba_share_t:s0 file1 file2 [root at localhost /]# ls -Z file1 file2 -rw-r--r--. root root staff_u:object_r:etc_runtime_t:s0 file1 -rw-r--r--. root root system_u:object_r:samba_share_t:s0 file2 so the file does actually gets copied with the specified context, but restorecond -u immeditiatly notices a file with a "wrong" context in your home dir and resets it to the default context specified for files in your home dir. It should work if you try it in runlevel 3 or if you try like my example above in a location other then $home. > > Thanks > > Mike Madore > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Tue Dec 8 18:37:12 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 8 Dec 2009 19:37:12 +0100 Subject: cp -Z in Fedora 12 In-Reply-To: References: Message-ID: <20091208183711.GB5911@localhost.localdomain> On Tue, Dec 08, 2009 at 01:27:34PM -0500, Michael Madore wrote: > Hi, > > I have been reading through the Fedora 12 selinux documentation: > > http://docs.fedoraproject.org/selinux-user-guide/f12/en-US/ > > In section 5.10.1 (Copying Files and Directories), the following > example is used to demonstrate changing the context of a file when > copying: > > $ touch file1 > $ cp -Z system_u:object_r:samba_share_t:s0 file1 file2 > $ ls -Z file1 file2 > -rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1 > -rw-rw-r-- user1 group1 system_u:object_r:samba_share_t:s0 file2 > > However, when I try this on my Fedora 12 system i get the following: > > ls -Z file1 file2 > -rw-rw-r--. mmadore mmadore unconfined_u:object_r:user_home_t:s0 file1 > -rw-rw-r--. mmadore mmadore unconfined_u:object_r:user_home_t:s0 file2 > > On CentOS 5.4 and Fedora 11, I see the documented behaviour. Is this > a bug, or am I doing something wrong? We should probably make a note about restorecond -u in Fedora 12 and/or edit the example to reflect the side effect of restorecond -u. It can be very confusing at times... > > Thanks > > Mike Madore > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From joliver at john-oliver.net Tue Dec 8 18:41:51 2009 From: joliver at john-oliver.net (John Oliver) Date: Tue, 8 Dec 2009 10:41:51 -0800 Subject: Combining modules? Message-ID: <20091208184151.GA10762@ns.sdsitehosting.net> I don't know if there's a better way to do this, but I'm trying to get nagios working with selinux (CentOS 5.4 Final) I try to run it, get an error, create a policy module, install it, and return to step one. It's getting pretty ridiculous: [joliver at mda-services4 ~]$ sudo /usr/sbin/semodule -l | grep nagios nagios 1.1.0 nagios10 1.0 nagios2 1.0 nagios3 1.0 nagios4 1.0 nagios5 1.0 nagios6 1.0 nagios7 1.0 nagios8 1.0 nagios9 1.0 When I finally discover all of the problems... is there a way to dump all of those modules into one? Both for my sanity, and so that I can maybe submit that module to CentOS so the next poor SOB who tries to do this doesn't have to reinvent the wheel? Or is there another, better, way to find all of the various rules that are needed in one fell swoop? -- *********************************************************************** * John Oliver http://www.john-oliver.net/ * * * *********************************************************************** From joshua.roys at gtri.gatech.edu Tue Dec 8 18:46:10 2009 From: joshua.roys at gtri.gatech.edu (Joshua Roys) Date: Tue, 8 Dec 2009 13:46:10 -0500 Subject: Combining modules? In-Reply-To: <20091208184151.GA10762@ns.sdsitehosting.net> References: <20091208184151.GA10762@ns.sdsitehosting.net> Message-ID: <4B1E9EF2.6030408@gtri.gatech.edu> On 12/08/2009 01:41 PM, John Oliver wrote: > I don't know if there's a better way to do this, but I'm trying to get > nagios working with selinux (CentOS 5.4 Final) I try to run it, get an > error, create a policy module, install it, and return to step one. It's > getting pretty ridiculous: > > [joliver at mda-services4 ~]$ sudo /usr/sbin/semodule -l | grep nagios > nagios 1.1.0 > nagios10 1.0 > nagios2 1.0 > nagios3 1.0 > nagios4 1.0 > nagios5 1.0 > nagios6 1.0 > nagios7 1.0 > nagios8 1.0 > nagios9 1.0 > > When I finally discover all of the problems... is there a way to dump > all of those modules into one? Both for my sanity, and so that I can > maybe submit that module to CentOS so the next poor SOB who tries to do > this doesn't have to reinvent the wheel? > > Or is there another, better, way to find all of the various rules that > are needed in one fell swoop? > Instead of making a new file, you can just edit the old files, bump the version, and instead of semodule -i, use semodule -u (update). -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2719 bytes Desc: S/MIME Cryptographic Signature URL: From domg472 at gmail.com Tue Dec 8 18:57:10 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 8 Dec 2009 19:57:10 +0100 Subject: Combining modules? In-Reply-To: <20091208184151.GA10762@ns.sdsitehosting.net> References: <20091208184151.GA10762@ns.sdsitehosting.net> Message-ID: <20091208185708.GC5911@localhost.localdomain> On Tue, Dec 08, 2009 at 10:41:51AM -0800, John Oliver wrote: > I don't know if there's a better way to do this, but I'm trying to get > nagios working with selinux (CentOS 5.4 Final) I try to run it, get an > error, create a policy module, install it, and return to step one. It's > getting pretty ridiculous: Yes common issue with developing policy. What developers usually do it develop policy in permissive mode or in fedora11 and up using permissive domains. These methods allow you to accumulate all or atleast most avc denials in one runs. This is because permissive mode/domains allow the access but log "would be denials". So the process usually works but youll still get to see what SELinux would have denied. But apart from that. You can also develop policy in enforcing mode. Although since selinux actually denies every permission the process cannot proceed. So youll write a rule, reload modified policy, appends the next rule, reload and so forth an so forth. An easier way to do that is to just modify your source policy (the .te, .if and .fc files), rebuild the binary policy and install it again. That will overwrite the installed policy. echo "policy_module(example, 1.0.0)" > example.te; make -f /usr/share/selinux/devel/Makefile example.pp sudo semodule -i example.pp ( .. later you figure out more policy is required .. ) ( .. appending some stuff to existing source policy example.te file .. ) echo "type example_t;" >> example.te; echo "type example_exec_t;" >> example.te; echo "init_daemon_domain(example_t, example_exec_t)" >> example.te; ( .. building a binary module again this time from modified source policy example.te file .. ) make -f /usr/share/selinux/devel/Makefile example.pp ( .. installing modified example.pp binary module *again*, whichif policy version is the same, overwrites the existing installed example.pp) That way you will end up with a single module with all your mods for a particular domain. > > [joliver at mda-services4 ~]$ sudo /usr/sbin/semodule -l | grep nagios > nagios 1.1.0 > nagios10 1.0 > nagios2 1.0 > nagios3 1.0 > nagios4 1.0 > nagios5 1.0 > nagios6 1.0 > nagios7 1.0 > nagios8 1.0 > nagios9 1.0 > > When I finally discover all of the problems... is there a way to dump > all of those modules into one? Both for my sanity, and so that I can > maybe submit that module to CentOS so the next poor SOB who tries to do > this doesn't have to reinvent the wheel? > > Or is there another, better, way to find all of the various rules that > are needed in one fell swoop? > > -- > *********************************************************************** > * John Oliver http://www.john-oliver.net/ * > * * > *********************************************************************** > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From misc.lists at blueyonder.co.uk Tue Dec 8 20:43:32 2009 From: misc.lists at blueyonder.co.uk (Arthur Dent) Date: Tue, 08 Dec 2009 20:43:32 +0000 Subject: Selinux & Fail2Ban In-Reply-To: <20091207225136.GE6387@localhost.localdomain> References: <1260092312.3083.10.camel@localhost> <20091206115908.GA2886@localhost.localdomain> <1260135861.3083.37.camel@localhost> <20091207114947.GB2942@localhost.localdomain> <1260223906.3056.24.camel@localhost> <20091207221757.GB6387@localhost.localdomain> <1260225261.3056.43.camel@localhost> <20091207223639.GD6387@localhost.localdomain> <1260225855.3056.47.camel@localhost> <20091207225136.GE6387@localhost.localdomain> Message-ID: <1260305012.5969.23.camel@localhost> On Mon, 2009-12-07 at 23:51 +0100, Dominick Grift wrote: > > > > > > > > [Snip] > > > > > > > > # matchpathcon /usr/bin/fail2ban-server > > > > /usr/bin/fail2ban-server system_u:object_r:fail2ban_exec_t:s0 > > > > > > > > Is that what you would expect to see? > > > > > > yes, now the question is, is the path labeled the way it should be: > > > > > > ls -alZ /usr/bin/fail2ban-server > > > > # ls -alZ /usr/bin/fail2ban-server > > -rwxr-xr-x. root root unconfined_u:object_r:bin_t:s0 /usr/bin/fail2ban-server > > > > Hmmmm... > > > > # restorecon -v /usr/bin/fail2ban-server > > restorecon reset /usr/bin/fail2ban-server context unconfined_u:object_r:bin_t:s0->system_u:object_r:fail2ban_exec_t:s0 > > > > # ls -alZ /usr/bin/fail2ban-server > > -rwxr-xr-x. root root system_u:object_r:fail2ban_exec_t:s0 /usr/bin/fail2ban-server > > > > Ahhh... > > > > Is that more like it? > > Yes that should get you atleast a little closer. I am wondering what else may be mislabeled on your system. > > maybe a relabel/fixfiles restore is in order... Yes. Good advice. As it happens there was a new selinux policy available today (using yum update): # rpm -q selinux-policy selinux-policy-targeted selinux-policy-3.6.12-91.fc11.noarch selinux-policy-targeted-3.6.12-91.fc11.noarch I removed two of my local policies (log rotation and fail2ban) and put selinux into permissive mode. Having updated I did a "touch /.autorelabel; reboot" Following your 7 point plan I believe I am now at stage 6? { 1) I believe there is a type created for the process? (fail2ban_exec) 2) I believe there is a type for the executable file (fail2ban_exec) 3) declare the two types init_daemon_domain(). (Not sure about this) 4) The executable file is labelled with the type fail2ban_exec 5) I have started the service (in permissive mode). } I got 5 AVCs. 2 on startup and 3 when fail2ban actually hit on a rule. (Copies of the AVCs below) So - point 6: Using audit2allow I get this: =================8<============================================ module myfail2ban 11.2.1; require { type iptables_t; type system_mail_t; type fail2ban_t; class unix_stream_socket { read write }; } #============= iptables_t ============== allow iptables_t fail2ban_t:unix_stream_socket { read write }; #============= system_mail_t ============== allow system_mail_t fail2ban_t:unix_stream_socket { read write }; =================8<============================================ So what do you think? Am I on the right track? Thanks again for all your help. Mark AVCs (I think a couple may be duplicates - I'm running in permissive mode): Raw Audit Messages : node=troodos.org.uk type=AVC msg=audit(1260298720.4:21): avc: denied { read write } for pid=1907 comm="iptables" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket node=troodos.org.uk type=SYSCALL msg=audit(1260298720.4:21): arch=40000003 syscall=11 success=yes exit=0 a0=8a1a250 a1=8a1a460 a2=8a19738 a3=8a1a460 items=0 ppid=1906 pid=1907 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/iptables" subj=system_u:system_r:iptables_t:s0 key=(null) Raw Audit Messages : node=troodos.org.uk type=AVC msg=audit(1260298720.169:22): avc: denied { read write } for pid=1921 comm="sendmail" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket node=troodos.org.uk type=SYSCALL msg=audit(1260298720.169:22): arch=40000003 syscall=11 success=yes exit=0 a0=85867d0 a1=8587798 a2=8587670 a3=8587798 items=0 ppid=1919 pid=1921 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:system_mail_t:s0 key=(null) Raw Audit Messages : node=troodos.org.uk type=AVC msg=audit(1260301404.622:121): avc: denied { read write } for pid=2799 comm="iptables" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket node=troodos.org.uk type=SYSCALL msg=audit(1260301404.622:121): arch=40000003 syscall=11 success=yes exit=0 a0=88b13e0 a1=88b1618 a2=88b06f8 a3=88b1618 items=0 ppid=2798 pid=2799 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/iptables" subj=system_u:system_r:iptables_t:s0 key=(null) Raw Audit Messages : node=troodos.org.uk type=AVC msg=audit(1260301405.169:122): avc: denied { read write } for pid=2804 comm="iptables" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket node=troodos.org.uk type=SYSCALL msg=audit(1260301405.169:122): arch=40000003 syscall=11 success=yes exit=0 a0=96e3418 a1=96e3718 a2=96e2700 a3=96e3718 items=0 ppid=1901 pid=2804 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/iptables" subj=system_u:system_r:iptables_t:s0 key=(null) Raw Audit Messages : node=troodos.org.uk type=AVC msg=audit(1260301405.212:123): avc: denied { read write } for pid=2811 comm="sendmail" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket node=troodos.org.uk type=SYSCALL msg=audit(1260301405.212:123): arch=40000003 syscall=11 success=yes exit=0 a0=a119518 a1=a119a48 a2=a119750 a3=a119a48 items=0 ppid=2807 pid=2811 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:system_mail_t:s0 key=(null) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From domg472 at gmail.com Tue Dec 8 20:57:29 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 8 Dec 2009 21:57:29 +0100 Subject: Selinux & Fail2Ban In-Reply-To: <1260305012.5969.23.camel@localhost> References: <20091206115908.GA2886@localhost.localdomain> <1260135861.3083.37.camel@localhost> <20091207114947.GB2942@localhost.localdomain> <1260223906.3056.24.camel@localhost> <20091207221757.GB6387@localhost.localdomain> <1260225261.3056.43.camel@localhost> <20091207223639.GD6387@localhost.localdomain> <1260225855.3056.47.camel@localhost> <20091207225136.GE6387@localhost.localdomain> <1260305012.5969.23.camel@localhost> Message-ID: <20091208205728.GA9740@localhost.localdomain> On Tue, Dec 08, 2009 at 08:43:32PM +0000, Arthur Dent wrote: > On Mon, 2009-12-07 at 23:51 +0100, Dominick Grift wrote: > > > > > > > > > > [Snip] > > > > > > > > > > > # matchpathcon /usr/bin/fail2ban-server > > > > > /usr/bin/fail2ban-server system_u:object_r:fail2ban_exec_t:s0 > > > > > > > > > > Is that what you would expect to see? > > > > > > > > yes, now the question is, is the path labeled the way it should be: > > > > > > > > ls -alZ /usr/bin/fail2ban-server > > > > > > # ls -alZ /usr/bin/fail2ban-server > > > -rwxr-xr-x. root root unconfined_u:object_r:bin_t:s0 /usr/bin/fail2ban-server > > > > > > Hmmmm... > > > > > > # restorecon -v /usr/bin/fail2ban-server > > > restorecon reset /usr/bin/fail2ban-server context unconfined_u:object_r:bin_t:s0->system_u:object_r:fail2ban_exec_t:s0 > > > > > > # ls -alZ /usr/bin/fail2ban-server > > > -rwxr-xr-x. root root system_u:object_r:fail2ban_exec_t:s0 /usr/bin/fail2ban-server > > > > > > Ahhh... > > > > > > Is that more like it? > > > > Yes that should get you atleast a little closer. I am wondering what else may be mislabeled on your system. > > > > maybe a relabel/fixfiles restore is in order... > > Yes. Good advice. > > As it happens there was a new selinux policy available today (using yum > update): > # rpm -q selinux-policy selinux-policy-targeted > selinux-policy-3.6.12-91.fc11.noarch > selinux-policy-targeted-3.6.12-91.fc11.noarch > > > I removed two of my local policies (log rotation and fail2ban) and put > selinux into permissive mode. > > Having updated I did a "touch /.autorelabel; reboot" > > Following your 7 point plan I believe I am now at stage 6? > { > 1) I believe there is a type created for the process? (fail2ban_exec) > 2) I believe there is a type for the executable file (fail2ban_exec) > 3) declare the two types init_daemon_domain(). (Not sure about this) > 4) The executable file is labelled with the type fail2ban_exec > 5) I have started the service (in permissive mode). > } > > I got 5 AVCs. 2 on startup and 3 when fail2ban actually hit on a rule. > (Copies of the AVCs below) > > So - point 6: Using audit2allow I get this: > > =================8<============================================ > > module myfail2ban 11.2.1; > > require { > type iptables_t; > type system_mail_t; > type fail2ban_t; > class unix_stream_socket { read write }; > } > > #============= iptables_t ============== > allow iptables_t fail2ban_t:unix_stream_socket { read write }; > > #============= system_mail_t ============== > allow system_mail_t fail2ban_t:unix_stream_socket { read write }; > > =================8<============================================ > > So what do you think? > > Am I on the right track? Yes "allow system_mail_t fail2ban_t:unix_stream_socket { read write };", signals a leaked file descriptor on fail2ban. This issue is known. You can ignore those avc denials and/or silence them: echo "policy_module(myfail2ban, 1.0.0)" > myfail2ban.te; echo "optional_policy(\`" >> myfail2ban.te; echo "gen_require(\`" >> myfail2ban.te; echo "attribute domain;" >> myfail2ban.te; echo "type fail2ban_t;" >> myfail2ban.te; echo "\')" >> myfail2ban.te; echo "dontaudit domain fail2ban_t:unix_stream_socket { read write };" >> myfail2ban.te; echo "\')" >> myfail2ban.te; make -f /usr/share/selinux/devel/Makefile myfail2ban.pp sudo semodule -i myfail2ban.pp > > Thanks again for all your help. > > Mark > > > AVCs (I think a couple may be duplicates - I'm running in permissive > mode): > > Raw Audit Messages : > > node=troodos.org.uk type=AVC msg=audit(1260298720.4:21): avc: denied { read write } for pid=1907 comm="iptables" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket > node=troodos.org.uk type=SYSCALL msg=audit(1260298720.4:21): arch=40000003 syscall=11 success=yes exit=0 a0=8a1a250 a1=8a1a460 a2=8a19738 a3=8a1a460 items=0 ppid=1906 pid=1907 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/iptables" subj=system_u:system_r:iptables_t:s0 key=(null) > > Raw Audit Messages : > > node=troodos.org.uk type=AVC msg=audit(1260298720.169:22): avc: denied { read write } for pid=1921 comm="sendmail" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket > node=troodos.org.uk type=SYSCALL msg=audit(1260298720.169:22): arch=40000003 syscall=11 success=yes exit=0 a0=85867d0 a1=8587798 a2=8587670 a3=8587798 items=0 ppid=1919 pid=1921 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:system_mail_t:s0 key=(null) > > Raw Audit Messages : > > node=troodos.org.uk type=AVC msg=audit(1260301404.622:121): avc: denied { read write } for pid=2799 comm="iptables" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket > node=troodos.org.uk type=SYSCALL msg=audit(1260301404.622:121): arch=40000003 syscall=11 success=yes exit=0 a0=88b13e0 a1=88b1618 a2=88b06f8 a3=88b1618 items=0 ppid=2798 pid=2799 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/iptables" subj=system_u:system_r:iptables_t:s0 key=(null) > > Raw Audit Messages : > > node=troodos.org.uk type=AVC msg=audit(1260301405.169:122): avc: denied { read write } for pid=2804 comm="iptables" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket > node=troodos.org.uk type=SYSCALL msg=audit(1260301405.169:122): arch=40000003 syscall=11 success=yes exit=0 a0=96e3418 a1=96e3718 a2=96e2700 a3=96e3718 items=0 ppid=1901 pid=2804 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/iptables" subj=system_u:system_r:iptables_t:s0 key=(null) > > Raw Audit Messages : > > node=troodos.org.uk type=AVC msg=audit(1260301405.212:123): avc: denied { read write } for pid=2811 comm="sendmail" path="socket:[16217]" dev=sockfs ino=16217 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket > node=troodos.org.uk type=SYSCALL msg=audit(1260301405.212:123): arch=40000003 syscall=11 success=yes exit=0 a0=a119518 a1=a119a48 a2=a119750 a3=a119a48 items=0 ppid=2807 pid=2811 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:system_mail_t:s0 key=(null) > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From misc.lists at blueyonder.co.uk Tue Dec 8 21:15:48 2009 From: misc.lists at blueyonder.co.uk (Arthur Dent) Date: Tue, 08 Dec 2009 21:15:48 +0000 Subject: Selinux & Fail2Ban In-Reply-To: <20091208205728.GA9740@localhost.localdomain> References: <20091206115908.GA2886@localhost.localdomain> <1260135861.3083.37.camel@localhost> <20091207114947.GB2942@localhost.localdomain> <1260223906.3056.24.camel@localhost> <20091207221757.GB6387@localhost.localdomain> <1260225261.3056.43.camel@localhost> <20091207223639.GD6387@localhost.localdomain> <1260225855.3056.47.camel@localhost> <20091207225136.GE6387@localhost.localdomain> <1260305012.5969.23.camel@localhost> <20091208205728.GA9740@localhost.localdomain> Message-ID: <1260306948.5969.31.camel@localhost> On Tue, 2009-12-08 at 21:57 +0100, Dominick Grift wrote: > > So what do you think? > > > > Am I on the right track? > > Yes "allow system_mail_t fail2ban_t:unix_stream_socket { read write };", signals a leaked file descriptor on fail2ban. This issue is known. You can ignore those avc denials and/or silence them: What exactly *is* a "leaked file descriptor"? > echo "policy_module(myfail2ban, 1.0.0)" > myfail2ban.te; > echo "optional_policy(\`" >> myfail2ban.te; > echo "gen_require(\`" >> myfail2ban.te; > echo "attribute domain;" >> myfail2ban.te; > echo "type fail2ban_t;" >> myfail2ban.te; > echo "\')" >> myfail2ban.te; > echo "dontaudit domain fail2ban_t:unix_stream_socket { read write };" >> myfail2ban.te; > echo "\')" >> myfail2ban.te; OK - Thanks for this. It's not the way I'm used to generating local policies and I think there may be an error? Once all the lines are echo'd into myfail2ban.te this is what I get: # cat myfail2ban.te policy_module(myfail2ban, 11.2.1) optional_policy(` gen_require(` attribute domain; type fail2ban_t; \') dontaudit domain fail2ban_t:unix_stream_socket { read write }; \') Which won't compile: > make -f /usr/share/selinux/devel/Makefile myfail2ban.pp > sudo semodule -i myfail2ban.pp Gives: # make -f /usr/share/selinux/devel/Makefile myfail2ban.pp Compiling targeted myfail2ban module /usr/bin/checkmodule: loading policy configuration from tmp/myfail2ban.tmp myfail2ban.te":2:WARNING 'unrecognized character' at token '\' on line 3204: \ #line 2 myfail2ban.te":2:WARNING 'unrecognized character' at token '\' on line 3214: \ #line 2 myfail2ban.te":2:WARNING 'unrecognized character' at token '\' on line 3204: \ #line 2 myfail2ban.te":2:WARNING 'unrecognized character' at token '\' on line 3214: \ #line 2 /usr/bin/checkmodule: policy configuration loaded /usr/bin/checkmodule: writing binary representation (version 10) to tmp/myfail2ban.mod Creating targeted myfail2ban.pp policy package rm tmp/myfail2ban.mod.fc tmp/myfail2ban.mod I'm not exactly sure what you had in mind otherwise I would edit it to work... But thanks again. I do appreciate your help! Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From domg472 at gmail.com Tue Dec 8 21:24:39 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 8 Dec 2009 22:24:39 +0100 Subject: Selinux & Fail2Ban In-Reply-To: <1260306948.5969.31.camel@localhost> References: <20091207114947.GB2942@localhost.localdomain> <1260223906.3056.24.camel@localhost> <20091207221757.GB6387@localhost.localdomain> <1260225261.3056.43.camel@localhost> <20091207223639.GD6387@localhost.localdomain> <1260225855.3056.47.camel@localhost> <20091207225136.GE6387@localhost.localdomain> <1260305012.5969.23.camel@localhost> <20091208205728.GA9740@localhost.localdomain> <1260306948.5969.31.camel@localhost> Message-ID: <20091208212438.GB9740@localhost.localdomain> On Tue, Dec 08, 2009 at 09:15:48PM +0000, Arthur Dent wrote: > On Tue, 2009-12-08 at 21:57 +0100, Dominick Grift wrote: > > > > So what do you think? > > > > > > Am I on the right track? > > > > Yes "allow system_mail_t fail2ban_t:unix_stream_socket { read write };", signals a leaked file descriptor on fail2ban. This issue is known. You can ignore those avc denials and/or silence them: > > What exactly *is* a "leaked file descriptor"? > > > > echo "policy_module(myfail2ban, 1.0.0)" > myfail2ban.te; > > echo "optional_policy(\`" >> myfail2ban.te; > > echo "gen_require(\`" >> myfail2ban.te; > > echo "attribute domain;" >> myfail2ban.te; > > echo "type fail2ban_t;" >> myfail2ban.te; > > echo "\')" >> myfail2ban.te; > > echo "dontaudit domain fail2ban_t:unix_stream_socket { read write };" >> myfail2ban.te; > > echo "\')" >> myfail2ban.te; > > OK - Thanks for this. It's not the way I'm used to generating local > policies and I think there may be an error? Once all the lines are > echo'd into myfail2ban.te this is what I get: > # cat myfail2ban.te > > policy_module(myfail2ban, 11.2.1) > optional_policy(` > gen_require(` > attribute domain; > type fail2ban_t; > \') > dontaudit domain fail2ban_t:unix_stream_socket { read write }; > \') Your myfail2ban.te file should look like this: policy_module(myfail2ban, 11.2.1) optional_policy(` gen_require(` attribute domain; type fail2ban_t; ') dontaudit domain fail2ban_t:unix_stream_socket { read write }; ') A leaked file descriptor is a programming error it is where the programmer forgot to close a file descriptor (bug in fail2ban) > > Which won't compile: > > make -f /usr/share/selinux/devel/Makefile myfail2ban.pp > > sudo semodule -i myfail2ban.pp > Gives: > > # make -f /usr/share/selinux/devel/Makefile myfail2ban.pp > Compiling targeted myfail2ban module > /usr/bin/checkmodule: loading policy configuration from > tmp/myfail2ban.tmp > myfail2ban.te":2:WARNING 'unrecognized character' at token '\' on line > 3204: > \ > #line 2 > myfail2ban.te":2:WARNING 'unrecognized character' at token '\' on line > 3214: > \ > #line 2 > myfail2ban.te":2:WARNING 'unrecognized character' at token '\' on line > 3204: > \ > #line 2 > myfail2ban.te":2:WARNING 'unrecognized character' at token '\' on line > 3214: > \ > #line 2 > /usr/bin/checkmodule: policy configuration loaded > /usr/bin/checkmodule: writing binary representation (version 10) to > tmp/myfail2ban.mod > Creating targeted myfail2ban.pp policy package > rm tmp/myfail2ban.mod.fc tmp/myfail2ban.mod > > > I'm not exactly sure what you had in mind otherwise I would edit it to > work... > > > But thanks again. I do appreciate your help! > > Mark > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From misc.lists at blueyonder.co.uk Tue Dec 8 21:37:59 2009 From: misc.lists at blueyonder.co.uk (Arthur Dent) Date: Tue, 08 Dec 2009 21:37:59 +0000 Subject: Selinux & Fail2Ban In-Reply-To: <20091208212438.GB9740@localhost.localdomain> References: <20091207114947.GB2942@localhost.localdomain> <1260223906.3056.24.camel@localhost> <20091207221757.GB6387@localhost.localdomain> <1260225261.3056.43.camel@localhost> <20091207223639.GD6387@localhost.localdomain> <1260225855.3056.47.camel@localhost> <20091207225136.GE6387@localhost.localdomain> <1260305012.5969.23.camel@localhost> <20091208205728.GA9740@localhost.localdomain> <1260306948.5969.31.camel@localhost> <20091208212438.GB9740@localhost.localdomain> Message-ID: <1260308279.5969.34.camel@localhost> On Tue, 2009-12-08 at 22:24 +0100, Dominick Grift wrote: > > Your myfail2ban.te file should look like this: > > policy_module(myfail2ban, 11.2.1) > optional_policy(` > gen_require(` > attribute domain; > type fail2ban_t; > ') > dontaudit domain fail2ban_t:unix_stream_socket { read write }; > ') That did it - Thanks! > A leaked file descriptor is a programming error it is where the programmer forgot to close a file descriptor (bug in fail2ban) How can I explain this to the f2b developers so that it can be fixed? Thanks - yet again! Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dpquigl at tycho.nsa.gov Tue Dec 8 21:52:44 2009 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Tue, 08 Dec 2009 16:52:44 -0500 Subject: Selinux & Fail2Ban In-Reply-To: <1260308279.5969.34.camel@localhost> References: <20091207114947.GB2942@localhost.localdomain> <1260223906.3056.24.camel@localhost> <20091207221757.GB6387@localhost.localdomain> <1260225261.3056.43.camel@localhost> <20091207223639.GD6387@localhost.localdomain> <1260225855.3056.47.camel@localhost> <20091207225136.GE6387@localhost.localdomain> <1260305012.5969.23.camel@localhost> <20091208205728.GA9740@localhost.localdomain> <1260306948.5969.31.camel@localhost> <20091208212438.GB9740@localhost.localdomain> <1260308279.5969.34.camel@localhost> Message-ID: <1260309164.2484.220.camel@moss-terrapins.epoch.ncsc.mil> On Tue, 2009-12-08 at 21:37 +0000, Arthur Dent wrote: > On Tue, 2009-12-08 at 22:24 +0100, Dominick Grift wrote: > > > > > Your myfail2ban.te file should look like this: > > > > policy_module(myfail2ban, 11.2.1) > > optional_policy(` > > gen_require(` > > attribute domain; > > type fail2ban_t; > > ') > > dontaudit domain fail2ban_t:unix_stream_socket { read write }; > > ') > > That did it - Thanks! > > > A leaked file descriptor is a programming error it is where the programmer forgot to close a file descriptor (bug in fail2ban) > > How can I explain this to the f2b developers so that it can be fixed? > So I have copied a small section from Dan Walsh's blog. Its a bit more than forgetting to close a file descriptor. The problem is that by default on exec the child process will inherit all file descriptors from the parent except ones that are closed before exec or marked close on exec with the fcntl listed below. One of the interesting things about SELinux is its use to discover bugs in other code. When I first started working with SELinux a few years ago, we started discovering a whole bunch of domains wanting to read and write system_u:object_r:initctl_t file. This is the context of the /dev/initctl device. After investigating for a while we found out something in the boot process was leaking an open file descriptor to /dev/initctl. This open file descriptor would allow a compromised application to change the run level of the system. Of course all of these AVC messages were being reported as bugs in SELinux, but really they were a serious bug in the boot process. Investigating this problem further I found that the default behavior of all file descriptors is to have them inherited over the fork/exec. You have to execute fcntl(fd, F_SETFD, FD_CLOEXEC); on all file descriptors that you do not want to be leaked. Needless to say, lots of programmers forget this and leaked file descriptors are quite common. Dan Walsh > Thanks - yet again! > > Mark > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From jorge.fabregas at gmail.com Wed Dec 9 12:06:15 2009 From: jorge.fabregas at gmail.com (Jorge =?iso-8859-1?q?F=E1bregas?=) Date: Wed, 9 Dec 2009 08:06:15 -0400 Subject: Targeted Daemons/Apps- Fedora 12 In-Reply-To: <20091208124532.GA3462@localhost.localdomain> References: <200912080821.42031.jorge.fabregas@gmail.com> <20091208124532.GA3462@localhost.localdomain> Message-ID: <200912090806.15528.jorge.fabregas@gmail.com> Thanks Dominick for the nice explanation. Ok, now I understand it's not as straightforward as I thought. I originally asked because I remember when RHEL4 and RHEL5 came out, among the new features list, was this list of the "targeted daemons". Now...as I'm considering SELinux for personal/desktop use. (in Fedora) I was wondering which typical apps (of the base install) were protected (like Thunderbird, Firefox, etc...). Again, thanks for pointing me to the right direction. All the best, Jorge From dwalsh at redhat.com Wed Dec 9 18:34:14 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 09 Dec 2009 13:34:14 -0500 Subject: Targeted Daemons/Apps- Fedora 12 In-Reply-To: <200912090806.15528.jorge.fabregas@gmail.com> References: <200912080821.42031.jorge.fabregas@gmail.com> <20091208124532.GA3462@localhost.localdomain> <200912090806.15528.jorge.fabregas@gmail.com> Message-ID: <4B1FEDA6.1000108@redhat.com> On 12/09/2009 07:06 AM, Jorge F?bregas wrote: > Thanks Dominick for the nice explanation. Ok, now I understand it's not as > straightforward as I thought. > > I originally asked because I remember when RHEL4 and RHEL5 came out, among the > new features list, was this list of the "targeted daemons". Now...as I'm > considering SELinux for personal/desktop use. (in Fedora) I was wondering > which typical apps (of the base install) were protected (like Thunderbird, > Firefox, etc...). > > Again, thanks for pointing me to the right direction. > > All the best, > Jorge > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > You can see all the types associate with processes by executing seinfo -adomain -x | wc -l 506 Permissive domains # seinfo --permissive| wc -l 32 Unconfined domains # seinfo -aunconfined_domain_type -x | wc -l 51 Unconfined domains with unconfined pp file disabled #semodule -d unconfined # seinfo -aunconfined_domain_type -x | wc -l 16 From goeran at uddeborg.se Wed Dec 9 19:37:07 2009 From: goeran at uddeborg.se (=?utf-8?Q?G=C3=B6ran?= Uddeborg) Date: Wed, 9 Dec 2009 20:37:07 +0100 Subject: Selinux & Fail2Ban In-Reply-To: <1260308279.5969.34.camel@localhost> References: <20091207114947.GB2942@localhost.localdomain> <1260223906.3056.24.camel@localhost> <20091207221757.GB6387@localhost.localdomain> <1260225261.3056.43.camel@localhost> <20091207223639.GD6387@localhost.localdomain> <1260225855.3056.47.camel@localhost> <20091207225136.GE6387@localhost.localdomain> <1260305012.5969.23.camel@localhost> <20091208205728.GA9740@localhost.localdomain> <1260306948.5969.31.camel@localhost> <20091208212438.GB9740@localhost.localdomain> <1260308279.5969.34.camel@localhost> Message-ID: <19231.64611.828376.719927@freddi.uddeborg> Arthur Dent: > How can I explain this to the f2b developers so that it can be fixed? For your information: I filed a bug about it a little more than a year ago: http://sourceforge.net/tracker/?func=detail&atid=689044&aid=2086568&group_id=121032 There hasn't been any action as far as I can tell. But maybe you'll have more luck if you do a new try now. From dwalsh at redhat.com Wed Dec 9 21:41:55 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 09 Dec 2009 16:41:55 -0500 Subject: Selinux & Fail2Ban In-Reply-To: <19231.64611.828376.719927@freddi.uddeborg> References: <20091207114947.GB2942@localhost.localdomain> <1260223906.3056.24.camel@localhost> <20091207221757.GB6387@localhost.localdomain> <1260225261.3056.43.camel@localhost> <20091207223639.GD6387@localhost.localdomain> <1260225855.3056.47.camel@localhost> <20091207225136.GE6387@localhost.localdomain> <1260305012.5969.23.camel@localhost> <20091208205728.GA9740@localhost.localdomain> <1260306948.5969.31.camel@localhost> <20091208212438.GB9740@localhost.localdomain> <1260308279.5969.34.camel@localhost> <19231.64611.828376.719927@freddi.uddeborg> Message-ID: <4B2019A3.1060504@redhat.com> On 12/09/2009 02:37 PM, G?ran Uddeborg wrote: > Arthur Dent: >> How can I explain this to the f2b developers so that it can be fixed? > > For your information: I filed a bug about it a little more than a year > ago: > http://sourceforge.net/tracker/?func=detail&atid=689044&aid=2086568&group_id=121032 > > There hasn't been any action as far as I can tell. But maybe you'll > have more luck if you do a new try now. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Fail2ban developers are well aware of this, they have been dealing with leaks for a while From jorge.fabregas at gmail.com Thu Dec 10 23:26:02 2009 From: jorge.fabregas at gmail.com (Jorge =?iso-8859-1?q?F=E1bregas?=) Date: Thu, 10 Dec 2009 19:26:02 -0400 Subject: Targeted Daemons/Apps- Fedora 12 In-Reply-To: <4B1FEDA6.1000108@redhat.com> References: <200912080821.42031.jorge.fabregas@gmail.com> <200912090806.15528.jorge.fabregas@gmail.com> <4B1FEDA6.1000108@redhat.com> Message-ID: <200912101926.02861.jorge.fabregas@gmail.com> Thank you Daniel. That's right on. All the best, Jorge From dhighley at highley-recommended.com Fri Dec 11 03:22:59 2009 From: dhighley at highley-recommended.com (David Highley) Date: Thu, 10 Dec 2009 19:22:59 -0800 (PST) Subject: sebools are getting reset on reboot Message-ID: <200912110322.nBB3MxdY002739@douglas.highley-recommended.com> Is this a bug? The two sebools, httpd_unified and httpd_can_network_connect, are getting changed on policy updates and or reboots. From bruno at wolff.to Fri Dec 11 06:13:51 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 11 Dec 2009 00:13:51 -0600 Subject: sebools are getting reset on reboot In-Reply-To: <200912110322.nBB3MxdY002739@douglas.highley-recommended.com> References: <200912110322.nBB3MxdY002739@douglas.highley-recommended.com> Message-ID: <20091211061351.GA16405@wolff.to> On Thu, Dec 10, 2009 at 19:22:59 -0800, David Highley wrote: > Is this a bug? The two sebools, httpd_unified and > httpd_can_network_connect, are getting changed on policy updates and or > reboots. Are you using the -P option when using the setsebool command? If you are using setsebool without it, then it is expected to reset on the next reboot. From misc.lists at blueyonder.co.uk Mon Dec 14 10:01:07 2009 From: misc.lists at blueyonder.co.uk (Arthur Dent) Date: Mon, 14 Dec 2009 10:01:07 +0000 Subject: Logrotate frustration In-Reply-To: <1260225022.3056.40.camel@localhost> References: <1260092312.3083.10.camel@localhost> <4B1D7275.6020400@redhat.com> <1260225022.3056.40.camel@localhost> Message-ID: <1260784867.3069.18.camel@localhost> On Mon, 2009-12-07 at 22:30 +0000, Arthur Dent wrote: > On Mon, 2009-12-07 at 16:24 -0500, Daniel J Walsh wrote: > > On 12/06/2009 04:38 AM, Arthur Dent wrote: > > > Hello all, > > > > > > Its seems that almost every week logrotate is throwing up a new AVC. I > > > have an almost vanilla F11 install with most packages installed via yum > > > and yet I keep getting these. Each time I audit2allow and build a new > > > policy. My "mylogr.te" is now at version 7. Am I missing a bool or is > > > there something else I'm lacking? > > > > > > Here is the latest version of my policy: > > > > > > > > > ===============8<================================================== > > > > > > module mylogr 11.1.7; > > > > > > require { > > > type mail_spool_t; > > > type logrotate_t; > > > type fail2ban_var_run_t; > > > type initrc_t; > > > type squid_log_t; > > > class dir {read open write remove_name}; > > > class file { getattr read write open}; > > > class file setattr; > > > class sock_file write; > > > class unix_stream_socket connectto; > > > class lnk_file rename; > > > } > > > > > > #============= logrotate_t ============== > > > allow logrotate_t mail_spool_t:file { getattr read write open }; > > > allow logrotate_t mail_spool_t:dir { read open write remove_name}; > > > allow logrotate_t mail_spool_t:file setattr; > > > allow logrotate_t fail2ban_var_run_t:sock_file write; > > > allow logrotate_t initrc_t:unix_stream_socket connectto; > > > allow logrotate_t squid_log_t:lnk_file rename; > > > > > > ===============8<================================================== > > > > > > > > > This was today's AVC that necessitated the inclusion of the squid stuff: > > > > > > ===============8<================================================== > > > Raw Audit Messages : > > > > > > node=mydomain.org.uk type=AVC msg=audit(1260069452.494:45041): avc: denied { rename } for pid=12302 comm="logrotate" name="squidGuard.log" dev=sda5 ino=387195 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:squid_log_t:s0 tclass=lnk_file > > > node=mydomain.org.uk type=SYSCALL msg=audit(1260069452.494:45041): arch=40000003 syscall=38 success=no exit=-13 a0=890b130 a1=8908760 a2=890b060 a3=0 items=0 ppid=12300 pid=12302 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2275 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null) > > > ===============8<================================================== > > > > > > > > > > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > I can allow logrotate to manage log lnk_files, and allow it to write to the fail2ban socket. > > > > Are you using a custom logrotate to rotate mail_spool? > > > > Why is > > I think that my problem with mailspool/logrotate is that it relates to > my mail backup system in which procmail places a copy of every mail (in > mbox format) onto a separate partition on the same machine. This seemed > to cause labelling problems and we went round the houses on this issue a > while back ("Partitions Mounted by fstab" 5 March 2008 - > https://www.redhat.com/archives/fedora-selinux-list/2008-March/msg00030.html) > > Thanks for your help - much appreciated... > > Mark OK - Following another arm of this thread I have (last week) done a complete relabel and removed my existing fail2ban and logrotate local policies. As a result of yesterday's weekly log rotate squid threw up another couple of AVCs related to log_lnk (see below). I have created another local policy but, do I understand you correctly Daniel that you may include log_lnk in a future targeted policy? Here is my new logrotate policy: ===============8<================================================== module mylogr 11.2.2; require { type mail_spool_t; type logrotate_t; type squid_log_t; class file getattr; class lnk_file { rename unlink }; } #============= logrotate_t ============== allow logrotate_t mail_spool_t:file getattr; allow logrotate_t squid_log_t:lnk_file { rename unlink }; ===============8<================================================== Is this OK? Thanks for any help or suggestions... Mark p.s. Logrotate AVCs Raw Audit Messages : node=troodos.org.uk type=AVC msg=audit(1260331775.761:1220): avc: denied { getattr } for pid=31349 comm="logrotate" path="/mnt/backup/mail/rawmail" dev=sda9 ino=2490369 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mail_spool_t:s0 tclass=file node=troodos.org.uk type=SYSCALL msg=audit(1260331775.761:1220): arch=40000003 syscall=196 success=yes exit=0 a0=9e59668 a1=bfd3e864 a2=bf5ff4 a3=1 items=0 ppid=31347 pid=31349 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=257 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null) Raw Audit Messages : node=troodos.org.uk type=AVC msg=audit(1260675470.813:43484): avc: denied { rename } for pid=11490 comm="logrotate" name="squidGuard.log" dev=sda5 ino=387195 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:squid_log_t:s0 tclass=lnk_file node=troodos.org.uk type=SYSCALL msg=audit(1260675470.813:43484): arch=40000003 syscall=38 success=yes exit=0 a0=8295138 a1=8298f98 a2=8295068 a3=0 items=0 ppid=11488 pid=11490 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1554 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null) Raw Audit Messages : node=troodos.org.uk type=AVC msg=audit(1260675471.68:43485): avc: denied { unlink } for pid=11490 comm="logrotate" name="squidGuard.log.1" dev=sda5 ino=387195 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:squid_log_t:s0 tclass=lnk_file node=troodos.org.uk type=SYSCALL msg=audit(1260675471.68:43485): arch=40000003 syscall=10 success=yes exit=0 a0=8298f98 a1=bfbeffa8 a2=8298f98 a3=bfbeff70 items=0 ppid=11488 pid=11490 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1554 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From roberto.sassu at polito.it Mon Dec 14 10:11:04 2009 From: roberto.sassu at polito.it (Roberto Sassu) Date: Mon, 14 Dec 2009 11:11:04 +0100 Subject: ecryptfs selinux labeling on Fedora 12 Message-ID: <200912141111.09024.roberto.sassu@polito.it> Hi all i'm using Fedora12 and i have configured an ecryptfs filesystem. I see that the default behaviour for this filesystem is to use an unique mount- wide context (ecryptfs_t) to label each file. There's a way to override this behaviour (for example by inserting a mount parameter), in order to use the extended attributes on the lower filesystem or patching the distributed selinux policy is the only option possible? Thanks in advance for replies. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2153 bytes Desc: not available URL: From sds at tycho.nsa.gov Mon Dec 14 15:05:27 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 14 Dec 2009 10:05:27 -0500 Subject: ecryptfs selinux labeling on Fedora 12 In-Reply-To: <200912141111.09024.roberto.sassu@polito.it> References: <200912141111.09024.roberto.sassu@polito.it> Message-ID: <1260803127.4126.8.camel@moss-pluto.epoch.ncsc.mil> On Mon, 2009-12-14 at 11:11 +0100, Roberto Sassu wrote: > Hi all > > i'm using Fedora12 and i have configured an ecryptfs filesystem. > I see that the default behaviour for this filesystem is to use an unique mount- > wide context (ecryptfs_t) to label each file. > There's a way to override this behaviour (for example by inserting a mount > parameter), in order to use the extended attributes on the lower filesystem or > patching the distributed selinux policy is the only option possible? > > Thanks in advance for replies. You'd have to modify, rebuild, and replace the base policy module to specify fs_use_xattr for ecryptfs rather than genfscon. There was an attempt to automate probing for xattr support and use it if present, but it ran into problems, see: http://marc.info/?t=121379726100001&r=1&w=2 -- Stephen Smalley National Security Agency From serue at us.ibm.com Mon Dec 14 17:49:15 2009 From: serue at us.ibm.com (Serge E. Hallyn) Date: Mon, 14 Dec 2009 11:49:15 -0600 Subject: The SELinux Documentation Project In-Reply-To: <4B1175BA.1060604@manicmethod.com> References: <4AC1130D.8000601@manicmethod.com> <4B103712.2050709@manicmethod.com> <4B1114E9.7060806@gmail.com> <4B1175BA.1060604@manicmethod.com> Message-ID: <20091214174915.GA14651@us.ibm.com> Quoting Joshua Brindle (method at manicmethod.com): > Dominick Grift wrote: > >On 11/27/2009 09:31 PM, Joshua Brindle wrote: > >>Joshua Brindle wrote: > >>>As we discussed at Linux Plumbers Conference during the 'Making SELinux > >>>Easier to Use" talk we have some document deficiencies in the SELinux > >>>project. > >>> > >> > >> > >>We have gotten some good contributions to the documentation project over > >>the last couple months but there is always more to do. I've updated the > >>Documentation TODO at: > >> > >> > >> > >>with some docs we'd like written and some guidance on what the format > >>should be. Use cases would be particularly appreciated. > >> > >>If you haven't gone to the documentation wiki lately take a look at > >> > >> > >> > >>and see what's been added. > >> > >>Thanks for the help of the contributors and hopefully this effort will > >>go a long way toward gaining users and keeping SELinux enabled. > >> > >>-- > >>fedora-selinux-list mailing list > >>fedora-selinux-list at redhat.com > >>https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > >Attached is a concept i wrote today about Locking down webapps with CGI. > >This was a topic in the todo list. > > > >Would be nice if someone could proof-read this and when > >modified/accepted publish it. > > It's a wiki :) Just put it up there and others can make How are we to create an account to edit a page? The 'Log in/Create Account' page doesn't seem to let me create an account? I'd like to add the recipe useradd xa semanage user -a -R user_r xa semanage login -a -s xa xa to lock user xa into its own selinux context to the recipes page. If someone else is willing to post it, all the better. > modifications. There are actually a couple people who are decent at > copy editing that have done some work on the wiki so if we get > technical content up there they can do what they do to clean it up. thanks, -serge From domg472 at gmail.com Mon Dec 14 18:12:08 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 14 Dec 2009 19:12:08 +0100 Subject: The SELinux Documentation Project In-Reply-To: <20091214174915.GA14651@us.ibm.com> References: <4AC1130D.8000601@manicmethod.com> <4B103712.2050709@manicmethod.com> <4B1114E9.7060806@gmail.com> <4B1175BA.1060604@manicmethod.com> <20091214174915.GA14651@us.ibm.com> Message-ID: <20091214181207.GA2646@localhost.localdomain> On Mon, Dec 14, 2009 at 11:49:15AM -0600, Serge E. Hallyn wrote: > Quoting Joshua Brindle (method at manicmethod.com): > > Dominick Grift wrote: > > >On 11/27/2009 09:31 PM, Joshua Brindle wrote: > > >>Joshua Brindle wrote: > > >>>As we discussed at Linux Plumbers Conference during the 'Making SELinux > > >>>Easier to Use" talk we have some document deficiencies in the SELinux > > >>>project. > > >>> > > >> > > >> > > >>We have gotten some good contributions to the documentation project over > > >>the last couple months but there is always more to do. I've updated the > > >>Documentation TODO at: > > >> > > >> > > >> > > >>with some docs we'd like written and some guidance on what the format > > >>should be. Use cases would be particularly appreciated. > > >> > > >>If you haven't gone to the documentation wiki lately take a look at > > >> > > >> > > >> > > >>and see what's been added. > > >> > > >>Thanks for the help of the contributors and hopefully this effort will > > >>go a long way toward gaining users and keeping SELinux enabled. > > >> > > >>-- > > >>fedora-selinux-list mailing list > > >>fedora-selinux-list at redhat.com > > >>https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > >Attached is a concept i wrote today about Locking down webapps with CGI. > > >This was a topic in the todo list. > > > > > >Would be nice if someone could proof-read this and when > > >modified/accepted publish it. > > > > It's a wiki :) Just put it up there and others can make > > How are we to create an account to edit a page? The 'Log in/Create > Account' page doesn't seem to let me create an account? > > I'd like to add the recipe > > useradd xa > semanage user -a -R user_r xa > semanage login -a -s xa xa You would probably also need: cd /etc/selinux/targeted/contexts/users; cp user_u xa; To make that work. Easier would probably be: useradd -Z user_u xa or useradd xa semanage login -m -s user_u -r s0-s0 xa You should send an e-mail to james morris. He maintains the site and will add a login if you ask him. > > to lock user xa into its own selinux context to the recipes page. > If someone else is willing to post it, all the better. > > > modifications. There are actually a couple people who are decent at > > copy editing that have done some work on the wiki so if we get > > technical content up there they can do what they do to clean it up. > > thanks, > -serge -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dhighley at highley-recommended.com Mon Dec 14 18:25:08 2009 From: dhighley at highley-recommended.com (David Highley) Date: Mon, 14 Dec 2009 10:25:08 -0800 (PST) Subject: Fedora 12 and unconfined_u sshdfilter In-Reply-To: <20091207202828.GA6387@localhost.localdomain> Message-ID: <200912141825.nBEIP8WR027234@douglas.highley-recommended.com> "Dominick Grift wrote:" > > > --===============0725889959== > Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" > Content-Disposition: inline > > > --uAKRQypu60I7Lcqm > Content-Type: text/plain; charset=utf-8 > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Mon, Dec 07, 2009 at 12:01:09PM +0000, Moray Henderson (ICT) wrote: > > James Carter wrote: > > >Dan's example used Refpolicy interfaces. Interfaces are very useful and > > >provide a better layer of abstraction, but they are just m4 macros, > > >which have always been used in SELinux policy. > > > > > >Interfaces should be used as much as possible, but it is not true that > > >you can't mix the old and new ways. > >=20 > > Mixing the plain rules and the m4 macros didn't work when I tried it - bu= > t perhaps I just wasn=E2=80=99t writing it right. Is there a Refpolicy tut= > orial anywhere? > > I spend a little time today writing about the policy structure in Fedora. M= > aybe it can help you or others: > > http://82.197.205.60/~dgrift/stuff/Managing_a_SELinux_environment_with_Fedo= > ra_12.pdf Still have not mastered this one yet. Here is the policy file created by grep of /var/log/audit/audit.log file piped to audit2allow: module mysshdfilter 1.0; require { type var_run_t; type iptables_exec_t; type bin_t; type sshd_t; type iptables_t; class lnk_file read; class file { read getattr open execute execute_no_trans }; class fifo_file { read write ioctl getattr }; } #============= iptables_t ============== allow iptables_t bin_t:lnk_file read; allow iptables_t self:fifo_file { read write ioctl getattr }; #============= sshd_t ============== allow sshd_t iptables_exec_t:file { read execute open execute_no_trans }; allow sshd_t var_run_t:file getattr; The audit log entries are: type=AVC msg=audit(1259642932.902:7): avc: denied { execute } for pid=1411 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259642932.902:7): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1562e28 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=1411 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259644707.700:73): avc: denied { execute } for pid=1948 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259644707.700:73): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=15694c8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=1948 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259650605.247:84): avc: denied { execute } for pid=2248 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259650605.247:84): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1567828 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=2248 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259661894.420:113): avc: denied { execute } for pid=2815 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259661894.420:113): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1566e28 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=2815 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259667665.966:123): avc: denied { execute } for pid=3724 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259667665.966:123): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=15699d8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=3724 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259671660.048:131): avc: denied { execute } for pid=3920 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259671660.048:131): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1565778 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=3920 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259673411.553:758): avc: denied { execute } for pid=4558 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259673411.553:758): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1569af8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=4558 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259679153.568:1267): avc: denied { execute } for pid=5170 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259679153.568:1267): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1566a68 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=5170 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259682588.736:1315): avc: denied { execute } for pid=5540 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259682588.736:1315): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1565778 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=5540 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259684861.197:1344): avc: denied { execute } for pid=5745 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259684861.197:1344): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a478 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=5745 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259690558.951:1388): avc: denied { execute } for pid=6161 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259690558.951:1388): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=15667a8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=6161 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259702647.573:1433): avc: denied { execute } for pid=6829 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259702647.573:1433): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156b4d8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=6829 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259708100.231:1441): avc: denied { execute } for pid=7085 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259708100.231:1441): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a0b8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=7085 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259708922.953:1450): avc: denied { execute } for pid=7153 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259708922.953:1450): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a6a8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=7153 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259713257.803:1545): avc: denied { execute } for pid=7492 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259713257.803:1545): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a4a8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=7492 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259721513.893:1732): avc: denied { execute } for pid=8097 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259721513.893:1732): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a5d8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=8097 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259730724.196:1790): avc: denied { execute } for pid=8689 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259730724.196:1790): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1569718 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=8689 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259730728.123:1793): avc: denied { execute } for pid=8699 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259730728.123:1793): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1566778 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=8699 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259747840.157:1835): avc: denied { execute } for pid=9575 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259747840.157:1835): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156ba78 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=9575 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259760819.408:1863): avc: denied { execute } for pid=10840 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259760819.408:1863): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a4a8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=10840 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259762576.442:1887): avc: denied { execute } for pid=11067 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259762576.442:1887): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d4d5a8 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=11067 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259767362.673:1896): avc: denied { execute } for pid=11318 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259767362.673:1896): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d54088 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=11318 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259773905.214:1967): avc: denied { execute } for pid=11922 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259773905.214:1967): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d54868 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=11922 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259780362.196:1977): avc: denied { execute } for pid=12215 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259780362.196:1977): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d50af8 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=12215 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259780393.314:1979): avc: denied { execute } for pid=12219 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259780393.314:1979): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d50af8 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=12219 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259785085.323:2012): avc: denied { execute } for pid=12568 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259785085.323:2012): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d521b8 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=12568 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259786872.756:2015): avc: denied { execute } for pid=12645 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259786872.756:2015): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d53568 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=12645 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259795695.936:2052): avc: denied { execute } for pid=13127 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259795695.936:2052): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d52e38 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=13127 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259802506.518:3031): avc: denied { getattr } for pid=11058 comm="sshdfilter" path="/var/run/sshdfilter.pid.SSHD" dev=dm-0 ino=12538 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file type=SYSCALL msg=audit(1259802506.518:3031): arch=c000003e syscall=6 success=no exit=-13 a0=d4a128 a1=a0d0a0 a2=a0d0a0 a3=7fffb9164bb0 items=0 ppid=1 pid=11058 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259802888.332:7): avc: denied { ioctl } for pid=1435 comm="sshdfilter" path="pipe:[11021]" dev=pipefs ino=11021 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802888.332:7): arch=c000003e syscall=16 success=yes exit=128 a0=3 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1431 pid=1435 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.340:8): avc: denied { ioctl } for pid=1435 comm="sshdfilter" path="pipe:[11021]" dev=pipefs ino=11021 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802888.340:8): arch=c000003e syscall=16 success=yes exit=128 a0=4 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1431 pid=1435 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.342:9): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11031]" dev=pipefs ino=11031 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=AVC msg=audit(1259802888.343:10): avc: denied { read } for pid=1435 comm="sshdfilter" path="pipe:[11021]" dev=pipefs ino=11021 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802888.343:10): arch=c000003e syscall=0 success=yes exit=128 a0=3 a1=eb06e8 a2=1000 a3=0 items=0 ppid=1431 pid=1435 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=SYSCALL msg=audit(1259802888.342:9): arch=c000003e syscall=16 success=yes exit=128 a0=5 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.347:11): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11031]" dev=pipefs ino=11031 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802888.347:11): arch=c000003e syscall=16 success=yes exit=128 a0=6 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.350:12): avc: denied { read } for pid=1439 comm="sshdfilter" path="pipe:[11031]" dev=pipefs ino=11031 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802888.350:12): arch=c000003e syscall=0 success=yes exit=128 a0=5 a1=eb0f18 a2=1000 a3=0 items=0 ppid=1438 pid=1439 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.360:13): avc: denied { read } for pid=1440 comm="sshdfilter" name="sh" dev=dm-0 ino=10258 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1259802888.360:13): arch=c000003e syscall=59 success=no exit=-13 a0=7fd1ef909e0f a1=7fffa884e9b0 a2=7fffa88511c0 a3=7fffa88507d0 items=0 ppid=1438 pid=1440 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.364:14): avc: denied { write } for pid=1440 comm="sshdfilter" path="pipe:[11043]" dev=pipefs ino=11043 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802888.364:14): arch=c000003e syscall=1 success=yes exit=128 a0=a a1=7fffa8850a0c a2=4 a3=7fffa8850790 items=0 ppid=1438 pid=1440 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.367:15): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11043]" dev=pipefs ino=11043 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802888.367:15): arch=c000003e syscall=0 success=yes exit=128 a0=9 a1=7fffa8850ccc a2=4 a3=b73830 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.367:16): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11042]" dev=pipefs ino=11042 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802888.367:16): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7fffa8850a20 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.367:17): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11042]" dev=pipefs ino=11042 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802888.367:17): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=eb1168 a2=1000 a3=0 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.375:18): avc: denied { read } for pid=1441 comm="sshdfilter" name="sh" dev=dm-0 ino=10258 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1259802888.375:18): arch=c000003e syscall=59 success=no exit=-13 a0=7fd1ef909e0f a1=7fffa884e9b0 a2=7fffa88511c0 a3=7fffa88507d0 items=0 ppid=1438 pid=1441 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.375:19): avc: denied { write } for pid=1441 comm="sshdfilter" path="pipe:[11045]" dev=pipefs ino=11045 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802888.375:19): arch=c000003e syscall=1 success=yes exit=128 a0=a a1=7fffa8850a0c a2=4 a3=8 items=0 ppid=1438 pid=1441 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.378:20): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11045]" dev=pipefs ino=11045 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802888.378:20): arch=c000003e syscall=0 success=yes exit=128 a0=9 a1=7fffa8850ccc a2=4 a3=7fd1ef2e39d0 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.378:21): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11044]" dev=pipefs ino=11044 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802888.378:21): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7fffa8850a20 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.378:22): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11044]" dev=pipefs ino=11044 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802888.378:22): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=eb2878 a2=1000 a3=0 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.379:23): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11046]" dev=pipefs ino=11046 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802888.379:23): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.379:24): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11046]" dev=pipefs ino=11046 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802888.379:24): arch=c000003e syscall=16 success=yes exit=128 a0=8 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.384:25): avc: denied { ioctl } for pid=1442 comm="sshdfilter" path="pipe:[11046]" dev=pipefs ino=11046 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802888.384:25): arch=c000003e syscall=16 success=yes exit=128 a0=4 a1=5401 a2=7fffa8850ba0 a3=60 items=0 ppid=1438 pid=1442 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802888.384:26): avc: denied { getattr } for pid=1442 comm="sshdfilter" path="pipe:[11046]" dev=pipefs ino=11046 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802888.384:26): arch=c000003e syscall=5 success=yes exit=128 a0=4 a1=b730a0 a2=b730a0 a3=0 items=0 ppid=1438 pid=1442 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802889.381:27): avc: denied { read } for pid=1494 comm="sshdfilter" name="iptables" dev=dm-0 ino=11793 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1259802889.381:27): arch=c000003e syscall=59 success=no exit=-13 a0=7fffa8850a88 a1=eb31c8 a2=7fffa88511c0 a3=7fffa88508d0 items=0 ppid=1438 pid=1494 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802889.382:28): avc: denied { write } for pid=1494 comm="sshdfilter" path="pipe:[11397]" dev=pipefs ino=11397 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802889.382:28): arch=c000003e syscall=1 success=yes exit=128 a0=9 a1=7fffa8850b0c a2=4 a3=8 items=0 ppid=1438 pid=1494 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802889.385:29): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11397]" dev=pipefs ino=11397 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802889.385:29): arch=c000003e syscall=0 success=yes exit=128 a0=8 a1=7fffa8850f18 a2=4 a3=8 items=0 ppid=1 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802889.388:30): avc: denied { write } for pid=1438 comm="sshdfilter" path="pipe:[11021]" dev=pipefs ino=11021 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802889.388:30): arch=c000003e syscall=1 success=yes exit=128 a0=4 a1=eb3248 a2=9 a3=0 items=0 ppid=1 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259802889.390:31): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11046]" dev=pipefs ino=11046 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259802889.390:31): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=eb3568 a2=400 a3=b73010 items=0 ppid=1 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.790:43): avc: denied { ioctl } for pid=2329 comm="sshdfilter" path="pipe:[24498]" dev=pipefs ino=24498 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803042.790:43): arch=c000003e syscall=16 success=yes exit=4294967424 a0=3 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2323 pid=2329 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.795:44): avc: denied { ioctl } for pid=2329 comm="sshdfilter" path="pipe:[24498]" dev=pipefs ino=24498 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803042.795:44): arch=c000003e syscall=16 success=yes exit=4294967424 a0=4 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2323 pid=2329 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.798:45): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24509]" dev=pipefs ino=24509 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=AVC msg=audit(1259803042.801:46): avc: denied { read } for pid=2329 comm="sshdfilter" path="pipe:[24498]" dev=pipefs ino=24498 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803042.801:46): arch=c000003e syscall=0 success=yes exit=128 a0=3 a1=104fb28 a2=1000 a3=0 items=0 ppid=2323 pid=2329 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=SYSCALL msg=audit(1259803042.798:45): arch=c000003e syscall=16 success=yes exit=4294967424 a0=5 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.804:47): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24509]" dev=pipefs ino=24509 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803042.804:47): arch=c000003e syscall=16 success=yes exit=4294967424 a0=6 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.806:48): avc: denied { read } for pid=2333 comm="sshdfilter" path="pipe:[24509]" dev=pipefs ino=24509 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=AVC msg=audit(1259803042.812:49): avc: denied { read } for pid=2334 comm="sshdfilter" name="sh" dev=dm-0 ino=10258 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1259803042.806:48): arch=c000003e syscall=0 success=yes exit=4294967424 a0=5 a1=1050268 a2=1000 a3=0 items=0 ppid=2332 pid=2333 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.816:50): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24516]" dev=pipefs ino=24516 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803042.812:49): arch=c000003e syscall=59 success=no exit=-13 a0=7fceba680e0f a1=7ffffc391b70 a2=7ffffc394380 a3=7ffffc393990 items=0 ppid=2332 pid=2334 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.816:51): avc: denied { write } for pid=2334 comm="sshdfilter" path="pipe:[24516]" dev=pipefs ino=24516 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803042.816:51): arch=c000003e syscall=1 success=yes exit=128 a0=a a1=7ffffc393bcc a2=4 a3=7ffffc393950 items=0 ppid=2332 pid=2334 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=SYSCALL msg=audit(1259803042.816:50): arch=c000003e syscall=0 success=yes exit=128 a0=9 a1=7ffffc393e8c a2=4 a3=d13830 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.818:52): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24515]" dev=pipefs ino=24515 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803042.818:52): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7ffffc393be0 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.818:53): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24515]" dev=pipefs ino=24515 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803042.818:53): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=10504b8 a2=1000 a3=0 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.823:54): avc: denied { read } for pid=2335 comm="sshdfilter" name="sh" dev=dm-0 ino=10258 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1259803042.823:54): arch=c000003e syscall=59 success=no exit=-13 a0=7fceba680e0f a1=7ffffc391b70 a2=7ffffc394380 a3=7ffffc393990 items=0 ppid=2332 pid=2335 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.823:55): avc: denied { write } for pid=2335 comm="sshdfilter" path="pipe:[24518]" dev=pipefs ino=24518 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803042.823:55): arch=c000003e syscall=1 success=yes exit=128 a0=a a1=7ffffc393bcc a2=4 a3=8 items=0 ppid=2332 pid=2335 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.828:56): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24518]" dev=pipefs ino=24518 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803042.828:56): arch=c000003e syscall=0 success=yes exit=128 a0=9 a1=7ffffc393e8c a2=4 a3=7fceba05a9d0 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.828:57): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24517]" dev=pipefs ino=24517 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803042.828:57): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7ffffc393be0 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.828:58): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24517]" dev=pipefs ino=24517 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803042.828:58): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=1051cc8 a2=1000 a3=0 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.833:59): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24519]" dev=pipefs ino=24519 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803042.833:59): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.833:60): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24519]" dev=pipefs ino=24519 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803042.833:60): arch=c000003e syscall=16 success=yes exit=128 a0=8 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.834:61): avc: denied { ioctl } for pid=2336 comm="sshdfilter" path="pipe:[24519]" dev=pipefs ino=24519 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803042.834:61): arch=c000003e syscall=16 success=yes exit=128 a0=4 a1=5401 a2=7ffffc393d60 a3=60 items=0 ppid=2332 pid=2336 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803042.836:62): avc: denied { getattr } for pid=2336 comm="sshdfilter" path="pipe:[24519]" dev=pipefs ino=24519 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803042.836:62): arch=c000003e syscall=5 success=yes exit=128 a0=4 a1=d130a0 a2=d130a0 a3=0 items=0 ppid=2332 pid=2336 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803043.839:63): avc: denied { read } for pid=2338 comm="sshdfilter" name="iptables" dev=dm-0 ino=11793 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1259803043.839:63): arch=c000003e syscall=59 success=no exit=-13 a0=7ffffc393c48 a1=1052638 a2=7ffffc394380 a3=7ffffc393a90 items=0 ppid=2332 pid=2338 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803043.840:64): avc: denied { write } for pid=2338 comm="sshdfilter" path="pipe:[24549]" dev=pipefs ino=24549 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803043.840:64): arch=c000003e syscall=1 success=yes exit=128 a0=9 a1=7ffffc393ccc a2=4 a3=8 items=0 ppid=2332 pid=2338 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803043.844:65): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24549]" dev=pipefs ino=24549 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803043.844:65): arch=c000003e syscall=0 success=yes exit=128 a0=8 a1=7ffffc3940d8 a2=4 a3=8 items=0 ppid=1 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803043.845:66): avc: denied { write } for pid=2332 comm="sshdfilter" path="pipe:[24498]" dev=pipefs ino=24498 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803043.845:66): arch=c000003e syscall=1 success=yes exit=128 a0=4 a1=10526b8 a2=9 a3=0 items=0 ppid=1 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803043.849:67): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24519]" dev=pipefs ino=24519 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1259803043.849:67): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=10529d8 a2=400 a3=d13010 items=0 ppid=1 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1259803128.077:69): avc: denied { execute } for pid=2422 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259803128.077:69): arch=c000003e syscall=59 success=no exit=-13 a0=7fff14469168 a1=1c20208 a2=7fff144698a0 a3=7fff14468fb0 items=0 ppid=2413 pid=2422 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259806154.170:82): avc: denied { execute } for pid=2653 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259806154.170:82): arch=c000003e syscall=59 success=no exit=-13 a0=7fff14469168 a1=1c267e8 a2=7fff144698a0 a3=7fff14468fb0 items=0 ppid=2413 pid=2653 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259812687.066:113): avc: denied { read open } for pid=3074 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259812687.066:113): arch=c000003e syscall=59 success=no exit=-13 a0=7fff14469168 a1=1c26a88 a2=7fff144698a0 a3=7fff14468fb0 items=0 ppid=2413 pid=3074 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259816690.197:196): avc: denied { read open } for pid=3631 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259816690.197:196): arch=c000003e syscall=59 success=no exit=-13 a0=7fff15c5a888 a1=24095a8 a2=7fff15c5afc0 a3=7fff15c5a6d0 items=0 ppid=3622 pid=3631 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=9 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259819529.773:214): avc: denied { read open } for pid=3827 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259819529.773:214): arch=c000003e syscall=59 success=no exit=-13 a0=7fff15c5a888 a1=2410198 a2=7fff15c5afc0 a3=7fff15c5a6d0 items=0 ppid=3622 pid=3827 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=9 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259899887.509:471): avc: denied { read open } for pid=11794 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259899887.509:471): arch=c000003e syscall=59 success=no exit=-13 a0=7fff15c5a888 a1=2410198 a2=7fff15c5afc0 a3=7fff15c5a6d0 items=0 ppid=3622 pid=11794 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=9 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259899890.409:475): avc: denied { read open } for pid=11799 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259899890.409:475): arch=c000003e syscall=59 success=no exit=-13 a0=7fff15c5a888 a1=2410548 a2=7fff15c5afc0 a3=7fff15c5a6d0 items=0 ppid=3622 pid=11799 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=9 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1259899950.600:483): avc: denied { read open } for pid=11860 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1259899950.600:483): arch=c000003e syscall=59 success=no exit=-13 a0=7fff9722f198 a1=f6e208 a2=7fff9722f8d0 a3=7fff9722efe0 items=0 ppid=11851 pid=11860 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=44 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1260146847.427:1066): avc: denied { read open } for pid=28420 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1260146847.427:1066): arch=c000003e syscall=59 success=no exit=-13 a0=7fff9722f198 a1=f71c88 a2=7fff9722f8d0 a3=7fff9722efe0 items=0 ppid=11851 pid=28420 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=44 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1260146850.722:1070): avc: denied { read open } for pid=28428 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1260146850.722:1070): arch=c000003e syscall=59 success=no exit=-13 a0=7fff9722f198 a1=f72a28 a2=7fff9722f8d0 a3=7fff9722efe0 items=0 ppid=11851 pid=28428 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=44 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1260500225.789:25455): avc: denied { read open } for pid=21350 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1260500225.789:25455): arch=c000003e syscall=59 success=no exit=-13 a0=7fff032b96b8 a1=bdbd18 a2=7fff032b9df0 a3=7fff032b9500 items=0 ppid=1441 pid=21350 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1260500228.740:25459): avc: denied { read open } for pid=21355 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1260500228.740:25459): arch=c000003e syscall=59 success=no exit=-13 a0=7fff032b96b8 a1=bddc38 a2=7fff032b9df0 a3=7fff032b9500 items=0 ppid=1441 pid=21355 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1260500358.675:25470): avc: denied { getattr } for pid=1441 comm="sshdfilter" path="/var/run/sshdfilter.pid.SSHD" dev=dm-0 ino=10948 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file type=SYSCALL msg=audit(1260500358.675:25470): arch=c000003e syscall=6 success=no exit=-13 a0=bd5dd8 a1=8980a0 a2=8980a0 a3=7fff032b9880 items=0 ppid=1 pid=1441 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1260809448.592:28614): avc: denied { execute_no_trans } for pid=23422 comm="sshdfilter" path="/sbin/iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file type=SYSCALL msg=audit(1260809448.592:28614): arch=c000003e syscall=59 success=no exit=-13 a0=7fffc0880288 a1=e0c508 a2=7fffc08809c0 a3=7fffc08800d0 items=0 ppid=1432 pid=23422 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > >=20 > >=20 > > Moray. > > "To err is human. To purr, feline" > >=20 > >=20 > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > --uAKRQypu60I7Lcqm > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAksdZWwACgkQMlxVo39jgT/olgCgwo9wvxeAyJG/gm4dEYHBIpGf > TNEAn2bFoQZeg8+gaYPIDuB0wxuu6N8F > =tNuu > -----END PGP SIGNATURE----- > > --uAKRQypu60I7Lcqm-- > > > --===============0725889959== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > --===============0725889959==-- > From serue at us.ibm.com Mon Dec 14 18:32:01 2009 From: serue at us.ibm.com (Serge E. Hallyn) Date: Mon, 14 Dec 2009 12:32:01 -0600 Subject: The SELinux Documentation Project In-Reply-To: <20091214181207.GA2646@localhost.localdomain> References: <4AC1130D.8000601@manicmethod.com> <4B103712.2050709@manicmethod.com> <4B1114E9.7060806@gmail.com> <4B1175BA.1060604@manicmethod.com> <20091214174915.GA14651@us.ibm.com> <20091214181207.GA2646@localhost.localdomain> Message-ID: <20091214183201.GA17188@us.ibm.com> Quoting Dominick Grift (domg472 at gmail.com): > On Mon, Dec 14, 2009 at 11:49:15AM -0600, Serge E. Hallyn wrote: > > Quoting Joshua Brindle (method at manicmethod.com): > > > Dominick Grift wrote: > > > >On 11/27/2009 09:31 PM, Joshua Brindle wrote: > > > >>Joshua Brindle wrote: > > > >>>As we discussed at Linux Plumbers Conference during the 'Making SELinux > > > >>>Easier to Use" talk we have some document deficiencies in the SELinux > > > >>>project. > > > >>> > > > >> > > > >> > > > >>We have gotten some good contributions to the documentation project over > > > >>the last couple months but there is always more to do. I've updated the > > > >>Documentation TODO at: > > > >> > > > >> > > > >> > > > >>with some docs we'd like written and some guidance on what the format > > > >>should be. Use cases would be particularly appreciated. > > > >> > > > >>If you haven't gone to the documentation wiki lately take a look at > > > >> > > > >> > > > >> > > > >>and see what's been added. > > > >> > > > >>Thanks for the help of the contributors and hopefully this effort will > > > >>go a long way toward gaining users and keeping SELinux enabled. > > > >> > > > >>-- > > > >>fedora-selinux-list mailing list > > > >>fedora-selinux-list at redhat.com > > > >>https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > > >Attached is a concept i wrote today about Locking down webapps with CGI. > > > >This was a topic in the todo list. > > > > > > > >Would be nice if someone could proof-read this and when > > > >modified/accepted publish it. > > > > > > It's a wiki :) Just put it up there and others can make > > > > How are we to create an account to edit a page? The 'Log in/Create > > Account' page doesn't seem to let me create an account? > > > > I'd like to add the recipe > > > > useradd xa > > semanage user -a -R user_r xa > > semanage login -a -s xa xa > > You would probably also need: > > cd /etc/selinux/targeted/contexts/users; cp user_u xa; > > To make that work. Hmm - I didn't think in f10 or f11 I needed to, but good to know, thanks! > Easier would probably be: useradd -Z user_u xa Excellent, didn't know about it and I like it :) > or > > useradd xa > semanage login -m -s user_u -r s0-s0 xa I don't have a fedora system handy at the moment - is the help documentation in semanage now context-sensitive (so 'semanage login help' and 'semanage user help' give different, briefer, more meaningful help)? > You should send an e-mail to james morris. He maintains the site and will add a login if you ask him. > > > > > to lock user xa into its own selinux context to the recipes page. > > If someone else is willing to post it, all the better. > > > > > modifications. There are actually a couple people who are decent at > > > copy editing that have done some work on the wiki so if we get > > > technical content up there they can do what they do to clean it up. > > > > thanks, > > -serge thanks, -serge From James.Cernak at ngc.com Mon Dec 14 19:29:38 2009 From: James.Cernak at ngc.com (Cernak, James E (IS)) Date: Mon, 14 Dec 2009 13:29:38 -0600 Subject: how to restrict a SOCK_RAW by interface Message-ID: <1309562CC0F060478581A2D7331F90AC5AD11C@XMBTX122.northgrum.com> Hello, I am trying to restrict an application to using only some interfaces on the system. I have defined a new type and assigned the interface on my RHEL5.4-x64 system to the new type with semanage. The system indicates that the interface is now configured. # semanage interface -l SELinux Interface Context eth1 system_u:object_r:iface_test_t:s0 This does restrict applications like tcpdump or wireshark from listing the interface that was configured. # tcpdump -D 1.peth0 2.virbr0 3.vif0.0 4.eth0 5.xenbr0 6.eth2 7.eth3 8.any (Pseudo-device that captures on all interfaces) 9.lo My problem comes that my application can still open eth1 and read and write packets to this interface. The application is opening a socket as SOCK_RAW then binding with a struct sockaddr_LL that has the ssll_ifindex field configured with the index of ETH1. How do I write a selinux policy to restrict this application from using some interfaces. Thanks James Cernak -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at tycho.nsa.gov Mon Dec 14 19:49:52 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 14 Dec 2009 14:49:52 -0500 Subject: how to restrict a SOCK_RAW by interface In-Reply-To: <1309562CC0F060478581A2D7331F90AC5AD11C@XMBTX122.northgrum.com> References: <1309562CC0F060478581A2D7331F90AC5AD11C@XMBTX122.northgrum.com> Message-ID: <1260820192.4126.13.camel@moss-pluto.epoch.ncsc.mil> On Mon, 2009-12-14 at 13:29 -0600, Cernak, James E (IS) wrote: > Hello, > > I am trying to restrict an application to using only some interfaces > on the system. I have defined a new type and assigned the interface on > my RHEL5.4-x64 system to the new type with semanage. The system > indicates that the interface is now configured. > # semanage interface -l > SELinux Interface Context > > eth1 system_u:object_r:iface_test_t:s0 > This does restrict applications like tcpdump or wireshark from listing > the interface that was configured. > # tcpdump -D > 1.peth0 > 2.virbr0 > 3.vif0.0 > 4.eth0 > 5.xenbr0 > 6.eth2 > 7.eth3 > 8.any (Pseudo-device that captures on all interfaces) > 9.lo > > My problem comes that my application can still open eth1 and read and > write packets to this interface. > The application is opening a socket as SOCK_RAW then binding with a > struct sockaddr_LL that has the ssll_ifindex field configured with the > index of ETH1. > How do I write a selinux policy to restrict this application from > using some interfaces. > In RHEL5 (Linux 2.6.18), you might need to enable compat_net (echo 1 > /selinux/compat_net or boot with selinux_compat_net=1 on the kernel command line). -- Stephen Smalley National Security Agency From domg472 at gmail.com Mon Dec 14 20:09:42 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 14 Dec 2009 21:09:42 +0100 Subject: The SELinux Documentation Project In-Reply-To: <20091214183201.GA17188@us.ibm.com> References: <4AC1130D.8000601@manicmethod.com> <4B103712.2050709@manicmethod.com> <4B1114E9.7060806@gmail.com> <4B1175BA.1060604@manicmethod.com> <20091214174915.GA14651@us.ibm.com> <20091214181207.GA2646@localhost.localdomain> <20091214183201.GA17188@us.ibm.com> Message-ID: <20091214200941.GB2646@localhost.localdomain> On Mon, Dec 14, 2009 at 12:32:01PM -0600, Serge E. Hallyn wrote: > Quoting Dominick Grift (domg472 at gmail.com): > > On Mon, Dec 14, 2009 at 11:49:15AM -0600, Serge E. Hallyn wrote: > > > Quoting Joshua Brindle (method at manicmethod.com): > > > > Dominick Grift wrote: > > > > >On 11/27/2009 09:31 PM, Joshua Brindle wrote: > > > > >>Joshua Brindle wrote: > > > > >>>As we discussed at Linux Plumbers Conference during the 'Making SELinux > > > > >>>Easier to Use" talk we have some document deficiencies in the SELinux > > > > >>>project. > > > > >>> > > > > >> > > > > >> > > > > >>We have gotten some good contributions to the documentation project over > > > > >>the last couple months but there is always more to do. I've updated the > > > > >>Documentation TODO at: > > > > >> > > > > >> > > > > >> > > > > >>with some docs we'd like written and some guidance on what the format > > > > >>should be. Use cases would be particularly appreciated. > > > > >> > > > > >>If you haven't gone to the documentation wiki lately take a look at > > > > >> > > > > >> > > > > >> > > > > >>and see what's been added. > > > > >> > > > > >>Thanks for the help of the contributors and hopefully this effort will > > > > >>go a long way toward gaining users and keeping SELinux enabled. > > > > >> > > > > >>-- > > > > >>fedora-selinux-list mailing list > > > > >>fedora-selinux-list at redhat.com > > > > >>https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > > > > >Attached is a concept i wrote today about Locking down webapps with CGI. > > > > >This was a topic in the todo list. > > > > > > > > > >Would be nice if someone could proof-read this and when > > > > >modified/accepted publish it. > > > > > > > > It's a wiki :) Just put it up there and others can make > > > > > > How are we to create an account to edit a page? The 'Log in/Create > > > Account' page doesn't seem to let me create an account? > > > > > > I'd like to add the recipe > > > > > > useradd xa > > > semanage user -a -R user_r xa > > > semanage login -a -s xa xa > > > > You would probably also need: > > > > cd /etc/selinux/targeted/contexts/users; cp user_u xa; > > > > To make that work. > > Hmm - I didn't think in f10 or f11 I needed to, but good to > know, thanks! > > > Easier would probably be: useradd -Z user_u xa > > Excellent, didn't know about it and I like it :) > > > or > > > > useradd xa > > semanage login -m -s user_u -r s0-s0 xa > > I don't have a fedora system handy at the moment - is the help > documentation in semanage now context-sensitive (so > 'semanage login help' and 'semanage user help' give different, > briefer, more meaningful help)? less meaningful i would say: [root at localhost etc]# semanage login help /usr/sbin/semanage: Invalid command: semanage login help [root at localhost etc]# semanage user help /usr/sbin/semanage: Invalid command: semanage user help > > > You should send an e-mail to james morris. He maintains the site and will add a login if you ask him. > > > > > > > > to lock user xa into its own selinux context to the recipes page. > > > If someone else is willing to post it, all the better. > > > > > > > modifications. There are actually a couple people who are decent at > > > > copy editing that have done some work on the wiki so if we get > > > > technical content up there they can do what they do to clean it up. > > > > > > thanks, > > > -serge > > thanks, > -serge -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Mon Dec 14 21:21:06 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 14 Dec 2009 22:21:06 +0100 Subject: Fedora 12 and unconfined_u sshdfilter In-Reply-To: <200912141825.nBEIP8WR027234@douglas.highley-recommended.com> References: <20091207202828.GA6387@localhost.localdomain> <200912141825.nBEIP8WR027234@douglas.highley-recommended.com> Message-ID: <20091214212104.GA23680@localhost.localdomain> On Mon, Dec 14, 2009 at 10:25:08AM -0800, David Highley wrote: > "Dominick Grift wrote:" > > > > > > --===============0725889959== > > Content-Type: multipart/signed; micalg=pgp-sha1; > > protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" > > Content-Disposition: inline > > > > > > --uAKRQypu60I7Lcqm > > Content-Type: text/plain; charset=utf-8 > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > > > > On Mon, Dec 07, 2009 at 12:01:09PM +0000, Moray Henderson (ICT) wrote: > > > James Carter wrote: > > > >Dan's example used Refpolicy interfaces. Interfaces are very useful and > > > >provide a better layer of abstraction, but they are just m4 macros, > > > >which have always been used in SELinux policy. > > > > > > > >Interfaces should be used as much as possible, but it is not true that > > > >you can't mix the old and new ways. > > >=20 > > > Mixing the plain rules and the m4 macros didn't work when I tried it - bu= > > t perhaps I just wasn=E2=80=99t writing it right. Is there a Refpolicy tut= > > orial anywhere? > > > > I spend a little time today writing about the policy structure in Fedora. M= > > aybe it can help you or others: > > > > http://82.197.205.60/~dgrift/stuff/Managing_a_SELinux_environment_with_Fedo= > > ra_12.pdf > > > Still have not mastered this one yet. Here is the policy file created by > grep of /var/log/audit/audit.log file piped to audit2allow: > > module mysshdfilter 1.0; > > require { > type var_run_t; > type iptables_exec_t; > type bin_t; > type sshd_t; > type iptables_t; > class lnk_file read; > class file { read getattr open execute execute_no_trans }; > class fifo_file { read write ioctl getattr }; > } > > #============= iptables_t ============== > allow iptables_t bin_t:lnk_file read; > allow iptables_t self:fifo_file { read write ioctl getattr }; echo "policy_module(newiptables, 1.0.0)" > newuiptables.te echo "optional_policy(\`" >> newiptables.te echo "gen_require(\'" >> newiptables.te echo "type iptables_t;" >> newiptables.te echo "')" >> newiptables.te echo "corecmd_read_bin_symlinks(iptables_t)" >> newiptables.te echo "allow iptables_t self:fifo_file rw_fifo_file_perms;" >> newiptables.te echo "')" >> newiptables.te make -f /usr/share/selinux/devel/Makefile newiptables.pp sudo semodule -i newiptables.pp > > #============= sshd_t ============== > allow sshd_t iptables_exec_t:file { read execute open execute_no_trans }; echo "policy_module(newsshd, 1.0.0)" > newsshd.te echo "optional_policy(\`" >> newsshd.te echo "gen_require(\`" >> newsshd.te echo "type sshd_t;" >> newsshd.te echo "')" >> newsshd.te echo "iptables_domtrans(sshd_t)" >> newsshd.te echo "')" >> newsshd.te make -f /usr/share/selinux/devel/Makefile newsshd.pp sudo semodule -i newsshd.pp > allow sshd_t var_run_t:file getattr; This one is a bit more complicated because i dont know for sure what created it (in what context runs sshdfilter?) > > > The audit log entries are: > type=AVC msg=audit(1259642932.902:7): avc: denied { execute } for pid=1411 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259642932.902:7): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1562e28 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=1411 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259644707.700:73): avc: denied { execute } for pid=1948 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259644707.700:73): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=15694c8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=1948 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259650605.247:84): avc: denied { execute } for pid=2248 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259650605.247:84): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1567828 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=2248 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259661894.420:113): avc: denied { execute } for pid=2815 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259661894.420:113): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1566e28 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=2815 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259667665.966:123): avc: denied { execute } for pid=3724 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259667665.966:123): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=15699d8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=3724 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259671660.048:131): avc: denied { execute } for pid=3920 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259671660.048:131): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1565778 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=3920 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259673411.553:758): avc: denied { execute } for pid=4558 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259673411.553:758): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1569af8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=4558 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259679153.568:1267): avc: denied { execute } for pid=5170 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259679153.568:1267): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1566a68 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=5170 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259682588.736:1315): avc: denied { execute } for pid=5540 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259682588.736:1315): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1565778 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=5540 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259684861.197:1344): avc: denied { execute } for pid=5745 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259684861.197:1344): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a478 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=5745 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259690558.951:1388): avc: denied { execute } for pid=6161 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259690558.951:1388): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=15667a8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=6161 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259702647.573:1433): avc: denied { execute } for pid=6829 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259702647.573:1433): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156b4d8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=6829 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259708100.231:1441): avc: denied { execute } for pid=7085 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259708100.231:1441): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a0b8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=7085 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259708922.953:1450): avc: denied { execute } for pid=7153 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259708922.953:1450): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a6a8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=7153 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259713257.803:1545): avc: denied { execute } for pid=7492 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259713257.803:1545): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a4a8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=7492 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259721513.893:1732): avc: denied { execute } for pid=8097 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259721513.893:1732): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a5d8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=8097 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259730724.196:1790): avc: denied { execute } for pid=8689 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259730724.196:1790): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1569718 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=8689 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259730728.123:1793): avc: denied { execute } for pid=8699 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259730728.123:1793): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1566778 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=8699 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259747840.157:1835): avc: denied { execute } for pid=9575 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259747840.157:1835): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156ba78 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=9575 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259760819.408:1863): avc: denied { execute } for pid=10840 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259760819.408:1863): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a4a8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=10840 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259762576.442:1887): avc: denied { execute } for pid=11067 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259762576.442:1887): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d4d5a8 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=11067 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259767362.673:1896): avc: denied { execute } for pid=11318 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259767362.673:1896): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d54088 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=11318 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259773905.214:1967): avc: denied { execute } for pid=11922 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259773905.214:1967): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d54868 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=11922 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259780362.196:1977): avc: denied { execute } for pid=12215 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259780362.196:1977): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d50af8 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=12215 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259780393.314:1979): avc: denied { execute } for pid=12219 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259780393.314:1979): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d50af8 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=12219 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259785085.323:2012): avc: denied { execute } for pid=12568 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259785085.323:2012): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d521b8 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=12568 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259786872.756:2015): avc: denied { execute } for pid=12645 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259786872.756:2015): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d53568 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=12645 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259795695.936:2052): avc: denied { execute } for pid=13127 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259795695.936:2052): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d52e38 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=13127 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259802506.518:3031): avc: denied { getattr } for pid=11058 comm="sshdfilter" path="/var/run/sshdfilter.pid.SSHD" dev=dm-0 ino=12538 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file > type=SYSCALL msg=audit(1259802506.518:3031): arch=c000003e syscall=6 success=no exit=-13 a0=d4a128 a1=a0d0a0 a2=a0d0a0 a3=7fffb9164bb0 items=0 ppid=1 pid=11058 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259802888.332:7): avc: denied { ioctl } for pid=1435 comm="sshdfilter" path="pipe:[11021]" dev=pipefs ino=11021 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.332:7): arch=c000003e syscall=16 success=yes exit=128 a0=3 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1431 pid=1435 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.340:8): avc: denied { ioctl } for pid=1435 comm="sshdfilter" path="pipe:[11021]" dev=pipefs ino=11021 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.340:8): arch=c000003e syscall=16 success=yes exit=128 a0=4 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1431 pid=1435 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.342:9): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11031]" dev=pipefs ino=11031 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=AVC msg=audit(1259802888.343:10): avc: denied { read } for pid=1435 comm="sshdfilter" path="pipe:[11021]" dev=pipefs ino=11021 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.343:10): arch=c000003e syscall=0 success=yes exit=128 a0=3 a1=eb06e8 a2=1000 a3=0 items=0 ppid=1431 pid=1435 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=SYSCALL msg=audit(1259802888.342:9): arch=c000003e syscall=16 success=yes exit=128 a0=5 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.347:11): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11031]" dev=pipefs ino=11031 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.347:11): arch=c000003e syscall=16 success=yes exit=128 a0=6 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.350:12): avc: denied { read } for pid=1439 comm="sshdfilter" path="pipe:[11031]" dev=pipefs ino=11031 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.350:12): arch=c000003e syscall=0 success=yes exit=128 a0=5 a1=eb0f18 a2=1000 a3=0 items=0 ppid=1438 pid=1439 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.360:13): avc: denied { read } for pid=1440 comm="sshdfilter" name="sh" dev=dm-0 ino=10258 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file > type=SYSCALL msg=audit(1259802888.360:13): arch=c000003e syscall=59 success=no exit=-13 a0=7fd1ef909e0f a1=7fffa884e9b0 a2=7fffa88511c0 a3=7fffa88507d0 items=0 ppid=1438 pid=1440 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.364:14): avc: denied { write } for pid=1440 comm="sshdfilter" path="pipe:[11043]" dev=pipefs ino=11043 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.364:14): arch=c000003e syscall=1 success=yes exit=128 a0=a a1=7fffa8850a0c a2=4 a3=7fffa8850790 items=0 ppid=1438 pid=1440 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.367:15): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11043]" dev=pipefs ino=11043 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.367:15): arch=c000003e syscall=0 success=yes exit=128 a0=9 a1=7fffa8850ccc a2=4 a3=b73830 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.367:16): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11042]" dev=pipefs ino=11042 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.367:16): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7fffa8850a20 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.367:17): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11042]" dev=pipefs ino=11042 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.367:17): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=eb1168 a2=1000 a3=0 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.375:18): avc: denied { read } for pid=1441 comm="sshdfilter" name="sh" dev=dm-0 ino=10258 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file > type=SYSCALL msg=audit(1259802888.375:18): arch=c000003e syscall=59 success=no exit=-13 a0=7fd1ef909e0f a1=7fffa884e9b0 a2=7fffa88511c0 a3=7fffa88507d0 items=0 ppid=1438 pid=1441 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.375:19): avc: denied { write } for pid=1441 comm="sshdfilter" path="pipe:[11045]" dev=pipefs ino=11045 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.375:19): arch=c000003e syscall=1 success=yes exit=128 a0=a a1=7fffa8850a0c a2=4 a3=8 items=0 ppid=1438 pid=1441 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.378:20): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11045]" dev=pipefs ino=11045 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.378:20): arch=c000003e syscall=0 success=yes exit=128 a0=9 a1=7fffa8850ccc a2=4 a3=7fd1ef2e39d0 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.378:21): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11044]" dev=pipefs ino=11044 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.378:21): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7fffa8850a20 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.378:22): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11044]" dev=pipefs ino=11044 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.378:22): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=eb2878 a2=1000 a3=0 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.379:23): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11046]" dev=pipefs ino=11046 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.379:23): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.379:24): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11046]" dev=pipefs ino=11046 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.379:24): arch=c000003e syscall=16 success=yes exit=128 a0=8 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.384:25): avc: denied { ioctl } for pid=1442 comm="sshdfilter" path="pipe:[11046]" dev=pipefs ino=11046 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.384:25): arch=c000003e syscall=16 success=yes exit=128 a0=4 a1=5401 a2=7fffa8850ba0 a3=60 items=0 ppid=1438 pid=1442 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.384:26): avc: denied { getattr } for pid=1442 comm="sshdfilter" path="pipe:[11046]" dev=pipefs ino=11046 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.384:26): arch=c000003e syscall=5 success=yes exit=128 a0=4 a1=b730a0 a2=b730a0 a3=0 items=0 ppid=1438 pid=1442 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802889.381:27): avc: denied { read } for pid=1494 comm="sshdfilter" name="iptables" dev=dm-0 ino=11793 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file > type=SYSCALL msg=audit(1259802889.381:27): arch=c000003e syscall=59 success=no exit=-13 a0=7fffa8850a88 a1=eb31c8 a2=7fffa88511c0 a3=7fffa88508d0 items=0 ppid=1438 pid=1494 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802889.382:28): avc: denied { write } for pid=1494 comm="sshdfilter" path="pipe:[11397]" dev=pipefs ino=11397 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802889.382:28): arch=c000003e syscall=1 success=yes exit=128 a0=9 a1=7fffa8850b0c a2=4 a3=8 items=0 ppid=1438 pid=1494 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802889.385:29): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11397]" dev=pipefs ino=11397 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802889.385:29): arch=c000003e syscall=0 success=yes exit=128 a0=8 a1=7fffa8850f18 a2=4 a3=8 items=0 ppid=1 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802889.388:30): avc: denied { write } for pid=1438 comm="sshdfilter" path="pipe:[11021]" dev=pipefs ino=11021 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802889.388:30): arch=c000003e syscall=1 success=yes exit=128 a0=4 a1=eb3248 a2=9 a3=0 items=0 ppid=1 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802889.390:31): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11046]" dev=pipefs ino=11046 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802889.390:31): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=eb3568 a2=400 a3=b73010 items=0 ppid=1 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.790:43): avc: denied { ioctl } for pid=2329 comm="sshdfilter" path="pipe:[24498]" dev=pipefs ino=24498 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.790:43): arch=c000003e syscall=16 success=yes exit=4294967424 a0=3 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2323 pid=2329 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.795:44): avc: denied { ioctl } for pid=2329 comm="sshdfilter" path="pipe:[24498]" dev=pipefs ino=24498 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.795:44): arch=c000003e syscall=16 success=yes exit=4294967424 a0=4 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2323 pid=2329 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.798:45): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24509]" dev=pipefs ino=24509 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=AVC msg=audit(1259803042.801:46): avc: denied { read } for pid=2329 comm="sshdfilter" path="pipe:[24498]" dev=pipefs ino=24498 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.801:46): arch=c000003e syscall=0 success=yes exit=128 a0=3 a1=104fb28 a2=1000 a3=0 items=0 ppid=2323 pid=2329 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=SYSCALL msg=audit(1259803042.798:45): arch=c000003e syscall=16 success=yes exit=4294967424 a0=5 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.804:47): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24509]" dev=pipefs ino=24509 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.804:47): arch=c000003e syscall=16 success=yes exit=4294967424 a0=6 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.806:48): avc: denied { read } for pid=2333 comm="sshdfilter" path="pipe:[24509]" dev=pipefs ino=24509 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=AVC msg=audit(1259803042.812:49): avc: denied { read } for pid=2334 comm="sshdfilter" name="sh" dev=dm-0 ino=10258 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file > type=SYSCALL msg=audit(1259803042.806:48): arch=c000003e syscall=0 success=yes exit=4294967424 a0=5 a1=1050268 a2=1000 a3=0 items=0 ppid=2332 pid=2333 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.816:50): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24516]" dev=pipefs ino=24516 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.812:49): arch=c000003e syscall=59 success=no exit=-13 a0=7fceba680e0f a1=7ffffc391b70 a2=7ffffc394380 a3=7ffffc393990 items=0 ppid=2332 pid=2334 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.816:51): avc: denied { write } for pid=2334 comm="sshdfilter" path="pipe:[24516]" dev=pipefs ino=24516 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.816:51): arch=c000003e syscall=1 success=yes exit=128 a0=a a1=7ffffc393bcc a2=4 a3=7ffffc393950 items=0 ppid=2332 pid=2334 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=SYSCALL msg=audit(1259803042.816:50): arch=c000003e syscall=0 success=yes exit=128 a0=9 a1=7ffffc393e8c a2=4 a3=d13830 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.818:52): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24515]" dev=pipefs ino=24515 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.818:52): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7ffffc393be0 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.818:53): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24515]" dev=pipefs ino=24515 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.818:53): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=10504b8 a2=1000 a3=0 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.823:54): avc: denied { read } for pid=2335 comm="sshdfilter" name="sh" dev=dm-0 ino=10258 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file > type=SYSCALL msg=audit(1259803042.823:54): arch=c000003e syscall=59 success=no exit=-13 a0=7fceba680e0f a1=7ffffc391b70 a2=7ffffc394380 a3=7ffffc393990 items=0 ppid=2332 pid=2335 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.823:55): avc: denied { write } for pid=2335 comm="sshdfilter" path="pipe:[24518]" dev=pipefs ino=24518 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.823:55): arch=c000003e syscall=1 success=yes exit=128 a0=a a1=7ffffc393bcc a2=4 a3=8 items=0 ppid=2332 pid=2335 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.828:56): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24518]" dev=pipefs ino=24518 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.828:56): arch=c000003e syscall=0 success=yes exit=128 a0=9 a1=7ffffc393e8c a2=4 a3=7fceba05a9d0 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.828:57): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24517]" dev=pipefs ino=24517 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.828:57): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7ffffc393be0 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.828:58): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24517]" dev=pipefs ino=24517 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.828:58): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=1051cc8 a2=1000 a3=0 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.833:59): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24519]" dev=pipefs ino=24519 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.833:59): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.833:60): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24519]" dev=pipefs ino=24519 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.833:60): arch=c000003e syscall=16 success=yes exit=128 a0=8 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.834:61): avc: denied { ioctl } for pid=2336 comm="sshdfilter" path="pipe:[24519]" dev=pipefs ino=24519 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.834:61): arch=c000003e syscall=16 success=yes exit=128 a0=4 a1=5401 a2=7ffffc393d60 a3=60 items=0 ppid=2332 pid=2336 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.836:62): avc: denied { getattr } for pid=2336 comm="sshdfilter" path="pipe:[24519]" dev=pipefs ino=24519 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.836:62): arch=c000003e syscall=5 success=yes exit=128 a0=4 a1=d130a0 a2=d130a0 a3=0 items=0 ppid=2332 pid=2336 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803043.839:63): avc: denied { read } for pid=2338 comm="sshdfilter" name="iptables" dev=dm-0 ino=11793 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file > type=SYSCALL msg=audit(1259803043.839:63): arch=c000003e syscall=59 success=no exit=-13 a0=7ffffc393c48 a1=1052638 a2=7ffffc394380 a3=7ffffc393a90 items=0 ppid=2332 pid=2338 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803043.840:64): avc: denied { write } for pid=2338 comm="sshdfilter" path="pipe:[24549]" dev=pipefs ino=24549 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803043.840:64): arch=c000003e syscall=1 success=yes exit=128 a0=9 a1=7ffffc393ccc a2=4 a3=8 items=0 ppid=2332 pid=2338 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803043.844:65): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24549]" dev=pipefs ino=24549 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803043.844:65): arch=c000003e syscall=0 success=yes exit=128 a0=8 a1=7ffffc3940d8 a2=4 a3=8 items=0 ppid=1 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803043.845:66): avc: denied { write } for pid=2332 comm="sshdfilter" path="pipe:[24498]" dev=pipefs ino=24498 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803043.845:66): arch=c000003e syscall=1 success=yes exit=128 a0=4 a1=10526b8 a2=9 a3=0 items=0 ppid=1 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803043.849:67): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24519]" dev=pipefs ino=24519 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803043.849:67): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=10529d8 a2=400 a3=d13010 items=0 ppid=1 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803128.077:69): avc: denied { execute } for pid=2422 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259803128.077:69): arch=c000003e syscall=59 success=no exit=-13 a0=7fff14469168 a1=1c20208 a2=7fff144698a0 a3=7fff14468fb0 items=0 ppid=2413 pid=2422 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259806154.170:82): avc: denied { execute } for pid=2653 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259806154.170:82): arch=c000003e syscall=59 success=no exit=-13 a0=7fff14469168 a1=1c267e8 a2=7fff144698a0 a3=7fff14468fb0 items=0 ppid=2413 pid=2653 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259812687.066:113): avc: denied { read open } for pid=3074 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259812687.066:113): arch=c000003e syscall=59 success=no exit=-13 a0=7fff14469168 a1=1c26a88 a2=7fff144698a0 a3=7fff14468fb0 items=0 ppid=2413 pid=3074 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259816690.197:196): avc: denied { read open } for pid=3631 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259816690.197:196): arch=c000003e syscall=59 success=no exit=-13 a0=7fff15c5a888 a1=24095a8 a2=7fff15c5afc0 a3=7fff15c5a6d0 items=0 ppid=3622 pid=3631 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=9 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259819529.773:214): avc: denied { read open } for pid=3827 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259819529.773:214): arch=c000003e syscall=59 success=no exit=-13 a0=7fff15c5a888 a1=2410198 a2=7fff15c5afc0 a3=7fff15c5a6d0 items=0 ppid=3622 pid=3827 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=9 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259899887.509:471): avc: denied { read open } for pid=11794 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259899887.509:471): arch=c000003e syscall=59 success=no exit=-13 a0=7fff15c5a888 a1=2410198 a2=7fff15c5afc0 a3=7fff15c5a6d0 items=0 ppid=3622 pid=11794 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=9 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259899890.409:475): avc: denied { read open } for pid=11799 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259899890.409:475): arch=c000003e syscall=59 success=no exit=-13 a0=7fff15c5a888 a1=2410548 a2=7fff15c5afc0 a3=7fff15c5a6d0 items=0 ppid=3622 pid=11799 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=9 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259899950.600:483): avc: denied { read open } for pid=11860 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259899950.600:483): arch=c000003e syscall=59 success=no exit=-13 a0=7fff9722f198 a1=f6e208 a2=7fff9722f8d0 a3=7fff9722efe0 items=0 ppid=11851 pid=11860 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=44 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1260146847.427:1066): avc: denied { read open } for pid=28420 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1260146847.427:1066): arch=c000003e syscall=59 success=no exit=-13 a0=7fff9722f198 a1=f71c88 a2=7fff9722f8d0 a3=7fff9722efe0 items=0 ppid=11851 pid=28420 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=44 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1260146850.722:1070): avc: denied { read open } for pid=28428 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1260146850.722:1070): arch=c000003e syscall=59 success=no exit=-13 a0=7fff9722f198 a1=f72a28 a2=7fff9722f8d0 a3=7fff9722efe0 items=0 ppid=11851 pid=28428 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=44 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1260500225.789:25455): avc: denied { read open } for pid=21350 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1260500225.789:25455): arch=c000003e syscall=59 success=no exit=-13 a0=7fff032b96b8 a1=bdbd18 a2=7fff032b9df0 a3=7fff032b9500 items=0 ppid=1441 pid=21350 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1260500228.740:25459): avc: denied { read open } for pid=21355 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1260500228.740:25459): arch=c000003e syscall=59 success=no exit=-13 a0=7fff032b96b8 a1=bddc38 a2=7fff032b9df0 a3=7fff032b9500 items=0 ppid=1441 pid=21355 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1260500358.675:25470): avc: denied { getattr } for pid=1441 comm="sshdfilter" path="/var/run/sshdfilter.pid.SSHD" dev=dm-0 ino=10948 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file > type=SYSCALL msg=audit(1260500358.675:25470): arch=c000003e syscall=6 success=no exit=-13 a0=bd5dd8 a1=8980a0 a2=8980a0 a3=7fff032b9880 items=0 ppid=1 pid=1441 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1260809448.592:28614): avc: denied { execute_no_trans } for pid=23422 comm="sshdfilter" path="/sbin/iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1260809448.592:28614): arch=c000003e syscall=59 success=no exit=-13 a0=7fffc0880288 a1=e0c508 a2=7fffc08809c0 a3=7fffc08800d0 items=0 ppid=1432 pid=23422 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > > > >=20 > > >=20 > > > Moray. > > > "To err is human. To purr, feline" > > >=20 > > >=20 > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > --uAKRQypu60I7Lcqm > > Content-Type: application/pgp-signature > > Content-Disposition: inline > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.10 (GNU/Linux) > > > > iEYEARECAAYFAksdZWwACgkQMlxVo39jgT/olgCgwo9wvxeAyJG/gm4dEYHBIpGf > > TNEAn2bFoQZeg8+gaYPIDuB0wxuu6N8F > > =tNuu > > -----END PGP SIGNATURE----- > > > > --uAKRQypu60I7Lcqm-- > > > > > > --===============0725889959== > > Content-Type: text/plain; charset="us-ascii" > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > --===============0725889959==-- > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Mon Dec 14 21:35:39 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 14 Dec 2009 22:35:39 +0100 Subject: Fedora 12 and unconfined_u sshdfilter In-Reply-To: <200912141825.nBEIP8WR027234@douglas.highley-recommended.com> References: <20091207202828.GA6387@localhost.localdomain> <200912141825.nBEIP8WR027234@douglas.highley-recommended.com> Message-ID: <20091214213537.GB23680@localhost.localdomain> On Mon, Dec 14, 2009 at 10:25:08AM -0800, David Highley wrote: > "Dominick Grift wrote:" > > > > > > --===============0725889959== > > Content-Type: multipart/signed; micalg=pgp-sha1; > > protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" > > Content-Disposition: inline > > > > > > --uAKRQypu60I7Lcqm > > Content-Type: text/plain; charset=utf-8 > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > > > > On Mon, Dec 07, 2009 at 12:01:09PM +0000, Moray Henderson (ICT) wrote: > > > James Carter wrote: > > > >Dan's example used Refpolicy interfaces. Interfaces are very useful and > > > >provide a better layer of abstraction, but they are just m4 macros, > > > >which have always been used in SELinux policy. > > > > > > > >Interfaces should be used as much as possible, but it is not true that > > > >you can't mix the old and new ways. > > >=20 > > > Mixing the plain rules and the m4 macros didn't work when I tried it - bu= > > t perhaps I just wasn=E2=80=99t writing it right. Is there a Refpolicy tut= > > orial anywhere? > > > > I spend a little time today writing about the policy structure in Fedora. M= > > aybe it can help you or others: > > > > http://82.197.205.60/~dgrift/stuff/Managing_a_SELinux_environment_with_Fedo= > > ra_12.pdf > > > Still have not mastered this one yet. Here is the policy file created by > grep of /var/log/audit/audit.log file piped to audit2allow: > > module mysshdfilter 1.0; > > require { > type var_run_t; > type iptables_exec_t; > type bin_t; > type sshd_t; > type iptables_t; > class lnk_file read; > class file { read getattr open execute execute_no_trans }; > class fifo_file { read write ioctl getattr }; > } > > #============= iptables_t ============== > allow iptables_t bin_t:lnk_file read; > allow iptables_t self:fifo_file { read write ioctl getattr }; > > #============= sshd_t ============== > allow sshd_t iptables_exec_t:file { read execute open execute_no_trans }; > allow sshd_t var_run_t:file getattr; Actually i think sshdfilter init script may have created it? Does it even have an init script? > > > The audit log entries are: > type=AVC msg=audit(1259642932.902:7): avc: denied { execute } for pid=1411 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259642932.902:7): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1562e28 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=1411 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259644707.700:73): avc: denied { execute } for pid=1948 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259644707.700:73): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=15694c8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=1948 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259650605.247:84): avc: denied { execute } for pid=2248 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259650605.247:84): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1567828 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=2248 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259661894.420:113): avc: denied { execute } for pid=2815 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259661894.420:113): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1566e28 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=2815 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259667665.966:123): avc: denied { execute } for pid=3724 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259667665.966:123): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=15699d8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=3724 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259671660.048:131): avc: denied { execute } for pid=3920 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259671660.048:131): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1565778 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=3920 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259673411.553:758): avc: denied { execute } for pid=4558 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259673411.553:758): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1569af8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=4558 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259679153.568:1267): avc: denied { execute } for pid=5170 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259679153.568:1267): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1566a68 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=5170 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259682588.736:1315): avc: denied { execute } for pid=5540 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259682588.736:1315): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1565778 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=5540 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259684861.197:1344): avc: denied { execute } for pid=5745 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259684861.197:1344): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a478 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=5745 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259690558.951:1388): avc: denied { execute } for pid=6161 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259690558.951:1388): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=15667a8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=6161 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259702647.573:1433): avc: denied { execute } for pid=6829 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259702647.573:1433): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156b4d8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=6829 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259708100.231:1441): avc: denied { execute } for pid=7085 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259708100.231:1441): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a0b8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=7085 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259708922.953:1450): avc: denied { execute } for pid=7153 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259708922.953:1450): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a6a8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=7153 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259713257.803:1545): avc: denied { execute } for pid=7492 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259713257.803:1545): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a4a8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=7492 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259721513.893:1732): avc: denied { execute } for pid=8097 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259721513.893:1732): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a5d8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=8097 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259730724.196:1790): avc: denied { execute } for pid=8689 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259730724.196:1790): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1569718 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=8689 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259730728.123:1793): avc: denied { execute } for pid=8699 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259730728.123:1793): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=1566778 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=8699 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259747840.157:1835): avc: denied { execute } for pid=9575 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259747840.157:1835): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156ba78 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=9575 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259760819.408:1863): avc: denied { execute } for pid=10840 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259760819.408:1863): arch=c000003e syscall=59 success=no exit=-13 a0=7fff837b36b8 a1=156a4a8 a2=7fff837b3df0 a3=7fff837b3500 items=0 ppid=1402 pid=10840 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259762576.442:1887): avc: denied { execute } for pid=11067 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259762576.442:1887): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d4d5a8 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=11067 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259767362.673:1896): avc: denied { execute } for pid=11318 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259767362.673:1896): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d54088 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=11318 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259773905.214:1967): avc: denied { execute } for pid=11922 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259773905.214:1967): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d54868 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=11922 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259780362.196:1977): avc: denied { execute } for pid=12215 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259780362.196:1977): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d50af8 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=12215 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259780393.314:1979): avc: denied { execute } for pid=12219 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259780393.314:1979): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d50af8 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=12219 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259785085.323:2012): avc: denied { execute } for pid=12568 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259785085.323:2012): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d521b8 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=12568 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259786872.756:2015): avc: denied { execute } for pid=12645 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259786872.756:2015): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d53568 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=12645 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259795695.936:2052): avc: denied { execute } for pid=13127 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259795695.936:2052): arch=c000003e syscall=59 success=no exit=-13 a0=7fffb91649e8 a1=d52e38 a2=7fffb9165120 a3=7fffb9164830 items=0 ppid=11058 pid=13127 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259802506.518:3031): avc: denied { getattr } for pid=11058 comm="sshdfilter" path="/var/run/sshdfilter.pid.SSHD" dev=dm-0 ino=12538 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file > type=SYSCALL msg=audit(1259802506.518:3031): arch=c000003e syscall=6 success=no exit=-13 a0=d4a128 a1=a0d0a0 a2=a0d0a0 a3=7fffb9164bb0 items=0 ppid=1 pid=11058 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=47 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259802888.332:7): avc: denied { ioctl } for pid=1435 comm="sshdfilter" path="pipe:[11021]" dev=pipefs ino=11021 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.332:7): arch=c000003e syscall=16 success=yes exit=128 a0=3 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1431 pid=1435 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.340:8): avc: denied { ioctl } for pid=1435 comm="sshdfilter" path="pipe:[11021]" dev=pipefs ino=11021 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.340:8): arch=c000003e syscall=16 success=yes exit=128 a0=4 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1431 pid=1435 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.342:9): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11031]" dev=pipefs ino=11031 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=AVC msg=audit(1259802888.343:10): avc: denied { read } for pid=1435 comm="sshdfilter" path="pipe:[11021]" dev=pipefs ino=11021 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.343:10): arch=c000003e syscall=0 success=yes exit=128 a0=3 a1=eb06e8 a2=1000 a3=0 items=0 ppid=1431 pid=1435 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=SYSCALL msg=audit(1259802888.342:9): arch=c000003e syscall=16 success=yes exit=128 a0=5 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.347:11): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11031]" dev=pipefs ino=11031 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.347:11): arch=c000003e syscall=16 success=yes exit=128 a0=6 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.350:12): avc: denied { read } for pid=1439 comm="sshdfilter" path="pipe:[11031]" dev=pipefs ino=11031 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.350:12): arch=c000003e syscall=0 success=yes exit=128 a0=5 a1=eb0f18 a2=1000 a3=0 items=0 ppid=1438 pid=1439 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.360:13): avc: denied { read } for pid=1440 comm="sshdfilter" name="sh" dev=dm-0 ino=10258 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file > type=SYSCALL msg=audit(1259802888.360:13): arch=c000003e syscall=59 success=no exit=-13 a0=7fd1ef909e0f a1=7fffa884e9b0 a2=7fffa88511c0 a3=7fffa88507d0 items=0 ppid=1438 pid=1440 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.364:14): avc: denied { write } for pid=1440 comm="sshdfilter" path="pipe:[11043]" dev=pipefs ino=11043 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.364:14): arch=c000003e syscall=1 success=yes exit=128 a0=a a1=7fffa8850a0c a2=4 a3=7fffa8850790 items=0 ppid=1438 pid=1440 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.367:15): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11043]" dev=pipefs ino=11043 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.367:15): arch=c000003e syscall=0 success=yes exit=128 a0=9 a1=7fffa8850ccc a2=4 a3=b73830 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.367:16): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11042]" dev=pipefs ino=11042 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.367:16): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7fffa8850a20 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.367:17): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11042]" dev=pipefs ino=11042 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.367:17): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=eb1168 a2=1000 a3=0 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.375:18): avc: denied { read } for pid=1441 comm="sshdfilter" name="sh" dev=dm-0 ino=10258 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file > type=SYSCALL msg=audit(1259802888.375:18): arch=c000003e syscall=59 success=no exit=-13 a0=7fd1ef909e0f a1=7fffa884e9b0 a2=7fffa88511c0 a3=7fffa88507d0 items=0 ppid=1438 pid=1441 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.375:19): avc: denied { write } for pid=1441 comm="sshdfilter" path="pipe:[11045]" dev=pipefs ino=11045 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.375:19): arch=c000003e syscall=1 success=yes exit=128 a0=a a1=7fffa8850a0c a2=4 a3=8 items=0 ppid=1438 pid=1441 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.378:20): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11045]" dev=pipefs ino=11045 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.378:20): arch=c000003e syscall=0 success=yes exit=128 a0=9 a1=7fffa8850ccc a2=4 a3=7fd1ef2e39d0 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.378:21): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11044]" dev=pipefs ino=11044 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.378:21): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7fffa8850a20 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.378:22): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11044]" dev=pipefs ino=11044 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.378:22): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=eb2878 a2=1000 a3=0 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.379:23): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11046]" dev=pipefs ino=11046 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.379:23): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.379:24): avc: denied { ioctl } for pid=1438 comm="sshdfilter" path="pipe:[11046]" dev=pipefs ino=11046 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.379:24): arch=c000003e syscall=16 success=yes exit=128 a0=8 a1=5401 a2=7fffa8850c80 a3=60 items=0 ppid=1435 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.384:25): avc: denied { ioctl } for pid=1442 comm="sshdfilter" path="pipe:[11046]" dev=pipefs ino=11046 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.384:25): arch=c000003e syscall=16 success=yes exit=128 a0=4 a1=5401 a2=7fffa8850ba0 a3=60 items=0 ppid=1438 pid=1442 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802888.384:26): avc: denied { getattr } for pid=1442 comm="sshdfilter" path="pipe:[11046]" dev=pipefs ino=11046 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802888.384:26): arch=c000003e syscall=5 success=yes exit=128 a0=4 a1=b730a0 a2=b730a0 a3=0 items=0 ppid=1438 pid=1442 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802889.381:27): avc: denied { read } for pid=1494 comm="sshdfilter" name="iptables" dev=dm-0 ino=11793 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file > type=SYSCALL msg=audit(1259802889.381:27): arch=c000003e syscall=59 success=no exit=-13 a0=7fffa8850a88 a1=eb31c8 a2=7fffa88511c0 a3=7fffa88508d0 items=0 ppid=1438 pid=1494 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802889.382:28): avc: denied { write } for pid=1494 comm="sshdfilter" path="pipe:[11397]" dev=pipefs ino=11397 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802889.382:28): arch=c000003e syscall=1 success=yes exit=128 a0=9 a1=7fffa8850b0c a2=4 a3=8 items=0 ppid=1438 pid=1494 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802889.385:29): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11397]" dev=pipefs ino=11397 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802889.385:29): arch=c000003e syscall=0 success=yes exit=128 a0=8 a1=7fffa8850f18 a2=4 a3=8 items=0 ppid=1 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802889.388:30): avc: denied { write } for pid=1438 comm="sshdfilter" path="pipe:[11021]" dev=pipefs ino=11021 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802889.388:30): arch=c000003e syscall=1 success=yes exit=128 a0=4 a1=eb3248 a2=9 a3=0 items=0 ppid=1 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259802889.390:31): avc: denied { read } for pid=1438 comm="sshdfilter" path="pipe:[11046]" dev=pipefs ino=11046 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259802889.390:31): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=eb3568 a2=400 a3=b73010 items=0 ppid=1 pid=1438 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.790:43): avc: denied { ioctl } for pid=2329 comm="sshdfilter" path="pipe:[24498]" dev=pipefs ino=24498 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.790:43): arch=c000003e syscall=16 success=yes exit=4294967424 a0=3 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2323 pid=2329 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.795:44): avc: denied { ioctl } for pid=2329 comm="sshdfilter" path="pipe:[24498]" dev=pipefs ino=24498 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.795:44): arch=c000003e syscall=16 success=yes exit=4294967424 a0=4 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2323 pid=2329 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.798:45): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24509]" dev=pipefs ino=24509 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=AVC msg=audit(1259803042.801:46): avc: denied { read } for pid=2329 comm="sshdfilter" path="pipe:[24498]" dev=pipefs ino=24498 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.801:46): arch=c000003e syscall=0 success=yes exit=128 a0=3 a1=104fb28 a2=1000 a3=0 items=0 ppid=2323 pid=2329 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=SYSCALL msg=audit(1259803042.798:45): arch=c000003e syscall=16 success=yes exit=4294967424 a0=5 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.804:47): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24509]" dev=pipefs ino=24509 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.804:47): arch=c000003e syscall=16 success=yes exit=4294967424 a0=6 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.806:48): avc: denied { read } for pid=2333 comm="sshdfilter" path="pipe:[24509]" dev=pipefs ino=24509 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=AVC msg=audit(1259803042.812:49): avc: denied { read } for pid=2334 comm="sshdfilter" name="sh" dev=dm-0 ino=10258 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file > type=SYSCALL msg=audit(1259803042.806:48): arch=c000003e syscall=0 success=yes exit=4294967424 a0=5 a1=1050268 a2=1000 a3=0 items=0 ppid=2332 pid=2333 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.816:50): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24516]" dev=pipefs ino=24516 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.812:49): arch=c000003e syscall=59 success=no exit=-13 a0=7fceba680e0f a1=7ffffc391b70 a2=7ffffc394380 a3=7ffffc393990 items=0 ppid=2332 pid=2334 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.816:51): avc: denied { write } for pid=2334 comm="sshdfilter" path="pipe:[24516]" dev=pipefs ino=24516 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.816:51): arch=c000003e syscall=1 success=yes exit=128 a0=a a1=7ffffc393bcc a2=4 a3=7ffffc393950 items=0 ppid=2332 pid=2334 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=SYSCALL msg=audit(1259803042.816:50): arch=c000003e syscall=0 success=yes exit=128 a0=9 a1=7ffffc393e8c a2=4 a3=d13830 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.818:52): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24515]" dev=pipefs ino=24515 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.818:52): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7ffffc393be0 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.818:53): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24515]" dev=pipefs ino=24515 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.818:53): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=10504b8 a2=1000 a3=0 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.823:54): avc: denied { read } for pid=2335 comm="sshdfilter" name="sh" dev=dm-0 ino=10258 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file > type=SYSCALL msg=audit(1259803042.823:54): arch=c000003e syscall=59 success=no exit=-13 a0=7fceba680e0f a1=7ffffc391b70 a2=7ffffc394380 a3=7ffffc393990 items=0 ppid=2332 pid=2335 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.823:55): avc: denied { write } for pid=2335 comm="sshdfilter" path="pipe:[24518]" dev=pipefs ino=24518 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.823:55): arch=c000003e syscall=1 success=yes exit=128 a0=a a1=7ffffc393bcc a2=4 a3=8 items=0 ppid=2332 pid=2335 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.828:56): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24518]" dev=pipefs ino=24518 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.828:56): arch=c000003e syscall=0 success=yes exit=128 a0=9 a1=7ffffc393e8c a2=4 a3=7fceba05a9d0 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.828:57): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24517]" dev=pipefs ino=24517 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.828:57): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7ffffc393be0 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.828:58): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24517]" dev=pipefs ino=24517 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.828:58): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=1051cc8 a2=1000 a3=0 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.833:59): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24519]" dev=pipefs ino=24519 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.833:59): arch=c000003e syscall=16 success=yes exit=128 a0=7 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.833:60): avc: denied { ioctl } for pid=2332 comm="sshdfilter" path="pipe:[24519]" dev=pipefs ino=24519 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.833:60): arch=c000003e syscall=16 success=yes exit=128 a0=8 a1=5401 a2=7ffffc393e40 a3=60 items=0 ppid=2329 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.834:61): avc: denied { ioctl } for pid=2336 comm="sshdfilter" path="pipe:[24519]" dev=pipefs ino=24519 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.834:61): arch=c000003e syscall=16 success=yes exit=128 a0=4 a1=5401 a2=7ffffc393d60 a3=60 items=0 ppid=2332 pid=2336 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803042.836:62): avc: denied { getattr } for pid=2336 comm="sshdfilter" path="pipe:[24519]" dev=pipefs ino=24519 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803042.836:62): arch=c000003e syscall=5 success=yes exit=128 a0=4 a1=d130a0 a2=d130a0 a3=0 items=0 ppid=2332 pid=2336 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803043.839:63): avc: denied { read } for pid=2338 comm="sshdfilter" name="iptables" dev=dm-0 ino=11793 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file > type=SYSCALL msg=audit(1259803043.839:63): arch=c000003e syscall=59 success=no exit=-13 a0=7ffffc393c48 a1=1052638 a2=7ffffc394380 a3=7ffffc393a90 items=0 ppid=2332 pid=2338 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803043.840:64): avc: denied { write } for pid=2338 comm="sshdfilter" path="pipe:[24549]" dev=pipefs ino=24549 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803043.840:64): arch=c000003e syscall=1 success=yes exit=128 a0=9 a1=7ffffc393ccc a2=4 a3=8 items=0 ppid=2332 pid=2338 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803043.844:65): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24549]" dev=pipefs ino=24549 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803043.844:65): arch=c000003e syscall=0 success=yes exit=128 a0=8 a1=7ffffc3940d8 a2=4 a3=8 items=0 ppid=1 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803043.845:66): avc: denied { write } for pid=2332 comm="sshdfilter" path="pipe:[24498]" dev=pipefs ino=24498 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803043.845:66): arch=c000003e syscall=1 success=yes exit=128 a0=4 a1=10526b8 a2=9 a3=0 items=0 ppid=1 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803043.849:67): avc: denied { read } for pid=2332 comm="sshdfilter" path="pipe:[24519]" dev=pipefs ino=24519 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:iptables_t:s0 tclass=fifo_file > type=SYSCALL msg=audit(1259803043.849:67): arch=c000003e syscall=0 success=yes exit=128 a0=7 a1=10529d8 a2=400 a3=d13010 items=0 ppid=1 pid=2332 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:iptables_t:s0 key=(null) > type=AVC msg=audit(1259803128.077:69): avc: denied { execute } for pid=2422 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259803128.077:69): arch=c000003e syscall=59 success=no exit=-13 a0=7fff14469168 a1=1c20208 a2=7fff144698a0 a3=7fff14468fb0 items=0 ppid=2413 pid=2422 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259806154.170:82): avc: denied { execute } for pid=2653 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259806154.170:82): arch=c000003e syscall=59 success=no exit=-13 a0=7fff14469168 a1=1c267e8 a2=7fff144698a0 a3=7fff14468fb0 items=0 ppid=2413 pid=2653 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259812687.066:113): avc: denied { read open } for pid=3074 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259812687.066:113): arch=c000003e syscall=59 success=no exit=-13 a0=7fff14469168 a1=1c26a88 a2=7fff144698a0 a3=7fff14468fb0 items=0 ppid=2413 pid=3074 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259816690.197:196): avc: denied { read open } for pid=3631 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259816690.197:196): arch=c000003e syscall=59 success=no exit=-13 a0=7fff15c5a888 a1=24095a8 a2=7fff15c5afc0 a3=7fff15c5a6d0 items=0 ppid=3622 pid=3631 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=9 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259819529.773:214): avc: denied { read open } for pid=3827 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259819529.773:214): arch=c000003e syscall=59 success=no exit=-13 a0=7fff15c5a888 a1=2410198 a2=7fff15c5afc0 a3=7fff15c5a6d0 items=0 ppid=3622 pid=3827 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=9 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259899887.509:471): avc: denied { read open } for pid=11794 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259899887.509:471): arch=c000003e syscall=59 success=no exit=-13 a0=7fff15c5a888 a1=2410198 a2=7fff15c5afc0 a3=7fff15c5a6d0 items=0 ppid=3622 pid=11794 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=9 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259899890.409:475): avc: denied { read open } for pid=11799 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259899890.409:475): arch=c000003e syscall=59 success=no exit=-13 a0=7fff15c5a888 a1=2410548 a2=7fff15c5afc0 a3=7fff15c5a6d0 items=0 ppid=3622 pid=11799 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=9 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1259899950.600:483): avc: denied { read open } for pid=11860 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1259899950.600:483): arch=c000003e syscall=59 success=no exit=-13 a0=7fff9722f198 a1=f6e208 a2=7fff9722f8d0 a3=7fff9722efe0 items=0 ppid=11851 pid=11860 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=44 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1260146847.427:1066): avc: denied { read open } for pid=28420 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1260146847.427:1066): arch=c000003e syscall=59 success=no exit=-13 a0=7fff9722f198 a1=f71c88 a2=7fff9722f8d0 a3=7fff9722efe0 items=0 ppid=11851 pid=28420 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=44 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1260146850.722:1070): avc: denied { read open } for pid=28428 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1260146850.722:1070): arch=c000003e syscall=59 success=no exit=-13 a0=7fff9722f198 a1=f72a28 a2=7fff9722f8d0 a3=7fff9722efe0 items=0 ppid=11851 pid=28428 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=44 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1260500225.789:25455): avc: denied { read open } for pid=21350 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1260500225.789:25455): arch=c000003e syscall=59 success=no exit=-13 a0=7fff032b96b8 a1=bdbd18 a2=7fff032b9df0 a3=7fff032b9500 items=0 ppid=1441 pid=21350 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1260500228.740:25459): avc: denied { read open } for pid=21355 comm="sshdfilter" name="iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1260500228.740:25459): arch=c000003e syscall=59 success=no exit=-13 a0=7fff032b96b8 a1=bddc38 a2=7fff032b9df0 a3=7fff032b9500 items=0 ppid=1441 pid=21355 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1260500358.675:25470): avc: denied { getattr } for pid=1441 comm="sshdfilter" path="/var/run/sshdfilter.pid.SSHD" dev=dm-0 ino=10948 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file > type=SYSCALL msg=audit(1260500358.675:25470): arch=c000003e syscall=6 success=no exit=-13 a0=bd5dd8 a1=8980a0 a2=8980a0 a3=7fff032b9880 items=0 ppid=1 pid=1441 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1260809448.592:28614): avc: denied { execute_no_trans } for pid=23422 comm="sshdfilter" path="/sbin/iptables-multi" dev=dm-0 ino=11798 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1260809448.592:28614): arch=c000003e syscall=59 success=no exit=-13 a0=7fffc0880288 a1=e0c508 a2=7fffc08809c0 a3=7fffc08800d0 items=0 ppid=1432 pid=23422 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshdfilter" exe="/usr/bin/perl" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > > > >=20 > > >=20 > > > Moray. > > > "To err is human. To purr, feline" > > >=20 > > >=20 > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > --uAKRQypu60I7Lcqm > > Content-Type: application/pgp-signature > > Content-Disposition: inline > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.10 (GNU/Linux) > > > > iEYEARECAAYFAksdZWwACgkQMlxVo39jgT/olgCgwo9wvxeAyJG/gm4dEYHBIpGf > > TNEAn2bFoQZeg8+gaYPIDuB0wxuu6N8F > > =tNuu > > -----END PGP SIGNATURE----- > > > > --uAKRQypu60I7Lcqm-- > > > > > > --===============0725889959== > > Content-Type: text/plain; charset="us-ascii" > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > --===============0725889959==-- > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From James.Cernak at ngc.com Mon Dec 14 22:56:27 2009 From: James.Cernak at ngc.com (Cernak, James E (IS)) Date: Mon, 14 Dec 2009 16:56:27 -0600 Subject: how to restrict a SOCK_RAW by interface References: <1309562CC0F060478581A2D7331F90AC5AD11C@XMBTX122.northgrum.com> <1260820192.4126.13.camel@moss-pluto.epoch.ncsc.mil> Message-ID: <1309562CC0F060478581A2D7331F90AC5AD11E@XMBTX122.northgrum.com> Hello, Thanks for the hint, However it does not solve my problem I still can read from eth0. I did have to add allow rules for netif_t:netif but my policy still does not allow iface_test_t. James -----Original Message----- From: Stephen Smalley [mailto:sds at tycho.nsa.gov] Sent: Mon 12/14/2009 1:49 PM To: Cernak, James E (IS) Cc: fedora-selinux-list at redhat.com Subject: Re: how to restrict a SOCK_RAW by interface On Mon, 2009-12-14 at 13:29 -0600, Cernak, James E (IS) wrote: > Hello, > > I am trying to restrict an application to using only some interfaces > on the system. I have defined a new type and assigned the interface on > my RHEL5.4-x64 system to the new type with semanage. The system > indicates that the interface is now configured. > # semanage interface -l > SELinux Interface Context > > eth1 system_u:object_r:iface_test_t:s0 > This does restrict applications like tcpdump or wireshark from listing > the interface that was configured. > # tcpdump -D > 1.peth0 > 2.virbr0 > 3.vif0.0 > 4.eth0 > 5.xenbr0 > 6.eth2 > 7.eth3 > 8.any (Pseudo-device that captures on all interfaces) > 9.lo > > My problem comes that my application can still open eth1 and read and > write packets to this interface. > The application is opening a socket as SOCK_RAW then binding with a > struct sockaddr_LL that has the ssll_ifindex field configured with the > index of ETH1. > How do I write a selinux policy to restrict this application from > using some interfaces. > In RHEL5 (Linux 2.6.18), you might need to enable compat_net (echo 1 > /selinux/compat_net or boot with selinux_compat_net=1 on the kernel command line). -- Stephen Smalley National Security Agency -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhighley at highley-recommended.com Tue Dec 15 00:08:56 2009 From: dhighley at highley-recommended.com (David Highley) Date: Mon, 14 Dec 2009 16:08:56 -0800 (PST) Subject: Fedora 12 and unconfined_u sshdfilter In-Reply-To: <20091214213537.GB23680@localhost.localdomain> Message-ID: <200912150008.nBF08uCk030514@douglas.highley-recommended.com> "Dominick Grift wrote:" > > > --===============1736741946== > Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; boundary="2B/JsCI69OhZNC5r" > Content-Disposition: inline > > > --2B/JsCI69OhZNC5r > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Mon, Dec 14, 2009 at 10:25:08AM -0800, David Highley wrote: > > "Dominick Grift wrote:" > > >=20 > > >=20 > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0725889959=3D=3D > > > Content-Type: multipart/signed; micalg=3Dpgp-sha1; > > > protocol=3D"application/pgp-signature"; boundary=3D"uAKRQypu60I7Lcqm" > > > Content-Disposition: inline > > >=20 > > >=20 > > > --uAKRQypu60I7Lcqm > > > Content-Type: text/plain; charset=3Dutf-8 > > > Content-Disposition: inline > > > Content-Transfer-Encoding: quoted-printable > > >=20 > > > On Mon, Dec 07, 2009 at 12:01:09PM +0000, Moray Henderson (ICT) wrote: > > > > James Carter wrote: > > > > >Dan's example used Refpolicy interfaces. Interfaces are very useful= > and > > > > >provide a better layer of abstraction, but they are just m4 macros, > > > > >which have always been used in SELinux policy. > > > > > > > > > >Interfaces should be used as much as possible, but it is not true th= > at > > > > >you can't mix the old and new ways. > > > >=3D20 > > > > Mixing the plain rules and the m4 macros didn't work when I tried it = > - bu=3D > > > t perhaps I just wasn=3DE2=3D80=3D99t writing it right. Is there a Ref= > policy tut=3D > > > orial anywhere? > > >=20 > > > I spend a little time today writing about the policy structure in Fedor= > a. M=3D > > > aybe it can help you or others: > > >=20 > > > http://82.197.205.60/~dgrift/stuff/Managing_a_SELinux_environment_with_= > Fedo=3D > > > ra_12.pdf > >=20 > >=20 > > Still have not mastered this one yet. Here is the policy file created by > > grep of /var/log/audit/audit.log file piped to audit2allow: > >=20 > > module mysshdfilter 1.0; > >=20 > > require { > > type var_run_t; > > type iptables_exec_t; > > type bin_t; > > type sshd_t; > > type iptables_t; > > class lnk_file read; > > class file { read getattr open execute execute_no_trans }; > > class fifo_file { read write ioctl getattr }; > > } > >=20 > > #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D iptables_t =3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D > > allow iptables_t bin_t:lnk_file read; > > allow iptables_t self:fifo_file { read write ioctl getattr }; > >=20 > > #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sshd_t =3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D > > allow sshd_t iptables_exec_t:file { read execute open execute_no_trans }; > > > > allow sshd_t var_run_t:file getattr; > > Actually i think sshdfilter init script may have created it? Does it even h= > ave an init script? Sorry, I think I confused the issue a little. I dumped in all the audit log entries related to the sshd filter wrapper script starting with no policy changes. I thought it might help to find the right policy changes. The wrapper filter script does not have its own init script, we modify the sshd init script to invoke the wrapper script instead of sshd. This is some what bad in that package maintainers assume they can freely over write the init scripts and not break a site. > > >=20 > >=20 > > The audit log entries are: > > type=3DAVC msg=3Daudit(1259642932.902:7): avc: denied { execute } for = > pid=3D1411 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D117= > 98 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_u:o= > bject_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259642932.902:7): arch=3Dc000003e syscall=3D5= > 9 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D1562e28 a2=3D7fff837b3df0 = > a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D1411 auid=3D4294967295 uid=3D= > 0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(no= > ne) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsyste= > m_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259644707.700:73): avc: denied { execute } for = > pid=3D1948 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D11= > 798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_u:= > object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259644707.700:73): arch=3Dc000003e syscall=3D= > 59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D15694c8 a2=3D7fff837b3df0= > a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D1948 auid=3D4294967295 uid= > =3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D= > (none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsy= > stem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259650605.247:84): avc: denied { execute } for = > pid=3D2248 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D11= > 798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_u:= > object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259650605.247:84): arch=3Dc000003e syscall=3D= > 59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D1567828 a2=3D7fff837b3df0= > a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D2248 auid=3D4294967295 uid= > =3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D= > (none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsy= > stem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259661894.420:113): avc: denied { execute } for= > pid=3D2815 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D1= > 1798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_u= > :object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259661894.420:113): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D1566e28 a2=3D7fff837b3= > df0 a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D2815 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259667665.966:123): avc: denied { execute } for= > pid=3D3724 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D1= > 1798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_u= > :object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259667665.966:123): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D15699d8 a2=3D7fff837b3= > df0 a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D3724 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259671660.048:131): avc: denied { execute } for= > pid=3D3920 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D1= > 1798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_u= > :object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259671660.048:131): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D1565778 a2=3D7fff837b3= > df0 a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D3920 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259673411.553:758): avc: denied { execute } for= > pid=3D4558 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D1= > 1798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_u= > :object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259673411.553:758): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D1569af8 a2=3D7fff837b3= > df0 a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D4558 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259679153.568:1267): avc: denied { execute } fo= > r pid=3D5170 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D= > 11798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_= > u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259679153.568:1267): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D1566a68 a2=3D7fff837b3= > df0 a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D5170 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259682588.736:1315): avc: denied { execute } fo= > r pid=3D5540 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D= > 11798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_= > u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259682588.736:1315): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D1565778 a2=3D7fff837b3= > df0 a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D5540 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259684861.197:1344): avc: denied { execute } fo= > r pid=3D5745 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D= > 11798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_= > u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259684861.197:1344): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D156a478 a2=3D7fff837b3= > df0 a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D5745 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259690558.951:1388): avc: denied { execute } fo= > r pid=3D6161 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D= > 11798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_= > u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259690558.951:1388): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D15667a8 a2=3D7fff837b3= > df0 a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D6161 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259702647.573:1433): avc: denied { execute } fo= > r pid=3D6829 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D= > 11798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_= > u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259702647.573:1433): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D156b4d8 a2=3D7fff837b3= > df0 a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D6829 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259708100.231:1441): avc: denied { execute } fo= > r pid=3D7085 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D= > 11798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_= > u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259708100.231:1441): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D156a0b8 a2=3D7fff837b3= > df0 a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D7085 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259708922.953:1450): avc: denied { execute } fo= > r pid=3D7153 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D= > 11798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_= > u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259708922.953:1450): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D156a6a8 a2=3D7fff837b3= > df0 a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D7153 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259713257.803:1545): avc: denied { execute } fo= > r pid=3D7492 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D= > 11798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_= > u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259713257.803:1545): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D156a4a8 a2=3D7fff837b3= > df0 a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D7492 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259721513.893:1732): avc: denied { execute } fo= > r pid=3D8097 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D= > 11798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_= > u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259721513.893:1732): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D156a5d8 a2=3D7fff837b3= > df0 a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D8097 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259730724.196:1790): avc: denied { execute } fo= > r pid=3D8689 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D= > 11798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_= > u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259730724.196:1790): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D1569718 a2=3D7fff837b3= > df0 a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D8689 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259730728.123:1793): avc: denied { execute } fo= > r pid=3D8699 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D= > 11798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_= > u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259730728.123:1793): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D1566778 a2=3D7fff837b3= > df0 a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D8699 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259747840.157:1835): avc: denied { execute } fo= > r pid=3D9575 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D= > 11798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsystem_= > u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259747840.157:1835): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D156ba78 a2=3D7fff837b3= > df0 a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D9575 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259760819.408:1863): avc: denied { execute } fo= > r pid=3D10840 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino= > =3D11798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsyst= > em_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259760819.408:1863): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff837b36b8 a1=3D156a4a8 a2=3D7fff837b3= > df0 a3=3D7fff837b3500 items=3D0 ppid=3D1402 pid=3D10840 auid=3D4294967295 u= > id=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259762576.442:1887): avc: denied { execute } fo= > r pid=3D11067 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino= > =3D11798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3D= > system_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259762576.442:1887): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fffb91649e8 a1=3Dd4d5a8 a2=3D7fffb91651= > 20 a3=3D7fffb9164830 items=3D0 ppid=3D11058 pid=3D11067 auid=3D1000 uid=3D0= > gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(non= > e) ses=3D47 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:s= > ystem_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259767362.673:1896): avc: denied { execute } fo= > r pid=3D11318 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino= > =3D11798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3D= > system_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259767362.673:1896): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fffb91649e8 a1=3Dd54088 a2=3D7fffb91651= > 20 a3=3D7fffb9164830 items=3D0 ppid=3D11058 pid=3D11318 auid=3D1000 uid=3D0= > gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(non= > e) ses=3D47 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:s= > ystem_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259773905.214:1967): avc: denied { execute } fo= > r pid=3D11922 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino= > =3D11798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3D= > system_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259773905.214:1967): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fffb91649e8 a1=3Dd54868 a2=3D7fffb91651= > 20 a3=3D7fffb9164830 items=3D0 ppid=3D11058 pid=3D11922 auid=3D1000 uid=3D0= > gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(non= > e) ses=3D47 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:s= > ystem_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259780362.196:1977): avc: denied { execute } fo= > r pid=3D12215 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino= > =3D11798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3D= > system_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259780362.196:1977): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fffb91649e8 a1=3Dd50af8 a2=3D7fffb91651= > 20 a3=3D7fffb9164830 items=3D0 ppid=3D11058 pid=3D12215 auid=3D1000 uid=3D0= > gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(non= > e) ses=3D47 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:s= > ystem_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259780393.314:1979): avc: denied { execute } fo= > r pid=3D12219 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino= > =3D11798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3D= > system_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259780393.314:1979): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fffb91649e8 a1=3Dd50af8 a2=3D7fffb91651= > 20 a3=3D7fffb9164830 items=3D0 ppid=3D11058 pid=3D12219 auid=3D1000 uid=3D0= > gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(non= > e) ses=3D47 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:s= > ystem_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259785085.323:2012): avc: denied { execute } fo= > r pid=3D12568 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino= > =3D11798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3D= > system_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259785085.323:2012): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fffb91649e8 a1=3Dd521b8 a2=3D7fffb91651= > 20 a3=3D7fffb9164830 items=3D0 ppid=3D11058 pid=3D12568 auid=3D1000 uid=3D0= > gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(non= > e) ses=3D47 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:s= > ystem_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259786872.756:2015): avc: denied { execute } fo= > r pid=3D12645 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino= > =3D11798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3D= > system_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259786872.756:2015): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fffb91649e8 a1=3Dd53568 a2=3D7fffb91651= > 20 a3=3D7fffb9164830 items=3D0 ppid=3D11058 pid=3D12645 auid=3D1000 uid=3D0= > gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(non= > e) ses=3D47 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:s= > ystem_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259795695.936:2052): avc: denied { execute } fo= > r pid=3D13127 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino= > =3D11798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3D= > system_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259795695.936:2052): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fffb91649e8 a1=3Dd52e38 a2=3D7fffb91651= > 20 a3=3D7fffb9164830 items=3D0 ppid=3D11058 pid=3D13127 auid=3D1000 uid=3D0= > gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(non= > e) ses=3D47 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:s= > ystem_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259802506.518:3031): avc: denied { getattr } fo= > r pid=3D11058 comm=3D"sshdfilter" path=3D"/var/run/sshdfilter.pid.SSHD" de= > v=3Ddm-0 ino=3D12538 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023= > tcontext=3Dsystem_u:object_r:var_run_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259802506.518:3031): arch=3Dc000003e syscall= > =3D6 success=3Dno exit=3D-13 a0=3Dd4a128 a1=3Da0d0a0 a2=3Da0d0a0 a3=3D7fffb= > 9164bb0 items=3D0 ppid=3D1 pid=3D11058 auid=3D1000 uid=3D0 gid=3D0 euid=3D0= > suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D47 comm= > =3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:sshd_t:s= > 0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259802888.332:7): avc: denied { ioctl } for pi= > d=3D1435 comm=3D"sshdfilter" path=3D"pipe:[11021]" dev=3Dpipefs ino=3D11021= > scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:ip= > tables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802888.332:7): arch=3Dc000003e syscall=3D1= > 6 success=3Dyes exit=3D128 a0=3D3 a1=3D5401 a2=3D7fffa8850c80 a3=3D60 items= > =3D0 ppid=3D1431 pid=3D1435 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 suid= > =3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 co= > mm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_t= > :s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259802888.340:8): avc: denied { ioctl } for pi= > d=3D1435 comm=3D"sshdfilter" path=3D"pipe:[11021]" dev=3Dpipefs ino=3D11021= > scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:ip= > tables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802888.340:8): arch=3Dc000003e syscall=3D1= > 6 success=3Dyes exit=3D128 a0=3D4 a1=3D5401 a2=3D7fffa8850c80 a3=3D60 items= > =3D0 ppid=3D1431 pid=3D1435 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 suid= > =3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 co= > mm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_t= > :s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259802888.342:9): avc: denied { ioctl } for pi= > d=3D1438 comm=3D"sshdfilter" path=3D"pipe:[11031]" dev=3Dpipefs ino=3D11031= > scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:ip= > tables_t:s0 tclass=3Dfifo_file > > type=3DAVC msg=3Daudit(1259802888.343:10): avc: denied { read } for pi= > d=3D1435 comm=3D"sshdfilter" path=3D"pipe:[11021]" dev=3Dpipefs ino=3D11021= > scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:ip= > tables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802888.343:10): arch=3Dc000003e syscall=3D= > 0 success=3Dyes exit=3D128 a0=3D3 a1=3Deb06e8 a2=3D1000 a3=3D0 items=3D0 pp= > id=3D1431 pid=3D1435 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fs= > uid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 comm=3D"s= > shdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_t:s0 key= > =3D(null) > > type=3DSYSCALL msg=3Daudit(1259802888.342:9): arch=3Dc000003e syscall=3D1= > 6 success=3Dyes exit=3D128 a0=3D5 a1=3D5401 a2=3D7fffa8850c80 a3=3D60 items= > =3D0 ppid=3D1435 pid=3D1438 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 suid= > =3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 co= > mm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_t= > :s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259802888.347:11): avc: denied { ioctl } for p= > id=3D1438 comm=3D"sshdfilter" path=3D"pipe:[11031]" dev=3Dpipefs ino=3D1103= > 1 scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:i= > ptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802888.347:11): arch=3Dc000003e syscall=3D= > 16 success=3Dyes exit=3D128 a0=3D6 a1=3D5401 a2=3D7fffa8850c80 a3=3D60 item= > s=3D0 ppid=3D1435 pid=3D1438 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 sui= > d=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 c= > omm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_= > t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259802888.350:12): avc: denied { read } for pi= > d=3D1439 comm=3D"sshdfilter" path=3D"pipe:[11031]" dev=3Dpipefs ino=3D11031= > scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:ip= > tables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802888.350:12): arch=3Dc000003e syscall=3D= > 0 success=3Dyes exit=3D128 a0=3D5 a1=3Deb0f18 a2=3D1000 a3=3D0 items=3D0 pp= > id=3D1438 pid=3D1439 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fs= > uid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 comm=3D"s= > shdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_t:s0 key= > =3D(null) > > type=3DAVC msg=3Daudit(1259802888.360:13): avc: denied { read } for pi= > d=3D1440 comm=3D"sshdfilter" name=3D"sh" dev=3Ddm-0 ino=3D10258 scontext=3D= > system_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:object_r:bin_t:s0 tclas= > s=3Dlnk_file > > type=3DSYSCALL msg=3Daudit(1259802888.360:13): arch=3Dc000003e syscall=3D= > 59 success=3Dno exit=3D-13 a0=3D7fd1ef909e0f a1=3D7fffa884e9b0 a2=3D7fffa88= > 511c0 a3=3D7fffa88507d0 items=3D0 ppid=3D1438 pid=3D1440 auid=3D4294967295 = > uid=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:iptables_t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259802888.364:14): avc: denied { write } for p= > id=3D1440 comm=3D"sshdfilter" path=3D"pipe:[11043]" dev=3Dpipefs ino=3D1104= > 3 scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:i= > ptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802888.364:14): arch=3Dc000003e syscall=3D= > 1 success=3Dyes exit=3D128 a0=3Da a1=3D7fffa8850a0c a2=3D4 a3=3D7fffa885079= > 0 items=3D0 ppid=3D1438 pid=3D1440 auid=3D4294967295 uid=3D0 gid=3D0 euid= > =3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294= > 967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:i= > ptables_t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259802888.367:15): avc: denied { read } for pi= > d=3D1438 comm=3D"sshdfilter" path=3D"pipe:[11043]" dev=3Dpipefs ino=3D11043= > scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:ip= > tables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802888.367:15): arch=3Dc000003e syscall=3D= > 0 success=3Dyes exit=3D128 a0=3D9 a1=3D7fffa8850ccc a2=3D4 a3=3Db73830 item= > s=3D0 ppid=3D1435 pid=3D1438 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 sui= > d=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 c= > omm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_= > t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259802888.367:16): avc: denied { ioctl } for p= > id=3D1438 comm=3D"sshdfilter" path=3D"pipe:[11042]" dev=3Dpipefs ino=3D1104= > 2 scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:i= > ptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802888.367:16): arch=3Dc000003e syscall=3D= > 16 success=3Dyes exit=3D128 a0=3D7 a1=3D5401 a2=3D7fffa8850a20 a3=3D60 item= > s=3D0 ppid=3D1435 pid=3D1438 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 sui= > d=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 c= > omm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_= > t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259802888.367:17): avc: denied { read } for pi= > d=3D1438 comm=3D"sshdfilter" path=3D"pipe:[11042]" dev=3Dpipefs ino=3D11042= > scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:ip= > tables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802888.367:17): arch=3Dc000003e syscall=3D= > 0 success=3Dyes exit=3D128 a0=3D7 a1=3Deb1168 a2=3D1000 a3=3D0 items=3D0 pp= > id=3D1435 pid=3D1438 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fs= > uid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 comm=3D"s= > shdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_t:s0 key= > =3D(null) > > type=3DAVC msg=3Daudit(1259802888.375:18): avc: denied { read } for pi= > d=3D1441 comm=3D"sshdfilter" name=3D"sh" dev=3Ddm-0 ino=3D10258 scontext=3D= > system_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:object_r:bin_t:s0 tclas= > s=3Dlnk_file > > type=3DSYSCALL msg=3Daudit(1259802888.375:18): arch=3Dc000003e syscall=3D= > 59 success=3Dno exit=3D-13 a0=3D7fd1ef909e0f a1=3D7fffa884e9b0 a2=3D7fffa88= > 511c0 a3=3D7fffa88507d0 items=3D0 ppid=3D1438 pid=3D1441 auid=3D4294967295 = > uid=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:iptables_t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259802888.375:19): avc: denied { write } for p= > id=3D1441 comm=3D"sshdfilter" path=3D"pipe:[11045]" dev=3Dpipefs ino=3D1104= > 5 scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:i= > ptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802888.375:19): arch=3Dc000003e syscall=3D= > 1 success=3Dyes exit=3D128 a0=3Da a1=3D7fffa8850a0c a2=3D4 a3=3D8 items=3D0= > ppid=3D1438 pid=3D1441 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 suid=3D0= > fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 comm= > =3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_t:s= > 0 key=3D(null) > > type=3DAVC msg=3Daudit(1259802888.378:20): avc: denied { read } for pi= > d=3D1438 comm=3D"sshdfilter" path=3D"pipe:[11045]" dev=3Dpipefs ino=3D11045= > scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:ip= > tables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802888.378:20): arch=3Dc000003e syscall=3D= > 0 success=3Dyes exit=3D128 a0=3D9 a1=3D7fffa8850ccc a2=3D4 a3=3D7fd1ef2e39d= > 0 items=3D0 ppid=3D1435 pid=3D1438 auid=3D4294967295 uid=3D0 gid=3D0 euid= > =3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294= > 967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:i= > ptables_t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259802888.378:21): avc: denied { ioctl } for p= > id=3D1438 comm=3D"sshdfilter" path=3D"pipe:[11044]" dev=3Dpipefs ino=3D1104= > 4 scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:i= > ptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802888.378:21): arch=3Dc000003e syscall=3D= > 16 success=3Dyes exit=3D128 a0=3D7 a1=3D5401 a2=3D7fffa8850a20 a3=3D60 item= > s=3D0 ppid=3D1435 pid=3D1438 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 sui= > d=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 c= > omm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_= > t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259802888.378:22): avc: denied { read } for pi= > d=3D1438 comm=3D"sshdfilter" path=3D"pipe:[11044]" dev=3Dpipefs ino=3D11044= > scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:ip= > tables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802888.378:22): arch=3Dc000003e syscall=3D= > 0 success=3Dyes exit=3D128 a0=3D7 a1=3Deb2878 a2=3D1000 a3=3D0 items=3D0 pp= > id=3D1435 pid=3D1438 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fs= > uid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 comm=3D"s= > shdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_t:s0 key= > =3D(null) > > type=3DAVC msg=3Daudit(1259802888.379:23): avc: denied { ioctl } for p= > id=3D1438 comm=3D"sshdfilter" path=3D"pipe:[11046]" dev=3Dpipefs ino=3D1104= > 6 scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:i= > ptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802888.379:23): arch=3Dc000003e syscall=3D= > 16 success=3Dyes exit=3D128 a0=3D7 a1=3D5401 a2=3D7fffa8850c80 a3=3D60 item= > s=3D0 ppid=3D1435 pid=3D1438 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 sui= > d=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 c= > omm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_= > t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259802888.379:24): avc: denied { ioctl } for p= > id=3D1438 comm=3D"sshdfilter" path=3D"pipe:[11046]" dev=3Dpipefs ino=3D1104= > 6 scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:i= > ptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802888.379:24): arch=3Dc000003e syscall=3D= > 16 success=3Dyes exit=3D128 a0=3D8 a1=3D5401 a2=3D7fffa8850c80 a3=3D60 item= > s=3D0 ppid=3D1435 pid=3D1438 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 sui= > d=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 c= > omm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_= > t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259802888.384:25): avc: denied { ioctl } for p= > id=3D1442 comm=3D"sshdfilter" path=3D"pipe:[11046]" dev=3Dpipefs ino=3D1104= > 6 scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:i= > ptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802888.384:25): arch=3Dc000003e syscall=3D= > 16 success=3Dyes exit=3D128 a0=3D4 a1=3D5401 a2=3D7fffa8850ba0 a3=3D60 item= > s=3D0 ppid=3D1438 pid=3D1442 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 sui= > d=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 c= > omm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_= > t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259802888.384:26): avc: denied { getattr } for = > pid=3D1442 comm=3D"sshdfilter" path=3D"pipe:[11046]" dev=3Dpipefs ino=3D11= > 046 scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r= > :iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802888.384:26): arch=3Dc000003e syscall=3D= > 5 success=3Dyes exit=3D128 a0=3D4 a1=3Db730a0 a2=3Db730a0 a3=3D0 items=3D0 = > ppid=3D1438 pid=3D1442 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 suid=3D0 = > fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 comm=3D= > "sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_t:s0 k= > ey=3D(null) > > type=3DAVC msg=3Daudit(1259802889.381:27): avc: denied { read } for pi= > d=3D1494 comm=3D"sshdfilter" name=3D"iptables" dev=3Ddm-0 ino=3D11793 scont= > ext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:object_r:bin_t:s0= > tclass=3Dlnk_file > > type=3DSYSCALL msg=3Daudit(1259802889.381:27): arch=3Dc000003e syscall=3D= > 59 success=3Dno exit=3D-13 a0=3D7fffa8850a88 a1=3Deb31c8 a2=3D7fffa88511c0 = > a3=3D7fffa88508d0 items=3D0 ppid=3D1438 pid=3D1494 auid=3D4294967295 uid=3D= > 0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(no= > ne) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsyste= > m_u:system_r:iptables_t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259802889.382:28): avc: denied { write } for p= > id=3D1494 comm=3D"sshdfilter" path=3D"pipe:[11397]" dev=3Dpipefs ino=3D1139= > 7 scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:i= > ptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802889.382:28): arch=3Dc000003e syscall=3D= > 1 success=3Dyes exit=3D128 a0=3D9 a1=3D7fffa8850b0c a2=3D4 a3=3D8 items=3D0= > ppid=3D1438 pid=3D1494 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 suid=3D0= > fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 comm= > =3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_t:s= > 0 key=3D(null) > > type=3DAVC msg=3Daudit(1259802889.385:29): avc: denied { read } for pi= > d=3D1438 comm=3D"sshdfilter" path=3D"pipe:[11397]" dev=3Dpipefs ino=3D11397= > scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:ip= > tables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802889.385:29): arch=3Dc000003e syscall=3D= > 0 success=3Dyes exit=3D128 a0=3D8 a1=3D7fffa8850f18 a2=3D4 a3=3D8 items=3D0= > ppid=3D1 pid=3D1438 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fs= > uid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 comm=3D"s= > shdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_t:s0 key= > =3D(null) > > type=3DAVC msg=3Daudit(1259802889.388:30): avc: denied { write } for p= > id=3D1438 comm=3D"sshdfilter" path=3D"pipe:[11021]" dev=3Dpipefs ino=3D1102= > 1 scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:i= > ptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802889.388:30): arch=3Dc000003e syscall=3D= > 1 success=3Dyes exit=3D128 a0=3D4 a1=3Deb3248 a2=3D9 a3=3D0 items=3D0 ppid= > =3D1 pid=3D1438 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid= > =3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 comm=3D"sshd= > filter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_t:s0 key=3D= > (null) > > type=3DAVC msg=3Daudit(1259802889.390:31): avc: denied { read } for pi= > d=3D1438 comm=3D"sshdfilter" path=3D"pipe:[11046]" dev=3Dpipefs ino=3D11046= > scontext=3Dsystem_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:system_r:ip= > tables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259802889.390:31): arch=3Dc000003e syscall=3D= > 0 success=3Dyes exit=3D128 a0=3D7 a1=3Deb3568 a2=3D400 a3=3Db73010 items=3D= > 0 ppid=3D1 pid=3D1438 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 suid=3D0 f= > suid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 comm=3D"= > sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:iptables_t:s0 ke= > y=3D(null) > > type=3DAVC msg=3Daudit(1259803042.790:43): avc: denied { ioctl } for p= > id=3D2329 comm=3D"sshdfilter" path=3D"pipe:[24498]" dev=3Dpipefs ino=3D2449= > 8 scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sy= > stem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803042.790:43): arch=3Dc000003e syscall=3D= > 16 success=3Dyes exit=3D4294967424 a0=3D3 a1=3D5401 a2=3D7ffffc393e40 a3=3D= > 60 items=3D0 ppid=3D2323 pid=3D2329 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 su= > id=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3Dpts0 ses=3D1 comm=3D"ssh= > dfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 k= > ey=3D(null) > > type=3DAVC msg=3Daudit(1259803042.795:44): avc: denied { ioctl } for p= > id=3D2329 comm=3D"sshdfilter" path=3D"pipe:[24498]" dev=3Dpipefs ino=3D2449= > 8 scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sy= > stem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803042.795:44): arch=3Dc000003e syscall=3D= > 16 success=3Dyes exit=3D4294967424 a0=3D4 a1=3D5401 a2=3D7ffffc393e40 a3=3D= > 60 items=3D0 ppid=3D2323 pid=3D2329 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 su= > id=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3Dpts0 ses=3D1 comm=3D"ssh= > dfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 k= > ey=3D(null) > > type=3DAVC msg=3Daudit(1259803042.798:45): avc: denied { ioctl } for p= > id=3D2332 comm=3D"sshdfilter" path=3D"pipe:[24509]" dev=3Dpipefs ino=3D2450= > 9 scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sy= > stem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DAVC msg=3Daudit(1259803042.801:46): avc: denied { read } for pi= > d=3D2329 comm=3D"sshdfilter" path=3D"pipe:[24498]" dev=3Dpipefs ino=3D24498= > scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sys= > tem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803042.801:46): arch=3Dc000003e syscall=3D= > 0 success=3Dyes exit=3D128 a0=3D3 a1=3D104fb28 a2=3D1000 a3=3D0 items=3D0 p= > pid=3D2323 pid=3D2329 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid= > =3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3Dpts0 ses=3D1 comm=3D"sshdfilter" exe= > =3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 key=3D(null) > > type=3DSYSCALL msg=3Daudit(1259803042.798:45): arch=3Dc000003e syscall=3D= > 16 success=3Dyes exit=3D4294967424 a0=3D5 a1=3D5401 a2=3D7ffffc393e40 a3=3D= > 60 items=3D0 ppid=3D2329 pid=3D2332 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 su= > id=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"s= > shdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0= > key=3D(null) > > type=3DAVC msg=3Daudit(1259803042.804:47): avc: denied { ioctl } for p= > id=3D2332 comm=3D"sshdfilter" path=3D"pipe:[24509]" dev=3Dpipefs ino=3D2450= > 9 scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sy= > stem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803042.804:47): arch=3Dc000003e syscall=3D= > 16 success=3Dyes exit=3D4294967424 a0=3D6 a1=3D5401 a2=3D7ffffc393e40 a3=3D= > 60 items=3D0 ppid=3D2329 pid=3D2332 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 su= > id=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"s= > shdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0= > key=3D(null) > > type=3DAVC msg=3Daudit(1259803042.806:48): avc: denied { read } for pi= > d=3D2333 comm=3D"sshdfilter" path=3D"pipe:[24509]" dev=3Dpipefs ino=3D24509= > scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sys= > tem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DAVC msg=3Daudit(1259803042.812:49): avc: denied { read } for pi= > d=3D2334 comm=3D"sshdfilter" name=3D"sh" dev=3Ddm-0 ino=3D10258 scontext=3D= > unconfined_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:object_r:bin_t:s0 t= > class=3Dlnk_file > > type=3DSYSCALL msg=3Daudit(1259803042.806:48): arch=3Dc000003e syscall=3D= > 0 success=3Dyes exit=3D4294967424 a0=3D5 a1=3D1050268 a2=3D1000 a3=3D0 item= > s=3D0 ppid=3D2332 pid=3D2333 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 = > fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"sshdfilt= > er" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 key=3D= > (null) > > type=3DAVC msg=3Daudit(1259803042.816:50): avc: denied { read } for pi= > d=3D2332 comm=3D"sshdfilter" path=3D"pipe:[24516]" dev=3Dpipefs ino=3D24516= > scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sys= > tem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803042.812:49): arch=3Dc000003e syscall=3D= > 59 success=3Dno exit=3D-13 a0=3D7fceba680e0f a1=3D7ffffc391b70 a2=3D7ffffc3= > 94380 a3=3D7ffffc393990 items=3D0 ppid=3D2332 pid=3D2334 auid=3D1000 uid=3D= > 0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(no= > ne) ses=3D1 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:s= > ystem_r:iptables_t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259803042.816:51): avc: denied { write } for p= > id=3D2334 comm=3D"sshdfilter" path=3D"pipe:[24516]" dev=3Dpipefs ino=3D2451= > 6 scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sy= > stem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803042.816:51): arch=3Dc000003e syscall=3D= > 1 success=3Dyes exit=3D128 a0=3Da a1=3D7ffffc393bcc a2=3D4 a3=3D7ffffc39395= > 0 items=3D0 ppid=3D2332 pid=3D2334 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 sui= > d=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"ss= > hdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 = > key=3D(null) > > type=3DSYSCALL msg=3Daudit(1259803042.816:50): arch=3Dc000003e syscall=3D= > 0 success=3Dyes exit=3D128 a0=3D9 a1=3D7ffffc393e8c a2=3D4 a3=3Dd13830 item= > s=3D0 ppid=3D2329 pid=3D2332 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 = > fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"sshdfilt= > er" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 key=3D= > (null) > > type=3DAVC msg=3Daudit(1259803042.818:52): avc: denied { ioctl } for p= > id=3D2332 comm=3D"sshdfilter" path=3D"pipe:[24515]" dev=3Dpipefs ino=3D2451= > 5 scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sy= > stem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803042.818:52): arch=3Dc000003e syscall=3D= > 16 success=3Dyes exit=3D128 a0=3D7 a1=3D5401 a2=3D7ffffc393be0 a3=3D60 item= > s=3D0 ppid=3D2329 pid=3D2332 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 = > fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"sshdfilt= > er" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 key=3D= > (null) > > type=3DAVC msg=3Daudit(1259803042.818:53): avc: denied { read } for pi= > d=3D2332 comm=3D"sshdfilter" path=3D"pipe:[24515]" dev=3Dpipefs ino=3D24515= > scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sys= > tem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803042.818:53): arch=3Dc000003e syscall=3D= > 0 success=3Dyes exit=3D128 a0=3D7 a1=3D10504b8 a2=3D1000 a3=3D0 items=3D0 p= > pid=3D2329 pid=3D2332 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid= > =3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"sshdfilter" e= > xe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259803042.823:54): avc: denied { read } for pi= > d=3D2335 comm=3D"sshdfilter" name=3D"sh" dev=3Ddm-0 ino=3D10258 scontext=3D= > unconfined_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:object_r:bin_t:s0 t= > class=3Dlnk_file > > type=3DSYSCALL msg=3Daudit(1259803042.823:54): arch=3Dc000003e syscall=3D= > 59 success=3Dno exit=3D-13 a0=3D7fceba680e0f a1=3D7ffffc391b70 a2=3D7ffffc3= > 94380 a3=3D7ffffc393990 items=3D0 ppid=3D2332 pid=3D2335 auid=3D1000 uid=3D= > 0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(no= > ne) ses=3D1 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:s= > ystem_r:iptables_t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259803042.823:55): avc: denied { write } for p= > id=3D2335 comm=3D"sshdfilter" path=3D"pipe:[24518]" dev=3Dpipefs ino=3D2451= > 8 scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sy= > stem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803042.823:55): arch=3Dc000003e syscall=3D= > 1 success=3Dyes exit=3D128 a0=3Da a1=3D7ffffc393bcc a2=3D4 a3=3D8 items=3D0= > ppid=3D2332 pid=3D2335 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid= > =3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"sshdfilter" e= > xe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259803042.828:56): avc: denied { read } for pi= > d=3D2332 comm=3D"sshdfilter" path=3D"pipe:[24518]" dev=3Dpipefs ino=3D24518= > scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sys= > tem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803042.828:56): arch=3Dc000003e syscall=3D= > 0 success=3Dyes exit=3D128 a0=3D9 a1=3D7ffffc393e8c a2=3D4 a3=3D7fceba05a9d= > 0 items=3D0 ppid=3D2329 pid=3D2332 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 sui= > d=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"ss= > hdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 = > key=3D(null) > > type=3DAVC msg=3Daudit(1259803042.828:57): avc: denied { ioctl } for p= > id=3D2332 comm=3D"sshdfilter" path=3D"pipe:[24517]" dev=3Dpipefs ino=3D2451= > 7 scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sy= > stem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803042.828:57): arch=3Dc000003e syscall=3D= > 16 success=3Dyes exit=3D128 a0=3D7 a1=3D5401 a2=3D7ffffc393be0 a3=3D60 item= > s=3D0 ppid=3D2329 pid=3D2332 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 = > fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"sshdfilt= > er" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 key=3D= > (null) > > type=3DAVC msg=3Daudit(1259803042.828:58): avc: denied { read } for pi= > d=3D2332 comm=3D"sshdfilter" path=3D"pipe:[24517]" dev=3Dpipefs ino=3D24517= > scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sys= > tem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803042.828:58): arch=3Dc000003e syscall=3D= > 0 success=3Dyes exit=3D128 a0=3D7 a1=3D1051cc8 a2=3D1000 a3=3D0 items=3D0 p= > pid=3D2329 pid=3D2332 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid= > =3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"sshdfilter" e= > xe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259803042.833:59): avc: denied { ioctl } for p= > id=3D2332 comm=3D"sshdfilter" path=3D"pipe:[24519]" dev=3Dpipefs ino=3D2451= > 9 scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sy= > stem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803042.833:59): arch=3Dc000003e syscall=3D= > 16 success=3Dyes exit=3D128 a0=3D7 a1=3D5401 a2=3D7ffffc393e40 a3=3D60 item= > s=3D0 ppid=3D2329 pid=3D2332 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 = > fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"sshdfilt= > er" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 key=3D= > (null) > > type=3DAVC msg=3Daudit(1259803042.833:60): avc: denied { ioctl } for p= > id=3D2332 comm=3D"sshdfilter" path=3D"pipe:[24519]" dev=3Dpipefs ino=3D2451= > 9 scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sy= > stem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803042.833:60): arch=3Dc000003e syscall=3D= > 16 success=3Dyes exit=3D128 a0=3D8 a1=3D5401 a2=3D7ffffc393e40 a3=3D60 item= > s=3D0 ppid=3D2329 pid=3D2332 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 = > fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"sshdfilt= > er" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 key=3D= > (null) > > type=3DAVC msg=3Daudit(1259803042.834:61): avc: denied { ioctl } for p= > id=3D2336 comm=3D"sshdfilter" path=3D"pipe:[24519]" dev=3Dpipefs ino=3D2451= > 9 scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sy= > stem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803042.834:61): arch=3Dc000003e syscall=3D= > 16 success=3Dyes exit=3D128 a0=3D4 a1=3D5401 a2=3D7ffffc393d60 a3=3D60 item= > s=3D0 ppid=3D2332 pid=3D2336 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 = > fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"sshdfilt= > er" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 key=3D= > (null) > > type=3DAVC msg=3Daudit(1259803042.836:62): avc: denied { getattr } for = > pid=3D2336 comm=3D"sshdfilter" path=3D"pipe:[24519]" dev=3Dpipefs ino=3D24= > 519 scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:= > system_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803042.836:62): arch=3Dc000003e syscall=3D= > 5 success=3Dyes exit=3D128 a0=3D4 a1=3Dd130a0 a2=3Dd130a0 a3=3D0 items=3D0 = > ppid=3D2332 pid=3D2336 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid= > =3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"sshdfilter" e= > xe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259803043.839:63): avc: denied { read } for pi= > d=3D2338 comm=3D"sshdfilter" name=3D"iptables" dev=3Ddm-0 ino=3D11793 scont= > ext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dsystem_u:object_r:bin_= > t:s0 tclass=3Dlnk_file > > type=3DSYSCALL msg=3Daudit(1259803043.839:63): arch=3Dc000003e syscall=3D= > 59 success=3Dno exit=3D-13 a0=3D7ffffc393c48 a1=3D1052638 a2=3D7ffffc394380= > a3=3D7ffffc393a90 items=3D0 ppid=3D2332 pid=3D2338 auid=3D1000 uid=3D0 gid= > =3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) s= > es=3D1 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system= > _r:iptables_t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259803043.840:64): avc: denied { write } for p= > id=3D2338 comm=3D"sshdfilter" path=3D"pipe:[24549]" dev=3Dpipefs ino=3D2454= > 9 scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sy= > stem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803043.840:64): arch=3Dc000003e syscall=3D= > 1 success=3Dyes exit=3D128 a0=3D9 a1=3D7ffffc393ccc a2=3D4 a3=3D8 items=3D0= > ppid=3D2332 pid=3D2338 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid= > =3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"sshdfilter" e= > xe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259803043.844:65): avc: denied { read } for pi= > d=3D2332 comm=3D"sshdfilter" path=3D"pipe:[24549]" dev=3Dpipefs ino=3D24549= > scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sys= > tem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803043.844:65): arch=3Dc000003e syscall=3D= > 0 success=3Dyes exit=3D128 a0=3D8 a1=3D7ffffc3940d8 a2=3D4 a3=3D8 items=3D0= > ppid=3D1 pid=3D2332 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D= > 0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"sshdfilter" exe= > =3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259803043.845:66): avc: denied { write } for p= > id=3D2332 comm=3D"sshdfilter" path=3D"pipe:[24498]" dev=3Dpipefs ino=3D2449= > 8 scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sy= > stem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803043.845:66): arch=3Dc000003e syscall=3D= > 1 success=3Dyes exit=3D128 a0=3D4 a1=3D10526b8 a2=3D9 a3=3D0 items=3D0 ppid= > =3D1 pid=3D2332 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egi= > d=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"sshdfilter" exe=3D"/u= > sr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 key=3D(null) > > type=3DAVC msg=3Daudit(1259803043.849:67): avc: denied { read } for pi= > d=3D2332 comm=3D"sshdfilter" path=3D"pipe:[24519]" dev=3Dpipefs ino=3D24519= > scontext=3Dunconfined_u:system_r:iptables_t:s0 tcontext=3Dunconfined_u:sys= > tem_r:iptables_t:s0 tclass=3Dfifo_file > > type=3DSYSCALL msg=3Daudit(1259803043.849:67): arch=3Dc000003e syscall=3D= > 0 success=3Dyes exit=3D128 a0=3D7 a1=3D10529d8 a2=3D400 a3=3Dd13010 items= > =3D0 ppid=3D1 pid=3D2332 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fsui= > d=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D1 comm=3D"sshdfilter" = > exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system_r:iptables_t:s0 key=3D(nul= > l) > > type=3DAVC msg=3Daudit(1259803128.077:69): avc: denied { execute } for = > pid=3D2422 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D11= > 798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsyste= > m_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259803128.077:69): arch=3Dc000003e syscall=3D= > 59 success=3Dno exit=3D-13 a0=3D7fff14469168 a1=3D1c20208 a2=3D7fff144698a0= > a3=3D7fff14468fb0 items=3D0 ppid=3D2413 pid=3D2422 auid=3D1000 uid=3D0 gid= > =3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) s= > es=3D1 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system= > _r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259806154.170:82): avc: denied { execute } for = > pid=3D2653 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino=3D11= > 798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsyste= > m_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259806154.170:82): arch=3Dc000003e syscall=3D= > 59 success=3Dno exit=3D-13 a0=3D7fff14469168 a1=3D1c267e8 a2=3D7fff144698a0= > a3=3D7fff14468fb0 items=3D0 ppid=3D2413 pid=3D2653 auid=3D1000 uid=3D0 gid= > =3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) s= > es=3D1 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system= > _r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259812687.066:113): avc: denied { read open } f= > or pid=3D3074 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino= > =3D11798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3D= > system_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259812687.066:113): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff14469168 a1=3D1c26a88 a2=3D7fff14469= > 8a0 a3=3D7fff14468fb0 items=3D0 ppid=3D2413 pid=3D3074 auid=3D1000 uid=3D0 = > gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none= > ) ses=3D1 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:sys= > tem_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259816690.197:196): avc: denied { read open } f= > or pid=3D3631 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino= > =3D11798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3D= > system_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259816690.197:196): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff15c5a888 a1=3D24095a8 a2=3D7fff15c5a= > fc0 a3=3D7fff15c5a6d0 items=3D0 ppid=3D3622 pid=3D3631 auid=3D0 uid=3D0 gid= > =3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) s= > es=3D9 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system= > _r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259819529.773:214): avc: denied { read open } f= > or pid=3D3827 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino= > =3D11798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3D= > system_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259819529.773:214): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff15c5a888 a1=3D2410198 a2=3D7fff15c5a= > fc0 a3=3D7fff15c5a6d0 items=3D0 ppid=3D3622 pid=3D3827 auid=3D0 uid=3D0 gid= > =3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) s= > es=3D9 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:system= > _r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259899887.509:471): avc: denied { read open } f= > or pid=3D11794 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino= > =3D11798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3D= > system_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259899887.509:471): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff15c5a888 a1=3D2410198 a2=3D7fff15c5a= > fc0 a3=3D7fff15c5a6d0 items=3D0 ppid=3D3622 pid=3D11794 auid=3D0 uid=3D0 gi= > d=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) = > ses=3D9 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:syste= > m_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259899890.409:475): avc: denied { read open } f= > or pid=3D11799 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino= > =3D11798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3D= > system_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259899890.409:475): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff15c5a888 a1=3D2410548 a2=3D7fff15c5a= > fc0 a3=3D7fff15c5a6d0 items=3D0 ppid=3D3622 pid=3D11799 auid=3D0 uid=3D0 gi= > d=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) = > ses=3D9 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:syste= > m_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1259899950.600:483): avc: denied { read open } f= > or pid=3D11860 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino= > =3D11798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3D= > system_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1259899950.600:483): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff9722f198 a1=3Df6e208 a2=3D7fff9722f8= > d0 a3=3D7fff9722efe0 items=3D0 ppid=3D11851 pid=3D11860 auid=3D0 uid=3D0 gi= > d=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) = > ses=3D44 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:syst= > em_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1260146847.427:1066): avc: denied { read open } = > for pid=3D28420 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino= > =3D11798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3D= > system_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1260146847.427:1066): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff9722f198 a1=3Df71c88 a2=3D7fff9722f8= > d0 a3=3D7fff9722efe0 items=3D0 ppid=3D11851 pid=3D28420 auid=3D0 uid=3D0 gi= > d=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) = > ses=3D44 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:syst= > em_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1260146850.722:1070): avc: denied { read open } = > for pid=3D28428 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 ino= > =3D11798 scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3D= > system_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1260146850.722:1070): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff9722f198 a1=3Df72a28 a2=3D7fff9722f8= > d0 a3=3D7fff9722efe0 items=3D0 ppid=3D11851 pid=3D28428 auid=3D0 uid=3D0 gi= > d=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) = > ses=3D44 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dunconfined_u:syst= > em_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1260500225.789:25455): avc: denied { read open }= > for pid=3D21350 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 in= > o=3D11798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsys= > tem_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1260500225.789:25455): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff032b96b8 a1=3Dbdbd18 a2=3D7fff032b9d= > f0 a3=3D7fff032b9500 items=3D0 ppid=3D1441 pid=3D21350 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1260500228.740:25459): avc: denied { read open }= > for pid=3D21355 comm=3D"sshdfilter" name=3D"iptables-multi" dev=3Ddm-0 in= > o=3D11798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=3Dsys= > tem_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1260500228.740:25459): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fff032b96b8 a1=3Dbddc38 a2=3D7fff032b9d= > f0 a3=3D7fff032b9500 items=3D0 ppid=3D1441 pid=3D21355 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1260500358.675:25470): avc: denied { getattr } f= > or pid=3D1441 comm=3D"sshdfilter" path=3D"/var/run/sshdfilter.pid.SSHD" de= > v=3Ddm-0 ino=3D10948 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 tco= > ntext=3Dsystem_u:object_r:var_run_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1260500358.675:25470): arch=3Dc000003e syscall= > =3D6 success=3Dno exit=3D-13 a0=3Dbd5dd8 a1=3D8980a0 a2=3D8980a0 a3=3D7fff0= > 32b9880 items=3D0 ppid=3D1 pid=3D1441 auid=3D4294967295 uid=3D0 gid=3D0 eui= > d=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D429= > 4967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj=3Dsystem_u:system_r:= > sshd_t:s0-s0:c0.c1023 key=3D(null) > > type=3DAVC msg=3Daudit(1260809448.592:28614): avc: denied { execute_no_= > trans } for pid=3D23422 comm=3D"sshdfilter" path=3D"/sbin/iptables-multi" = > dev=3Ddm-0 ino=3D11798 scontext=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 t= > context=3Dsystem_u:object_r:iptables_exec_t:s0 tclass=3Dfile > > type=3DSYSCALL msg=3Daudit(1260809448.592:28614): arch=3Dc000003e syscall= > =3D59 success=3Dno exit=3D-13 a0=3D7fffc0880288 a1=3De0c508 a2=3D7fffc08809= > c0 a3=3D7fffc08800d0 items=3D0 ppid=3D1432 pid=3D23422 auid=3D4294967295 ui= > d=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty= > =3D(none) ses=3D4294967295 comm=3D"sshdfilter" exe=3D"/usr/bin/perl" subj= > =3Dsystem_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null) > >=20 > > > >=3D20 > > > >=3D20 > > > > Moray. > > > > "To err is human. To purr, feline" > > > >=3D20 > > > >=3D20 > > > > -- > > > > fedora-selinux-list mailing list > > > > fedora-selinux-list at redhat.com > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > >=20 > > > --uAKRQypu60I7Lcqm > > > Content-Type: application/pgp-signature > > > Content-Disposition: inline > > >=20 > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1.4.10 (GNU/Linux) > > >=20 > > > iEYEARECAAYFAksdZWwACgkQMlxVo39jgT/olgCgwo9wvxeAyJG/gm4dEYHBIpGf > > > TNEAn2bFoQZeg8+gaYPIDuB0wxuu6N8F > > > =3DtNuu > > > -----END PGP SIGNATURE----- > > >=20 > > > --uAKRQypu60I7Lcqm-- > > >=20 > > >=20 > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0725889959=3D=3D > > > Content-Type: text/plain; charset=3D"us-ascii" > > > MIME-Version: 1.0 > > > Content-Transfer-Encoding: 7bit > > > Content-Disposition: inline > > >=20 > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0725889959=3D=3D-- > > >=20 > >=20 > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > --2B/JsCI69OhZNC5r > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAksmr6kACgkQMlxVo39jgT9jLQCghHyybd+FAVhKuaco96Y0PkNV > VlcAnjcN8KmKKFlL5jFAWI5/US7VJmoB > =HL4+ > -----END PGP SIGNATURE----- > > --2B/JsCI69OhZNC5r-- > > > --===============1736741946== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > --===============1736741946==-- > From dhighley at highley-recommended.com Tue Dec 15 00:21:41 2009 From: dhighley at highley-recommended.com (David Highley) Date: Mon, 14 Dec 2009 16:21:41 -0800 (PST) Subject: Fedora 12 and unconfined_u sshdfilter In-Reply-To: <20091214212104.GA23680@localhost.localdomain> Message-ID: <200912150021.nBF0Lf5a030601@douglas.highley-recommended.com> "Dominick Grift wrote:" > > > --===============1862406356== > Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" > Content-Disposition: inline > > > --AhhlLboLdkugWU4S > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Mon, Dec 14, 2009 at 10:25:08AM -0800, David Highley wrote: > > "Dominick Grift wrote:" > > >=20 > > >=20 > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0725889959=3D=3D > > > Content-Type: multipart/signed; micalg=3Dpgp-sha1; > > > protocol=3D"application/pgp-signature"; boundary=3D"uAKRQypu60I7Lcqm" > > > Content-Disposition: inline > > >=20 > > >=20 > > > --uAKRQypu60I7Lcqm > > > Content-Type: text/plain; charset=3Dutf-8 > > > Content-Disposition: inline > > > Content-Transfer-Encoding: quoted-printable > > >=20 > > > On Mon, Dec 07, 2009 at 12:01:09PM +0000, Moray Henderson (ICT) wrote: > > > > James Carter wrote: > > > > >Dan's example used Refpolicy interfaces. Interfaces are very useful= > and > > > > >provide a better layer of abstraction, but they are just m4 macros, > > > > >which have always been used in SELinux policy. > > > > > > > > > >Interfaces should be used as much as possible, but it is not true th= > at > > > > >you can't mix the old and new ways. > > > >=3D20 > > > > Mixing the plain rules and the m4 macros didn't work when I tried it = > - bu=3D > > > t perhaps I just wasn=3DE2=3D80=3D99t writing it right. Is there a Ref= > policy tut=3D > > > orial anywhere? > > >=20 > > > I spend a little time today writing about the policy structure in Fedor= > a. M=3D > > > aybe it can help you or others: > > >=20 > > > http://82.197.205.60/~dgrift/stuff/Managing_a_SELinux_environment_with_= > Fedo=3D > > > ra_12.pdf > >=20 > >=20 > > Still have not mastered this one yet. Here is the policy file created by > > grep of /var/log/audit/audit.log file piped to audit2allow: > >=20 > > module mysshdfilter 1.0; > >=20 > > require { > > type var_run_t; > > type iptables_exec_t; > > type bin_t; > > type sshd_t; > > type iptables_t; > > class lnk_file read; > > class file { read getattr open execute execute_no_trans }; > > class fifo_file { read write ioctl getattr }; > > } > >=20 > > #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D iptables_t =3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D > > allow iptables_t bin_t:lnk_file read; > > allow iptables_t self:fifo_file { read write ioctl getattr }; > > echo "policy_module(newiptables, 1.0.0)" > newuiptables.te > echo "optional_policy(\`" >> newiptables.te > echo "gen_require(\'" >> newiptables.te > echo "type iptables_t;" >> newiptables.te > echo "')" >> newiptables.te > echo "corecmd_read_bin_symlinks(iptables_t)" >> newiptables.te > echo "allow iptables_t self:fifo_file rw_fifo_file_perms;" >> newiptables.te > echo "')" >> newiptables.te > > make -f /usr/share/selinux/devel/Makefile newiptables.pp > sudo semodule -i newiptables.pp > > >=20 > > #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sshd_t =3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D > > allow sshd_t iptables_exec_t:file { read execute open execute_no_trans }; > > echo "policy_module(newsshd, 1.0.0)" > newsshd.te > echo "optional_policy(\`" >> newsshd.te > echo "gen_require(\`" >> newsshd.te > echo "type sshd_t;" >> newsshd.te > echo "')" >> newsshd.te > echo "iptables_domtrans(sshd_t)" >> newsshd.te > echo "')" >> newsshd.te > > make -f /usr/share/selinux/devel/Makefile newsshd.pp > sudo semodule -i newsshd.pp > > > allow sshd_t var_run_t:file getattr; > > This one is a bit more complicated because i dont know for sure what create= > d it (in what context runs sshdfilter?) > >=20 I also ment to ask if all three policy; mysshdfilter.pp, newiptables.pp, and newsshd.pp; changes are needed? > >=20 > > > >=3D20 > > > >=3D20 > > > > Moray. > > > > "To err is human. To purr, feline" > > > >=3D20 > > > >=3D20 > > > > -- > > > > fedora-selinux-list mailing list > > > > fedora-selinux-list at redhat.com > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > >=20 > > > --uAKRQypu60I7Lcqm > > > Content-Type: application/pgp-signature > > > Content-Disposition: inline > > >=20 > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1.4.10 (GNU/Linux) > > >=20 > > > iEYEARECAAYFAksdZWwACgkQMlxVo39jgT/olgCgwo9wvxeAyJG/gm4dEYHBIpGf > > > TNEAn2bFoQZeg8+gaYPIDuB0wxuu6N8F > > > =3DtNuu > > > -----END PGP SIGNATURE----- > > >=20 > > > --uAKRQypu60I7Lcqm-- > > >=20 > > >=20 > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0725889959=3D=3D > > > Content-Type: text/plain; charset=3D"us-ascii" > > > MIME-Version: 1.0 > > > Content-Transfer-Encoding: 7bit > > > Content-Disposition: inline > > >=20 > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0725889959=3D=3D-- > > >=20 > >=20 > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > --AhhlLboLdkugWU4S > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAksmrEAACgkQMlxVo39jgT/UPwCfexQ3gHxMcD3IFrFCeLSmqrQK > 1wQAn1TK0UM7xl0MqMFwQbeBb6qr+cst > =b5GU > -----END PGP SIGNATURE----- > > --AhhlLboLdkugWU4S-- > > > --===============1862406356== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > --===============1862406356==-- > From dhighley at highley-recommended.com Tue Dec 15 00:50:15 2009 From: dhighley at highley-recommended.com (David Highley) Date: Mon, 14 Dec 2009 16:50:15 -0800 (PST) Subject: Fedora 12 and unconfined_u sshdfilter In-Reply-To: <200912150021.nBF0Lf5a030601@douglas.highley-recommended.com> Message-ID: <200912150050.nBF0oFIr030957@douglas.highley-recommended.com> "David Highley wrote:" > > "Dominick Grift wrote:" > > > > > > --===============1862406356== > > Content-Type: multipart/signed; micalg=pgp-sha1; > > protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" > > Content-Disposition: inline > > > > > > --AhhlLboLdkugWU4S > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > > > > On Mon, Dec 14, 2009 at 10:25:08AM -0800, David Highley wrote: > > > "Dominick Grift wrote:" > > > >=20 > > > >=20 > > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0725889959=3D=3D > > > > Content-Type: multipart/signed; micalg=3Dpgp-sha1; > > > > protocol=3D"application/pgp-signature"; boundary=3D"uAKRQypu60I7Lcqm" > > > > Content-Disposition: inline > > > >=20 > > > >=20 > > > > --uAKRQypu60I7Lcqm > > > > Content-Type: text/plain; charset=3Dutf-8 > > > > Content-Disposition: inline > > > > Content-Transfer-Encoding: quoted-printable > > > >=20 > > > > On Mon, Dec 07, 2009 at 12:01:09PM +0000, Moray Henderson (ICT) wrote: > > > > > James Carter wrote: > > > > > >Dan's example used Refpolicy interfaces. Interfaces are very useful= > > and > > > > > >provide a better layer of abstraction, but they are just m4 macros, > > > > > >which have always been used in SELinux policy. > > > > > > > > > > > >Interfaces should be used as much as possible, but it is not true th= > > at > > > > > >you can't mix the old and new ways. > > > > >=3D20 > > > > > Mixing the plain rules and the m4 macros didn't work when I tried it = > > - bu=3D > > > > t perhaps I just wasn=3DE2=3D80=3D99t writing it right. Is there a Ref= > > policy tut=3D > > > > orial anywhere? > > > >=20 > > > > I spend a little time today writing about the policy structure in Fedor= > > a. M=3D > > > > aybe it can help you or others: > > > >=20 > > > > http://82.197.205.60/~dgrift/stuff/Managing_a_SELinux_environment_with_= > > Fedo=3D > > > > ra_12.pdf > > >=20 > > >=20 > > > Still have not mastered this one yet. Here is the policy file created by > > > grep of /var/log/audit/audit.log file piped to audit2allow: > > >=20 > > > module mysshdfilter 1.0; > > >=20 > > > require { > > > type var_run_t; > > > type iptables_exec_t; > > > type bin_t; > > > type sshd_t; > > > type iptables_t; > > > class lnk_file read; > > > class file { read getattr open execute execute_no_trans }; > > > class fifo_file { read write ioctl getattr }; > > > } > > >=20 > > > #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D iptables_t =3D=3D=3D=3D=3D=3D=3D= > > =3D=3D=3D=3D=3D=3D=3D > > > allow iptables_t bin_t:lnk_file read; > > > allow iptables_t self:fifo_file { read write ioctl getattr }; > > > > echo "policy_module(newiptables, 1.0.0)" > newuiptables.te > > echo "optional_policy(\`" >> newiptables.te > > echo "gen_require(\'" >> newiptables.te > > echo "type iptables_t;" >> newiptables.te > > echo "')" >> newiptables.te > > echo "corecmd_read_bin_symlinks(iptables_t)" >> newiptables.te > > echo "allow iptables_t self:fifo_file rw_fifo_file_perms;" >> newiptables.te > > echo "')" >> newiptables.te > > > > make -f /usr/share/selinux/devel/Makefile newiptables.pp Running the make for the above file ended up in an infinit loop outputing: myiptables.te:2: Warning: deprecated use of module name () as first parameter of optional_policy() block. > > sudo semodule -i newiptables.pp > > > > >=20 > > > #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sshd_t =3D=3D=3D=3D=3D=3D=3D=3D= > > =3D=3D=3D=3D=3D=3D > > > allow sshd_t iptables_exec_t:file { read execute open execute_no_trans }; > > > > echo "policy_module(newsshd, 1.0.0)" > newsshd.te > > echo "optional_policy(\`" >> newsshd.te > > echo "gen_require(\`" >> newsshd.te > > echo "type sshd_t;" >> newsshd.te > > echo "')" >> newsshd.te > > echo "iptables_domtrans(sshd_t)" >> newsshd.te > > echo "')" >> newsshd.te > > > > make -f /usr/share/selinux/devel/Makefile newsshd.pp > > sudo semodule -i newsshd.pp > > > > > allow sshd_t var_run_t:file getattr; > > > > This one is a bit more complicated because i dont know for sure what create= > > d it (in what context runs sshdfilter?) > > >=20 > > I also ment to ask if all three policy; mysshdfilter.pp, newiptables.pp, > and newsshd.pp; changes are needed? > > > > > >=20 > > > > >=3D20 > > > > >=3D20 > > > > > Moray. > > > > > "To err is human. To purr, feline" > > > > >=3D20 > > > > >=3D20 > > > > > -- > > > > > fedora-selinux-list mailing list > > > > > fedora-selinux-list at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > >=20 > > > > --uAKRQypu60I7Lcqm > > > > Content-Type: application/pgp-signature > > > > Content-Disposition: inline > > > >=20 > > > > -----BEGIN PGP SIGNATURE----- > > > > Version: GnuPG v1.4.10 (GNU/Linux) > > > >=20 > > > > iEYEARECAAYFAksdZWwACgkQMlxVo39jgT/olgCgwo9wvxeAyJG/gm4dEYHBIpGf > > > > TNEAn2bFoQZeg8+gaYPIDuB0wxuu6N8F > > > > =3DtNuu > > > > -----END PGP SIGNATURE----- > > > >=20 > > > > --uAKRQypu60I7Lcqm-- > > > >=20 > > > >=20 > > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0725889959=3D=3D > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > MIME-Version: 1.0 > > > > Content-Transfer-Encoding: 7bit > > > > Content-Disposition: inline > > > >=20 > > > > -- > > > > fedora-selinux-list mailing list > > > > fedora-selinux-list at redhat.com > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0725889959=3D=3D-- > > > >=20 > > >=20 > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > --AhhlLboLdkugWU4S > > Content-Type: application/pgp-signature > > Content-Disposition: inline > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.10 (GNU/Linux) > > > > iEYEARECAAYFAksmrEAACgkQMlxVo39jgT/UPwCfexQ3gHxMcD3IFrFCeLSmqrQK > > 1wQAn1TK0UM7xl0MqMFwQbeBb6qr+cst > > =b5GU > > -----END PGP SIGNATURE----- > > > > --AhhlLboLdkugWU4S-- > > > > > > --===============1862406356== > > Content-Type: text/plain; charset="us-ascii" > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > --===============1862406356==-- > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From domg472 at gmail.com Tue Dec 15 08:52:28 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 15 Dec 2009 09:52:28 +0100 Subject: Fedora 12 and unconfined_u sshdfilter In-Reply-To: <200912150050.nBF0oFIr030957@douglas.highley-recommended.com> References: <200912150021.nBF0Lf5a030601@douglas.highley-recommended.com> <200912150050.nBF0oFIr030957@douglas.highley-recommended.com> Message-ID: <20091215085226.GA31913@localhost.localdomain> On Mon, Dec 14, 2009 at 04:50:15PM -0800, David Highley wrote: > "David Highley wrote:" > > > > "Dominick Grift wrote:" > > > > > > > > > --===============1862406356== > > > Content-Type: multipart/signed; micalg=pgp-sha1; > > > protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" > > > Content-Disposition: inline > > > > > > > > > --AhhlLboLdkugWU4S > > > Content-Type: text/plain; charset=us-ascii > > > Content-Disposition: inline > > > Content-Transfer-Encoding: quoted-printable > > > > > > On Mon, Dec 14, 2009 at 10:25:08AM -0800, David Highley wrote: > > > > "Dominick Grift wrote:" > > > > >=20 > > > > >=20 > > > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0725889959=3D=3D > > > > > Content-Type: multipart/signed; micalg=3Dpgp-sha1; > > > > > protocol=3D"application/pgp-signature"; boundary=3D"uAKRQypu60I7Lcqm" > > > > > Content-Disposition: inline > > > > >=20 > > > > >=20 > > > > > --uAKRQypu60I7Lcqm > > > > > Content-Type: text/plain; charset=3Dutf-8 > > > > > Content-Disposition: inline > > > > > Content-Transfer-Encoding: quoted-printable > > > > >=20 > > > > > On Mon, Dec 07, 2009 at 12:01:09PM +0000, Moray Henderson (ICT) wrote: > > > > > > James Carter wrote: > > > > > > >Dan's example used Refpolicy interfaces. Interfaces are very useful= > > > and > > > > > > >provide a better layer of abstraction, but they are just m4 macros, > > > > > > >which have always been used in SELinux policy. > > > > > > > > > > > > > >Interfaces should be used as much as possible, but it is not true th= > > > at > > > > > > >you can't mix the old and new ways. > > > > > >=3D20 > > > > > > Mixing the plain rules and the m4 macros didn't work when I tried it = > > > - bu=3D > > > > > t perhaps I just wasn=3DE2=3D80=3D99t writing it right. Is there a Ref= > > > policy tut=3D > > > > > orial anywhere? > > > > >=20 > > > > > I spend a little time today writing about the policy structure in Fedor= > > > a. M=3D > > > > > aybe it can help you or others: > > > > >=20 > > > > > http://82.197.205.60/~dgrift/stuff/Managing_a_SELinux_environment_with_= > > > Fedo=3D > > > > > ra_12.pdf > > > >=20 > > > >=20 > > > > Still have not mastered this one yet. Here is the policy file created by > > > > grep of /var/log/audit/audit.log file piped to audit2allow: > > > >=20 > > > > module mysshdfilter 1.0; > > > >=20 > > > > require { > > > > type var_run_t; > > > > type iptables_exec_t; > > > > type bin_t; > > > > type sshd_t; > > > > type iptables_t; > > > > class lnk_file read; > > > > class file { read getattr open execute execute_no_trans }; > > > > class fifo_file { read write ioctl getattr }; > > > > } > > > >=20 > > > > #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D iptables_t =3D=3D=3D=3D=3D=3D=3D= > > > =3D=3D=3D=3D=3D=3D=3D > > > > allow iptables_t bin_t:lnk_file read; > > > > allow iptables_t self:fifo_file { read write ioctl getattr }; > > > > > > echo "policy_module(newiptables, 1.0.0)" > newuiptables.te > > > echo "optional_policy(\`" >> newiptables.te > > > echo "gen_require(\'" >> newiptables.te > > > echo "type iptables_t;" >> newiptables.te > > > echo "')" >> newiptables.te > > > echo "corecmd_read_bin_symlinks(iptables_t)" >> newiptables.te > > > echo "allow iptables_t self:fifo_file rw_fifo_file_perms;" >> newiptables.te > > > echo "')" >> newiptables.te > > > > > > make -f /usr/share/selinux/devel/Makefile newiptables.pp > > Running the make for the above file ended up in an infinit loop > outputing: > myiptables.te:2: Warning: deprecated use of module name () as first > parameter of optional_policy() block. Theres a syntax error or two: > > > echo "policy_module(newiptables, 1.0.0)" > newuiptables.te echo "policy_module(newiptables, 1.0.0)" > newiptables.te > > > echo "gen_require(\'" >> newiptables.te echo "gen_require(\`" >> newiptables.te > > > > sudo semodule -i newiptables.pp > > > > > > >=20 > > > > #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sshd_t =3D=3D=3D=3D=3D=3D=3D=3D= > > > =3D=3D=3D=3D=3D=3D > > > > allow sshd_t iptables_exec_t:file { read execute open execute_no_trans }; > > > > > > echo "policy_module(newsshd, 1.0.0)" > newsshd.te > > > echo "optional_policy(\`" >> newsshd.te > > > echo "gen_require(\`" >> newsshd.te > > > echo "type sshd_t;" >> newsshd.te > > > echo "')" >> newsshd.te > > > echo "iptables_domtrans(sshd_t)" >> newsshd.te > > > echo "')" >> newsshd.te > > > > > > make -f /usr/share/selinux/devel/Makefile newsshd.pp > > > sudo semodule -i newsshd.pp > > > > > > > allow sshd_t var_run_t:file getattr; > > > > > > This one is a bit more complicated because i dont know for sure what create= > > > d it (in what context runs sshdfilter?) > > > >=20 > > > > I also ment to ask if all three policy; mysshdfilter.pp, newiptables.pp, > > and newsshd.pp; changes are needed? > > > > > > > > > >=20 > > > > > >=3D20 > > > > > >=3D20 > > > > > > Moray. > > > > > > "To err is human. To purr, feline" > > > > > >=3D20 > > > > > >=3D20 > > > > > > -- > > > > > > fedora-selinux-list mailing list > > > > > > fedora-selinux-list at redhat.com > > > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > >=20 > > > > > --uAKRQypu60I7Lcqm > > > > > Content-Type: application/pgp-signature > > > > > Content-Disposition: inline > > > > >=20 > > > > > -----BEGIN PGP SIGNATURE----- > > > > > Version: GnuPG v1.4.10 (GNU/Linux) > > > > >=20 > > > > > iEYEARECAAYFAksdZWwACgkQMlxVo39jgT/olgCgwo9wvxeAyJG/gm4dEYHBIpGf > > > > > TNEAn2bFoQZeg8+gaYPIDuB0wxuu6N8F > > > > > =3DtNuu > > > > > -----END PGP SIGNATURE----- > > > > >=20 > > > > > --uAKRQypu60I7Lcqm-- > > > > >=20 > > > > >=20 > > > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0725889959=3D=3D > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > MIME-Version: 1.0 > > > > > Content-Transfer-Encoding: 7bit > > > > > Content-Disposition: inline > > > > >=20 > > > > > -- > > > > > fedora-selinux-list mailing list > > > > > fedora-selinux-list at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0725889959=3D=3D-- > > > > >=20 > > > >=20 > > > > -- > > > > fedora-selinux-list mailing list > > > > fedora-selinux-list at redhat.com > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > --AhhlLboLdkugWU4S > > > Content-Type: application/pgp-signature > > > Content-Disposition: inline > > > > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1.4.10 (GNU/Linux) > > > > > > iEYEARECAAYFAksmrEAACgkQMlxVo39jgT/UPwCfexQ3gHxMcD3IFrFCeLSmqrQK > > > 1wQAn1TK0UM7xl0MqMFwQbeBb6qr+cst > > > =b5GU > > > -----END PGP SIGNATURE----- > > > > > > --AhhlLboLdkugWU4S-- > > > > > > > > > --===============1862406356== > > > Content-Type: text/plain; charset="us-ascii" > > > MIME-Version: 1.0 > > > Content-Transfer-Encoding: 7bit > > > Content-Disposition: inline > > > > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > --===============1862406356==-- > > > > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Tue Dec 15 08:55:59 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 15 Dec 2009 09:55:59 +0100 Subject: Fedora 12 and unconfined_u sshdfilter In-Reply-To: <200912150021.nBF0Lf5a030601@douglas.highley-recommended.com> References: <20091214212104.GA23680@localhost.localdomain> <200912150021.nBF0Lf5a030601@douglas.highley-recommended.com> Message-ID: <20091215085558.GB31913@localhost.localdomain> On Mon, Dec 14, 2009 at 04:21:41PM -0800, David Highley wrote: > "Dominick Grift wrote:" > > > > > > --===============1862406356== > > Content-Type: multipart/signed; micalg=pgp-sha1; > > protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" > > Content-Disposition: inline > > > > > > --AhhlLboLdkugWU4S > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > > > > On Mon, Dec 14, 2009 at 10:25:08AM -0800, David Highley wrote: > > > "Dominick Grift wrote:" > > > >=20 > > > >=20 > > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0725889959=3D=3D > > > > Content-Type: multipart/signed; micalg=3Dpgp-sha1; > > > > protocol=3D"application/pgp-signature"; boundary=3D"uAKRQypu60I7Lcqm" > > > > Content-Disposition: inline > > > >=20 > > > >=20 > > > > --uAKRQypu60I7Lcqm > > > > Content-Type: text/plain; charset=3Dutf-8 > > > > Content-Disposition: inline > > > > Content-Transfer-Encoding: quoted-printable > > > >=20 > > > > On Mon, Dec 07, 2009 at 12:01:09PM +0000, Moray Henderson (ICT) wrote: > > > > > James Carter wrote: > > > > > >Dan's example used Refpolicy interfaces. Interfaces are very useful= > > and > > > > > >provide a better layer of abstraction, but they are just m4 macros, > > > > > >which have always been used in SELinux policy. > > > > > > > > > > > >Interfaces should be used as much as possible, but it is not true th= > > at > > > > > >you can't mix the old and new ways. > > > > >=3D20 > > > > > Mixing the plain rules and the m4 macros didn't work when I tried it = > > - bu=3D > > > > t perhaps I just wasn=3DE2=3D80=3D99t writing it right. Is there a Ref= > > policy tut=3D > > > > orial anywhere? > > > >=20 > > > > I spend a little time today writing about the policy structure in Fedor= > > a. M=3D > > > > aybe it can help you or others: > > > >=20 > > > > http://82.197.205.60/~dgrift/stuff/Managing_a_SELinux_environment_with_= > > Fedo=3D > > > > ra_12.pdf > > >=20 > > >=20 > > > Still have not mastered this one yet. Here is the policy file created by > > > grep of /var/log/audit/audit.log file piped to audit2allow: > > >=20 > > > module mysshdfilter 1.0; > > >=20 > > > require { > > > type var_run_t; > > > type iptables_exec_t; > > > type bin_t; > > > type sshd_t; > > > type iptables_t; > > > class lnk_file read; > > > class file { read getattr open execute execute_no_trans }; > > > class fifo_file { read write ioctl getattr }; > > > } > > >=20 > > > #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D iptables_t =3D=3D=3D=3D=3D=3D=3D= > > =3D=3D=3D=3D=3D=3D=3D > > > allow iptables_t bin_t:lnk_file read; > > > allow iptables_t self:fifo_file { read write ioctl getattr }; > > > > echo "policy_module(newiptables, 1.0.0)" > newuiptables.te > > echo "optional_policy(\`" >> newiptables.te > > echo "gen_require(\'" >> newiptables.te > > echo "type iptables_t;" >> newiptables.te > > echo "')" >> newiptables.te > > echo "corecmd_read_bin_symlinks(iptables_t)" >> newiptables.te > > echo "allow iptables_t self:fifo_file rw_fifo_file_perms;" >> newiptables.te > > echo "')" >> newiptables.te > > > > make -f /usr/share/selinux/devel/Makefile newiptables.pp > > sudo semodule -i newiptables.pp > > > > >=20 > > > #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sshd_t =3D=3D=3D=3D=3D=3D=3D=3D= > > =3D=3D=3D=3D=3D=3D > > > allow sshd_t iptables_exec_t:file { read execute open execute_no_trans }; > > > > echo "policy_module(newsshd, 1.0.0)" > newsshd.te > > echo "optional_policy(\`" >> newsshd.te > > echo "gen_require(\`" >> newsshd.te > > echo "type sshd_t;" >> newsshd.te > > echo "')" >> newsshd.te > > echo "iptables_domtrans(sshd_t)" >> newsshd.te > > echo "')" >> newsshd.te > > > > make -f /usr/share/selinux/devel/Makefile newsshd.pp > > sudo semodule -i newsshd.pp > > > > > allow sshd_t var_run_t:file getattr; > > > > This one is a bit more complicated because i dont know for sure what create= > > d it (in what context runs sshdfilter?) > > >=20 The two policy modules above try to fix the avc denials above. if you do not have mysshdfilter.pp installed then there is no need to install it now. But we do need to find a solution for the remaining avc denial that either of the two enclosed policy modules above do not fix. > > I also ment to ask if all three policy; mysshdfilter.pp, newiptables.pp, > and newsshd.pp; changes are needed? > > > > > >=20 > > > > >=3D20 > > > > >=3D20 > > > > > Moray. > > > > > "To err is human. To purr, feline" > > > > >=3D20 > > > > >=3D20 > > > > > -- > > > > > fedora-selinux-list mailing list > > > > > fedora-selinux-list at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > >=20 > > > > --uAKRQypu60I7Lcqm > > > > Content-Type: application/pgp-signature > > > > Content-Disposition: inline > > > >=20 > > > > -----BEGIN PGP SIGNATURE----- > > > > Version: GnuPG v1.4.10 (GNU/Linux) > > > >=20 > > > > iEYEARECAAYFAksdZWwACgkQMlxVo39jgT/olgCgwo9wvxeAyJG/gm4dEYHBIpGf > > > > TNEAn2bFoQZeg8+gaYPIDuB0wxuu6N8F > > > > =3DtNuu > > > > -----END PGP SIGNATURE----- > > > >=20 > > > > --uAKRQypu60I7Lcqm-- > > > >=20 > > > >=20 > > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0725889959=3D=3D > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > MIME-Version: 1.0 > > > > Content-Transfer-Encoding: 7bit > > > > Content-Disposition: inline > > > >=20 > > > > -- > > > > fedora-selinux-list mailing list > > > > fedora-selinux-list at redhat.com > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0725889959=3D=3D-- > > > >=20 > > >=20 > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > --AhhlLboLdkugWU4S > > Content-Type: application/pgp-signature > > Content-Disposition: inline > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.10 (GNU/Linux) > > > > iEYEARECAAYFAksmrEAACgkQMlxVo39jgT/UPwCfexQ3gHxMcD3IFrFCeLSmqrQK > > 1wQAn1TK0UM7xl0MqMFwQbeBb6qr+cst > > =b5GU > > -----END PGP SIGNATURE----- > > > > --AhhlLboLdkugWU4S-- > > > > > > --===============1862406356== > > Content-Type: text/plain; charset="us-ascii" > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > --===============1862406356==-- > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From misc.lists at blueyonder.co.uk Tue Dec 15 16:26:18 2009 From: misc.lists at blueyonder.co.uk (Arthur Dent) Date: Tue, 15 Dec 2009 16:26:18 +0000 Subject: Logrotate frustration In-Reply-To: <4B279F97.4070808@redhat.com> References: <1260092312.3083.10.camel@localhost> <4B1D7275.6020400@redhat.com> <1260225022.3056.40.camel@localhost> <1260784867.3069.18.camel@localhost> <4B279F97.4070808@redhat.com> Message-ID: <1260894378.3072.96.camel@localhost> On Tue, 2009-12-15 at 09:39 -0500, Daniel J Walsh wrote: > On 12/14/2009 05:01 AM, Arthur Dent wrote: > > On Mon, 2009-12-07 at 22:30 +0000, Arthur Dent wrote: > >> On Mon, 2009-12-07 at 16:24 -0500, Daniel J Walsh wrote: > >>> On 12/06/2009 04:38 AM, Arthur Dent wrote: [Snip] > >>> I can allow logrotate to manage log lnk_files, and allow it to write to the fail2ban socket. > >>> > >>> Are you using a custom logrotate to rotate mail_spool? [Snip] > > > > OK - Following another arm of this thread I have (last week) done a > > complete relabel and removed my existing fail2ban and logrotate local > > policies. > > > > As a result of yesterday's weekly log rotate squid threw up another > > couple of AVCs related to log_lnk (see below). > > > > I have created another local policy but, do I understand you correctly > > Daniel that you may include log_lnk in a future targeted policy? > > > > Here is my new logrotate policy: > > > > ===============8<================================================== > > > > module mylogr 11.2.2; > > > > require { > > type mail_spool_t; > > type logrotate_t; > > type squid_log_t; > > class file getattr; > > class lnk_file { rename unlink }; > > } > > > > #============= logrotate_t ============== > > allow logrotate_t mail_spool_t:file getattr; > > allow logrotate_t squid_log_t:lnk_file { rename unlink }; > > > > ===============8<================================================== > > > > Is this OK? [Snip] > > Yes the squid access will not be needed. > > Fixed in selinux-policy-3.6.32-59.fc12.noarch > > logrotate looking at /mnt/backup/mail/rawmail > Looks like a local customization. Thanks Daniel, OK - I am running F11: # rpm -qa | grep -i selinux-policy selinux-policy-targeted-3.6.12-91.fc11.noarch selinux-policy-3.6.12-91.fc11.noarch Will there be a F11 version? (If so what version will it be in?) In the meantime I should keep using my local policy I guess?... Thanks again Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sds at tycho.nsa.gov Wed Dec 16 15:02:11 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 16 Dec 2009 10:02:11 -0500 Subject: how to restrict a SOCK_RAW by interface In-Reply-To: <1309562CC0F060478581A2D7331F90AC5AD11E@XMBTX122.northgrum.com> References: <1309562CC0F060478581A2D7331F90AC5AD11C@XMBTX122.northgrum.com> <1260820192.4126.13.camel@moss-pluto.epoch.ncsc.mil> <1309562CC0F060478581A2D7331F90AC5AD11E@XMBTX122.northgrum.com> Message-ID: <1260975731.19290.12.camel@moss-pluto.epoch.ncsc.mil> On Mon, 2009-12-14 at 16:56 -0600, Cernak, James E (IS) wrote: > Hello, > > Thanks for the hint, However it does not solve my problem I still can > read from eth0. eth0 or eth1? Your example showed eth1 configured as iface_test_t. > > I did have to add allow rules for netif_t:netif but my policy still > does not allow iface_test_t. Hmmm..are you sure? Did you declare any type attributes for iface_test_t? Use sesearch or apol to confirm that there are no allow rules to it in the final binary policy. > > James > > > -----Original Message----- > From: Stephen Smalley [mailto:sds at tycho.nsa.gov] > Sent: Mon 12/14/2009 1:49 PM > To: Cernak, James E (IS) > Cc: fedora-selinux-list at redhat.com > Subject: Re: how to restrict a SOCK_RAW by interface > > On Mon, 2009-12-14 at 13:29 -0600, Cernak, James E (IS) wrote: > > Hello, > > > > I am trying to restrict an application to using only some interfaces > > on the system. I have defined a new type and assigned the interface > on > > my RHEL5.4-x64 system to the new type with semanage. The system > > indicates that the interface is now configured. > > # semanage interface -l > > SELinux Interface Context > > > > eth1 > system_u:object_r:iface_test_t:s0 > > This does restrict applications like tcpdump or wireshark from > listing > > the interface that was configured. > > # tcpdump -D > > 1.peth0 > > 2.virbr0 > > 3.vif0.0 > > 4.eth0 > > 5.xenbr0 > > 6.eth2 > > 7.eth3 > > 8.any (Pseudo-device that captures on all interfaces) > > 9.lo > > > > My problem comes that my application can still open eth1 and read > and > > write packets to this interface. > > The application is opening a socket as SOCK_RAW then binding with a > > struct sockaddr_LL that has the ssll_ifindex field configured with > the > > index of ETH1. > > How do I write a selinux policy to restrict this application from > > using some interfaces. > > > > In RHEL5 (Linux 2.6.18), you might need to enable compat_net (echo 1 > > /selinux/compat_net or boot with selinux_compat_net=1 on the kernel > command line). > > -- > Stephen Smalley > National Security Agency > > > > -- Stephen Smalley National Security Agency From James.Cernak at ngc.com Thu Dec 17 13:56:11 2009 From: James.Cernak at ngc.com (Cernak, James E (IS)) Date: Thu, 17 Dec 2009 07:56:11 -0600 Subject: how to restrict a SOCK_RAW by interface References: <1309562CC0F060478581A2D7331F90AC5AD11C@XMBTX122.northgrum.com><1260820192.4126.13.camel@moss-pluto.epoch.ncsc.mil><1309562CC0F060478581A2D7331F90AC5AD11E@XMBTX122.northgrum.com> <1260975731.19290.12.camel@moss-pluto.epoch.ncsc.mil> Message-ID: <1309562CC0F060478581A2D7331F90AC5AD123@XMBTX122.northgrum.com> Hello, Sorry typo it was intended to be eth1. I just checked again. Apol shows iface_test_t having 0 attributes and 0 rule match. # getenforce Enforcing # cat selinuc/compat_net 1 # semanage interface -l SELinux Interface Context eth1 system_u:object_r:iface_test_t:s0 # grep iface_test_t *.te type iface_test_t; My app still can restart connect a socket to eth1 and read and write to eth1; James -----Original Message----- From: Stephen Smalley [mailto:sds at tycho.nsa.gov] Sent: Wed 12/16/2009 9:02 AM To: Cernak, James E (IS) Cc: fedora-selinux-list at redhat.com Subject: RE: how to restrict a SOCK_RAW by interface On Mon, 2009-12-14 at 16:56 -0600, Cernak, James E (IS) wrote: > Hello, > > Thanks for the hint, However it does not solve my problem I still can > read from eth0. eth0 or eth1? Your example showed eth1 configured as iface_test_t. > > I did have to add allow rules for netif_t:netif but my policy still > does not allow iface_test_t. Hmmm..are you sure? Did you declare any type attributes for iface_test_t? Use sesearch or apol to confirm that there are no allow rules to it in the final binary policy. > > James > > > -----Original Message----- > From: Stephen Smalley [mailto:sds at tycho.nsa.gov] > Sent: Mon 12/14/2009 1:49 PM > To: Cernak, James E (IS) > Cc: fedora-selinux-list at redhat.com > Subject: Re: how to restrict a SOCK_RAW by interface > > On Mon, 2009-12-14 at 13:29 -0600, Cernak, James E (IS) wrote: > > Hello, > > > > I am trying to restrict an application to using only some interfaces > > on the system. I have defined a new type and assigned the interface > on > > my RHEL5.4-x64 system to the new type with semanage. The system > > indicates that the interface is now configured. > > # semanage interface -l > > SELinux Interface Context > > > > eth1 > system_u:object_r:iface_test_t:s0 > > This does restrict applications like tcpdump or wireshark from > listing > > the interface that was configured. > > # tcpdump -D > > 1.peth0 > > 2.virbr0 > > 3.vif0.0 > > 4.eth0 > > 5.xenbr0 > > 6.eth2 > > 7.eth3 > > 8.any (Pseudo-device that captures on all interfaces) > > 9.lo > > > > My problem comes that my application can still open eth1 and read > and > > write packets to this interface. > > The application is opening a socket as SOCK_RAW then binding with a > > struct sockaddr_LL that has the ssll_ifindex field configured with > the > > index of ETH1. > > How do I write a selinux policy to restrict this application from > > using some interfaces. > > > > In RHEL5 (Linux 2.6.18), you might need to enable compat_net (echo 1 > > /selinux/compat_net or boot with selinux_compat_net=1 on the kernel > command line). > > -- > Stephen Smalley > National Security Agency > > > > -- Stephen Smalley National Security Agency -------------- next part -------------- An HTML attachment was scrubbed... URL: From casmls at gmail.com Thu Dec 17 16:49:19 2009 From: casmls at gmail.com (Christoph A.) Date: Thu, 17 Dec 2009 17:49:19 +0100 Subject: FC12: 'sandbox -X' AVC's Message-ID: <4B2A610F.1090203@gmail.com> Hi, after watching Dan's presentation (LPC) about sandbox in Fedora 12 I wanted to try it out, but I was not successfull. I tried 'sandbox -X xterm' and 'sandbox -X firefox' but both crashed immedeately, and I got AVC's. package versions: selinux-policy-targeted-3.6.32-56.fc12.noarch policycoreutils-2.0.74-17.fc12.i686 policycoreutils-sandbox-2.0.74-17.fc12.i686 selinux-policy-3.6.32-56.fc12.noarch policycoreutils-python-2.0.74-17.fc12.i686 avc's for 'sandbox -X firefox' attached. Is this a known issue or should this work? thanks! Christoph -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sandbox-avc URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From dwalsh at redhat.com Thu Dec 17 19:46:27 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 17 Dec 2009 14:46:27 -0500 Subject: FC12: 'sandbox -X' AVC's In-Reply-To: <4B2A610F.1090203@gmail.com> References: <4B2A610F.1090203@gmail.com> Message-ID: <4B2A8A93.2060809@redhat.com> On 12/17/2009 11:49 AM, Christoph A. wrote: > Hi, > > after watching Dan's presentation (LPC) about sandbox > in Fedora 12 I wanted to try it out, but I was not successfull. > > I tried 'sandbox -X xterm' > and 'sandbox -X firefox' but both crashed immedeately, and I got AVC's. > > package versions: > > selinux-policy-targeted-3.6.32-56.fc12.noarch > policycoreutils-2.0.74-17.fc12.i686 > policycoreutils-sandbox-2.0.74-17.fc12.i686 > selinux-policy-3.6.32-56.fc12.noarch > policycoreutils-python-2.0.74-17.fc12.i686 > > avc's for 'sandbox -X firefox' attached. > > Is this a known issue or should this work? > > thanks! > Christoph > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list sandbox -t sandbox_web_t firefox Should work for firefox. Not sure what is going wrong with sandbox -X xterm. Did you reboot after installing policycoreutils-sandbox? You need to reboot in order to setup the namespace stuff. From casmls at gmail.com Fri Dec 18 01:21:04 2009 From: casmls at gmail.com (Christoph A.) Date: Fri, 18 Dec 2009 02:21:04 +0100 Subject: FC12: 'sandbox -X' AVC's (gnash-plugin) In-Reply-To: <4B2A8A93.2060809@redhat.com> References: <4B2A610F.1090203@gmail.com> <4B2A8A93.2060809@redhat.com> Message-ID: <4B2AD900.9080608@gmail.com> On 17.12.2009 20:46, Daniel J Walsh wrote: > sandbox -t sandbox_web_t firefox > > Should work for firefox. sandbox -X -t sandbox_web_t firefox comes up fine, thanks! I also installed gnash-plugin and some codecs from RPM Fusion, if I go to a website that contains flash movies gtk-gnash crashes (only within the sandbox). I guess gtk-gnash is not allowed to interact with pulse? AVC's attached. > Not sure what is going wrong with sandbox -X xterm. Sorry, this was my fault, xterm was not on that machine. thanks, Christoph -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gnash-avc URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From zephod at cfl.rr.com Fri Dec 18 01:36:00 2009 From: zephod at cfl.rr.com (Steve Blackwell) Date: Thu, 17 Dec 2009 20:36:00 -0500 Subject: SELinux is preventing zenity... Message-ID: <20091217203600.4c971199@steve.blackwell> I have a UPS that sends an SNMP trap when the main power goes out. I wrote my snmptrapd.conf file to execute a script when the trap is received. The script simply calls zenity to pop up a message. Here's my problem. If I start snmptrapd from the command line everything works beautifully but if I have the system start it at boot time or via System->Administration->Services, the trap gets logged in /var/log/messages but the zenity window doesn't get displayed and I get these SELinux messages in /var/log/messages. SELinux is preventing the zenity from using potentially mislabeled files (XO)... SELinux is preventing zenity (snmpd_t) "name_connect" to ... I've looked at the ouput of # ps -ef | grep snmptrapd and it is identical in both cases so I don't understand why one works and the other doesn't. I tried # cat /var/log/messages | audit2allow -m local but that just produced a file that said: module local 1.0; and nothing else. I'm running RHEL5.4 with SELinux in enforcing mode. Any help would be appreciated. Thanks, Steve From domg472 at gmail.com Fri Dec 18 09:11:53 2009 From: domg472 at gmail.com (Dominick Grift) Date: Fri, 18 Dec 2009 10:11:53 +0100 Subject: SELinux is preventing zenity... In-Reply-To: <20091217203600.4c971199@steve.blackwell> References: <20091217203600.4c971199@steve.blackwell> Message-ID: <20091218091152.GA7572@localhost.localdomain> On Thu, Dec 17, 2009 at 08:36:00PM -0500, Steve Blackwell wrote: > I have a UPS that sends an SNMP trap when the main power goes out. > I wrote my snmptrapd.conf file to execute a script when the trap is > received. The script simply calls zenity to pop up a message. > > Here's my problem. If I start snmptrapd from the command line > everything works beautifully but if I have the system start it at boot > time or via System->Administration->Services, the trap gets logged Because when you start it manually it gets executed in the users environment which is unrestricted/ unprotected in el5 > in /var/log/messages but the zenity window doesn't get displayed and I > get these SELinux messages in /var/log/messages. > > SELinux is preventing the zenity from using potentially mislabeled > files (XO)... > > SELinux is preventing zenity (snmpd_t) "name_connect" to > ... > > I've looked at the ouput of > > # ps -ef | grep snmptrapd > > and it is identical in both cases so I don't understand why one works > and the other doesn't. I tried > > # cat /var/log/messages | audit2allow -m local The avc denial gets logged to /var/log/audit/audit.log: ausearch -m avc -ts yesterday | grep snmpt_t | audit2allow -M mysnmp | semodule -i mysnmp.pp > > but that just produced a file that said: > > module local 1.0; > > and nothing else. > > I'm running RHEL5.4 with SELinux in enforcing mode. > > Any help would be appreciated. > > Thanks, > Steve > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From Moray.Henderson at ict-software.org Fri Dec 18 09:48:02 2009 From: Moray.Henderson at ict-software.org (Moray Henderson) Date: Fri, 18 Dec 2009 09:48:02 +0000 Subject: SELinux is preventing zenity... In-Reply-To: <20091217203600.4c971199@steve.blackwell> References: <20091217203600.4c971199@steve.blackwell> Message-ID: <000001ca7fc7$319de010$94d9a030$@Henderson@ict-software.org> Steve Blackwell wrote: >SELinux is preventing zenity (snmpd_t) "name_connect" to >... > >I've looked at the ouput of > ># ps -ef | grep snmptrapd > >and it is identical in both cases so I don't understand why one works >and the other doesn't. I tried # ps -Zef | grep snmptrapd should show you the context of the running process. Moray. "To err is human.? To purr, feline" From dwalsh at redhat.com Fri Dec 18 15:09:04 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 18 Dec 2009 10:09:04 -0500 Subject: Tutorial on setting up SELinux / X Server In-Reply-To: <4B19926E.9080500@tycho.nsa.gov> References: <4B187D09.90508@tycho.nsa.gov> <4B19926E.9080500@tycho.nsa.gov> Message-ID: <4B2B9B10.5050909@redhat.com> On 12/04/2009 05:51 PM, Eamon Walsh wrote: > On 12/04/2009 10:59 AM, Tyler Durvik wrote: >> I turned on the boolean: >> >> setsebool -P xserver_object_manager on >> >> and now I get the following in my Xorg.0.log file: >> >> SELinux: Invalid object class mapping, disabling SELinux support. >> >> Should I try the latest policy from oss.tresys.com? Would the >> upstream reference policy fix this error? >> >> Thanks, >> Mark >> >> > > OK, that error is because the x_pointer and x_keyboard object classes > haven't made it into F-12 policy yet. > > You could try the upstream policy. I'd recommend sticking with the > Fedora policy though, because I'm getting AVC's from upstream (at least > on rawhide) and upstream is not tuned for Fedora. If you do compile > from upstream make sure to set the "init_upstart" boolean to true or > everything gets out of whack at boot time. > > If you're willing to rebuild the F-12 policy, you can add the attached > patch which will fix the error above and allow the SELinux extension to > run. As soon as I can get the rest of the new X policy ported I'll send > it to Dan. > > > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Latest XServer policy will be in selinux-policy-3.7.4-7.fc13.noarch From joshua.roys at gtri.gatech.edu Fri Dec 18 20:13:13 2009 From: joshua.roys at gtri.gatech.edu (Joshua Roys) Date: Fri, 18 Dec 2009 15:13:13 -0500 Subject: labeling traffic over lo Message-ID: <4B2BE259.8060107@gtri.gatech.edu> Hello, I am trying to have some applications communicate over loopback under a f12 mls policy using some sort of labeled networking, the reason being that otherwise I hit a selinux avc about an unlabeled_t ingress: avc: denied { ingress } for saddr=127.0.0.1 daddr=127.0.0.1 netif=lo scontext=system_u:object_r:unlabeled_t:s15:c0.c1023 tcontext=...:lo_netif_t:s0-s15:c0.c1023 tclass=netif Thus far I have tried secmark, but there appear to be issues. I have incoming and outgoing labeled ipsec from this box working, until I add a secmark rule like: iptables -t mangle -A INPUT -p tcp -s 127.0.0.1 -d 127.0.0.1 -i lo --dport $secondary_app_port -j SECMARK --selctx system_u:system_r:httpd_t:s0-s1:c0,c3 And then labeled ipsec falls over and I get avcs similar to: avc: denied { recv } for saddr=$remote daddr=$local netif=eth0 scontext=...:application_t tcontext=...:unlabeled_t tclass=packet It seems as if having any secmark labels causes selinux to "forget" about the labels retrieved from labeled ipsec? When I delete the secmark rule, I return to getting ingress avcs... Any ideas? Thanks, Josh From domg472 at gmail.com Fri Dec 18 20:50:54 2009 From: domg472 at gmail.com (Dominick Grift) Date: Fri, 18 Dec 2009 21:50:54 +0100 Subject: libcg policy Message-ID: <4B2BEB2E.9090606@gmail.com> The policy below works for me. But there are variables. like for example i choose to mount cgroup fs in /mnt/ some mount it to /dev others to /proc Also interface naming could be better. And unfortunatly alot if done in init scripts. /etc/rc\.d/init\.d/cgconfig -- gen_context(system_u:object_r:cgconfig_initrc_exec_t, s0) /etc/rc\.d/init\.d/cgred -- gen_context(system_u:object_r:cgrulesengd_initrc_exec_t, s0) /sbin/cgrulesengd -- gen_context(system_u:object_r:cgrulesengd_exec_t, s0) /sbin/cgconfigparser -- gen_context(system_u:object_r:cgconfigparser_exec_t, s0) policy_module(libcgroup, 1.0.0) ######################################## # # cgrulesengd personal declarations. # type cgrulesengd_t; type cgrulesengd_exec_t; init_daemon_domain(cgrulesengd_t, cgrulesengd_exec_t) type cgrulesengd_initrc_exec_t; init_script_file(cgrulesengd_initrc_exec_t) type cgrulesengd_var_run_t; files_pid_file(cgrulesengd_var_run_t) permissive cgrulesengd_t; ######################################## # # cgconfig personal declarations. # type cgconfigparser_t; type cgconfigparser_exec_t; init_daemon_domain(cgconfigparser_t, cgconfigparser_exec_t) type cgconfig_initrc_exec_t; init_script_file(cgconfig_initrc_exec_t) permissive cgconfigparser_t; ######################################## # # cgrulesengd personal policy. # allow cgrulesengd_t self:capability { net_admin sys_ptrace dac_override }; allow cgrulesengd_t self:netlink_socket { write bind create read }; allow cgrulesengd_t self:unix_dgram_socket { write create connect }; manage_sock_files_pattern(cgrulesengd_t, cgrulesengd_var_run_t, cgrulesengd_var_run_t) files_pid_filetrans(cgrulesengd_t, cgrulesengd_var_run_t, sock_file) domain_read_all_domains_state(cgrulesengd_t) files_read_etc_files(cgrulesengd_t) files_search_all(cgrulesengd_t) files_getattr_all_files(cgrulesengd_t) files_getattr_all_dirs(cgrulesengd_t) files_getattr_all_sockets(cgrulesengd_t) files_getattr_all_pipes(cgrulesengd_t) files_getattr_all_symlinks(cgrulesengd_t) # read all link files. kernel_read_system_state(cgrulesengd_t) logging_send_syslog_msg(cgrulesengd_t) miscfiles_read_localization(cgrulesengd_t) optional_policy(` fs_write_cgroup_files(cgrulesengd_t) ') ######################################## # # cgconfig personal policy. # optional_policy(` fs_manage_cgroup_dirs(cgconfigparser_t) fs_rw_cgroup_files(cgconfigparser_t) fs_setattr_cgroup_files(cgconfigparser_t) fs_mount_cgroup_fs(cgconfigparser_t) ') files_mounton_mnt(cgconfigparser_t) files_manage_mnt_dirs(cgconfigparser_t) files_read_etc_files(cgconfigparser_t) ## Control group rules engine daemon. ## ##

## cgrulesengd is a daemon, which distributes processes ## to control groups. When any process changes its ## effective UID or GID, cgrulesengd inspects list of ## rules loaded from cgrules.conf file and moves the ## process to the appropriate control group. ##

##

## The list of rules is read during the daemon startup and ## are cached in daemon?s memory. The daemon reloads the ## list of rules when it receives SIGUSR2 signal. ##

## ######################################## ## ## Read and write cgrulesengd sock file in /var/run. ## ## ## ## Domain allowed access. ## ## # interface(`libcgroup_cgrulesengd_rw_pid_sock_file', ` gen_require(` type cgrulesengd_var_run_t; ') rw_sock_files_pattern($1, cgrulesengd_var_run_t, cgrulesengd_var_run_t) files_search_pids($1) ') ######################################## ## ## Unix stream socket connect to cgrulesengd. ## ## ## ## Domain allowed access. ## ## # interface(`libcgroup_cgrulesengd_stream_connect', ` gen_require(` type cgrulesengd_t; ') allow $1 cgrulesengd_t:unix_stream_socket connectto; ') # /mnt/cgroups/cpu kernel_list_unlabeled(cgconfigparser_t) kernel_read_system_state(cgconfigparser_t) ------------------------------------------- ------------------------------------------- patch to filesystem ------------------------------------------- ## Patch to facilitate interface to interact with cgroup fs. ## ##

## Add interfaces to allow for interaction with cgroupfs ## for initrc (cfconfig) and for cfrulesengd. ##

## ######################################## ## ## Mount a cgroup filesystem. ## ## ## ## Domain allowed access. ## ## # interface(`fs_mount_cgroup_fs', ` gen_require(` type cgroup_t; ') allow $1 cgroup_t:filesystem mount; ') ######################################## ## ## Remount a cgroup filesystem This allows ## some mount options to be changed. ## ## ## ## Domain allowed access. ## ## # interface(`fs_remount_cgroup_fs', ` gen_require(` type cgroup_t; ') allow $1 cgroup_t:filesystem remount; ') ######################################## ## ## Unmount a cgroup file system. ## ## ## ## Domain allowed access. ## ## # interface(`fs_unmount_cgroup_fs', ` gen_require(` type cgroup_t; ') allow $1 cgroup_t:filesystem unmount; ') ######################################## ## ## Read and write files on cgroup ## file systems. ## ## ## ## Domain allowed access. ## ## # interface(`fs_rw_cgroup_files',` gen_require(` type cgroup_t; ') rw_files_pattern($1, cgroup_t, cgroup_t) fs_search_cgroup_dirs($1) ') ######################################## ## ## Set attributes of files on cgroup ## file systems. ## ## ## ## Domain allowed access. ## ## # interface(`fs_setattr_cgroup_files',` gen_require(` type cgroup_t; ') setattr_files_pattern($1, cgroup_t, cgroup_t) fs_search_cgroup_dirs($1) ') ######################################## ## ## Manage dirs on cgroup ## file systems. ## ## ## ## Domain allowed access. ## ## # interface(`fs_manage_cgroup_dirs',` gen_require(` type cgroup_t; ') manage_dirs_pattern($1, cgroup_t, cgroup_t) ') ######################################## ## ## Search dirs on cgroup ## file systems. ## ## ## ## Domain allowed access. ## ## # interface(`fs_search_cgroup_dirs', ` gen_require(` type cgroup_t; ') allow $1 cgroup_t:dir search; ') ######################################## ## ## Write files on cgroup ## file systems. ## ## ## ## Domain allowed access. ## ## # interface(`fs_write_cgroup_files', ` gen_require(` type cgroup_t; ') write_files_pattern($1, cgroup_t, cgroup_t) fs_search_cgroup_dirs($1) ') ######################################## ## ## list dirs on cgroup ## file systems. ## ## ## ## Domain allowed access. ## ## # interface(`fs_list_cgroup_dirs', ` gen_require(` type cgroup_t; ') list_dirs_pattern($1, cgroup_t, cgroup_t) ') ######################################## ## ## create dirs on cgroup ## file systems. ## ## ## ## Domain allowed access. ## ## # interface(`fs_create_cgroup_dirs', ` gen_require(` type cgroup_t; ') create_dirs_pattern($1, cgroup_t, cgroup_t) ') ---------------------------------------------- patch to init --------------------------------------------- policy_module(patch_initrc_to_allow_cgconf_cgrulesengd_manage_files_on_cgroup_fs, 1.0.0) ######################################## # # Declarations # optional_policy(` gen_require(` type initrc_t; ') fs_manage_cgroup_dirs(initrc_t) fs_rw_cgroup_files(initrc_t) fs_setattr_cgroup_files(initrc_t) libcgroup_cgrulesengd_rw_pid_sock_file(initrc_t) libcgroup_cgrulesengd_stream_connect(initrc_t) ') -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From domg472 at gmail.com Sat Dec 19 09:51:46 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 19 Dec 2009 10:51:46 +0100 Subject: DenyHosts policy Message-ID: <4B2CA232.9090600@gmail.com> Attached is DenyHosts modules Based on the Fedora 12 DenyHosts package. Maintained here: git clone git://82.197.205.60/selinux-modules.git -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: denyhosts.fc URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: denyhosts.if URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: denyhosts.te URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From zephod at cfl.rr.com Mon Dec 21 02:25:58 2009 From: zephod at cfl.rr.com (Steve Blackwell) Date: Sun, 20 Dec 2009 21:25:58 -0500 Subject: SELinux is preventing zenity... In-Reply-To: <20091218091152.GA7572@localhost.localdomain> References: <20091217203600.4c971199@steve.blackwell> <20091218091152.GA7572@localhost.localdomain> Message-ID: <20091220212558.4523366a@steve.blackwell> On Fri, 18 Dec 2009 10:11:53 +0100 Dominick Grift wrote: > On Thu, Dec 17, 2009 at 08:36:00PM -0500, Steve Blackwell wrote: > > I have a UPS that sends an SNMP trap when the main power goes out. > > I wrote my snmptrapd.conf file to execute a script when the trap is > > received. The script simply calls zenity to pop up a message. > > > > Here's my problem. If I start snmptrapd from the command line > > everything works beautifully but if I have the system start it at > > boot time or via System->Administration->Services, the trap gets > > logged > > Because when you start it manually it gets executed in the users > environment which is unrestricted/ unprotected in el5 OK, I see that now. I got a bit wrapped around the axel because snmptrapd sometimes creates a file (I'm not quite sure when) called /var/net-smpd/snmptrapd.conf and if I run # /etc/rc.d/init.d/snmptrapd restart as root it gets created with a snmpd_var_lib_t type but if I just start snmptrapd from the command line as root it gets created with a different type and then the system can't restart snmptrapd because it doesn't have permission to write to that file. ... I think... > > > in /var/log/messages but the zenity window doesn't get displayed > > and I get these SELinux messages in /var/log/messages. > > > > SELinux is preventing the zenity from using potentially mislabeled > > files (XO)... > > > > SELinux is preventing zenity (snmpd_t) "name_connect" to > > ... > > > > I've looked at the ouput of > > > > # ps -ef | grep snmptrapd > > > > and it is identical in both cases so I don't understand why one > > works and the other doesn't. I tried > > > > # cat /var/log/messages | audit2allow -m local > > The avc denial gets logged to .: > > ausearch -m avc -ts yesterday | grep snmpt_t | audit2allow -M mysnmp > | semodule -i mysnmp.pp This was also confusing me because I had auditd turned off and so the avc denials are supposed to go to /var/log/messages but it seems that some still went to /var/log/audit/audit.log. Anyhow running this command helped in that I don't get any more avc denials logged but I still don't see my dialog popup. I'm going to try this again starting with a clean log. I have a few questions if you have the time to answer them. I have been reading this: http://www.linuxtopia.org/online_books/getting_started_with_SELinux/index.html and this: http://www.linuxtopia.org/online_books/writing_SELinux_policy_guide/index.html which I found quite useful but they are way out of date. Is there anything comparable that is current? My understanding is that a .te is a policy configuration file, a text file and that a .pp file is a policy package, a binary file. Does the .te file get "compiled" into a .pp file and if so how does this happen? I read that the policy directory for Fedora systems is /etc/security/selinux/src/policy but neither the RHEL5.4 system at work nor my Fedora 11 system at home has such a directory and the only .te file is in /usr/share/selinux/devel. Where is the accepted location to put .te files? Is there a way to "see" what a .pp file is doing? A disassembly of sorts. I'd like to look at some examples. There are plenty of .pp files in /etc/selinux/targeted/modules/active/modules. Thanks, Steve > > > > but that just produced a file that said: > > > > module local 1.0; > > > > and nothing else. > > > > I'm running RHEL5.4 with SELinux in enforcing mode. > > > > Any help would be appreciated. > > > > Thanks, > > Steve > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From tristan.santore at internexusconnect.net Mon Dec 21 03:06:55 2009 From: tristan.santore at internexusconnect.net (Tristan Santore) Date: Mon, 21 Dec 2009 03:06:55 +0000 Subject: SELinux is preventing zenity... In-Reply-To: <20091220212558.4523366a@steve.blackwell> References: <20091217203600.4c971199@steve.blackwell> <20091218091152.GA7572@localhost.localdomain> <20091220212558.4523366a@steve.blackwell> Message-ID: <4B2EE64F.8010500@internexusconnect.net> On 21/12/09 02:25, Steve Blackwell wrote: > On Fri, 18 Dec 2009 10:11:53 +0100 > Dominick Grift wrote: > > >> On Thu, Dec 17, 2009 at 08:36:00PM -0500, Steve Blackwell wrote: >> >>> I have a UPS that sends an SNMP trap when the main power goes out. >>> I wrote my snmptrapd.conf file to execute a script when the trap is >>> received. The script simply calls zenity to pop up a message. >>> >>> Here's my problem. If I start snmptrapd from the command line >>> everything works beautifully but if I have the system start it at >>> boot time or via System->Administration->Services, the trap gets >>> logged >>> >> Because when you start it manually it gets executed in the users >> environment which is unrestricted/ unprotected in el5 >> > OK, I see that now. I got a bit wrapped around the axel because > snmptrapd sometimes creates a file (I'm not quite sure > when) called /var/net-smpd/snmptrapd.conf and if I run > # /etc/rc.d/init.d/snmptrapd restart > as root it gets created with a snmpd_var_lib_t type but if I just > start snmptrapd from the command line as root it gets created with a > different type and then the system can't restart snmptrapd because it > doesn't have permission to write to that file. ... I think... > > >> >>> in /var/log/messages but the zenity window doesn't get displayed >>> and I get these SELinux messages in /var/log/messages. >>> >>> SELinux is preventing the zenity from using potentially mislabeled >>> files (XO)... >>> >>> SELinux is preventing zenity (snmpd_t) "name_connect" to >>> ... >>> >>> I've looked at the ouput of >>> >>> # ps -ef | grep snmptrapd >>> >>> and it is identical in both cases so I don't understand why one >>> works and the other doesn't. I tried >>> >>> # cat /var/log/messages | audit2allow -m local >>> >> The avc denial gets logged to .: >> >> ausearch -m avc -ts yesterday | grep snmpt_t | audit2allow -M mysnmp >> | semodule -i mysnmp.pp >> > This was also confusing me because I had auditd turned off and so the > avc denials are supposed to go to /var/log/messages but it seems that > some still went to /var/log/audit/audit.log. > > Anyhow running this command helped in that I don't get any more avc > denials logged but I still don't see my dialog popup. I'm going to try > this again starting with a clean log. > > I have a few questions if you have the time to answer them. > > I have been reading this: > http://www.linuxtopia.org/online_books/getting_started_with_SELinux/index.html > and this: > http://www.linuxtopia.org/online_books/writing_SELinux_policy_guide/index.html > which I found quite useful but they are way out of date. Is there > anything comparable that is current? > > My understanding is that a .te is a policy configuration file, a text > file and that a .pp file is a policy package, a binary file. Does > the .te file get "compiled" into a .pp file and if so how does this > happen? > > I read that the policy directory for Fedora systems is > /etc/security/selinux/src/policy > but neither the RHEL5.4 system at work nor my Fedora 11 system at home > has such a directory and the only .te file is in > /usr/share/selinux/devel. > Where is the accepted location to put .te files? > > Is there a way to "see" what a .pp file is doing? A disassembly of > sorts. I'd like to look at some examples. There are plenty of .pp files > in /etc/selinux/targeted/modules/active/modules. > > Thanks, > Steve > >>> but that just produced a file that said: >>> >>> module local 1.0; >>> >>> and nothing else. >>> >>> I'm running RHEL5.4 with SELinux in enforcing mode. >>> >>> Any help would be appreciated. >>> >>> Thanks, >>> Steve >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Steve, we have two selinux docs in the fedora docs at http://docs.fedoraproject.org/ Also maybe Daniels Blog might be useful to you @ http://danwalsh.livejournal.com/ There are more, but I cant think of them at the moment. If you harass fenris02 in #fedora, and ask him for the SElinux links,he has got a script that blahs them out. Regards, Tristan -- Tristan Santore BSc MBCS TS4523-RIPE Network and Infrastructure Operations InterNexusConnect Mobile +44-78-55069812 Tristan.Santore at internexusconnect.net Thawte Notary For Fedora related issues, please email me at: TSantore at fedoraproject.org -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3388 bytes Desc: S/MIME Cryptographic Signature URL: From zephod at cfl.rr.com Mon Dec 21 04:36:39 2009 From: zephod at cfl.rr.com (Steve Blackwell) Date: Sun, 20 Dec 2009 23:36:39 -0500 Subject: SELinux is preventing zenity... In-Reply-To: <4B2EE64F.8010500@internexusconnect.net> References: <20091217203600.4c971199@steve.blackwell> <20091218091152.GA7572@localhost.localdomain> <20091220212558.4523366a@steve.blackwell> <4B2EE64F.8010500@internexusconnect.net> Message-ID: <20091220233639.56d6e566@steve.blackwell> On Mon, 21 Dec 2009 03:06:55 +0000 Tristan Santore wrote: > > > I have been reading this: > > http://www.linuxtopia.org/online_books/getting_started_with_SELinux/index.html > > and this: > > http://www.linuxtopia.org/online_books/writing_SELinux_policy_guide/index.html > > which I found quite useful but they are way out of date. Is there > > anything comparable that is current? > Steve, > we have two selinux docs in the fedora docs at > http://docs.fedoraproject.org/ > Also maybe Daniels Blog might be useful to you @ > http://danwalsh.livejournal.com/ > > There are more, but I cant think of them at the moment. If you harass > fenris02 in #fedora, and ask him for the SElinux links,he has got a > script that > blahs them out. > > Regards, > Tristan > Thanks, I'll check those out. Steve From domg472 at gmail.com Mon Dec 21 09:32:25 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 21 Dec 2009 10:32:25 +0100 Subject: SELinux is preventing zenity... In-Reply-To: <20091220212558.4523366a@steve.blackwell> References: <20091217203600.4c971199@steve.blackwell> <20091218091152.GA7572@localhost.localdomain> <20091220212558.4523366a@steve.blackwell> Message-ID: <20091221093223.GA21720@localhost.localdomain> On Sun, Dec 20, 2009 at 09:25:58PM -0500, Steve Blackwell wrote: > On Fri, 18 Dec 2009 10:11:53 +0100 > Dominick Grift wrote: > > > On Thu, Dec 17, 2009 at 08:36:00PM -0500, Steve Blackwell wrote: > > > I have a UPS that sends an SNMP trap when the main power goes out. > > > I wrote my snmptrapd.conf file to execute a script when the trap is > > > received. The script simply calls zenity to pop up a message. > > > > > > Here's my problem. If I start snmptrapd from the command line > > > everything works beautifully but if I have the system start it at > > > boot time or via System->Administration->Services, the trap gets > > > logged > > > > Because when you start it manually it gets executed in the users > > environment which is unrestricted/ unprotected in el5 > > OK, I see that now. I got a bit wrapped around the axel because > snmptrapd sometimes creates a file (I'm not quite sure > when) called /var/net-smpd/snmptrapd.conf and if I run > # /etc/rc.d/init.d/snmptrapd restart > as root it gets created with a snmpd_var_lib_t type but if I just > start snmptrapd from the command line as root it gets created with a > different type and then the system can't restart snmptrapd because it > doesn't have permission to write to that file. ... I think... > > > > > > in /var/log/messages but the zenity window doesn't get displayed > > > and I get these SELinux messages in /var/log/messages. > > > > > > SELinux is preventing the zenity from using potentially mislabeled > > > files (XO)... > > > > > > SELinux is preventing zenity (snmpd_t) "name_connect" to > > > ... > > > > > > I've looked at the ouput of > > > > > > # ps -ef | grep snmptrapd > > > > > > and it is identical in both cases so I don't understand why one > > > works and the other doesn't. I tried > > > > > > # cat /var/log/messages | audit2allow -m local > > > > The avc denial gets logged to .: > > > > ausearch -m avc -ts yesterday | grep snmpt_t | audit2allow -M mysnmp > > | semodule -i mysnmp.pp > > This was also confusing me because I had auditd turned off and so the > avc denials are supposed to go to /var/log/messages but it seems that > some still went to /var/log/audit/audit.log. > > Anyhow running this command helped in that I don't get any more avc > denials logged but I still don't see my dialog popup. I'm going to try > this again starting with a clean log. > > I have a few questions if you have the time to answer them. > > I have been reading this: > http://www.linuxtopia.org/online_books/getting_started_with_SELinux/index.html > and this: > http://www.linuxtopia.org/online_books/writing_SELinux_policy_guide/index.html > which I found quite useful but they are way out of date. Is there > anything comparable that is current? I recently wrote a bit about the policy structure in Fedora 12 , that also applies to 11 and to some degree el5. its here: http://82.197.205.60/~dgrift/stuff/Managing_a_SELinux_environment_with_Fedora_12.pdf its not detailed though. > > My understanding is that a .te is a policy configuration file, a text > file and that a .pp file is a policy package, a binary file. Does > the .te file get "compiled" into a .pp file and if so how does this > happen? the .te , .fc and .if files make a complete source policy module. yes. A binary representation of this (.pp) is what gets loaded "into the kernel" This is done via the checkmodule and semodule_package commands. We usually use the installed /usr/share/selinux/devel/Makefile to do this (requires selinux-policy-devel on el5) > I read that the policy directory for Fedora systems is > /etc/security/selinux/src/policy > but neither the RHEL5.4 system at work nor my Fedora 11 system at home I think that is old (el4/fc4/5?) > has such a directory and the only .te file is in > /usr/share/selinux/devel. > Where is the accepted location to put .te files? > .te files is source policy. It should not get installed. The only source policy file that can get installed is the .if source policy file. This file is kind of like a header file. It has shared policy that can be used by other modules to interact with that modules' type. > Is there a way to "see" what a .pp file is doing? A disassembly of > sorts. I'd like to look at some examples. There are plenty of .pp files > in /etc/selinux/targeted/modules/active/modules. The is not pp disassembler but the sesearch command can be used to query the installed policy. (part of setools) > > Thanks, > Steve > > > > > > but that just produced a file that said: > > > > > > module local 1.0; > > > > > > and nothing else. > > > > > > I'm running RHEL5.4 with SELinux in enforcing mode. > > > > > > Any help would be appreciated. > > > > > > Thanks, > > > Steve > > > > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mgrepl at redhat.com Mon Dec 21 11:57:49 2009 From: mgrepl at redhat.com (Miroslav Grepl) Date: Mon, 21 Dec 2009 12:57:49 +0100 Subject: DenyHosts policy In-Reply-To: <4B2CA232.9090600@gmail.com> References: <4B2CA232.9090600@gmail.com> Message-ID: <4B2F62BD.5060101@redhat.com> On 12/19/2009 10:51 AM, Dominick Grift wrote: > Attached is DenyHosts modules Based on the Fedora 12 DenyHosts package. > > Maintained here: git clone git://82.197.205.60/selinux-modules.git > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From denyhosts.te: # /etc/hosts.deny files_rw_etc_files(denyhosts_t) Dominick, I believe we shouldn't add this permission to denyhosts. Dan, maybe other candidate for system_conf_t type as well as sysctl.conf. Regards, Miroslav -------------- next part -------------- An HTML attachment was scrubbed... URL: From domg472 at gmail.com Mon Dec 21 12:43:47 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 21 Dec 2009 13:43:47 +0100 Subject: DenyHosts policy In-Reply-To: <4B2F62BD.5060101@redhat.com> References: <4B2CA232.9090600@gmail.com> <4B2F62BD.5060101@redhat.com> Message-ID: <20091221124346.GA23337@localhost.localdomain> On Mon, Dec 21, 2009 at 12:57:49PM +0100, Miroslav Grepl wrote: > On 12/19/2009 10:51 AM, Dominick Grift wrote: > >Attached is DenyHosts modules Based on the Fedora 12 DenyHosts package. > > > >Maintained here: git clone git://82.197.205.60/selinux-modules.git > > > > > > > >-- > >fedora-selinux-list mailing list > >fedora-selinux-list at redhat.com > >https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From denyhosts.te: > > # /etc/hosts.deny > files_rw_etc_files(denyhosts_t) > > Dominick, > I believe we shouldn't add this permission to denyhosts. > > Dan, > maybe other candidate for system_conf_t type as well as sysctl.conf. Agreed. Same could be said for /var/log/secure being generic var_log_t? > > Regards, > Miroslav > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dwalsh at redhat.com Mon Dec 21 16:52:48 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 21 Dec 2009 11:52:48 -0500 Subject: SELinux is preventing zenity... In-Reply-To: <20091220233639.56d6e566@steve.blackwell> References: <20091217203600.4c971199@steve.blackwell> <20091218091152.GA7572@localhost.localdomain> <20091220212558.4523366a@steve.blackwell> <4B2EE64F.8010500@internexusconnect.net> <20091220233639.56d6e566@steve.blackwell> Message-ID: <4B2FA7E0.4060200@redhat.com> On 12/20/2009 11:36 PM, Steve Blackwell wrote: > On Mon, 21 Dec 2009 03:06:55 +0000 > Tristan Santore wrote: > >> >>> I have been reading this: >>> http://www.linuxtopia.org/online_books/getting_started_with_SELinux/index.html >>> and this: >>> http://www.linuxtopia.org/online_books/writing_SELinux_policy_guide/index.html >>> which I found quite useful but they are way out of date. Is there >>> anything comparable that is current? > >> Steve, >> we have two selinux docs in the fedora docs at >> http://docs.fedoraproject.org/ >> Also maybe Daniels Blog might be useful to you @ >> http://danwalsh.livejournal.com/ >> >> There are more, but I cant think of them at the moment. If you harass >> fenris02 in #fedora, and ask him for the SElinux links,he has got a >> script that >> blahs them out. >> >> Regards, >> Tristan >> > Thanks, I'll check those out. > Steve > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Steve are you all set now, or do you still need help? From dwalsh at redhat.com Mon Dec 21 19:21:07 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 21 Dec 2009 14:21:07 -0500 Subject: Logrotate frustration In-Reply-To: <1260894378.3072.96.camel@localhost> References: <1260092312.3083.10.camel@localhost> <4B1D7275.6020400@redhat.com> <1260225022.3056.40.camel@localhost> <1260784867.3069.18.camel@localhost> <4B279F97.4070808@redhat.com> <1260894378.3072.96.camel@localhost> Message-ID: <4B2FCAA3.8020503@redhat.com> On 12/15/2009 11:26 AM, Arthur Dent wrote: > On Tue, 2009-12-15 at 09:39 -0500, Daniel J Walsh wrote: >> On 12/14/2009 05:01 AM, Arthur Dent wrote: >>> On Mon, 2009-12-07 at 22:30 +0000, Arthur Dent wrote: >>>> On Mon, 2009-12-07 at 16:24 -0500, Daniel J Walsh wrote: >>>>> On 12/06/2009 04:38 AM, Arthur Dent wrote: > > [Snip] > >>>>> I can allow logrotate to manage log lnk_files, and allow it to write to the fail2ban socket. >>>>> >>>>> Are you using a custom logrotate to rotate mail_spool? > > [Snip] > >>> >>> OK - Following another arm of this thread I have (last week) done a >>> complete relabel and removed my existing fail2ban and logrotate local >>> policies. >>> >>> As a result of yesterday's weekly log rotate squid threw up another >>> couple of AVCs related to log_lnk (see below). >>> >>> I have created another local policy but, do I understand you correctly >>> Daniel that you may include log_lnk in a future targeted policy? >>> >>> Here is my new logrotate policy: >>> >>> ===============8<================================================== >>> >>> module mylogr 11.2.2; >>> >>> require { >>> type mail_spool_t; >>> type logrotate_t; >>> type squid_log_t; >>> class file getattr; >>> class lnk_file { rename unlink }; >>> } >>> >>> #============= logrotate_t ============== >>> allow logrotate_t mail_spool_t:file getattr; >>> allow logrotate_t squid_log_t:lnk_file { rename unlink }; >>> >>> ===============8<================================================== >>> >>> Is this OK? > > [Snip] > >> >> Yes the squid access will not be needed. >> >> Fixed in selinux-policy-3.6.32-59.fc12.noarch >> >> logrotate looking at /mnt/backup/mail/rawmail >> Looks like a local customization. > > Thanks Daniel, > > OK - I am running F11: > # rpm -qa | grep -i selinux-policy > selinux-policy-targeted-3.6.12-91.fc11.noarch > selinux-policy-3.6.12-91.fc11.noarch > > Will there be a F11 version? (If so what version will it be in?) > > In the meantime I should keep using my local policy I guess?... > > Thanks again > > Mark > > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Miroslav, Could you add this patch to F11? -------------- next part -------------- A non-text attachment was scrubbed... Name: logrotate.diff Type: text/x-patch Size: 2382 bytes Desc: not available URL: From dwalsh at redhat.com Tue Dec 22 15:33:03 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 22 Dec 2009 10:33:03 -0500 Subject: DenyHosts policy In-Reply-To: <20091221124346.GA23337@localhost.localdomain> References: <4B2CA232.9090600@gmail.com> <4B2F62BD.5060101@redhat.com> <20091221124346.GA23337@localhost.localdomain> Message-ID: <4B30E6AF.2080007@redhat.com> On 12/21/2009 07:43 AM, Dominick Grift wrote: > On Mon, Dec 21, 2009 at 12:57:49PM +0100, Miroslav Grepl wrote: >> On 12/19/2009 10:51 AM, Dominick Grift wrote: >>> Attached is DenyHosts modules Based on the Fedora 12 DenyHosts package. >>> >>> Maintained here: git clone git://82.197.205.60/selinux-modules.git >>> >>> >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> From denyhosts.te: >> >> # /etc/hosts.deny >> files_rw_etc_files(denyhosts_t) >> >> Dominick, >> I believe we shouldn't add this permission to denyhosts. >> >> Dan, >> maybe other candidate for system_conf_t type as well as sysctl.conf. > > Agreed. Same could be said for /var/log/secure being generic var_log_t? >> >> Regards, >> Miroslav >> >> >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list Would net_conf_t make more sense? From dwalsh at redhat.com Tue Dec 22 15:35:55 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 22 Dec 2009 10:35:55 -0500 Subject: DenyHosts policy In-Reply-To: <20091221124346.GA23337@localhost.localdomain> References: <4B2CA232.9090600@gmail.com> <4B2F62BD.5060101@redhat.com> <20091221124346.GA23337@localhost.localdomain> Message-ID: <4B30E75B.8090805@redhat.com> On 12/21/2009 07:43 AM, Dominick Grift wrote: > On Mon, Dec 21, 2009 at 12:57:49PM +0100, Miroslav Grepl wrote: >> On 12/19/2009 10:51 AM, Dominick Grift wrote: >>> Attached is DenyHosts modules Based on the Fedora 12 DenyHosts package. >>> >>> Maintained here: git clone git://82.197.205.60/selinux-modules.git >>> >>> >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> From denyhosts.te: >> >> # /etc/hosts.deny >> files_rw_etc_files(denyhosts_t) >> >> Dominick, >> I believe we shouldn't add this permission to denyhosts. >> >> Dan, >> maybe other candidate for system_conf_t type as well as sysctl.conf. > > Agreed. Same could be said for /var/log/secure being generic var_log_t? >> >> Regards, >> Miroslav >> >> >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list sysnet_manage_config(denyhosts_t) sysnet_etc_filetrans_config(denyhosts_t) From Moray.Henderson at ict-software.org Tue Dec 22 16:44:40 2009 From: Moray.Henderson at ict-software.org (Moray Henderson) Date: Tue, 22 Dec 2009 16:44:40 +0000 Subject: General interface question Message-ID: <002d01ca8326$0f98aba0$2eca02e0$@Henderson@ict-software.org> How do you find out what module interfaces are available for you to use in your own policies? Moray. "To err is human.? To purr, feline" From domg472 at gmail.com Tue Dec 22 17:02:51 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 22 Dec 2009 18:02:51 +0100 Subject: General interface question In-Reply-To: <002d01ca8326$0f98aba0$2eca02e0$@Henderson@ict-software.org> References: <002d01ca8326$0f98aba0$2eca02e0$@Henderson@ict-software.org> Message-ID: <20091222170249.GB4242@localhost.localdomain> On Tue, Dec 22, 2009 at 04:44:40PM +0000, Moray Henderson wrote: > How do you find out what module interfaces are available for you to use > in your own policies? By looking into your modules .if (interface) file. That is also why it is important to have them in /usr/share/selinux/devel/include with the other .if files. Else you wont be able to use then in any case. So if you created/installed a module (.pp) and you suspect other (new self created) modules may need to interact with it. copy the modules .if file to the /usr/share/selinux/devel/include location. So that you will be able to use them. > > > Moray. > "To err is human.? To purr, feline" > > > > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Tue Dec 22 18:21:39 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 22 Dec 2009 19:21:39 +0100 Subject: General interface question In-Reply-To: <002d01ca8326$0f98aba0$2eca02e0$@Henderson@ict-software.org> References: <002d01ca8326$0f98aba0$2eca02e0$@Henderson@ict-software.org> Message-ID: <20091222182138.GC4242@localhost.localdomain> On Tue, Dec 22, 2009 at 04:44:40PM +0000, Moray Henderson wrote: > How do you find out what module interfaces are available for you to use > in your own policies? you can also fetch and prep the source rpm for selinux-policy and use the enclosed makefile to run make html, which will generate a html page with all interfaces, and their descriptions and info about how they can be used. an example of the output of make html can be found here: http://oss.tresys.com/docs/refpolicy/api/ plus you can also use eclipse-slide which is a slide plugin for selinux policy development. But the most easy way is to just grep -r /usr/share/selinux/devel/include and see the interface file for its contents. > > > Moray. > "To err is human.? To purr, feline" > > > > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From Moray.Henderson at ict-software.org Wed Dec 23 11:40:02 2009 From: Moray.Henderson at ict-software.org (Moray Henderson) Date: Wed, 23 Dec 2009 11:40:02 +0000 Subject: General interface question In-Reply-To: <20091222182138.GC4242@localhost.localdomain> References: <002d01ca8326$0f98aba0$2eca02e0$@Henderson@ict-software.org> <20091222182138.GC4242@localhost.localdomain> Message-ID: <000001ca83c4$ab1e5180$015af480$@Henderson@ict-software.org> Dominick Grift wrote: >On Tue, Dec 22, 2009 at 04:44:40PM +0000, Moray Henderson wrote: >> How do you find out what module interfaces are available for you to >> use in your own policies? > >you can also fetch and prep the source rpm for selinux-policy and use the >enclosed makefile to run make html, which will generate a html page with >all interfaces, and their descriptions and info about how they can be used. >an example of the output of make html can be found here: >http://oss.tresys.com/docs/refpolicy/api/ > >plus you can also use eclipse-slide which is a slide plugin for selinux >policy development. > >But the most easy way is to just grep -r /usr/share/selinux/devel/include >and see the interface file for its contents. Thanks for your replies - they were helpful. I'm slowly getting the hang of how refpolicy fits together. So far I have only needed to use 8 of the reserved words of SELinux policy language, so I must confess I find it a bit daunting to discover there are 5,419 available interfaces spread across 247 files in 5 subdirectories. I suppose the trick is to know what you're looking for, so that you can find the one bit you need without having to understand the whole lot. Moray. "To err is human.? To purr, feline" From domg472 at gmail.com Wed Dec 23 13:40:18 2009 From: domg472 at gmail.com (Dominick Grift) Date: Wed, 23 Dec 2009 14:40:18 +0100 Subject: General interface question In-Reply-To: <000001ca83c4$ab1e5180$015af480$@Henderson@ict-software.org> References: <002d01ca8326$0f98aba0$2eca02e0$@Henderson@ict-software.org> <20091222182138.GC4242@localhost.localdomain> <000001ca83c4$ab1e5180$015af480$@Henderson@ict-software.org> Message-ID: <20091223134016.GA3888@localhost.localdomain> On Wed, Dec 23, 2009 at 11:40:02AM +0000, Moray Henderson wrote: > Dominick Grift wrote: > >On Tue, Dec 22, 2009 at 04:44:40PM +0000, Moray Henderson wrote: > >> How do you find out what module interfaces are available for you to > >> use in your own policies? > > > >you can also fetch and prep the source rpm for selinux-policy and use > the > >enclosed makefile to run make html, which will generate a html page > with > >all interfaces, and their descriptions and info about how they can be > used. > >an example of the output of make html can be found here: > >http://oss.tresys.com/docs/refpolicy/api/ > > > >plus you can also use eclipse-slide which is a slide plugin for selinux > >policy development. > > > >But the most easy way is to just grep -r > /usr/share/selinux/devel/include > >and see the interface file for its contents. > > Thanks for your replies - they were helpful. I'm slowly getting the > hang of how refpolicy fits together. So far I have only needed to use 8 > of the reserved words of SELinux policy language, so I must confess I > find it a bit daunting to discover there are 5,419 available interfaces > spread across 247 files in 5 subdirectories. I suppose the trick is to > know what you're looking for, so that you can find the one bit you need > without having to understand the whole lot. Indeed. Knowing the structuring and style rules helps. These are actually important if you want to be able to maintain your policy. A bit of experience is sometimes helpful but the structure also tries to help for example the layers (the dirs in /usr/share/selinux/devel/include) If the target of the interaction is owned by a system service, you can look in the services layer. if it is owned by a userapp; apps. if user domain; roles and system. etc. Also the interface names should be prepended with the name of the module that provides it. This is also helpful if you want to determine in which module a interface is defined. Everything is carefully structured and grouped. This grouping and structuring is done for two reasons (atleast) - to keep source policy modules as small as possible. If you can group two lines or raw policy into one interface it saves one line of policy. With the amount of rules SELinux policy has this quickly saves much date for humans to sift throught. - to centralize policy. Instead of scathering similar policy pieces all over the place. define it in a central place. This means if policy changes, we only have to edit it in a single place and it gets automatically propagated across. Instead of having to edit policy all over the place for a minor change. any "macro" not specific to a target type can be found in /usr/share/selinux/devel/include/support. macros that group permissions (permission sets). Patterns: which are often used to define policy where the target type in a interaction is defined (declared) locally. > > > Moray. > "To err is human.? To purr, feline" > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jorge.fabregas at gmail.com Sat Dec 26 03:40:23 2009 From: jorge.fabregas at gmail.com (Jorge =?iso-8859-1?q?F=E1bregas?=) Date: Fri, 25 Dec 2009 23:40:23 -0400 Subject: No AVC when using non-standard SSH port Message-ID: <200912252340.23393.jorge.fabregas@gmail.com> Hello everyone, I'm using Fedora 12 and was wondering why, If I I run my sshd on a non- standard port...why don't SELinux registers an access violation? I see that "ssh_port_t" is there (attached to port 22) ... Is this not implemented yet for SSHD? Thanks, Jorge From cra at WPI.EDU Sat Dec 26 04:27:03 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 25 Dec 2009 23:27:03 -0500 Subject: No AVC when using non-standard SSH port In-Reply-To: <200912252340.23393.jorge.fabregas@gmail.com> References: <200912252340.23393.jorge.fabregas@gmail.com> Message-ID: <20091226042703.GA20553@angus.ind.WPI.EDU> On Fri, Dec 25, 2009 at 11:40:23PM -0400, Jorge F?bregas wrote: > I'm using Fedora 12 and was wondering why, If I I run my sshd on a non- > standard port...why don't SELinux registers an access violation? > > I see that "ssh_port_t" is there (attached to port 22) ... Is this not > implemented yet for SSHD? On F11, I was required to use this policy to bind sshd to a non-standard port. I haven't upgraded this particular system to F12 yet, so I'm not sure if it is required there. policy_module(sshd, 1.0) require { type sshd_t; } #============= sshd_t ============== corenet_tcp_bind_http_port(sshd_t) From domg472 at gmail.com Sat Dec 26 11:27:28 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 26 Dec 2009 12:27:28 +0100 Subject: No AVC when using non-standard SSH port In-Reply-To: <200912252340.23393.jorge.fabregas@gmail.com> References: <200912252340.23393.jorge.fabregas@gmail.com> Message-ID: <20091226112727.GA31930@localhost.localdomain> On Fri, Dec 25, 2009 at 11:40:23PM -0400, Jorge F?bregas wrote: > Hello everyone, > > I'm using Fedora 12 and was wondering why, If I I run my sshd on a non- > standard port...why don't SELinux registers an access violation? > > I see that "ssh_port_t" is there (attached to port 22) ... Is this not > implemented yet for SSHD? Hi, Good question. It seems that the policy maintainer decided to allow sshd_t to all unreserved ports. corenet_tcp_bind_all_unreserved_ports($1_t) in ssh_server_template services/ssh.if I dont know why and i rather not allow it to bind to all unreserved port by default either, > > Thanks, > Jorge > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mattdm at mattdm.org Sat Dec 26 12:41:56 2009 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 26 Dec 2009 07:41:56 -0500 Subject: No AVC when using non-standard SSH port In-Reply-To: <20091226112727.GA31930@localhost.localdomain> References: <200912252340.23393.jorge.fabregas@gmail.com> <20091226112727.GA31930@localhost.localdomain> Message-ID: <20091226124156.GA2289@jadzia.bu.edu> On Sat, Dec 26, 2009 at 12:27:28PM +0100, Dominick Grift wrote: > > I'm using Fedora 12 and was wondering why, If I I run my sshd on a non- > > standard port...why don't SELinux registers an access violation? > > I see that "ssh_port_t" is there (attached to port 22) ... Is this not > > implemented yet for SSHD? > Good question. It seems that the policy maintainer decided to allow sshd_t to all unreserved ports. > corenet_tcp_bind_all_unreserved_ports($1_t) in ssh_server_template services/ssh.if > I dont know why and i rather not allow it to bind to all unreserved port by default either, Possibly needed for ssh port forwarding? -- Matthew Miller mattdm at mattdm.org From k.lichtenwalder at computer.org Sun Dec 27 12:48:03 2009 From: k.lichtenwalder at computer.org (Klaus Lichtenwalder) Date: Sun, 27 Dec 2009 13:48:03 +0100 Subject: allow_exec{mem,stack} default to on? Message-ID: <1261918083.2611.11.camel@localhost> Hi, just checked to freshly installed Fedora 12 machines, and found allow_execmem --> on allow_execstack --> on Is there a reason for this, as the comment in semanage strongly discourages it? Or did I install a package that switches those booleans? Klaus -- ------------------------------------------------------------------------ Klaus Lichtenwalder, Dipl. Inform., http://lklaus.homelinux.org/Klaus/ PGP Key fingerprint: A5C0 F73A 2C83 96EE 766B 9C62 DB6D 1258 0E9B B6D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From domg472 at gmail.com Sun Dec 27 16:41:06 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sun, 27 Dec 2009 17:41:06 +0100 Subject: allow_exec{mem,stack} default to on? In-Reply-To: <1261918083.2611.11.camel@localhost> References: <1261918083.2611.11.camel@localhost> Message-ID: <20091227164104.GA22921@localhost.localdomain> On Sun, Dec 27, 2009 at 01:48:03PM +0100, Klaus Lichtenwalder wrote: > Hi, > > just checked to freshly installed Fedora 12 machines, and found > allow_execmem --> on > allow_execstack --> on > Is there a reason for this, as the comment in semanage strongly > discourages it? Or did I install a package that switches those booleans? I am not sure about the official reason but i think it is true that atleast execmem by unconfined_t is allowed by default. If you so desire you can switch it off. Personally i can imagine why these permissions are allowed by default for unconfined_t. unconfined_t is designed to be unconfined, thus in that theory execmem, execmod. execstack and execheap would be allowed by unrestricted processes. If you want to protect/restrict user processes, than consider defaulting to restricted user domains instead of unrestricted user domains. (just a general advise) > > Klaus > > -- > ------------------------------------------------------------------------ > Klaus Lichtenwalder, Dipl. Inform., http://lklaus.homelinux.org/Klaus/ > PGP Key fingerprint: A5C0 F73A 2C83 96EE 766B 9C62 DB6D 1258 0E9B B6D1 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Sun Dec 27 17:24:58 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sun, 27 Dec 2009 18:24:58 +0100 Subject: allow_exec{mem,stack} default to on? In-Reply-To: <1261918083.2611.11.camel@localhost> References: <1261918083.2611.11.camel@localhost> Message-ID: <20091227172456.GB22921@localhost.localdomain> On Sun, Dec 27, 2009 at 01:48:03PM +0100, Klaus Lichtenwalder wrote: > Hi, > > just checked to freshly installed Fedora 12 machines, and found > allow_execmem --> on > allow_execstack --> on > Is there a reason for this, as the comment in semanage strongly > discourages it? Or did I install a package that switches those booleans? By default SELinux is pretty permissive (much is allowed). However you can very much tighten the configuration. A few things to do: map all your Linux logins to confined SELinux users disable the unconfined module lock-down your booleans ...and much more... > > Klaus > > -- > ------------------------------------------------------------------------ > Klaus Lichtenwalder, Dipl. Inform., http://lklaus.homelinux.org/Klaus/ > PGP Key fingerprint: A5C0 F73A 2C83 96EE 766B 9C62 DB6D 1258 0E9B B6D1 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mica1884 at gmail.com Sun Dec 27 18:11:45 2009 From: mica1884 at gmail.com (Ryan Gandy) Date: Sun, 27 Dec 2009 13:11:45 -0500 Subject: allow_exec{mem,stack} default to on? In-Reply-To: <20091227172456.GB22921@localhost.localdomain> References: <1261918083.2611.11.camel@localhost> <20091227172456.GB22921@localhost.localdomain> Message-ID: <1df9930e0912271011w5ba20990i5808e7b2be1d5c45@mail.gmail.com> Hello Klaus, Personally I'd suggest turning off exec (mem, heap, stack); mapping your user role to staff_u and then disallowing unconfined logins; turning on secure_mode and secure_mode_policyload. setsebool -P should take care of that last from single user mode. ---------- Forwarded message ---------- From: Dominick Grift Date: Sun, Dec 27, 2009 at 12:24 PM Subject: Re: allow_exec{mem,stack} default to on? To: fedora-selinux-list at redhat.com On Sun, Dec 27, 2009 at 01:48:03PM +0100, Klaus Lichtenwalder wrote: > Hi, > > just checked to freshly installed Fedora 12 machines, and found > allow_execmem --> on > allow_execstack --> on > Is there a reason for this, as the comment in semanage strongly > discourages it? Or did I install a package that switches those booleans? By default SELinux is pretty permissive (much is allowed). However you can very much tighten the configuration. A few things to do: map all your Linux logins to confined SELinux users disable the unconfined module lock-down your booleans ...and much more... > > Klaus > > -- > ------------------------------------------------------------------------ > Klaus Lichtenwalder, Dipl. Inform., http://lklaus.homelinux.org/Klaus/ > PGP Key fingerprint: A5C0 F73A 2C83 96EE 766B 9C62 DB6D 1258 0E9B B6D1 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From k.lichtenwalder at computer.org Sun Dec 27 18:43:15 2009 From: k.lichtenwalder at computer.org (Klaus Lichtenwalder) Date: Sun, 27 Dec 2009 19:43:15 +0100 Subject: allow_exec{mem,stack} default to on? In-Reply-To: <1df9930e0912271011w5ba20990i5808e7b2be1d5c45@mail.gmail.com> References: <1261918083.2611.11.camel@localhost> <20091227172456.GB22921@localhost.localdomain> <1df9930e0912271011w5ba20990i5808e7b2be1d5c45@mail.gmail.com> Message-ID: <1261939395.2611.16.camel@localhost> Hi, thanks for all your answers. It's correct, if I wanted to go the secure road, I should map all users to some (more specific) role than is the default. Considering the situation I think I can stay with the default rights, as they are probably layed out fine (for default use, i.e. what I need :-) ) In the meantime, I found some boinc jobs, that need allow_execmem. Guess I can live with that, and will come back again when I start my first policies or refinements of some, I do have some on target, already, so beware ;-) Klaus On Sun, 2009-12-27 at 13:11 -0500, Ryan Gandy wrote: > Hello Klaus, > > Personally I'd suggest turning off exec (mem, heap, stack); mapping > your user role to staff_u and then disallowing unconfined logins; > turning on secure_mode and secure_mode_policyload. setsebool -P > should take care of that last from single > user mode. > > ---------- Forwarded message ---------- > From: Dominick Grift > Date: Sun, Dec 27, 2009 at 12:24 PM > Subject: Re: allow_exec{mem,stack} default to on? > To: fedora-selinux-list at redhat.com > > > On Sun, Dec 27, 2009 at 01:48:03PM +0100, Klaus Lichtenwalder wrote: > > > Hi, > > > > just checked to freshly installed Fedora 12 machines, and found > > allow_execmem --> on > > allow_execstack --> on > > Is there a reason for this, as the comment in semanage strongly > > discourages it? Or did I install a package that switches those > booleans? > > > By default SELinux is pretty permissive (much is allowed). However you > can very much tighten the configuration. > ... > > map all your Linux logins to confined SELinux users > disable the unconfined module > lock-down your booleans > ...and much more... -- ------------------------------------------------------------------------ Klaus Lichtenwalder, Dipl. Inform., http://lklaus.homelinux.org/Klaus/ PGP Key fingerprint: A5C0 F73A 2C83 96EE 766B 9C62 DB6D 1258 0E9B B6D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From empirical.humanist at gmail.com Mon Dec 28 23:21:44 2009 From: empirical.humanist at gmail.com (Kirk Lowery) Date: Mon, 28 Dec 2009 18:21:44 -0500 Subject: vbetool denied Message-ID: I'm running a newly installed, uptodate Fedora 12 box. Is there any reason by vbetools is denied? From dmesg: type=1400 audit(1262025694.652:4): avc: denied { mmap_zero } for pid=598 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 t class=memprotect Is this a problem with my local system, or a more general bug? And what is the best way to fix this? TIA! Kirk -------------- next part -------------- An HTML attachment was scrubbed... URL: From warner at rubix.com Mon Dec 28 23:29:02 2009 From: warner at rubix.com (Andy Warner) Date: Mon, 28 Dec 2009 18:29:02 -0500 Subject: newrole: double free or corruption Message-ID: <4B393F3E.1060403@rubix.com> Got the following output from using the newrole command on Fedora 12. Not sure where to properly report such bugs. If it helps, the rubix_remote_client_r role transition should fail (as it does) as there are no role transition rules for it. The role is associated with the current SELinux user. I believe my system just updated to the newest newrole package. [warner at Fedora12-Dev ~]$ yum info policycoreutils Loaded plugins: presto, refresh-packagekit Installed Packages Name : policycoreutils Arch : i686 Version : 2.0.78 Release : 3.fc12 Size : 3.3 M Repo : installed >From repo : updates Error output from newrole follows: [warner at Fedora12-Dev ~]$ newrole -r rubix_remote_client_r Password: failed to exec shell : Permission denied *** glibc detected *** newrole: double free or corruption (out): 0x01726138 *** ======= Backtrace: ========= /lib/libc.so.6(-0xff836d9f)[0x233261] /lib/libselinux.so.1(freecon+0x1e)[0x9fd42e] newrole(main+0x6eb)[0x119d6b] /lib/libc.so.6(__libc_start_main+0xe6)[0x1dbbb6] newrole(+0x16f1)[0x1186f1] ======= Memory map: ======== 00117000-0011d000 r-xp 00000000 fd:00 126525 /usr/bin/newrole 0011d000-0011e000 r--p 00005000 fd:00 126525 /usr/bin/newrole 0011e000-0011f000 rw-p 00006000 fd:00 126525 /usr/bin/newrole 0011f000-00135000 r-xp 00000000 fd:00 56679 /lib/libpthread-2.11.so 00135000-00136000 r--p 00015000 fd:00 56679 /lib/libpthread-2.11.so 00136000-00137000 rw-p 00016000 fd:00 56679 /lib/libpthread-2.11.so 00137000-00139000 rw-p 00000000 00:00 0 001a5000-001c3000 r-xp 00000000 fd:00 56677 /lib/ld-2.11.so 001c3000-001c4000 r--p 0001d000 fd:00 56677 /lib/ld-2.11.so 001c4000-001c5000 rw-p 0001e000 fd:00 56677 /lib/ld-2.11.so 001c5000-00333000 r-xp 00000000 fd:00 56678 /lib/libc-2.11.so 00333000-00334000 ---p 0016e000 fd:00 56678 /lib/libc-2.11.so 00334000-00336000 r--p 0016e000 fd:00 56678 /lib/libc-2.11.so 00336000-00337000 rw-p 00170000 fd:00 56678 /lib/libc-2.11.so 00337000-0033a000 rw-p 00000000 00:00 0 0055f000-00560000 r-xp 00000000 00:00 0 [vdso] 005f6000-005fa000 r-xp 00000000 fd:00 1331 /lib/libattr.so.1.1.0 005fa000-005fb000 rw-p 00003000 fd:00 1331 /lib/libattr.so.1.1.0 0062d000-00638000 r-xp 00000000 fd:00 10441 /lib/libnss_files-2.11.so 00638000-00639000 r--p 0000a000 fd:00 10441 /lib/libnss_files-2.11.so 00639000-0063a000 rw-p 0000b000 fd:00 10441 /lib/libnss_files-2.11.so 008a3000-008a5000 r-xp 00000000 fd:00 15448 /lib/libpam_misc.so.0.82.0 008a5000-008a6000 rw-p 00001000 fd:00 15448 /lib/libpam_misc.so.0.82.0 00928000-0092c000 r-xp 00000000 fd:00 1332 /lib/libcap.so.2.16 0092c000-0092d000 rw-p 00003000 fd:00 1332 /lib/libcap.so.2.16 00992000-00995000 r-xp 00000000 fd:00 56684 /lib/libdl-2.11.so 00995000-00996000 r--p 00002000 fd:00 56684 /lib/libdl-2.11.so 00996000-00997000 rw-p 00003000 fd:00 56684 /lib/libdl-2.11.so 009f3000-00a0f000 r-xp 00000000 fd:00 56687 /lib/libselinux.so.1 00a0f000-00a10000 r--p 0001b000 fd:00 56687 /lib/libselinux.so.1 00a10000-00a11000 rw-p 0001c000 fd:00 56687 /lib/libselinux.so.1 00c8b000-00c97000 r-xp 00000000 fd:00 15447 /lib/libpam.so.0.82.1 00c97000-00c98000 rw-p 0000b000 fd:00 15447 /lib/libpam.so.0.82.1 00e6f000-00e85000 r-xp 00000000 fd:00 15446 /lib/libaudit.so.1.0.0 00e85000-00e86000 r--p 00015000 fd:00 15446 /lib/libaudit.so.1.0.0 00e86000-00e87000 rw-p 00016000 fd:00 15446 /lib/libaudit.so.1.0.0 00ea9000-00ec6000 r-xp 00000000 fd:00 51325 /lib/libgcc_s-4.4.2-20091027.so.1 00ec6000-00ec7000 rw-p 0001c000 fd:00 51325 /lib/libgcc_s-4.4.2-20091027.so.1 00f05000-00f0c000 r-xp 00000000 fd:00 56680 /lib/librt-2.11.so 00f0c000-00f0d000 r--p 00006000 fd:00 56680 /lib/librt-2.11.so 00f0d000-00f0e000 rw-p 00007000 fd:00 56680 /lib/librt-2.11.so 01724000-017a9000 rw-p 00000000 00:00 0 [heap] b7627000-b7827000 r--p 00000000 fd:00 12545 /usr/lib/locale/locale-archive b7827000-b782a000 rw-p 00000000 00:00 0 b783b000-b7842000 r--s 00000000 fd:00 10739 /usr/lib/gconv/gconv-modules.cache b7842000-b7843000 rw-p 00000000 00:00 0 bfcce000-bfce3000 rw-p 00000000 00:00 0 [stack] [warner at Fedora12-Dev ~]$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tachyon.81 at googlemail.com Tue Dec 29 01:14:18 2009 From: tachyon.81 at googlemail.com (Antony Vennard) Date: Tue, 29 Dec 2009 01:14:18 +0000 Subject: Obtaining Source for Fedora SELinux policies Message-ID: <4B3957EA.5030408@googlemail.com> Hi All, This may seem like an obvious question but I'm yet to understand how I do it. How do I obtain the sources for the Fedora SELinux policy (targetted) used on my system and how do I grab the sources for the MLS policy should I want to look at that? I imagine this won't be too difficult to answer, I just can't seem to find the sources. Thanks, Antony -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: From kanarip at kanarip.com Tue Dec 29 01:38:11 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 29 Dec 2009 02:38:11 +0100 Subject: Obtaining Source for Fedora SELinux policies In-Reply-To: <4B3957EA.5030408@googlemail.com> References: <4B3957EA.5030408@googlemail.com> Message-ID: <4B395D83.4000707@kanarip.com> On 12/29/2009 02:14 AM, Antony Vennard wrote: > Hi All, > > This may seem like an obvious question but I'm yet to understand how I > do it. How do I obtain the sources for the Fedora SELinux policy > (targetted) used on my system and how do I grab the sources for the > MLS policy should I want to look at that? > The sources of whatever package installed on your system can be very easily retrieved by using the yumdownloader utility (part of the yum-utils package): yumdownloader --source -- Jeroen From jorge.fabregas at gmail.com Tue Dec 29 01:55:17 2009 From: jorge.fabregas at gmail.com (Jorge =?iso-8859-1?q?F=E1bregas?=) Date: Mon, 28 Dec 2009 21:55:17 -0400 Subject: No AVC when using non-standard SSH port In-Reply-To: <20091226124156.GA2289@jadzia.bu.edu> References: <200912252340.23393.jorge.fabregas@gmail.com> <20091226112727.GA31930@localhost.localdomain> <20091226124156.GA2289@jadzia.bu.edu> Message-ID: <200912282155.17752.jorge.fabregas@gmail.com> On Saturday 26 December 2009 08:41:56 Matthew Miller wrote: > Possibly needed for ssh port forwarding? I don't think this might be the reason. If someone's tech-savvy enough to do port forwarding, they might as well use semanage to add the custom ports... I'm still clueless on why it is like this on F12 :( Best regards, Jorge From gmaxwell at gmail.com Tue Dec 29 07:06:37 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Tue, 29 Dec 2009 02:06:37 -0500 Subject: No AVC when using non-standard SSH port In-Reply-To: <200912282155.17752.jorge.fabregas@gmail.com> References: <200912252340.23393.jorge.fabregas@gmail.com> <20091226112727.GA31930@localhost.localdomain> <20091226124156.GA2289@jadzia.bu.edu> <200912282155.17752.jorge.fabregas@gmail.com> Message-ID: 2009/12/28 Jorge F?bregas : > On Saturday 26 December 2009 08:41:56 Matthew Miller wrote: >> Possibly needed for ssh port forwarding? > > I don't think this might be the reason. If someone's tech-savvy enough to do > port forwarding, they might as well use semanage to add the custom ports... > I'm still clueless on why it is like this on F12 :( Er. Port forwarding is a normal user-visible SSH feature which has been historically enabled. The person using it may not have the authority to change the SE linux permissions. OTOH, I think GatewayPorts defaults to no. So SELinux could back that up and restrict non-22 listens to localhost without changing the SSH default configuration. Also, listens on privileged ports (<=1024) are denied for non-root users so denying that in the SELinux policy wouldn't be harmful. It might be handy to add comments to the relevant configuration files mentioning the SELinux limitations. It can be rather annoying when you change a setting only to have the change mooted by some SELinux imposed limitation. Some simple comments would go a long way in reducing confusions. From k.lichtenwalder at computer.org Tue Dec 29 09:17:36 2009 From: k.lichtenwalder at computer.org (Klaus Lichtenwalder) Date: Tue, 29 Dec 2009 10:17:36 +0100 Subject: policy for mgetty fax receive and new_fax Message-ID: <1262078256.12219.3.camel@localhost> Hi, just tried receiving a fax with mgetty (and notifying me via email with the attached fax) Watching all denials flowing by (permissive mode, selinux-policy-targeted-3.6.32-59.fc12.noarch) I'm wondering whether someone already started preparing a policy or whether I should try to start it on myself? Anyone knows? Google does not find much of value Klaus -- ------------------------------------------------------------------------ Klaus Lichtenwalder, Dipl. Inform., http://lklaus.homelinux.org/Klaus/ PGP Key fingerprint: A5C0 F73A 2C83 96EE 766B 9C62 DB6D 1258 0E9B B6D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From domg472 at gmail.com Tue Dec 29 10:53:09 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 29 Dec 2009 11:53:09 +0100 Subject: vbetool denied In-Reply-To: References: Message-ID: <20091229105307.GA20705@localhost.localdomain> On Mon, Dec 28, 2009 at 06:21:44PM -0500, Kirk Lowery wrote: > I'm running a newly installed, uptodate Fedora 12 box. Is there any reason > by vbetools is denied? From dmesg: > > type=1400 audit(1262025694.652:4): avc: denied { mmap_zero } for pid=598 > comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 t > class=memprotect > > Is this a problem with my local system, or a more general bug? And what is > the best way to fix this? setsebool -P mmap_low_allowed on That would (most likely) allow vbetool and any other program requiring it. I just ignore that AVC denial on my system. I dont want it to have this access. It still seems to work fine though. So, it is not really a bug (atleast the issue is know). But the permission that is required is disallowed by default. The command i pasted above would allow it. > > TIA! > > Kirk > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Tue Dec 29 10:57:01 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 29 Dec 2009 11:57:01 +0100 Subject: newrole: double free or corruption In-Reply-To: <4B393F3E.1060403@rubix.com> References: <4B393F3E.1060403@rubix.com> Message-ID: <20091229105700.GB20705@localhost.localdomain> On Mon, Dec 28, 2009 at 06:29:02PM -0500, Andy Warner wrote: > Got the following output from using the newrole command on Fedora 12. > Not sure where to properly report such bugs. > > If it helps, the rubix_remote_client_r role transition should fail (as > it does) as there are no role transition rules for it. The role is > associated with the current SELinux user. > > I believe my system just updated to the newest newrole package. > [warner at Fedora12-Dev ~]$ yum info policycoreutils > Loaded plugins: presto, refresh-packagekit > Installed Packages > Name : policycoreutils > Arch : i686 > Version : 2.0.78 > Release : 3.fc12 > Size : 3.3 M > Repo : installed > >From repo : updates > > Error output from newrole follows: > > [warner at Fedora12-Dev ~]$ newrole -r rubix_remote_client_r Does it behave as expected if you use sudo instead? sudo -r rubix_remote_client_r -t rubix_remote_client_t -s Eitherway looks like a bug in newrole > Password: > failed to exec shell > : Permission denied > *** glibc detected *** newrole: double free or corruption (out): > 0x01726138 *** > ======= Backtrace: ========= > /lib/libc.so.6(-0xff836d9f)[0x233261] > /lib/libselinux.so.1(freecon+0x1e)[0x9fd42e] > newrole(main+0x6eb)[0x119d6b] > /lib/libc.so.6(__libc_start_main+0xe6)[0x1dbbb6] > newrole(+0x16f1)[0x1186f1] > ======= Memory map: ======== > 00117000-0011d000 r-xp 00000000 fd:00 126525 /usr/bin/newrole > 0011d000-0011e000 r--p 00005000 fd:00 126525 /usr/bin/newrole > 0011e000-0011f000 rw-p 00006000 fd:00 126525 /usr/bin/newrole > 0011f000-00135000 r-xp 00000000 fd:00 56679 /lib/libpthread-2.11.so > 00135000-00136000 r--p 00015000 fd:00 56679 /lib/libpthread-2.11.so > 00136000-00137000 rw-p 00016000 fd:00 56679 /lib/libpthread-2.11.so > 00137000-00139000 rw-p 00000000 00:00 0 > 001a5000-001c3000 r-xp 00000000 fd:00 56677 /lib/ld-2.11.so > 001c3000-001c4000 r--p 0001d000 fd:00 56677 /lib/ld-2.11.so > 001c4000-001c5000 rw-p 0001e000 fd:00 56677 /lib/ld-2.11.so > 001c5000-00333000 r-xp 00000000 fd:00 56678 /lib/libc-2.11.so > 00333000-00334000 ---p 0016e000 fd:00 56678 /lib/libc-2.11.so > 00334000-00336000 r--p 0016e000 fd:00 56678 /lib/libc-2.11.so > 00336000-00337000 rw-p 00170000 fd:00 56678 /lib/libc-2.11.so > 00337000-0033a000 rw-p 00000000 00:00 0 > 0055f000-00560000 r-xp 00000000 00:00 0 [vdso] > 005f6000-005fa000 r-xp 00000000 fd:00 1331 /lib/libattr.so.1.1.0 > 005fa000-005fb000 rw-p 00003000 fd:00 1331 /lib/libattr.so.1.1.0 > 0062d000-00638000 r-xp 00000000 fd:00 10441 /lib/libnss_files-2.11.so > 00638000-00639000 r--p 0000a000 fd:00 10441 /lib/libnss_files-2.11.so > 00639000-0063a000 rw-p 0000b000 fd:00 10441 /lib/libnss_files-2.11.so > 008a3000-008a5000 r-xp 00000000 fd:00 15448 /lib/libpam_misc.so.0.82.0 > 008a5000-008a6000 rw-p 00001000 fd:00 15448 /lib/libpam_misc.so.0.82.0 > 00928000-0092c000 r-xp 00000000 fd:00 1332 /lib/libcap.so.2.16 > 0092c000-0092d000 rw-p 00003000 fd:00 1332 /lib/libcap.so.2.16 > 00992000-00995000 r-xp 00000000 fd:00 56684 /lib/libdl-2.11.so > 00995000-00996000 r--p 00002000 fd:00 56684 /lib/libdl-2.11.so > 00996000-00997000 rw-p 00003000 fd:00 56684 /lib/libdl-2.11.so > 009f3000-00a0f000 r-xp 00000000 fd:00 56687 /lib/libselinux.so.1 > 00a0f000-00a10000 r--p 0001b000 fd:00 56687 /lib/libselinux.so.1 > 00a10000-00a11000 rw-p 0001c000 fd:00 56687 /lib/libselinux.so.1 > 00c8b000-00c97000 r-xp 00000000 fd:00 15447 /lib/libpam.so.0.82.1 > 00c97000-00c98000 rw-p 0000b000 fd:00 15447 /lib/libpam.so.0.82.1 > 00e6f000-00e85000 r-xp 00000000 fd:00 15446 /lib/libaudit.so.1.0.0 > 00e85000-00e86000 r--p 00015000 fd:00 15446 /lib/libaudit.so.1.0.0 > 00e86000-00e87000 rw-p 00016000 fd:00 15446 /lib/libaudit.so.1.0.0 > 00ea9000-00ec6000 r-xp 00000000 fd:00 51325 > /lib/libgcc_s-4.4.2-20091027.so.1 > 00ec6000-00ec7000 rw-p 0001c000 fd:00 51325 > /lib/libgcc_s-4.4.2-20091027.so.1 > 00f05000-00f0c000 r-xp 00000000 fd:00 56680 /lib/librt-2.11.so > 00f0c000-00f0d000 r--p 00006000 fd:00 56680 /lib/librt-2.11.so > 00f0d000-00f0e000 rw-p 00007000 fd:00 56680 /lib/librt-2.11.so > 01724000-017a9000 rw-p 00000000 00:00 0 [heap] > b7627000-b7827000 r--p 00000000 fd:00 12545 > /usr/lib/locale/locale-archive > b7827000-b782a000 rw-p 00000000 00:00 0 > b783b000-b7842000 r--s 00000000 fd:00 10739 > /usr/lib/gconv/gconv-modules.cache > b7842000-b7843000 rw-p 00000000 00:00 0 > bfcce000-bfce3000 rw-p 00000000 00:00 0 [stack] > [warner at Fedora12-Dev ~]$ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Tue Dec 29 11:05:42 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 29 Dec 2009 12:05:42 +0100 Subject: Obtaining Source for Fedora SELinux policies In-Reply-To: <4B3957EA.5030408@googlemail.com> References: <4B3957EA.5030408@googlemail.com> Message-ID: <20091229110540.GC20705@localhost.localdomain> On Tue, Dec 29, 2009 at 01:14:18AM +0000, Antony Vennard wrote: > Hi All, > > This may seem like an obvious question but I'm yet to understand how I > do it. How do I obtain the sources for the Fedora SELinux policy > (targetted) used on my system and how do I grab the sources for the > MLS policy should I want to look at that? The source for both models is one and the same. it is in the selinux-policy-{%version}.src.rpm (available on mirrors or koji) example: http://ftp.tudelft.nl/download.fedora.redhat.com/linux/updates/12/SRPMS/selinux-policy-3.6.32-59.fc12.src.rpm I usually extract (cpio) the src rpm and apply the included patch. I use a simple ugly shell script to fetch / prep the latest selinux-policy sources and if possible create a diff of a previous version: http://82.197.205.60/~dgrift/cgi-bin/test.cgi?option=projects¶m=sepoldiff > > I imagine this won't be too difficult to answer, I just can't seem to > find the sources. > > Thanks, > > Antony > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Tue Dec 29 11:16:01 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 29 Dec 2009 12:16:01 +0100 Subject: policy for mgetty fax receive and new_fax In-Reply-To: <1262078256.12219.3.camel@localhost> References: <1262078256.12219.3.camel@localhost> Message-ID: <20091229111559.GD20705@localhost.localdomain> On Tue, Dec 29, 2009 at 10:17:36AM +0100, Klaus Lichtenwalder wrote: > Hi, > > just tried receiving a fax with mgetty (and notifying me via email with > the attached fax) > Watching all denials flowing by (permissive mode, > selinux-policy-targeted-3.6.32-59.fc12.noarch) I'm wondering whether > someone already started preparing a policy or whether I should try to > start it on myself? Anyone knows? Google does not find much of value Can you show us the AVC denials? > > Klaus > -- > ------------------------------------------------------------------------ > Klaus Lichtenwalder, Dipl. Inform., http://lklaus.homelinux.org/Klaus/ > PGP Key fingerprint: A5C0 F73A 2C83 96EE 766B 9C62 DB6D 1258 0E9B B6D1 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Tue Dec 29 11:26:01 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 29 Dec 2009 12:26:01 +0100 Subject: No AVC when using non-standard SSH port In-Reply-To: References: <200912252340.23393.jorge.fabregas@gmail.com> <20091226112727.GA31930@localhost.localdomain> <20091226124156.GA2289@jadzia.bu.edu> <200912282155.17752.jorge.fabregas@gmail.com> Message-ID: <20091229112600.GE20705@localhost.localdomain> On Tue, Dec 29, 2009 at 02:06:37AM -0500, Gregory Maxwell wrote: > 2009/12/28 Jorge F?bregas : > > On Saturday 26 December 2009 08:41:56 Matthew Miller wrote: > >> Possibly needed for ssh port forwarding? > > > > I don't think this might be the reason. If someone's tech-savvy enough to do > > port forwarding, they might as well use semanage to add the custom ports... > > I'm still clueless on why it is like this on F12 :( > > Er. Port forwarding is a normal user-visible SSH feature which has > been historically enabled. The person using it may not have the > authority to change the SE linux permissions. > > OTOH, I think GatewayPorts defaults to no. So SELinux could back that > up and restrict non-22 listens to localhost without changing the SSH > default configuration. Also, listens on privileged ports (<=1024) are > denied for non-root users so denying that in the SELinux policy > wouldn't be harmful. As far as i can tell SELinux only allows bind access to unreserved ports. I think that means > 1024. (not sure though) > > It might be handy to add comments to the relevant configuration files > mentioning the SELinux limitations. It can be rather annoying when you > change a setting only to have the change mooted by some SELinux > imposed limitation. Some simple comments would go a long way in > reducing confusions. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From k.lichtenwalder at computer.org Tue Dec 29 11:27:56 2009 From: k.lichtenwalder at computer.org (Klaus Lichtenwalder) Date: Tue, 29 Dec 2009 12:27:56 +0100 Subject: policy for mgetty fax receive and new_fax In-Reply-To: <20091229111559.GD20705@localhost.localdomain> References: <1262078256.12219.3.camel@localhost> <20091229111559.GD20705@localhost.localdomain> Message-ID: <1262086076.12219.17.camel@localhost> Am Dienstag, den 29.12.2009, 12:16 +0100 schrieb Dominick Grift: > On Tue, Dec 29, 2009 at 10:17:36AM +0100, Klaus Lichtenwalder wrote: > > Hi, > > > > just tried receiving a fax with mgetty (and notifying me via email with > > the attached fax) > > Watching all denials flowing by (permissive mode, > > selinux-policy-targeted-3.6.32-59.fc12.noarch) I'm wondering whether > > someone already started preparing a policy or whether I should try to > > start it on myself? Anyone knows? Google does not find much of value > > Can you show us the AVC denials? Sure, no problem. One thing, as a first step I put new_fax into bin_t, as this was a suggestion from sealert output. I do think this probably does not belong to the getty policy, as mgetty, receiving a fax, does far more than standard getty, imho. Klaus -- ------------------------------------------------------------------------ Klaus Lichtenwalder, Dipl. Inform., http://lklaus.homelinux.org/Klaus/ PGP Key fingerprint: A5C0 F73A 2C83 96EE 766B 9C62 DB6D 1258 0E9B B6D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: MGETTY-POL Type: text/x-vhdl Size: 7278 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From domg472 at gmail.com Tue Dec 29 11:46:49 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 29 Dec 2009 12:46:49 +0100 Subject: policy for mgetty fax receive and new_fax In-Reply-To: <1262086076.12219.17.camel@localhost> References: <1262078256.12219.3.camel@localhost> <20091229111559.GD20705@localhost.localdomain> <1262086076.12219.17.camel@localhost> Message-ID: <20091229114648.GF20705@localhost.localdomain> On Tue, Dec 29, 2009 at 12:27:56PM +0100, Klaus Lichtenwalder wrote: > Am Dienstag, den 29.12.2009, 12:16 +0100 schrieb Dominick Grift: > > On Tue, Dec 29, 2009 at 10:17:36AM +0100, Klaus Lichtenwalder wrote: > > > Hi, > > > > > > just tried receiving a fax with mgetty (and notifying me via email with > > > the attached fax) > > > Watching all denials flowing by (permissive mode, > > > selinux-policy-targeted-3.6.32-59.fc12.noarch) I'm wondering whether > > > someone already started preparing a policy or whether I should try to > > > start it on myself? Anyone knows? Google does not find much of value > > > > Can you show us the AVC denials? > > Sure, no problem. One thing, as a first step I put new_fax into bin_t, > as this was a suggestion from sealert output. > I do think this probably does not belong to the getty policy, as mgetty, > receiving a fax, does far more than standard getty, imho. echo "policy_module(mygetty, 1.0.0)" > mygetty.te; echo "optional_policy(\`" >> mygetty.te; echo "gen_require(\`" >> mygetty.te; echo "type getty_t;" >> mygetty.te; echo "')" >> mygetty.te; echo "corecmd_exec_shell(getty_t)" >> mygetty.te; echo "')" >> mygetty.te; make -f /usr/share/selinux/devel/Makefile mygetty.pp sudo semodule -i mygetty.pp See if this solves your issue > > Klaus > -- > ------------------------------------------------------------------------ > Klaus Lichtenwalder, Dipl. Inform., http://lklaus.homelinux.org/Klaus/ > PGP Key fingerprint: A5C0 F73A 2C83 96EE 766B 9C62 DB6D 1258 0E9B B6D1 > > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.657:57496): arch=c000003e syscall=59 success=yes exit=0 a0=3273d3ace3 a1=7fffef415d60 a2=7fffef418a30 a3=7f0863d089d0 items=0 ppid=31795 pid=1283 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="sh" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.657:57496): avc: denied { execute_no_trans } for pid=1283 comm="mgetty" path="/bin/bash" dev=dm-6 ino=12628 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file > type=AVC msg=audit(1262016758.657:57496): avc: denied { read open } for pid=1283 comm="mgetty" name="bash" dev=dm-6 ino=12628 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file > type=AVC msg=audit(1262016758.657:57496): avc: denied { execute } for pid=1283 comm="mgetty" name="bash" dev=dm-6 ino=12628 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.659:57497): arch=c000003e syscall=2 success=yes exit=3 a0=3273d3c1f2 a1=0 a2=1b6 a3=2 items=0 ppid=31795 pid=1283 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="sh" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.659:57497): avc: denied { open } for pid=1283 comm="sh" name="meminfo" dev=proc ino=4026531984 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file > type=AVC msg=audit(1262016758.659:57497): avc: denied { read } for pid=1283 comm="sh" name="meminfo" dev=proc ino=4026531984 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.661:57498): arch=c000003e syscall=5 success=yes exit=128 a0=3 a1=7fff05edb290 a2=7fff05edb290 a3=2 items=0 ppid=31795 pid=1283 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="sh" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.661:57498): avc: denied { getattr } for pid=1283 comm="sh" path="/proc/meminfo" dev=proc ino=4026531984 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.662:57499): arch=c000003e syscall=4 success=yes exit=128 a0=1090ab0 a1=7fff05edd2e0 a2=7fff05edd2e0 a3=8 items=0 ppid=31795 pid=1283 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="sh" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.662:57499): avc: denied { getattr } for pid=1283 comm="sh" path="/bin/bash" dev=dm-6 ino=12628 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.664:57500): arch=c000003e syscall=59 success=yes exit=0 a0=1093a10 a1=1093b30 a2=1092b20 a3=18 items=0 ppid=1283 pid=1286 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.postfix" subj=system_u:system_r:system_mail_t:s0 key=(null) > type=AVC msg=audit(1262016758.664:57500): avc: denied { read write } for pid=1286 comm="sendmail" name="ttyS0" dev=tmpfs ino=2217 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.806:57501): arch=c000003e syscall=2 success=yes exit=0 a0=3273d3c1f2 a1=0 a2=1b6 a3=2 items=0 ppid=1288 pid=1289 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="sh" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.806:57501): avc: denied { open } for pid=1289 comm="sh" name="meminfo" dev=proc ino=4026531984 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file > type=AVC msg=audit(1262016758.806:57501): avc: denied { read } for pid=1289 comm="sh" name="meminfo" dev=proc ino=4026531984 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.807:57502): arch=c000003e syscall=5 success=yes exit=128 a0=0 a1=7fff44b52830 a2=7fff44b52830 a3=2 items=0 ppid=1288 pid=1289 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="sh" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.807:57502): avc: denied { getattr } for pid=1289 comm="sh" path="/proc/meminfo" dev=proc ino=4026531984 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.809:57503): arch=c000003e syscall=59 success=yes exit=0 a0=eb55b0 a1=eb5480 a2=eb3e50 a3=30 items=0 ppid=1289 pid=1291 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="new_fax" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.809:57503): avc: denied { execute_no_trans } for pid=1291 comm="sh" path="/etc/mgetty+sendfax/new_fax" dev=dm-6 ino=51 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file > type=AVC msg=audit(1262016758.809:57503): avc: denied { read open } for pid=1291 comm="sh" name="new_fax" dev=dm-6 ino=51 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file > type=AVC msg=audit(1262016758.809:57503): avc: denied { execute } for pid=1291 comm="sh" name="new_fax" dev=dm-6 ino=51 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.817:57504): arch=c000003e syscall=16 success=no exit=-25 a0=3 a1=5401 a2=7fffcdc622a0 a3=2 items=0 ppid=1289 pid=1291 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="new_fax" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.817:57504): avc: denied { ioctl } for pid=1291 comm="new_fax" path="/etc/mgetty+sendfax/new_fax" dev=dm-6 ino=51 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.817:57505): arch=c000003e syscall=5 success=yes exit=0 a0=ff a1=7fffcdc62370 a2=7fffcdc62370 a3=0 items=0 ppid=1289 pid=1291 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="new_fax" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.817:57505): avc: denied { getattr } for pid=1291 comm="new_fax" path="/etc/mgetty+sendfax/new_fax" dev=dm-6 ino=51 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Tue Dec 29 12:02:02 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 29 Dec 2009 13:02:02 +0100 Subject: policy for mgetty fax receive and new_fax In-Reply-To: <1262086076.12219.17.camel@localhost> References: <1262078256.12219.3.camel@localhost> <20091229111559.GD20705@localhost.localdomain> <1262086076.12219.17.camel@localhost> Message-ID: <20091229120201.GG20705@localhost.localdomain> On Tue, Dec 29, 2009 at 12:27:56PM +0100, Klaus Lichtenwalder wrote: > Am Dienstag, den 29.12.2009, 12:16 +0100 schrieb Dominick Grift: > > On Tue, Dec 29, 2009 at 10:17:36AM +0100, Klaus Lichtenwalder wrote: > > > Hi, > > > > > > just tried receiving a fax with mgetty (and notifying me via email with > > > the attached fax) > > > Watching all denials flowing by (permissive mode, > > > selinux-policy-targeted-3.6.32-59.fc12.noarch) I'm wondering whether > > > someone already started preparing a policy or whether I should try to > > > start it on myself? Anyone knows? Google does not find much of value > > > > Can you show us the AVC denials? > > Sure, no problem. One thing, as a first step I put new_fax into bin_t, > as this was a suggestion from sealert output. > I do think this probably does not belong to the getty policy, as mgetty, > receiving a fax, does far more than standard getty, imho. Whoops i forgot some policy: echo "policy_module(mygetty, 1.0.0)" > mygetty.te; echo "optional_policy(\`" >> mygetty.te; echo "gen_require(\`" >> mygetty.te; echo "type getty_t;" >> mygetty.te; echo "')" >> mygetty.te; echo "corecmd_exec_bin(getty_t)" >> mygetty.te; echo "corecmd_exec_shell(getty_t)" >> mygetty.te; echo "kernel_read_system_state(getty_t)" >> mygetty.te; echo "')" >> mygetty.te; make -f /usr/share/selinux/devel/Makefile mygetty.pp sudo semodule -i mygetty.pp As for system_mail_t: echo "policy_module(mymail, 1.0.0)" > mymail.te; echo "optional_policy(\`" >> mymail.te; echo "gen_require(\`" >> mymail.te; echo "type system_mail_t;" >> mymail.te; echo "')" >> mymail.te; echo "term_use_unallocated_ttys(system_mail_t)" >> mymail.te; echo "')" >> mymail.te; make -f /usr/share/selinux/devel/Makefile mymail.pp sudo semodule -i mymail.pp That should help. > > Klaus > -- > ------------------------------------------------------------------------ > Klaus Lichtenwalder, Dipl. Inform., http://lklaus.homelinux.org/Klaus/ > PGP Key fingerprint: A5C0 F73A 2C83 96EE 766B 9C62 DB6D 1258 0E9B B6D1 > > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.657:57496): arch=c000003e syscall=59 success=yes exit=0 a0=3273d3ace3 a1=7fffef415d60 a2=7fffef418a30 a3=7f0863d089d0 items=0 ppid=31795 pid=1283 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="sh" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.657:57496): avc: denied { execute_no_trans } for pid=1283 comm="mgetty" path="/bin/bash" dev=dm-6 ino=12628 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file > type=AVC msg=audit(1262016758.657:57496): avc: denied { read open } for pid=1283 comm="mgetty" name="bash" dev=dm-6 ino=12628 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file > type=AVC msg=audit(1262016758.657:57496): avc: denied { execute } for pid=1283 comm="mgetty" name="bash" dev=dm-6 ino=12628 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.659:57497): arch=c000003e syscall=2 success=yes exit=3 a0=3273d3c1f2 a1=0 a2=1b6 a3=2 items=0 ppid=31795 pid=1283 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="sh" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.659:57497): avc: denied { open } for pid=1283 comm="sh" name="meminfo" dev=proc ino=4026531984 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file > type=AVC msg=audit(1262016758.659:57497): avc: denied { read } for pid=1283 comm="sh" name="meminfo" dev=proc ino=4026531984 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.661:57498): arch=c000003e syscall=5 success=yes exit=128 a0=3 a1=7fff05edb290 a2=7fff05edb290 a3=2 items=0 ppid=31795 pid=1283 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="sh" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.661:57498): avc: denied { getattr } for pid=1283 comm="sh" path="/proc/meminfo" dev=proc ino=4026531984 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.662:57499): arch=c000003e syscall=4 success=yes exit=128 a0=1090ab0 a1=7fff05edd2e0 a2=7fff05edd2e0 a3=8 items=0 ppid=31795 pid=1283 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="sh" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.662:57499): avc: denied { getattr } for pid=1283 comm="sh" path="/bin/bash" dev=dm-6 ino=12628 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.664:57500): arch=c000003e syscall=59 success=yes exit=0 a0=1093a10 a1=1093b30 a2=1092b20 a3=18 items=0 ppid=1283 pid=1286 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.postfix" subj=system_u:system_r:system_mail_t:s0 key=(null) > type=AVC msg=audit(1262016758.664:57500): avc: denied { read write } for pid=1286 comm="sendmail" name="ttyS0" dev=tmpfs ino=2217 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.806:57501): arch=c000003e syscall=2 success=yes exit=0 a0=3273d3c1f2 a1=0 a2=1b6 a3=2 items=0 ppid=1288 pid=1289 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="sh" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.806:57501): avc: denied { open } for pid=1289 comm="sh" name="meminfo" dev=proc ino=4026531984 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file > type=AVC msg=audit(1262016758.806:57501): avc: denied { read } for pid=1289 comm="sh" name="meminfo" dev=proc ino=4026531984 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.807:57502): arch=c000003e syscall=5 success=yes exit=128 a0=0 a1=7fff44b52830 a2=7fff44b52830 a3=2 items=0 ppid=1288 pid=1289 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="sh" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.807:57502): avc: denied { getattr } for pid=1289 comm="sh" path="/proc/meminfo" dev=proc ino=4026531984 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.809:57503): arch=c000003e syscall=59 success=yes exit=0 a0=eb55b0 a1=eb5480 a2=eb3e50 a3=30 items=0 ppid=1289 pid=1291 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="new_fax" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.809:57503): avc: denied { execute_no_trans } for pid=1291 comm="sh" path="/etc/mgetty+sendfax/new_fax" dev=dm-6 ino=51 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file > type=AVC msg=audit(1262016758.809:57503): avc: denied { read open } for pid=1291 comm="sh" name="new_fax" dev=dm-6 ino=51 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file > type=AVC msg=audit(1262016758.809:57503): avc: denied { execute } for pid=1291 comm="sh" name="new_fax" dev=dm-6 ino=51 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.817:57504): arch=c000003e syscall=16 success=no exit=-25 a0=3 a1=5401 a2=7fffcdc622a0 a3=2 items=0 ppid=1289 pid=1291 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="new_fax" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.817:57504): avc: denied { ioctl } for pid=1291 comm="new_fax" path="/etc/mgetty+sendfax/new_fax" dev=dm-6 ino=51 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file > ---- > time->Mon Dec 28 17:12:38 2009 > type=SYSCALL msg=audit(1262016758.817:57505): arch=c000003e syscall=5 success=yes exit=0 a0=ff a1=7fffcdc62370 a2=7fffcdc62370 a3=0 items=0 ppid=1289 pid=1291 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="new_fax" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(1262016758.817:57505): avc: denied { getattr } for pid=1291 comm="new_fax" path="/etc/mgetty+sendfax/new_fax" dev=dm-6 ino=51 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From k.lichtenwalder at computer.org Tue Dec 29 12:52:16 2009 From: k.lichtenwalder at computer.org (Klaus Lichtenwalder) Date: Tue, 29 Dec 2009 13:52:16 +0100 Subject: policy for mgetty fax receive and new_fax In-Reply-To: <20091229120201.GG20705@localhost.localdomain> References: <1262078256.12219.3.camel@localhost> <20091229111559.GD20705@localhost.localdomain> <1262086076.12219.17.camel@localhost> <20091229120201.GG20705@localhost.localdomain> Message-ID: <1262091136.12219.20.camel@localhost> Dominick, Am Dienstag, den 29.12.2009, 13:02 +0100 schrieb Dominick Grift: > Whoops i forgot some policy: Ok, I was already wondering whether that could be it, trying to understand :-) > > echo "policy_module(mygetty, 1.0.0)" > mygetty.te; > echo "optional_policy(\`" >> mygetty.te; > echo "gen_require(\`" >> mygetty.te; > echo "type getty_t;" >> mygetty.te; > echo "')" >> mygetty.te; > echo "corecmd_exec_bin(getty_t)" >> mygetty.te; > echo "corecmd_exec_shell(getty_t)" >> mygetty.te; > echo "kernel_read_system_state(getty_t)" >> mygetty.te; > echo "')" >> mygetty.te; > > make -f /usr/share/selinux/devel/Makefile mygetty.pp > sudo semodule -i mygetty.pp > > As for system_mail_t: > > echo "policy_module(mymail, 1.0.0)" > mymail.te; > echo "optional_policy(\`" >> mymail.te; > echo "gen_require(\`" >> mymail.te; > echo "type system_mail_t;" >> mymail.te; > echo "')" >> mymail.te; > echo "term_use_unallocated_ttys(system_mail_t)" >> mymail.te; > echo "')" >> mymail.te; > > make -f /usr/share/selinux/devel/Makefile mymail.pp > sudo semodule -i mymail.pp > > That should help. This helps a lot, as fax receiving (and notifying) works without AVC denials showing up. No I'm off trying to understand everything. With all those makros, one get's a lot done with little code :-) Thanks again Klaus -- ------------------------------------------------------------------------ Klaus Lichtenwalder, Dipl. Inform., http://lklaus.homelinux.org/Klaus/ PGP Key fingerprint: A5C0 F73A 2C83 96EE 766B 9C62 DB6D 1258 0E9B B6D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From domg472 at gmail.com Tue Dec 29 13:06:01 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 29 Dec 2009 14:06:01 +0100 Subject: policy for mgetty fax receive and new_fax In-Reply-To: <1262091136.12219.20.camel@localhost> References: <1262078256.12219.3.camel@localhost> <20091229111559.GD20705@localhost.localdomain> <1262086076.12219.17.camel@localhost> <20091229120201.GG20705@localhost.localdomain> <1262091136.12219.20.camel@localhost> Message-ID: <4B39FEB9.5010000@gmail.com> On 12/29/2009 01:52 PM, Klaus Lichtenwalder wrote: > Dominick, > > Am Dienstag, den 29.12.2009, 13:02 +0100 schrieb Dominick Grift: > >> Whoops i forgot some policy: > > Ok, I was already wondering whether that could be it, trying to > understand :-) > >> >> echo "policy_module(mygetty, 1.0.0)" > mygetty.te; >> echo "optional_policy(\`" >> mygetty.te; >> echo "gen_require(\`" >> mygetty.te; >> echo "type getty_t;" >> mygetty.te; >> echo "')" >> mygetty.te; >> echo "corecmd_exec_bin(getty_t)" >> mygetty.te; >> echo "corecmd_exec_shell(getty_t)" >> mygetty.te; >> echo "kernel_read_system_state(getty_t)" >> mygetty.te; >> echo "')" >> mygetty.te; >> >> make -f /usr/share/selinux/devel/Makefile mygetty.pp >> sudo semodule -i mygetty.pp >> >> As for system_mail_t: >> >> echo "policy_module(mymail, 1.0.0)" > mymail.te; >> echo "optional_policy(\`" >> mymail.te; >> echo "gen_require(\`" >> mymail.te; >> echo "type system_mail_t;" >> mymail.te; >> echo "')" >> mymail.te; >> echo "term_use_unallocated_ttys(system_mail_t)" >> mymail.te; >> echo "')" >> mymail.te; >> >> make -f /usr/share/selinux/devel/Makefile mymail.pp >> sudo semodule -i mymail.pp >> >> That should help. > > > This helps a lot, as fax receiving (and notifying) works without AVC > denials showing up. No I'm off trying to understand everything. With all > those makros, one get's a lot done with little code :-) Well there was already policy for getty present but it seems to not be sufficient for your configuration (or it may signal misconfiguration on your part) With regard to system_mail_t this is likely due to a bug. (known bug) Where the tty device does not get properly labeled. My fix makes it work but it is not a good fix ( user tty devices need to get labeled properly) If you are certain that you are using getty properly then consider reporting the AVC denials and my policy for getty_t to bugzilla/selinux-policy so that getties policy can be extended to support your configuration. > Thanks again > Klaus > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From k.lichtenwalder at computer.org Tue Dec 29 14:00:49 2009 From: k.lichtenwalder at computer.org (Klaus Lichtenwalder) Date: Tue, 29 Dec 2009 15:00:49 +0100 Subject: policy for mgetty fax receive and new_fax In-Reply-To: <4B39FEB9.5010000@gmail.com> References: <1262078256.12219.3.camel@localhost> <20091229111559.GD20705@localhost.localdomain> <1262086076.12219.17.camel@localhost> <20091229120201.GG20705@localhost.localdomain> <1262091136.12219.20.camel@localhost> <4B39FEB9.5010000@gmail.com> Message-ID: <1262095249.12219.26.camel@localhost> Am Dienstag, den 29.12.2009, 14:06 +0100 schrieb Dominick Grift: [...] > Well there was already policy for getty present but it seems to not be > sufficient for your configuration (or it may signal misconfiguration on > your part) Yes, but mgetty does lots more than getty (which can be used for serial devices, too). It is always possible I made a mistake configuring mgetty, but I'm using it for ca 15 years now (starting with some 0.x release, if I remember correctly), so I'm fairly confident I did not... The extensions needed for the policy are for the mechanisms after the successful receipt of a fax, and as this is nothing needed in the getty-policy I guess mgetty does need its own policy. > > With regard to system_mail_t this is likely due to a bug. (known bug) > Where the tty device does not get properly labeled. My fix makes it work > but it is not a good fix ( user tty devices need to get labeled properly) > > If you are certain that you are using getty properly then consider > reporting the AVC denials and my policy for getty_t to > bugzilla/selinux-policy so that getties policy can be extended to > support your configuration. > Yes, I forgot to ask in my last mail, I will check and try to understand, possibly help weed out the (possible) bugs and then go ahead. Thanks, Klaus -- ------------------------------------------------------------------------ Klaus Lichtenwalder, Dipl. Inform., http://lklaus.homelinux.org/Klaus/ PGP Key fingerprint: A5C0 F73A 2C83 96EE 766B 9C62 DB6D 1258 0E9B B6D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From warner at rubix.com Tue Dec 29 17:04:50 2009 From: warner at rubix.com (Andy Warner) Date: Tue, 29 Dec 2009 12:04:50 -0500 Subject: newrole: double free or corruption In-Reply-To: <20091229105700.GB20705@localhost.localdomain> References: <4B393F3E.1060403@rubix.com> <20091229105700.GB20705@localhost.localdomain> Message-ID: <4B3A36B2.3090703@rubix.com> Dominick Grift wrote: > On Mon, Dec 28, 2009 at 06:29:02PM -0500, Andy Warner wrote: > >> Got the following output from using the newrole command on Fedora 12. >> Not sure where to properly report such bugs. >> >> If it helps, the rubix_remote_client_r role transition should fail (as >> it does) as there are no role transition rules for it. The role is >> associated with the current SELinux user. >> >> I believe my system just updated to the newest newrole package. >> [warner at Fedora12-Dev ~]$ yum info policycoreutils >> Loaded plugins: presto, refresh-packagekit >> Installed Packages >> Name : policycoreutils >> Arch : i686 >> Version : 2.0.78 >> Release : 3.fc12 >> Size : 3.3 M >> Repo : installed >> >From repo : updates >> >> Error output from newrole follows: >> >> [warner at Fedora12-Dev ~]$ newrole -r rubix_remote_client_r >> > > Does it behave as expected if you use sudo instead? > > sudo -r rubix_remote_client_r -t rubix_remote_client_t -s > > Eitherway looks like a bug in newrole > Yes, sudo behaves as expected. The problem does not happen. The sudo command fails normally being unable to exec bash do to a lack of a transition rule. > >> Password: >> failed to exec shell >> : Permission denied >> *** glibc detected *** newrole: double free or corruption (out): >> 0x01726138 *** >> ======= Backtrace: ========= >> /lib/libc.so.6(-0xff836d9f)[0x233261] >> /lib/libselinux.so.1(freecon+0x1e)[0x9fd42e] >> newrole(main+0x6eb)[0x119d6b] >> /lib/libc.so.6(__libc_start_main+0xe6)[0x1dbbb6] >> newrole(+0x16f1)[0x1186f1] >> ======= Memory map: ======== >> 00117000-0011d000 r-xp 00000000 fd:00 126525 /usr/bin/newrole >> 0011d000-0011e000 r--p 00005000 fd:00 126525 /usr/bin/newrole >> 0011e000-0011f000 rw-p 00006000 fd:00 126525 /usr/bin/newrole >> 0011f000-00135000 r-xp 00000000 fd:00 56679 /lib/libpthread-2.11.so >> 00135000-00136000 r--p 00015000 fd:00 56679 /lib/libpthread-2.11.so >> 00136000-00137000 rw-p 00016000 fd:00 56679 /lib/libpthread-2.11.so >> 00137000-00139000 rw-p 00000000 00:00 0 >> 001a5000-001c3000 r-xp 00000000 fd:00 56677 /lib/ld-2.11.so >> 001c3000-001c4000 r--p 0001d000 fd:00 56677 /lib/ld-2.11.so >> 001c4000-001c5000 rw-p 0001e000 fd:00 56677 /lib/ld-2.11.so >> 001c5000-00333000 r-xp 00000000 fd:00 56678 /lib/libc-2.11.so >> 00333000-00334000 ---p 0016e000 fd:00 56678 /lib/libc-2.11.so >> 00334000-00336000 r--p 0016e000 fd:00 56678 /lib/libc-2.11.so >> 00336000-00337000 rw-p 00170000 fd:00 56678 /lib/libc-2.11.so >> 00337000-0033a000 rw-p 00000000 00:00 0 >> 0055f000-00560000 r-xp 00000000 00:00 0 [vdso] >> 005f6000-005fa000 r-xp 00000000 fd:00 1331 /lib/libattr.so.1.1.0 >> 005fa000-005fb000 rw-p 00003000 fd:00 1331 /lib/libattr.so.1.1.0 >> 0062d000-00638000 r-xp 00000000 fd:00 10441 /lib/libnss_files-2.11.so >> 00638000-00639000 r--p 0000a000 fd:00 10441 /lib/libnss_files-2.11.so >> 00639000-0063a000 rw-p 0000b000 fd:00 10441 /lib/libnss_files-2.11.so >> 008a3000-008a5000 r-xp 00000000 fd:00 15448 /lib/libpam_misc.so.0.82.0 >> 008a5000-008a6000 rw-p 00001000 fd:00 15448 /lib/libpam_misc.so.0.82.0 >> 00928000-0092c000 r-xp 00000000 fd:00 1332 /lib/libcap.so.2.16 >> 0092c000-0092d000 rw-p 00003000 fd:00 1332 /lib/libcap.so.2.16 >> 00992000-00995000 r-xp 00000000 fd:00 56684 /lib/libdl-2.11.so >> 00995000-00996000 r--p 00002000 fd:00 56684 /lib/libdl-2.11.so >> 00996000-00997000 rw-p 00003000 fd:00 56684 /lib/libdl-2.11.so >> 009f3000-00a0f000 r-xp 00000000 fd:00 56687 /lib/libselinux.so.1 >> 00a0f000-00a10000 r--p 0001b000 fd:00 56687 /lib/libselinux.so.1 >> 00a10000-00a11000 rw-p 0001c000 fd:00 56687 /lib/libselinux.so.1 >> 00c8b000-00c97000 r-xp 00000000 fd:00 15447 /lib/libpam.so.0.82.1 >> 00c97000-00c98000 rw-p 0000b000 fd:00 15447 /lib/libpam.so.0.82.1 >> 00e6f000-00e85000 r-xp 00000000 fd:00 15446 /lib/libaudit.so.1.0.0 >> 00e85000-00e86000 r--p 00015000 fd:00 15446 /lib/libaudit.so.1.0.0 >> 00e86000-00e87000 rw-p 00016000 fd:00 15446 /lib/libaudit.so.1.0.0 >> 00ea9000-00ec6000 r-xp 00000000 fd:00 51325 >> /lib/libgcc_s-4.4.2-20091027.so.1 >> 00ec6000-00ec7000 rw-p 0001c000 fd:00 51325 >> /lib/libgcc_s-4.4.2-20091027.so.1 >> 00f05000-00f0c000 r-xp 00000000 fd:00 56680 /lib/librt-2.11.so >> 00f0c000-00f0d000 r--p 00006000 fd:00 56680 /lib/librt-2.11.so >> 00f0d000-00f0e000 rw-p 00007000 fd:00 56680 /lib/librt-2.11.so >> 01724000-017a9000 rw-p 00000000 00:00 0 [heap] >> b7627000-b7827000 r--p 00000000 fd:00 12545 >> /usr/lib/locale/locale-archive >> b7827000-b782a000 rw-p 00000000 00:00 0 >> b783b000-b7842000 r--s 00000000 fd:00 10739 >> /usr/lib/gconv/gconv-modules.cache >> b7842000-b7843000 rw-p 00000000 00:00 0 >> bfcce000-bfce3000 rw-p 00000000 00:00 0 [stack] >> [warner at Fedora12-Dev ~]$ >> >> > > >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From goeran at uddeborg.se Tue Dec 29 21:32:19 2009 From: goeran at uddeborg.se (=?utf-8?Q?G=C3=B6ran?= Uddeborg) Date: Tue, 29 Dec 2009 22:32:19 +0100 Subject: AVC:s on xauth file when doing su In-Reply-To: <4B3A36B2.3090703@rubix.com> References: <4B393F3E.1060403@rubix.com> <20091229105700.GB20705@localhost.localdomain> <4B3A36B2.3090703@rubix.com> Message-ID: <19258.30051.160951.252201@gargle.gargle.HOWL> Whenever I do "su" in an xterm window, I get two AVC denials. The command xauth is denied to read and write a file .xauthXXXXX where XXXXX is some random string different each time. (I encose an example below.) I would bugzilla this, but I'm (as often) not quite sure if it's the policy or if it's me. That is, if maybe this is not intended to be allowed? Or if there there something else I might be missing? I can't see any boolean I would connect to this. So, is this a bug I should report, or is it intentional? ---- time->Tue Dec 29 21:32:48 2009 type=SYSCALL msg=audit(1262118768.835:41732): arch=c000003e syscall=21 success=no exit=-13 a0=7fff99bd14d5 a1=2 a2=0 a3=7fff99bcfd10 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1262118768.835:41732): avc: denied { write } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file ---- time->Tue Dec 29 21:32:48 2009 type=SYSCALL msg=audit(1262118768.836:41733): arch=c000003e syscall=2 success=no exit=-13 a0=7fff99bd14d5 a1=0 a2=1b6 a3=0 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1262118768.836:41733): avc: denied { read } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file From domg472 at gmail.com Tue Dec 29 21:50:46 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 29 Dec 2009 22:50:46 +0100 Subject: AVC:s on xauth file when doing su In-Reply-To: <19258.30051.160951.252201@gargle.gargle.HOWL> References: <4B393F3E.1060403@rubix.com> <20091229105700.GB20705@localhost.localdomain> <4B3A36B2.3090703@rubix.com> <19258.30051.160951.252201@gargle.gargle.HOWL> Message-ID: <20091229215045.GA29350@localhost.localdomain> On Tue, Dec 29, 2009 at 10:32:19PM +0100, G?ran Uddeborg wrote: > Whenever I do "su" in an xterm window, I get two AVC denials. The > command xauth is denied to read and write a file .xauthXXXXX where > XXXXX is some random string different each time. (I encose an example > below.) > > I would bugzilla this, but I'm (as often) not quite sure if it's the > policy or if it's me. That is, if maybe this is not intended to be > allowed? Or if there there something else I might be missing? I > can't see any boolean I would connect to this. > > So, is this a bug I should report, or is it intentional? Well for starters the file is mislabeled: [root at localhost Desktop]# matchpathcon /root/.xauthbDy84s /root/.xauthbDy84s system_u:object_r:xauth_home_t:s0 If the file was properly labeled the access would be allowed: [root at localhost Desktop]# sesearch --allow -s xauth_t -t xauth_home_t Found 2 semantic av rules: allow xauth_t xauth_home_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; allow xauth_t file_type : filesystem getattr ; The following policy would make source process type xauth_t create .xauth* files in /root with type xauth_home_t: allow xauth_t xauth_home_t:file manage_file_perms; userdom_admin_home_dir_filetrans(xauth_t, xauth_home_t, file) /root/\.xauth.* -- gen_context(system_u:object_r:xauth_home_t,s0) The Question is: why did this not happen? > > ---- > time->Tue Dec 29 21:32:48 2009 > type=SYSCALL msg=audit(1262118768.835:41732): arch=c000003e syscall=21 success=no exit=-13 a0=7fff99bd14d5 a1=2 a2=0 a3=7fff99bcfd10 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1262118768.835:41732): avc: denied { write } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file > ---- > time->Tue Dec 29 21:32:48 2009 > type=SYSCALL msg=audit(1262118768.836:41733): arch=c000003e syscall=2 success=no exit=-13 a0=7fff99bd14d5 a1=0 a2=1b6 a3=0 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1262118768.836:41733): avc: denied { read } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Tue Dec 29 21:57:02 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 29 Dec 2009 22:57:02 +0100 Subject: AVC:s on xauth file when doing su In-Reply-To: <19258.30051.160951.252201@gargle.gargle.HOWL> References: <4B393F3E.1060403@rubix.com> <20091229105700.GB20705@localhost.localdomain> <4B3A36B2.3090703@rubix.com> <19258.30051.160951.252201@gargle.gargle.HOWL> Message-ID: <20091229215701.GB29350@localhost.localdomain> On Tue, Dec 29, 2009 at 10:32:19PM +0100, G?ran Uddeborg wrote: > Whenever I do "su" in an xterm window, I get two AVC denials. The > command xauth is denied to read and write a file .xauthXXXXX where > XXXXX is some random string different each time. (I encose an example > below.) > > I would bugzilla this, but I'm (as often) not quite sure if it's the > policy or if it's me. That is, if maybe this is not intended to be > allowed? Or if there there something else I might be missing? I > can't see any boolean I would connect to this. > > So, is this a bug I should report, or is it intentional? Remove the file and see if xauth creates a new one and what the type of the newly created file is: ls -alZ /root | grep .xauth What distro are you using? If xauth creates the file it should be type xauth_home_t, not admin_home_t. Maybe something else creates it? The fact is that the file is mislabeled. > > ---- > time->Tue Dec 29 21:32:48 2009 > type=SYSCALL msg=audit(1262118768.835:41732): arch=c000003e syscall=21 success=no exit=-13 a0=7fff99bd14d5 a1=2 a2=0 a3=7fff99bcfd10 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1262118768.835:41732): avc: denied { write } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file > ---- > time->Tue Dec 29 21:32:48 2009 > type=SYSCALL msg=audit(1262118768.836:41733): arch=c000003e syscall=2 success=no exit=-13 a0=7fff99bd14d5 a1=0 a2=1b6 a3=0 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1262118768.836:41733): avc: denied { read } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Tue Dec 29 22:29:51 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 29 Dec 2009 23:29:51 +0100 Subject: AVC:s on xauth file when doing su In-Reply-To: <19258.30051.160951.252201@gargle.gargle.HOWL> References: <4B393F3E.1060403@rubix.com> <20091229105700.GB20705@localhost.localdomain> <4B3A36B2.3090703@rubix.com> <19258.30051.160951.252201@gargle.gargle.HOWL> Message-ID: <20091229222949.GC29350@localhost.localdomain> On Tue, Dec 29, 2009 at 10:32:19PM +0100, G?ran Uddeborg wrote: > Whenever I do "su" in an xterm window, I get two AVC denials. The > command xauth is denied to read and write a file .xauthXXXXX where > XXXXX is some random string different each time. (I encose an example > below.) > > I would bugzilla this, but I'm (as often) not quite sure if it's the > policy or if it's me. That is, if maybe this is not intended to be > allowed? Or if there there something else I might be missing? I > can't see any boolean I would connect to this. > > So, is this a bug I should report, or is it intentional? I think this may be a bug here: optional_policy(` domain_trans(sshd_t, xauth_exec_t, userdomain) ') I do not think we want sshd_t to domain transition to a user domain upon executing files with type xauth_exec_t. Instead i would argue for a xauth_domtrans(sshd_t) I could be wrong and i do not know about any complications. I think this is a valid bug. consider reporting it with the AVC denials and my analys to bugzilla/selinux-policy. > > ---- > time->Tue Dec 29 21:32:48 2009 > type=SYSCALL msg=audit(1262118768.835:41732): arch=c000003e syscall=21 success=no exit=-13 a0=7fff99bd14d5 a1=2 a2=0 a3=7fff99bcfd10 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1262118768.835:41732): avc: denied { write } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file > ---- > time->Tue Dec 29 21:32:48 2009 > type=SYSCALL msg=audit(1262118768.836:41733): arch=c000003e syscall=2 success=no exit=-13 a0=7fff99bd14d5 a1=0 a2=1b6 a3=0 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1262118768.836:41733): avc: denied { read } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Tue Dec 29 23:11:52 2009 From: domg472 at gmail.com (Dominick Grift) Date: Wed, 30 Dec 2009 00:11:52 +0100 Subject: AVC:s on xauth file when doing su In-Reply-To: <19258.30051.160951.252201@gargle.gargle.HOWL> References: <4B393F3E.1060403@rubix.com> <20091229105700.GB20705@localhost.localdomain> <4B3A36B2.3090703@rubix.com> <19258.30051.160951.252201@gargle.gargle.HOWL> Message-ID: <20091229231151.GD29350@localhost.localdomain> On Tue, Dec 29, 2009 at 10:32:19PM +0100, G?ran Uddeborg wrote: > Whenever I do "su" in an xterm window, I get two AVC denials. The > command xauth is denied to read and write a file .xauthXXXXX where > XXXXX is some random string different each time. (I encose an example > below.) > > I would bugzilla this, but I'm (as often) not quite sure if it's the > policy or if it's me. That is, if maybe this is not intended to be > allowed? Or if there there something else I might be missing? I > can't see any boolean I would connect to this. > > So, is this a bug I should report, or is it intentional? Hmm ignore my latest reply. Seems there is a rule that does the domain transition: optional_policy(` xserver_domtrans_xauth(sshd_t) ') So, i am running out of clues. BTW: It is not encouraged to login as root via ssh (-X) > > ---- > time->Tue Dec 29 21:32:48 2009 > type=SYSCALL msg=audit(1262118768.835:41732): arch=c000003e syscall=21 success=no exit=-13 a0=7fff99bd14d5 a1=2 a2=0 a3=7fff99bcfd10 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1262118768.835:41732): avc: denied { write } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file > ---- > time->Tue Dec 29 21:32:48 2009 > type=SYSCALL msg=audit(1262118768.836:41733): arch=c000003e syscall=2 success=no exit=-13 a0=7fff99bd14d5 a1=0 a2=1b6 a3=0 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1262118768.836:41733): avc: denied { read } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dwalsh at redhat.com Wed Dec 30 14:19:07 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 30 Dec 2009 09:19:07 -0500 Subject: No AVC when using non-standard SSH port In-Reply-To: <20091229112600.GE20705@localhost.localdomain> References: <200912252340.23393.jorge.fabregas@gmail.com> <20091226112727.GA31930@localhost.localdomain> <20091226124156.GA2289@jadzia.bu.edu> <200912282155.17752.jorge.fabregas@gmail.com> <20091229112600.GE20705@localhost.localdomain> Message-ID: <4B3B615B.3000601@redhat.com> On 12/29/2009 06:26 AM, Dominick Grift wrote: > On Tue, Dec 29, 2009 at 02:06:37AM -0500, Gregory Maxwell wrote: >> 2009/12/28 Jorge F?bregas : >>> On Saturday 26 December 2009 08:41:56 Matthew Miller wrote: >>>> Possibly needed for ssh port forwarding? >>> >>> I don't think this might be the reason. If someone's tech-savvy enough to do >>> port forwarding, they might as well use semanage to add the custom ports... >>> I'm still clueless on why it is like this on F12 :( >> >> Er. Port forwarding is a normal user-visible SSH feature which has >> been historically enabled. The person using it may not have the >> authority to change the SE linux permissions. >> >> OTOH, I think GatewayPorts defaults to no. So SELinux could back that >> up and restrict non-22 listens to localhost without changing the SSH >> default configuration. Also, listens on privileged ports (<=1024) are >> denied for non-root users so denying that in the SELinux policy >> wouldn't be harmful. > > As far as i can tell SELinux only allows bind access to unreserved ports. I think that means > 1024. (not sure though) > > >> >> It might be handy to add comments to the relevant configuration files >> mentioning the SELinux limitations. It can be rather annoying when you >> change a setting only to have the change mooted by some SELinux >> imposed limitation. Some simple comments would go a long way in >> reducing confusions. >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list Portforwardning requires allowing ssh to bind to ports > 1024. corenet_tcp_bind_all_unreserved_ports I guess we could add a boolean to allow this to be turned off. From dwalsh at redhat.com Wed Dec 30 14:23:56 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 30 Dec 2009 09:23:56 -0500 Subject: allow_exec{mem,stack} default to on? In-Reply-To: <1261939395.2611.16.camel@localhost> References: <1261918083.2611.11.camel@localhost> <20091227172456.GB22921@localhost.localdomain> <1df9930e0912271011w5ba20990i5808e7b2be1d5c45@mail.gmail.com> <1261939395.2611.16.camel@localhost> Message-ID: <4B3B627C.7090704@redhat.com> On 12/27/2009 01:43 PM, Klaus Lichtenwalder wrote: > Hi, > > thanks for all your answers. It's correct, if I wanted to go the secure > road, I should map all users to some (more specific) role than is the > default. Considering the situation I think I can stay with the default > rights, as they are probably layed out fine (for default use, i.e. what > I need :-) ) In the meantime, I found some boinc jobs, that need > allow_execmem. Guess I can live with that, and will come back again when > I start my first policies or refinements of some, I do have some on > target, already, so beware ;-) > > Klaus > > On Sun, 2009-12-27 at 13:11 -0500, Ryan Gandy wrote: >> Hello Klaus, >> >> Personally I'd suggest turning off exec (mem, heap, stack); mapping >> your user role to staff_u and then disallowing unconfined logins; >> turning on secure_mode and secure_mode_policyload. setsebool -P >> should take care of that last from single >> user mode. >> >> ---------- Forwarded message ---------- >> From: Dominick Grift >> Date: Sun, Dec 27, 2009 at 12:24 PM >> Subject: Re: allow_exec{mem,stack} default to on? >> To: fedora-selinux-list at redhat.com >> >> >> On Sun, Dec 27, 2009 at 01:48:03PM +0100, Klaus Lichtenwalder wrote: >> >>> Hi, >>> >>> just checked to freshly installed Fedora 12 machines, and found >>> allow_execmem --> on >>> allow_execstack --> on >>> Is there a reason for this, as the comment in semanage strongly >>> discourages it? Or did I install a package that switches those >> booleans? >> >> >> By default SELinux is pretty permissive (much is allowed). However you >> can very much tighten the configuration. >> > .. >> >> map all your Linux logins to confined SELinux users >> disable the unconfined module >> lock-down your booleans >> ...and much more... > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list I have tried many times to turn off the allow_execmem and allow_execstack booleans. The problem is there is too much badly written code and too many unknown executables out there that require execmem and execstack. Including stuff that is downloaded to the homedir. allow_execmem was on by default in F12 and allow_execstack has been turned on by default in newer policies, although this will only happen on fresh installs with the new policy. Updates NEVER change boolean settings. I would advise people who know what they are doing to turn off this booleans, but turning them on by default inflicts too much pain. allow_execmod and allow_execheap are off by default. These booleans only effect unconfined domains. So evey confined domain will enforce the execmem and execstack access control regardless of their settings. From dwalsh at redhat.com Wed Dec 30 14:25:55 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 30 Dec 2009 09:25:55 -0500 Subject: vbetool denied In-Reply-To: References: Message-ID: <4B3B62F3.2080606@redhat.com> On 12/28/2009 06:21 PM, Kirk Lowery wrote: > I'm running a newly installed, uptodate Fedora 12 box. Is there any reason > by vbetools is denied? From dmesg: > > type=1400 audit(1262025694.652:4): avc: denied { mmap_zero } for pid=598 > comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 t > class=memprotect > > Is this a problem with my local system, or a more general bug? And what is > the best way to fix this? > > TIA! > > Kirk > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list There is an open bug on vbetool to not require this access. Some systems need this access in order for suspend/resume to work properly. mmap_zero, has proven to be a way for root privledge escallation when a bug is found in the kernel. Having this boolean off prevents unconfined users from gaining root access. Turning this on removes this protection. From k.lichtenwalder at computer.org Wed Dec 30 14:52:10 2009 From: k.lichtenwalder at computer.org (Klaus Lichtenwalder) Date: Wed, 30 Dec 2009 15:52:10 +0100 Subject: allow_exec{mem,stack} default to on? In-Reply-To: <4B3B627C.7090704@redhat.com> References: <1261918083.2611.11.camel@localhost> <20091227172456.GB22921@localhost.localdomain> <1df9930e0912271011w5ba20990i5808e7b2be1d5c45@mail.gmail.com> <1261939395.2611.16.camel@localhost> <4B3B627C.7090704@redhat.com> Message-ID: <1262184730.12219.38.camel@localhost> Am Mittwoch, den 30.12.2009, 09:23 -0500 schrieb Daniel J Walsh: > allow_execmem was on by default in F12 and allow_execstack has been > turned on by default in newer policies, although this will only happen > on fresh installs with the new policy. Updates NEVER change boolean > settings. I did an install with the netintall CD, so kind of fresh install with the new policy > > I would advise people who know what they are doing to turn off this > booleans, but turning them on by default inflicts too much pain. > > allow_execmod and allow_execheap are off by default. > > These booleans only effect unconfined domains. So evey confined > domain will enforce the execmem and execstack access control > regardless of their settings. At the moment I have allow_execheap --> off allow_execmem --> on allow_execmod --> off allow_execstack --> off As the boinc_client needs execmem. Guess I'll file a bug with them, as I'm more comfortable with this off... Which brings me to the point, I should check whether the *service* boinc (which I don't use) is running unconfined... Interestingly I have another application, for homebanking, that's throwing the famous mmap_zero violation. Which I still don't allow and the application doesn't care... Probably lot's of bugs in their code and code pathes that aren't too important :-) Klaus -- ------------------------------------------------------------------------ Klaus Lichtenwalder, Dipl. Inform., http://lklaus.homelinux.org/Klaus/ PGP Key fingerprint: A5C0 F73A 2C83 96EE 766B 9C62 DB6D 1258 0E9B B6D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From goeran at uddeborg.se Wed Dec 30 16:14:59 2009 From: goeran at uddeborg.se (=?utf-8?Q?G=C3=B6ran?= Uddeborg) Date: Wed, 30 Dec 2009 17:14:59 +0100 Subject: AVC:s on xauth file when doing su In-Reply-To: <20091229215045.GA29350@localhost.localdomain> References: <4B393F3E.1060403@rubix.com> <20091229105700.GB20705@localhost.localdomain> <4B3A36B2.3090703@rubix.com> <19258.30051.160951.252201@gargle.gargle.HOWL> <20091229215045.GA29350@localhost.localdomain> Message-ID: <19259.31875.618530.552239@freddi.uddeborg> Dominick Grift: > Well for starters the file is mislabeled: > The Question is: why did this not happen? Thanks for your analysis. I'll try to investigate exactly when this happens. And if it turns out to be something policy-related (rather than something that has gone wrong locally) I'll file a bugzilla. > Remove the file and see if xauth creates a new one and what the type > of the newly created file is: ls -alZ /root | grep .xauth Now it gets a context of xauth_home_t. (As usual, bugs hide when you start looking for them!) > What distro are you using? Fedora 12. I recently upgraded the policy to selinux-policy-3.6.32-63.fc12. > BTW: It is not encouraged to login as root via ssh (-X) :-) Between two trusted hosts on a trusted local, wired, network, I'm not too worried. (I don't actually log in as root. I log in as myself and do su or sudo. But I guess that part doesn't really make much difference.) From eswierk at aristanetworks.com Thu Dec 31 00:32:01 2009 From: eswierk at aristanetworks.com (Ed Swierk) Date: Wed, 30 Dec 2009 16:32:01 -0800 Subject: Apparent memory leak in libselinux Message-ID: <9ae48b020912301632u6d69e445tf2dd33d3afe9ca04@mail.gmail.com> When I run the following on a F12 system booted with selinux=0, the tcmalloc heap checker complains about a leak somewhere in libselinux: $ HEAPCHECK=normal LD_PRELOAD=/usr/lib64/libtcmalloc.so.0 /usr/bin/python -c 'import _ssl' Leak check _main_ detected leaks of 120 bytes in 1 objects The 1 largest leaks: Leak of 120 bytes in 1 objects allocated from: @ 0x3bf9866589 _IO_getdelim @ 0x3bfb40ca53 set_selinuxmnt @ 0x3bfb414fe6 string_to_security_class @ 0x3bfb404cdb _init @ 0x7fff4bdfa8ed 0x00007fff4bdfa8ed No leak is detected when I run this with selinux enabled. My system has libselinux-2.0.87-1.fc12 installed. --Ed From rnicholsNOSPAM at comcast.net Thu Dec 31 00:52:02 2009 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Wed, 30 Dec 2009 18:52:02 -0600 Subject: Home directories within /var Message-ID: On my system I have home directories in /var/home and bind mounted to /home: /var/home on /home type none (rw,bind) Is there any way to prevent restorecon on /var from descending into /var/home and destroying the normal home directory file contexts? Reproducing all of file_contexts.homedirs in local policy is of course unmaintainable. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. From paul at city-fan.org Thu Dec 31 08:09:55 2009 From: paul at city-fan.org (Paul Howarth) Date: Thu, 31 Dec 2009 08:09:55 +0000 Subject: Home directories within /var In-Reply-To: References: Message-ID: <20091231080955.6e39659f@city-fan.org> On Wed, 30 Dec 2009 18:52:02 -0600 Robert Nichols wrote: > On my system I have home directories in /var/home and bind mounted > to /home: > > /var/home on /home type none (rw,bind) > > Is there any way to prevent restorecon on /var from descending into > /var/home and destroying the normal home directory file contexts? > Reproducing all of file_contexts.homedirs in local policy is of course > unmaintainable. You can make the file contexts for /var/home match those for /home very easily on F-11 onwards: # semanage fcontext -a -e /home /var/home See http://danwalsh.livejournal.com/2009/04/09/ for Dan's blog on file context equivalency. On a slightly related issue, I note that current selinux-policy packages do a restorecon on the contents of /var/lib, which on my mock buildsystem is *huge* (all buildroots live under /var/lib/mock) and takes a very long time indeed. I wonder what the problem is that this behaviour is trying to solve? Paul. From root at localdomain.pl Thu Dec 31 10:06:58 2009 From: root at localdomain.pl (Grzegorz Nosek) Date: Thu, 31 Dec 2009 11:06:58 +0100 Subject: CentOS 5.4 + xinetd + sshd + SELinux issues Message-ID: <20091231100658.GA25765@megiteam.pl> Hi all, I have a problem trying to run sshd via xinetd on a CentOS 5.4 system (I want to slap a tcpwrappers-style wrapper before sshd, so I need it that way). In permissive mode I can log in/out with the following failures reported by audit2allow: allow amanda_t consoletype_exec_t:file { execute execute_no_trans }; allow amanda_t devpts_t:chr_file { write ioctl }; allow amanda_t hostname_exec_t:file { execute execute_no_trans }; allow amanda_t shell_exec_t:file entrypoint; I don't even have amanda installed, so the context is clearly bogus. After a chat on #fedora-selinux it seems that sshd cannot find its default context, so falls back to the first available one, which happens to be something:something:amanda_t (the list is read from /selinux/user). This operation is performed by sshd itself (as verified by strace). I don't need Fort Knox type security but I'd like to use SELinux to tighten down other parts of the system, so I'd really like to use the enforcing mode. Any hints? A good TFM to R will hopefully do. Best regards, Grzegorz Nosek From stefan at seekline.net Thu Dec 31 13:16:51 2009 From: stefan at seekline.net (Stefan Schulze Frielinghaus) Date: Thu, 31 Dec 2009 14:16:51 +0100 Subject: How to handle cron jobs? Message-ID: <1262265411.1947.28.camel@localhost> Hi all, on one of my servers (running CentOS 5.4) is a cron job installed by default which checks the status of my software array on a weekly base. The script is the following: /etc/cron.weekly/99-raid-check (is shipped via mdadm) Having a look at other cron jobs most run as bin_t and call a binary e.g. logrotate or whatever and do a simple domtrans. The raid check script only uses basic commands like if/grep/cat and so on. What would be the best way to write a policy for such a script with the interest to get it included into RHEL/Fedora or maybe even refpolicy (Chris: Is this even interesting for refpolicy or should we exclude such tiny policies because this one seems to be shipped only by RHEL/Fedora). Just to make it precise: What would be the best way to write a policy for such tiny cron job? I suppose it would be cron_system_entry() because prelink uses it and has its own type. All others I have seen are using domtrans(). cheers, Stefan From dwalsh at redhat.com Thu Dec 31 14:09:44 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 31 Dec 2009 09:09:44 -0500 Subject: AVC:s on xauth file when doing su In-Reply-To: <19259.31875.618530.552239@freddi.uddeborg> References: <4B393F3E.1060403@rubix.com> <20091229105700.GB20705@localhost.localdomain> <4B3A36B2.3090703@rubix.com> <19258.30051.160951.252201@gargle.gargle.HOWL> <20091229215045.GA29350@localhost.localdomain> <19259.31875.618530.552239@freddi.uddeborg> Message-ID: <4B3CB0A8.6050603@redhat.com> On 12/30/2009 11:14 AM, G?ran Uddeborg wrote: > Dominick Grift: >> Well for starters the file is mislabeled: > >> The Question is: why did this not happen? > > Thanks for your analysis. > > I'll try to investigate exactly when this happens. And if it turns > out to be something policy-related (rather than something that has > gone wrong locally) I'll file a bugzilla. > >> Remove the file and see if xauth creates a new one and what the type >> of the newly created file is: ls -alZ /root | grep .xauth > > Now it gets a context of xauth_home_t. (As usual, bugs hide when you > start looking for them!) > >> What distro are you using? > > Fedora 12. I recently upgraded the policy to > selinux-policy-3.6.32-63.fc12. > >> BTW: It is not encouraged to login as root via ssh (-X) > > :-) Between two trusted hosts on a trusted local, wired, network, I'm > not too worried. (I don't actually log in as root. I log in as > myself and do su or sudo. But I guess that part doesn't really make > much difference.) > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > There have been some fixes around the handling of xauth in the latest policies, so this might have fixed your problems. From dwalsh at redhat.com Thu Dec 31 14:11:55 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 31 Dec 2009 09:11:55 -0500 Subject: allow_exec{mem,stack} default to on? In-Reply-To: <1262184730.12219.38.camel@localhost> References: <1261918083.2611.11.camel@localhost> <20091227172456.GB22921@localhost.localdomain> <1df9930e0912271011w5ba20990i5808e7b2be1d5c45@mail.gmail.com> <1261939395.2611.16.camel@localhost> <4B3B627C.7090704@redhat.com> <1262184730.12219.38.camel@localhost> Message-ID: <4B3CB12B.5050509@redhat.com> On 12/30/2009 09:52 AM, Klaus Lichtenwalder wrote: > Am Mittwoch, den 30.12.2009, 09:23 -0500 schrieb Daniel J Walsh: > >> allow_execmem was on by default in F12 and allow_execstack has been >> turned on by default in newer policies, although this will only happen >> on fresh installs with the new policy. Updates NEVER change boolean >> settings. > > I did an install with the netintall CD, so kind of fresh install with > the new policy >> >> I would advise people who know what they are doing to turn off this >> booleans, but turning them on by default inflicts too much pain. >> >> allow_execmod and allow_execheap are off by default. >> >> These booleans only effect unconfined domains. So evey confined >> domain will enforce the execmem and execstack access control >> regardless of their settings. > > At the moment I have > allow_execheap --> off > allow_execmem --> on > allow_execmod --> off > allow_execstack --> off > > As the boinc_client needs execmem. Guess I'll file a bug with them, as > I'm more comfortable with this off... > > Which brings me to the point, I should check whether the *service* boinc > (which I don't use) is running unconfined... > > Interestingly I have another application, for homebanking, that's > throwing the famous mmap_zero violation. Which I still don't allow and > the application doesn't care... Probably lot's of bugs in their code and > code pathes that aren't too important :-) > Is this a wine application? Wine seems to throw this error even though it only needs it for very old DOS type apps. > Klaus > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From k.lichtenwalder at computer.org Thu Dec 31 14:30:43 2009 From: k.lichtenwalder at computer.org (Klaus Lichtenwalder) Date: Thu, 31 Dec 2009 15:30:43 +0100 Subject: allow_exec{mem,stack} default to on? In-Reply-To: <4B3CB12B.5050509@redhat.com> References: <1261918083.2611.11.camel@localhost> <20091227172456.GB22921@localhost.localdomain> <1df9930e0912271011w5ba20990i5808e7b2be1d5c45@mail.gmail.com> <1261939395.2611.16.camel@localhost> <4B3B627C.7090704@redhat.com> <1262184730.12219.38.camel@localhost> <4B3CB12B.5050509@redhat.com> Message-ID: <1262269843.12219.51.camel@localhost> Am Donnerstag, den 31.12.2009, 09:11 -0500 schrieb Daniel J Walsh: > On 12/30/2009 09:52 AM, Klaus Lichtenwalder wrote: [...] > > > > Interestingly I have another application, for homebanking, that's > > throwing the famous mmap_zero violation. Which I still don't allow and > > the application doesn't care... Probably lot's of bugs in their code and > > code pathes that aren't too important :-) > > > Is this a wine application? Wine seems to throw this error even though it only needs it for very old DOS type apps. > No, it is indeed a native linux binary, but the Windows heredity shows. It does have some minor issues with windowing though, but otherwise ok. And I have lots of data in it ... Klaus -- ------------------------------------------------------------------------ Klaus Lichtenwalder, Dipl. Inform., http://lklaus.homelinux.org/Klaus/ PGP Key fingerprint: A5C0 F73A 2C83 96EE 766B 9C62 DB6D 1258 0E9B B6D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From rnicholsNOSPAM at comcast.net Thu Dec 31 17:18:47 2009 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Thu, 31 Dec 2009 11:18:47 -0600 Subject: Home directories within /var In-Reply-To: <20091231080955.6e39659f@city-fan.org> References: <20091231080955.6e39659f@city-fan.org> Message-ID: Paul Howarth wrote: > On Wed, 30 Dec 2009 18:52:02 -0600 > Robert Nichols wrote: > >> On my system I have home directories in /var/home and bind mounted >> to /home: >> >> /var/home on /home type none (rw,bind) >> >> Is there any way to prevent restorecon on /var from descending into >> /var/home and destroying the normal home directory file contexts? >> Reproducing all of file_contexts.homedirs in local policy is of course >> unmaintainable. > > You can make the file contexts for /var/home match those for /home very > easily on F-11 onwards: > > # semanage fcontext -a -e /home /var/home > > See http://danwalsh.livejournal.com/2009/04/09/ for Dan's blog on file > context equivalency. TYVM. Perhaps someday the manpage for semanage will include some mention of that "-e" flag. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.