From eparis at redhat.com Wed Jul 1 01:46:16 2009 From: eparis at redhat.com (Eric Paris) Date: Tue, 30 Jun 2009 21:46:16 -0400 Subject: Supporting multiple OS releases In-Reply-To: <4A4A8380.3060707@redhat.com> References: <4A4A1C74.5040600@redhat.com> <4A4A7524.8010308@redhat.com> <4A4A7881.6040303@redhat.com> <4A4A8380.3060707@redhat.com> Message-ID: <1246412776.22562.28.camel@dhcp235-23.rdu.redhat.com> On Tue, 2009-06-30 at 17:28 -0400, Daniel J Walsh wrote: > RIght I think you would need to build on F9 for support on F11 not the > other way around. Just like you would do with shared libraries. You > would not expect an c executable built on F11 to run on F9? I think he wants a single code base which can be built on F9 or F11. I might not expect that C to run, but I'd expect the same source could be compiled on either. We aren't providing enough information for his policy to know which interface it should be using, not sure how to solve the problem, but obviously Rob want a way to use the new interface if it is there and to use the old interface if it is not..... -Eric From rcritten at redhat.com Wed Jul 1 02:31:48 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 30 Jun 2009 22:31:48 -0400 Subject: Supporting multiple OS releases In-Reply-To: <1246412776.22562.28.camel@dhcp235-23.rdu.redhat.com> References: <4A4A1C74.5040600@redhat.com> <4A4A7524.8010308@redhat.com> <4A4A7881.6040303@redhat.com> <4A4A8380.3060707@redhat.com> <1246412776.22562.28.camel@dhcp235-23.rdu.redhat.com> Message-ID: <4A4ACA94.3000802@redhat.com> Eric Paris wrote: > On Tue, 2009-06-30 at 17:28 -0400, Daniel J Walsh wrote: > >> RIght I think you would need to build on F9 for support on F11 not the >> other way around. Just like you would do with shared libraries. You >> would not expect an c executable built on F11 to run on F9? > > I think he wants a single code base which can be built on F9 or F11. I > might not expect that C to run, but I'd expect the same source could be > compiled on either. > > We aren't providing enough information for his policy to know which > interface it should be using, not sure how to solve the problem, but > obviously Rob want a way to use the new interface if it is there and to > use the old interface if it is not..... > > -Eric > Yes, this is exactly what I was trying to say. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From sds at tycho.nsa.gov Wed Jul 1 13:18:38 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 01 Jul 2009 09:18:38 -0400 Subject: Supporting multiple OS releases In-Reply-To: <1246412776.22562.28.camel@dhcp235-23.rdu.redhat.com> References: <4A4A1C74.5040600@redhat.com> <4A4A7524.8010308@redhat.com> <4A4A7881.6040303@redhat.com> <4A4A8380.3060707@redhat.com> <1246412776.22562.28.camel@dhcp235-23.rdu.redhat.com> Message-ID: <1246454318.13464.134.camel@moss-pluto.epoch.ncsc.mil> On Tue, 2009-06-30 at 21:46 -0400, Eric Paris wrote: > On Tue, 2009-06-30 at 17:28 -0400, Daniel J Walsh wrote: > > > RIght I think you would need to build on F9 for support on F11 not the > > other way around. Just like you would do with shared libraries. You > > would not expect an c executable built on F11 to run on F9? > > I think he wants a single code base which can be built on F9 or F11. I > might not expect that C to run, but I'd expect the same source could be > compiled on either. > > We aren't providing enough information for his policy to know which > interface it should be using, not sure how to solve the problem, but > obviously Rob want a way to use the new interface if it is there and to > use the old interface if it is not..... In the case of the ltp selinux test policy, which has a similar challenge with changing refpolicy interfaces (as well as kernel changes, e.g. introduction and enabling of open perm), I finally had to just fork a copy of the test policy in a subdirectory for RHEL5, while continuing to track the latest Fedora in the main directory. The Makefile then selects what policy to build automatically. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed Jul 1 14:52:43 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 01 Jul 2009 10:52:43 -0400 Subject: Supporting multiple OS releases In-Reply-To: <1246454318.13464.134.camel@moss-pluto.epoch.ncsc.mil> References: <4A4A1C74.5040600@redhat.com> <4A4A7524.8010308@redhat.com> <4A4A7881.6040303@redhat.com> <4A4A8380.3060707@redhat.com> <1246412776.22562.28.camel@dhcp235-23.rdu.redhat.com> <1246454318.13464.134.camel@moss-pluto.epoch.ncsc.mil> Message-ID: <1246459963.13464.176.camel@moss-pluto.epoch.ncsc.mil> On Wed, 2009-07-01 at 09:18 -0400, Stephen Smalley wrote: > On Tue, 2009-06-30 at 21:46 -0400, Eric Paris wrote: > > On Tue, 2009-06-30 at 17:28 -0400, Daniel J Walsh wrote: > > > > > RIght I think you would need to build on F9 for support on F11 not the > > > other way around. Just like you would do with shared libraries. You > > > would not expect an c executable built on F11 to run on F9? > > > > I think he wants a single code base which can be built on F9 or F11. I > > might not expect that C to run, but I'd expect the same source could be > > compiled on either. > > > > We aren't providing enough information for his policy to know which > > interface it should be using, not sure how to solve the problem, but > > obviously Rob want a way to use the new interface if it is there and to > > use the old interface if it is not..... > > In the case of the ltp selinux test policy, which has a similar > challenge with changing refpolicy interfaces (as well as kernel changes, > e.g. introduction and enabling of open perm), I finally had to just fork > a copy of the test policy in a subdirectory for RHEL5, while continuing > to track the latest Fedora in the main directory. The Makefile then > selects what policy to build automatically. I do however enable the main copy of the test policy to build on multiple Fedora releases through use of ifdefs, ala: # If the base policy defines userdom_search_generic_user_home_dirs # then no action required; else define it to # userdom_search_user_home_dirs. ifdef(`userdom_search_generic_user_home_dirs', `', ` dnl interface(`userdom_search_generic_user_home_dirs', ` userdom_search_user_home_dirs($1) ') ') -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed Jul 1 15:00:46 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 01 Jul 2009 11:00:46 -0400 Subject: Supporting multiple OS releases In-Reply-To: <4A4A7881.6040303@redhat.com> References: <4A4A1C74.5040600@redhat.com> <4A4A7524.8010308@redhat.com> <4A4A7881.6040303@redhat.com> Message-ID: <1246460446.13464.180.camel@moss-pluto.epoch.ncsc.mil> On Tue, 2009-06-30 at 16:41 -0400, Rob Crittenden wrote: > Daniel J Walsh wrote: > > On 06/30/2009 10:08 AM, Rob Crittenden wrote: > >> In the freeIPA project we have our own SELinux policy. We support RHEL 5 > >> up through Fedora Rawhide. With Fedora 11 we saw some problems compiling > >> our SELinux module which Dan Walsh provided a patch for. I haven't tried > >> this on older releases yet but I'm guessing it won't work as expected > >> (some policies seem to have been renamed, such as > >> corenet_non_ipsec_sendrecv() -> corenet_all_recvfrom_unlabeled() > >> > >> My question is, how can we handle this in our source tree? Are we going > >> to need to maintain per-release policies or does SELinux support some > >> sort of versioning conditionals? > >> > >> thanks > >> > >> rob > >> > >> > >> ------------------------------------------------------------------------ > >> > >> -- > >> fedora-selinux-list mailing list > >> fedora-selinux-list at redhat.com > >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > The old interface will work, it just reports a nasty warning message > > when you compile it against newer policy. So I think you are safe > > compiling it on RHEL5 and installing it on F10/F11. > > We compile it on the given platform so we need some way to support all > at once. > > For example, the code that builds fine on F-11 fails like this on F-9: > > Compiling targeted ipa_webgui module > /usr/bin/checkmodule: loading policy configuration from tmp/ipa_webgui.tmp > ipa_webgui.te":77:ERROR 'syntax error' at token > 'userdom_dontaudit_search_admin_dir' on line 10764: > userdom_dontaudit_search_admin_dir(ipa_webgui_t) > > The diff between F-11 and F-9 being: > > -userdom_dontaudit_search_sysadm_home_dirs(ipa_webgui_t) > +userdom_dontaudit_search_admin_dir(ipa_webgui_t) Try adding this to your module .if file: ifdef(`userdom_dontaudit_search_admin_dir', `', ` dnl interface(`userdom_dontaudit_search_admin_dir', ` userdom_dontaudit_search_sysadm_home_dirs($1) ') ') And then use userdom_dontaudit_search_admin_dir throughout your module .te file. Then it should get remapped if not defined. -- Stephen Smalley National Security Agency From rcritten at redhat.com Wed Jul 1 19:07:59 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 01 Jul 2009 15:07:59 -0400 Subject: Supporting multiple OS releases In-Reply-To: <1246460446.13464.180.camel@moss-pluto.epoch.ncsc.mil> References: <4A4A1C74.5040600@redhat.com> <4A4A7524.8010308@redhat.com> <4A4A7881.6040303@redhat.com> <1246460446.13464.180.camel@moss-pluto.epoch.ncsc.mil> Message-ID: <4A4BB40F.5060302@redhat.com> Stephen Smalley wrote: > On Tue, 2009-06-30 at 16:41 -0400, Rob Crittenden wrote: >> Daniel J Walsh wrote: >>> On 06/30/2009 10:08 AM, Rob Crittenden wrote: >>>> In the freeIPA project we have our own SELinux policy. We support RHEL 5 >>>> up through Fedora Rawhide. With Fedora 11 we saw some problems compiling >>>> our SELinux module which Dan Walsh provided a patch for. I haven't tried >>>> this on older releases yet but I'm guessing it won't work as expected >>>> (some policies seem to have been renamed, such as >>>> corenet_non_ipsec_sendrecv() -> corenet_all_recvfrom_unlabeled() >>>> >>>> My question is, how can we handle this in our source tree? Are we going >>>> to need to maintain per-release policies or does SELinux support some >>>> sort of versioning conditionals? >>>> >>>> thanks >>>> >>>> rob >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> -- >>>> fedora-selinux-list mailing list >>>> fedora-selinux-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> The old interface will work, it just reports a nasty warning message >>> when you compile it against newer policy. So I think you are safe >>> compiling it on RHEL5 and installing it on F10/F11. >> We compile it on the given platform so we need some way to support all >> at once. >> >> For example, the code that builds fine on F-11 fails like this on F-9: >> >> Compiling targeted ipa_webgui module >> /usr/bin/checkmodule: loading policy configuration from tmp/ipa_webgui.tmp >> ipa_webgui.te":77:ERROR 'syntax error' at token >> 'userdom_dontaudit_search_admin_dir' on line 10764: >> userdom_dontaudit_search_admin_dir(ipa_webgui_t) >> >> The diff between F-11 and F-9 being: >> >> -userdom_dontaudit_search_sysadm_home_dirs(ipa_webgui_t) >> +userdom_dontaudit_search_admin_dir(ipa_webgui_t) > > Try adding this to your module .if file: > ifdef(`userdom_dontaudit_search_admin_dir', `', ` dnl > interface(`userdom_dontaudit_search_admin_dir', ` > userdom_dontaudit_search_sysadm_home_dirs($1) > ') > ') > > And then use userdom_dontaudit_search_admin_dir throughout your > module .te file. Then it should get remapped if not defined. > This is exactly what I was looking for, thanks. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From BGinn at symark.com Wed Jul 1 23:15:36 2009 From: BGinn at symark.com (Brian Ginn) Date: Wed, 1 Jul 2009 16:15:36 -0700 Subject: getpwnam and SELinux Message-ID: <8F43ACC6DCEECD4FA252B8042E2C4B8B9F3288E0B4@dragonfly.symark.com> I have an app that I'm trying to confine. In enforcing mode, getpwnam() returns "X" for the pw_passwd field. Is there SELinux policy to allow this app to get the shadow passwd? I've tried the following without success: auth_can_read_shadow_passwords( ) auth_read_shadow( ) auth_tunable_read_shadow( ) auth_use_nsswitch( ) Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From chepkov at yahoo.com Thu Jul 2 09:42:31 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Thu, 2 Jul 2009 02:42:31 -0700 (PDT) Subject: sysstat policy Message-ID: <592724.746.qm@web36808.mail.mud.yahoo.com> It seems sysstat policy in Fedora 11 needs adjustment, it didn't happen before: type=AVC msg=audit(1246506781.781:1687): avc: denied { read } for pid=16924 comm="find" name="mls" dev=selinuxfs ino=12 scontext=system_u:system_r:sysstat_t:s0-s0:c0.c1023 tcontext=system_u:object_r:security_t:s0 tclass=file Sincerely yours, Vadym Chepkov From paul at city-fan.org Thu Jul 2 10:03:56 2009 From: paul at city-fan.org (Paul Howarth) Date: Thu, 02 Jul 2009 11:03:56 +0100 Subject: sysstat policy In-Reply-To: <592724.746.qm@web36808.mail.mud.yahoo.com> References: <592724.746.qm@web36808.mail.mud.yahoo.com> Message-ID: <4A4C860C.20004@city-fan.org> On 02/07/09 10:42, Vadym Chepkov wrote: > It seems sysstat policy in Fedora 11 needs adjustment, it didn't happen before: > > type=AVC msg=audit(1246506781.781:1687): avc: denied { read } for pid=16924 comm="find" name="mls" dev=selinuxfs ino=12 scontext=system_u:system_r:sysstat_t:s0-s0:c0.c1023 tcontext=system_u:object_r:security_t:s0 tclass=file A lot of things are generating denials like these at the moment, not just sysstat. There's a libselinux update in the pipeline that should resolve it. Paul. From sds at tycho.nsa.gov Thu Jul 2 11:52:49 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 02 Jul 2009 07:52:49 -0400 Subject: getpwnam and SELinux In-Reply-To: <8F43ACC6DCEECD4FA252B8042E2C4B8B9F3288E0B4@dragonfly.symark.com> References: <8F43ACC6DCEECD4FA252B8042E2C4B8B9F3288E0B4@dragonfly.symark.com> Message-ID: <1246535569.13464.237.camel@moss-pluto.epoch.ncsc.mil> On Wed, 2009-07-01 at 16:15 -0700, Brian Ginn wrote: > I have an app that I'm trying to confine. > > > > In enforcing mode, getpwnam() returns "X" for the pw_passwd field. > > > > Is there SELinux policy to allow this app to get the shadow passwd? > > I've tried the following without success: > > auth_can_read_shadow_passwords( ) > > auth_read_shadow( ) > > auth_tunable_read_shadow( ) > > auth_use_nsswitch( ) Can you show us the actual denial? Run semodule -DB first if you don't get any denials, and then run semodule -B afterward. Also, post your .te file. -- Stephen Smalley National Security Agency From paul at city-fan.org Thu Jul 2 12:12:47 2009 From: paul at city-fan.org (Paul Howarth) Date: Thu, 02 Jul 2009 13:12:47 +0100 Subject: proftpd and mod_ban Message-ID: <4A4CA43F.80000@city-fan.org> proftpd's mod_ban uses shared memory, so I needed to add this policy locally on F-11: # Proftpd needs shared memory for mod_ban allow ftpd_t self:shm create_shm_perms; Paul. From an037-ooai8 at yahoo.com Fri Jul 3 06:21:16 2009 From: an037-ooai8 at yahoo.com (Allen Kistler) Date: Fri, 03 Jul 2009 01:21:16 -0500 Subject: Confining stunnel started from init script Message-ID: <4A4DA35C.6000504@yahoo.com> Since F7, I've started stunnel as a daemon from an init script. In F11, I'm confining it using SELinux, instead of just letting it run as initrc_t. However, I've got two questions. First: I think at some point, it might be worth submitting what I've done as an enhancement, minor though it may be, to stunnel. In my case, I use stunnel to establish an SSL tunnel to my ISP's smtps port from sendmail. Since I bind stunnel locally to tcp/465, I can't define stunnel_port_t (the pre-existing label for whatever port the end user chooses to use) as tcp/465 because tcp/465 is already labeled as smtp_port_t. What I've done is: bool stunnel_can_sendmail false; if (stunnel_can_sendmail) { allow stunnel_t smtp_port_t : tcp_socket name_bind; }; Does this seem the most reasonable way to do things with ports already labeled? For a more general policy, that would mean a Boolean for every port label. Hmm.... Second: What's the syntax in the TE file to get descriptive text attached to a Boolean declaration? Right now I get: # semanage boolean -l | grep stunnel_can_sendmail stunnel_can_sendmail -> on stunnel_can_sendmail But I'd prefer something more informative and cosmetically pleasing like: # semanage boolean -l | grep xen_use_nfs xen_use_nfs -> off Allow xen to manage nfs files Thanks for any info and assistance. From mgrepl at redhat.com Fri Jul 3 06:40:19 2009 From: mgrepl at redhat.com (Miroslav Grepl) Date: Fri, 03 Jul 2009 08:40:19 +0200 Subject: proftpd and mod_ban In-Reply-To: <4A4CA43F.80000@city-fan.org> References: <4A4CA43F.80000@city-fan.org> Message-ID: <4A4DA7D3.2020208@redhat.com> On 07/02/2009 02:12 PM, Paul Howarth wrote: > proftpd's mod_ban uses shared memory, so I needed to add this policy > locally on F-11: > > # Proftpd needs shared memory for mod_ban > allow ftpd_t self:shm create_shm_perms; > > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list You are right. I will add it to selinux-policy-3.6.12-63.fc11 Miroslav -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at city-fan.org Fri Jul 3 06:43:06 2009 From: paul at city-fan.org (Paul Howarth) Date: Fri, 3 Jul 2009 07:43:06 +0100 Subject: Confining stunnel started from init script In-Reply-To: <4A4DA35C.6000504@yahoo.com> References: <4A4DA35C.6000504@yahoo.com> Message-ID: <20090703074306.5a2e05c1@metropolis.intra.city-fan.org> On Fri, 03 Jul 2009 01:21:16 -0500 Allen Kistler wrote: > Since F7, I've started stunnel as a daemon from an init script. In > F11, I'm confining it using SELinux, instead of just letting it run > as initrc_t. However, I've got two questions. > > First: > I think at some point, it might be worth submitting what I've done as > an enhancement, minor though it may be, to stunnel. In my case, I > use stunnel to establish an SSL tunnel to my ISP's smtps port from > sendmail. Since I bind stunnel locally to tcp/465, I can't define > stunnel_port_t (the pre-existing label for whatever port the end user > chooses to use) as tcp/465 because tcp/465 is already labeled as > smtp_port_t. What I've done is: > > bool stunnel_can_sendmail false; > > if (stunnel_can_sendmail) { > allow stunnel_t smtp_port_t : tcp_socket name_bind; > }; > > Does this seem the most reasonable way to do things with ports > already labeled? For a more general policy, that would mean a > Boolean for every port label. Hmm.... This looks like exactly the right thing to me. > Second: > What's the syntax in the TE file to get descriptive text attached to > a Boolean declaration? Right now I get: > > # semanage boolean -l | grep stunnel_can_sendmail > stunnel_can_sendmail -> on stunnel_can_sendmail > > But I'd prefer something more informative and cosmetically pleasing > like: > > # semanage boolean -l | grep xen_use_nfs > xen_use_nfs -> off Allow xen to manage nfs files > > Thanks for any info and assistance. ## ##

## Allow samba to export NFS volumes. ##

## gen_tunable(samba_share_nfs, false) Paul. From shintaro.fujiwara at gmail.com Sat Jul 4 07:09:02 2009 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Sat, 4 Jul 2009 16:09:02 +0900 Subject: rpm post install can't install pp files Message-ID: Hi, when I tried to install my.pp by post install script in my.rpm, I go semodule: my.pp Failed ! But I could succeed in tar-ball file, why ? Thanks in advance. -- http://intrajp.no-ip.com/ Home Page From linuxking at live.com Sat Jul 4 10:37:18 2009 From: linuxking at live.com (John Smith) Date: Sat, 4 Jul 2009 11:37:18 +0100 Subject: QEMU in Fedora 10 Message-ID: Hello, I'm working on QEMU right now on Fedora 10. Interestingly I QEMU runs in qemu_unconfined_t. as I have not changed any of the labelling of my qemu files ( chroot directory, qemu filesystem image). I find it working with them with no denial messages. I have checked the policy for qemu on tresys refpolicy trunk, which somehow make the QEMU unconfined. Is this true? _________________________________________________________________ With Windows Live, you can organise, edit, and share your photos. http://clk.atdmt.com/UKM/go/134665338/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.stott at gmail.com Sat Jul 4 11:41:55 2009 From: jonathan.stott at gmail.com (Jonathan Stott) Date: Sat, 4 Jul 2009 12:41:55 +0100 Subject: SELinux and gitosis (FC11) In-Reply-To: <4A4A4954.40308@redhat.com> References: <20090630162121.58df1092@hzhangpg02.ph.man.ac.uk> <4A4A4954.40308@redhat.com> Message-ID: <14cf210a0907040441p38dce15k91dee18697f0fd9a@mail.gmail.com> Hi # rpm -q selinux-policy selinux-policy-targeted selinux-policy-3.6.12-62.fc11.noarch selinux-policy-targeted-3.6.12-62.fc11.noarch (previously it was 3.6.12-53) And gitosis-serve is labelled gitosis_exec_t Even after upgrading the selinux policy versions, it still seems to hang in the same manner though. Regards, Jon From chepkov at yahoo.com Sat Jul 4 12:11:18 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Sat, 4 Jul 2009 05:11:18 -0700 (PDT) Subject: Domain transition missing Message-ID: <327554.66260.qm@web36802.mail.mud.yahoo.com> Hi, Last night I got a nasty surprise from selinux. I am using winbind for external authentication and since it has history of failures I have a simple watchdog implemented to check the status and restart it if necessary. That is what happened last night and as a law abiding selinux citizen I used 'service winbind restart', but it seems the proper domain transitions is missing and winbind was started in system_cronjob_t domain instead of winbind_t and none of other domains could connect to it. I think jobs running from cron should be granted the same transition rules as from unconfined_t. I will file bugzilla report about it, but could somebody help me with modifying my local policy until/if it gets implemented, please? Thank you. Sincerely yours, Vadym Chepkov From domg472 at gmail.com Sat Jul 4 12:38:03 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 04 Jul 2009 14:38:03 +0200 Subject: Domain transition missing In-Reply-To: <327554.66260.qm@web36802.mail.mud.yahoo.com> References: <327554.66260.qm@web36802.mail.mud.yahoo.com> Message-ID: <1246711083.7188.12.camel@notebook1.grift.internal> On Sat, 2009-07-04 at 05:11 -0700, Vadym Chepkov wrote: > Hi, > > Last night I got a nasty surprise from selinux. I am using winbind for external authentication and since it has history of failures I have a simple watchdog implemented to check the status and restart it if necessary. That is what happened last night and as a law abiding selinux citizen I used 'service winbind restart', but it seems the proper domain transitions is missing and winbind was started in system_cronjob_t domain instead of winbind_t and none of other domains could connect to it. > > I think jobs running from cron should be granted the same transition rules as from unconfined_t. > > I will file bugzilla report about it, but could somebody help me with modifying my local policy until/if it gets implemented, please? Thank you. > > Sincerely yours, > Vadym Chepkov A domain transition would be: policy_module(mywinbind, 0.0.1) require { type system_cronjob_t, winbind_exec_t, winbind_t; } domain_auto_trans(system_cronjob_t, winbind_exec_t, winbind_t) Can you show us the full raw avc denial? > -- > 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 Sat Jul 4 12:41:27 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 04 Jul 2009 14:41:27 +0200 Subject: Domain transition missing In-Reply-To: <1246711083.7188.12.camel@notebook1.grift.internal> References: <327554.66260.qm@web36802.mail.mud.yahoo.com> <1246711083.7188.12.camel@notebook1.grift.internal> Message-ID: <1246711287.7188.15.camel@notebook1.grift.internal> On Sat, 2009-07-04 at 14:38 +0200, Dominick Grift wrote: > On Sat, 2009-07-04 at 05:11 -0700, Vadym Chepkov wrote: > > Hi, > > > > Last night I got a nasty surprise from selinux. I am using winbind for external authentication and since it has history of failures I have a simple watchdog implemented to check the status and restart it if necessary. That is what happened last night and as a law abiding selinux citizen I used 'service winbind restart', but it seems the proper domain transitions is missing and winbind was started in system_cronjob_t domain instead of winbind_t and none of other domains could connect to it. > > > > I think jobs running from cron should be granted the same transition rules as from unconfined_t. > > > > I will file bugzilla report about it, but could somebody help me with modifying my local policy until/if it gets implemented, please? Thank you. > > > > Sincerely yours, > > Vadym Chepkov > > A domain transition would be: > > policy_module(mywinbind, 0.0.1) > > require { type system_cronjob_t, winbind_exec_t, winbind_t; } > domain_auto_trans(system_cronjob_t, winbind_exec_t, winbind_t) > > Can you show us the full raw avc denial? But personally would deal with this in a different way. I would write policy for the script that restarts winbind and then i would create a domain transition for the domain in which the script runs to winbind_t. Mainly because i wouldnt want to extend/modify system_cronjob_t So: system_cronjob_t -> myscript_exec_t -> myscript_t -> winbind_exec_t -> winbind_t > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From chepkov at yahoo.com Sat Jul 4 12:44:34 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Sat, 4 Jul 2009 05:44:34 -0700 (PDT) Subject: Domain transition missing Message-ID: <331774.73517.qm@web36804.mail.mud.yahoo.com> Thank you Every single daemon out there was choking, just a few: type=AVC msg=audit(1246707387.606:8922): avc: denied { connectto } for pid=1313 comm="dovecot-auth" path="/var/run/winbindd/pipe" scontext=unconfined_u:system_r:dovecot_auth_t:s0 tcontext=system_u:system_r:system_cronjob_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1246707463.608:8931): avc: denied { connectto } for pid=6828 comm="sendmail" path="/var/run/winbindd/pipe" scontext=unconfined_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:system_cronjob_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1246707468.105:8932): avc: denied { connectto } for pid=6841 comm="procmail" path="/var/run/winbindd/pipe" scontext=unconfined_u:system_r:procmail_t:s0 tcontext=system_u:system_r:system_cronjob_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1246707508.622:8935): avc: denied { connectto } for pid=6847 comm="sendmail" path="/var/run/winbindd/pipe" scontext=unconfined_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:system_cronjob_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1246707508.629:8936): avc: denied { connectto } for pid=6851 comm="dbus-daemon-lau" path="/var/run/winbindd/pipe" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_cronjob_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1246707632.720:8963): avc: denied { connectto } for pid=7855 comm="pop3" path="/var/run/winbindd/pipe" scontext=unconfined_u:system_r:dovecot_t:s0 tcontext=system_u:system_r:system_cronjob_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1246707632.732:8964): avc: denied { connectto } for pid=7857 comm="dbus-daemon-lau" path="/var/run/winbindd/pipe" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_cronjob_t:s0 tclass=unix_stream_socket Sincerely yours, Vadym Chepkov --- On Sat, 7/4/09, Dominick Grift wrote: > From: Dominick Grift > Subject: Re: Domain transition missing > To: "Vadym Chepkov" > Cc: "Fedora SELinux" > Date: Saturday, July 4, 2009, 8:38 AM > On Sat, 2009-07-04 at 05:11 -0700, > Vadym Chepkov wrote: > > Hi, > > > > Last night I got a nasty surprise from selinux. I am > using winbind for external authentication and since it has > history of failures I have a simple watchdog implemented to > check the status and restart it if necessary. That is? > what happened last night and as a law abiding selinux > citizen I used 'service winbind restart', but it seems the > proper domain transitions is missing and winbind was started > in system_cronjob_t domain instead of winbind_t and none of > other domains could connect to it. > > > > I think jobs running from cron should be granted the > same transition rules as? from unconfined_t. > > > > I will file bugzilla report about it, but could > somebody help me with modifying my local policy until/if it > gets implemented, please? Thank you. > > > > Sincerely yours, > >???Vadym Chepkov > > A domain transition would be: > > policy_module(mywinbind, 0.0.1) > > require { type system_cronjob_t, winbind_exec_t, winbind_t; > } > domain_auto_trans(system_cronjob_t, winbind_exec_t, > winbind_t) > > Can you show us the full raw avc denial? > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From chepkov at yahoo.com Sat Jul 4 12:48:26 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Sat, 4 Jul 2009 05:48:26 -0700 (PDT) Subject: Domain transition missing Message-ID: <156305.76378.qm@web36804.mail.mud.yahoo.com> I really get used to running my scripts unconfined, how I can accomplish it in this scenario? Sincerely yours, Vadym Chepkov --- On Sat, 7/4/09, Dominick Grift wrote: > From: Dominick Grift > Subject: Re: Domain transition missing > To: "Vadym Chepkov" > Cc: "Fedora SELinux" > Date: Saturday, July 4, 2009, 8:41 AM > On Sat, 2009-07-04 at 14:38 +0200, > Dominick Grift wrote: > > On Sat, 2009-07-04 at 05:11 -0700, Vadym Chepkov > wrote: > > > Hi, > > > > > > Last night I got a nasty surprise from selinux. I > am using winbind for external authentication and since it > has history of failures I have a simple watchdog implemented > to check the status and restart it if necessary. That > is? what happened last night and as a law abiding > selinux citizen I used 'service winbind restart', but it > seems the proper domain transitions is missing and winbind > was started in system_cronjob_t domain instead of winbind_t > and none of other domains could connect to it. > > > > > > I think jobs running from cron should be granted > the same transition rules as? from unconfined_t. > > > > > > I will file bugzilla report about it, but could > somebody help me with modifying my local policy until/if it > gets implemented, please? Thank you. > > > > > > Sincerely yours, > > >???Vadym Chepkov > > > > A domain transition would be: > > > > policy_module(mywinbind, 0.0.1) > > > > require { type system_cronjob_t, winbind_exec_t, > winbind_t; } > > domain_auto_trans(system_cronjob_t, winbind_exec_t, > winbind_t) > > > > Can you show us the full raw avc denial? > > > But personally would deal with this in a different way. I > would write > policy for the script that restarts winbind and then i > would create a > domain transition for the domain in which the script runs > to winbind_t. > > Mainly because i wouldnt want to extend/modify > system_cronjob_t > > So: system_cronjob_t -> myscript_exec_t -> myscript_t > -> winbind_exec_t > -> winbind_t > > > > -- > > > 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 Sat Jul 4 12:53:36 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 04 Jul 2009 14:53:36 +0200 Subject: Domain transition missing In-Reply-To: <331774.73517.qm@web36804.mail.mud.yahoo.com> References: <331774.73517.qm@web36804.mail.mud.yahoo.com> Message-ID: <1246712016.7188.23.camel@notebook1.grift.internal> On Sat, 2009-07-04 at 05:44 -0700, Vadym Chepkov wrote: > Thank you > > Every single daemon out there was choking, just a few: > > type=AVC msg=audit(1246707387.606:8922): avc: denied { connectto } for pid=1313 comm="dovecot-auth" path="/var/run/winbindd/pipe" scontext=unconfined_u:system_r:dovecot_auth_t:s0 tcontext=system_u:system_r:system_cronjob_t:s0 tclass=unix_stream_socket > type=AVC msg=audit(1246707463.608:8931): avc: denied { connectto } for pid=6828 comm="sendmail" path="/var/run/winbindd/pipe" scontext=unconfined_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:system_cronjob_t:s0 tclass=unix_stream_socket > type=AVC msg=audit(1246707468.105:8932): avc: denied { connectto } for pid=6841 comm="procmail" path="/var/run/winbindd/pipe" scontext=unconfined_u:system_r:procmail_t:s0 tcontext=system_u:system_r:system_cronjob_t:s0 tclass=unix_stream_socket > type=AVC msg=audit(1246707508.622:8935): avc: denied { connectto } for pid=6847 comm="sendmail" path="/var/run/winbindd/pipe" scontext=unconfined_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:system_cronjob_t:s0 tclass=unix_stream_socket > type=AVC msg=audit(1246707508.629:8936): avc: denied { connectto } for pid=6851 comm="dbus-daemon-lau" path="/var/run/winbindd/pipe" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_cronjob_t:s0 tclass=unix_stream_socket > type=AVC msg=audit(1246707632.720:8963): avc: denied { connectto } for pid=7855 comm="pop3" path="/var/run/winbindd/pipe" scontext=unconfined_u:system_r:dovecot_t:s0 tcontext=system_u:system_r:system_cronjob_t:s0 tclass=unix_stream_socket > type=AVC msg=audit(1246707632.732:8964): avc: denied { connectto } for pid=7857 comm="dbus-daemon-lau" path="/var/run/winbindd/pipe" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_cronjob_t:s0 tclass=unix_stream_socket > > Sincerely yours, > Vadym Chepkov > You need to run winbind in the winbind_t domain. 1. create a policy for your cronjob script. 2. make it so that system_cronjob_t transitions to the domain of your cronjob script. 3. make your cronjob script domain auto transition to winbind_t It is not so simple to make his work properly the way cron is currently configured in SELinux. I can help you make a policy though but i would need some info 1. where is the cron script located (/path/name) 2. whats ur distro 3. what is the type of winbind executable? ls -alZ /path/to/winbind Here is an example for a backup cron script i made earlier: http://desktop1/~dgrift/stuff/modules/backupdgrift.te http://desktop1/~dgrift/stuff/modules/backupdgrift.if http://desktop1/~dgrift/stuff/modules/backupdgrift.fc > --- On Sat, 7/4/09, Dominick Grift wrote: > > > From: Dominick Grift > > Subject: Re: Domain transition missing > > To: "Vadym Chepkov" > > Cc: "Fedora SELinux" > > Date: Saturday, July 4, 2009, 8:38 AM > > On Sat, 2009-07-04 at 05:11 -0700, > > Vadym Chepkov wrote: > > > Hi, > > > > > > Last night I got a nasty surprise from selinux. I am > > using winbind for external authentication and since it has > > history of failures I have a simple watchdog implemented to > > check the status and restart it if necessary. That is > > what happened last night and as a law abiding selinux > > citizen I used 'service winbind restart', but it seems the > > proper domain transitions is missing and winbind was started > > in system_cronjob_t domain instead of winbind_t and none of > > other domains could connect to it. > > > > > > I think jobs running from cron should be granted the > > same transition rules as from unconfined_t. > > > > > > I will file bugzilla report about it, but could > > somebody help me with modifying my local policy until/if it > > gets implemented, please? Thank you. > > > > > > Sincerely yours, > > > Vadym Chepkov > > > > A domain transition would be: > > > > policy_module(mywinbind, 0.0.1) > > > > require { type system_cronjob_t, winbind_exec_t, winbind_t; > > } > > domain_auto_trans(system_cronjob_t, winbind_exec_t, > > winbind_t) > > > > Can you show us the full raw avc denial? > > > > > -- > > > 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 Sat Jul 4 12:57:53 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 04 Jul 2009 14:57:53 +0200 Subject: Domain transition missing In-Reply-To: <156305.76378.qm@web36804.mail.mud.yahoo.com> References: <156305.76378.qm@web36804.mail.mud.yahoo.com> Message-ID: <1246712273.7188.26.camel@notebook1.grift.internal> On Sat, 2009-07-04 at 05:48 -0700, Vadym Chepkov wrote: > I really get used to running my scripts unconfined, how I can accomplish it in this scenario? > > Sincerely yours, > Vadym Chepkov > if you want the system to run jobs you will need to write some policy or extend the system_cronjob_t domain i think Were those the only avc denial you got? I would expect more denials. > --- On Sat, 7/4/09, Dominick Grift wrote: > > > From: Dominick Grift > > Subject: Re: Domain transition missing > > To: "Vadym Chepkov" > > Cc: "Fedora SELinux" > > Date: Saturday, July 4, 2009, 8:41 AM > > On Sat, 2009-07-04 at 14:38 +0200, > > Dominick Grift wrote: > > > On Sat, 2009-07-04 at 05:11 -0700, Vadym Chepkov > > wrote: > > > > Hi, > > > > > > > > Last night I got a nasty surprise from selinux. I > > am using winbind for external authentication and since it > > has history of failures I have a simple watchdog implemented > > to check the status and restart it if necessary. That > > is what happened last night and as a law abiding > > selinux citizen I used 'service winbind restart', but it > > seems the proper domain transitions is missing and winbind > > was started in system_cronjob_t domain instead of winbind_t > > and none of other domains could connect to it. > > > > > > > > I think jobs running from cron should be granted > > the same transition rules as from unconfined_t. > > > > > > > > I will file bugzilla report about it, but could > > somebody help me with modifying my local policy until/if it > > gets implemented, please? Thank you. > > > > > > > > Sincerely yours, > > > > Vadym Chepkov > > > > > > A domain transition would be: > > > > > > policy_module(mywinbind, 0.0.1) > > > > > > require { type system_cronjob_t, winbind_exec_t, > > winbind_t; } > > > domain_auto_trans(system_cronjob_t, winbind_exec_t, > > winbind_t) > > > > > > Can you show us the full raw avc denial? > > > > > > But personally would deal with this in a different way. I > > would write > > policy for the script that restarts winbind and then i > > would create a > > domain transition for the domain in which the script runs > > to winbind_t. > > > > Mainly because i wouldnt want to extend/modify > > system_cronjob_t > > > > So: system_cronjob_t -> myscript_exec_t -> myscript_t > > -> winbind_exec_t > > -> winbind_t > > > > > > -- > > > > fedora-selinux-list mailing list > > > > fedora-selinux-list at redhat.com > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > > From chepkov at yahoo.com Sat Jul 4 13:18:37 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Sat, 4 Jul 2009 06:18:37 -0700 (PDT) Subject: Domain transition missing Message-ID: <467495.30108.qm@web36808.mail.mud.yahoo.com> That would be unfortunate. Mine approach is not uncommon. If you look closely you will see the same technique in wast scripts. spamassassin restarts itself when it updates anti-spam rules, clamav does that (antivirus) and on and on. I use Fedora 11, by the way. For now, instead of creating a new policy I just added 'runcon -t unconfind_t ' in the cron, and it seemed to did the trick. Sincerely yours, Vadym Chepkov --- On Sat, 7/4/09, Dominick Grift wrote: > From: Dominick Grift > Subject: Re: Domain transition missing > To: "Vadym Chepkov" > Cc: "Fedora SELinux" > Date: Saturday, July 4, 2009, 8:57 AM > On Sat, 2009-07-04 at 05:48 -0700, > Vadym Chepkov wrote: > > I really get used to running my scripts unconfined, > how I can accomplish it in this scenario? > > > > Sincerely yours, > >???Vadym Chepkov > > > > if you want the system to run jobs you will need to write > some policy or > extend the system_cronjob_t domain i think > > > Were those the only avc denial you got? I would expect more > denials. > > > --- On Sat, 7/4/09, Dominick Grift > wrote: > > > > > From: Dominick Grift > > > Subject: Re: Domain transition missing > > > To: "Vadym Chepkov" > > > Cc: "Fedora SELinux" > > > Date: Saturday, July 4, 2009, 8:41 AM > > > On Sat, 2009-07-04 at 14:38 +0200, > > > Dominick Grift wrote: > > > > On Sat, 2009-07-04 at 05:11 -0700, Vadym > Chepkov > > > wrote: > > > > > Hi, > > > > > > > > > > Last night I got a nasty surprise from > selinux. I > > > am using winbind for external authentication and > since it > > > has history of failures I have a simple watchdog > implemented > > > to check the status and restart it if necessary. > That > > > is? what happened last night and as a law > abiding > > > selinux citizen I used 'service winbind restart', > but it > > > seems the proper domain transitions is missing > and winbind > > > was started in system_cronjob_t domain instead of > winbind_t > > > and none of other domains could connect to it. > > > > > > > > > > I think jobs running from cron should > be granted > > > the same transition rules as? from > unconfined_t. > > > > > > > > > > I will file bugzilla report about it, > but could > > > somebody help me with modifying my local policy > until/if it > > > gets implemented, please? Thank you. > > > > > > > > > > Sincerely yours, > > > > >???Vadym Chepkov > > > > > > > > A domain transition would be: > > > > > > > > policy_module(mywinbind, 0.0.1) > > > > > > > > require { type system_cronjob_t, > winbind_exec_t, > > > winbind_t; } > > > > domain_auto_trans(system_cronjob_t, > winbind_exec_t, > > > winbind_t) > > > > > > > > Can you show us the full raw avc denial? > > > > > > > > > But personally would deal with this in a > different way. I > > > would write > > > policy for the script that restarts winbind and > then i > > > would create a > > > domain transition for the domain in which the > script runs > > > to winbind_t. > > > > > > Mainly because i wouldnt want to extend/modify > > > system_cronjob_t > > > > > > So: system_cronjob_t -> myscript_exec_t -> > myscript_t > > > -> winbind_exec_t > > > -> winbind_t > > > > > > > > -- > > > > > 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 Sat Jul 4 13:28:58 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 04 Jul 2009 15:28:58 +0200 Subject: Domain transition missing In-Reply-To: <467495.30108.qm@web36808.mail.mud.yahoo.com> References: <467495.30108.qm@web36808.mail.mud.yahoo.com> Message-ID: <1246714138.7649.3.camel@notebook1.grift.internal> On Sat, 2009-07-04 at 06:18 -0700, Vadym Chepkov wrote: > That would be unfortunate. Mine approach is not uncommon. If you look closely you will see the same technique in wast scripts. spamassassin restarts itself when it updates anti-spam rules, clamav does that (antivirus) and on and on. I use Fedora 11, by the way. > > For now, instead of creating a new policy I just added 'runcon -t unconfind_t ' in the cron, and it seemed to did the trick. > > Sincerely yours, > Vadym Chepkov > Looking here: http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/services/cron.if line 235 to line 269. That seems like a interface one might use in your situation: cron_system_entry(winbind_t, winbind_exec_t) I admit that using cron with SELinux is not very easy currently > --- On Sat, 7/4/09, Dominick Grift wrote: > > > From: Dominick Grift > > Subject: Re: Domain transition missing > > To: "Vadym Chepkov" > > Cc: "Fedora SELinux" > > Date: Saturday, July 4, 2009, 8:57 AM > > On Sat, 2009-07-04 at 05:48 -0700, > > Vadym Chepkov wrote: > > > I really get used to running my scripts unconfined, > > how I can accomplish it in this scenario? > > > > > > Sincerely yours, > > > Vadym Chepkov > > > > > > > if you want the system to run jobs you will need to write > > some policy or > > extend the system_cronjob_t domain i think > > > > > > Were those the only avc denial you got? I would expect more > > denials. > > > > > --- On Sat, 7/4/09, Dominick Grift > > wrote: > > > > > > > From: Dominick Grift > > > > Subject: Re: Domain transition missing > > > > To: "Vadym Chepkov" > > > > Cc: "Fedora SELinux" > > > > Date: Saturday, July 4, 2009, 8:41 AM > > > > On Sat, 2009-07-04 at 14:38 +0200, > > > > Dominick Grift wrote: > > > > > On Sat, 2009-07-04 at 05:11 -0700, Vadym > > Chepkov > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > Last night I got a nasty surprise from > > selinux. I > > > > am using winbind for external authentication and > > since it > > > > has history of failures I have a simple watchdog > > implemented > > > > to check the status and restart it if necessary. > > That > > > > is what happened last night and as a law > > abiding > > > > selinux citizen I used 'service winbind restart', > > but it > > > > seems the proper domain transitions is missing > > and winbind > > > > was started in system_cronjob_t domain instead of > > winbind_t > > > > and none of other domains could connect to it. > > > > > > > > > > > > I think jobs running from cron should > > be granted > > > > the same transition rules as from > > unconfined_t. > > > > > > > > > > > > I will file bugzilla report about it, > > but could > > > > somebody help me with modifying my local policy > > until/if it > > > > gets implemented, please? Thank you. > > > > > > > > > > > > Sincerely yours, > > > > > > Vadym Chepkov > > > > > > > > > > A domain transition would be: > > > > > > > > > > policy_module(mywinbind, 0.0.1) > > > > > > > > > > require { type system_cronjob_t, > > winbind_exec_t, > > > > winbind_t; } > > > > > domain_auto_trans(system_cronjob_t, > > winbind_exec_t, > > > > winbind_t) > > > > > > > > > > Can you show us the full raw avc denial? > > > > > > > > > > > > But personally would deal with this in a > > different way. I > > > > would write > > > > policy for the script that restarts winbind and > > then i > > > > would create a > > > > domain transition for the domain in which the > > script runs > > > > to winbind_t. > > > > > > > > Mainly because i wouldnt want to extend/modify > > > > system_cronjob_t > > > > > > > > So: system_cronjob_t -> myscript_exec_t -> > > myscript_t > > > > -> winbind_exec_t > > > > -> winbind_t > > > > > > > > > > -- > > > > > > fedora-selinux-list mailing list > > > > > > fedora-selinux-list at redhat.com > > > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > > > > > > > > > > > > From chepkov at yahoo.com Sat Jul 4 14:00:54 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Sat, 4 Jul 2009 07:00:54 -0700 (PDT) Subject: Domain transition missing Message-ID: <432743.50588.qm@web36808.mail.mud.yahoo.com> This worked well too, thank you system_u:system_r:winbind_t:SystemLow root 11926 1 0 09:57 ? 00:00:00 winbindd system_u:system_r:winbind_t:SystemLow root 11928 11926 0 09:57 ? 00:00:00 winbindd system_u:system_r:winbind_t:SystemLow root 11954 11926 0 09:57 ? 00:00:00 winbindd system_u:system_r:winbind_t:SystemLow root 11956 11926 0 09:57 ? 00:00:00 winbindd system_u:system_r:winbind_t:SystemLow root 11957 11926 0 09:57 ? 00:00:00 winbindd Sincerely yours, Vadym Chepkov --- On Sat, 7/4/09, Dominick Grift wrote: > From: Dominick Grift > Subject: Re: Domain transition missing > To: "Vadym Chepkov" > Cc: "Fedora SELinux" > Date: Saturday, July 4, 2009, 9:28 AM > On Sat, 2009-07-04 at 06:18 -0700, > Vadym Chepkov wrote: > > That would be unfortunate. Mine approach is not > uncommon. If you look closely you will see the same > technique in wast scripts. spamassassin restarts itself when > it updates anti-spam rules, clamav does that (antivirus) and > on and on. I use Fedora 11, by the way. > > > > For now, instead of creating a new policy I just added > 'runcon -t unconfind_t ' in the cron, and it seemed to did > the trick.? > > > > Sincerely yours, > >???Vadym Chepkov > > > > Looking here: > http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/services/cron.if > line 235 to line 269. > > That seems like a interface one might use in your > situation: > > cron_system_entry(winbind_t, winbind_exec_t) > > I admit that using cron with SELinux is not very easy > currently > > > --- On Sat, 7/4/09, Dominick Grift > wrote: > > > > > From: Dominick Grift > > > Subject: Re: Domain transition missing > > > To: "Vadym Chepkov" > > > Cc: "Fedora SELinux" > > > Date: Saturday, July 4, 2009, 8:57 AM > > > On Sat, 2009-07-04 at 05:48 -0700, > > > Vadym Chepkov wrote: > > > > I really get used to running my scripts > unconfined, > > > how I can accomplish it in this scenario? > > > > > > > > Sincerely yours, > > > >???Vadym Chepkov > > > > > > > > > > if you want the system to run jobs you will need > to write > > > some policy or > > > extend the system_cronjob_t domain i think > > > > > > > > > Were those the only avc denial you got? I would > expect more > > > denials. > > > > > > > --- On Sat, 7/4/09, Dominick Grift > > > wrote: > > > > > > > > > From: Dominick Grift > > > > > Subject: Re: Domain transition missing > > > > > To: "Vadym Chepkov" > > > > > Cc: "Fedora SELinux" > > > > > Date: Saturday, July 4, 2009, 8:41 AM > > > > > On Sat, 2009-07-04 at 14:38 +0200, > > > > > Dominick Grift wrote: > > > > > > On Sat, 2009-07-04 at 05:11 -0700, > Vadym > > > Chepkov > > > > > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Last night I got a nasty > surprise from > > > selinux. I > > > > > am using winbind for external > authentication and > > > since it > > > > > has history of failures I have a simple > watchdog > > > implemented > > > > > to check the status and restart it if > necessary. > > > That > > > > > is? what happened last night and > as a law > > > abiding > > > > > selinux citizen I used 'service winbind > restart', > > > but it > > > > > seems the proper domain transitions is > missing > > > and winbind > > > > > was started in system_cronjob_t domain > instead of > > > winbind_t > > > > > and none of other domains could connect > to it. > > > > > > > > > > > > > > I think jobs running from > cron should > > > be granted > > > > > the same transition rules as? > from > > > unconfined_t. > > > > > > > > > > > > > > I will file bugzilla report > about it, > > > but could > > > > > somebody help me with modifying my > local policy > > > until/if it > > > > > gets implemented, please? Thank you. > > > > > > > > > > > > > > Sincerely yours, > > > > > > >???Vadym > Chepkov > > > > > > > > > > > > A domain transition would be: > > > > > > > > > > > > policy_module(mywinbind, 0.0.1) > > > > > > > > > > > > require { type system_cronjob_t, > > > winbind_exec_t, > > > > > winbind_t; } > > > > > > > domain_auto_trans(system_cronjob_t, > > > winbind_exec_t, > > > > > winbind_t) > > > > > > > > > > > > Can you show us the full raw avc > denial? > > > > > > > > > > > > > > > But personally would deal with this in > a > > > different way. I > > > > > would write > > > > > policy for the script that restarts > winbind and > > > then i > > > > > would create a > > > > > domain transition for the domain in > which the > > > script runs > > > > > to winbind_t. > > > > > > > > > > Mainly because i wouldnt want to > extend/modify > > > > > system_cronjob_t > > > > > > > > > > So: system_cronjob_t -> > myscript_exec_t -> > > > myscript_t > > > > > -> winbind_exec_t > > > > > -> winbind_t > > > > > > > > > > > > -- > > > > > > > fedora-selinux-list mailing > list > > > > > > > fedora-selinux-list at redhat.com > > > > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > > > > > > > > > > > > > > > > > > > From chepkov at yahoo.com Sat Jul 4 14:09:41 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Sat, 4 Jul 2009 07:09:41 -0700 (PDT) Subject: Domain transition missing Message-ID: <138975.46083.qm@web36806.mail.mud.yahoo.com> It would be nice if the interface would be smart enough and allow output from the cron job to be sent, but no one is perfect :) ---- type=AVC msg=audit(1246715821.417:10142): avc: denied { write } for pid=11916 comm="winbind" path="pipe:[591689]" dev=pipefs ino=591689 scontext=system_u:system_r:system_cronjob_t:s0 tcontext=unconfined_u:system_r:crond_t:s0-s0:c0.c1023 tclass=fifo_file ---- type=AVC msg=audit(1246715821.780:10143): avc: denied { write } for pid=11925 comm="winbindd" path="pipe:[591689]" dev=pipefs ino=591689 scontext=system_u:system_r:winbind_t:s0 tcontext=unconfined_u:system_r:crond_t:s0-s0:c0.c1023 tclass=fifo_file Sincerely yours, Vadym Chepkov --- On Sat, 7/4/09, Vadym Chepkov wrote: > From: Vadym Chepkov > Subject: Re: Domain transition missing > To: "Dominick Grift" > Cc: "Fedora SELinux" > Date: Saturday, July 4, 2009, 10:00 AM > This worked well too, thank you > > system_u:system_r:winbind_t:SystemLow root > 11926???1? 0 09:57 ?? ? ? > ? 00:00:00 winbindd > system_u:system_r:winbind_t:SystemLow root 11928 > 11926? 0 09:57 ?? ? ? 00:00:00 winbindd > system_u:system_r:winbind_t:SystemLow root 11954 > 11926? 0 09:57 ?? ? ? 00:00:00 winbindd > system_u:system_r:winbind_t:SystemLow root 11956 > 11926? 0 09:57 ?? ? ? 00:00:00 winbindd > system_u:system_r:winbind_t:SystemLow root 11957 > 11926? 0 09:57 ?? ? ? 00:00:00 winbindd > > > Sincerely yours, > ? Vadym Chepkov > > > --- On Sat, 7/4/09, Dominick Grift > wrote: > > > From: Dominick Grift > > Subject: Re: Domain transition missing > > To: "Vadym Chepkov" > > Cc: "Fedora SELinux" > > Date: Saturday, July 4, 2009, 9:28 AM > > On Sat, 2009-07-04 at 06:18 -0700, > > Vadym Chepkov wrote: > > > That would be unfortunate. Mine approach is not > > uncommon. If you look closely you will see the same > > technique in wast scripts. spamassassin restarts > itself when > > it updates anti-spam rules, clamav does that > (antivirus) and > > on and on. I use Fedora 11, by the way. > > > > > > For now, instead of creating a new policy I just > added > > 'runcon -t unconfind_t ' in the cron, and it seemed to > did > > the trick.? > > > > > > Sincerely yours, > > >???Vadym Chepkov > > > > > > > Looking here: > > http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/services/cron.if > > line 235 to line 269. > > > > That seems like a interface one might use in your > > situation: > > > > cron_system_entry(winbind_t, winbind_exec_t) > > > > I admit that using cron with SELinux is not very easy > > currently > > > > > --- On Sat, 7/4/09, Dominick Grift > > wrote: > > > > > > > From: Dominick Grift > > > > Subject: Re: Domain transition missing > > > > To: "Vadym Chepkov" > > > > Cc: "Fedora SELinux" > > > > Date: Saturday, July 4, 2009, 8:57 AM > > > > On Sat, 2009-07-04 at 05:48 -0700, > > > > Vadym Chepkov wrote: > > > > > I really get used to running my > scripts > > unconfined, > > > > how I can accomplish it in this scenario? > > > > > > > > > > Sincerely yours, > > > > >???Vadym Chepkov > > > > > > > > > > > > > if you want the system to run jobs you will > need > > to write > > > > some policy or > > > > extend the system_cronjob_t domain i think > > > > > > > > > > > > Were those the only avc denial you got? I > would > > expect more > > > > denials. > > > > > > > > > --- On Sat, 7/4/09, Dominick Grift > > > > > wrote: > > > > > > > > > > > From: Dominick Grift > > > > > > Subject: Re: Domain transition > missing > > > > > > To: "Vadym Chepkov" > > > > > > Cc: "Fedora SELinux" > > > > > > Date: Saturday, July 4, 2009, 8:41 > AM > > > > > > On Sat, 2009-07-04 at 14:38 > +0200, > > > > > > Dominick Grift wrote: > > > > > > > On Sat, 2009-07-04 at 05:11 > -0700, > > Vadym > > > > Chepkov > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > Last night I got a > nasty > > surprise from > > > > selinux. I > > > > > > am using winbind for external > > authentication and > > > > since it > > > > > > has history of failures I have a > simple > > watchdog > > > > implemented > > > > > > to check the status and restart it > if > > necessary. > > > > That > > > > > > is? what happened last night and > > as a law > > > > abiding > > > > > > selinux citizen I used 'service > winbind > > restart', > > > > but it > > > > > > seems the proper domain > transitions is > > missing > > > > and winbind > > > > > > was started in system_cronjob_t > domain > > instead of > > > > winbind_t > > > > > > and none of other domains could > connect > > to it. > > > > > > > > > > > > > > > > I think jobs running > from > > cron should > > > > be granted > > > > > > the same transition rules as? > > from > > > > unconfined_t. > > > > > > > > > > > > > > > > I will file bugzilla > report > > about it, > > > > but could > > > > > > somebody help me with modifying > my > > local policy > > > > until/if it > > > > > > gets implemented, please? Thank > you. > > > > > > > > > > > > > > > > Sincerely yours, > > > > > > > >???Vadym > > Chepkov > > > > > > > > > > > > > > A domain transition would > be: > > > > > > > > > > > > > > policy_module(mywinbind, > 0.0.1) > > > > > > > > > > > > > > require { type > system_cronjob_t, > > > > winbind_exec_t, > > > > > > winbind_t; } > > > > > > > > > domain_auto_trans(system_cronjob_t, > > > > winbind_exec_t, > > > > > > winbind_t) > > > > > > > > > > > > > > Can you show us the full raw > avc > > denial? > > > > > > > > > > > > > > > > > > But personally would deal with > this in > > a > > > > different way. I > > > > > > would write > > > > > > policy for the script that > restarts > > winbind and > > > > then i > > > > > > would create a > > > > > > domain transition for the domain > in > > which the > > > > script runs > > > > > > to winbind_t. > > > > > > > > > > > > Mainly because i wouldnt want to > > extend/modify > > > > > > system_cronjob_t > > > > > > > > > > > > So: system_cronjob_t -> > > myscript_exec_t -> > > > > myscript_t > > > > > > -> winbind_exec_t > > > > > > -> winbind_t > > > > > > > > > > > > > > -- > > > > > > > > fedora-selinux-list > mailing > > list > > > > > > > > fedora-selinux-list at redhat.com > > > > > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From chepkov at yahoo.com Sat Jul 4 14:37:31 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Sat, 4 Jul 2009 07:37:31 -0700 (PDT) Subject: Strange denials Message-ID: <991230.41638.qm@web36801.mail.mud.yahoo.com> Ok, I am lost I clearly allowed this. allow winbind_t crond_t:fifo_file write; I can see it in the policy: sesearch --all --source winbind_t --target crond_t Found 3 semantic av rules: allow winbind_t crond_t : process sigchld ; allow winbind_t crond_t : fd use ; allow winbind_t crond_t : fifo_file { ioctl read write getattr lock append open } ; Why do I get denial anyway? time->Sat Jul 4 10:28:01 2009 type=SYSCALL msg=audit(1246717681.676:10436): arch=40000003 syscall=11 success=yes exit=0 a0=9073c10 a1=9073358 a2=90732a8 a3=9073358 items=0 ppid=20323 pid=20324 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=777 comm="winbindd" exe="/usr/sbin/winbindd" subj=system_u:system_r:winbind_t:s0 key=(null) type=AVC msg=audit(1246717681.676:10436): avc: denied { write } for pid=20324 comm="winbindd" path="pipe:[611496]" dev=pipefs ino=611496 scontext=system_u:system_r:winbind_t:s0 tcontext=unconfined_u:system_r:crond_t:s0-s0:c0.c1023 tclass=fifo_file Sincerely yours, Vadym Chepkov From leguerinos at gmail.com Sat Jul 4 14:55:43 2009 From: leguerinos at gmail.com (=?ISO-8859-1?Q?K=E9vin_GUERIN?=) Date: Sat, 4 Jul 2009 16:55:43 +0200 Subject: Strange denials In-Reply-To: <991230.41638.qm@web36801.mail.mud.yahoo.com> References: <991230.41638.qm@web36801.mail.mud.yahoo.com> Message-ID: winbindd is running with no MCS categories and tries to access a file with c0.c0123. Access will be granted only if winbindd runs with all the categories that has the file it wants to interact with. K?vin 2009/7/4 Vadym Chepkov > > Ok, I am lost > > I clearly allowed this. > > allow winbind_t crond_t:fifo_file write; > > I can see it in the policy: > sesearch --all --source winbind_t --target crond_t > Found 3 semantic av rules: > allow winbind_t crond_t : process sigchld ; > allow winbind_t crond_t : fd use ; > allow winbind_t crond_t : fifo_file { ioctl read write getattr lock > append open } ; > > Why do I get denial anyway? > > time->Sat Jul 4 10:28:01 2009 > type=SYSCALL msg=audit(1246717681.676:10436): arch=40000003 syscall=11 > success=yes exit=0 a0=9073c10 a1=9073358 a2=90732a8 a3=9073358 items=0 > ppid=20323 pid=20324 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=(none) ses=777 comm="winbindd" exe="/usr/sbin/winbindd" > subj=system_u:system_r:winbind_t:s0 key=(null) > type=AVC msg=audit(1246717681.676:10436): avc: denied { write } for > pid=20324 comm="winbindd" path="pipe:[611496]" dev=pipefs ino=611496 > scontext=system_u:system_r:winbind_t:s0 > tcontext=unconfined_u:system_r:crond_t:s0-s0:c0.c1023 tclass=fifo_file > > > Sincerely yours, > Vadym Chepkov > > -- > 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 chepkov at yahoo.com Sat Jul 4 15:19:33 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Sat, 4 Jul 2009 08:19:33 -0700 (PDT) Subject: Strange denials Message-ID: <785397.13993.qm@web36808.mail.mud.yahoo.com> I barely redirect output of a cron job to /dev/null :( Is the a way to run cron unconfined? I don't see any boolean anymore. Sincerely yours, Vadym Chepkov --- On Sat, 7/4/09, K?vin GUERIN wrote: > From: K?vin GUERIN > Subject: Re: Strange denials > To: "Vadym Chepkov" > Cc: "Fedora SELinux" > Date: Saturday, July 4, 2009, 10:55 AM > winbindd is running with no MCS > categories and tries to access a file with c0.c0123. > > Access will be granted only if winbindd runs with all the > categories that has the file it wants to interact with. > > K?vin > > > 2009/7/4 Vadym Chepkov > > > > Ok, I am lost > > > > I clearly allowed this. > > > > allow winbind_t crond_t:fifo_file write; > > > > I can see it in the policy: > > sesearch --all --source winbind_t --target crond_t > > Found 3 semantic av rules: > > ? allow winbind_t crond_t : process sigchld ; > > ? allow winbind_t crond_t : fd use ; > > ? allow winbind_t crond_t : fifo_file { ioctl read write > getattr lock append open } ; > > > > Why do I get denial anyway? > > > > time->Sat Jul ?4 10:28:01 2009 > > type=SYSCALL msg=audit(1246717681.676:10436): arch=40000003 > syscall=11 success=yes exit=0 a0=9073c10 a1=9073358 > a2=90732a8 a3=9073358 items=0 ppid=20323 pid=20324 auid=0 > uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > tty=(none) ses=777 comm="winbindd" > exe="/usr/sbin/winbindd" > subj=system_u:system_r:winbind_t:s0 key=(null) > > > type=AVC msg=audit(1246717681.676:10436): avc: ?denied ?{ > write } for ?pid=20324 comm="winbindd" > path="pipe:[611496]" dev=pipefs ino=611496 > scontext=system_u:system_r:winbind_t:s0 > tcontext=unconfined_u:system_r:crond_t:s0-s0:c0.c1023 > tclass=fifo_file > > > > > > > Sincerely yours, > > ?Vadym Chepkov > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > From gene at czarc.net Sat Jul 4 16:13:47 2009 From: gene at czarc.net (Gene Czarcinski) Date: Sat, 4 Jul 2009 12:13:47 -0400 Subject: sVirt Message-ID: <200907041213.47694.gene@czarc.net> I am having some problems with the design/implementation of sVirt for Fedora- virtualization on Fedora 11. 1. I am a longtime user of Fedora since FC1 and, prior to that, I used Red Hat Linux. 2. I am a big fan of SELinux and have been using it since FC3 and always run in enforcing mode. I get upset/angry when someone suggests disabling SELinux to "fix" my problems. If there is a "bug", report it and get it fixed ... do not ignore it. 3. I have also been a longtime user of VMware. However, with Fedora- virtualization on Fedora 11, I decided to "change my problem set" and give Fedora-virtualization a try ... especially since I now have an AMD Phenom II 940 which supports hardware virtualization. I have researched and found a number of documents which provide some of the goals, etc. for sVirt. However, I have hit some undesirable characteristics and bad side effects in dealing with ISO images. First of all, sVirt changes/sets the file context for any virtual disk, ISO image, or device (e.g., /dev/sr0) ... I am not sure what happens with LVM logical volumes because I have not tried them yet. I understand that, with mandatory access control, a process should be denied access to all resources except those which have been explicitly permitted. I assume this is the reason for setting/changing the file context. For ISO images, this is BAD! I have an apache (httpd) server running which has access to my repository of ISO images. After I create a virtual guest and point to an ISO image in the repository, the apache server can no longer see that ISO image! Bad, BAD! Yes, I know restorecon will fix things up but this should not happen in the first place. Another (related) problem is that I cannot use an ISO image file on a read-only mounted file system. Why? Just what is being protected here? As currently implemented, there is no protection between guests with respect to their individual virtual disk files. This really does need doing and it will be interesting to see how it will be done by SELinux (assuming this is protected by Fedora-virtualization applications software is not good enough). Some suggestions: 1. I am not sure what should be done with real devices such as /dev/sr0. 2. For files on read-only file systems, don't do anything ... they are protected about as much as they can be. 3. For files in /var/lib/libvirt/images, set the file context as is now done. This is also true if I locate my read/write virtual disk (file) elsewhere. 4. For ISO files, maybe there should be a new/special file context which allows sharing between processes ... it would be explicit but it would allow sharing ... maybe something like "public_content_t". 5. Maybe implement a switch which disables SELinux enforcing (and does not change the file context of ISO files) for Fedora-virtualization. 6. Maybe the switch should be by guest. - - - - - OK, I can see where locking down Fedora-virtualization with mandatory access control would be very interesting to some organizations such as NSA but that this would be used in a very rigidly controlled and limited system. But, this stuff has to be usable in other environments too. - - - - - - Finally ... IMHO, the design/implementation of SELinux for Fedora- virtualization was a bit of a quick-and-dirty approach ... do what we know how to do. I suggest that maybe some SELinux folks and some key Fedora- virtualization (especially libvirt) folks should take a week off (or maybe just a weekend), go off somewhere where you will not be bothered, and the figure out what should be done ... not "how" ... just the "should" at first. Then after some time has passed so that folks have had time to think about it, have another "session" where the "how" is considered and a roadmap is created. Just some food for thought. Gene From domg472 at gmail.com Sat Jul 4 17:19:38 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 04 Jul 2009 19:19:38 +0200 Subject: sVirt In-Reply-To: <200907041213.47694.gene@czarc.net> References: <200907041213.47694.gene@czarc.net> Message-ID: <1246727979.2811.10.camel@notebook2.grift.internal> On Sat, 2009-07-04 at 12:13 -0400, Gene Czarcinski wrote: > I am having some problems with the design/implementation of sVirt for Fedora- > virtualization on Fedora 11. > > 1. I am a longtime user of Fedora since FC1 and, prior to that, I used Red Hat > Linux. > > 2. I am a big fan of SELinux and have been using it since FC3 and always run > in enforcing mode. I get upset/angry when someone suggests disabling SELinux > to "fix" my problems. If there is a "bug", report it and get it fixed ... do > not ignore it. > > 3. I have also been a longtime user of VMware. However, with Fedora- > virtualization on Fedora 11, I decided to "change my problem set" and give > Fedora-virtualization a try ... especially since I now have an AMD Phenom II > 940 which supports hardware virtualization. > > I have researched and found a number of documents which provide some of the > goals, etc. for sVirt. However, I have hit some undesirable characteristics > and bad side effects in dealing with ISO images. > > First of all, sVirt changes/sets the file context for any virtual disk, ISO > image, or device (e.g., /dev/sr0) ... I am not sure what happens with LVM > logical volumes because I have not tried them yet. ls -alZ /dev/mapper | grep volume2 brw-rw----. root disk system_u:object_r:svirt_image_t:s0:c168,c894 vg_mybook-lv_volume2 > I understand that, with mandatory access control, a process should be denied > access to all resources except those which have been explicitly permitted. I > assume this is the reason for setting/changing the file context. For ISO > images, this is BAD! > > I have an apache (httpd) server running which has access to my repository of > ISO images. After I create a virtual guest and point to an ISO image in the > repository, the apache server can no longer see that ISO image! Bad, BAD! > Yes, I know restorecon will fix things up but this should not happen in the > first place. > > Another (related) problem is that I cannot use an ISO image file on a read-only > mounted file system. Why? Just what is being protected here? > > As currently implemented, there is no protection between guests with respect > to their individual virtual disk files. This really does need doing and it > will be interesting to see how it will be done by SELinux (assuming this is > protected by Fedora-virtualization applications software is not good enough). > > Some suggestions: > > 1. I am not sure what should be done with real devices such as /dev/sr0. > > 2. For files on read-only file systems, don't do anything ... they are protected > about as much as they can be. > > 3. For files in /var/lib/libvirt/images, set the file context as is now done. > This is also true if I locate my read/write virtual disk (file) elsewhere. > > 4. For ISO files, maybe there should be a new/special file context which allows > sharing between processes ... it would be explicit but it would allow sharing > ... maybe something like "public_content_t". > > 5. Maybe implement a switch which disables SELinux enforcing (and does not > change the file context of ISO files) for Fedora-virtualization. > > 6. Maybe the switch should be by guest. > > - - - - - > > OK, I can see where locking down Fedora-virtualization with mandatory access > control would be very interesting to some organizations such as NSA but that > this would be used in a very rigidly controlled and limited system. But, this > stuff has to be usable in other environments too. > > - - - - - - > > Finally ... IMHO, the design/implementation of SELinux for Fedora- > virtualization was a bit of a quick-and-dirty approach ... do what we know > how to do. I suggest that maybe some SELinux folks and some key Fedora- > virtualization (especially libvirt) folks should take a week off (or maybe just > a weekend), go off somewhere where you will not be bothered, and the figure out > what should be done ... not "how" ... just the "should" at first. Then after > some time has passed so that folks have had time to think about it, have > another "session" where the "how" is considered and a roadmap is created. > > Just some food for thought. > > Gene There was a libvirt/svirt test-day earlier but dwalsh was not there, and svirt was not mentioned by anyone. I know svirt is a work in progress. I have not tested the iso image thing but sounds like you have a good point there. My svirt setup is very generic and i did not notice any such issues. > -- > 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: 197 bytes Desc: This is a digitally signed message part URL: From an037-ooai8 at yahoo.com Sun Jul 5 00:09:09 2009 From: an037-ooai8 at yahoo.com (Allen Kistler) Date: Sat, 04 Jul 2009 19:09:09 -0500 Subject: Confining stunnel started from init script In-Reply-To: <20090703074306.5a2e05c1@metropolis.intra.city-fan.org> References: <4A4DA35C.6000504@yahoo.com> <20090703074306.5a2e05c1@metropolis.intra.city-fan.org> Message-ID: <4A4FEF25.8010104@yahoo.com> Paul Howarth wrote: > On Fri, 03 Jul 2009 01:21:16 -0500 > Allen Kistler wrote: >> [snip] >> >> Second: >> What's the syntax in the TE file to get descriptive text attached to >> a Boolean declaration? Right now I get: >> >> # semanage boolean -l | grep stunnel_can_sendmail >> stunnel_can_sendmail -> on stunnel_can_sendmail >> >> But I'd prefer something more informative and cosmetically pleasing >> like: >> >> # semanage boolean -l | grep xen_use_nfs >> xen_use_nfs -> off Allow xen to manage nfs files >> >> Thanks for any info and assistance. > > ## > ##

> ## Allow samba to export NFS volumes. > ##

> ## > gen_tunable(samba_share_nfs, false) checkmodule doesn't like that syntax in the TE file. I guess I need to install some macro preprocessors for the not-so-vanilla stuff. From berrange at redhat.com Sun Jul 5 10:36:05 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Sun, 5 Jul 2009 11:36:05 +0100 Subject: sVirt In-Reply-To: <200907041213.47694.gene@czarc.net> References: <200907041213.47694.gene@czarc.net> Message-ID: <20090705103605.GA8963@redhat.com> On Sat, Jul 04, 2009 at 12:13:47PM -0400, Gene Czarcinski wrote: > 1. I am not sure what should be done with real devices such as /dev/sr0. sVirt does not distinguish based on device type, rather it goes off the disk mode. Exclusive Read/write disks get a label with an mcs level specific to the guest, Read/write shared get a label with an mcs level of 0, and read-only disks get a label system_u:object_r:svirt_image_t:s0 which allows read access. > 2. For files on read-only file systems, don't do anything ... they are protected > about as much as they can be. As has been mentioned in the bug you raised several days ago, this issue should already be addressed https://bugzilla.redhat.com/show_bug.cgi?id=507555 > 4. For ISO files, maybe there should be a new/special file context which allows > sharing between processes ... it would be explicit but it would allow sharing > ... maybe something like "public_content_t". There is already a label for read only guest images system_u:object_r:svirt_image_t:s0 it shouldn't be much work for you to add a custom SELinux plugin that gives httpd_t access to content labelled svirt_image_t. Ask the fedora-selinux mailing list for assistance if needed > 5. Maybe implement a switch which disables SELinux enforcing (and does not > change the file context of ISO files) for Fedora-virtualization. Already present /etc/libvirt/qemu.conf , change security_driver="none" > 6. Maybe the switch should be by guest. Easy enough to add - file a bug if you want this capability. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From casmls at gmail.com Sun Jul 5 12:45:37 2009 From: casmls at gmail.com (Christoph A.) Date: Sun, 05 Jul 2009 14:45:37 +0200 Subject: kismet - DBUS AVCs Message-ID: <4A50A071.2090800@gmail.com> Hi, I'm running fedora 11. rpm -qa selinux* selinux-policy-3.6.12-53.fc11.noarch selinux-policy-targeted-3.6.12-53.fc11.noarch When I try to start kismet it failes with this error: WARNING: Failed to connect to DBUS system, will not be able to control networkmanager: Failed to connect to socket /var/run/dbus/system_bus_socket: Permission denied WARNING: Failed to send 'sleep' command to networkmanager via DBUS, NM may try to take control of the interfaces still.FATAL: Dump file error: Unable to open dump file /home/kismet/dump/Jul-05-2009-14-26-09.dump (No such file or directory) Sending termination request to channel control child 10743... WARNING: Error disabling monitor mode: mode set ioctl failed 16:Device or resource busy WARNING: WIFI5100AGN (wlan0) left in an unknown state. You may need to manually restart or reconfigure it for normal operation. WARNING: Sometimes cards don't always come out of monitor mode cleanly. If your card is not fully working, you may need to restart or reconfigure it for normal operation. Waiting for channel control child 10743 to exit... Trying to wake networkmanager back up... WARNING: Failed to connect to DBUS system, will not be able to control networkmanager: Failed to connect to socket /var/run/dbus/system_bus_socket: Permission denied WARNING: Failed to send 'wake' command to networkmanager via DBUS, NM may still be inactive.Kismet exiting. log: node=localhost.localdomain type=AVC msg=audit(1246795836.328:420): avc: denied { search } for pid=10334 comm="kismet_server" name="dbus" dev=dm-1 ino=2000053 scontext=unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=dir node=localhost.localdomain type=SYSCALL msg=audit(1246795836.328:420): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfe50b20 a2=bbeff4 a3=bfe50ccc items=0 ppid=10333 pid=10334 auid=500 uid=492 gid=496 euid=492 suid=492 fsuid=492 egid=496 sgid=496 fsgid=496 tty=pts0 ses=1 comm="kismet_server" exe="/usr/bin/kismet_server" subj=unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 key=(null) while searching the web I found a old but similar issue: http://www.linux-archive.org/fedora-selinux-support/195736-further-selinux-kismet.html What should I do to successfully start kismet (without disabling SELinux)? thanks Christoph (kismet.conf attached) From domg472 at gmail.com Sun Jul 5 13:31:04 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sun, 05 Jul 2009 15:31:04 +0200 Subject: kismet - DBUS AVCs In-Reply-To: <4A50A071.2090800@gmail.com> References: <4A50A071.2090800@gmail.com> Message-ID: <1246800664.5852.2.camel@notebook2.grift.internal> On Sun, 2009-07-05 at 14:45 +0200, Christoph A. wrote: > Hi, > > I'm running fedora 11. > > rpm -qa selinux* > selinux-policy-3.6.12-53.fc11.noarch > selinux-policy-targeted-3.6.12-53.fc11.noarch > > When I try to start kismet it failes with this error: > > WARNING: Failed to connect to DBUS system, will not be able to control > networkmanager: Failed to connect to socket > /var/run/dbus/system_bus_socket: Permission denied > WARNING: Failed to send 'sleep' command to networkmanager via DBUS, NM > may try to take control of the interfaces still.FATAL: Dump file error: > Unable to open dump file /home/kismet/dump/Jul-05-2009-14-26-09.dump (No > such file or directory) > Sending termination request to channel control child 10743... > WARNING: Error disabling monitor mode: mode set ioctl failed 16:Device > or resource busy > WARNING: WIFI5100AGN (wlan0) left in an unknown state. You may need to > manually > restart or reconfigure it for normal operation. > WARNING: Sometimes cards don't always come out of monitor mode > cleanly. If your card is not fully working, you may need to > restart or reconfigure it for normal operation. > Waiting for channel control child 10743 to exit... > Trying to wake networkmanager back up... > WARNING: Failed to connect to DBUS system, will not be able to control > networkmanager: Failed to connect to socket > /var/run/dbus/system_bus_socket: Permission denied > WARNING: Failed to send 'wake' command to networkmanager via DBUS, NM > may still be inactive.Kismet exiting. > > > log: > > node=localhost.localdomain type=AVC msg=audit(1246795836.328:420): avc: > denied { search } for pid=10334 comm="kismet_server" name="dbus" > dev=dm-1 ino=2000053 > scontext=unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=dir > node=localhost.localdomain type=SYSCALL msg=audit(1246795836.328:420): > arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfe50b20 a2=bbeff4 > a3=bfe50ccc items=0 ppid=10333 pid=10334 auid=500 uid=492 gid=496 > euid=492 suid=492 fsuid=492 egid=496 sgid=496 fsgid=496 tty=pts0 ses=1 > comm="kismet_server" exe="/usr/bin/kismet_server" > subj=unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 key=(null) > > > while searching the web I found a old but similar issue: > http://www.linux-archive.org/fedora-selinux-support/195736-further-selinux-kismet.html > > What should I do to successfully start kismet (without disabling SELinux)? Probably: mkdir ~/mykismet; cd ~/mykismet; echo "policy_module(mykismet, 0.0.1)" > mykismet.te echo "require { type kismet_t; }" >> mykismet.te echo "dbus_system_bus_client(kismet_t) >> mykismet.te make -f /usr/share/selinux/devel mykismet.pp sudo semodule -i mykismet.po > thanks > Christoph > (kismet.conf attached) > > -- > 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: 197 bytes Desc: This is a digitally signed message part URL: From domg472 at gmail.com Sun Jul 5 13:32:35 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sun, 05 Jul 2009 15:32:35 +0200 Subject: kismet - DBUS AVCs In-Reply-To: <1246800664.5852.2.camel@notebook2.grift.internal> References: <4A50A071.2090800@gmail.com> <1246800664.5852.2.camel@notebook2.grift.internal> Message-ID: <1246800755.5852.3.camel@notebook2.grift.internal> On Sun, 2009-07-05 at 15:31 +0200, Dominick Grift wrote: > On Sun, 2009-07-05 at 14:45 +0200, Christoph A. wrote: > > Hi, > > > > I'm running fedora 11. > > > > rpm -qa selinux* > > selinux-policy-3.6.12-53.fc11.noarch > > selinux-policy-targeted-3.6.12-53.fc11.noarch > > > > When I try to start kismet it failes with this error: > > > > WARNING: Failed to connect to DBUS system, will not be able to control > > networkmanager: Failed to connect to socket > > /var/run/dbus/system_bus_socket: Permission denied > > WARNING: Failed to send 'sleep' command to networkmanager via DBUS, NM > > may try to take control of the interfaces still.FATAL: Dump file error: > > Unable to open dump file /home/kismet/dump/Jul-05-2009-14-26-09.dump (No > > such file or directory) > > Sending termination request to channel control child 10743... > > WARNING: Error disabling monitor mode: mode set ioctl failed 16:Device > > or resource busy > > WARNING: WIFI5100AGN (wlan0) left in an unknown state. You may need to > > manually > > restart or reconfigure it for normal operation. > > WARNING: Sometimes cards don't always come out of monitor mode > > cleanly. If your card is not fully working, you may need to > > restart or reconfigure it for normal operation. > > Waiting for channel control child 10743 to exit... > > Trying to wake networkmanager back up... > > WARNING: Failed to connect to DBUS system, will not be able to control > > networkmanager: Failed to connect to socket > > /var/run/dbus/system_bus_socket: Permission denied > > WARNING: Failed to send 'wake' command to networkmanager via DBUS, NM > > may still be inactive.Kismet exiting. > > > > > > log: > > > > node=localhost.localdomain type=AVC msg=audit(1246795836.328:420): avc: > > denied { search } for pid=10334 comm="kismet_server" name="dbus" > > dev=dm-1 ino=2000053 > > scontext=unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 > > tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=dir > > node=localhost.localdomain type=SYSCALL msg=audit(1246795836.328:420): > > arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfe50b20 a2=bbeff4 > > a3=bfe50ccc items=0 ppid=10333 pid=10334 auid=500 uid=492 gid=496 > > euid=492 suid=492 fsuid=492 egid=496 sgid=496 fsgid=496 tty=pts0 ses=1 > > comm="kismet_server" exe="/usr/bin/kismet_server" > > subj=unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 key=(null) > > > > > > while searching the web I found a old but similar issue: > > http://www.linux-archive.org/fedora-selinux-support/195736-further-selinux-kismet.html > > > > What should I do to successfully start kismet (without disabling SELinux)? > > Probably: > > mkdir ~/mykismet; cd ~/mykismet; > echo "policy_module(mykismet, 0.0.1)" > mykismet.te > echo "require { type kismet_t; }" >> mykismet.te > echo "dbus_system_bus_client(kismet_t) >> mykismet.te > make -f /usr/share/selinux/devel mykismet.pp make that: make -f /usr/share/selinux/devel/Makefile mykismet.pp > sudo semodule -i mykismet.po > > > thanks > > Christoph > > (kismet.conf attached) > > > > -- > > 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: 197 bytes Desc: This is a digitally signed message part URL: From paul at city-fan.org Sun Jul 5 15:55:04 2009 From: paul at city-fan.org (Paul Howarth) Date: Sun, 5 Jul 2009 16:55:04 +0100 Subject: sVirt In-Reply-To: <20090705103605.GA8963@redhat.com> References: <200907041213.47694.gene@czarc.net> <20090705103605.GA8963@redhat.com> Message-ID: <20090705165504.0ec053ce@metropolis.intra.city-fan.org> On Sun, 5 Jul 2009 11:36:05 +0100 "Daniel P. Berrange" wrote: > > 4. For ISO files, maybe there should be a new/special file context > > which allows sharing between processes ... it would be explicit but > > it would allow sharing ... maybe something like "public_content_t". > > There is already a label for read only guest images > > system_u:object_r:svirt_image_t:s0 > > it shouldn't be much work for you to add a custom SELinux plugin that > gives httpd_t access to content labelled svirt_image_t. Ask the > fedora-selinux mailing list for assistance if needed Couldn't an ISO image that's already public_content_t (or even public_content_rw_t) be left alone, as that type is already well-known and used for sharing this type of content by various means? Paul. From domg472 at gmail.com Sun Jul 5 18:13:12 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sun, 05 Jul 2009 20:13:12 +0200 Subject: kismet - DBUS AVCs In-Reply-To: <1246800755.5852.3.camel@notebook2.grift.internal> References: <4A50A071.2090800@gmail.com> <1246800664.5852.2.camel@notebook2.grift.internal> <1246800755.5852.3.camel@notebook2.grift.internal> Message-ID: <1246817592.5852.6.camel@notebook2.grift.internal> On Sun, 2009-07-05 at 15:32 +0200, Dominick Grift wrote: > On Sun, 2009-07-05 at 15:31 +0200, Dominick Grift wrote: > > On Sun, 2009-07-05 at 14:45 +0200, Christoph A. wrote: > > > Hi, > > > > > > I'm running fedora 11. > > > > > > rpm -qa selinux* > > > selinux-policy-3.6.12-53.fc11.noarch > > > selinux-policy-targeted-3.6.12-53.fc11.noarch > > > > > > When I try to start kismet it failes with this error: > > > > > > WARNING: Failed to connect to DBUS system, will not be able to control > > > networkmanager: Failed to connect to socket > > > /var/run/dbus/system_bus_socket: Permission denied > > > WARNING: Failed to send 'sleep' command to networkmanager via DBUS, NM > > > may try to take control of the interfaces still.FATAL: Dump file error: > > > Unable to open dump file /home/kismet/dump/Jul-05-2009-14-26-09.dump (No > > > such file or directory) > > > Sending termination request to channel control child 10743... > > > WARNING: Error disabling monitor mode: mode set ioctl failed 16:Device > > > or resource busy > > > WARNING: WIFI5100AGN (wlan0) left in an unknown state. You may need to > > > manually > > > restart or reconfigure it for normal operation. > > > WARNING: Sometimes cards don't always come out of monitor mode > > > cleanly. If your card is not fully working, you may need to > > > restart or reconfigure it for normal operation. > > > Waiting for channel control child 10743 to exit... > > > Trying to wake networkmanager back up... > > > WARNING: Failed to connect to DBUS system, will not be able to control > > > networkmanager: Failed to connect to socket > > > /var/run/dbus/system_bus_socket: Permission denied > > > WARNING: Failed to send 'wake' command to networkmanager via DBUS, NM > > > may still be inactive.Kismet exiting. > > > > > > > > > log: > > > > > > node=localhost.localdomain type=AVC msg=audit(1246795836.328:420): avc: > > > denied { search } for pid=10334 comm="kismet_server" name="dbus" > > > dev=dm-1 ino=2000053 > > > scontext=unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 > > > tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=dir > > > node=localhost.localdomain type=SYSCALL msg=audit(1246795836.328:420): > > > arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfe50b20 a2=bbeff4 > > > a3=bfe50ccc items=0 ppid=10333 pid=10334 auid=500 uid=492 gid=496 > > > euid=492 suid=492 fsuid=492 egid=496 sgid=496 fsgid=496 tty=pts0 ses=1 > > > comm="kismet_server" exe="/usr/bin/kismet_server" > > > subj=unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 key=(null) > > > > > > > > > while searching the web I found a old but similar issue: > > > http://www.linux-archive.org/fedora-selinux-support/195736-further-selinux-kismet.html > > > > > > What should I do to successfully start kismet (without disabling SELinux)? > > > > Probably: > > > > mkdir ~/mykismet; cd ~/mykismet; > > echo "policy_module(mykismet, 0.0.1)" > mykismet.te > > echo "require { type kismet_t; }" >> mykismet.te > > echo "dbus_system_bus_client(kismet_t) >> mykismet.te > > make -f /usr/share/selinux/devel mykismet.pp > make that: > > make -f /usr/share/selinux/devel/Makefile mykismet.pp > > sudo semodule -i mykismet.po > > By the way you might need to give it even more permissions. The DBUS daemon object manager logs a lot of stuff to /var/log/messages instead of /var/log/audit/audit.log. I could for example imagine kismet wanting to send dbus msgs to network-manager or both dbus chatting to each other. > > > thanks > > > Christoph > > > (kismet.conf attached) > > > > > > -- > > > 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: 197 bytes Desc: This is a digitally signed message part URL: From casmls at gmail.com Sun Jul 5 18:59:57 2009 From: casmls at gmail.com (Christoph A.) Date: Sun, 05 Jul 2009 20:59:57 +0200 Subject: kismet - DBUS AVCs In-Reply-To: <1246817592.5852.6.camel@notebook2.grift.internal> References: <4A50A071.2090800@gmail.com> <1246800664.5852.2.camel@notebook2.grift.internal> <1246800755.5852.3.camel@notebook2.grift.internal> <1246817592.5852.6.camel@notebook2.grift.internal> Message-ID: <4A50F82D.7040008@gmail.com> >> make -f /usr/share/selinux/devel/Makefile mykismet.pp >>> sudo semodule -i mykismet.po the module was loaded successfull: semodule -l|grep myk mykismet 0.0.1 > By the way you might need to give it even more permissions. The DBUS > daemon object manager logs a lot of stuff to /var/log/messages instead > of /var/log/audit/audit.log. > > I could for example imagine kismet wanting to send dbus msgs to > network-manager or both dbus chatting to each other. you are right: type=USER_AVC msg=audit(1246817621.469:1260): user pid=1652 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=signal interface=org.freedesktop.NetworkManager member=sleep dest=org.freedesktop.NetworkManager spid=18051 tpid=1850 scontext=unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 tcontext=system_u:system_r:NetworkManager_t:s0 tclass=dbus : exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' starting kismet in enforcing mode gives me: NOTICE: configdir '/root/' does not exist, making it. FATAL: Could not make configdir: File exists Before adding more homemade rules: I'm wondering if all other kismet users are turning off SELinux or if I have a special setup where the default rules of the kismet 1.2.0 module do not work? Also because Dan mentioned [1] that he will add dbus rules to solve these denies. The only thing that is non-standard in my config is the logtemplate configuration (see kismet.conf). [1] http://www.linux-archive.org/fedora-selinux-support/195736-further-selinux-kismet.html thanks Christoph -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: kismet.conf URL: From domg472 at gmail.com Sun Jul 5 19:16:12 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sun, 05 Jul 2009 21:16:12 +0200 Subject: kismet - DBUS AVCs In-Reply-To: <4A50F82D.7040008@gmail.com> References: <4A50A071.2090800@gmail.com> <1246800664.5852.2.camel@notebook2.grift.internal> <1246800755.5852.3.camel@notebook2.grift.internal> <1246817592.5852.6.camel@notebook2.grift.internal> <4A50F82D.7040008@gmail.com> Message-ID: <1246821372.5852.14.camel@notebook2.grift.internal> On Sun, 2009-07-05 at 20:59 +0200, Christoph A. wrote: > >> make -f /usr/share/selinux/devel/Makefile mykismet.pp > >>> sudo semodule -i mykismet.po > > the module was loaded successfull: > > semodule -l|grep myk > mykismet 0.0.1 > > > > By the way you might need to give it even more permissions. The DBUS > > daemon object manager logs a lot of stuff to /var/log/messages instead > > of /var/log/audit/audit.log. > > > > I could for example imagine kismet wanting to send dbus msgs to > > network-manager or both dbus chatting to each other. > > you are right: > type=USER_AVC msg=audit(1246817621.469:1260): user pid=1652 uid=81 > auid=4294967295 ses=4294967295 > subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied > { send_msg } for msgtype=signal interface=org.freedesktop.NetworkManager > member=sleep dest=org.freedesktop.NetworkManager spid=18051 tpid=1850 > scontext=unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:NetworkManager_t:s0 tclass=dbus : > exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' > > starting kismet in enforcing mode gives me: > NOTICE: configdir '/root/' does not exist, making it. > FATAL: Could not make configdir: File exists > > Before adding more homemade rules: > I'm wondering if all other kismet users are turning off SELinux or if I > have a special setup where the default rules of the kismet 1.2.0 module > do not work? > Also because Dan mentioned [1] that he will add dbus rules to solve > these denies. > The only thing that is non-standard in my config is the logtemplate > configuration (see kismet.conf). > > [1] > http://www.linux-archive.org/fedora-selinux-support/195736-further-selinux-kismet.html Well a few things to consider here: - not all wifi hardware work with kismet (mine doesnt) - in rhel it would run unconfined - fedora is a development platform and many devs run selinux in permissive mode unfortunatly (they focus on developing and care less about security) Obviously there are still bugs in you kismet policy: consider reporting to bugzilla.redhat.com/selinux-policy A fix for the above issue would be: networkmanager_dbus_chat(kismet.te) You would add that to you mykismet.te file and rebuild/reinstall the mykismet.pp However it may be that the above interface call is a bit too coarse since it allows two way chatting and the above denial only reports that kismet want to send_msg to network-manager. So in that case a new interface should be added to networkmanager.if: networkmanager_send_dbus_msg() > thanks > Christoph -------------- 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 Sun Jul 5 19:19:00 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sun, 05 Jul 2009 21:19:00 +0200 Subject: kismet - DBUS AVCs In-Reply-To: <1246821372.5852.14.camel@notebook2.grift.internal> References: <4A50A071.2090800@gmail.com> <1246800664.5852.2.camel@notebook2.grift.internal> <1246800755.5852.3.camel@notebook2.grift.internal> <1246817592.5852.6.camel@notebook2.grift.internal> <4A50F82D.7040008@gmail.com> <1246821372.5852.14.camel@notebook2.grift.internal> Message-ID: <1246821540.5852.15.camel@notebook2.grift.internal> On Sun, 2009-07-05 at 21:16 +0200, Dominick Grift wrote: > On Sun, 2009-07-05 at 20:59 +0200, Christoph A. wrote: > > >> make -f /usr/share/selinux/devel/Makefile mykismet.pp > > >>> sudo semodule -i mykismet.po > > > > the module was loaded successfull: > > > > semodule -l|grep myk > > mykismet 0.0.1 > > > > > > > By the way you might need to give it even more permissions. The DBUS > > > daemon object manager logs a lot of stuff to /var/log/messages instead > > > of /var/log/audit/audit.log. > > > > > > I could for example imagine kismet wanting to send dbus msgs to > > > network-manager or both dbus chatting to each other. > > > > you are right: > > type=USER_AVC msg=audit(1246817621.469:1260): user pid=1652 uid=81 > > auid=4294967295 ses=4294967295 > > subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied > > { send_msg } for msgtype=signal interface=org.freedesktop.NetworkManager > > member=sleep dest=org.freedesktop.NetworkManager spid=18051 tpid=1850 > > scontext=unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 > > tcontext=system_u:system_r:NetworkManager_t:s0 tclass=dbus : > > exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' > > > > starting kismet in enforcing mode gives me: > > NOTICE: configdir '/root/' does not exist, making it. > > FATAL: Could not make configdir: File exists > > > > Before adding more homemade rules: > > I'm wondering if all other kismet users are turning off SELinux or if I > > have a special setup where the default rules of the kismet 1.2.0 module > > do not work? > > Also because Dan mentioned [1] that he will add dbus rules to solve > > these denies. > > The only thing that is non-standard in my config is the logtemplate > > configuration (see kismet.conf). > > > > [1] > > http://www.linux-archive.org/fedora-selinux-support/195736-further-selinux-kismet.html > > Well a few things to consider here: > > - not all wifi hardware work with kismet (mine doesnt) > - in rhel it would run unconfined > - fedora is a development platform and many devs run selinux in > permissive mode unfortunatly (they focus on developing and care less > about security) > > > Obviously there are still bugs in you kismet policy: consider reporting > to bugzilla.redhat.com/selinux-policy > > A fix for the above issue would be: > > networkmanager_dbus_chat(kismet.te) make that: networkmanager_dbus_chat(kismet_t) > > You would add that to you mykismet.te file and rebuild/reinstall the > mykismet.pp > > However it may be that the above interface call is a bit too coarse > since it allows two way chatting and the above denial only reports that > kismet want to send_msg to network-manager. > > So in that case a new interface should be added to networkmanager.if: > > networkmanager_send_dbus_msg() > > > > thanks > > Christoph -------------- 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 casmls at gmail.com Sun Jul 5 20:41:10 2009 From: casmls at gmail.com (Christoph A.) Date: Sun, 05 Jul 2009 22:41:10 +0200 Subject: kismet - DBUS AVCs In-Reply-To: <1246821540.5852.15.camel@notebook2.grift.internal> References: <4A50A071.2090800@gmail.com> <1246800664.5852.2.camel@notebook2.grift.internal> <1246800755.5852.3.camel@notebook2.grift.internal> <1246817592.5852.6.camel@notebook2.grift.internal> <4A50F82D.7040008@gmail.com> <1246821372.5852.14.camel@notebook2.grift.internal> <1246821540.5852.15.camel@notebook2.grift.internal> Message-ID: <4A510FE6.3030400@gmail.com> >> Well a few things to consider here: >> >> - not all wifi hardware work with kismet (mine doesnt) >> - in rhel it would run unconfined >> - fedora is a development platform and many devs run selinux in >> permissive mode unfortunatly (they focus on developing and care less >> about security) thank you for your infos and fast replies >> Obviously there are still bugs in you kismet policy: consider reporting >> to bugzilla.redhat.com/selinux-policy I filed the bugreport here: https://bugzilla.redhat.com/show_bug.cgi?id=509756 going this way, maybe it will be fixed upstream instead of fixing it just locally thanks Christoph From dwalsh at redhat.com Mon Jul 6 12:12:26 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 06 Jul 2009 08:12:26 -0400 Subject: SELinux and gitosis (FC11) In-Reply-To: <14cf210a0907040441p38dce15k91dee18697f0fd9a@mail.gmail.com> References: <20090630162121.58df1092@hzhangpg02.ph.man.ac.uk> <4A4A4954.40308@redhat.com> <14cf210a0907040441p38dce15k91dee18697f0fd9a@mail.gmail.com> Message-ID: <4A51EA2A.8020609@redhat.com> On 07/04/2009 07:41 AM, Jonathan Stott wrote: > Hi > > # rpm -q selinux-policy selinux-policy-targeted > selinux-policy-3.6.12-62.fc11.noarch > selinux-policy-targeted-3.6.12-62.fc11.noarch > > (previously it was 3.6.12-53) > > And gitosis-serve is labelled gitosis_exec_t > > Even after upgrading the selinux policy versions, it still seems to > hang in the same manner though. > > Regards, > Jon > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Are you seeing any avc messages in /var/log/audit/audit.log? ps -eZ | grep gitosis Does this show apps running under the correct domain? From dwalsh at redhat.com Mon Jul 6 12:16:50 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 06 Jul 2009 08:16:50 -0400 Subject: sysstat policy In-Reply-To: <4A4C860C.20004@city-fan.org> References: <592724.746.qm@web36808.mail.mud.yahoo.com> <4A4C860C.20004@city-fan.org> Message-ID: <4A51EB32.4040403@redhat.com> On 07/02/2009 06:03 AM, Paul Howarth wrote: > On 02/07/09 10:42, Vadym Chepkov wrote: >> It seems sysstat policy in Fedora 11 needs adjustment, it didn't >> happen before: >> >> type=AVC msg=audit(1246506781.781:1687): avc: denied { read } for >> pid=16924 comm="find" name="mls" dev=selinuxfs ino=12 >> scontext=system_u:system_r:sysstat_t:s0-s0:c0.c1023 >> tcontext=system_u:object_r:security_t:s0 tclass=file > > A lot of things are generating denials like these at the moment, not > just sysstat. There's a libselinux update in the pipeline that should > resolve it. > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Just upgrade to selinux-policy-3.6.12-57.fc11.noarch Which should fix these yum -y upgrade selinux-policy-targeted From dwalsh at redhat.com Mon Jul 6 12:19:49 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 06 Jul 2009 08:19:49 -0400 Subject: rpm post install can't install pp files In-Reply-To: References: Message-ID: <4A51EBE5.8080501@redhat.com> On 07/04/2009 03:09 AM, Shintaro Fujiwara wrote: > Hi, when I tried to install my.pp by post install script in my.rpm, I go > > semodule: my.pp Failed ! > > But I could succeed in tar-ball file, why ? > > Thanks in advance. > Please attach the log of the failure. Is this during a full install? From dwalsh at redhat.com Mon Jul 6 12:20:57 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 06 Jul 2009 08:20:57 -0400 Subject: QEMU in Fedora 10 In-Reply-To: References: Message-ID: <4A51EC29.9060304@redhat.com> On 07/04/2009 06:37 AM, John Smith wrote: > Hello, > I'm working on QEMU right now on Fedora 10. Interestingly I QEMU runs in qemu_unconfined_t. as I have not changed any of the labelling of my qemu files ( chroot directory, qemu filesystem image). I find it working with them with no denial messages. I have checked the policy for qemu on tresys refpolicy trunk, which somehow make the QEMU unconfined. Is this true? > Tresys and Fedora policy are not the same. There are major patches between them. > _________________________________________________________________ > With Windows Live, you can organise, edit, and share your photos. > http://clk.atdmt.com/UKM/go/134665338/direct/01/ > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Mon Jul 6 12:31:13 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 06 Jul 2009 08:31:13 -0400 Subject: Strange denials In-Reply-To: References: <991230.41638.qm@web36801.mail.mud.yahoo.com> Message-ID: <4A51EE91.8070200@redhat.com> On 07/04/2009 10:55 AM, K?vin GUERIN wrote: > winbindd is running with no MCS categories and tries to access a file with > c0.c0123. > > Access will be granted only if winbindd runs with all the categories that > has the file it wants to interact with. > > K?vin > > 2009/7/4 Vadym Chepkov > >> Ok, I am lost >> >> I clearly allowed this. >> >> allow winbind_t crond_t:fifo_file write; >> >> I can see it in the policy: >> sesearch --all --source winbind_t --target crond_t >> Found 3 semantic av rules: >> allow winbind_t crond_t : process sigchld ; >> allow winbind_t crond_t : fd use ; >> allow winbind_t crond_t : fifo_file { ioctl read write getattr lock >> append open } ; >> >> Why do I get denial anyway? >> >> time->Sat Jul 4 10:28:01 2009 >> type=SYSCALL msg=audit(1246717681.676:10436): arch=40000003 syscall=11 >> success=yes exit=0 a0=9073c10 a1=9073358 a2=90732a8 a3=9073358 items=0 >> ppid=20323 pid=20324 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 >> fsgid=0 tty=(none) ses=777 comm="winbindd" exe="/usr/sbin/winbindd" >> subj=system_u:system_r:winbind_t:s0 key=(null) >> type=AVC msg=audit(1246717681.676:10436): avc: denied { write } for >> pid=20324 comm="winbindd" path="pipe:[611496]" dev=pipefs ino=611496 >> scontext=system_u:system_r:winbind_t:s0 >> tcontext=unconfined_u:system_r:crond_t:s0-s0:c0.c1023 tclass=fifo_file >> >> >> Sincerely yours, >> Vadym Chepkov >> >> -- >> 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 I would just change your allow rules to dontaudit, since winbind does not need access to the fifo_file From dwalsh at redhat.com Mon Jul 6 12:33:18 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 06 Jul 2009 08:33:18 -0400 Subject: Strange denials In-Reply-To: <785397.13993.qm@web36808.mail.mud.yahoo.com> References: <785397.13993.qm@web36808.mail.mud.yahoo.com> Message-ID: <4A51EF0E.9040509@redhat.com> On 07/04/2009 11:19 AM, Vadym Chepkov wrote: > I barely redirect output of a cron job to /dev/null :( > > Is the a way to run cron unconfined? I don't see any boolean anymore. > > Sincerely yours, > Vadym Chepkov The problem is not the confinement of cron, but the confinement of winbind. winbind is handed an open file descritor from cron that it is not allowed to use. SELinux closes the descriptor and reports the avc. winbind and cron will continue to work without a problem. You can add a dontaudit rule to tell SELinux to stop reporting the leaked file descriptor. > > > --- On Sat, 7/4/09, K?vin GUERIN wrote: > >> From: K?vin GUERIN >> Subject: Re: Strange denials >> To: "Vadym Chepkov" >> Cc: "Fedora SELinux" >> Date: Saturday, July 4, 2009, 10:55 AM >> winbindd is running with no MCS >> categories and tries to access a file with c0.c0123. >> >> Access will be granted only if winbindd runs with all the >> categories that has the file it wants to interact with. >> >> K?vin >> >> >> 2009/7/4 Vadym Chepkov >> >> >> >> Ok, I am lost >> >> >> >> I clearly allowed this. >> >> >> >> allow winbind_t crond_t:fifo_file write; >> >> >> >> I can see it in the policy: >> >> sesearch --all --source winbind_t --target crond_t >> >> Found 3 semantic av rules: >> >> allow winbind_t crond_t : process sigchld ; >> >> allow winbind_t crond_t : fd use ; >> >> allow winbind_t crond_t : fifo_file { ioctl read write >> getattr lock append open } ; >> >> >> >> Why do I get denial anyway? >> >> >> >> time->Sat Jul 4 10:28:01 2009 >> >> type=SYSCALL msg=audit(1246717681.676:10436): arch=40000003 >> syscall=11 success=yes exit=0 a0=9073c10 a1=9073358 >> a2=90732a8 a3=9073358 items=0 ppid=20323 pid=20324 auid=0 >> uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 >> tty=(none) ses=777 comm="winbindd" >> exe="/usr/sbin/winbindd" >> subj=system_u:system_r:winbind_t:s0 key=(null) >> >> >> type=AVC msg=audit(1246717681.676:10436): avc: denied { >> write } for pid=20324 comm="winbindd" >> path="pipe:[611496]" dev=pipefs ino=611496 >> scontext=system_u:system_r:winbind_t:s0 >> tcontext=unconfined_u:system_r:crond_t:s0-s0:c0.c1023 >> tclass=fifo_file >> >> >> >> >> >> >> Sincerely yours, >> >> Vadym Chepkov >> >> >> >> -- >> >> 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 dwalsh at redhat.com Mon Jul 6 12:38:15 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 06 Jul 2009 08:38:15 -0400 Subject: Domain transition missing In-Reply-To: <138975.46083.qm@web36806.mail.mud.yahoo.com> References: <138975.46083.qm@web36806.mail.mud.yahoo.com> Message-ID: <4A51F037.1070300@redhat.com> On 07/04/2009 10:09 AM, Vadym Chepkov wrote: > It would be nice if the interface would be smart enough and allow output from the cron job to be sent, but no one is perfect :) > > ---- > type=AVC msg=audit(1246715821.417:10142): avc: denied { write } for pid=11916 comm="winbind" path="pipe:[591689]" dev=pipefs ino=591689 scontext=system_u:system_r:system_cronjob_t:s0 tcontext=unconfined_u:system_r:crond_t:s0-s0:c0.c1023 tclass=fifo_file > ---- > type=AVC msg=audit(1246715821.780:10143): avc: denied { write } for pid=11925 comm="winbindd" path="pipe:[591689]" dev=pipefs ino=591689 scontext=system_u:system_r:winbind_t:s0 tcontext=unconfined_u:system_r:crond_t:s0-s0:c0.c1023 tclass=fifo_file > > Sincerely yours, > Vadym Chepkov > > > --- On Sat, 7/4/09, Vadym Chepkov wrote: > >> From: Vadym Chepkov >> Subject: Re: Domain transition missing >> To: "Dominick Grift" >> Cc: "Fedora SELinux" >> Date: Saturday, July 4, 2009, 10:00 AM >> This worked well too, thank you >> >> system_u:system_r:winbind_t:SystemLow root >> 11926 1 0 09:57 ? >> 00:00:00 winbindd >> system_u:system_r:winbind_t:SystemLow root 11928 >> 11926 0 09:57 ? 00:00:00 winbindd >> system_u:system_r:winbind_t:SystemLow root 11954 >> 11926 0 09:57 ? 00:00:00 winbindd >> system_u:system_r:winbind_t:SystemLow root 11956 >> 11926 0 09:57 ? 00:00:00 winbindd >> system_u:system_r:winbind_t:SystemLow root 11957 >> 11926 0 09:57 ? 00:00:00 winbindd >> >> >> Sincerely yours, >> Vadym Chepkov >> >> >> --- On Sat, 7/4/09, Dominick Grift >> wrote: >> >>> From: Dominick Grift >>> Subject: Re: Domain transition missing >>> To: "Vadym Chepkov" >>> Cc: "Fedora SELinux" >>> Date: Saturday, July 4, 2009, 9:28 AM >>> On Sat, 2009-07-04 at 06:18 -0700, >>> Vadym Chepkov wrote: >>>> That would be unfortunate. Mine approach is not >>> uncommon. If you look closely you will see the same >>> technique in wast scripts. spamassassin restarts >> itself when >>> it updates anti-spam rules, clamav does that >> (antivirus) and >>> on and on. I use Fedora 11, by the way. >>>> For now, instead of creating a new policy I just >> added >>> 'runcon -t unconfind_t ' in the cron, and it seemed to >> did >>> the trick. >>>> Sincerely yours, >>>> Vadym Chepkov >>>> >>> Looking here: >>> http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/services/cron.if >>> line 235 to line 269. >>> >>> That seems like a interface one might use in your >>> situation: >>> >>> cron_system_entry(winbind_t, winbind_exec_t) >>> >>> I admit that using cron with SELinux is not very easy >>> currently >>> >>>> --- On Sat, 7/4/09, Dominick Grift >>> wrote: >>>>> From: Dominick Grift >>>>> Subject: Re: Domain transition missing >>>>> To: "Vadym Chepkov" >>>>> Cc: "Fedora SELinux" >>>>> Date: Saturday, July 4, 2009, 8:57 AM >>>>> On Sat, 2009-07-04 at 05:48 -0700, >>>>> Vadym Chepkov wrote: >>>>>> I really get used to running my >> scripts >>> unconfined, >>>>> how I can accomplish it in this scenario? >>>>>> Sincerely yours, >>>>>> Vadym Chepkov >>>>>> >>>>> if you want the system to run jobs you will >> need >>> to write >>>>> some policy or >>>>> extend the system_cronjob_t domain i think >>>>> >>>>> >>>>> Were those the only avc denial you got? I >> would >>> expect more >>>>> denials. >>>>> >>>>>> --- On Sat, 7/4/09, Dominick Grift >> >>>>> wrote: >>>>>>> From: Dominick Grift >>>>>>> Subject: Re: Domain transition >> missing >>>>>>> To: "Vadym Chepkov" >>>>>>> Cc: "Fedora SELinux" >>>>>>> Date: Saturday, July 4, 2009, 8:41 >> AM >>>>>>> On Sat, 2009-07-04 at 14:38 >> +0200, >>>>>>> Dominick Grift wrote: >>>>>>>> On Sat, 2009-07-04 at 05:11 >> -0700, >>> Vadym >>>>> Chepkov >>>>>>> wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Last night I got a >> nasty >>> surprise from >>>>> selinux. I >>>>>>> am using winbind for external >>> authentication and >>>>> since it >>>>>>> has history of failures I have a >> simple >>> watchdog >>>>> implemented >>>>>>> to check the status and restart it >> if >>> necessary. >>>>> That >>>>>>> is what happened last night and >>> as a law >>>>> abiding >>>>>>> selinux citizen I used 'service >> winbind >>> restart', >>>>> but it >>>>>>> seems the proper domain >> transitions is >>> missing >>>>> and winbind >>>>>>> was started in system_cronjob_t >> domain >>> instead of >>>>> winbind_t >>>>>>> and none of other domains could >> connect >>> to it. >>>>>>>>> I think jobs running >> from >>> cron should >>>>> be granted >>>>>>> the same transition rules as >>> from >>>>> unconfined_t. >>>>>>>>> I will file bugzilla >> report >>> about it, >>>>> but could >>>>>>> somebody help me with modifying >> my >>> local policy >>>>> until/if it >>>>>>> gets implemented, please? Thank >> you. >>>>>>>>> Sincerely yours, >>>>>>>>> Vadym >>> Chepkov >>>>>>>> A domain transition would >> be: >>>>>>>> policy_module(mywinbind, >> 0.0.1) >>>>>>>> require { type >> system_cronjob_t, >>>>> winbind_exec_t, >>>>>>> winbind_t; } >>> domain_auto_trans(system_cronjob_t, >>>>> winbind_exec_t, >>>>>>> winbind_t) >>>>>>>> Can you show us the full raw >> avc >>> denial? >>>>>>> >>>>>>> But personally would deal with >> this in >>> a >>>>> different way. I >>>>>>> would write >>>>>>> policy for the script that >> restarts >>> winbind and >>>>> then i >>>>>>> would create a >>>>>>> domain transition for the domain >> in >>> which the >>>>> script runs >>>>>>> to winbind_t. >>>>>>> >>>>>>> Mainly because i wouldnt want to >>> extend/modify >>>>>>> system_cronjob_t >>>>>>> >>>>>>> So: system_cronjob_t -> >>> myscript_exec_t -> >>>>> myscript_t >>>>>>> -> winbind_exec_t >>>>>>> -> winbind_t >>>>>>> >>>>>>>>> -- >>>>>>>>> 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 Miroslav, I think you should add dontaudit $1 crond_t:fifo_file rw_fifo_file_perms; To cron_system_entry to eliminate this leaked file descriptor problem. From dwalsh at redhat.com Mon Jul 6 12:53:32 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 06 Jul 2009 08:53:32 -0400 Subject: Domain transition missing In-Reply-To: <156305.76378.qm@web36804.mail.mud.yahoo.com> References: <156305.76378.qm@web36804.mail.mud.yahoo.com> Message-ID: <4A51F3CC.4030105@redhat.com> On 07/04/2009 08:48 AM, Vadym Chepkov wrote: > I really get used to running my scripts unconfined, how I can accomplish it in this scenario? > > Sincerely yours, > Vadym Chepkov > > > --- On Sat, 7/4/09, Dominick Grift wrote: > >> From: Dominick Grift >> Subject: Re: Domain transition missing >> To: "Vadym Chepkov" >> Cc: "Fedora SELinux" >> Date: Saturday, July 4, 2009, 8:41 AM >> On Sat, 2009-07-04 at 14:38 +0200, >> Dominick Grift wrote: >>> On Sat, 2009-07-04 at 05:11 -0700, Vadym Chepkov >> wrote: >>>> Hi, >>>> >>>> Last night I got a nasty surprise from selinux. I >> am using winbind for external authentication and since it >> has history of failures I have a simple watchdog implemented >> to check the status and restart it if necessary. That >> is what happened last night and as a law abiding >> selinux citizen I used 'service winbind restart', but it >> seems the proper domain transitions is missing and winbind >> was started in system_cronjob_t domain instead of winbind_t >> and none of other domains could connect to it. >>>> I think jobs running from cron should be granted >> the same transition rules as from unconfined_t. >>>> I will file bugzilla report about it, but could >> somebody help me with modifying my local policy until/if it >> gets implemented, please? Thank you. >>>> Sincerely yours, >>>> Vadym Chepkov >>> A domain transition would be: >>> >>> policy_module(mywinbind, 0.0.1) >>> >>> require { type system_cronjob_t, winbind_exec_t, >> winbind_t; } >>> domain_auto_trans(system_cronjob_t, winbind_exec_t, >> winbind_t) >>> Can you show us the full raw avc denial? >> >> But personally would deal with this in a different way. I >> would write >> policy for the script that restarts winbind and then i >> would create a >> domain transition for the domain in which the script runs >> to winbind_t. >> >> Mainly because i wouldnt want to extend/modify >> system_cronjob_t >> >> So: system_cronjob_t -> myscript_exec_t -> myscript_t >> -> winbind_exec_t >> -> winbind_t >> >>>> -- >>>> 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 It looks like standard SELinux policy should have allowed system_cronjob_t to transition to initrc_t when executing an initrc script. How is the windbind script labeled? ls -lZ /etc/init.d/winbind -rwxr-xr-x. root root system_u:object_r:samba_initrc_exec_t:s0 /etc/init.d/winbind From dwalsh at redhat.com Mon Jul 6 12:58:59 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 06 Jul 2009 08:58:59 -0400 Subject: Confining stunnel started from init script In-Reply-To: <4A4DA35C.6000504@yahoo.com> References: <4A4DA35C.6000504@yahoo.com> Message-ID: <4A51F513.9070708@redhat.com> On 07/03/2009 02:21 AM, Allen Kistler wrote: > Since F7, I've started stunnel as a daemon from an init script. In F11, > I'm confining it using SELinux, instead of just letting it run as > initrc_t. However, I've got two questions. > > First: > I think at some point, it might be worth submitting what I've done as an > enhancement, minor though it may be, to stunnel. In my case, I use > stunnel to establish an SSL tunnel to my ISP's smtps port from sendmail. > Since I bind stunnel locally to tcp/465, I can't define stunnel_port_t > (the pre-existing label for whatever port the end user chooses to use) > as tcp/465 because tcp/465 is already labeled as smtp_port_t. What I've > done is: > > bool stunnel_can_sendmail false; > > if (stunnel_can_sendmail) { > allow stunnel_t smtp_port_t : tcp_socket name_bind; > }; > > Does this seem the most reasonable way to do things with ports already > labeled? For a more general policy, that would mean a Boolean for every > port label. Hmm.... > > Second: > What's the syntax in the TE file to get descriptive text attached to a > Boolean declaration? Right now I get: > > # semanage boolean -l | grep stunnel_can_sendmail > stunnel_can_sendmail -> on stunnel_can_sendmail > > But I'd prefer something more informative and cosmetically pleasing like: > > # semanage boolean -l | grep xen_use_nfs > xen_use_nfs -> off Allow xen to manage nfs files > > Thanks for any info and assistance. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list If stunnel has to connect to random ports I would prefer you just allow it to connect to all ports, So stunnnel_connect_all_ports as a boolean. That way we don't end up adding a boolean for every named port that someone could ever allow. Not as Minimum privs as many would like, but better for the masses. From paul at city-fan.org Mon Jul 6 13:04:29 2009 From: paul at city-fan.org (Paul Howarth) Date: Mon, 06 Jul 2009 14:04:29 +0100 Subject: Confining stunnel started from init script In-Reply-To: <4A51F513.9070708@redhat.com> References: <4A4DA35C.6000504@yahoo.com> <4A51F513.9070708@redhat.com> Message-ID: <4A51F65D.5040309@city-fan.org> On 06/07/09 13:58, Daniel J Walsh wrote: > On 07/03/2009 02:21 AM, Allen Kistler wrote: >> Since F7, I've started stunnel as a daemon from an init script. In F11, >> I'm confining it using SELinux, instead of just letting it run as >> initrc_t. However, I've got two questions. >> >> First: >> I think at some point, it might be worth submitting what I've done as an >> enhancement, minor though it may be, to stunnel. In my case, I use >> stunnel to establish an SSL tunnel to my ISP's smtps port from sendmail. >> Since I bind stunnel locally to tcp/465, I can't define stunnel_port_t >> (the pre-existing label for whatever port the end user chooses to use) >> as tcp/465 because tcp/465 is already labeled as smtp_port_t. What I've >> done is: >> >> bool stunnel_can_sendmail false; >> >> if (stunnel_can_sendmail) { >> allow stunnel_t smtp_port_t : tcp_socket name_bind; >> }; >> >> Does this seem the most reasonable way to do things with ports already >> labeled? For a more general policy, that would mean a Boolean for every >> port label. Hmm.... >> >> Second: >> What's the syntax in the TE file to get descriptive text attached to a >> Boolean declaration? Right now I get: >> >> # semanage boolean -l | grep stunnel_can_sendmail >> stunnel_can_sendmail -> on stunnel_can_sendmail >> >> But I'd prefer something more informative and cosmetically pleasing like: >> >> # semanage boolean -l | grep xen_use_nfs >> xen_use_nfs -> off Allow xen to manage nfs files >> >> Thanks for any info and assistance. >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > If stunnel has to connect to random ports I would prefer you just allow > it to connect to all ports, So > > stunnnel_connect_all_ports as a boolean. That way we don't end up adding > a boolean for every named port that someone could ever allow. > > Not as Minimum privs as many would like, but better for the masses. It doesn't just have to *connect* to random ports, it has to *bind* to them. It's a general-purpose wrapper for converting plain text protocols to their SSL-protected versions, which are often found on different ports. So for instance you might have stunnel listening on port 465 for SMTPS and forwarding traffic after decryption to local port 25 (i.e. bind on 465, connect to 25). Paul. From gene at czarc.net Mon Jul 6 13:11:17 2009 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 6 Jul 2009 09:11:17 -0400 Subject: sVirt In-Reply-To: <20090705165504.0ec053ce@metropolis.intra.city-fan.org> References: <200907041213.47694.gene@czarc.net> <20090705103605.GA8963@redhat.com> <20090705165504.0ec053ce@metropolis.intra.city-fan.org> Message-ID: <200907060911.17364.gene@czarc.net> On Sunday 05 July 2009 11:55:04 Paul Howarth wrote: > On Sun, 5 Jul 2009 11:36:05 +0100 > > "Daniel P. Berrange" wrote: > > > 4. For ISO files, maybe there should be a new/special file context > > > which allows sharing between processes ... it would be explicit but > > > it would allow sharing ... maybe something like "public_content_t". > > > > There is already a label for read only guest images > > > > system_u:object_r:svirt_image_t:s0 > > > > it shouldn't be much work for you to add a custom SELinux plugin that > > gives httpd_t access to content labelled svirt_image_t. Ask the > > fedora-selinux mailing list for assistance if needed > > Couldn't an ISO image that's already public_content_t (or even > public_content_rw_t) be left alone, as that type is already well-known > and used for sharing this type of content by various means? Yes, exactly my point. I believe that changing any file context should not be done. Depend on the rules in the security policy or any added with semanage apply. And then let something like public_content_t and public_content_rw_t be OK too. Mmmm, this makes so much sense that I think I will bugzilla this. Gene From sds at tycho.nsa.gov Mon Jul 6 13:29:25 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 06 Jul 2009 09:29:25 -0400 Subject: sVirt In-Reply-To: <200907060911.17364.gene@czarc.net> References: <200907041213.47694.gene@czarc.net> <20090705103605.GA8963@redhat.com> <20090705165504.0ec053ce@metropolis.intra.city-fan.org> <200907060911.17364.gene@czarc.net> Message-ID: <1246886965.28321.7.camel@moss-pluto.epoch.ncsc.mil> On Mon, 2009-07-06 at 09:11 -0400, Gene Czarcinski wrote: > On Sunday 05 July 2009 11:55:04 Paul Howarth wrote: > > On Sun, 5 Jul 2009 11:36:05 +0100 > > > > "Daniel P. Berrange" wrote: > > > > 4. For ISO files, maybe there should be a new/special file context > > > > which allows sharing between processes ... it would be explicit but > > > > it would allow sharing ... maybe something like "public_content_t". > > > > > > There is already a label for read only guest images > > > > > > system_u:object_r:svirt_image_t:s0 > > > > > > it shouldn't be much work for you to add a custom SELinux plugin that > > > gives httpd_t access to content labelled svirt_image_t. Ask the > > > fedora-selinux mailing list for assistance if needed > > > > Couldn't an ISO image that's already public_content_t (or even > > public_content_rw_t) be left alone, as that type is already well-known > > and used for sharing this type of content by various means? > > Yes, exactly my point. > > I believe that changing any file context should not be done. Depend on the > rules in the security policy or any added with semanage apply. And then let > something like public_content_t and public_content_rw_t be OK too. > > Mmmm, this makes so much sense that I think I will bugzilla this. The reason that it presently relabels the disk image is that it is auto-generating a unique security context (unique category pair) for each VM, and then assigning that category pair to both the qemu-kvm process and to the disk image to isolate instances from one another. There is also a static configuration option where you can specify the desired context for the VM, in which case it shouldn't relabel the disk image. -- Stephen Smalley National Security Agency From gene at czarc.net Mon Jul 6 13:49:02 2009 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 6 Jul 2009 09:49:02 -0400 Subject: sVirt In-Reply-To: <200907060911.17364.gene@czarc.net> References: <200907041213.47694.gene@czarc.net> <20090705165504.0ec053ce@metropolis.intra.city-fan.org> <200907060911.17364.gene@czarc.net> Message-ID: <200907060949.02959.gene@czarc.net> On Monday 06 July 2009 09:11:17 Gene Czarcinski wrote: > On Sunday 05 July 2009 11:55:04 Paul Howarth wrote: > > On Sun, 5 Jul 2009 11:36:05 +0100 > > > > "Daniel P. Berrange" wrote: > > > > 4. For ISO files, maybe there should be a new/special file context > > > > which allows sharing between processes ... it would be explicit but > > > > it would allow sharing ... maybe something like "public_content_t". > > > > > > There is already a label for read only guest images > > > > > > system_u:object_r:svirt_image_t:s0 > > > > > > it shouldn't be much work for you to add a custom SELinux plugin that > > > gives httpd_t access to content labelled svirt_image_t. Ask the > > > fedora-selinux mailing list for assistance if needed > > > > Couldn't an ISO image that's already public_content_t (or even > > public_content_rw_t) be left alone, as that type is already well-known > > and used for sharing this type of content by various means? > > Yes, exactly my point. > > I believe that changing any file context should not be done. Depend on the > rules in the security policy or any added with semanage apply. And then > let something like public_content_t and public_content_rw_t be OK too. > > Mmmm, this makes so much sense that I think I will bugzilla this. https://bugzilla.redhat.com/show_bug.cgi?id=509834 From gene at czarc.net Mon Jul 6 14:13:12 2009 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 6 Jul 2009 10:13:12 -0400 Subject: sVirt In-Reply-To: <20090705103605.GA8963@redhat.com> References: <200907041213.47694.gene@czarc.net> <20090705103605.GA8963@redhat.com> Message-ID: <200907061013.12970.gene@czarc.net> On Sunday 05 July 2009 06:36:05 Daniel P. Berrange wrote: > > 2. For files on read-only file systems, don't do anything ... they are > > protected about as much as they can be. > > As has been mentioned in the bug you raised several days ago, this issue > should already be addressed > > https://bugzilla.redhat.com/show_bug.cgi?id=507555 I am still looking for the update libvirt to be post to updates-testing. > > > 4. For ISO files, maybe there should be a new/special file context which > > allows sharing between processes ... it would be explicit but it would > > allow sharing ... maybe something like "public_content_t". > > There is already a label for read only guest images > > system_u:object_r:svirt_image_t:s0 > > it shouldn't be much work for you to add a custom SELinux plugin that > gives httpd_t access to content labelled svirt_image_t. Ask the > fedora-selinux mailing list for assistance if needed I believe this is backwards from the way things should work. Please see my new bugzilla report: https://bugzilla.redhat.com/show_bug.cgi?id=509834 sVirt is the new kid on the block and should work with others not the reverse. Why should I need to create an SELinux plugin so that stuff that did work still does work? > > > 5. Maybe implement a switch which disables SELinux enforcing (and does > > not change the file context of ISO files) for Fedora-virtualization. > > Already present /etc/libvirt/qemu.conf , change security_driver="none" OK, I can certainly edit the config file myself (now that I am aware of it). However, shouldn't I be able to set this with either an SELinux boolean or via virt-manager's preferences? BTW, there are currently a number of SELinux booleans for "virt" but I am not sure what each does/means. > > > 6. Maybe the switch should be by guest. > > Easy enough to add - file a bug if you want this capability. Yes, something like this is desirable (IMHO). However, what I really want is to be able to define and build a guest without screwing up "other" shared files and/or devices but then be able to lock that guest down once it is built. The system settings for a guest in creation/build mode should not effect the settings of other guest virtuals already built This is analogous to development versus production environments. Gene From dwalsh at redhat.com Mon Jul 6 14:50:48 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 06 Jul 2009 10:50:48 -0400 Subject: Confining stunnel started from init script In-Reply-To: <4A51F65D.5040309@city-fan.org> References: <4A4DA35C.6000504@yahoo.com> <4A51F513.9070708@redhat.com> <4A51F65D.5040309@city-fan.org> Message-ID: <4A520F48.6000808@redhat.com> On 07/06/2009 09:04 AM, Paul Howarth wrote: > On 06/07/09 13:58, Daniel J Walsh wrote: >> On 07/03/2009 02:21 AM, Allen Kistler wrote: >>> Since F7, I've started stunnel as a daemon from an init script. In F11, >>> I'm confining it using SELinux, instead of just letting it run as >>> initrc_t. However, I've got two questions. >>> >>> First: >>> I think at some point, it might be worth submitting what I've done as an >>> enhancement, minor though it may be, to stunnel. In my case, I use >>> stunnel to establish an SSL tunnel to my ISP's smtps port from sendmail. >>> Since I bind stunnel locally to tcp/465, I can't define stunnel_port_t >>> (the pre-existing label for whatever port the end user chooses to use) >>> as tcp/465 because tcp/465 is already labeled as smtp_port_t. What I've >>> done is: >>> >>> bool stunnel_can_sendmail false; >>> >>> if (stunnel_can_sendmail) { >>> allow stunnel_t smtp_port_t : tcp_socket name_bind; >>> }; >>> >>> Does this seem the most reasonable way to do things with ports already >>> labeled? For a more general policy, that would mean a Boolean for every >>> port label. Hmm.... >>> >>> Second: >>> What's the syntax in the TE file to get descriptive text attached to a >>> Boolean declaration? Right now I get: >>> >>> # semanage boolean -l | grep stunnel_can_sendmail >>> stunnel_can_sendmail -> on stunnel_can_sendmail >>> >>> But I'd prefer something more informative and cosmetically pleasing >>> like: >>> >>> # semanage boolean -l | grep xen_use_nfs >>> xen_use_nfs -> off Allow xen to manage nfs files >>> >>> Thanks for any info and assistance. >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> If stunnel has to connect to random ports I would prefer you just allow >> it to connect to all ports, So >> >> stunnnel_connect_all_ports as a boolean. That way we don't end up adding >> a boolean for every named port that someone could ever allow. >> >> Not as Minimum privs as many would like, but better for the masses. > > It doesn't just have to *connect* to random ports, it has to *bind* to > them. It's a general-purpose wrapper for converting plain text protocols > to their SSL-protected versions, which are often found on different > ports. So for instance you might have stunnel listening on port 465 for > SMTPS and forwarding traffic after decryption to local port 25 (i.e. > bind on 465, connect to 25). > > Paul. Ok I misspoke and maybe the boolean should be something like stunnel_relay_all_ports But you need to allow it to bind and connect to all ports on the system. From gene at czarc.net Mon Jul 6 15:12:41 2009 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 6 Jul 2009 11:12:41 -0400 Subject: sVirt In-Reply-To: <1246886965.28321.7.camel@moss-pluto.epoch.ncsc.mil> References: <200907041213.47694.gene@czarc.net> <200907060911.17364.gene@czarc.net> <1246886965.28321.7.camel@moss-pluto.epoch.ncsc.mil> Message-ID: <200907061112.42099.gene@czarc.net> On Monday 06 July 2009 09:29:25 Stephen Smalley wrote: > > I believe that changing any file context should not be done. Depend on > > the rules in the security policy or any added with semanage apply. And > > then let something like public_content_t and public_content_rw_t be OK > > too. > > > > Mmmm, this makes so much sense that I think I will bugzilla this. > > The reason that it presently relabels the disk image is that it is > auto-generating a unique security context (unique category pair) for > each VM, and then assigning that category pair to both the qemu-kvm > process and to the disk image to isolate instances from one another. OK does this "unique security context" protect guests from each other? I do not understand what is being protected and who are we protecting from. [with respect to ISO image files and other shared files] I am not talking about a guest's virtual disk in /var/lib/libvirt/images (or whatever). Regardless, I do NOT believe that sVirt should be changing file contexts. The system (security?) administrator should be controlling what contexts a file has ... it should not be happening under the sVirt covers. This is especially true when it effects other processes (my httpd example). ISO image files should be sharable between guests as well as other processes on the system with a common file context. Setting the file context also causes other problems when the ISO image exists in a read-only file system. > There is also a static configuration option where you can specify the > desired context for the VM, in which case it shouldn't relabel the disk > image. Is there additional information somewhere about using this "static configuration option"? I am not trying to be nit-picky about this stuff. I have and do support SELinux as a significant security improvement an applaud the efforts of NSA, Red Hat, Fedora, and others in making it a reality. I run SELinux enforcing mode and prefer that everything protected should always be the case. However, there is a difference between shared resources (files) and owned resources (files). I am also a new fan of Fedora Virtualization and want to see it succeed. That you can run Fedora, Red Hat, Solaris, *BSDs, etc. as guests is a fantastic capability. Locking down guests with SELinux is a significant capability. I believe I have some understanding of why organizations such as NSA and related organizations want to have locked down (restricted access) guests. However, the only true secure computer systems is an isolated one with the power off (assuming adequate physical security). We need security implemented while we "keep our sanity". The question: what is "good enough" security as oppose to "perfect" security? When SELinux was first introduced in Fedora, the security policy was strict. Well, that turned out to be a bummer and many folks disabled SELinux. So, a targeted policy was developed and has evolved to cover more and more of the system. With Fedora 11 sVirt has been introduced as the latest evolution. But, as currently implemented, sVirt breaks protections for other (previously protected) processes. I am just saying that it needs some fine tuning or perhaps re-thinking. Gene From sds at tycho.nsa.gov Mon Jul 6 16:31:53 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 06 Jul 2009 12:31:53 -0400 Subject: sVirt In-Reply-To: <200907061112.42099.gene@czarc.net> References: <200907041213.47694.gene@czarc.net> <200907060911.17364.gene@czarc.net> <1246886965.28321.7.camel@moss-pluto.epoch.ncsc.mil> <200907061112.42099.gene@czarc.net> Message-ID: <1246897913.28321.57.camel@moss-pluto.epoch.ncsc.mil> On Mon, 2009-07-06 at 11:12 -0400, Gene Czarcinski wrote: > On Monday 06 July 2009 09:29:25 Stephen Smalley wrote: > > > I believe that changing any file context should not be done. Depend on > > > the rules in the security policy or any added with semanage apply. And > > > then let something like public_content_t and public_content_rw_t be OK > > > too. > > > > > > Mmmm, this makes so much sense that I think I will bugzilla this. > > > > The reason that it presently relabels the disk image is that it is > > auto-generating a unique security context (unique category pair) for > > each VM, and then assigning that category pair to both the qemu-kvm > > process and to the disk image to isolate instances from one another. > > OK does this "unique security context" protect guests from each other? It provides some degree of isolation between them, yes. By default, the TE policy is being used to protect the host from the guests (by restricting what types are accessible to svirt_t), and the MCS policy is being used to isolate the guests from one another (by using unique category sets for each guest). > I do not understand what is being protected and who are we protecting from. > [with respect to ISO image files and other shared files] > > I am not talking about a guest's virtual disk in /var/lib/libvirt/images (or > whatever). > > Regardless, I do NOT believe that sVirt should be changing file contexts. The > system (security?) administrator should be controlling what contexts a file has > ... it should not be happening under the sVirt covers. This is especially > true when it effects other processes (my httpd example). > > ISO image files should be sharable between guests as well as other processes on > the system with a common file context. > > Setting the file context also causes other problems when the ISO image exists > in a read-only file system. There are definitely situations where relabeling should not happen. But the sVirt designers wanted some default protection out of the box, without requiring manual configuration by an admin. Thus automatic generation of MCS category pairs for each guest, with those categories applied to the process and to the virtual disk image. > > There is also a static configuration option where you can specify the > > desired context for the VM, in which case it shouldn't relabel the disk > > image. > Is there additional information somewhere about using this "static > configuration option"? First, you need to use virsh edit to add/replace the seclabel entry with something like this: Note the type='static' part, which prevents libvirt from clobbering it later with a dynamically generated context. Then you need to manually label the image file - it won't do that for you once you've defined a static label, e.g.: chcon system_u:object_r:svirt_image_t:s0:c1 /var/lib/libvirt/images/vm1.img -- Stephen Smalley National Security Agency From dwalsh at redhat.com Mon Jul 6 17:04:08 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 06 Jul 2009 13:04:08 -0400 Subject: sVirt In-Reply-To: <1246897913.28321.57.camel@moss-pluto.epoch.ncsc.mil> References: <200907041213.47694.gene@czarc.net> <200907060911.17364.gene@czarc.net> <1246886965.28321.7.camel@moss-pluto.epoch.ncsc.mil> <200907061112.42099.gene@czarc.net> <1246897913.28321.57.camel@moss-pluto.epoch.ncsc.mil> Message-ID: <4A522E88.4060408@redhat.com> On 07/06/2009 12:31 PM, Stephen Smalley wrote: > On Mon, 2009-07-06 at 11:12 -0400, Gene Czarcinski wrote: >> On Monday 06 July 2009 09:29:25 Stephen Smalley wrote: >>>> I believe that changing any file context should not be done. Depend on >>>> the rules in the security policy or any added with semanage apply. And >>>> then let something like public_content_t and public_content_rw_t be OK >>>> too. >>>> >>>> Mmmm, this makes so much sense that I think I will bugzilla this. >>> The reason that it presently relabels the disk image is that it is >>> auto-generating a unique security context (unique category pair) for >>> each VM, and then assigning that category pair to both the qemu-kvm >>> process and to the disk image to isolate instances from one another. >> OK does this "unique security context" protect guests from each other? > > It provides some degree of isolation between them, yes. By default, the > TE policy is being used to protect the host from the guests (by > restricting what types are accessible to svirt_t), and the MCS policy is > being used to isolate the guests from one another (by using unique > category sets for each guest). > >> I do not understand what is being protected and who are we protecting from. >> [with respect to ISO image files and other shared files] >> >> I am not talking about a guest's virtual disk in /var/lib/libvirt/images (or >> whatever). >> >> Regardless, I do NOT believe that sVirt should be changing file contexts. The >> system (security?) administrator should be controlling what contexts a file has >> ... it should not be happening under the sVirt covers. This is especially >> true when it effects other processes (my httpd example). >> >> ISO image files should be sharable between guests as well as other processes on >> the system with a common file context. >> >> Setting the file context also causes other problems when the ISO image exists >> in a read-only file system. > > There are definitely situations where relabeling should not happen. But > the sVirt designers wanted some default protection out of the box, > without requiring manual configuration by an admin. Thus automatic > generation of MCS category pairs for each guest, with those categories > applied to the process and to the virtual disk image. > >>> There is also a static configuration option where you can specify the >>> desired context for the VM, in which case it shouldn't relabel the disk >>> image. >> Is there additional information somewhere about using this "static >> configuration option"? > > First, you need to use virsh edit to add/replace the seclabel entry > with something like this: > > > > > Note the type='static' part, which prevents libvirt from clobbering it > later with a dynamically generated context. > > Then you need to manually label the image file - it won't do that for > you once you've defined a static label, e.g.: > chcon > system_u:object_r:svirt_image_t:s0:c1 /var/lib/libvirt/images/vm1.img > I also have made a patch to virt-manager to do this from the GUI, although it has not been merged yet into Rawhide. From domg472 at gmail.com Mon Jul 6 17:27:21 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 06 Jul 2009 19:27:21 +0200 Subject: sVirt In-Reply-To: <1246897913.28321.57.camel@moss-pluto.epoch.ncsc.mil> References: <200907041213.47694.gene@czarc.net> <200907060911.17364.gene@czarc.net> <1246886965.28321.7.camel@moss-pluto.epoch.ncsc.mil> <200907061112.42099.gene@czarc.net> <1246897913.28321.57.camel@moss-pluto.epoch.ncsc.mil> Message-ID: <1246901241.9209.2.camel@notebook2.grift.internal> On Mon, 2009-07-06 at 12:31 -0400, Stephen Smalley wrote: > On Mon, 2009-07-06 at 11:12 -0400, Gene Czarcinski wrote: > > On Monday 06 July 2009 09:29:25 Stephen Smalley wrote: > > > > I believe that changing any file context should not be done. Depend on > > > > the rules in the security policy or any added with semanage apply. And > > > > then let something like public_content_t and public_content_rw_t be OK > > > > too. > > > > > > > > Mmmm, this makes so much sense that I think I will bugzilla this. > > > > > > The reason that it presently relabels the disk image is that it is > > > auto-generating a unique security context (unique category pair) for > > > each VM, and then assigning that category pair to both the qemu-kvm > > > process and to the disk image to isolate instances from one another. > > > > OK does this "unique security context" protect guests from each other? > > It provides some degree of isolation between them, yes. By default, the > TE policy is being used to protect the host from the guests (by > restricting what types are accessible to svirt_t), and the MCS policy is > being used to isolate the guests from one another (by using unique > category sets for each guest). > > > I do not understand what is being protected and who are we protecting from. > > [with respect to ISO image files and other shared files] > > > > I am not talking about a guest's virtual disk in /var/lib/libvirt/images (or > > whatever). > > > > Regardless, I do NOT believe that sVirt should be changing file contexts. The > > system (security?) administrator should be controlling what contexts a file has > > ... it should not be happening under the sVirt covers. This is especially > > true when it effects other processes (my httpd example). > > > > ISO image files should be sharable between guests as well as other processes on > > the system with a common file context. > > > > Setting the file context also causes other problems when the ISO image exists > > in a read-only file system. > > There are definitely situations where relabeling should not happen. But > the sVirt designers wanted some default protection out of the box, > without requiring manual configuration by an admin. Thus automatic > generation of MCS category pairs for each guest, with those categories > applied to the process and to the virtual disk image. > > > > There is also a static configuration option where you can specify the > > > desired context for the VM, in which case it shouldn't relabel the disk > > > image. > > Is there additional information somewhere about using this "static > > configuration option"? > > First, you need to use virsh edit to add/replace the seclabel entry > with something like this: > > > Thanks for the tip. Static works better for me. system_u:system_r:svirt_t:mybookvolume2 root 2933 13.1 3.2 2420860 266352 ? Sl 19:21 0:25 /usr/bin/qemu-kvm -S -M pc -m 2047 -smp 2 -name mybookvolume2 -uuid bede1797-dea4-af3d-29c7-cf216f822f1a -monitor pty -pidfile /var/run/libvirt/qemu//mybookvolume2.pid -boot c -drive file=,if=ide,media=cdrom,index=2 -drive file=/dev/mapper/vg_mybook-lv_volume2,if=virtio,index=0,boot=on -net nic,macaddr=54:52:00:70:cc:5e,vlan=0,model=virtio -net tap,fd=17,vlan=0 -serial pty -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0 -k en-us > Note the type='static' part, which prevents libvirt from clobbering it > later with a dynamically generated context. > > Then you need to manually label the image file - it won't do that for > you once you've defined a static label, e.g.: > chcon > system_u:object_r:svirt_image_t:s0:c1 /var/lib/libvirt/images/vm1.img > -------------- 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 gene at czarc.net Mon Jul 6 18:26:29 2009 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 6 Jul 2009 14:26:29 -0400 Subject: sVirt In-Reply-To: <1246897913.28321.57.camel@moss-pluto.epoch.ncsc.mil> References: <200907041213.47694.gene@czarc.net> <200907061112.42099.gene@czarc.net> <1246897913.28321.57.camel@moss-pluto.epoch.ncsc.mil> Message-ID: <200907061426.29751.gene@czarc.net> On Monday 06 July 2009 12:31:53 Stephen Smalley wrote: > On Mon, 2009-07-06 at 11:12 -0400, Gene Czarcinski wrote: > > On Monday 06 July 2009 09:29:25 Stephen Smalley wrote: > > > > I believe that changing any file context should not be done. Depend > > > > on the rules in the security policy or any added with semanage apply. > > > > And then let something like public_content_t and public_content_rw_t > > > > be OK too. > > > > > > > > Mmmm, this makes so much sense that I think I will bugzilla this. > > > > > > The reason that it presently relabels the disk image is that it is > > > auto-generating a unique security context (unique category pair) for > > > each VM, and then assigning that category pair to both the qemu-kvm > > > process and to the disk image to isolate instances from one another. > > > > OK does this "unique security context" protect guests from each other? > > It provides some degree of isolation between them, yes. By default, the > TE policy is being used to protect the host from the guests (by > restricting what types are accessible to svirt_t), and the MCS policy is > being used to isolate the guests from one another (by using unique > category sets for each guest). Neat! OK, this is starting to make more sense to me. I like the idea of using the MCS policy to protect guests from each other. As far as I can see, the MCS policy stuff has not been implemented yet ... at least with libvirt-0.6.2 ... I am still waiting for 0.6.5 to appear in Fedora 11 updates-testing. I hope this MCS policy stuff gets implemented for Fedora 11 so I can give it a try. As far as protecting the host from guests, the act of defining a guest in the current implementation changes the host and impacts other processes (my httpd example). > > > I do not understand what is being protected and who are we protecting > > from. [with respect to ISO image files and other shared files] > > > > I am not talking about a guest's virtual disk in /var/lib/libvirt/images > > (or whatever). > > > > Regardless, I do NOT believe that sVirt should be changing file contexts. > > The system (security?) administrator should be controlling what contexts > > a file has ... it should not be happening under the sVirt covers. This > > is especially true when it effects other processes (my httpd example). > > > > ISO image files should be sharable between guests as well as other > > processes on the system with a common file context. > > > > Setting the file context also causes other problems when the ISO image > > exists in a read-only file system. > > There are definitely situations where relabeling should not happen. But > the sVirt designers wanted some default protection out of the box, > without requiring manual configuration by an admin. Thus automatic > generation of MCS category pairs for each guest, with those categories > applied to the process and to the virtual disk image. I can understand the desire to provide some protection out of the box. However, having the file contexts changed automagically should be an explicit decision by the system/security administrator ... not something done by default. If this is to be allowed, there should be an sVirt or SELinux switch which needs to be set to enable automagically setting the file context. Naturally, all this needs documentation. BTW, when the MCS policy protection gets implemented, there needs to be something which manages the categories. When you have one, two or three guest, this can be manual but when you get a lot of guests (I currently have two defined), this can be a problem to manually manage. I still believe that ISO image files (and perhaps other shared virtual disk files) need a special file context that allows sVirt and other processes to access the files ... make this read-only access if that is better. Question: ... When the MCS policy stuff is implemented, will two or more guests be able to share a single ISO image file ... they should! Yes, I know this makes things a lot more complicated but I believe it is necessary. After all, doing the targeted policy is a lot more complicated than the old strict policy but was necessary to have something actually usable. Gene From sds at tycho.nsa.gov Mon Jul 6 18:46:13 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 06 Jul 2009 14:46:13 -0400 Subject: sVirt In-Reply-To: <200907061426.29751.gene@czarc.net> References: <200907041213.47694.gene@czarc.net> <200907061112.42099.gene@czarc.net> <1246897913.28321.57.camel@moss-pluto.epoch.ncsc.mil> <200907061426.29751.gene@czarc.net> Message-ID: <1246905973.28321.115.camel@moss-pluto.epoch.ncsc.mil> On Mon, 2009-07-06 at 14:26 -0400, Gene Czarcinski wrote: > Neat! > > OK, this is starting to make more sense to me. I like the idea of using the > MCS policy to protect guests from each other. > > As far as I can see, the MCS policy stuff has not been implemented yet ... at > least with libvirt-0.6.2 ... I am still waiting for 0.6.5 to appear in Fedora > 11 updates-testing. I hope this MCS policy stuff gets implemented for Fedora > 11 so I can give it a try. It works for me on F11 out of the box, as described in: http://fedoraproject.org/wiki/Features/SVirt_Mandatory_Access_Control#How_To_Test If I start guest VMs via virt-manager or virsh, they get labeled with unique MCS category pairs and their virtual disks get labeled accordingly automatically. And when I stop them, the disks get reset to their original label and become inaccessible to any guest. -- Stephen Smalley National Security Agency From jmorris at namei.org Mon Jul 6 22:22:42 2009 From: jmorris at namei.org (James Morris) Date: Tue, 7 Jul 2009 08:22:42 +1000 (EST) Subject: sVirt In-Reply-To: <200907061426.29751.gene@czarc.net> References: <200907041213.47694.gene@czarc.net> <200907061112.42099.gene@czarc.net> <1246897913.28321.57.camel@moss-pluto.epoch.ncsc.mil> <200907061426.29751.gene@czarc.net> Message-ID: On Mon, 6 Jul 2009, Gene Czarcinski wrote: > Neat! > > OK, this is starting to make more sense to me. I like the idea of using the > MCS policy to protect guests from each other. These slides from LCA should help explain the design further: http://namei.org/presentations/svirt-lca-2009.pdf There's also a google video of the talk: http://video.google.com/videoplay?docid=5750618585157629496&hl=en Dan Walsh is giving a talk on the topic at Linuxcon in September: http://linuxcon.linuxfoundation.org/meetings/1571 (which will be especially useful, as the code has evolved since the initial design). -- James Morris From BGinn at symark.com Tue Jul 7 01:23:10 2009 From: BGinn at symark.com (Brian Ginn) Date: Mon, 6 Jul 2009 18:23:10 -0700 Subject: getpwnam and SELinux In-Reply-To: <1246535569.13464.237.camel@moss-pluto.epoch.ncsc.mil> References: <8F43ACC6DCEECD4FA252B8042E2C4B8B9F3288E0B4@dragonfly.symark.com> <1246535569.13464.237.camel@moss-pluto.epoch.ncsc.mil> Message-ID: <8F43ACC6DCEECD4FA252B8042E2C4B8B9F650D8714@dragonfly.symark.com> Thanks for the response! My RHEL 5.3 box doesn't have the -D option for semodule , so I moved to Fedora 9. I still don't see a relevant AVC message. My policy, a sample run, and a test program are shown below. I get the same results running it unconfined as root. Note the role statement identified below still shows up with audit2allow, even though it is in the policy Thanks, Brian [root at localhost t]# cat t_getpw.te policy_module(t_getpw,1.0.0) type t_getpw_t; type t_getpw_exec_t; gen_require(` type unconfined_t; ') domain_auto_trans(unconfined_t, t_getpw_exec_t, t_getpw_t ) auth_can_read_shadow_passwords( t_getpw_t ); auth_read_shadow( t_getpw_t ); auth_tunable_read_shadow( t_getpw_t ); auth_use_nsswitch( t_getpw_t ); auth_domtrans_chk_passwd(t_getpw_t) gen_require(` type ld_so_cache_t; type ld_so_t; type lib_t; type root_t; type sshd_t; type unconfined_devpts_t; ') #============= t_getpw_t ============== allow t_getpw_t ld_so_cache_t:file { read getattr }; allow t_getpw_t ld_so_t:file read; allow t_getpw_t lib_t:dir search; allow t_getpw_t lib_t:file { read getattr execute }; allow t_getpw_t lib_t:lnk_file read; allow t_getpw_t root_t:dir search; allow t_getpw_t sshd_t:fd use; allow t_getpw_t t_getpw_exec_t:file entrypoint; allow t_getpw_t unconfined_devpts_t:chr_file { read write getattr }; allow t_getpw_t unconfined_t:fd use; allow t_getpw_t unconfined_t:process sigchld; #============= unconfined_t ============== allow unconfined_t t_getpw_t:dir { getattr search }; allow unconfined_t t_getpw_t:file read; allow unconfined_t t_getpw_t:process { siginh getattr rlimitinh noatsecure }; #curiously, this role statement still shows up with audit2allow: role unconfined_r types t_getpw_exec_t; #=========== pam_t and vmware_host_t are probably not related #=========== but always show up in audit.log gen_require(` type pam_t; type initrc_var_run_t; type vmware_host_t; type xdm_xserver_t; ') #============= pam_t ============== allow pam_t initrc_var_run_t:file write; #============= vmware_host_t ============== allow vmware_host_t t_getpw_t:dir { search getattr }; allow vmware_host_t t_getpw_t:file read; allow vmware_host_t xdm_xserver_t:process ptrace; [root at localhost t]# cat t_getpw.fc /usr/local/bin/t_getpwnam -- gen_context(system_u:object_r:t_getpw_exec_t,s0) [root at localhost t]# Loading Policy + /usr/sbin/semodule -i t_getpw.pp + '[' 0 -ne 0 ']' + /sbin/restorecon -F -R -v /usr/local/bin/t_getpwnam /sbin/restorecon reset /usr/local/bin/t_getpwnam context unconfined_u:object_r:bin_t:s0->system_u:object_r:t_getpw_exec_t:s0 + setenforce 1 + setenforce 0 + semodule -DB [root at localhost t]# /usr/local/bin/t_getpwnam bginn Calling getpwnam for user: bginn USER:bginn UID:500 pwd:x DONE. [root at localhost t]# cat /var/log/audit/audit.log type=AVC msg=audit(1246903716.331:18364): avc: denied { ptrace } for pid=1665 comm="vmware-guestd" scontext=system_u:system_r:vmware_host_t:s0 tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=process type=SYSCALL msg=audit(1246903716.331:18364): arch=c000003e syscall=89 per=400000 success=yes exit=19 a0=7fff06c1c7b0 a1=7fff06c1b7a0 a2=1000 a3=0 items=0 ppid=1 pid=1665 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmware-guestd" exe="/usr/lib/vmware-tools/sbin64/vmware-guestd" subj=system_u:system_r:vmware_host_t:s0 key=(null) type=SELINUX_ERR msg=audit(1246903718.119:18365): security_compute_sid: invalid context unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:t_getpw_exec_t:s0 tclass=process type=SYSCALL msg=audit(1246903718.119:18365): arch=c000003e syscall=59 success=yes exit=0 a0=bfcbd0 a1=c06760 a2=c06cb0 a3=8 items=0 ppid=16180 pid=16315 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=6 comm="t_getpwnam" exe="/usr/local/bin/t_getpwnam" subj=unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1246903726.351:18366): avc: denied { search } for pid=1665 comm="vmware-guestd" name="16315" dev=proc ino=83606 scontext=system_u:system_r:vmware_host_t:s0 tcontext=unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 tclass=dir type=AVC msg=audit(1246903726.351:18366): avc: denied { read } for pid=1665 comm="vmware-guestd" name="cmdline" dev=proc ino=83608 scontext=system_u:system_r:vmware_host_t:s0 tcontext=unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 tclass=file type=SYSCALL msg=audit(1246903726.351:18366): arch=c000003e syscall=2 per=400000 success=yes exit=12 a0=7fff06c0b190 a1=0 a2=13 a3=8101010101010100 items=0 ppid=1 pid=1665 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmware-guestd" exe="/usr/lib/vmware-tools/sbin64/vmware-guestd" subj=system_u:system_r:vmware_host_t:s0 key=(null) type=AVC msg=audit(1246903726.352:18367): avc: denied { getattr } for pid=1665 comm="vmware-guestd" path="/proc/16315" dev=proc ino=83606 scontext=system_u:system_r:vmware_host_t:s0 tcontext=unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 tclass=dir type=SYSCALL msg=audit(1246903726.352:18367): arch=c000003e syscall=4 per=400000 success=yes exit=0 a0=7fff06c0b190 a1=7fff06c0b590 a2=7fff06c0b590 a3=0 items=0 ppid=1 pid=1665 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmware-guestd" exe="/usr/lib/vmware-tools/sbin64/vmware-guestd" subj=system_u:system_r:vmware_host_t:s0 key=(null) [root at localhost t]# cat /var/log/audit/audit.log| audit2allow #============= vmware_host_t ============== allow vmware_host_t t_getpw_t:dir { search getattr }; allow vmware_host_t t_getpw_t:file read; allow vmware_host_t xdm_xserver_t:process ptrace; =========== ROLES =============== role unconfined_r types t_getpw_exec_t; [root at localhost t]# [root at localhost t]# cat t_getpwnam.c #include #include #include #include int main( int argc, char** argv ) { struct passwd *p; char* user = NULL; sleep(9); if( argc != 2 ) { printf("must have username as argument\n"); exit(1); } user = argv[1]; printf("Calling getpwnam for user: %s\n", user); setpwent(); p = getpwnam( user ); if( p == NULL ) { printf("User not found (or error).\n"); }else{ printf("USER:%s UID:%d pwd:%s\n", p->pw_name, p->pw_uid, p->pw_passwd ); } endpwent(); printf("DONE.\n"); return( 0 ); } [root at localhost t]# -----Original Message----- From: Stephen Smalley [mailto:sds at tycho.nsa.gov] Sent: Thursday, July 02, 2009 4:53 AM To: Brian Ginn Cc: 'fedora-selinux-list at redhat.com' Subject: Re: getpwnam and SELinux On Wed, 2009-07-01 at 16:15 -0700, Brian Ginn wrote: > I have an app that I'm trying to confine. > > > > In enforcing mode, getpwnam() returns "X" for the pw_passwd field. > > > > Is there SELinux policy to allow this app to get the shadow passwd? > > I've tried the following without success: > > auth_can_read_shadow_passwords( ) > > auth_read_shadow( ) > > auth_tunable_read_shadow( ) > > auth_use_nsswitch( ) Can you show us the actual denial? Run semodule -DB first if you don't get any denials, and then run semodule -B afterward. Also, post your .te file. -- Stephen Smalley National Security Agency From jonathan.stott at gmail.com Tue Jul 7 09:59:51 2009 From: jonathan.stott at gmail.com (Jonathan Stott) Date: Tue, 7 Jul 2009 10:59:51 +0100 Subject: SELinux and gitosis (FC11) In-Reply-To: <4A51EA2A.8020609@redhat.com> References: <20090630162121.58df1092@hzhangpg02.ph.man.ac.uk> <4A4A4954.40308@redhat.com> <14cf210a0907040441p38dce15k91dee18697f0fd9a@mail.gmail.com> <4A51EA2A.8020609@redhat.com> Message-ID: <20090707105951.443270f3@hzhangpg02.ph.man.ac.uk> On Mon, 06 Jul 2009 08:12:26 -0400 Daniel J Walsh wrote: > On 07/04/2009 07:41 AM, Jonathan Stott wrote: > > Hi > > > > # rpm -q selinux-policy selinux-policy-targeted > > selinux-policy-3.6.12-62.fc11.noarch > > selinux-policy-targeted-3.6.12-62.fc11.noarch > > > > (previously it was 3.6.12-53) > > > > And gitosis-serve is labelled gitosis_exec_t > > > > Even after upgrading the selinux policy versions, it still seems to > > hang in the same manner though. > > > > Regards, > > Jon > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Are you seeing any avc messages in /var/log/audit/audit.log? > > ps -eZ | grep gitosis > > Does this show apps running under the correct domain? > It's hard to tell whether it's running under the correct context (gitosis-serve seems to very quickly shell out to whatever git command is called and I'm not sure how to trigger ps at the correct time). However it definitely has the correct context on the executable (which is the only copy of gitosis-serve on the system), and I've relabeled the file system just to be sure. However, I still seem to get the same AVC denial: ----------------------------------------------------------------------------- Summary: SELinux is preventing bash (guest_t) "write" sshd_t. Detailed Description: SELinux denied access requested by bash. It is not expected that this access is required by bash and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context guest_u:guest_r:guest_t:s0 Target Context system_u:system_r:sshd_t:s0-s0:c0.c1023 Target Objects pipe [ fifo_file ] Source bash Source Path /bin/bash Port Host hzhangpg02.ph.man.ac.uk Source RPM Packages bash-4.0-6.fc11 Target RPM Packages Policy RPM selinux-policy-3.6.12-62.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name hzhangpg02.ph.man.ac.uk Platform Linux hzhangpg02.ph.man.ac.uk 2.6.29.5-191.fc11.x86_64 #1 SMP Tue Jun 16 23:23:21 EDT 2009 x86_64 x86_64 Alert Count 31 First Seen Tue 30 Jun 2009 16:48:17 BST Last Seen Tue 07 Jul 2009 10:51:13 BST Local ID 1cf6580e-12c8-48fb-bbb8-c06c3e55109d Line Numbers Raw Audit Messages node=hzhangpg02.ph.man.ac.uk type=AVC msg=audit(1246960273.947:80): avc: denied { write } for pid=3472 comm="bash" path="pipe:[51971]" dev=pipefs ino=51971 scontext=guest_u:guest_r:guest_t:s0 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=fifo_file node=hzhangpg02.ph.man.ac.uk type=AVC msg=audit(1246960273.947:80): avc: denied { write } for pid=3472 comm="bash" path="pipe:[51972]" dev=pipefs ino=51972 scontext=guest_u:guest_r:guest_t:s0 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=fifo_file node=hzhangpg02.ph.man.ac.uk type=SYSCALL msg=audit(1246960273.947:80): arch=c000003e syscall=59 success=yes exit=0 a0=7f5e932395d0 a1=7ffff16ddc90 a2=7f5e932314c0 a3=7ffff16dd940 items=0 ppid=3471 pid=3472 auid=501 uid=501 gid=501 euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=(none) ses=5 comm="bash" exe="/bin/bash" subj=guest_u:guest_r:guest_t:s0 key=(null) -------------------------------------------------------------------- Piping the raw audit messages into audit2allow and installing the module doesn't seem to remove them, though. Regards, Jon From sds at tycho.nsa.gov Tue Jul 7 11:57:05 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 07 Jul 2009 07:57:05 -0400 Subject: getpwnam and SELinux In-Reply-To: <8F43ACC6DCEECD4FA252B8042E2C4B8B9F650D8714@dragonfly.symark.com> References: <8F43ACC6DCEECD4FA252B8042E2C4B8B9F3288E0B4@dragonfly.symark.com> <1246535569.13464.237.camel@moss-pluto.epoch.ncsc.mil> <8F43ACC6DCEECD4FA252B8042E2C4B8B9F650D8714@dragonfly.symark.com> Message-ID: <1246967825.28321.164.camel@moss-pluto.epoch.ncsc.mil> On Mon, 2009-07-06 at 18:23 -0700, Brian Ginn wrote: > Thanks for the response! > > My RHEL 5.3 box doesn't have the -D option for semodule , so I moved to Fedora 9. > I still don't see a relevant AVC message. > > My policy, a sample run, and a test program are shown below. > I get the same results running it unconfined as root. > Note the role statement identified below still shows up with audit2allow, even though it is in the policy Hmmm...bug in the policy compiler, maybe? I don't see unconfined_r in a require block in your policy module. Try adding: role unconfined_r; to the first gen_require() block. > Thanks, > Brian > > > [root at localhost t]# cat t_getpw.te > policy_module(t_getpw,1.0.0) > > type t_getpw_t; > type t_getpw_exec_t; > > gen_require(` > type unconfined_t; > ') > domain_auto_trans(unconfined_t, t_getpw_exec_t, t_getpw_t ) > > auth_can_read_shadow_passwords( t_getpw_t ); > auth_read_shadow( t_getpw_t ); > auth_tunable_read_shadow( t_getpw_t ); > auth_use_nsswitch( t_getpw_t ); > auth_domtrans_chk_passwd(t_getpw_t) > > gen_require(` > type ld_so_cache_t; > type ld_so_t; > type lib_t; > type root_t; > type sshd_t; > type unconfined_devpts_t; > ') > > #============= t_getpw_t ============== > allow t_getpw_t ld_so_cache_t:file { read getattr }; > allow t_getpw_t ld_so_t:file read; > allow t_getpw_t lib_t:dir search; > allow t_getpw_t lib_t:file { read getattr execute }; > allow t_getpw_t lib_t:lnk_file read; > allow t_getpw_t root_t:dir search; > allow t_getpw_t sshd_t:fd use; > allow t_getpw_t t_getpw_exec_t:file entrypoint; > allow t_getpw_t unconfined_devpts_t:chr_file { read write getattr }; > allow t_getpw_t unconfined_t:fd use; > allow t_getpw_t unconfined_t:process sigchld; > > #============= unconfined_t ============== > allow unconfined_t t_getpw_t:dir { getattr search }; > allow unconfined_t t_getpw_t:file read; > allow unconfined_t t_getpw_t:process { siginh getattr rlimitinh noatsecure }; > > #curiously, this role statement still shows up with audit2allow: > role unconfined_r types t_getpw_exec_t; > > #=========== pam_t and vmware_host_t are probably not related > #=========== but always show up in audit.log > > gen_require(` > type pam_t; > type initrc_var_run_t; > type vmware_host_t; > type xdm_xserver_t; > ') > #============= pam_t ============== > allow pam_t initrc_var_run_t:file write; > > #============= vmware_host_t ============== > allow vmware_host_t t_getpw_t:dir { search getattr }; > allow vmware_host_t t_getpw_t:file read; > allow vmware_host_t xdm_xserver_t:process ptrace; > > > [root at localhost t]# cat t_getpw.fc > > /usr/local/bin/t_getpwnam -- gen_context(system_u:object_r:t_getpw_exec_t,s0) > > [root at localhost t]# > > > > > Loading Policy > + /usr/sbin/semodule -i t_getpw.pp > + '[' 0 -ne 0 ']' > + /sbin/restorecon -F -R -v /usr/local/bin/t_getpwnam > /sbin/restorecon reset /usr/local/bin/t_getpwnam context unconfined_u:object_r:bin_t:s0->system_u:object_r:t_getpw_exec_t:s0 > + setenforce 1 > + setenforce 0 > + semodule -DB > [root at localhost t]# /usr/local/bin/t_getpwnam bginn > Calling getpwnam for user: bginn > USER:bginn UID:500 pwd:x > DONE. > [root at localhost t]# cat /var/log/audit/audit.log > type=AVC msg=audit(1246903716.331:18364): avc: denied { ptrace } for pid=1665 comm="vmware-guestd" scontext=system_u:system_r:vmware_host_t:s0 tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=process > type=SYSCALL msg=audit(1246903716.331:18364): arch=c000003e syscall=89 per=400000 success=yes exit=19 a0=7fff06c1c7b0 a1=7fff06c1b7a0 a2=1000 a3=0 items=0 ppid=1 pid=1665 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmware-guestd" exe="/usr/lib/vmware-tools/sbin64/vmware-guestd" subj=system_u:system_r:vmware_host_t:s0 key=(null) > type=SELINUX_ERR msg=audit(1246903718.119:18365): security_compute_sid: invalid context unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:t_getpw_exec_t:s0 tclass=process > type=SYSCALL msg=audit(1246903718.119:18365): arch=c000003e syscall=59 success=yes exit=0 a0=bfcbd0 a1=c06760 a2=c06cb0 a3=8 items=0 ppid=16180 pid=16315 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=6 comm="t_getpwnam" exe="/usr/local/bin/t_getpwnam" subj=unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1246903726.351:18366): avc: denied { search } for pid=1665 comm="vmware-guestd" name="16315" dev=proc ino=83606 scontext=system_u:system_r:vmware_host_t:s0 tcontext=unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 tclass=dir > type=AVC msg=audit(1246903726.351:18366): avc: denied { read } for pid=1665 comm="vmware-guestd" name="cmdline" dev=proc ino=83608 scontext=system_u:system_r:vmware_host_t:s0 tcontext=unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 tclass=file > type=SYSCALL msg=audit(1246903726.351:18366): arch=c000003e syscall=2 per=400000 success=yes exit=12 a0=7fff06c0b190 a1=0 a2=13 a3=8101010101010100 items=0 ppid=1 pid=1665 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmware-guestd" exe="/usr/lib/vmware-tools/sbin64/vmware-guestd" subj=system_u:system_r:vmware_host_t:s0 key=(null) > type=AVC msg=audit(1246903726.352:18367): avc: denied { getattr } for pid=1665 comm="vmware-guestd" path="/proc/16315" dev=proc ino=83606 scontext=system_u:system_r:vmware_host_t:s0 tcontext=unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 tclass=dir > type=SYSCALL msg=audit(1246903726.352:18367): arch=c000003e syscall=4 per=400000 success=yes exit=0 a0=7fff06c0b190 a1=7fff06c0b590 a2=7fff06c0b590 a3=0 items=0 ppid=1 pid=1665 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmware-guestd" exe="/usr/lib/vmware-tools/sbin64/vmware-guestd" subj=system_u:system_r:vmware_host_t:s0 key=(null) > [root at localhost t]# cat /var/log/audit/audit.log| audit2allow > > > #============= vmware_host_t ============== > allow vmware_host_t t_getpw_t:dir { search getattr }; > allow vmware_host_t t_getpw_t:file read; > allow vmware_host_t xdm_xserver_t:process ptrace; > > =========== ROLES =============== > role unconfined_r types t_getpw_exec_t; > [root at localhost t]# > > > > [root at localhost t]# cat t_getpwnam.c > #include > #include > #include > #include > > int main( int argc, char** argv ) > { > struct passwd *p; > char* user = NULL; > > sleep(9); > > if( argc != 2 ) > { > printf("must have username as argument\n"); > exit(1); > } > > user = argv[1]; > > printf("Calling getpwnam for user: %s\n", user); > > setpwent(); > p = getpwnam( user ); > if( p == NULL ) > { > printf("User not found (or error).\n"); > }else{ > printf("USER:%s UID:%d pwd:%s\n", p->pw_name, p->pw_uid, p->pw_passwd ); > } > endpwent(); > > printf("DONE.\n"); > return( 0 ); > } > [root at localhost t]# > > > > > -----Original Message----- > From: Stephen Smalley [mailto:sds at tycho.nsa.gov] > Sent: Thursday, July 02, 2009 4:53 AM > To: Brian Ginn > Cc: 'fedora-selinux-list at redhat.com' > Subject: Re: getpwnam and SELinux > > On Wed, 2009-07-01 at 16:15 -0700, Brian Ginn wrote: > > I have an app that I'm trying to confine. > > > > > > > > In enforcing mode, getpwnam() returns "X" for the pw_passwd field. > > > > > > > > Is there SELinux policy to allow this app to get the shadow passwd? > > > > I've tried the following without success: > > > > auth_can_read_shadow_passwords( ) > > > > auth_read_shadow( ) > > > > auth_tunable_read_shadow( ) > > > > auth_use_nsswitch( ) > > Can you show us the actual denial? Run semodule -DB first if you don't > get any denials, and then run semodule -B afterward. Also, post > your .te file. > -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue Jul 7 12:57:02 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 07 Jul 2009 08:57:02 -0400 Subject: SELinux and gitosis (FC11) In-Reply-To: <20090707105951.443270f3@hzhangpg02.ph.man.ac.uk> References: <20090630162121.58df1092@hzhangpg02.ph.man.ac.uk> <4A4A4954.40308@redhat.com> <14cf210a0907040441p38dce15k91dee18697f0fd9a@mail.gmail.com> <4A51EA2A.8020609@redhat.com> <20090707105951.443270f3@hzhangpg02.ph.man.ac.uk> Message-ID: <4A53461E.2040508@redhat.com> On 07/07/2009 05:59 AM, Jonathan Stott wrote: > On Mon, 06 Jul 2009 08:12:26 -0400 > Daniel J Walsh wrote: > >> On 07/04/2009 07:41 AM, Jonathan Stott wrote: >>> Hi >>> >>> # rpm -q selinux-policy selinux-policy-targeted >>> selinux-policy-3.6.12-62.fc11.noarch >>> selinux-policy-targeted-3.6.12-62.fc11.noarch >>> >>> (previously it was 3.6.12-53) >>> >>> And gitosis-serve is labelled gitosis_exec_t >>> >>> Even after upgrading the selinux policy versions, it still seems to >>> hang in the same manner though. >>> >>> Regards, >>> Jon >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> Are you seeing any avc messages in /var/log/audit/audit.log? >> >> ps -eZ | grep gitosis >> >> Does this show apps running under the correct domain? >> > > It's hard to tell whether it's running under the correct context (gitosis-serve seems to very quickly shell out to whatever git command is called and I'm not sure how to trigger ps at the correct time). However it definitely has the correct context on the executable (which is the only copy of gitosis-serve on the system), and I've relabeled the file system just to be sure. > > However, I still seem to get the same AVC denial: > > ----------------------------------------------------------------------------- > Summary: > > SELinux is preventing bash (guest_t) "write" sshd_t. > > Detailed Description: > > SELinux denied access requested by bash. It is not expected that this access is > required by bash and this access may signal an intrusion attempt. It is also > possible that the specific version or configuration of the application is > causing it to require additional access. > > Allowing Access: > > You can generate a local policy module to allow this access - see FAQ > (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable > SELinux protection altogether. Disabling SELinux protection is not recommended. > Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > against this package. > > Additional Information: > > Source Context guest_u:guest_r:guest_t:s0 > Target Context system_u:system_r:sshd_t:s0-s0:c0.c1023 > Target Objects pipe [ fifo_file ] > Source bash > Source Path /bin/bash > Port > Host hzhangpg02.ph.man.ac.uk > Source RPM Packages bash-4.0-6.fc11 > Target RPM Packages > Policy RPM selinux-policy-3.6.12-62.fc11 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall > Host Name hzhangpg02.ph.man.ac.uk > Platform Linux hzhangpg02.ph.man.ac.uk > 2.6.29.5-191.fc11.x86_64 #1 SMP Tue Jun 16 > 23:23:21 EDT 2009 x86_64 x86_64 > Alert Count 31 > First Seen Tue 30 Jun 2009 16:48:17 BST > Last Seen Tue 07 Jul 2009 10:51:13 BST > Local ID 1cf6580e-12c8-48fb-bbb8-c06c3e55109d > Line Numbers > > Raw Audit Messages > > node=hzhangpg02.ph.man.ac.uk type=AVC msg=audit(1246960273.947:80): avc: denied { write } for pid=3472 comm="bash" path="pipe:[51971]" dev=pipefs ino=51971 scontext=guest_u:guest_r:guest_t:s0 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=fifo_file > > node=hzhangpg02.ph.man.ac.uk type=AVC msg=audit(1246960273.947:80): avc: denied { write } for pid=3472 comm="bash" path="pipe:[51972]" dev=pipefs ino=51972 scontext=guest_u:guest_r:guest_t:s0 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=fifo_file > > node=hzhangpg02.ph.man.ac.uk type=SYSCALL msg=audit(1246960273.947:80): arch=c000003e syscall=59 success=yes exit=0 a0=7f5e932395d0 a1=7ffff16ddc90 a2=7f5e932314c0 a3=7ffff16dd940 items=0 ppid=3471 pid=3472 auid=501 uid=501 gid=501 euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=(none) ses=5 comm="bash" exe="/bin/bash" subj=guest_u:guest_r:guest_t:s0 key=(null) > > -------------------------------------------------------------------- > > Piping the raw audit messages into audit2allow and installing the module doesn't seem to remove them, though. > > Regards, > Jon So you intended on using the guest_t user? What does the te file created by audit2allow look like? I think the problem here is the guest_t user is running at s0 and trying to write to a fifo_file at s0-s0:c0.c1023 If you take the above audit messages and run them through audit2why, what does the tool say? From jonathan.stott at gmail.com Tue Jul 7 13:07:59 2009 From: jonathan.stott at gmail.com (Jonathan Stott) Date: Tue, 7 Jul 2009 14:07:59 +0100 Subject: SELinux and gitosis (FC11) In-Reply-To: <4A53461E.2040508@redhat.com> References: <20090630162121.58df1092@hzhangpg02.ph.man.ac.uk> <4A4A4954.40308@redhat.com> <14cf210a0907040441p38dce15k91dee18697f0fd9a@mail.gmail.com> <4A51EA2A.8020609@redhat.com> <20090707105951.443270f3@hzhangpg02.ph.man.ac.uk> <4A53461E.2040508@redhat.com> Message-ID: <14cf210a0907070607y2d6d6cc8p23bc3bfe7052421f@mail.gmail.com> 2009/7/7 Daniel J Walsh : > > So you intended on using the guest_t user? ?What does the te file created by > audit2allow look like? > > I think the problem here is the guest_t user is running at s0 and trying to > write to a fifo_file at s0-s0:c0.c1023 > > If you take the above audit messages and run them through audit2why, what > does the tool say? > It says the errors were caused by: Was caused by: Policy constraint violation. May require adding a type attribute to the domain or type to satisfy the constraint. Constraints are defined in the policy sources in policy/constraints (general), policy/mcs (MCS), and policy/mls (MLS). And when I run them through audit2why gives me #============= guest_t ============== allow guest_t sshd_t:fifo_file write; Which looks vaguely sane to my untrained eye. I'm not particularly wedded to the guest user in specific, but I would prefer it to have a minimal privilege user, since it has no need to do anything but manage the git repositories in the home directory. Regards Jon From dwalsh at redhat.com Tue Jul 7 14:20:35 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 07 Jul 2009 10:20:35 -0400 Subject: SELinux and gitosis (FC11) In-Reply-To: <14cf210a0907070607y2d6d6cc8p23bc3bfe7052421f@mail.gmail.com> References: <20090630162121.58df1092@hzhangpg02.ph.man.ac.uk> <4A4A4954.40308@redhat.com> <14cf210a0907040441p38dce15k91dee18697f0fd9a@mail.gmail.com> <4A51EA2A.8020609@redhat.com> <20090707105951.443270f3@hzhangpg02.ph.man.ac.uk> <4A53461E.2040508@redhat.com> <14cf210a0907070607y2d6d6cc8p23bc3bfe7052421f@mail.gmail.com> Message-ID: <4A5359B3.2050703@redhat.com> On 07/07/2009 09:07 AM, Jonathan Stott wrote: > 2009/7/7 Daniel J Walsh: >> So you intended on using the guest_t user? What does the te file created by >> audit2allow look like? >> >> I think the problem here is the guest_t user is running at s0 and trying to >> write to a fifo_file at s0-s0:c0.c1023 >> >> If you take the above audit messages and run them through audit2why, what >> does the tool say? >> > > It says the errors were caused by: > Was caused by: > Policy constraint violation. > > May require adding a type attribute to the domain or type to satisfy > the constraint. > > Constraints are defined in the policy sources in policy/constraints > (general), policy/mcs (MCS), and policy/mls (MLS). > > And when I run them through audit2why gives me > > #============= guest_t ============== > allow guest_t sshd_t:fifo_file write; > > Which looks vaguely sane to my untrained eye. > > I'm not particularly wedded to the guest user in specific, but I would > prefer it to have a minimal privilege user, since it has no need to do > anything but manage the git repositories in the home directory. > > Regards > Jon No I think this is great, Just trying to figure out the best way to do this. From dwalsh at redhat.com Tue Jul 7 14:28:22 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 07 Jul 2009 10:28:22 -0400 Subject: SELinux and gitosis (FC11) In-Reply-To: <14cf210a0907070607y2d6d6cc8p23bc3bfe7052421f@mail.gmail.com> References: <20090630162121.58df1092@hzhangpg02.ph.man.ac.uk> <4A4A4954.40308@redhat.com> <14cf210a0907040441p38dce15k91dee18697f0fd9a@mail.gmail.com> <4A51EA2A.8020609@redhat.com> <20090707105951.443270f3@hzhangpg02.ph.man.ac.uk> <4A53461E.2040508@redhat.com> <14cf210a0907070607y2d6d6cc8p23bc3bfe7052421f@mail.gmail.com> Message-ID: <4A535B86.4010807@redhat.com> On 07/07/2009 09:07 AM, Jonathan Stott wrote: > 2009/7/7 Daniel J Walsh: >> So you intended on using the guest_t user? What does the te file created by >> audit2allow look like? >> >> I think the problem here is the guest_t user is running at s0 and trying to >> write to a fifo_file at s0-s0:c0.c1023 >> >> If you take the above audit messages and run them through audit2why, what >> does the tool say? >> > > It says the errors were caused by: > Was caused by: > Policy constraint violation. > > May require adding a type attribute to the domain or type to satisfy > the constraint. > > Constraints are defined in the policy sources in policy/constraints > (general), policy/mcs (MCS), and policy/mls (MLS). > > And when I run them through audit2why gives me > > #============= guest_t ============== > allow guest_t sshd_t:fifo_file write; > > Which looks vaguely sane to my untrained eye. > > I'm not particularly wedded to the guest user in specific, but I would > prefer it to have a minimal privilege user, since it has no need to do > anything but manage the git repositories in the home directory. > > Regards > Jon Ok I think the easiest thing for you to do now is change the range of the login user. # semanage user -m -r s0-s0:c0.c1023 guest_u # semanage login -m -r s0-s0:c0.c1023 __default__ (If you use a user other then __default__ you would need to change this also.) I will send a patch to F11 to allow communications to fifo_files running at different levels. From gene at czarc.net Tue Jul 7 17:06:43 2009 From: gene at czarc.net (Gene Czarcinski) Date: Tue, 7 Jul 2009 13:06:43 -0400 Subject: sVirt In-Reply-To: References: <200907041213.47694.gene@czarc.net> <200907061426.29751.gene@czarc.net> Message-ID: <200907071306.43499.gene@czarc.net> On Monday 06 July 2009 18:22:42 James Morris wrote: > On Mon, 6 Jul 2009, Gene Czarcinski wrote: > > Neat! > > > > OK, this is starting to make more sense to me. I like the idea of using > > the MCS policy to protect guests from each other. > > These slides from LCA should help explain the design further: > http://namei.org/presentations/svirt-lca-2009.pdf > > There's also a google video of the talk: > http://video.google.com/videoplay?docid=5750618585157629496&hl=en > > Dan Walsh is giving a talk on the topic at Linuxcon in September: > http://linuxcon.linuxfoundation.org/meetings/1571 > > (which will be especially useful, as the code has evolved since the > initial design). Thank you one and all. With the provided pointers to documentation I now have a much better understanding of how sVirt is using MCS. When I originally saw that MCS was being used to restrict guest, I immediately thought it was a static implementation but did not see anything on the virtual disk image files so I thought it was not implemented yet. However, you use MCS dynamically when a guest is actually run ... this makes more sense and is far simpler to implement and manage than any static implementation.. I see that you "only" set categories for the virtual disk images and not the ISO image file ... at least this is what I see and hope this is true ... example: i OFTEN run two or three guests which booted into rescue mode from a single netinst CD image. I noticed that the SELinux rule for virt_image_t allows both read and write as it must. However, the SELinux rule for virt_content_t (which is used for ISO image files) also allows both read and write ... changing this to read-only makes more sense to me. I still believe that sVirt should not be changing the file context for ISO images (especially now that I see that categories are not set). One solution which would "scratch my itch" while still doing (more or less) what is now done is to add some global sVirt parameter to define what context to use and have this default to virt_content_t. It would also be nice if this could be overridden on a per-guest basis also. Note that I am only talking about files which would use virt_content_t since the "static" option mentioned in a different email addresses the virtual disk image file ... at least I think it does. BTW, it appears that sVirt picks a couple of non-zero random numbers to use for the category pair. True? If true, is any checking done so there are not any conflicts/reuse on different guests? [I am trying to avoid going to the ultimate documentation for any software ... the source code] Gene From BGinn at symark.com Tue Jul 7 19:04:31 2009 From: BGinn at symark.com (Brian Ginn) Date: Tue, 7 Jul 2009 12:04:31 -0700 Subject: getpwnam and SELinux In-Reply-To: <1246967825.28321.164.camel@moss-pluto.epoch.ncsc.mil> References: <8F43ACC6DCEECD4FA252B8042E2C4B8B9F3288E0B4@dragonfly.symark.com> <1246535569.13464.237.camel@moss-pluto.epoch.ncsc.mil> <8F43ACC6DCEECD4FA252B8042E2C4B8B9F650D8714@dragonfly.symark.com> <1246967825.28321.164.camel@moss-pluto.epoch.ncsc.mil> Message-ID: <8F43ACC6DCEECD4FA252B8042E2C4B8B9F650D8718@dragonfly.symark.com> Thanks for the suggestion. My program still doesn't work yet, but I notice that /var/log/messages has: Jul 6 12:43:55 localhost kernel: security: context unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 is invalid What would make this invlaid? Thanks, Brian -----Original Message----- From: Stephen Smalley [mailto:sds at tycho.nsa.gov] Sent: Tuesday, July 07, 2009 4:57 AM To: Brian Ginn Cc: 'fedora-selinux-list at redhat.com'; Joshua Brindle Subject: RE: getpwnam and SELinux On Mon, 2009-07-06 at 18:23 -0700, Brian Ginn wrote: > Thanks for the response! > > My RHEL 5.3 box doesn't have the -D option for semodule , so I moved to Fedora 9. > I still don't see a relevant AVC message. > > My policy, a sample run, and a test program are shown below. > I get the same results running it unconfined as root. > Note the role statement identified below still shows up with audit2allow, even though it is in the policy Hmmm...bug in the policy compiler, maybe? I don't see unconfined_r in a require block in your policy module. Try adding: role unconfined_r; to the first gen_require() block. > Thanks, > Brian > > > [root at localhost t]# cat t_getpw.te > policy_module(t_getpw,1.0.0) > > type t_getpw_t; > type t_getpw_exec_t; > > gen_require(` > type unconfined_t; > ') > domain_auto_trans(unconfined_t, t_getpw_exec_t, t_getpw_t ) > > auth_can_read_shadow_passwords( t_getpw_t ); > auth_read_shadow( t_getpw_t ); > auth_tunable_read_shadow( t_getpw_t ); > auth_use_nsswitch( t_getpw_t ); > auth_domtrans_chk_passwd(t_getpw_t) > > gen_require(` > type ld_so_cache_t; > type ld_so_t; > type lib_t; > type root_t; > type sshd_t; > type unconfined_devpts_t; > ') > > #============= t_getpw_t ============== > allow t_getpw_t ld_so_cache_t:file { read getattr }; > allow t_getpw_t ld_so_t:file read; > allow t_getpw_t lib_t:dir search; > allow t_getpw_t lib_t:file { read getattr execute }; > allow t_getpw_t lib_t:lnk_file read; > allow t_getpw_t root_t:dir search; > allow t_getpw_t sshd_t:fd use; > allow t_getpw_t t_getpw_exec_t:file entrypoint; > allow t_getpw_t unconfined_devpts_t:chr_file { read write getattr }; > allow t_getpw_t unconfined_t:fd use; > allow t_getpw_t unconfined_t:process sigchld; > > #============= unconfined_t ============== > allow unconfined_t t_getpw_t:dir { getattr search }; > allow unconfined_t t_getpw_t:file read; > allow unconfined_t t_getpw_t:process { siginh getattr rlimitinh noatsecure }; > > #curiously, this role statement still shows up with audit2allow: > role unconfined_r types t_getpw_exec_t; > > #=========== pam_t and vmware_host_t are probably not related > #=========== but always show up in audit.log > > gen_require(` > type pam_t; > type initrc_var_run_t; > type vmware_host_t; > type xdm_xserver_t; > ') > #============= pam_t ============== > allow pam_t initrc_var_run_t:file write; > > #============= vmware_host_t ============== > allow vmware_host_t t_getpw_t:dir { search getattr }; > allow vmware_host_t t_getpw_t:file read; > allow vmware_host_t xdm_xserver_t:process ptrace; > > > [root at localhost t]# cat t_getpw.fc > > /usr/local/bin/t_getpwnam -- gen_context(system_u:object_r:t_getpw_exec_t,s0) > > [root at localhost t]# > > > > > Loading Policy > + /usr/sbin/semodule -i t_getpw.pp > + '[' 0 -ne 0 ']' > + /sbin/restorecon -F -R -v /usr/local/bin/t_getpwnam > /sbin/restorecon reset /usr/local/bin/t_getpwnam context unconfined_u:object_r:bin_t:s0->system_u:object_r:t_getpw_exec_t:s0 > + setenforce 1 > + setenforce 0 > + semodule -DB > [root at localhost t]# /usr/local/bin/t_getpwnam bginn > Calling getpwnam for user: bginn > USER:bginn UID:500 pwd:x > DONE. > [root at localhost t]# cat /var/log/audit/audit.log > type=AVC msg=audit(1246903716.331:18364): avc: denied { ptrace } for pid=1665 comm="vmware-guestd" scontext=system_u:system_r:vmware_host_t:s0 tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=process > type=SYSCALL msg=audit(1246903716.331:18364): arch=c000003e syscall=89 per=400000 success=yes exit=19 a0=7fff06c1c7b0 a1=7fff06c1b7a0 a2=1000 a3=0 items=0 ppid=1 pid=1665 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmware-guestd" exe="/usr/lib/vmware-tools/sbin64/vmware-guestd" subj=system_u:system_r:vmware_host_t:s0 key=(null) > type=SELINUX_ERR msg=audit(1246903718.119:18365): security_compute_sid: invalid context unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:t_getpw_exec_t:s0 tclass=process > type=SYSCALL msg=audit(1246903718.119:18365): arch=c000003e syscall=59 success=yes exit=0 a0=bfcbd0 a1=c06760 a2=c06cb0 a3=8 items=0 ppid=16180 pid=16315 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=6 comm="t_getpwnam" exe="/usr/local/bin/t_getpwnam" subj=unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1246903726.351:18366): avc: denied { search } for pid=1665 comm="vmware-guestd" name="16315" dev=proc ino=83606 scontext=system_u:system_r:vmware_host_t:s0 tcontext=unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 tclass=dir > type=AVC msg=audit(1246903726.351:18366): avc: denied { read } for pid=1665 comm="vmware-guestd" name="cmdline" dev=proc ino=83608 scontext=system_u:system_r:vmware_host_t:s0 tcontext=unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 tclass=file > type=SYSCALL msg=audit(1246903726.351:18366): arch=c000003e syscall=2 per=400000 success=yes exit=12 a0=7fff06c0b190 a1=0 a2=13 a3=8101010101010100 items=0 ppid=1 pid=1665 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmware-guestd" exe="/usr/lib/vmware-tools/sbin64/vmware-guestd" subj=system_u:system_r:vmware_host_t:s0 key=(null) > type=AVC msg=audit(1246903726.352:18367): avc: denied { getattr } for pid=1665 comm="vmware-guestd" path="/proc/16315" dev=proc ino=83606 scontext=system_u:system_r:vmware_host_t:s0 tcontext=unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 tclass=dir > type=SYSCALL msg=audit(1246903726.352:18367): arch=c000003e syscall=4 per=400000 success=yes exit=0 a0=7fff06c0b190 a1=7fff06c0b590 a2=7fff06c0b590 a3=0 items=0 ppid=1 pid=1665 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vmware-guestd" exe="/usr/lib/vmware-tools/sbin64/vmware-guestd" subj=system_u:system_r:vmware_host_t:s0 key=(null) > [root at localhost t]# cat /var/log/audit/audit.log| audit2allow > > > #============= vmware_host_t ============== > allow vmware_host_t t_getpw_t:dir { search getattr }; > allow vmware_host_t t_getpw_t:file read; > allow vmware_host_t xdm_xserver_t:process ptrace; > > =========== ROLES =============== > role unconfined_r types t_getpw_exec_t; > [root at localhost t]# > > > > [root at localhost t]# cat t_getpwnam.c > #include > #include > #include > #include > > int main( int argc, char** argv ) > { > struct passwd *p; > char* user = NULL; > > sleep(9); > > if( argc != 2 ) > { > printf("must have username as argument\n"); > exit(1); > } > > user = argv[1]; > > printf("Calling getpwnam for user: %s\n", user); > > setpwent(); > p = getpwnam( user ); > if( p == NULL ) > { > printf("User not found (or error).\n"); > }else{ > printf("USER:%s UID:%d pwd:%s\n", p->pw_name, p->pw_uid, p->pw_passwd ); > } > endpwent(); > > printf("DONE.\n"); > return( 0 ); > } > [root at localhost t]# > > > > > -----Original Message----- > From: Stephen Smalley [mailto:sds at tycho.nsa.gov] > Sent: Thursday, July 02, 2009 4:53 AM > To: Brian Ginn > Cc: 'fedora-selinux-list at redhat.com' > Subject: Re: getpwnam and SELinux > > On Wed, 2009-07-01 at 16:15 -0700, Brian Ginn wrote: > > I have an app that I'm trying to confine. > > > > > > > > In enforcing mode, getpwnam() returns "X" for the pw_passwd field. > > > > > > > > Is there SELinux policy to allow this app to get the shadow passwd? > > > > I've tried the following without success: > > > > auth_can_read_shadow_passwords( ) > > > > auth_read_shadow( ) > > > > auth_tunable_read_shadow( ) > > > > auth_use_nsswitch( ) > > Can you show us the actual denial? Run semodule -DB first if you don't > get any denials, and then run semodule -B afterward. Also, post > your .te file. > -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Jul 7 19:24:18 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 07 Jul 2009 15:24:18 -0400 Subject: getpwnam and SELinux In-Reply-To: <8F43ACC6DCEECD4FA252B8042E2C4B8B9F650D8718@dragonfly.symark.com> References: <8F43ACC6DCEECD4FA252B8042E2C4B8B9F3288E0B4@dragonfly.symark.com> <1246535569.13464.237.camel@moss-pluto.epoch.ncsc.mil> <8F43ACC6DCEECD4FA252B8042E2C4B8B9F650D8714@dragonfly.symark.com> <1246967825.28321.164.camel@moss-pluto.epoch.ncsc.mil> <8F43ACC6DCEECD4FA252B8042E2C4B8B9F650D8718@dragonfly.symark.com> Message-ID: <1246994658.28321.285.camel@moss-pluto.epoch.ncsc.mil> On Tue, 2009-07-07 at 12:04 -0700, Brian Ginn wrote: > Thanks for the suggestion. My program still doesn't work yet, but I notice that /var/log/messages has: > > Jul 6 12:43:55 localhost kernel: security: context unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 is invalid > > What would make this invlaid? user-role, role-type, or user-range association is not authorized by the policy. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue Jul 7 20:03:56 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 07 Jul 2009 16:03:56 -0400 Subject: sVirt In-Reply-To: <200907071306.43499.gene@czarc.net> References: <200907041213.47694.gene@czarc.net> <200907061426.29751.gene@czarc.net> <200907071306.43499.gene@czarc.net> Message-ID: <4A53AA2C.9070303@redhat.com> On 07/07/2009 01:06 PM, Gene Czarcinski wrote: > On Monday 06 July 2009 18:22:42 James Morris wrote: >> On Mon, 6 Jul 2009, Gene Czarcinski wrote: >>> Neat! >>> >>> OK, this is starting to make more sense to me. I like the idea of using >>> the MCS policy to protect guests from each other. >> These slides from LCA should help explain the design further: >> http://namei.org/presentations/svirt-lca-2009.pdf >> >> There's also a google video of the talk: >> http://video.google.com/videoplay?docid=5750618585157629496&hl=en >> >> Dan Walsh is giving a talk on the topic at Linuxcon in September: >> http://linuxcon.linuxfoundation.org/meetings/1571 >> >> (which will be especially useful, as the code has evolved since the >> initial design). > > Thank you one and all. With the provided pointers to documentation I now have > a much better understanding of how sVirt is using MCS. > > When I originally saw that MCS was being used to restrict guest, I immediately > thought it was a static implementation but did not see anything on the virtual > disk image files so I thought it was not implemented yet. However, you use MCS > dynamically when a guest is actually run ... this makes more sense and is far > simpler to implement and manage than any static implementation.. > > I see that you "only" set categories for the virtual disk images and not the > ISO image file ... at least this is what I see and hope this is true ... > example: i OFTEN run two or three guests which booted into rescue mode from a > single netinst CD image. > > I noticed that the SELinux rule for virt_image_t allows both read and write as > it must. > > However, the SELinux rule for virt_content_t (which is used for ISO image > files) also allows both read and write ... changing this to read-only makes > more sense to me. These are the rules in F11, it only allows read # sesearch --allow -s svirt_t -t virt_content_t Found 2 semantic av rules: allow svirt_t virt_content_t : file { ioctl read getattr lock open } ; allow svirt_t virt_content_t : dir { ioctl read getattr lock search open } ; > > I still believe that sVirt should not be changing the file context for ISO > images (especially now that I see that categories are not set). One solution > which would "scratch my itch" while still doing (more or less) what is now > done is to add some global sVirt parameter to define what context to use and > have this default to virt_content_t. It would also be nice if this could be > overridden on a per-guest basis also. > > Note that I am only talking about files which would use virt_content_t since > the "static" option mentioned in a different email addresses the virtual disk > image file ... at least I think it does. > > BTW, it appears that sVirt picks a couple of non-zero random numbers to use > for the category pair. True? If true, is any checking done so there are not > any conflicts/reuse on different guests? [I am trying to avoid going to the > ultimate documentation for any software ... the source code] > Well it does check if the MCS label is unique among svirt images and it makes sure that the to numbers are different. s0:c1,c1 == so:c1 which is not allowed. > Gene > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From brian at krusic.com Tue Jul 7 20:10:52 2009 From: brian at krusic.com (Brian Krusic) Date: Tue, 7 Jul 2009 13:10:52 -0700 Subject: dump/restore EA errors Message-ID: <0CF2DF79-67BD-417F-B4E3-BE1753A771C6@krusic.com> Hi, Not sure if even this is were I should post so forgive the mis- posting. I did a search for selinux help and this is were I got. I'm running RHEL 5 and am having SE linux issues even though I have SE Linux disabled. I have basic support and they really are of no help on this matter. My scenario; RHEL 5 NFS server (although it can be a Centos NFS server or even a BlueArc). Centos 5 NFS client. Dump/Restore. From my NFS client I do; dump -f - / | restore -r -r - I can get screen loads of stuff like; restore: ./etc/ysyconfig/network-scripts/ifcfg-eth0: EA set security.selinux:system_u:object_r:etc_t:s0 failed: Operation not supported. This happens on various files in various folders. The dump/restore does complete and the files do get restored. lsattr shows nothing set on the source files and when doing it on the NFS share, I get; lsattr: Inappropriate ioctl for device While reading flags on .... (this is various dirs). Any clues are appreciated. Thanks in advance, - Brian From shintaro.fujiwara at gmail.com Tue Jul 7 21:28:13 2009 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Wed, 8 Jul 2009 06:28:13 +0900 Subject: rpm post install can't install pp files In-Reply-To: <4A51EBE5.8080501@redhat.com> References: <4A51EBE5.8080501@redhat.com> Message-ID: Well, in permissive mode, I could install my.rpm, and I found AVC messages like #============= load_policy_t ============== allow load_policy_t segatex_data_t:file write; allow load_policy_t segatex_t:fifo_file { write read }; #============= locate_t ============== allow locate_t segatex_data_t:dir open; #============= rpm_script_t ============== allow rpm_script_t segatex_data_t:dir open; #============= rpm_t ============== allow rpm_t segatex_data_t:file open; so, I think I can write interfaces allowing these permissions to segatex_t. 2009/7/6 Daniel J Walsh : > On 07/04/2009 03:09 AM, Shintaro Fujiwara wrote: >> >> Hi, when I tried to install my.pp by post install script in my.rpm, I go >> >> semodule: my.pp Failed ! >> >> But I could succeed in tar-ball file, why ? >> >> Thanks in advance. >> > Please attach the log of the failure. ?Is this during a full install? > -- http://intrajp.no-ip.com/ Home Page From dwalsh at redhat.com Tue Jul 7 21:32:04 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 07 Jul 2009 17:32:04 -0400 Subject: dump/restore EA errors In-Reply-To: <0CF2DF79-67BD-417F-B4E3-BE1753A771C6@krusic.com> References: <0CF2DF79-67BD-417F-B4E3-BE1753A771C6@krusic.com> Message-ID: <4A53BED4.3040602@redhat.com> On 07/07/2009 04:10 PM, Brian Krusic wrote: > Hi, > > Not sure if even this is were I should post so forgive the mis-posting. > I did a search for selinux help and this is were I got. > > I'm running RHEL 5 and am having SE linux issues even though I have SE > Linux disabled. > > I have basic support and they really are of no help on this matter. > > My scenario; > > RHEL 5 NFS server (although it can be a Centos NFS server or even a > BlueArc). > Centos 5 NFS client. > Dump/Restore. > > From my NFS client I do; > > dump -f - / | restore -r -r - > > I can get screen loads of stuff like; > > restore: ./etc/ysyconfig/network-scripts/ifcfg-eth0: EA set > security.selinux:system_u:object_r:etc_t:s0 failed: Operation not > supported. > > This happens on various files in various folders. > > The dump/restore does complete and the files do get restored. > > lsattr shows nothing set on the source files and when doing it on the > NFS share, I get; > > lsattr: Inappropriate ioctl for device While reading flags on .... (this > is various dirs). > > Any clues are appreciated. > > Thanks in advance, > - Brian > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Looks like restore is trying to maintain the xattrs of a previous selinux label, when the kernel sees the xattr it refuses to assign it on an NFS share since NFS does not support xattrs. From brian at krusic.com Tue Jul 7 21:38:56 2009 From: brian at krusic.com (Brian Krusic) Date: Tue, 7 Jul 2009 14:38:56 -0700 Subject: dump/restore EA errors In-Reply-To: <4A53BED4.3040602@redhat.com> References: <0CF2DF79-67BD-417F-B4E3-BE1753A771C6@krusic.com> <4A53BED4.3040602@redhat.com> Message-ID: <6F8D6B62-87C3-4E3E-B2AC-87A13EEA5022@krusic.com> On Jul 7, 2009, at 2:32 PM, Daniel J Walsh wrote: > On 07/07/2009 04:10 PM, Brian Krusic wrote: >> Hi, >> >> Not sure if even this is were I should post so forgive the mis- >> posting. >> I did a search for selinux help and this is were I got. >> >> I'm running RHEL 5 and am having SE linux issues even though I have >> SE >> Linux disabled. >> >> I have basic support and they really are of no help on this matter. >> >> My scenario; >> >> RHEL 5 NFS server (although it can be a Centos NFS server or even a >> BlueArc). >> Centos 5 NFS client. >> Dump/Restore. >> >> From my NFS client I do; >> >> dump -f - / | restore -r -r - >> >> I can get screen loads of stuff like; >> >> restore: ./etc/ysyconfig/network-scripts/ifcfg-eth0: EA set >> security.selinux:system_u:object_r:etc_t:s0 failed: Operation not >> supported. >> >> This happens on various files in various folders. >> >> The dump/restore does complete and the files do get restored. >> >> lsattr shows nothing set on the source files and when doing it on the >> NFS share, I get; >> >> lsattr: Inappropriate ioctl for device While reading flags on .... >> (this >> is various dirs). >> >> Any clues are appreciated. >> >> Thanks in advance, >> - Brian >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Looks like restore is trying to maintain the xattrs of a previous > selinux label, when the kernel sees the xattr it refuses to assign > it on an NFS share since NFS does not support xattrs. > > Hi Daniel, A few things; 1 - When doing an lsxattr, I don't see any thing other then ------------ which tells me that no extended attributes exist for that file. 2 - How do I remove any selinux lables since I don't use or need selinux? From dwalsh at redhat.com Wed Jul 8 10:23:01 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 08 Jul 2009 06:23:01 -0400 Subject: dump/restore EA errors In-Reply-To: <6F8D6B62-87C3-4E3E-B2AC-87A13EEA5022@krusic.com> References: <0CF2DF79-67BD-417F-B4E3-BE1753A771C6@krusic.com> <4A53BED4.3040602@redhat.com> <6F8D6B62-87C3-4E3E-B2AC-87A13EEA5022@krusic.com> Message-ID: <4A547385.1080403@redhat.com> On 07/07/2009 05:38 PM, Brian Krusic wrote: > On Jul 7, 2009, at 2:32 PM, Daniel J Walsh wrote: > >> On 07/07/2009 04:10 PM, Brian Krusic wrote: >>> Hi, >>> >>> Not sure if even this is were I should post so forgive the mis-posting. >>> I did a search for selinux help and this is were I got. >>> >>> I'm running RHEL 5 and am having SE linux issues even though I have SE >>> Linux disabled. >>> >>> I have basic support and they really are of no help on this matter. >>> >>> My scenario; >>> >>> RHEL 5 NFS server (although it can be a Centos NFS server or even a >>> BlueArc). >>> Centos 5 NFS client. >>> Dump/Restore. >>> >>> From my NFS client I do; >>> >>> dump -f - / | restore -r -r - >>> >>> I can get screen loads of stuff like; >>> >>> restore: ./etc/ysyconfig/network-scripts/ifcfg-eth0: EA set >>> security.selinux:system_u:object_r:etc_t:s0 failed: Operation not >>> supported. >>> >>> This happens on various files in various folders. >>> >>> The dump/restore does complete and the files do get restored. >>> >>> lsattr shows nothing set on the source files and when doing it on the >>> NFS share, I get; >>> >>> lsattr: Inappropriate ioctl for device While reading flags on .... (this >>> is various dirs). >>> >>> Any clues are appreciated. >>> >>> Thanks in advance, >>> - Brian >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> Looks like restore is trying to maintain the xattrs of a previous >> selinux label, when the kernel sees the xattr it refuses to assign it >> on an NFS share since NFS does not support xattrs. >> >> > > Hi Daniel, > > A few things; > > 1 - When doing an lsxattr, I don't see any thing other then ------------ > which tells me that no extended attributes exist for that file. > > 2 - How do I remove any selinux lables since I don't use or need selinux? > I am not sure there is a good way to remove them, or if it is worth it. Try > getfattr -n security.selinux /etc To see if you have labeled. I guess you could try > setfattr -x security.selinux /etc To remove. From brian at krusic.com Wed Jul 8 17:33:11 2009 From: brian at krusic.com (Brian Krusic) Date: Wed, 8 Jul 2009 10:33:11 -0700 Subject: removing context Message-ID: Hi, When doing an ls -lZ, some files show a security context like; root:object_r:user_home_t:s0 ... while some don't. Does any one know how to remove this context either on a file, dir or file system level? This would solve my dump/restore issue as even though they work, dump level 9 for example is being treated as a 0 because of the error. - Brian From BGinn at symark.com Wed Jul 8 17:48:17 2009 From: BGinn at symark.com (Brian Ginn) Date: Wed, 8 Jul 2009 10:48:17 -0700 Subject: getpwnam and SELinux In-Reply-To: <1246994658.28321.285.camel@moss-pluto.epoch.ncsc.mil> References: <8F43ACC6DCEECD4FA252B8042E2C4B8B9F3288E0B4@dragonfly.symark.com> <1246535569.13464.237.camel@moss-pluto.epoch.ncsc.mil> <8F43ACC6DCEECD4FA252B8042E2C4B8B9F650D8714@dragonfly.symark.com> <1246967825.28321.164.camel@moss-pluto.epoch.ncsc.mil> <8F43ACC6DCEECD4FA252B8042E2C4B8B9F650D8718@dragonfly.symark.com> <1246994658.28321.285.camel@moss-pluto.epoch.ncsc.mil> Message-ID: <8F43ACC6DCEECD4FA252B8042E2C4B8B9F650D871C@dragonfly.symark.com> Thanks again! I got that last problem solved. My confined program now works on RHEL5.3. Fedora 9, on the other hand, always returns x, even when not enforcing and not confined. That doesn't seem to be an SELinux issue. -Brian -----Original Message----- From: Stephen Smalley [mailto:sds at tycho.nsa.gov] Sent: Tuesday, July 07, 2009 12:24 PM To: Brian Ginn Cc: 'fedora-selinux-list at redhat.com'; Joshua Brindle Subject: RE: getpwnam and SELinux On Tue, 2009-07-07 at 12:04 -0700, Brian Ginn wrote: > Thanks for the suggestion. My program still doesn't work yet, but I notice that /var/log/messages has: > > Jul 6 12:43:55 localhost kernel: security: context unconfined_u:unconfined_r:t_getpw_t:s0-s0:c0.c1023 is invalid > > What would make this invlaid? user-role, role-type, or user-range association is not authorized by the policy. -- Stephen Smalley National Security Agency From mike.cloaked at gmail.com Wed Jul 8 19:19:20 2009 From: mike.cloaked at gmail.com (Mike Cloaked) Date: Wed, 8 Jul 2009 12:19:20 -0700 (PDT) Subject: removing context In-Reply-To: References: Message-ID: <24397663.post@talk.nabble.com> Brian Krusic wrote: > > Hi, > > When doing an ls -lZ, some files show a security context like; > > root:object_r:user_home_t:s0 > > ... while some don't. > > Does any one know how to remove this context either on a file, dir or > file system level? > > Why do you want to remove them - if selinux is enforcing (as it should be in an up to date version of Fedora ) then all files should have a context and your best security is when selinux is set up correctly to work with your system. In F10 selinux did have a number of tweaks needed to get it going but in F11 it is likely to need very few tweaks. -- View this message in context: http://www.nabble.com/removing-context-tp24396015p24397663.html Sent from the Fedora SELinux List mailing list archive at Nabble.com. From brian at krusic.com Wed Jul 8 19:27:09 2009 From: brian at krusic.com (Brian Krusic) Date: Wed, 8 Jul 2009 12:27:09 -0700 Subject: removing context In-Reply-To: <24397663.post@talk.nabble.com> References: <24397663.post@talk.nabble.com> Message-ID: <4403FCED-E9D4-4929-A8BD-0A4143BACA66@krusic.com> On Jul 8, 2009, at 12:19 PM, Mike Cloaked wrote: > > > > Brian Krusic wrote: >> >> Hi, >> >> When doing an ls -lZ, some files show a security context like; >> >> root:object_r:user_home_t:s0 >> >> ... while some don't. >> >> Does any one know how to remove this context either on a file, dir or >> file system level? >> >> > > Why do you want to remove them - if selinux is enforcing (as it > should be in > an up to date version of Fedora ) then all files should have a > context and > your best security is when selinux is set up correctly to work with > your > system. In F10 selinux did have a number of tweaks needed to get it > going > but in F11 it is likely to need very few tweaks. > -- > View this message in context: http://www.nabble.com/removing-context-tp24396015p24397663.html > Sent from the Fedora SELinux List mailing list archive at Nabble.com. I'm glad you asked the question. I have selinux disabled first and foremost. However the context labels still exist on some files which cause a problem doing dump/restore over NFS. Let me explain; While dump/restore works over NFS in general, they don't work with selinux context so I keep getting errors like; restore: ./etc/ysyconfig/network-scripts/ifcfg-eth0: EA set security.selinux:system_u:object_r:etc_t:s0 failed: Operation not supported. And while the dump/restore works and the files get copied, this error causes my incremental backs to work as full backups. Also, this muddies my log files which i rely on. Image half the files on the system kicking out this error. Thanks in advance, - Brian > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dpquigl at tycho.nsa.gov Wed Jul 8 19:34:54 2009 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Wed, 08 Jul 2009 15:34:54 -0400 Subject: removing context In-Reply-To: <4403FCED-E9D4-4929-A8BD-0A4143BACA66@krusic.com> References: <24397663.post@talk.nabble.com> <4403FCED-E9D4-4929-A8BD-0A4143BACA66@krusic.com> Message-ID: <1247081694.4398.133.camel@localhost> On Wed, 2009-07-08 at 12:27 -0700, Brian Krusic wrote: > On Jul 8, 2009, at 12:19 PM, Mike Cloaked wrote: > > > > > > > > > Brian Krusic wrote: > >> > >> Hi, > >> > >> When doing an ls -lZ, some files show a security context like; > >> > >> root:object_r:user_home_t:s0 > >> > >> ... while some don't. > >> > >> Does any one know how to remove this context either on a file, dir or > >> file system level? > >> > >> > > > > Why do you want to remove them - if selinux is enforcing (as it > > should be in > > an up to date version of Fedora ) then all files should have a > > context and > > your best security is when selinux is set up correctly to work with > > your > > system. In F10 selinux did have a number of tweaks needed to get it > > going > > but in F11 it is likely to need very few tweaks. > > -- > > View this message in context: http://www.nabble.com/removing-context-tp24396015p24397663.html > > Sent from the Fedora SELinux List mailing list archive at Nabble.com. > > I'm glad you asked the question. > > I have selinux disabled first and foremost. > > However the context labels still exist on some files which cause a > problem doing dump/restore over NFS. > > Let me explain; > > While dump/restore works over NFS in general, they don't work with > selinux context so I keep getting errors like; > > restore: ./etc/ysyconfig/network-scripts/ifcfg-eth0: EA set > security.selinux:system_u:object_r:etc_t:s0 failed: Operation not > supported. > > And while the dump/restore works and the files get copied, this error > causes my incremental backs to work as full backups. Also, this > muddies my log files which i rely on. Image half the files on the > system kicking out this error. > > Thanks in advance, > - Brian > > > > > > > > > > -- > > 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 Have you tried something like cd / find . -exec setfattr -h -x security.selinux '{}'\; I know on an SELinux enabled system this will fail because you can't outright remove the security.selinux xattr but if it falls back to the generic xattr handlers it should be allowed. I'm not sure how the exec directive will handle the -h and -x options so you may have to fiddle with that. - Dave From brian at krusic.com Wed Jul 8 20:41:09 2009 From: brian at krusic.com (Brian Krusic) Date: Wed, 8 Jul 2009 13:41:09 -0700 Subject: removing context In-Reply-To: <1247081694.4398.133.camel@localhost> References: <24397663.post@talk.nabble.com> <4403FCED-E9D4-4929-A8BD-0A4143BACA66@krusic.com> <1247081694.4398.133.camel@localhost> Message-ID: Wow and I mean Wow! Yoda mang! Basically; find . -exec setfattr -h -x security.selinux '{}' \; ... worked!!! The only diff and it may have been email formatting was there needs to be a space between "{}' and \; at the end of the command. Thanks a lot David! - Brian On Jul 8, 2009, at 12:34 PM, David P. Quigley wrote: > On Wed, 2009-07-08 at 12:27 -0700, Brian Krusic wrote: >> On Jul 8, 2009, at 12:19 PM, Mike Cloaked wrote: >> >>> >>> >>> >>> Brian Krusic wrote: >>>> >>>> Hi, >>>> >>>> When doing an ls -lZ, some files show a security context like; >>>> >>>> root:object_r:user_home_t:s0 >>>> >>>> ... while some don't. >>>> >>>> Does any one know how to remove this context either on a file, >>>> dir or >>>> file system level? >>>> >>>> >>> >>> Why do you want to remove them - if selinux is enforcing (as it >>> should be in >>> an up to date version of Fedora ) then all files should have a >>> context and >>> your best security is when selinux is set up correctly to work with >>> your >>> system. In F10 selinux did have a number of tweaks needed to get it >>> going >>> but in F11 it is likely to need very few tweaks. >>> -- >>> View this message in context: http://www.nabble.com/removing-context-tp24396015p24397663.html >>> Sent from the Fedora SELinux List mailing list archive at >>> Nabble.com. >> >> I'm glad you asked the question. >> >> I have selinux disabled first and foremost. >> >> However the context labels still exist on some files which cause a >> problem doing dump/restore over NFS. >> >> Let me explain; >> >> While dump/restore works over NFS in general, they don't work with >> selinux context so I keep getting errors like; >> >> restore: ./etc/ysyconfig/network-scripts/ifcfg-eth0: EA set >> security.selinux:system_u:object_r:etc_t:s0 failed: Operation not >> supported. >> >> And while the dump/restore works and the files get copied, this error >> causes my incremental backs to work as full backups. Also, this >> muddies my log files which i rely on. Image half the files on the >> system kicking out this error. >> >> Thanks in advance, >> - Brian >> >> >> >> >>> >>> >>> -- >>> 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 > > > Have you tried something like > > cd / > find . -exec setfattr -h -x security.selinux '{}'\; > > I know on an SELinux enabled system this will fail because you can't > outright remove the security.selinux xattr but if it falls back to the > generic xattr handlers it should be allowed. I'm not sure how the exec > directive will handle the -h and -x options so you may have to fiddle > with that. > > - Dave > From sradvan at redhat.com Thu Jul 9 03:15:08 2009 From: sradvan at redhat.com (Scott Radvan) Date: Thu, 9 Jul 2009 13:15:08 +1000 Subject: selinux and rsync Message-ID: <20090709131508.487c7351@redhat.com> Hi all, Having a bit of trouble with rsync on F11 for the managing confined services book I am working on. I am trying to demonstrate the allow_rsync_anon_write boolean as a configuration example by invoking a denial and detailing the subsequent work-around, but rsyncd is happily letting me anonymously read and write files across the network no matter the state of the boolean. The default install of F11 I'm using as a server has a simple 'files' rsyncd module (in daemon mode) set up in rsyncd.conf which by itself should allow access anonymously, but my understanding is that SELinux should still over-ride this and stop anonymous writes even with this loose rsyncd setup. /etc/rsyncd.conf: log file = /var/log/rsyncd.log pid file = /var/run/rsyncd.pid local file = /var/run/rsync.lock [files] path = /srv/files comment = file area read only = false >From the F11 client: $ rsync -avHPAX 100M_file ::files sending incremental file list 100M_file 104857600 100% 52.37MB/s 0:00:01 (xfer#1, to-check=0/1) sent 104870493 bytes received 27 bytes 41948208.00 bytes/sec total size is 104857600 speedup is 1.00 $ My rsync command is entered so that it will preserve extended attributes (-X) and ACLs (-A), as shown in rsync(1). But I am getting no denials or errors, SELinux does not seem to be having a problem with me doing anonymous writes/reads with allow_rsync_anon_write --> off Perhaps I'm doing something wrong altogether, or misinterpreting this boolean, but I would have thought SELinux would have a problem with me performing this rsync operation while that boolean is off. Further, rsync_selinux(8) says: "SELinux requires files to have an extended attribute to define the file type. Policy governs the access daemons have to these files. If you want to share files using the rsync daemon, you must label the files and directories public_content_t" But my manually-created path for rsync files is var_t, as is the file I copied over, with no denial mentioning public_content_t - is this man page out of date? My problem is that it all works too easily! I would have thought SELinux would not at all be happy with what I'm doing, but I'm yet to get a single denial. What am I doing wrong? Thanks, -- Scott Radvan Content Author, Platform (Installation and Deployment) Red Hat Asia Pacific (Brisbane) http://www.apac.redhat.com From paul at city-fan.org Thu Jul 9 06:19:52 2009 From: paul at city-fan.org (Paul Howarth) Date: Thu, 9 Jul 2009 07:19:52 +0100 Subject: selinux and rsync In-Reply-To: <20090709131508.487c7351@redhat.com> References: <20090709131508.487c7351@redhat.com> Message-ID: <20090709071952.3b14bff0@metropolis.intra.city-fan.org> On Thu, 9 Jul 2009 13:15:08 +1000 Scott Radvan wrote: > Hi all, > > > Having a bit of trouble with rsync on F11 for the managing confined > services book I am working on. > > I am trying to demonstrate the allow_rsync_anon_write boolean as a > configuration example by invoking a denial and detailing the > subsequent work-around, but rsyncd is happily letting me anonymously > read and write files across the network no matter the state of the > boolean. > > The default install of F11 I'm using as a server has a simple 'files' > rsyncd module (in daemon mode) set up in rsyncd.conf which by itself > should allow access anonymously, but my understanding is that SELinux > should still over-ride this and stop anonymous writes even with this > loose rsyncd setup. > > /etc/rsyncd.conf: > > log file = /var/log/rsyncd.log > pid file = /var/run/rsyncd.pid > local file = /var/run/rsync.lock > > [files] > path = /srv/files > comment = file area > read only = false > > > >From the F11 client: > > $ rsync -avHPAX 100M_file ::files > sending incremental file list > 100M_file > 104857600 100% 52.37MB/s 0:00:01 (xfer#1, to-check=0/1) > > sent 104870493 bytes received 27 bytes 41948208.00 bytes/sec > total size is 104857600 speedup is 1.00 > > $ > > My rsync command is entered so that it will preserve extended > attributes (-X) and ACLs (-A), as shown in rsync(1). > > But I am getting no denials or errors, SELinux does not seem to be > having a problem with me doing anonymous writes/reads with > allow_rsync_anon_write --> off > > Perhaps I'm doing something wrong altogether, or misinterpreting this > boolean, but I would have thought SELinux would have a problem with me > performing this rsync operation while that boolean is off. > > Further, rsync_selinux(8) says: > > "SELinux requires files to have an extended attribute to define the > file type. Policy governs the access daemons have to these files. If > you want to share files using the rsync daemon, you must label the > files and directories public_content_t" > > But my manually-created path for rsync files is var_t, as is the file > I copied over, with no denial mentioning public_content_t - is this > man page out of date? > > My problem is that it all works too easily! I would have thought > SELinux would not at all be happy with what I'm doing, but I'm yet to > get a single denial. The boolean controls the rsync daemon's ability to write to public_content_rw_t files. The "anon" part of the boolean's name is historical baggage really - it's nothing to do with how the rsync daemon's authentication is set up. Paul. From dhighley at highley-recommended.com Thu Jul 9 19:36:21 2009 From: dhighley at highley-recommended.com (David Highley) Date: Thu, 9 Jul 2009 12:36:21 -0700 (PDT) Subject: Question about split betweeen delivered and local policy Message-ID: <200907091936.n69JaLdn007622@douglas.highley-recommended.com> Seems with every new version of Fedora there are several modifications to selinux policy that we need to do. So were trying to understand where the split is between creating a bug report and when we need to create local policy modifications. For example, email seems to always need selinux policy changes so that avc's are not blocking spamassassin and pyzor. We did a tar with option --xattrs on a Fedora 10 system for home directories and were not able to restore the tar on a Fedora 11 until we did a policy change. Still ended up needing to a restorecon on the home directories. We wonder if poking these holes in the delivered policies is the correct fix or are we opening up unnecessary security holes. From fdsubs at t-online.hu Thu Jul 9 19:51:59 2009 From: fdsubs at t-online.hu (Daniel Fazekas) Date: Thu, 9 Jul 2009 21:51:59 +0200 Subject: Question about split betweeen delivered and local policy In-Reply-To: <200907091936.n69JaLdn007622@douglas.highley-recommended.com> References: <200907091936.n69JaLdn007622@douglas.highley-recommended.com> Message-ID: <87A3E7E8-E32D-4654-BB19-F3F9FF7EE3CE@t-online.hu> On Jul 9, 2009, at 21:36, David Highley wrote: > For example, email seems to always need selinux policy changes so > that avc's are not blocking spamassassin and pyzor. SpamAssassin and Pyzor should be working fine without any further tweaking since some Fedora releases ago. Some time around Fedora 8 or 9. Are you using the spamassassin service (spamd)? Are the relevant spamassassin selinux bools enabled? # getsebool -a | grep spam spamassassin_can_network --> on spamd_enable_home_dirs --> on If they still don't work properly this way, you should check if the contexts went wrong with some files in the home directories. restorecon -Rv /root /home I think if you aren't doing anything unusual yet basic packages break, the recommended course of action is to file a Bugzilla report rather than try and patch it with your custom local policy. From dwalsh at redhat.com Thu Jul 9 21:07:49 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 09 Jul 2009 17:07:49 -0400 Subject: Question about split betweeen delivered and local policy In-Reply-To: <87A3E7E8-E32D-4654-BB19-F3F9FF7EE3CE@t-online.hu> References: <200907091936.n69JaLdn007622@douglas.highley-recommended.com> <87A3E7E8-E32D-4654-BB19-F3F9FF7EE3CE@t-online.hu> Message-ID: <4A565C25.9050105@redhat.com> On 07/09/2009 03:51 PM, Daniel Fazekas wrote: > On Jul 9, 2009, at 21:36, David Highley wrote: > >> For example, email seems to always need selinux policy changes so that >> avc's are not blocking spamassassin and pyzor. > > SpamAssassin and Pyzor should be working fine without any further > tweaking since some Fedora releases ago. Some time around Fedora 8 or 9. > > Are you using the spamassassin service (spamd)? > Are the relevant spamassassin selinux bools enabled? > > # getsebool -a | grep spam > spamassassin_can_network --> on > spamd_enable_home_dirs --> on > > If they still don't work properly this way, you should check if the > contexts went wrong with some files in the home directories. > restorecon -Rv /root /home > > I think if you aren't doing anything unusual yet basic packages break, > the recommended course of action is to file a Bugzilla report rather > than try and patch it with your custom local policy. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Well as we move forward we are putting more and more labels in the homedir. So just maintaining the labels on the Homedir, from Previous to new is not going to work. If we ever want to get confined user applications to work in the homedir, we got to get a mechanism to set these labels at creation time. In Rawhide right now, I have a restorecond running in user space watching for creation of files in the homedir to make sure they are labeled correct. So if a user just executes mkdir .ssh or mkdir public_html it gets labeled correctly without the user having to be an SELinux expert. Similarly tools like firefox/nsplugin and other tools rely on the homedir being correctly labeled to add confinement. From dhighley at highley-recommended.com Fri Jul 10 05:05:31 2009 From: dhighley at highley-recommended.com (David Highley) Date: Thu, 9 Jul 2009 22:05:31 -0700 (PDT) Subject: Question about split betweeen delivered and local policy In-Reply-To: <4A565C25.9050105@redhat.com> Message-ID: <200907100505.n6A55Vxj012518@douglas.highley-recommended.com> "Daniel J Walsh wrote:" > > On 07/09/2009 03:51 PM, Daniel Fazekas wrote: > > On Jul 9, 2009, at 21:36, David Highley wrote: > > > >> For example, email seems to always need selinux policy changes so that > >> avc's are not blocking spamassassin and pyzor. > > > > SpamAssassin and Pyzor should be working fine without any further > > tweaking since some Fedora releases ago. Some time around Fedora 8 or 9. > > > > Are you using the spamassassin service (spamd)? > > Are the relevant spamassassin selinux bools enabled? > > > > # getsebool -a | grep spam > > spamassassin_can_network --> on > > spamd_enable_home_dirs --> on > > > > If they still don't work properly this way, you should check if the > > contexts went wrong with some files in the home directories. > > restorecon -Rv /root /home > > > > I think if you aren't doing anything unusual yet basic packages break, > > the recommended course of action is to file a Bugzilla report rather > > than try and patch it with your custom local policy. > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Well as we move forward we are putting more and more labels in the homedir. So just maintaining the labels on the Homedir, from Previous to new is not going to work. > > If we ever want to get confined user applications to work in the homedir, we got to get a mechanism to set these labels at creation time. In Rawhide right now, I have a restorecond running in user space watching for creation of files in the homedir to make sure they are labeled correct. So if a user just executes mkdir .ssh or mkdir public_html it gets labeled correctly without the user having to be an SELinux expert. Similarly tools like firefox/nsplugin and other tools rely on the homedir being correctly labeled to add confinement. I agree, home directories are problematic. I submitted 5 bug reports. There were some avc's that I did not submit as they maybe tied up in the gdm respawing bug 499489. Installed the unreleased patch which fixed the issue of not being able to log in and I'm not seeing the avc's that were occurring. Is there away to un-compile the policies we created? Thought it might be of interest to post or provide for the bug reports. I'm assuming that we would just remove the policy file if we wanted to revert back after if new policy updates fix issues we have ran into. Also needed to do label changes for the Mythtv packages from the rpmfusion repo to get the web interface to work. These are new packages, we will provide feed back to them. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From paul at city-fan.org Fri Jul 10 07:58:06 2009 From: paul at city-fan.org (Paul Howarth) Date: Fri, 10 Jul 2009 08:58:06 +0100 Subject: dhclient denial F-11 Message-ID: <4A56F48E.7000009@city-fan.org> I get one of these every time my DHCP lease is renewed: type=AVC msg=audit(1247181873.317:23522): avc: denied { create } for pid=31499 comm="mv" name="yp.conf.predhclient.br0" scontext=unconfined_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:net_conf_t:s0 tclass=file type=SYSCALL msg=audit(1247181873.317:23522): arch=c000003e syscall=2 success=no exit=-13 a0=7fff9e36ebcc a1=c1 a2=180 a3=65726373662f7274 items=0 ppid=31485 pid=31499 auid=1012 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="mv" exe="/bin/mv" subj=unconfined_u:system_r:dhcpc_t:s0 key=(null) It originates from /etc/dhcp/dhclient.d/nis.sh in the ypbind package. Paul.. From dwalsh at redhat.com Fri Jul 10 12:41:09 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 10 Jul 2009 08:41:09 -0400 Subject: Question about split betweeen delivered and local policy In-Reply-To: <200907100505.n6A55Vxj012518@douglas.highley-recommended.com> References: <200907100505.n6A55Vxj012518@douglas.highley-recommended.com> Message-ID: <4A5736E5.30703@redhat.com> On 07/10/2009 01:05 AM, David Highley wrote: > "Daniel J Walsh wrote:" >> On 07/09/2009 03:51 PM, Daniel Fazekas wrote: >>> On Jul 9, 2009, at 21:36, David Highley wrote: >>> >>>> For example, email seems to always need selinux policy changes so that >>>> avc's are not blocking spamassassin and pyzor. >>> SpamAssassin and Pyzor should be working fine without any further >>> tweaking since some Fedora releases ago. Some time around Fedora 8 or 9. >>> >>> Are you using the spamassassin service (spamd)? >>> Are the relevant spamassassin selinux bools enabled? >>> >>> # getsebool -a | grep spam >>> spamassassin_can_network --> on >>> spamd_enable_home_dirs --> on >>> >>> If they still don't work properly this way, you should check if the >>> contexts went wrong with some files in the home directories. >>> restorecon -Rv /root /home >>> >>> I think if you aren't doing anything unusual yet basic packages break, >>> the recommended course of action is to file a Bugzilla report rather >>> than try and patch it with your custom local policy. >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> Well as we move forward we are putting more and more labels in the homedir. So just maintaining the labels on the Homedir, from Previous to new is not going to work. >> >> If we ever want to get confined user applications to work in the homedir, we got to get a mechanism to set these labels at creation time. In Rawhide right now, I have a restorecond running in user space watching for creation of files in the homedir to make sure they are labeled correct. So if a user just executes mkdir .ssh or mkdir public_html it gets labeled correctly without the user having to be an SELinux expert. Similarly tools like firefox/nsplugin and other tools rely on the homedir being correctly labeled to add confinement. > > I agree, home directories are problematic. I submitted 5 bug reports. > There were some avc's that I did not submit as they maybe tied up in the > gdm respawing bug 499489. Installed the unreleased patch which fixed the > issue of not being able to log in and I'm not seeing the avc's that were > occurring. > > Is there away to un-compile the policies we created? Thought it might be > of interest to post or provide for the bug reports. I'm assuming that we > would just remove the policy file if we wanted to revert back after if > new policy updates fix issues we have ran into. semodule -r YOURPOL Will remove a policy module. > > Also needed to do label changes for the Mythtv packages from the > rpmfusion repo to get the web interface to work. These are new packages, > we will provide feed back to them. > Send me the new labels. >> -- >> 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 dwalsh at redhat.com Fri Jul 10 12:50:25 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 10 Jul 2009 08:50:25 -0400 Subject: dhclient denial F-11 In-Reply-To: <4A56F48E.7000009@city-fan.org> References: <4A56F48E.7000009@city-fan.org> Message-ID: <4A573911.5060109@redhat.com> On 07/10/2009 03:58 AM, Paul Howarth wrote: > I get one of these every time my DHCP lease is renewed: > > type=AVC msg=audit(1247181873.317:23522): avc: denied { create } for > pid=31499 comm="mv" name="yp.conf.predhclient.br0" > scontext=unconfined_u:system_r:dhcpc_t:s0 > tcontext=system_u:object_r:net_conf_t:s0 tclass=file > type=SYSCALL msg=audit(1247181873.317:23522): arch=c000003e syscall=2 > success=no exit=-13 a0=7fff9e36ebcc a1=c1 a2=180 a3=65726373662f7274 > items=0 ppid=31485 pid=31499 auid=1012 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="mv" exe="/bin/mv" > subj=unconfined_u:system_r:dhcpc_t:s0 key=(null) > > It originates from /etc/dhcp/dhclient.d/nis.sh in the ypbind package. > > Paul.. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list That is a new one, looks like you started dhclient by hand, and it is running as unconfined_u:system_r:dhcpc_t:s0, But some where in the tool it is trying to create a file labeled system_u:object_r:net_conf_t:s0 unconfined_u creating a file with a user type of system_u is a constraint violation. The mv command tries to maintain the context of the context of the yp.conf.predhclient.br0 file which must have been created by dhclient when it was run as a service, so you get this denial. So I guess we need to allow dhcpc_t the ability to change the user componant of a file. Who said SELinux is not simple... :^( If you add the following in a module it should allow your app to work. domain_obj_id_change_exemption(dhcpc_t) Miroslav can you add this to sysnetwork.te for F10, F11. From paul at city-fan.org Fri Jul 10 13:03:54 2009 From: paul at city-fan.org (Paul Howarth) Date: Fri, 10 Jul 2009 14:03:54 +0100 Subject: dhclient denial F-11 In-Reply-To: <4A573911.5060109@redhat.com> References: <4A56F48E.7000009@city-fan.org> <4A573911.5060109@redhat.com> Message-ID: <4A573C3A.1090802@city-fan.org> On 10/07/09 13:50, Daniel J Walsh wrote: > On 07/10/2009 03:58 AM, Paul Howarth wrote: >> I get one of these every time my DHCP lease is renewed: >> >> type=AVC msg=audit(1247181873.317:23522): avc: denied { create } for >> pid=31499 comm="mv" name="yp.conf.predhclient.br0" >> scontext=unconfined_u:system_r:dhcpc_t:s0 >> tcontext=system_u:object_r:net_conf_t:s0 tclass=file >> type=SYSCALL msg=audit(1247181873.317:23522): arch=c000003e syscall=2 >> success=no exit=-13 a0=7fff9e36ebcc a1=c1 a2=180 a3=65726373662f7274 >> items=0 ppid=31485 pid=31499 auid=1012 uid=0 gid=0 euid=0 suid=0 fsuid=0 >> egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="mv" exe="/bin/mv" >> subj=unconfined_u:system_r:dhcpc_t:s0 key=(null) >> >> It originates from /etc/dhcp/dhclient.d/nis.sh in the ypbind package. >> >> Paul.. >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > That is a new one, looks like you started dhclient by hand, and it is > running as unconfined_u:system_r:dhcpc_t:s0, But some where in the tool > it is trying to create a file labeled system_u:object_r:net_conf_t:s0 > > unconfined_u creating a file with a user type of system_u is a > constraint violation. > > The mv command tries to maintain the context of the context of the > yp.conf.predhclient.br0 file which must have been created by dhclient > when it was run as a service, so you get this denial. > > So I guess we need to allow dhcpc_t the ability to change the user > componant of a file. > > Who said SELinux is not simple... :^( I seem to have a lot of processes like this: # ps uaxZ|grep unconfined_u:system_r: unconfined_u:system_r:auditd_t:s0 root 701 0.0 0.0 27464 428 ? S References: <4A56F48E.7000009@city-fan.org> <4A573911.5060109@redhat.com> <4A573C3A.1090802@city-fan.org> Message-ID: <4A574646.2030907@redhat.com> On 07/10/2009 09:03 AM, Paul Howarth wrote: > On 10/07/09 13:50, Daniel J Walsh wrote: >> On 07/10/2009 03:58 AM, Paul Howarth wrote: >>> I get one of these every time my DHCP lease is renewed: >>> >>> type=AVC msg=audit(1247181873.317:23522): avc: denied { create } for >>> pid=31499 comm="mv" name="yp.conf.predhclient.br0" >>> scontext=unconfined_u:system_r:dhcpc_t:s0 >>> tcontext=system_u:object_r:net_conf_t:s0 tclass=file >>> type=SYSCALL msg=audit(1247181873.317:23522): arch=c000003e syscall=2 >>> success=no exit=-13 a0=7fff9e36ebcc a1=c1 a2=180 a3=65726373662f7274 >>> items=0 ppid=31485 pid=31499 auid=1012 uid=0 gid=0 euid=0 suid=0 fsuid=0 >>> egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="mv" exe="/bin/mv" >>> subj=unconfined_u:system_r:dhcpc_t:s0 key=(null) >>> >>> It originates from /etc/dhcp/dhclient.d/nis.sh in the ypbind package. >>> >>> Paul.. >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> That is a new one, looks like you started dhclient by hand, and it is >> running as unconfined_u:system_r:dhcpc_t:s0, But some where in the tool >> it is trying to create a file labeled system_u:object_r:net_conf_t:s0 >> >> unconfined_u creating a file with a user type of system_u is a >> constraint violation. >> >> The mv command tries to maintain the context of the context of the >> yp.conf.predhclient.br0 file which must have been created by dhclient >> when it was run as a service, so you get this denial. >> >> So I guess we need to allow dhcpc_t the ability to change the user >> componant of a file. >> >> Who said SELinux is not simple... :^( > > I seem to have a lot of processes like this: > > # ps uaxZ|grep unconfined_u:system_r: > unconfined_u:system_r:auditd_t:s0 root 701 0.0 0.0 27464 428 ? S Jun24 0:00 auditd > unconfined_u:system_r:audisp_t:s0 root 703 0.0 0.0 81920 420 ? S Jun24 0:00 /sbin/audispd > unconfined_u:system_r:audisp_t:s0 root 704 0.0 0.0 97764 648 ? S< Jun24 > 0:00 /usr/sbin/sedispatch > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 5678 0.0 0.0 > 89008 788 pts/0 S+ 14:00 0:00 grep unconfined_u:system_r: > unconfined_u:system_r:ntpd_t:s0 ntp 5700 0.0 0.0 58984 696 ? Ss Jun23 > 0:04 ntpd -u ntp:ntp -p /var/run/ntpd.pid -g > unconfined_u:system_r:dhcpc_t:s0 root 5702 0.0 0.0 6856 356 ? Ss Jun23 > 0:00 /sbin/dhclient -1 -q -lf /var/lib/dhclient/dhclient-br0.leases -pf > /var/run/dhclient-br0.pid br0 > unconfined_u:system_r:virtd_t:s0-s0:c0.c1023 root 5835 0.3 0.1 466888 > 2844 ? Sl Jun23 74:12 libvirtd --daemon > unconfined_u:system_r:dnsmasq_t:s0-s0:c0.c1023 nobody 5895 0.0 0.0 12584 > 300 ? S Jun23 0:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces > --pid-file=/var/run/libvirt/network/default.pid --conf-file= > --listen-address 192.168.122.1 --except-interface lo --dhcp-range > 192.168.122.2,192.168.122.254 > unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 root 9606 0.0 0.0 63236 312 > ? Ss Jun23 0:00 /usr/sbin/sshd > unconfined_u:system_r:avahi_t:s0 avahi 9690 0.0 0.0 60036 912 ? Ss Jul01 > 0:00 avahi-daemon: registering [roary.local] > unconfined_u:system_r:avahi_t:s0 avahi 9691 0.0 0.0 59868 156 ? Ss Jul01 > 0:00 avahi-daemon: chroot helper > unconfined_u:system_r:rpcbind_t:s0 rpc 17479 0.0 0.0 18788 308 ? Ss > Jun29 0:00 rpcbind -w > unconfined_u:system_r:crond_t:s0-s0:c0.c1023 root 17538 0.0 0.0 100292 > 464 ? Ss Jun29 0:02 crond > > Why are some processes starting in system_u and some in unconfined_u? > I'm always mindful to do "service xyz restart" rather than starting > things manually. It's not just one machine either. > > Paul. > > > If you execute service xyz restart, xyz will run as unconfined_u, if the system does it at boot it will run as system_u. You can use run_init if you choose to get it to run as system_u run_init service xyz restart (If you want to use this form, put pam_rootok in /etc/pam.d/run_init, for you sanity. :^)) From Robert.Story at cobham.com Fri Jul 10 17:29:14 2009 From: Robert.Story at cobham.com (Robert Story) Date: Fri, 10 Jul 2009 13:29:14 -0400 Subject: dhclient denial F-11 In-Reply-To: <4A574646.2030907@redhat.com> References: <4A56F48E.7000009@city-fan.org> <4A573911.5060109@redhat.com> <4A573C3A.1090802@city-fan.org> <4A574646.2030907@redhat.com> Message-ID: <20090710132914.3252c93a@sparta.com> On Fri, 10 Jul 2009 09:46:46 -0400 Daniel wrote: DJW> If you execute service xyz restart, xyz will run as unconfined_u, if the DJW> system does it at boot it will run as system_u. You can use run_init if DJW> you choose to get it to run as system_u I've always wondered why service doesn't check for selinux and re-run itself via run_init... -- Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dwalsh at redhat.com Fri Jul 10 19:50:25 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 10 Jul 2009 15:50:25 -0400 Subject: dhclient denial F-11 In-Reply-To: <20090710132914.3252c93a@sparta.com> References: <4A56F48E.7000009@city-fan.org> <4A573911.5060109@redhat.com> <4A573C3A.1090802@city-fan.org> <4A574646.2030907@redhat.com> <20090710132914.3252c93a@sparta.com> Message-ID: <4A579B81.8030508@redhat.com> On 07/10/2009 01:29 PM, Robert Story wrote: > On Fri, 10 Jul 2009 09:46:46 -0400 Daniel wrote: > DJW> If you execute service xyz restart, xyz will run as unconfined_u, if the > DJW> system does it at boot it will run as system_u. You can use run_init if > DJW> you choose to get it to run as system_u > > I've always wondered why service doesn't check for selinux and re-run > itself via run_init... > Mainly because run_init requires a password by default, and we did not want to change it to pam_rootok, by default. From rnicholsNOSPAM at comcast.net Fri Jul 10 21:28:33 2009 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Fri, 10 Jul 2009 16:28:33 -0500 Subject: SELinux is preventing gconf-defaults- (gconfdefaultsm_t) "read" security_t. Message-ID: When trying to set a new default for Power Management Preferences: Detailed Description: SELinux denied access requested by gconf-defaults-. It is not expected that this access is required by gconf-defaults- and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:gconfdefaultsm_t:s0-s0:c0.c1023 Target Context system_u:object_r:security_t:s0 Target Objects mls [ file ] Source gconf-defaults- Source Path /usr/libexec/gconf-defaults-mechanism Port Host omega-3p.local Source RPM Packages GConf2-2.26.2-1.fc11 Target RPM Packages Policy RPM selinux-policy-3.6.12-53.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name omega-3p.local Platform Linux omega-3p.local 2.6.29.5-191.fc11.i586 #1 SMP Tue Jun 16 23:11:39 EDT 2009 i686 i686 Alert Count 2 First Seen Fri 10 Jul 2009 04:20:11 PM CDT Last Seen Fri 10 Jul 2009 04:20:11 PM CDT Local ID de1d32d5-dded-47ec-9eb5-9dc8167a8685 Line Numbers Raw Audit Messages node=omega-3p.local type=AVC msg=audit(1247260811.959:37): avc: denied { read } for pid=3541 comm="gconf-defaults-" name="mls" dev=selinuxfs ino=12 scontext=system_u:system_r:gconfdefaultsm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:security_t:s0 tclass=file node=omega-3p.local type=AVC msg=audit(1247260811.959:37): avc: denied { open } for pid=3541 comm="gconf-defaults-" name="mls" dev=selinuxfs ino=12 scontext=system_u:system_r:gconfdefaultsm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:security_t:s0 tclass=file node=omega-3p.local type=SYSCALL msg=audit(1247260811.959:37): arch=40000003 syscall=5 success=yes exit=3 a0=bfd414e8 a1=8000 a2=0 a3=bfd414e8 items=0 ppid=3540 pid=3541 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="gconf-defaults-" exe="/usr/libexec/gconf-defaults-mechanism" subj=system_u:system_r:gconfdefaultsm_t:s0-s0:c0.c1023 key=(null) -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. From chepkov at yahoo.com Sat Jul 11 12:06:10 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Sat, 11 Jul 2009 05:06:10 -0700 (PDT) Subject: spamassassin pre-compiled rules Message-ID: <712568.20114.qm@web36805.mail.mud.yahoo.com> spamassassin rules got updated recently and I got this avc type=AVC msg=audit(1247216252.200:31900): avc: denied { execute } for pid=24001 comm="spamd" path="/var/lib/spamassassin/compiled/5.010/3.002005/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so" dev=dm-3 ino=124989 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=file audit2allow suggests this #============= spamd_t ============== allow spamd_t spamd_var_lib_t:file execute; seems reasonable, but why is it missing in standard policy? Sincerely yours, Vadym Chepkov From chepkov at yahoo.com Sat Jul 11 12:20:32 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Sat, 11 Jul 2009 05:20:32 -0700 (PDT) Subject: semodule/dbus Message-ID: <694609.67066.qm@web36802.mail.mud.yahoo.com> Everytime I install or update a local selinux module I get a log entry, like this. Jul 11 08:10:36 hut dbus: Can't send to audit system: USER_AVC avc: received policyload notice (seqno=5)#012: exe="?" (sauid=81, hostname=?, addr=?, terminal=?) I wonder what is it about? It doesn't seem to affect anything, but still. Sincerely yours, Vadym Chepkov From domg472 at gmail.com Sat Jul 11 16:07:38 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 11 Jul 2009 18:07:38 +0200 Subject: SELinux is preventing gconf-defaults- (gconfdefaultsm_t) "read" security_t. In-Reply-To: References: Message-ID: <1247328458.18261.3.camel@notebook2.grift.internal> On Fri, 2009-07-10 at 16:28 -0500, Robert Nichols wrote: > When trying to set a new default for Power Management Preferences: > > Detailed Description: > > SELinux denied access requested by gconf-defaults-. It is not expected > that this > access is required by gconf-defaults- and this access may signal an > intrusion > attempt. It is also possible that the specific version or configuration > of the > application is causing it to require additional access. > > Allowing Access: > > You can generate a local policy module to allow this access - see FAQ > (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can > disable > SELinux protection altogether. Disabling SELinux protection is not > recommended. > Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > against this package. > > Additional Information: > > Source Context > system_u:system_r:gconfdefaultsm_t:s0-s0:c0.c1023 > Target Context system_u:object_r:security_t:s0 > Target Objects mls [ file ] > Source gconf-defaults- > Source Path /usr/libexec/gconf-defaults-mechanism > Port > Host omega-3p.local > Source RPM Packages GConf2-2.26.2-1.fc11 > Target RPM Packages > Policy RPM selinux-policy-3.6.12-53.fc11 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall > Host Name omega-3p.local > Platform Linux omega-3p.local > 2.6.29.5-191.fc11.i586 #1 SMP > Tue Jun 16 23:11:39 EDT 2009 i686 i686 > Alert Count 2 > First Seen Fri 10 Jul 2009 04:20:11 PM CDT > Last Seen Fri 10 Jul 2009 04:20:11 PM CDT > Local ID de1d32d5-dded-47ec-9eb5-9dc8167a8685 > Line Numbers > > Raw Audit Messages > > node=omega-3p.local type=AVC msg=audit(1247260811.959:37): avc: denied > { read } for pid=3541 comm="gconf-defaults-" name="mls" dev=selinuxfs > ino=12 scontext=system_u:system_r:gconfdefaultsm_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:security_t:s0 tclass=file > > node=omega-3p.local type=AVC msg=audit(1247260811.959:37): avc: denied > { open } for pid=3541 comm="gconf-defaults-" name="mls" dev=selinuxfs > ino=12 scontext=system_u:system_r:gconfdefaultsm_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:security_t:s0 tclass=file > > node=omega-3p.local type=SYSCALL msg=http://kojipkgs.fedoraproject.org/packages/selinux-policy/3.6.12/65.fc11/noarch/selinux-policy-3.6.12-65.fc11.noarch.rpmaudit(1247260811.959:37): > arch=40000003 syscall=5 success=yes exit=3 a0=bfd414e8 a1=8000 a2=0 > a3=bfd414e8 items=0 ppid=3540 pid=3541 auid=4294967295 uid=0 gid=0 > euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 > comm="gconf-defaults-" exe="/usr/libexec/gconf-defaults-mechanism" > subj=system_u:system_r:gconfdefaultsm_t:s0-s0:c0.c1023 key=(null) > This issue should be resolved in latest policy: rpm -Uvh http://kojipkgs.fedoraproject.org/packages/selinux-policy/3.6.12/65.fc11/noarch/selinux-policy-3.6.12-65.fc11.noarch.rpm http://kojipkgs.fedoraproject.org/packages/selinux-policy/3.6.12/65.fc11/noarch/selinux-policy-targeted-3.6.12-65.fc11.noarch.rpm -------------- 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 Sat Jul 11 16:12:38 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 11 Jul 2009 18:12:38 +0200 Subject: semodule/dbus In-Reply-To: <694609.67066.qm@web36802.mail.mud.yahoo.com> References: <694609.67066.qm@web36802.mail.mud.yahoo.com> Message-ID: <1247328758.18261.8.camel@notebook2.grift.internal> On Sat, 2009-07-11 at 05:20 -0700, Vadym Chepkov wrote: > Everytime I install or update a local selinux module I get a log entry, like this. > > Jul 11 08:10:36 hut dbus: Can't send to audit system: USER_AVC avc: received policyload notice (seqno=5)#012: exe="?" (sauid=81, hostname=?, addr=?, terminal=?) > > I wonder what is it about? It doesn't seem to affect anything, but still. dbus complains that it can not send a "receive policyload notice" to the audit system. I guess this should be considered a bug. Dbus also has some other issues where it sends avc denials to /var/log/messages instead of audit (/var/log/audit/audit.log). You could consider reporting a bugzilla for this. I would probably try the dbus component and cc. both sgrubb and dwalsh. > Sincerely yours, > Vadym Chepkov > > -- > 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: 197 bytes Desc: This is a digitally signed message part URL: From domg472 at gmail.com Sat Jul 11 16:38:16 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 11 Jul 2009 18:38:16 +0200 Subject: spamassassin pre-compiled rules In-Reply-To: <712568.20114.qm@web36805.mail.mud.yahoo.com> References: <712568.20114.qm@web36805.mail.mud.yahoo.com> Message-ID: <1247330296.18261.34.camel@notebook2.grift.internal> On Sat, 2009-07-11 at 05:06 -0700, Vadym Chepkov wrote: > spamassassin rules got updated recently and I got this avc > > type=AVC msg=audit(1247216252.200:31900): avc: denied { execute } for pid=24001 comm="spamd" path="/var/lib/spamassassin/compiled/5.010/3.002005/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so" dev=dm-3 ino=124989 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=file > > audit2allow suggests this > #============= spamd_t ============== > allow spamd_t spamd_var_lib_t:file execute; > seems reasonable, but why is it missing in standard policy? > > Sincerely yours, > Vadym Chepkov Is that file part of the package? /var/lib/spamassassin/compiled/5.010/3.002005/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so It is probably created by spamd_t. The problem is that if you allow spamd_t to execute files with type spamd_var_lib_t then spamd_t can run everything in /var/lib/spamassassin. This is not so nice but it might not be a problem either Looking at the path it appears that spamd put compiled stuff under /var/lib/spamassassin/compiled/ assuming that all stuff under there should be executable by spamd_t, one could consider to introduce a new type for spamd_t executable files there. That would look something like this: myspamd.te: policy_module(myspamd, 0.0.1) type spamd_var_lib_exec_t; files_type(spamd_var_lib_exec_t) require { type spamd_t; } filetrans_pattern(spamd_t, spamd_var_lib_exec_t, spamd_var_lib_exec_t, { dir file }) manage_dirs_pattern(spamd_t, spamd_var_lib_exec_t, spamd_var_lib_exec_t) manage_files_pattern(spamd_t, spamd_var_lib_exec_t, spamd_var_lib_exec_t) exec_files_pattern(spamd_t, spamd_var_lib_exec_t, spamd_var_lib_exec_t) myspamd.fc: /var/lib/spamassassin/compiled(/.*)? -- gen_context(system_u:object_r:spamd_var_lib_exec_t, s0) But i guess that depends on your security requirements For now this could be considered a bug in selinux-policy > 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: 197 bytes Desc: This is a digitally signed message part URL: From domg472 at gmail.com Sat Jul 11 17:08:20 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 11 Jul 2009 19:08:20 +0200 Subject: spamassassin pre-compiled rules In-Reply-To: <1247330296.18261.34.camel@notebook2.grift.internal> References: <712568.20114.qm@web36805.mail.mud.yahoo.com> <1247330296.18261.34.camel@notebook2.grift.internal> Message-ID: <1247332100.18261.37.camel@notebook2.grift.internal> On Sat, 2009-07-11 at 18:38 +0200, Dominick Grift wrote: > On Sat, 2009-07-11 at 05:06 -0700, Vadym Chepkov wrote: > > spamassassin rules got updated recently and I got this avc > > > > type=AVC msg=audit(1247216252.200:31900): avc: denied { execute } for pid=24001 comm="spamd" path="/var/lib/spamassassin/compiled/5.010/3.002005/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so" dev=dm-3 ino=124989 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=file > > > > audit2allow suggests this > > #============= spamd_t ============== > > allow spamd_t spamd_var_lib_t:file execute; > > seems reasonable, but why is it missing in standard policy? > > > > Sincerely yours, > > Vadym Chepkov Whoops, some errors in my example > Is that file part of the package? > /var/lib/spamassassin/compiled/5.010/3.002005/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so > > It is probably created by spamd_t. > > The problem is that if you allow spamd_t to execute files with type > spamd_var_lib_t then spamd_t can run everything > in /var/lib/spamassassin. > > This is not so nice but it might not be a problem either > > Looking at the path it appears that spamd put compiled stuff > under /var/lib/spamassassin/compiled/ > > assuming that all stuff under there should be executable by spamd_t, one > could consider to introduce a new type for spamd_t executable files > there. > > That would look something like this: > > myspamd.te: > policy_module(myspamd, 0.0.1) > type spamd_var_lib_exec_t; > files_type(spamd_var_lib_exec_t) > require { type spamd_t; } require { type spamd_t, spamd_var_lib_t; } > filetrans_pattern(spamd_t, spamd_var_lib_exec_t, spamd_var_lib_exec_t, > { dir file }) filetrans_pattern(spamd_t, spamd_var_lib_t, spamd_var_lib_exec_t, { dir file }) > manage_dirs_pattern(spamd_t, spamd_var_lib_exec_t, spamd_var_lib_exec_t) > manage_files_pattern(spamd_t, spamd_var_lib_exec_t, > spamd_var_lib_exec_t) > exec_files_pattern(spamd_t, spamd_var_lib_exec_t, spamd_var_lib_exec_t) > > myspamd.fc: > /var/lib/spamassassin/compiled(/.*)? -- > gen_context(system_u:object_r:spamd_var_lib_exec_t, s0) /var/lib/spamassassin/compiled(/.*)? gen_context(system_u:object_r:spamd_var_lib_exec_t, s0) > > But i guess that depends on your security requirements > > For now this could be considered a bug in selinux-policy > > > 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: 197 bytes Desc: This is a digitally signed message part URL: From rnicholsNOSPAM at comcast.net Sat Jul 11 17:13:56 2009 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Sat, 11 Jul 2009 12:13:56 -0500 Subject: SELinux is preventing gconf-defaults- (gconfdefaultsm_t) "read" security_t. In-Reply-To: <1247328458.18261.3.camel@notebook2.grift.internal> References: <1247328458.18261.3.camel@notebook2.grift.internal> Message-ID: Dominick Grift wrote: > On Fri, 2009-07-10 at 16:28 -0500, Robert Nichols wrote: >> When trying to set a new default for Power Management Preferences: >> >> Detailed Description: >> >> SELinux denied access requested by gconf-defaults-. It is not expected >> that this >> access is required by gconf-defaults- and this access may signal an >> intrusion >> attempt. It is also possible that the specific version or configuration >> of the >> application is causing it to require additional access. [SNIP] > This issue should be resolved in latest policy: > > rpm -Uvh > http://kojipkgs.fedoraproject.org/packages/selinux-policy/3.6.12/65.fc11/noarch/selinux-policy-3.6.12-65.fc11.noarch.rpm > http://kojipkgs.fedoraproject.org/packages/selinux-policy/3.6.12/65.fc11/noarch/selinux-policy-targeted-3.6.12-65.fc11.noarch.rpm That appears to take care of it. Thanks. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. From olivares14031 at yahoo.com Sat Jul 11 19:14:46 2009 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Sat, 11 Jul 2009 12:14:46 -0700 (PDT) Subject: selinux denying ifconfig, Fedora 11 Message-ID: <11442.93225.qm@web52611.mail.re2.yahoo.com> [olivares at ET1161-05 ~]$ dmesg | grep 'avc' type=1400 audit(1247281500.625:4): avc: denied { read } for pid=871 comm="ifconfig" name="mls" dev=selinuxfs ino=12 scontext=system_u:system_r:ifconfig_t:s0-s0:c0.c1023 tcontext=system_u:object_r:security_t:s0 tclass=file [olivares at ET1161-05 ~]$ [olivares at ET1161-05 ~]$ cat /etc/fedora-release Fedora release 11 (Leonidas) [olivares at ET1161-05 ~]$ uname -r 2.6.30.1 smoltProfile here after install if it is useful? http://www.smolts.org/client/show/pub_bf6b4475-b2d9-4796-8965-112b094912de I only called command to check that I was connected while using dialup # ifconfig -a That was it, I saw setroubleshoot pop up but my fonts are very small, and I used above command to give me back avc. Regards, Antonio From domg472 at gmail.com Sat Jul 11 19:22:21 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 11 Jul 2009 21:22:21 +0200 Subject: selinux denying ifconfig, Fedora 11 In-Reply-To: <11442.93225.qm@web52611.mail.re2.yahoo.com> References: <11442.93225.qm@web52611.mail.re2.yahoo.com> Message-ID: <1247340146.19275.0.camel@notebook2.grift.internal> On Sat, 2009-07-11 at 12:14 -0700, Antonio Olivares wrote: > [olivares at ET1161-05 ~]$ dmesg | grep 'avc' > type=1400 audit(1247281500.625:4): avc: denied { read } for pid=871 comm="ifconfig" name="mls" dev=selinuxfs ino=12 scontext=system_u:system_r:ifconfig_t:s0-s0:c0.c1023 tcontext=system_u:object_r:security_t:s0 tclass=file > [olivares at ET1161-05 ~]$ > [olivares at ET1161-05 ~]$ cat /etc/fedora-release > Fedora release 11 (Leonidas) > [olivares at ET1161-05 ~]$ uname -r > 2.6.30.1 > > smoltProfile here after install if it is useful? > > http://www.smolts.org/client/show/pub_bf6b4475-b2d9-4796-8965-112b094912de > > I only called command to check that I was connected while using dialup > # ifconfig -a > That was it, I saw setroubleshoot pop up but my fonts are very small, and I used above command to give me back avc. > > Regards, > > Antonio > This issue should be resolved in latest policy: rpm -Uvh http://kojipkgs.fedoraproject.org/packages/selinux-policy/3.6.12/65.fc11/noarch/selinux-policy-3.6.12-65.fc11.noarch.rpm http://kojipkgs.fedoraproject.org/packages/selinux-policy/3.6.12/65.fc11/noarch/selinux-policy-targeted-3.6.12-65.fc11.noarch.rpm > > > > -- > 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: 197 bytes Desc: This is a digitally signed message part URL: From chepkov at yahoo.com Sat Jul 11 19:49:19 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Sat, 11 Jul 2009 12:49:19 -0700 (PDT) Subject: spamassassin pre-compiled rules Message-ID: <682303.42789.qm@web36805.mail.mud.yahoo.com> I figured it out. There is a proper label in the policy /var/lib/spamassassin/compiled/.*\.so.* regular file system_u:object_r:lib_t:s0 It seems when a script that compiles this library runs, it creates shared libraries with spamd_var_lib_t instead. So I guess the only way to fix this issue is to run restorecon -R /var/lib/spamassassin/compiled/ right after sa-compile finishes. Sincerely yours, Vadym Chepkov --- On Sat, 7/11/09, Dominick Grift wrote: > From: Dominick Grift > Subject: Re: spamassassin pre-compiled rules > To: "Vadym Chepkov" > Cc: "Fedora SELinux" > Date: Saturday, July 11, 2009, 12:38 PM > On Sat, 2009-07-11 at 05:06 -0700, > Vadym Chepkov wrote: > > spamassassin rules got updated recently and I got this > avc > > > > type=AVC msg=audit(1247216252.200:31900): avc:? > denied? { execute } for? pid=24001 comm="spamd" > path="/var/lib/spamassassin/compiled/5.010/3.002005/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so" > dev=dm-3 ino=124989 scontext=system_u:system_r:spamd_t:s0 > tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=file > > > > audit2allow suggests this > > #============= spamd_t ============== > > allow spamd_t spamd_var_lib_t:file execute; > > seems reasonable, but why is it missing in standard > policy? > > > > Sincerely yours, > >???Vadym Chepkov > > Is that file part of the package? > /var/lib/spamassassin/compiled/5.010/3.002005/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so > > It is probably created by spamd_t. > > The problem is that if you allow spamd_t to execute files > with type > spamd_var_lib_t then spamd_t can run everything > in /var/lib/spamassassin. > > This is not so nice but it might not be a problem either > > Looking at the path it appears that spamd put compiled > stuff > under /var/lib/spamassassin/compiled/ > > assuming that all stuff under there should be executable by > spamd_t, one > could consider to introduce a new type for spamd_t > executable files > there. > > That would look something like this: > > myspamd.te: > policy_module(myspamd, 0.0.1) > type spamd_var_lib_exec_t; > files_type(spamd_var_lib_exec_t) > require { type spamd_t; } > filetrans_pattern(spamd_t, spamd_var_lib_exec_t, > spamd_var_lib_exec_t, > { dir file }) > manage_dirs_pattern(spamd_t, spamd_var_lib_exec_t, > spamd_var_lib_exec_t) > manage_files_pattern(spamd_t, spamd_var_lib_exec_t, > spamd_var_lib_exec_t) > exec_files_pattern(spamd_t, spamd_var_lib_exec_t, > spamd_var_lib_exec_t) > > myspamd.fc: > /var/lib/spamassassin/compiled(/.*)?? -- > gen_context(system_u:object_r:spamd_var_lib_exec_t, s0) > > But i guess that depends on your security requirements > > For now this could be considered a bug in selinux-policy > > > > 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 Sat Jul 11 20:30:08 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 11 Jul 2009 22:30:08 +0200 Subject: spamassassin pre-compiled rules In-Reply-To: <682303.42789.qm@web36805.mail.mud.yahoo.com> References: <682303.42789.qm@web36805.mail.mud.yahoo.com> Message-ID: <1247344208.19593.4.camel@notebook2.grift.internal> On Sat, 2009-07-11 at 12:49 -0700, Vadym Chepkov wrote: > I figured it out. There is a proper label in the policy > > /var/lib/spamassassin/compiled/.*\.so.* regular file system_u:object_r:lib_t:s0 > > It seems when a script that compiles this library runs, it creates shared libraries with spamd_var_lib_t instead. So I guess the only way to fix this issue is to run restorecon -R /var/lib/spamassassin/compiled/ right after sa-compile finishes. The solution i described below makes spamd_t create files with a type it can execute. That does not require you to run restorecon. But if you do not mind to restore the context manually then lib_t might be a reasonable solution. Be aware though that all domains have access to lib_t > Sincerely yours, > Vadym Chepkov > > > --- On Sat, 7/11/09, Dominick Grift wrote: > > > From: Dominick Grift > > Subject: Re: spamassassin pre-compiled rules > > To: "Vadym Chepkov" > > Cc: "Fedora SELinux" > > Date: Saturday, July 11, 2009, 12:38 PM > > On Sat, 2009-07-11 at 05:06 -0700, > > Vadym Chepkov wrote: > > > spamassassin rules got updated recently and I got this > > avc > > > > > > type=AVC msg=audit(1247216252.200:31900): avc: > > denied { execute } for pid=24001 comm="spamd" > > path="/var/lib/spamassassin/compiled/5.010/3.002005/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so" > > dev=dm-3 ino=124989 scontext=system_u:system_r:spamd_t:s0 > > tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=file > > > > > > audit2allow suggests this > > > #============= spamd_t ============== > > > allow spamd_t spamd_var_lib_t:file execute; > > > seems reasonable, but why is it missing in standard > > policy? > > > > > > Sincerely yours, > > > Vadym Chepkov > > > > Is that file part of the package? > > /var/lib/spamassassin/compiled/5.010/3.002005/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so > > > > It is probably created by spamd_t. > > > > The problem is that if you allow spamd_t to execute files > > with type > > spamd_var_lib_t then spamd_t can run everything > > in /var/lib/spamassassin. > > > > This is not so nice but it might not be a problem either > > > > Looking at the path it appears that spamd put compiled > > stuff > > under /var/lib/spamassassin/compiled/ > > > > assuming that all stuff under there should be executable by > > spamd_t, one > > could consider to introduce a new type for spamd_t > > executable files > > there. > > > > That would look something like this: > > > > myspamd.te: > > policy_module(myspamd, 0.0.1) > > type spamd_var_lib_exec_t; > > files_type(spamd_var_lib_exec_t) > > require { type spamd_t; } > > filetrans_pattern(spamd_t, spamd_var_lib_exec_t, > > spamd_var_lib_exec_t, > > { dir file }) > > manage_dirs_pattern(spamd_t, spamd_var_lib_exec_t, > > spamd_var_lib_exec_t) > > manage_files_pattern(spamd_t, spamd_var_lib_exec_t, > > spamd_var_lib_exec_t) > > exec_files_pattern(spamd_t, spamd_var_lib_exec_t, > > spamd_var_lib_exec_t) > > > > myspamd.fc: > > /var/lib/spamassassin/compiled(/.*)? -- > > gen_context(system_u:object_r:spamd_var_lib_exec_t, s0) > > > > But i guess that depends on your security requirements > > > > For now this could be considered a bug in selinux-policy > > > > > > > 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: 197 bytes Desc: This is a digitally signed message part URL: From domg472 at gmail.com Sun Jul 12 11:16:04 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sun, 12 Jul 2009 13:16:04 +0200 Subject: spamassassin pre-compiled rules In-Reply-To: <1247344208.19593.4.camel@notebook2.grift.internal> References: <682303.42789.qm@web36805.mail.mud.yahoo.com> <1247344208.19593.4.camel@notebook2.grift.internal> Message-ID: <1247397364.21869.1.camel@notebook2.grift.internal> On Sat, 2009-07-11 at 22:30 +0200, Dominick Grift wrote: > On Sat, 2009-07-11 at 12:49 -0700, Vadym Chepkov wrote: > > I figured it out. There is a proper label in the policy > > > > /var/lib/spamassassin/compiled/.*\.so.* regular file system_u:object_r:lib_t:s0 > > > > It seems when a script that compiles this library runs, it creates shared libraries with spamd_var_lib_t instead. So I guess the only way to fix this issue is to run restorecon -R /var/lib/spamassassin/compiled/ right after sa-compile finishes. > > The solution i described below makes spamd_t create files with a type it > can execute. That does not require you to run restorecon. > > But if you do not mind to restore the context manually then lib_t might > be a reasonable solution. > > Be aware though that all domains have access to lib_t Actually my solution might not work after all unfortunately. So i guess either label it lib_t manually or give spamd_t execute access to spamd_var_lib_t... > > > Sincerely yours, > > Vadym Chepkov > > > > > > --- On Sat, 7/11/09, Dominick Grift wrote: > > > > > From: Dominick Grift > > > Subject: Re: spamassassin pre-compiled rules > > > To: "Vadym Chepkov" > > > Cc: "Fedora SELinux" > > > Date: Saturday, July 11, 2009, 12:38 PM > > > On Sat, 2009-07-11 at 05:06 -0700, > > > Vadym Chepkov wrote: > > > > spamassassin rules got updated recently and I got this > > > avc > > > > > > > > type=AVC msg=audit(1247216252.200:31900): avc: > > > denied { execute } for pid=24001 comm="spamd" > > > path="/var/lib/spamassassin/compiled/5.010/3.002005/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so" > > > dev=dm-3 ino=124989 scontext=system_u:system_r:spamd_t:s0 > > > tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=file > > > > > > > > audit2allow suggests this > > > > #============= spamd_t ============== > > > > allow spamd_t spamd_var_lib_t:file execute; > > > > seems reasonable, but why is it missing in standard > > > policy? > > > > > > > > Sincerely yours, > > > > Vadym Chepkov > > > > > > Is that file part of the package? > > > /var/lib/spamassassin/compiled/5.010/3.002005/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so > > > > > > It is probably created by spamd_t. > > > > > > The problem is that if you allow spamd_t to execute files > > > with type > > > spamd_var_lib_t then spamd_t can run everything > > > in /var/lib/spamassassin. > > > > > > This is not so nice but it might not be a problem either > > > > > > Looking at the path it appears that spamd put compiled > > > stuff > > > under /var/lib/spamassassin/compiled/ > > > > > > assuming that all stuff under there should be executable by > > > spamd_t, one > > > could consider to introduce a new type for spamd_t > > > executable files > > > there. > > > > > > That would look something like this: > > > > > > myspamd.te: > > > policy_module(myspamd, 0.0.1) > > > type spamd_var_lib_exec_t; > > > files_type(spamd_var_lib_exec_t) > > > require { type spamd_t; } > > > filetrans_pattern(spamd_t, spamd_var_lib_exec_t, > > > spamd_var_lib_exec_t, > > > { dir file }) > > > manage_dirs_pattern(spamd_t, spamd_var_lib_exec_t, > > > spamd_var_lib_exec_t) > > > manage_files_pattern(spamd_t, spamd_var_lib_exec_t, > > > spamd_var_lib_exec_t) > > > exec_files_pattern(spamd_t, spamd_var_lib_exec_t, > > > spamd_var_lib_exec_t) > > > > > > myspamd.fc: > > > /var/lib/spamassassin/compiled(/.*)? -- > > > gen_context(system_u:object_r:spamd_var_lib_exec_t, s0) > > > > > > But i guess that depends on your security requirements > > > > > > For now this could be considered a bug in selinux-policy > > > > > > > > > > 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: 197 bytes Desc: This is a digitally signed message part URL: From mgrepl at redhat.com Mon Jul 13 07:42:05 2009 From: mgrepl at redhat.com (Miroslav Grepl) Date: Mon, 13 Jul 2009 09:42:05 +0200 Subject: SELinux and gitosis (FC11) In-Reply-To: <4A535B86.4010807@redhat.com> References: <20090630162121.58df1092@hzhangpg02.ph.man.ac.uk> <4A4A4954.40308@redhat.com> <14cf210a0907040441p38dce15k91dee18697f0fd9a@mail.gmail.com> <4A51EA2A.8020609@redhat.com> <20090707105951.443270f3@hzhangpg02.ph.man.ac.uk> <4A53461E.2040508@redhat.com> <14cf210a0907070607y2d6d6cc8p23bc3bfe7052421f@mail.gmail.com> <4A535B86.4010807@redhat.com> Message-ID: <4A5AE54D.7090907@redhat.com> On 07/07/2009 04:28 PM, Daniel J Walsh wrote: > On 07/07/2009 09:07 AM, Jonathan Stott wrote: >> 2009/7/7 Daniel J Walsh: >>> So you intended on using the guest_t user? What does the te file >>> created by >>> audit2allow look like? >>> >>> I think the problem here is the guest_t user is running at s0 and >>> trying to >>> write to a fifo_file at s0-s0:c0.c1023 >>> >>> If you take the above audit messages and run them through audit2why, >>> what >>> does the tool say? >>> >> >> It says the errors were caused by: >> Was caused by: >> Policy constraint violation. >> >> May require adding a type attribute to the domain or type to >> satisfy >> the constraint. >> >> Constraints are defined in the policy sources in >> policy/constraints >> (general), policy/mcs (MCS), and policy/mls (MLS). >> >> And when I run them through audit2why gives me >> >> #============= guest_t ============== >> allow guest_t sshd_t:fifo_file write; >> >> Which looks vaguely sane to my untrained eye. >> >> I'm not particularly wedded to the guest user in specific, but I would >> prefer it to have a minimal privilege user, since it has no need to do >> anything but manage the git repositories in the home directory. >> >> Regards >> Jon > > Ok I think the easiest thing for you to do now is change the range of > the login user. > > # semanage user -m -r s0-s0:c0.c1023 guest_u > # semanage login -m -r s0-s0:c0.c1023 __default__ > > (If you use a user other then __default__ you would need to change > this also.) > > I will send a patch to F11 to allow communications to fifo_files > running at different levels. > The patch has been added to selinux-policy-3.6.12-65.fc11 Regards Miroslav > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From mgrepl at redhat.com Mon Jul 13 08:09:30 2009 From: mgrepl at redhat.com (Miroslav Grepl) Date: Mon, 13 Jul 2009 10:09:30 +0200 Subject: Domain transition missing In-Reply-To: <4A51F037.1070300@redhat.com> References: <138975.46083.qm@web36806.mail.mud.yahoo.com> <4A51F037.1070300@redhat.com> Message-ID: <4A5AEBBA.8080808@redhat.com> On 07/06/2009 02:38 PM, Daniel J Walsh wrote: > On 07/04/2009 10:09 AM, Vadym Chepkov wrote: >> It would be nice if the interface would be smart enough and allow >> output from the cron job to be sent, but no one is perfect :) >> >> ---- >> type=AVC msg=audit(1246715821.417:10142): avc: denied { write } >> for pid=11916 comm="winbind" path="pipe:[591689]" dev=pipefs >> ino=591689 scontext=system_u:system_r:system_cronjob_t:s0 >> tcontext=unconfined_u:system_r:crond_t:s0-s0:c0.c1023 tclass=fifo_file >> ---- >> type=AVC msg=audit(1246715821.780:10143): avc: denied { write } >> for pid=11925 comm="winbindd" path="pipe:[591689]" dev=pipefs >> ino=591689 scontext=system_u:system_r:winbind_t:s0 >> tcontext=unconfined_u:system_r:crond_t:s0-s0:c0.c1023 tclass=fifo_file >> >> Sincerely yours, >> Vadym Chepkov >> >> >> --- On Sat, 7/4/09, Vadym Chepkov wrote: >> >>> From: Vadym Chepkov >>> Subject: Re: Domain transition missing >>> To: "Dominick Grift" >>> Cc: "Fedora SELinux" >>> Date: Saturday, July 4, 2009, 10:00 AM >>> This worked well too, thank you >>> >>> system_u:system_r:winbind_t:SystemLow root >>> 11926 1 0 09:57 ? >>> 00:00:00 winbindd >>> system_u:system_r:winbind_t:SystemLow root 11928 >>> 11926 0 09:57 ? 00:00:00 winbindd >>> system_u:system_r:winbind_t:SystemLow root 11954 >>> 11926 0 09:57 ? 00:00:00 winbindd >>> system_u:system_r:winbind_t:SystemLow root 11956 >>> 11926 0 09:57 ? 00:00:00 winbindd >>> system_u:system_r:winbind_t:SystemLow root 11957 >>> 11926 0 09:57 ? 00:00:00 winbindd >>> >>> >>> Sincerely yours, >>> Vadym Chepkov >>> >>> >>> --- On Sat, 7/4/09, Dominick Grift >>> wrote: >>> >>>> From: Dominick Grift >>>> Subject: Re: Domain transition missing >>>> To: "Vadym Chepkov" >>>> Cc: "Fedora SELinux" >>>> Date: Saturday, July 4, 2009, 9:28 AM >>>> On Sat, 2009-07-04 at 06:18 -0700, >>>> Vadym Chepkov wrote: >>>>> That would be unfortunate. Mine approach is not >>>> uncommon. If you look closely you will see the same >>>> technique in wast scripts. spamassassin restarts >>> itself when >>>> it updates anti-spam rules, clamav does that >>> (antivirus) and >>>> on and on. I use Fedora 11, by the way. >>>>> For now, instead of creating a new policy I just >>> added >>>> 'runcon -t unconfind_t ' in the cron, and it seemed to >>> did >>>> the trick. >>>>> Sincerely yours, >>>>> Vadym Chepkov >>>>> >>>> Looking here: >>>> http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/services/cron.if >>>> >>>> line 235 to line 269. >>>> >>>> That seems like a interface one might use in your >>>> situation: >>>> >>>> cron_system_entry(winbind_t, winbind_exec_t) >>>> >>>> I admit that using cron with SELinux is not very easy >>>> currently >>>> >>>>> --- On Sat, 7/4/09, Dominick Grift >>>> wrote: >>>>>> From: Dominick Grift >>>>>> Subject: Re: Domain transition missing >>>>>> To: "Vadym Chepkov" >>>>>> Cc: "Fedora SELinux" >>>>>> Date: Saturday, July 4, 2009, 8:57 AM >>>>>> On Sat, 2009-07-04 at 05:48 -0700, >>>>>> Vadym Chepkov wrote: >>>>>>> I really get used to running my >>> scripts >>>> unconfined, >>>>>> how I can accomplish it in this scenario? >>>>>>> Sincerely yours, >>>>>>> Vadym Chepkov >>>>>>> >>>>>> if you want the system to run jobs you will >>> need >>>> to write >>>>>> some policy or >>>>>> extend the system_cronjob_t domain i think >>>>>> >>>>>> >>>>>> Were those the only avc denial you got? I >>> would >>>> expect more >>>>>> denials. >>>>>> >>>>>>> --- On Sat, 7/4/09, Dominick Grift >>> >>>>>> wrote: >>>>>>>> From: Dominick Grift >>>>>>>> Subject: Re: Domain transition >>> missing >>>>>>>> To: "Vadym Chepkov" >>>>>>>> Cc: "Fedora SELinux" >>>>>>>> Date: Saturday, July 4, 2009, 8:41 >>> AM >>>>>>>> On Sat, 2009-07-04 at 14:38 >>> +0200, >>>>>>>> Dominick Grift wrote: >>>>>>>>> On Sat, 2009-07-04 at 05:11 >>> -0700, >>>> Vadym >>>>>> Chepkov >>>>>>>> wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Last night I got a >>> nasty >>>> surprise from >>>>>> selinux. I >>>>>>>> am using winbind for external >>>> authentication and >>>>>> since it >>>>>>>> has history of failures I have a >>> simple >>>> watchdog >>>>>> implemented >>>>>>>> to check the status and restart it >>> if >>>> necessary. >>>>>> That >>>>>>>> is what happened last night and >>>> as a law >>>>>> abiding >>>>>>>> selinux citizen I used 'service >>> winbind >>>> restart', >>>>>> but it >>>>>>>> seems the proper domain >>> transitions is >>>> missing >>>>>> and winbind >>>>>>>> was started in system_cronjob_t >>> domain >>>> instead of >>>>>> winbind_t >>>>>>>> and none of other domains could >>> connect >>>> to it. >>>>>>>>>> I think jobs running >>> from >>>> cron should >>>>>> be granted >>>>>>>> the same transition rules as >>>> from >>>>>> unconfined_t. >>>>>>>>>> I will file bugzilla >>> report >>>> about it, >>>>>> but could >>>>>>>> somebody help me with modifying >>> my >>>> local policy >>>>>> until/if it >>>>>>>> gets implemented, please? Thank >>> you. >>>>>>>>>> Sincerely yours, >>>>>>>>>> Vadym >>>> Chepkov >>>>>>>>> A domain transition would >>> be: >>>>>>>>> policy_module(mywinbind, >>> 0.0.1) >>>>>>>>> require { type >>> system_cronjob_t, >>>>>> winbind_exec_t, >>>>>>>> winbind_t; } >>>> domain_auto_trans(system_cronjob_t, >>>>>> winbind_exec_t, >>>>>>>> winbind_t) >>>>>>>>> Can you show us the full raw >>> avc >>>> denial? >>>>>>>> >>>>>>>> But personally would deal with >>> this in >>>> a >>>>>> different way. I >>>>>>>> would write >>>>>>>> policy for the script that >>> restarts >>>> winbind and >>>>>> then i >>>>>>>> would create a >>>>>>>> domain transition for the domain >>> in >>>> which the >>>>>> script runs >>>>>>>> to winbind_t. >>>>>>>> >>>>>>>> Mainly because i wouldnt want to >>>> extend/modify >>>>>>>> system_cronjob_t >>>>>>>> >>>>>>>> So: system_cronjob_t -> >>>> myscript_exec_t -> >>>>>> myscript_t >>>>>>>> -> winbind_exec_t >>>>>>>> -> winbind_t >>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 > > > Miroslav, > > I think you should add > > dontaudit $1 crond_t:fifo_file rw_fifo_file_perms; > > To cron_system_entry to eliminate this leaked file descriptor problem. > > I will add this to selinux-policy-3.6.12-66.fc11 From mgrepl at redhat.com Mon Jul 13 08:26:53 2009 From: mgrepl at redhat.com (Miroslav Grepl) Date: Mon, 13 Jul 2009 10:26:53 +0200 Subject: dhclient denial F-11 In-Reply-To: <4A573911.5060109@redhat.com> References: <4A56F48E.7000009@city-fan.org> <4A573911.5060109@redhat.com> Message-ID: <4A5AEFCD.509@redhat.com> On 07/10/2009 02:50 PM, Daniel J Walsh wrote: > On 07/10/2009 03:58 AM, Paul Howarth wrote: >> I get one of these every time my DHCP lease is renewed: >> >> type=AVC msg=audit(1247181873.317:23522): avc: denied { create } for >> pid=31499 comm="mv" name="yp.conf.predhclient.br0" >> scontext=unconfined_u:system_r:dhcpc_t:s0 >> tcontext=system_u:object_r:net_conf_t:s0 tclass=file >> type=SYSCALL msg=audit(1247181873.317:23522): arch=c000003e syscall=2 >> success=no exit=-13 a0=7fff9e36ebcc a1=c1 a2=180 a3=65726373662f7274 >> items=0 ppid=31485 pid=31499 auid=1012 uid=0 gid=0 euid=0 suid=0 fsuid=0 >> egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="mv" exe="/bin/mv" >> subj=unconfined_u:system_r:dhcpc_t:s0 key=(null) >> >> It originates from /etc/dhcp/dhclient.d/nis.sh in the ypbind package. >> >> Paul.. >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > That is a new one, looks like you started dhclient by hand, and it is > running as unconfined_u:system_r:dhcpc_t:s0, But some where in the > tool it is trying to create a file labeled > system_u:object_r:net_conf_t:s0 > > unconfined_u creating a file with a user type of system_u is a > constraint violation. > > The mv command tries to maintain the context of the context of the > yp.conf.predhclient.br0 file which must have been created by dhclient > when it was run as a service, so you get this denial. > > So I guess we need to allow dhcpc_t the ability to change the user > componant of a file. > > Who said SELinux is not simple... :^( > > If you add the following in a module it should allow your app to work. > > > domain_obj_id_change_exemption(dhcpc_t) > > > Miroslav can you add this to sysnetwork.te for F10, F11. > I will add this to selinux-policy-3.6.12-66.fc11 and selinux-policy-3.5.13-67.fc10 From mgrepl at redhat.com Mon Jul 13 08:43:02 2009 From: mgrepl at redhat.com (Miroslav Grepl) Date: Mon, 13 Jul 2009 10:43:02 +0200 Subject: selinux denying ifconfig, Fedora 11 In-Reply-To: <11442.93225.qm@web52611.mail.re2.yahoo.com> References: <11442.93225.qm@web52611.mail.re2.yahoo.com> Message-ID: <4A5AF396.4070601@redhat.com> On 07/11/2009 09:14 PM, Antonio Olivares wrote: > [olivares at ET1161-05 ~]$ dmesg | grep 'avc' > type=1400 audit(1247281500.625:4): avc: denied { read } for pid=871 comm="ifconfig" name="mls" dev=selinuxfs ino=12 scontext=system_u:system_r:ifconfig_t:s0-s0:c0.c1023 tcontext=system_u:object_r:security_t:s0 tclass=file > [olivares at ET1161-05 ~]$ > [olivares at ET1161-05 ~]$ cat /etc/fedora-release > Fedora release 11 (Leonidas) > [olivares at ET1161-05 ~]$ uname -r > 2.6.30.1 > > smoltProfile here after install if it is useful? > > http://www.smolts.org/client/show/pub_bf6b4475-b2d9-4796-8965-112b094912de > > I only called command to check that I was connected while using dialup > # ifconfig -a > That was it, I saw setroubleshoot pop up but my fonts are very small, and I used above command to give me back avc. > > Regards, > > Antonio > > > This issue was fixed in selinux-policy-3.6.12-57.fc11. Just update your selinux-policy. Regards Miroslav > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From dwalsh at redhat.com Mon Jul 13 15:06:48 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 13 Jul 2009 11:06:48 -0400 Subject: spamassassin pre-compiled rules In-Reply-To: <712568.20114.qm@web36805.mail.mud.yahoo.com> References: <712568.20114.qm@web36805.mail.mud.yahoo.com> Message-ID: <4A5B4D88.8090805@redhat.com> On 07/11/2009 08:06 AM, Vadym Chepkov wrote: > spamassassin rules got updated recently and I got this avc > > type=AVC msg=audit(1247216252.200:31900): avc: denied { execute } for pid=24001 comm="spamd" path="/var/lib/spamassassin/compiled/5.010/3.002005/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so" dev=dm-3 ino=124989 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=file > > audit2allow suggests this > #============= spamd_t ============== > allow spamd_t spamd_var_lib_t:file execute; > seems reasonable, but why is it missing in standard policy? > > Sincerely yours, > Vadym Chepkov > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Vadym, What puts the files in this directory? Are they all shared libraries? One solution would be to label this directory # semanage fcontext -a -t lib_t '/var/lib/spamassassin/compiled(/.*)?' # restorecon -R -v /var/lib/spamassassin From chepkov at yahoo.com Mon Jul 13 15:19:16 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Mon, 13 Jul 2009 08:19:16 -0700 (PDT) Subject: spamassassin pre-compiled rules Message-ID: <305690.30265.qm@web36803.mail.mud.yahoo.com> sa-compile scripts puts them there, it runs manually from the cron. sa-compile call is not part of the standard Fedora package and as I said earlier, this context already exists in the standard policy, furthermore, Dan, you added it the by my request :) But even though it exists, it is being ignored when the library is created, I am not really sure how sa-compile script does it, but 'restorecon -R' afterward seems like an appropriate workaround. Sincerely yours, Vadym Chepkov --- On Mon, 7/13/09, Daniel J Walsh wrote: > From: Daniel J Walsh > Subject: Re: spamassassin pre-compiled rules > To: "Vadym Chepkov" > Cc: "Fedora SELinux" > Date: Monday, July 13, 2009, 11:06 AM > On 07/11/2009 08:06 AM, Vadym Chepkov > wrote: > > spamassassin rules got updated recently and I got this > avc > > > > type=AVC msg=audit(1247216252.200:31900): avc:? > denied? { execute } for? pid=24001 comm="spamd" > path="/var/lib/spamassassin/compiled/5.010/3.002005/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so" > dev=dm-3 ino=124989 scontext=system_u:system_r:spamd_t:s0 > tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=file > > > > audit2allow suggests this > > #============= spamd_t ============== > > allow spamd_t spamd_var_lib_t:file execute; > > seems reasonable, but why is it missing in standard > policy? > > > > Sincerely yours, > >???Vadym Chepkov > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Vadym, What puts the files in this directory?? Are > they all shared libraries? > > One solution would be to label this directory > > # semanage fcontext -a -t lib_t > '/var/lib/spamassassin/compiled(/.*)?' > # restorecon -R -v /var/lib/spamassassin > > > From dwalsh at redhat.com Mon Jul 13 15:20:42 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 13 Jul 2009 11:20:42 -0400 Subject: semodule/dbus In-Reply-To: <1247328758.18261.8.camel@notebook2.grift.internal> References: <694609.67066.qm@web36802.mail.mud.yahoo.com> <1247328758.18261.8.camel@notebook2.grift.internal> Message-ID: <4A5B50CA.7090309@redhat.com> On 07/11/2009 12:12 PM, Dominick Grift wrote: > On Sat, 2009-07-11 at 05:20 -0700, Vadym Chepkov wrote: >> Everytime I install or update a local selinux module I get a log entry, like this. >> >> Jul 11 08:10:36 hut dbus: Can't send to audit system: USER_AVC avc: received policyload notice (seqno=5)#012: exe="?" (sauid=81, hostname=?, addr=?, terminal=?) >> >> I wonder what is it about? It doesn't seem to affect anything, but still. > > dbus complains that it can not send a "receive policyload notice" to the > audit system. I guess this should be considered a bug. Dbus also has > some other issues where it sends avc denials to /var/log/messages > instead of audit (/var/log/audit/audit.log). > > You could consider reporting a bugzilla for this. I would probably try > the dbus component and cc. both sgrubb and dwalsh. > >> Sincerely yours, >> Vadym Chepkov >> >> -- >> 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 This bug comes back all the time. It is a bug in dbus trying to send audit message system when running as non-root. Every time a policy gets reloaded, dbus gets a messages telling it about the reload. It then sends an audit message, but the code is not smart enough to know whether to send it to the audit subsystem if it is the system bus or the syslog if it is the user bus. I have sent patches and this has been fixed, but it seems to come back every few releases. From dwalsh at redhat.com Mon Jul 13 15:23:37 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 13 Jul 2009 11:23:37 -0400 Subject: spamassassin pre-compiled rules In-Reply-To: <305690.30265.qm@web36803.mail.mud.yahoo.com> References: <305690.30265.qm@web36803.mail.mud.yahoo.com> Message-ID: <4A5B5179.9030607@redhat.com> On 07/13/2009 11:19 AM, Vadym Chepkov wrote: > sa-compile scripts puts them there, it runs manually from the cron. > sa-compile call is not part of the standard Fedora package and as I said earlier, this context already exists in the standard policy, furthermore, Dan, you added it the by my request :) But even though it exists, it is being ignored when the library is created, I am not really sure how sa-compile script does it, but 'restorecon -R' afterward seems like an appropriate workaround. > > Sincerely yours, > Vadym Chepkov > > > --- On Mon, 7/13/09, Daniel J Walsh wrote: > >> From: Daniel J Walsh >> Subject: Re: spamassassin pre-compiled rules >> To: "Vadym Chepkov" >> Cc: "Fedora SELinux" >> Date: Monday, July 13, 2009, 11:06 AM >> On 07/11/2009 08:06 AM, Vadym Chepkov >> wrote: >>> spamassassin rules got updated recently and I got this >> avc >>> type=AVC msg=audit(1247216252.200:31900): avc: >> denied { execute } for pid=24001 comm="spamd" >> path="/var/lib/spamassassin/compiled/5.010/3.002005/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so" >> dev=dm-3 ino=124989 scontext=system_u:system_r:spamd_t:s0 >> tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=file >>> audit2allow suggests this >>> #============= spamd_t ============== >>> allow spamd_t spamd_var_lib_t:file execute; >>> seems reasonable, but why is it missing in standard >> policy? >>> Sincerely yours, >>> Vadym Chepkov >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> Vadym, What puts the files in this directory? Are >> they all shared libraries? >> >> One solution would be to label this directory >> >> # semanage fcontext -a -t lib_t >> '/var/lib/spamassassin/compiled(/.*)?' >> # restorecon -R -v /var/lib/spamassassin >> >> >> Vadym, can you create a patch for them to add a restorecon after they create the libraries. From chepkov at yahoo.com Mon Jul 13 16:32:39 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Mon, 13 Jul 2009 09:32:39 -0700 (PDT) Subject: spamassassin pre-compiled rules Message-ID: <870137.78003.qm@web36801.mail.mud.yahoo.com> --- On Mon, 7/13/09, Daniel J Walsh wrote: > Vadym, can you create a patch for them to add a restorecon > after they create the libraries. You mean to the Fedora package? Sure, I can try, I will cc you on it. It's a perl script so I am not sure how keen maintainer will be to include it 'system' call. From choeger at cs.tu-berlin.de Thu Jul 16 17:20:16 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Thu, 16 Jul 2009 19:20:16 +0200 Subject: Would SELinux prevent that with the current policy? Message-ID: <1247764816.12894.117.camel@choeger6> Hi, after looking at: http://blog.cr0.org/2009/07/old-school-local-root-vulnerability-in.html I wondered if SELinux would not be the right answer to those re-exec exploits. I guess that pulseaudio should run as something like pulseaudio_t which has all caps it needs. Re-exec should not change that as pulseaudio does not need any transformation of context. So short question: Does it work that way? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From chepkov at yahoo.com Sun Jul 19 03:03:40 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Sat, 18 Jul 2009 20:03:40 -0700 (PDT) Subject: httpd interface question Message-ID: <12285.68637.qm@web36807.mail.mud.yahoo.com> Hi, I have a question about httpd interface on RedHat 5.3 selinux-policy-targeted-2.4.6-203.el5 I have httpd_unified --> off and I defined domain for subversion: apache_content_template(svn) I labeled my subversion hooks as httpd_svn_script_exec_t and I expected it will be able to read files labeled as httpd_svn_content_t, but it is not the case: type=AVC msg=audit(1247931060.612:40993): avc: denied { read } for pid=21405 comm="svn-mailer" name="svn-mailer.cfg" dev=sda1 ino=773360 scontext=user_u:system_r:httpd_svn_script_t:s0 tcontext=system_u:object_r:httpd_svn_content_t:s0 tclass=file # sesearch -a -s httpd_svn_script_t -t httpd_svn_content_t Found 1 av rules: allow httpd_svn_script_t httpd_svn_content_t : dir { getattr search }; The question is, why only this and nothing else? Sincerely yours, Vadym Chepkov From chepkov at yahoo.com Sun Jul 19 03:35:08 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Sat, 18 Jul 2009 20:35:08 -0700 (PDT) Subject: add a transition rule Message-ID: <606582.36904.qm@web36801.mail.mud.yahoo.com> Hi, I have a script, executed by apache, which is running in httpd_svn_script_t domain. This script calls svn-mailer(bin_t) which in turns calls /usr/sbin/sendmail.sendmail(sendmail_exec_t) and since there is no transition defined, sendmail still runs in httpd_svn_script_t and I get humongous amount of avc's. What would be the proper rule to add to the local policy to make sendmail running in the proper domain, sendmail_t? And for that matter if httpd_can_sendmail --> on, shouldn't it be happening automatically? Thank you. Sincerely yours, Vadym Chepkov From sundaram at fedoraproject.org Sun Jul 19 09:51:08 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 19 Jul 2009 15:21:08 +0530 Subject: Would SELinux prevent that with the current policy? In-Reply-To: <1247764816.12894.117.camel@choeger6> References: <1247764816.12894.117.camel@choeger6> Message-ID: <4A62EC8C.1060002@fedoraproject.org> On 07/16/2009 10:50 PM, Christoph H?ger wrote: > Hi, > > after looking at: > http://blog.cr0.org/2009/07/old-school-local-root-vulnerability-in.html > > I wondered if SELinux would not be the right answer to those re-exec > exploits. I guess that pulseaudio should run as something like > pulseaudio_t which has all caps it needs. > Re-exec should not change that as pulseaudio does not need any > transformation of context. > > So short question: Does it work that way? Read this http://blog.namei.org/2009/07/18/a-brief-note-on-the-2630-kernel-null-pointer-vulnerability/ Rahul From domg472 at gmail.com Sun Jul 19 11:06:25 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sun, 19 Jul 2009 13:06:25 +0200 Subject: add a transition rule In-Reply-To: <606582.36904.qm@web36801.mail.mud.yahoo.com> References: <606582.36904.qm@web36801.mail.mud.yahoo.com> Message-ID: <1248001585.2564.53.camel@notebook1.grift.internal> On Sat, 2009-07-18 at 20:35 -0700, Vadym Chepkov wrote: > Hi, > > I have a script, executed by apache, which is running in httpd_svn_script_t domain. This script calls svn-mailer(bin_t) which in turns calls /usr/sbin/sendmail.sendmail(sendmail_exec_t) and since there is no transition defined, sendmail still runs in httpd_svn_script_t and I get humongous amount of avc's. What would be the proper rule to add to the local policy to make sendmail running in the proper domain, sendmail_t? > And for that matter if httpd_can_sendmail --> on, shouldn't it be happening automatically? Thank you. Not sure about all this (sesearch and review of source policy might reveal the answer). I am not in my usual location so i cannot verify at the moment, however my personal opinion is that you might as well write some policy yourself to make this happen. Those httpd booleans are generally coarse grained. If you write a policy for your script and do a transition from httpd_svn_script_t to myscript_t and than allow myscript_t to transition to the mail domain (probably something like sendmail_domtrans(myscript_t)). That way you do not pollute your httpd_svn_script_t domain too much with access vectors that are really meant for your script and not svn. > Sincerely yours, > Vadym Chepkov > > -- > 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 Sun Jul 19 11:36:22 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sun, 19 Jul 2009 13:36:22 +0200 Subject: Would SELinux prevent that with the current policy? In-Reply-To: <4A62EC8C.1060002@fedoraproject.org> References: <1247764816.12894.117.camel@choeger6> <4A62EC8C.1060002@fedoraproject.org> Message-ID: <1248003382.2564.74.camel@notebook1.grift.internal> On Sun, 2009-07-19 at 15:21 +0530, Rahul Sundaram wrote: > On 07/16/2009 10:50 PM, Christoph H?ger wrote: > > Hi, > > > > after looking at: > > http://blog.cr0.org/2009/07/old-school-local-root-vulnerability-in.html > > > > I wondered if SELinux would not be the right answer to those re-exec > > exploits. I guess that pulseaudio should run as something like > > pulseaudio_t which has all caps it needs. > > Re-exec should not change that as pulseaudio does not need any > > transformation of context. > > > > So short question: Does it work that way? > > Read this > > http://blog.namei.org/2009/07/18/a-brief-note-on-the-2630-kernel-null-pointer-vulnerability/ > > Rahul >From what i heard there were two bugs one in pulseaudio and one in kernel. When operating in a unconfined domain one (obviously) could exploit the kernel without using pulseaudio To me this makes perfect sense as in my view unconfined_t is a domain for the SElinux exempt. SELinux is built-into the kernel and so in a SELinux environment the kernel will always be a vulnerable spot. In my environments this exploit did not work. I only use unconfined_t for a privileged secondary domain for myself. For all other users i use strict user domain and role based access control (strict privileged secondary domains) >From what i understand there also was a bug in SELinux policy in a function that disallows mmap for unconfined_t. allow_unconfined_mmap_low, However this boolean is disabled by default anyways. (as i would expect in a unconfined domain) So in my view this issue is not really selinux related. SELinux does prevent it from happening if you configured is strict. If you map users to unconfined environments then obviously you have a problem but thats not selinux fault in my view. What this issue does show, and i think jmorris touched on this, is that, and i have said this many times: writing policy is one thing, but maintaining policy is another. is that policy needs to be reviewed once in a while. So that these bugs get found before they get " exploited". But again, for my environment, SELinux did its job. and to me this is another victory for SELinux. But for those that use the policy defaults i am sorry because they are (more) vulnerable to this issue, SElinux is two parts: The framework and policy. In this case policy is not optimal. Back in f2 we used a strict policy but it was no success because the policy wasnt mature enough. So targeted was designed, Now strict policy is more mature. maybe its time to move back to strict again. Or atleast use strict by default and let users optional map to unconfined_t. So long story short: in my view SELinux is the answer. This current targeted-policy model may not be the right answer. (atleast not if we want to protect/restrict users by default) > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From choeger at cs.tu-berlin.de Sun Jul 19 12:15:07 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Sun, 19 Jul 2009 14:15:07 +0200 Subject: Would SELinux prevent that with the current policy? In-Reply-To: <1248003382.2564.74.camel@notebook1.grift.internal> References: <1247764816.12894.117.camel@choeger6> <4A62EC8C.1060002@fedoraproject.org> <1248003382.2564.74.camel@notebook1.grift.internal> Message-ID: <1248005707.5922.8.camel@choeger5.umpa.netz> > But for those that use the policy defaults i am sorry because they are > (more) vulnerable to this issue, More? In what way can SELinux make you _more_ vulnerable? LSM are stackable, right? So basically all SELinux could do is restrict access and not allow access that already is denied by the dummy LSM, or not? > Back in f2 we used a strict policy but it was no success because the > policy wasnt mature enough. So targeted was designed, Now strict policy > is more mature. maybe its time to move back to strict again. Or atleast > use strict by default and let users optional map to unconfined_t. > > So long story short: in my view SELinux is the answer. This current > targeted-policy model may not be the right answer. (atleast not if we > want to protect/restrict users by default) AFAIK Dan Walsh blogged some time ago about confining firefox, because that is where we loose the linux security advantage: In the userland. (Ever tried to read your private ssh key with firefox? Combine that with one of the latest exploits and *bang* network open to everyone) You could of course make a strict userland policy, but who should be in charge of maintaining? Upstream? Package maintainers? Someone special? Think of all those binaries you would need to confine, that seems like way too much work to be done. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From chepkov at yahoo.com Sun Jul 19 13:33:51 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Sun, 19 Jul 2009 06:33:51 -0700 (PDT) Subject: add a transition rule In-Reply-To: <1248001585.2564.53.camel@notebook1.grift.internal> Message-ID: <635819.55557.qm@web36803.mail.mud.yahoo.com> I created httpd_svn_script_t for this exact purpose, I don't think another one is required. sendmail_domtrans(httpd_svn_script_t) is the rule then? Thank you, I will try it. Sincerely yours, Vadym Chepkov --- On Sun, 7/19/09, Dominick Grift wrote: > From: Dominick Grift > Subject: Re: add a transition rule > To: "Vadym Chepkov" > Cc: "Fedora SELinux" > Date: Sunday, July 19, 2009, 7:06 AM > On Sat, 2009-07-18 at 20:35 -0700, > Vadym Chepkov wrote: > > Hi, > > > > I have a script, executed by apache, which is running > in httpd_svn_script_t domain. This script calls > svn-mailer(bin_t) which in turns calls > /usr/sbin/sendmail.sendmail(sendmail_exec_t) and since there > is no transition defined, sendmail still runs in > httpd_svn_script_t and I get humongous amount of avc's. What > would be the proper rule to add to the local policy to make > sendmail running in the proper domain, sendmail_t? > > And for that matter if httpd_can_sendmail --> on, > shouldn't it be happening automatically? Thank you. > Not sure about all this (sesearch and review of source > policy might > reveal the answer). I am not in my usual location so i > cannot verify at > the moment, however my personal opinion is that you might > as well write > some policy yourself to make this happen. Those httpd > booleans are > generally coarse grained. > > If you write a policy for your script and do a transition > from > httpd_svn_script_t to myscript_t and than allow myscript_t > to transition > to the mail domain (probably something like > sendmail_domtrans(myscript_t)). That way you do not pollute > your > httpd_svn_script_t domain too much with access vectors that > are really > meant for your script and not svn. > > > Sincerely yours, > >???Vadym Chepkov > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From jmorris at namei.org Sun Jul 19 23:00:39 2009 From: jmorris at namei.org (James Morris) Date: Mon, 20 Jul 2009 09:00:39 +1000 (EST) Subject: Would SELinux prevent that with the current policy? In-Reply-To: <1248005707.5922.8.camel@choeger5.umpa.netz> References: <1247764816.12894.117.camel@choeger6> <4A62EC8C.1060002@fedoraproject.org> <1248003382.2564.74.camel@notebook1.grift.internal> <1248005707.5922.8.camel@choeger5.umpa.netz> Message-ID: On Sun, 19 Jul 2009, Christoph H?ger wrote: > > But for those that use the policy defaults i am sorry because they are > > (more) vulnerable to this issue, > > More? In what way can SELinux make you _more_ vulnerable? LSM are > stackable, right? So basically all SELinux could do is restrict access > and not allow access that already is denied by the dummy LSM, or not? Usually, but in this case, the problem is that SELinux (and this could happen to any LSM, really) allowed more access than the configured default. We want to be able to use MAC policy to allow applications to mmap low memory. There does not seem to be a really great solution which avoids the problem of then allowing more access than would otherwise be allowed. Consider, though, that you you wanted to run wine on a standard system, you would disable mmap_min_addr entirely for everything on the system. Most people will probably not need to do that and have it set at the normal value. Perhaps what we should do is never allow SELinux policy to reduce the protection level here, which would mean that if someone wants to allow an app to mmap low memory, they have to: a) disable protection globally via the sysctl b) then depend entirely on SELinux to enforce it except for domains with the mmap_zero permission So, IOW, the SELinux permission won't have any effect until the admin removes the "DAC" control globally. - James -- James Morris From jmorris at namei.org Sun Jul 19 23:18:05 2009 From: jmorris at namei.org (James Morris) Date: Mon, 20 Jul 2009 09:18:05 +1000 (EST) Subject: Would SELinux prevent that with the current policy? In-Reply-To: <1248003382.2564.74.camel@notebook1.grift.internal> References: <1247764816.12894.117.camel@choeger6> <4A62EC8C.1060002@fedoraproject.org> <1248003382.2564.74.camel@notebook1.grift.internal> Message-ID: On Sun, 19 Jul 2009, Dominick Grift wrote: > >From what i heard there were two bugs one in pulseaudio and one in kernel. > When operating in a unconfined domain one (obviously) could exploit the kernel > without using pulseaudio To me this makes perfect sense as in my view unconfined_t > is a domain for the SElinux exempt. SELinux is built-into the kernel and so in a SELinux environment > the kernel will always be a vulnerable spot. Yes, although SELinux should not reduce the security of the system vs. the default. This is the core issue from the SELinux POV. > In my environments this exploit did not work. The exploit depends on having non-default permissions on /dev/net/tun, or running as root, which was not made clear in the video or code. It seems that udev on at least F9 changes the permissions on the device, so beware. It's still a bug for SELinux, though, because it is designed to protect against DAC weaknesses. > What this issue does show, and i think jmorris touched on this, is that, > and i have said this many times: writing policy is one thing, but > maintaining policy is another. is that policy needs to be reviewed once > in a while. Well, I think the underlying problem is that it should not be possible for a policy writer to make the system less secure. It needs to be more robust, so that policy errors at least default to the standard DAC level of protection. - James -- James Morris From sradvan at redhat.com Mon Jul 20 01:53:38 2009 From: sradvan at redhat.com (Scott Radvan) Date: Mon, 20 Jul 2009 11:53:38 +1000 Subject: Trying to cause a denial with rsync and SELinux Message-ID: <20090720115338.247ede30@redhat.com> Hello all, I'm having troubles invoking _any_ denial whatsoever for rsync related tasks, in order for me to demonstrate in my book how to then work around it. I've made a custom init script for rsync as there is no existing one in Fedora 11, so I labeled it initrc_exec_t so that the rsync daemon transitions to rsync_t: # ps -eZ | grep rsync unconfined_u:system_r:rsync_t:s0 326 ? 00:00:00 rsync According to the information I have, now that it's running as rsync_t, the following Booleans should have an effect: allow_rsync_anon_write No mattter the state of this Boolean, I can still write to public_content_rw_t files, locally or over the LAN. rsync_client I have very little information on this Boolean and what it actually implies, what it requires in terms of labels, etc. but no matter its state, rsync operates normally as a client reading and writing to a daemonized process on another machine. rsync_export_all_ro Perhaps I'm misinterpreting this one as well, but no matter its state, I can read _and_ write the test files in the directory specified by the rsync daemon, locally and over the network. Really, I'm probably misinterpreting these Booleans and their actual implications, or doing something completely wrong. I simply need a way that I can get SELinux to give me a denial related to rsync (running as a daemon) which I can then document and demonstrate the work-around for. My problem remains that everything works too _well_ and SELinux doesn't seem to be denying any of the access or transfers I'm performing, whatever the state of these Booleans, based on my limited understanding of them. Does anyone have a better understanding of these particular Booleans, what they actually imply, what labels the files need in order to be affected by them, any other condition they require to enforce upon the system...and mainly how I can intentionally invoke a denial based on one of them? Thanks in advance, -- Scott Radvan Content Author, Platform (Installation and Deployment) Red Hat Asia Pacific (Brisbane) http://www.apac.redhat.com From ekuns at kilroy.chi.il.us Tue Jul 21 04:18:55 2009 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Mon, 20 Jul 2009 23:18:55 -0500 Subject: SELinux is preventing clamd.scan (system_cronjob_t) "write" crond_t Message-ID: <1248149935.26733.30.camel@kilroy.chi.il.us> Just in the past few days I've received seven of this AVC complaint, and I haven't seen any of this complaint before that. On 11 July, I updated selinux to 3.6.12-62.fc11. I currently have clamav-0.95.1-2.fc11.i586, installed on 1 July. I am not aware of anything that changed on or just before the 17th. Any ideas? Here's the sealert: Thanks Eddie Summary: SELinux is preventing clamd.scan (system_cronjob_t) "write" crond_t. Detailed Description: SELinux denied access requested by clamd.scan. It is not expected that this access is required by clamd.scan and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:system_cronjob_t:s0 Target Context system_u:system_r:crond_t:s0-s0:c0.c1023 Target Objects pipe [ fifo_file ] Source clamd.scan Source Path /bin/bash Port Host kilroy.chi.il.us Source RPM Packages bash-4.0-6.fc11 Target RPM Packages Policy RPM selinux-policy-3.6.12-62.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name kilroy.chi.il.us Platform Linux kilroy.chi.il.us 2.6.29.5-191.fc11.i686.PAE #1 SMP Tue Jun 16 23:19:53 EDT 2009 i686 i686 Alert Count 7 First Seen Fri Jul 17 10:36:13 2009 Last Seen Mon Jul 20 16:36:12 2009 Local ID 39c625f5-4b31-49f2-bb14-57835e8afc61 Line Numbers Raw Audit Messages node=kilroy.chi.il.us type=AVC msg=audit(1248125772.619:80082): avc: denied { write } for pid=3642 comm="clamd.scan" path="pipe:[8230868]" dev=pipefs ino=8230868 scontext=system_u:system_r:system_cronjob_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=fifo_file node=kilroy.chi.il.us type=SYSCALL msg=audit(1248125772.619:80082): arch=40000003 syscall=11 success=yes exit=0 a0=9ef08f0 a1=9ef0910 a2=9eeecb8 a3=9ef0910 items=0 ppid=509 pid=3642 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2000 comm="clamd.scan" exe="/bin/bash" subj=system_u:system_r:system_cronjob_t:s0 key=(null) From stecarucci at hotmail.com Tue Jul 21 09:49:02 2009 From: stecarucci at hotmail.com (Stefano Carucci) Date: Tue, 21 Jul 2009 09:49:02 +0000 Subject: policy database Message-ID: Hello all! I would like to ask you experts some details about how the policy binary is managed by the security server. While looking through the code I noticed that the avtab (in security/selinux/ss/avtab.h/c) stores all the needed information about the rules in a hash-table. Then, on the other side there is a policy database, that, as far as I understood is meant for configuration parameters only. So my question is: what is the link betweem the policy binary file and the avtab? Are all the rules loaded into the avtab from the binary file? Is there any mechanism to fast policy lookup from the binary file? Thank you in advance. Stefano _________________________________________________________________ 25 GB di spazio sempre con te. Accedi a SkyDrive! http://www.windowslive.it/skyDrive.aspx From dwalsh at redhat.com Tue Jul 21 11:57:33 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 21 Jul 2009 07:57:33 -0400 Subject: SELinux is preventing clamd.scan (system_cronjob_t) "write" crond_t In-Reply-To: <1248149935.26733.30.camel@kilroy.chi.il.us> References: <1248149935.26733.30.camel@kilroy.chi.il.us> Message-ID: <4A65AD2D.10608@redhat.com> On 07/21/2009 12:18 AM, Edward Kuns wrote: > Just in the past few days I've received seven of this AVC complaint, and > I haven't seen any of this complaint before that. On 11 July, I updated > selinux to 3.6.12-62.fc11. I currently have clamav-0.95.1-2.fc11.i586, > installed on 1 July. I am not aware of anything that changed on or just > before the 17th. Any ideas? > > Here's the sealert: > > Thanks > > Eddie > > > Summary: > > SELinux is preventing clamd.scan (system_cronjob_t) "write" crond_t. > > Detailed Description: > > SELinux denied access requested by clamd.scan. It is not expected that > this > access is required by clamd.scan and this access may signal an intrusion > attempt. It is also possible that the specific version or configuration > of the > application is causing it to require additional access. > > Allowing Access: > > You can generate a local policy module to allow this access - see FAQ > (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can > disable > SELinux protection altogether. Disabling SELinux protection is not > recommended. > Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > against this package. > > Additional Information: > > Source Context system_u:system_r:system_cronjob_t:s0 > Target Context system_u:system_r:crond_t:s0-s0:c0.c1023 > Target Objects pipe [ fifo_file ] > Source clamd.scan > Source Path /bin/bash > Port > Host kilroy.chi.il.us > Source RPM Packages bash-4.0-6.fc11 > Target RPM Packages > Policy RPM selinux-policy-3.6.12-62.fc11 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall > Host Name kilroy.chi.il.us > Platform Linux kilroy.chi.il.us > 2.6.29.5-191.fc11.i686.PAE > #1 SMP Tue Jun 16 23:19:53 EDT 2009 i686 > i686 > Alert Count 7 > First Seen Fri Jul 17 10:36:13 2009 > Last Seen Mon Jul 20 16:36:12 2009 > Local ID 39c625f5-4b31-49f2-bb14-57835e8afc61 > Line Numbers > > Raw Audit Messages > > node=kilroy.chi.il.us type=AVC msg=audit(1248125772.619:80082): avc: > denied { write } for pid=3642 comm="clamd.scan" path="pipe:[8230868]" > dev=pipefs ino=8230868 scontext=system_u:system_r:system_cronjob_t:s0 > tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=fifo_file > > node=kilroy.chi.il.us type=SYSCALL msg=audit(1248125772.619:80082): > arch=40000003 syscall=11 success=yes exit=0 a0=9ef08f0 a1=9ef0910 > a2=9eeecb8 a3=9ef0910 items=0 ppid=509 pid=3642 auid=0 uid=0 gid=0 > euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2000 > comm="clamd.scan" exe="/bin/bash" > subj=system_u:system_r:system_cronjob_t:s0 key=(null) > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list This looks like a MCS constraint problem. And looking at current selinux policy it should be fixed. Can you upgrade to the latest selinux policy in testing? yum upgrade --enablerepo=updates-testing selinux-policy-targeted From dwalsh at redhat.com Tue Jul 21 19:24:10 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 21 Jul 2009 15:24:10 -0400 Subject: httpd interface question In-Reply-To: <12285.68637.qm@web36807.mail.mud.yahoo.com> References: <12285.68637.qm@web36807.mail.mud.yahoo.com> Message-ID: <4A6615DA.3000403@redhat.com> On 07/18/2009 11:03 PM, Vadym Chepkov wrote: > Hi, > > I have a question about httpd interface on RedHat 5.3 > selinux-policy-targeted-2.4.6-203.el5 > > I have httpd_unified --> off > and I defined domain for subversion: > > apache_content_template(svn) > > I labeled my subversion hooks as httpd_svn_script_exec_t > and I expected it will be able to read files labeled as httpd_svn_content_t, but it is not the case: > > type=AVC msg=audit(1247931060.612:40993): avc: denied { read } for pid=21405 comm="svn-mailer" name="svn-mailer.cfg" dev=sda1 ino=773360 scontext=user_u:system_r:httpd_svn_script_t:s0 tcontext=system_u:object_r:httpd_svn_content_t:s0 tclass=file > > # sesearch -a -s httpd_svn_script_t -t httpd_svn_content_t > Found 1 av rules: > allow httpd_svn_script_t httpd_svn_content_t : dir { getattr search }; > I would say this is a bug. > > The question is, why only this and nothing else? > > Sincerely yours, > Vadym Chepkov > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Tue Jul 21 19:30:07 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 21 Jul 2009 15:30:07 -0400 Subject: httpd interface question In-Reply-To: <4A6615DA.3000403@redhat.com> References: <12285.68637.qm@web36807.mail.mud.yahoo.com> <4A6615DA.3000403@redhat.com> Message-ID: <4A66173F.9080502@redhat.com> On 07/21/2009 03:24 PM, Daniel J Walsh wrote: > On 07/18/2009 11:03 PM, Vadym Chepkov wrote: >> Hi, >> >> I have a question about httpd interface on RedHat 5.3 >> selinux-policy-targeted-2.4.6-203.el5 >> >> I have httpd_unified --> off >> and I defined domain for subversion: >> >> apache_content_template(svn) >> >> I labeled my subversion hooks as httpd_svn_script_exec_t >> and I expected it will be able to read files labeled as httpd_svn_content_t, but it is not the case: >> >> type=AVC msg=audit(1247931060.612:40993): avc: denied { read } for pid=21405 comm="svn-mailer" name="svn-mailer.cfg" dev=sda1 ino=773360 scontext=user_u:system_r:httpd_svn_script_t:s0 tcontext=system_u:object_r:httpd_svn_content_t:s0 tclass=file >> >> # sesearch -a -s httpd_svn_script_t -t httpd_svn_content_t >> Found 1 av rules: >> allow httpd_svn_script_t httpd_svn_content_t : dir { getattr search }; >> > I would say this is a bug. > > >> The question is, why only this and nothing else? >> >> Sincerely yours, >> Vadym Chepkov >> >> -- >> 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 RHEL5 defined httpd_$1_script_ro_t with it is allowing to read. In Fedora we have merged the two together. I am updating the RHEL5.4 policy to include list_dirs_pattern(httpd_$1_script_t, httpd_$1_content_t, httpd_$1_content_t) read_files_pattern(httpd_$1_script_t, httpd_$1_content_t, httpd_$1_content_t) read_lnk_files_pattern(httpd_$1_script_t, httpd_$1_content_t, httpd_$1_content_t) selinux-policy-2.4.6-254.el5.src.rpm From ekuns at kilroy.chi.il.us Wed Jul 22 12:46:15 2009 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Wed, 22 Jul 2009 07:46:15 -0500 Subject: SELinux is preventing clamd.scan (system_cronjob_t) "write" crond_t In-Reply-To: <4A65AD2D.10608@redhat.com> References: <1248149935.26733.30.camel@kilroy.chi.il.us> <4A65AD2D.10608@redhat.com> Message-ID: <1248266775.26733.36.camel@kilroy.chi.il.us> On Tue, 2009-07-21 at 07:57 -0400, Daniel J Walsh wrote: > On 07/21/2009 12:18 AM, Edward Kuns wrote: > > Just in the past few days I've received seven of this AVC complaint, > > > > SELinux is preventing clamd.scan (system_cronjob_t) "write" crond_t. > > > This looks like a MCS constraint problem. And looking at current selinux policy it should be fixed. > > Can you upgrade to the latest selinux policy in testing? > > yum upgrade --enablerepo=updates-testing selinux-policy-targeted I tried this and got "No Packages marked for Update" ... does this depend on mirrors being up-to-date? I tried several times in case it would try different mirrors, but no luck. Eddie From mgrepl at redhat.com Wed Jul 22 13:01:04 2009 From: mgrepl at redhat.com (Miroslav Grepl) Date: Wed, 22 Jul 2009 15:01:04 +0200 Subject: SELinux is preventing clamd.scan (system_cronjob_t) "write" crond_t In-Reply-To: <1248266775.26733.36.camel@kilroy.chi.il.us> References: <1248149935.26733.30.camel@kilroy.chi.il.us> <4A65AD2D.10608@redhat.com> <1248266775.26733.36.camel@kilroy.chi.il.us> Message-ID: <4A670D90.3060003@redhat.com> On 07/22/2009 02:46 PM, Edward Kuns wrote: > On Tue, 2009-07-21 at 07:57 -0400, Daniel J Walsh wrote: > >> On 07/21/2009 12:18 AM, Edward Kuns wrote: >> >>> Just in the past few days I've received seven of this AVC complaint, >>> >>> SELinux is preventing clamd.scan (system_cronjob_t) "write" crond_t. >>> >>> >> This looks like a MCS constraint problem. And looking at current selinux policy it should be fixed. >> >> Can you upgrade to the latest selinux policy in testing? >> >> yum upgrade --enablerepo=updates-testing selinux-policy-targeted >> > > I tried this and got "No Packages marked for Update" ... does this > depend on mirrors being up-to-date? I tried several times in case it > would try different mirrors, but no luck. > > Eddie > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > For now you can download selinux-policy and selinux-policy-targeted rpms from koji. Look at: http://koji.fedoraproject.org/koji/buildinfo?buildID=115151 And install using "rpm -Uvh selinux-policy-3.6.12-69.fc11.noarch.rpm selinux-policy-targeted-3.6.12-69.fc11.noarch.rpm" -------------- next part -------------- An HTML attachment was scrubbed... URL: From chepkov at yahoo.com Wed Jul 22 18:06:44 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Wed, 22 Jul 2009 11:06:44 -0700 (PDT) Subject: restorecon question Message-ID: <600882.53262.qm@web36803.mail.mud.yahoo.com> Hi, Could you explain me, please, the behavior of the restorecon utility. I added the following in the local.fc file # phpbb /var/www/phpbb/cache(/.*)? gen_context(system_u:object_r:httpd_sys_script_rw_t,s0) /var/www/phpbb/files(/.*)? gen_context(system_u:object_r:httpd_sys_script_rw_t,s0) compiled and installed policy, seems to be in place. # semanage fcontext -l|grep phpbb /var/www/phpbb/cache(/.*)? all files system_u:object_r:httpd_sys_script_rw_t:s0 /var/www/phpbb/files(/.*)? all files system_u:object_r:httpd_sys_script_rw_t:s0 But when now I run restorecon -vR /var/www/phpbb/ it doesn't do anything. I would expect it to changed context on two directories and files in them. Only if I specify -F (force) I relabel everything. I can't quite grasp why sometimes I don't have to supply -F and sometimes I do. Thank you. Sincerely yours, Vadym Chepkov From domg472 at gmail.com Wed Jul 22 18:33:27 2009 From: domg472 at gmail.com (Dominick Grift) Date: Wed, 22 Jul 2009 20:33:27 +0200 Subject: restorecon question In-Reply-To: <600882.53262.qm@web36803.mail.mud.yahoo.com> References: <600882.53262.qm@web36803.mail.mud.yahoo.com> Message-ID: <1248287607.29571.5.camel@notebook2.grift.internal> On Wed, 2009-07-22 at 11:06 -0700, Vadym Chepkov wrote: > Hi, > > Could you explain me, please, the behavior of the restorecon utility. > > I added the following in the local.fc file > > # phpbb > /var/www/phpbb/cache(/.*)? gen_context(system_u:object_r:httpd_sys_script_rw_t,s0) > /var/www/phpbb/files(/.*)? gen_context(system_u:object_r:httpd_sys_script_rw_t,s0) > > compiled and installed policy, seems to be in place. > > # semanage fcontext -l|grep phpbb > /var/www/phpbb/cache(/.*)? all files system_u:object_r:httpd_sys_script_rw_t:s0 > /var/www/phpbb/files(/.*)? all files system_u:object_r:httpd_sys_script_rw_t:s0 > > But when now I run restorecon -vR /var/www/phpbb/ > it doesn't do anything. I would expect it to changed context on two directories and files in them. > > Only if I specify -F (force) I relabel everything. > I can't quite grasp why sometimes I don't have to supply -F and sometimes I do. Not completely sure but i think it may have to do with customizable types. Customizable types are types that should not be relabeled. This can be overridden with the -F (force) option. Again i am not quite sure if this is the case here because in my system the httpd_sys_content_t type is not added to the customizable_types files. less /etc/selinux/targeted/contexts/custom* If i am wrong i hope someone will correct me. > Thank you. > > Sincerely yours, > Vadym Chepkov > > -- > 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: 197 bytes Desc: This is a digitally signed message part URL: From eparis at redhat.com Wed Jul 22 19:12:39 2009 From: eparis at redhat.com (Eric Paris) Date: Wed, 22 Jul 2009 15:12:39 -0400 Subject: restorecon question In-Reply-To: <600882.53262.qm@web36803.mail.mud.yahoo.com> References: <600882.53262.qm@web36803.mail.mud.yahoo.com> Message-ID: <1248289959.2900.1.camel@localhost> On Wed, 2009-07-22 at 11:06 -0700, Vadym Chepkov wrote: > Hi, > > Could you explain me, please, the behavior of the restorecon utility. > > I added the following in the local.fc file > > # phpbb > /var/www/phpbb/cache(/.*)? gen_context(system_u:object_r:httpd_sys_script_rw_t,s0) > /var/www/phpbb/files(/.*)? gen_context(system_u:object_r:httpd_sys_script_rw_t,s0) > > compiled and installed policy, seems to be in place. > > # semanage fcontext -l|grep phpbb > /var/www/phpbb/cache(/.*)? all files system_u:object_r:httpd_sys_script_rw_t:s0 > /var/www/phpbb/files(/.*)? all files system_u:object_r:httpd_sys_script_rw_t:s0 > > But when now I run restorecon -vR /var/www/phpbb/ > it doesn't do anything. I would expect it to changed context on two directories and files in them. What was the context before? Was the only difference the 'user' portion? I don't think restorecon bothers to reset the context if the only thing 'wrong' is the user, since the user is not relevant to any security operations.... From chepkov at yahoo.com Wed Jul 22 19:50:11 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Wed, 22 Jul 2009 12:50:11 -0700 (PDT) Subject: restorecon question In-Reply-To: <1248289959.2900.1.camel@localhost> Message-ID: <880775.73819.qm@web36807.mail.mud.yahoo.com> No, it was httpd_sys_content_t Sincerely yours, Vadym Chepkov --- On Wed, 7/22/09, Eric Paris wrote: > From: Eric Paris > Subject: Re: restorecon question > To: "Vadym Chepkov" > Cc: "Fedora SELinux" > Date: Wednesday, July 22, 2009, 3:12 PM > On Wed, 2009-07-22 at 11:06 -0700, > Vadym Chepkov wrote: > > Hi, > > > > Could you explain me, please, the behavior of the > restorecon utility. > > > > I added the following in the local.fc file > > > > # phpbb > > /var/www/phpbb/cache(/.*)???? > ??? ??? ??? > gen_context(system_u:object_r:httpd_sys_script_rw_t,s0) > > /var/www/phpbb/files(/.*)???? > ??? ??? ??? > gen_context(system_u:object_r:httpd_sys_script_rw_t,s0) > > > > compiled and installed policy, seems to be in place. > > > > # semanage fcontext -l|grep phpbb > > /var/www/phpbb/cache(/.*)?? ? ? ? > ? ? ? ? ? ? ? > ???all files? ? ? ? > ? system_u:object_r:httpd_sys_script_rw_t:s0 > > /var/www/phpbb/files(/.*)?? ? ? ? > ? ? ? ? ? ? ? > ???all files? ? ? ? > ? system_u:object_r:httpd_sys_script_rw_t:s0 > > > > But when now I run restorecon -vR /var/www/phpbb/ > > it doesn't do anything. I would expect it to changed > context on two directories and files in them. > > What was the context before?? Was the only difference > the 'user' > portion?? I don't think restorecon bothers to reset > the context if the > only thing 'wrong' is the user, since the user is not > relevant to any > security operations.... > > From chepkov at yahoo.com Wed Jul 22 19:57:36 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Wed, 22 Jul 2009 12:57:36 -0700 (PDT) Subject: restorecon question In-Reply-To: <1248287607.29571.5.camel@notebook2.grift.internal> Message-ID: <728217.49487.qm@web36803.mail.mud.yahoo.com> You are right, these types are listed in /etc/selinux/targeted/contexts/customizable_types: .... httpd_sys_content_t httpd_sys_htaccess_t httpd_sys_script_exec_t httpd_sys_script_ra_t httpd_sys_script_ro_t httpd_sys_script_rw_t httpd_unconfined_script_exec_t .... May I ask, why do they set this way? Sincerely yours, Vadym Chepkov --- On Wed, 7/22/09, Dominick Grift wrote: > From: Dominick Grift > Subject: Re: restorecon question > To: "Vadym Chepkov" > Cc: "Fedora SELinux" > Date: Wednesday, July 22, 2009, 2:33 PM > On Wed, 2009-07-22 at 11:06 -0700, > Vadym Chepkov wrote: > > Hi, > > > > Could you explain me, please, the behavior of the > restorecon utility. > > > > I added the following in the local.fc file > > > > # phpbb > > /var/www/phpbb/cache(/.*)???? > ??? ??? ??? > gen_context(system_u:object_r:httpd_sys_script_rw_t,s0) > > /var/www/phpbb/files(/.*)???? > ??? ??? ??? > gen_context(system_u:object_r:httpd_sys_script_rw_t,s0) > > > > compiled and installed policy, seems to be in place. > > > > # semanage fcontext -l|grep phpbb > > /var/www/phpbb/cache(/.*)?? ? ? ? > ? ? ? ? ? ? ? > ???all files? ? ? ? > ? system_u:object_r:httpd_sys_script_rw_t:s0 > > /var/www/phpbb/files(/.*)?? ? ? ? > ? ? ? ? ? ? ? > ???all files? ? ? ? > ? system_u:object_r:httpd_sys_script_rw_t:s0 > > > > But when now I run restorecon -vR /var/www/phpbb/ > > it doesn't do anything. I would expect it to changed > context on two directories and files in them. > > > > Only if I specify -F (force) I relabel everything. > > I can't quite grasp why sometimes I don't have to > supply -F and sometimes I do. > > Not completely sure but i think it may have to do with > customizable > types. Customizable types are types that should not be > relabeled. > > This can be overridden with the -F (force) option. > > Again i am not quite sure if this is the case here because > in my system > the httpd_sys_content_t type is not added to the > customizable_types > files. > > less /etc/selinux/targeted/contexts/custom* > > If i am wrong i hope someone will correct me. > > > Thank you. > > > > Sincerely yours, > >???Vadym Chepkov > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From sds at tycho.nsa.gov Wed Jul 22 20:05:07 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 22 Jul 2009 16:05:07 -0400 Subject: restorecon question In-Reply-To: <728217.49487.qm@web36803.mail.mud.yahoo.com> References: <728217.49487.qm@web36803.mail.mud.yahoo.com> Message-ID: <1248293107.28321.562.camel@moss-pluto.epoch.ncsc.mil> On Wed, 2009-07-22 at 12:57 -0700, Vadym Chepkov wrote: > You are right, these types are listed in /etc/selinux/targeted/contexts/customizable_types: > > .... > httpd_sys_content_t > httpd_sys_htaccess_t > httpd_sys_script_exec_t > httpd_sys_script_ra_t > httpd_sys_script_ro_t > httpd_sys_script_rw_t > httpd_unconfined_script_exec_t > .... > > May I ask, why do they set this way? Because users may choose to customize the labeling of their web hierarchy and we didn't want restorecon to clobber it. These days that isn't so necessary because users can use semanage fcontext -a to add entries for their customizations, and that is why customizable_types in F11 doesn't include those types. -- Stephen Smalley National Security Agency From domg472 at gmail.com Wed Jul 22 20:19:06 2009 From: domg472 at gmail.com (Dominick Grift) Date: Wed, 22 Jul 2009 22:19:06 +0200 Subject: restorecon question In-Reply-To: <1248293107.28321.562.camel@moss-pluto.epoch.ncsc.mil> References: <728217.49487.qm@web36803.mail.mud.yahoo.com> <1248293107.28321.562.camel@moss-pluto.epoch.ncsc.mil> Message-ID: <1248293946.29571.9.camel@notebook2.grift.internal> On Wed, 2009-07-22 at 16:05 -0400, Stephen Smalley wrote: > On Wed, 2009-07-22 at 12:57 -0700, Vadym Chepkov wrote: > > You are right, these types are listed in /etc/selinux/targeted/contexts/customizable_types: > > > > .... > > httpd_sys_content_t > > httpd_sys_htaccess_t > > httpd_sys_script_exec_t > > httpd_sys_script_ra_t > > httpd_sys_script_ro_t > > httpd_sys_script_rw_t > > httpd_unconfined_script_exec_t > > .... > > > > May I ask, why do they set this way? > > Because users may choose to customize the labeling of their web > hierarchy and we didn't want restorecon to clobber it. These days that > isn't so necessary because users can use semanage fcontext -a to add > entries for their customizations, and that is why customizable_types in > F11 doesn't include those types. > But should http_user_{content,content_rw,script_exec}_t not be customizable types though? Afaik unpriv users cannot use semanage fcontext. What if a unpriv user tries to configure a custom apache homedir for example (~/mywww) Will that not be relabeled upon restorecon -R -v /home? -------------- 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 choeger at cs.tu-berlin.de Thu Jul 23 09:03:09 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Thu, 23 Jul 2009 11:03:09 +0200 Subject: postfix_smtp_t Message-ID: <1248339789.2519.9.camel@choeger6> Hi, this is a rather special use case, but I think it is valid. According to Pauls hints at http://marilyn.frields.org:8080/~paul/wordpress/?p=2616 I configured postfix to relay my local mail via some mail servers. But since I like a clean approach I did not want the sasl_password files in /etc/ so that the admin (me) has to handle plain text passwords there. Postfix seems to support multiple db files at arbitrary positions. But SELinux does not. I guess the transition to postfix_smtp_t is a little too early (before chroot). So I changed the context of my sasl_passwd files to postfix_smtp_t, just to notice that: 1. I (as a user) cannot do this 2. After I did it nevertheless I cannot edit those files So here is my proposal: Introduce postfix_userconfig_t and let postfix_smtp_t read it, and allow transitions and read/write access from unconfined_t to it. I know that this is suboptimal because it effectively becomes unconfinded_t, but since the admin _must_ add those files to /etc/postfix/main.cf (and should allow only harmless files) I guess that this is ok. any objections or shall I try to write a patch for the policy? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From bruno at wolff.to Thu Jul 23 10:48:48 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Thu, 23 Jul 2009 05:48:48 -0500 Subject: SELinux is preventing clamd.scan (system_cronjob_t) "write" crond_t In-Reply-To: <1248266775.26733.36.camel@kilroy.chi.il.us> References: <1248149935.26733.30.camel@kilroy.chi.il.us> <4A65AD2D.10608@redhat.com> <1248266775.26733.36.camel@kilroy.chi.il.us> Message-ID: <20090723104848.GA27714@wolff.to> On Wed, Jul 22, 2009 at 07:46:15 -0500, Edward Kuns wrote: > On Tue, 2009-07-21 at 07:57 -0400, Daniel J Walsh wrote: > > On 07/21/2009 12:18 AM, Edward Kuns wrote: > > > Just in the past few days I've received seven of this AVC complaint, > > > > > > SELinux is preventing clamd.scan (system_cronjob_t) "write" crond_t. > > > > > This looks like a MCS constraint problem. And looking at current selinux policy it should be fixed. > > > > Can you upgrade to the latest selinux policy in testing? > > > > yum upgrade --enablerepo=updates-testing selinux-policy-targeted > > I tried this and got "No Packages marked for Update" ... does this > depend on mirrors being up-to-date? I tried several times in case it > would try different mirrors, but no luck. Yes. You can get it directly from koji as a work around. Also mirrors2.kernel.org is currently up to date. From sds at tycho.nsa.gov Thu Jul 23 14:43:39 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 23 Jul 2009 10:43:39 -0400 Subject: restorecon question In-Reply-To: <1248293946.29571.9.camel@notebook2.grift.internal> References: <728217.49487.qm@web36803.mail.mud.yahoo.com> <1248293107.28321.562.camel@moss-pluto.epoch.ncsc.mil> <1248293946.29571.9.camel@notebook2.grift.internal> Message-ID: <1248360219.28321.625.camel@moss-pluto.epoch.ncsc.mil> On Wed, 2009-07-22 at 22:19 +0200, Dominick Grift wrote: > On Wed, 2009-07-22 at 16:05 -0400, Stephen Smalley wrote: > > On Wed, 2009-07-22 at 12:57 -0700, Vadym Chepkov wrote: > > > You are right, these types are listed in /etc/selinux/targeted/contexts/customizable_types: > > > > > > .... > > > httpd_sys_content_t > > > httpd_sys_htaccess_t > > > httpd_sys_script_exec_t > > > httpd_sys_script_ra_t > > > httpd_sys_script_ro_t > > > httpd_sys_script_rw_t > > > httpd_unconfined_script_exec_t > > > .... > > > > > > May I ask, why do they set this way? > > > > Because users may choose to customize the labeling of their web > > hierarchy and we didn't want restorecon to clobber it. These days that > > isn't so necessary because users can use semanage fcontext -a to add > > entries for their customizations, and that is why customizable_types in > > F11 doesn't include those types. > > > > But should http_user_{content,content_rw,script_exec}_t not be > customizable types though? > > Afaik unpriv users cannot use semanage fcontext. What if a unpriv user > tries to configure a custom apache homedir for example (~/mywww) > > Will that not be relabeled upon restorecon -R -v /home? Good question. Dan? Policy access control, if it ever reaches maturity and integration, could possibly allow unprivileged users to add semanage fcontext entries for their own home directory contents. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Jul 23 18:00:57 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 23 Jul 2009 14:00:57 -0400 Subject: add a transition rule In-Reply-To: <635819.55557.qm@web36803.mail.mud.yahoo.com> References: <635819.55557.qm@web36803.mail.mud.yahoo.com> Message-ID: <4A68A559.9080003@redhat.com> On 07/19/2009 09:33 AM, Vadym Chepkov wrote: > I created httpd_svn_script_t for this exact purpose, I don't think another one is required. > > sendmail_domtrans(httpd_svn_script_t) is the rule then? > Thank you, I will try it. > > Sincerely yours, > Vadym Chepkov > > > --- On Sun, 7/19/09, Dominick Grift wrote: > >> From: Dominick Grift >> Subject: Re: add a transition rule >> To: "Vadym Chepkov" >> Cc: "Fedora SELinux" >> Date: Sunday, July 19, 2009, 7:06 AM >> On Sat, 2009-07-18 at 20:35 -0700, >> Vadym Chepkov wrote: >>> Hi, >>> >>> I have a script, executed by apache, which is running >> in httpd_svn_script_t domain. This script calls >> svn-mailer(bin_t) which in turns calls >> /usr/sbin/sendmail.sendmail(sendmail_exec_t) and since there >> is no transition defined, sendmail still runs in >> httpd_svn_script_t and I get humongous amount of avc's. What >> would be the proper rule to add to the local policy to make >> sendmail running in the proper domain, sendmail_t? >>> And for that matter if httpd_can_sendmail --> on, >> shouldn't it be happening automatically? Thank you. >> Not sure about all this (sesearch and review of source >> policy might >> reveal the answer). I am not in my usual location so i >> cannot verify at >> the moment, however my personal opinion is that you might >> as well write >> some policy yourself to make this happen. Those httpd >> booleans are >> generally coarse grained. >> >> If you write a policy for your script and do a transition >> from >> httpd_svn_script_t to myscript_t and than allow myscript_t >> to transition >> to the mail domain (probably something like >> sendmail_domtrans(myscript_t)). That way you do not pollute >> your >> httpd_svn_script_t domain too much with access vectors that >> are really >> meant for your script and not svn. >> >>> Sincerely yours, >>> Vadym Chepkov >>> >>> -- >>> 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 mta_send_mail is probably better, since it will cover all possible mailers, not just sendmail From dwalsh at redhat.com Thu Jul 23 20:05:02 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 23 Jul 2009 16:05:02 -0400 Subject: restorecon question In-Reply-To: <880775.73819.qm@web36807.mail.mud.yahoo.com> References: <880775.73819.qm@web36807.mail.mud.yahoo.com> Message-ID: <4A68C26E.1050408@redhat.com> On 07/22/2009 03:50 PM, Vadym Chepkov wrote: > No, it was httpd_sys_content_t > > Sincerely yours, > Vadym Chepkov > > > --- On Wed, 7/22/09, Eric Paris wrote: > >> From: Eric Paris >> Subject: Re: restorecon question >> To: "Vadym Chepkov" >> Cc: "Fedora SELinux" >> Date: Wednesday, July 22, 2009, 3:12 PM >> On Wed, 2009-07-22 at 11:06 -0700, >> Vadym Chepkov wrote: >>> Hi, >>> >>> Could you explain me, please, the behavior of the >> restorecon utility. >>> I added the following in the local.fc file >>> >>> # phpbb >>> /var/www/phpbb/cache(/.*)? >> >> gen_context(system_u:object_r:httpd_sys_script_rw_t,s0) >>> /var/www/phpbb/files(/.*)? >> >> gen_context(system_u:object_r:httpd_sys_script_rw_t,s0) >>> compiled and installed policy, seems to be in place. >>> >>> # semanage fcontext -l|grep phpbb >>> /var/www/phpbb/cache(/.*)? >> >> all files >> system_u:object_r:httpd_sys_script_rw_t:s0 >>> /var/www/phpbb/files(/.*)? >> >> all files >> system_u:object_r:httpd_sys_script_rw_t:s0 >>> But when now I run restorecon -vR /var/www/phpbb/ >>> it doesn't do anything. I would expect it to changed >> context on two directories and files in them. >> >> What was the context before? Was the only difference >> the 'user' >> portion? I don't think restorecon bothers to reset >> the context if the >> only thing 'wrong' is the user, since the user is not >> relevant to any >> security operations.... >> >> > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list customizable_types was the problem. You need to use the -F to override customizable_types. From dwalsh at redhat.com Thu Jul 23 20:07:36 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 23 Jul 2009 16:07:36 -0400 Subject: postfix_smtp_t In-Reply-To: <1248339789.2519.9.camel@choeger6> References: <1248339789.2519.9.camel@choeger6> Message-ID: <4A68C308.6070701@redhat.com> On 07/23/2009 05:03 AM, Christoph H?ger wrote: > Hi, > > this is a rather special use case, but I think it is valid. According to > Pauls hints at > http://marilyn.frields.org:8080/~paul/wordpress/?p=2616 > I configured postfix to relay my local mail via some mail servers. But > since I like a clean approach I did not want the sasl_password files > in /etc/ so that the admin (me) has to handle plain text passwords > there. > > Postfix seems to support multiple db files at arbitrary positions. But > SELinux does not. I guess the transition to postfix_smtp_t is a little > too early (before chroot). So I changed the context of my sasl_passwd > files to postfix_smtp_t, just to notice that: > > 1. I (as a user) cannot do this > 2. After I did it nevertheless I cannot edit those files > > So here is my proposal: > > Introduce postfix_userconfig_t and let postfix_smtp_t read it, and allow > transitions and read/write access from unconfined_t to it. I know that > this is suboptimal because it effectively becomes unconfinded_t, but > since the admin _must_ add those files to /etc/postfix/main.cf (and > should allow only harmless files) I guess that this is ok. > > any objections or shall I try to write a patch for the policy? > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list What was the AVC you were seeing that caused you to make this change? From dwalsh at redhat.com Thu Jul 23 21:18:40 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 23 Jul 2009 17:18:40 -0400 Subject: restorecon question In-Reply-To: <1248360219.28321.625.camel@moss-pluto.epoch.ncsc.mil> References: <728217.49487.qm@web36803.mail.mud.yahoo.com> <1248293107.28321.562.camel@moss-pluto.epoch.ncsc.mil> <1248293946.29571.9.camel@notebook2.grift.internal> <1248360219.28321.625.camel@moss-pluto.epoch.ncsc.mil> Message-ID: <4A68D3B0.1060003@redhat.com> On 07/23/2009 10:43 AM, Stephen Smalley wrote: > On Wed, 2009-07-22 at 22:19 +0200, Dominick Grift wrote: >> On Wed, 2009-07-22 at 16:05 -0400, Stephen Smalley wrote: >>> On Wed, 2009-07-22 at 12:57 -0700, Vadym Chepkov wrote: >>>> You are right, these types are listed in /etc/selinux/targeted/contexts/customizable_types: >>>> >>>> .... >>>> httpd_sys_content_t >>>> httpd_sys_htaccess_t >>>> httpd_sys_script_exec_t >>>> httpd_sys_script_ra_t >>>> httpd_sys_script_ro_t >>>> httpd_sys_script_rw_t >>>> httpd_unconfined_script_exec_t >>>> .... >>>> >>>> May I ask, why do they set this way? >>> Because users may choose to customize the labeling of their web >>> hierarchy and we didn't want restorecon to clobber it. These days that >>> isn't so necessary because users can use semanage fcontext -a to add >>> entries for their customizations, and that is why customizable_types in >>> F11 doesn't include those types. >>> >> But should http_user_{content,content_rw,script_exec}_t not be >> customizable types though? >> >> Afaik unpriv users cannot use semanage fcontext. What if a unpriv user >> tries to configure a custom apache homedir for example (~/mywww) >> >> Will that not be relabeled upon restorecon -R -v /home? > > Good question. Dan? > > Policy access control, if it ever reaches maturity and integration, > could possibly allow unprivileged users to add semanage fcontext entries > for their own home directory contents. > Dominick has a good point. I was thinking only in terms of administrators. I will fix in Rawhide. svirt_image_t virt_content_t httpd_user_htaccess_t httpd_user_script_exec_t httpd_user_content_ra_t httpd_user_content_rw_t httpd_user_content_t From choeger at cs.tu-berlin.de Thu Jul 23 22:00:01 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Fri, 24 Jul 2009 00:00:01 +0200 Subject: postfix_smtp_t In-Reply-To: <4A68C308.6070701@redhat.com> References: <1248339789.2519.9.camel@choeger6> <4A68C308.6070701@redhat.com> Message-ID: <1248386401.2519.27.camel@choeger6> Hi Dan, I got something like: type=SYSCALL msg=audit(1248337552.277:51): arch=40000003 syscall=5 success=yes exit=9 a0=2590dd8 a1=8000 a2=0 a3=0 items=0 ppid=3929 pid=3934 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="smtp" exe="/usr/libexec/postfix/smtp" subj=unconfined_u:system_r:postfix_smtp_t:s0 key=(null) type=AVC msg=audit(1248337552.277:52): avc: denied { lock } for pid=3934 comm="smtp" path="/home/choeger/cert/sasl_passwd.db" dev=dm-1 ino=2976113 scontext=unconfined_u:system_r:postfix_smtp_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file (that's just a simple example) Basically postfix_smtp_t and user_home_t do not play nice - which is not a big surprise since that is what confinement is all about, but I wish there would be a way to handle that use case. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From frankly3d at gmail.com Fri Jul 24 16:48:16 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Fri, 24 Jul 2009 17:48:16 +0100 Subject: Rawhide F12 and Skype AVC Message-ID: <4A69E5D0.8060400@gmail.com> Following is AVC Do I replace '' with skype? > Summary: > > SELinux is preventing skype from changing a writable memory segment executable. > > Detailed Description: > > The skype application attempted to change the access protection of memory (e.g., > allocated using malloc). This is a potential security problem. Applications > should not be doing this. Applications are sometimes coded incorrectly and > request this permission. The SELinux Memory Protection Tests > (http://people.redhat.com/drepper/selinux-mem.html) web page explains how to > remove this requirement. If skype does not work and you need it to work, you can > configure SELinux temporarily to allow this access until the application is > fixed. Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. > > Allowing Access: > > If you trust skype to run correctly, you can change the context of the > executable to execmem_exec_t. "chcon -t execmem_exec_t ''". You must > also change the default file context files on the system in order to preserve > them even on a full relabel. "semanage fcontext -a -t execmem_exec_t ''" > > Fix Command: > > chcon -t execmem_exec_t '' > > Additional Information: > > Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 > 023 > Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 > 023 > Target Objects None [ process ] > Source skype > Source Path > Port > Host (removed) > Source RPM Packages > Target RPM Packages > Policy RPM selinux-policy-3.6.22-2.fc12 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name allow_execmem > Host Name (removed) > Platform Linux internet01.frankly3d.local > 2.6.31-0.86.rc3.git5.fc12.x86_64 #1 SMP Wed Jul 22 > 15:31:34 EDT 2009 x86_64 x86_64 > Alert Count 1 > First Seen Fri 24 Jul 2009 17:38:51 IST > Last Seen Fri 24 Jul 2009 17:38:51 IST > Local ID 6c5beb61-0671-4497-b86d-cd1bf0944901 > Line Numbers > > Raw Audit Messages > > node=internet01.frankly3d.local type=AVC msg=audit(1248453531.351:24900): avc: denied { execmem } for pid=2079 comm="skype" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process > > node=internet01.frankly3d.local type=SYSCALL msg=audit(1248453531.351:24900): arch=c000003e syscall=59 per=400000 success=no exit=-13 a0=1dae08f a1=1c0bcd0 a2=7fff70be3b38 a3=7fff70be2410 items=0 ppid=2078 pid=2079 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="skype" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) > > -- Regards, Frank jabber | msn | skype: frankly3d http://www.frankly3d.com From domg472 at gmail.com Fri Jul 24 16:55:43 2009 From: domg472 at gmail.com (Dominick Grift) Date: Fri, 24 Jul 2009 18:55:43 +0200 Subject: Rawhide F12 and Skype AVC In-Reply-To: <4A69E5D0.8060400@gmail.com> References: <4A69E5D0.8060400@gmail.com> Message-ID: <1248454543.8562.1.camel@notebook2.grift.internal> On Fri, 2009-07-24 at 17:48 +0100, Frank Murphy wrote: > Following is AVC > Do I replace '' with skype? > > > > Summary: > > > > SELinux is preventing skype from changing a writable memory segment executable. > > > > Detailed Description: > > > > The skype application attempted to change the access protection of memory (e.g., > > allocated using malloc). This is a potential security problem. Applications > > should not be doing this. Applications are sometimes coded incorrectly and > > request this permission. The SELinux Memory Protection Tests > > (http://people.redhat.com/drepper/selinux-mem.html) web page explains how to > > remove this requirement. If skype does not work and you need it to work, you can > > configure SELinux temporarily to allow this access until the application is > > fixed. Please file a bug report > > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. > > > > Allowing Access: > > > > If you trust skype to run correctly, you can change the context of the > > executable to execmem_exec_t. "chcon -t execmem_exec_t ''". You must > > also change the default file context files on the system in order to preserve > > them even on a full relabel. "semanage fcontext -a -t execmem_exec_t ''" > > > > Fix Command: > > > > chcon -t execmem_exec_t '' > > > > Additional Information: > > > > Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 > > 023 > > Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 > > 023 > > Target Objects None [ process ] > > Source skype > > Source Path > > Port > > Host (removed) > > Source RPM Packages > > Target RPM Packages > > Policy RPM selinux-policy-3.6.22-2.fc12 > > Selinux Enabled True > > Policy Type targeted > > MLS Enabled True > > Enforcing Mode Enforcing > > Plugin Name allow_execmem > > Host Name (removed) > > Platform Linux internet01.frankly3d.local > > 2.6.31-0.86.rc3.git5.fc12.x86_64 #1 SMP Wed Jul 22 > > 15:31:34 EDT 2009 x86_64 x86_64 > > Alert Count 1 > > First Seen Fri 24 Jul 2009 17:38:51 IST > > Last Seen Fri 24 Jul 2009 17:38:51 IST > > Local ID 6c5beb61-0671-4497-b86d-cd1bf0944901 > > Line Numbers > > > > Raw Audit Messages > > > > node=internet01.frankly3d.local type=AVC msg=audit(1248453531.351:24900): avc: denied { execmem } for pid=2079 comm="skype" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process > > > > node=internet01.frankly3d.local type=SYSCALL msg=audit(1248453531.351:24900): arch=c000003e syscall=59 per=400000 success=no exit=-13 a0=1dae08f a1=1c0bcd0 a2=7fff70be3b38 a3=7fff70be2410 items=0 ppid=2078 pid=2079 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="skype" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) > > > > Yes: semanage fcontext -a -t execmem_exec_t /path/to/skype restorecon -v /path/to/skype where "/path/to/skype" is the path to the skype executable file. -------------- 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 ekuns at kilroy.chi.il.us Sat Jul 25 16:41:11 2009 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Sat, 25 Jul 2009 11:41:11 -0500 Subject: SELinux is preventing clamd.scan (system_cronjob_t) "write" crond_t In-Reply-To: <4A65AD2D.10608@redhat.com> References: <1248149935.26733.30.camel@kilroy.chi.il.us> <4A65AD2D.10608@redhat.com> Message-ID: <1248540071.7814.4.camel@kilroy.chi.il.us> On 07/21/2009 12:18 AM, Edward Kuns wrote: > Just in the past few days I've received seven of this AVC complaint, and > I haven't seen any of this complaint before that. On Tue, 2009-07-21 at 07:57 -0400, Daniel J Walsh wrote: > This looks like a MCS constraint problem. And looking at current selinux policy it should be fixed. > > Can you upgrade to the latest selinux policy in testing? I was able to apply this upgrade. I currently have selinux-policy-3.6.12-69.fc11.noarch selinux-policy-targeted-3.6.12-69.fc11.noarch if I don't see this AVC for a week, then I can be sure that the problem was fixed. Thanks. Eddie From dwalsh at redhat.com Mon Jul 27 12:54:21 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 27 Jul 2009 08:54:21 -0400 Subject: Rawhide F12 and Skype AVC In-Reply-To: <1248454543.8562.1.camel@notebook2.grift.internal> References: <4A69E5D0.8060400@gmail.com> <1248454543.8562.1.camel@notebook2.grift.internal> Message-ID: <4A6DA37D.9060605@redhat.com> On 07/24/2009 12:55 PM, Dominick Grift wrote: > On Fri, 2009-07-24 at 17:48 +0100, Frank Murphy wrote: >> Following is AVC >> Do I replace '' with skype? >> >> >>> Summary: >>> >>> SELinux is preventing skype from changing a writable memory segment executable. >>> >>> Detailed Description: >>> >>> The skype application attempted to change the access protection of memory (e.g., >>> allocated using malloc). This is a potential security problem. Applications >>> should not be doing this. Applications are sometimes coded incorrectly and >>> request this permission. The SELinux Memory Protection Tests >>> (http://people.redhat.com/drepper/selinux-mem.html) web page explains how to >>> remove this requirement. If skype does not work and you need it to work, you can >>> configure SELinux temporarily to allow this access until the application is >>> fixed. Please file a bug report >>> (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. >>> >>> Allowing Access: >>> >>> If you trust skype to run correctly, you can change the context of the >>> executable to execmem_exec_t. "chcon -t execmem_exec_t ''". You must >>> also change the default file context files on the system in order to preserve >>> them even on a full relabel. "semanage fcontext -a -t execmem_exec_t ''" >>> >>> Fix Command: >>> >>> chcon -t execmem_exec_t '' >>> >>> Additional Information: >>> >>> Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 >>> 023 >>> Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 >>> 023 >>> Target Objects None [ process ] >>> Source skype >>> Source Path >>> Port >>> Host (removed) >>> Source RPM Packages >>> Target RPM Packages >>> Policy RPM selinux-policy-3.6.22-2.fc12 >>> Selinux Enabled True >>> Policy Type targeted >>> MLS Enabled True >>> Enforcing Mode Enforcing >>> Plugin Name allow_execmem >>> Host Name (removed) >>> Platform Linux internet01.frankly3d.local >>> 2.6.31-0.86.rc3.git5.fc12.x86_64 #1 SMP Wed Jul 22 >>> 15:31:34 EDT 2009 x86_64 x86_64 >>> Alert Count 1 >>> First Seen Fri 24 Jul 2009 17:38:51 IST >>> Last Seen Fri 24 Jul 2009 17:38:51 IST >>> Local ID 6c5beb61-0671-4497-b86d-cd1bf0944901 >>> Line Numbers >>> >>> Raw Audit Messages >>> >>> node=internet01.frankly3d.local type=AVC msg=audit(1248453531.351:24900): avc: denied { execmem } for pid=2079 comm="skype" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process >>> >>> node=internet01.frankly3d.local type=SYSCALL msg=audit(1248453531.351:24900): arch=c000003e syscall=59 per=400000 success=no exit=-13 a0=1dae08f a1=1c0bcd0 a2=7fff70be3b38 a3=7fff70be2410 items=0 ppid=2078 pid=2079 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="skype" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) >>> >>> > Yes: > > semanage fcontext -a -t execmem_exec_t /path/to/skype > restorecon -v /path/to/skype > > where "/path/to/skype" is the path to the skype executable file. > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Please open a bugzilla on skype saying that apps should not require execmem privs to run. Attach the following link. http://people.redhat.com/~drepper/selinux-mem.html From dwalsh at redhat.com Mon Jul 27 13:08:05 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 27 Jul 2009 09:08:05 -0400 Subject: postfix_smtp_t In-Reply-To: <1248386401.2519.27.camel@choeger6> References: <1248339789.2519.9.camel@choeger6> <4A68C308.6070701@redhat.com> <1248386401.2519.27.camel@choeger6> Message-ID: <4A6DA6B5.4000300@redhat.com> On 07/23/2009 06:00 PM, Christoph H?ger wrote: > Hi Dan, > > I got something like: > > type=SYSCALL msg=audit(1248337552.277:51): arch=40000003 syscall=5 > success=yes exit=9 a0=2590dd8 a1=8000 a2=0 a3=0 items=0 ppid=3929 > pid=3934 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=(none) ses=1 comm="smtp" exe="/usr/libexec/postfix/smtp" > subj=unconfined_u:system_r:postfix_smtp_t:s0 key=(null) > type=AVC msg=audit(1248337552.277:52): avc: denied { lock } for > pid=3934 comm="smtp" path="/home/choeger/cert/sasl_passwd.db" dev=dm-1 > ino=2976113 scontext=unconfined_u:system_r:postfix_smtp_t:s0 > tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file > > (that's just a simple example) > > Basically postfix_smtp_t and user_home_t do not play nice - which is not > a big surprise since that is what confinement is all about, but I wish > there would be a way to handle that use case. > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list THe best thing for something like this is to set the labeling. If you want to have certificates in your homedir, you need to set the labeling to something like cert_t. # semanage fcontext -a -t cert_t '/home/choeger/cert(/.*)?' # restorecon -R -v /home/choeger/cert Should fix. From frankly3d at gmail.com Mon Jul 27 13:13:20 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Mon, 27 Jul 2009 14:13:20 +0100 Subject: Rawhide F12 and Skype AVC In-Reply-To: <4A6DA37D.9060605@redhat.com> References: <4A69E5D0.8060400@gmail.com> <1248454543.8562.1.camel@notebook2.grift.internal> <4A6DA37D.9060605@redhat.com> Message-ID: <4A6DA7F0.90804@gmail.com> On 27/07/09 13:54, Daniel J Walsh wrote: > Please open a bugzilla on skype saying that apps should not require execmem privs to run. > > Attach the following link. > > http://people.redhat.com/~drepper/selinux-mem.html Done: https://developer.skype.com/jira/browse/SCL-501 From paul at city-fan.org Tue Jul 28 13:46:47 2009 From: paul at city-fan.org (Paul Howarth) Date: Tue, 28 Jul 2009 14:46:47 +0100 Subject: add a transition rule In-Reply-To: <606582.36904.qm@web36801.mail.mud.yahoo.com> References: <606582.36904.qm@web36801.mail.mud.yahoo.com> Message-ID: <4A6F0147.9030606@city-fan.org> Hi Vadym, On 19/07/09 04:35, Vadym Chepkov wrote: > I have a script, executed by apache, which is running in httpd_svn_script_t domain. This script calls svn-mailer(bin_t) which in turns calls /usr/sbin/sendmail.sendmail(sendmail_exec_t) and since there is no transition defined, sendmail still runs in httpd_svn_script_t and I get humongous amount of avc's. What would be the proper rule to add to the local policy to make sendmail running in the proper domain, sendmail_t? > And for that matter if httpd_can_sendmail --> on, shouldn't it be happening automatically? Thank you. > > Sincerely yours, > Vadym Chepkov I'm just back off vacation and saw your email. Funnily enough I wrote an svnmailer policy a few weeks ago, so it would be interesting to compare notes: I've actually split it into two modules, svnmailer for the policy itself, and svnmailer-extras for additional interfaces needed in other policy modules. I find this arrangement is easier to manage when getting policy merged upstream. I made my hook scripts httpd_sys_script_exec_t and transition from there to httpd_svnmailer_script_t via a domtrans. The svn repository itself is httpd_sys_content_rw_t. Paul. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: svnmailer.fc URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: svnmailer.if URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: svnmailer.te URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: svnmailer-extras.fc URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: svnmailer-extras.if URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: svnmailer-extras.te URL: From cliffe at ii.net Thu Jul 30 04:04:40 2009 From: cliffe at ii.net (Cliffe) Date: Thu, 30 Jul 2009 12:04:40 +0800 Subject: Help with SELinux Policy for Usability Study Message-ID: <4A711BD8.2080709@ii.net> Dear SELinux Gurus, I am a PhD candidate conducting research into the usability of security mechanisms. I would really appreciate some help regarding the use of SELinux. Let me know if this is not the right place to be asking these types of questions. I generated a policy for opera using polgengui. I then ran the generated ./opera.sh. Although SELinux was still set to enforcing mode opera seemed to run unconfined. The executable and process was labelled as expected (unconfined_u:unconfined_r:opera_t). AVCs were generated, but not enforced. I added to opera.te using grep opera /var/log/audit/audit.log | audit2allow >> opera.te and reran ./opera.sh until no AVCs were generated. Looking at opera.te I noticed the line "permissive opera_t", and not knowing exactly what this line does, I thought it may be placing this domain into permissive mode (although the gui tools suggest otherwise). Removing the line causes "/bin/sh: /usr/bin/opera: Permission denied". No AVCs are generated. So I am not sure why opera seams to be unconfined, or if removing the permissive line was on the right track. Any advice? Also I tried creating a policy for kwrite. This time the created policy seemed to be in effect as soon as I ran the kwrite.sh script. I set setenforce 0 and added to kwrite.te (as above for opera) until no error msgs were generated. Then I reran ./kwrite.sh. Now kwrite exists with "kwrite(2533): Couldn't register name '"org.kate-editor.kwrite-2533'" with DBUS -- another process owns it already!". When setenforce 0 it runs without AVCs. Again I am sure I am missing something simple and your advice will help a lot. I need to resolve this asap and will really appreciate any advice. Soon I will be running a comparative study comparing a number of security mechanisms and I need to sort this out. Thank you, Cliffe. -------------- next part -------------- An HTML attachment was scrubbed... URL: From domg472 at gmail.com Thu Jul 30 08:44:04 2009 From: domg472 at gmail.com (Dominick Grift) Date: Thu, 30 Jul 2009 10:44:04 +0200 Subject: Help with SELinux Policy for Usability Study In-Reply-To: <4A711BD8.2080709@ii.net> References: <4A711BD8.2080709@ii.net> Message-ID: <1248943444.14879.6.camel@notebook2.grift.internal> On Thu, 2009-07-30 at 12:04 +0800, Cliffe wrote: > Dear SELinux Gurus, > > I am a PhD candidate conducting research into the usability of > security mechanisms. I would really appreciate some help regarding the > use of SELinux. Let me know if this is not the right place to be > asking these types of questions. > > I generated a policy for opera using polgengui. I then ran the > generated ./opera.sh. > > Although SELinux was still set to enforcing mode opera seemed to run > unconfined. The executable and process was labelled as expected > (unconfined_u:unconfined_r:opera_t). AVCs were generated, but not > enforced. > > I added to opera.te using > grep opera /var/log/audit/audit.log | audit2allow >> opera.te > and reran ./opera.sh > until no AVCs were generated. > > Looking at opera.te I noticed the line ?permissive opera_t?, and not > knowing exactly what this line does, I thought it may be placing this > domain into permissive mode (although the gui tools suggest > otherwise). Removing the line causes ?/bin/sh: /usr/bin/opera: > Permission denied?. No AVCs are generated. Yes permissive opera_t makes opera_t a permissive domain indeed. To expose any possible hidden denials run: semodule -DB To hide them again: semodule -B > So I am not sure why opera seams to be unconfined, or if removing the > permissive line was on the right track. Any advice? > > Also I tried creating a policy for kwrite. This time the created > policy seemed to be in effect as soon as I ran the kwrite.sh script. I > set setenforce 0 and added to kwrite.te (as above for opera) until no > error msgs were generated. Then I reran ./kwrite.sh. Now kwrite exists > with ?kwrite(2533): Couldn?t register name > ??org.kate-editor.kwrite-2533?? with DBUS ? another process owns it > already!?. When setenforce 0 it runs without AVCs. This is probably a DBUS issue. DBUS is a SELinux object manager. This means that DBUS itself provides classes and permission for some of its objects. Dbus also enforces policy for these objects. DBUS logs some user avc denials in audit.log (ausearch -m user_avc -ts today | grep dbus) DBUS also logs some denials in /var/log/messages. > Again I am sure I am missing something simple and your advice will > help a lot. > > I need to resolve this asap and will really appreciate any advice. > > Soon I will be running a comparative study comparing a number of > security mechanisms and I need to sort this out. Good luck. On a unrelated note: I recently created a extensive series of screencasts showing how to confine a GUI app with SELinux (google-gadgets) http://www.youtube.com/results?search_query=SELinux+confine+a+GUI+app > Thank you, > > Cliffe. > > -- > 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: 197 bytes Desc: This is a digitally signed message part URL: From frankly3d at gmail.com Thu Jul 30 08:49:30 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Thu, 30 Jul 2009 09:49:30 +0100 Subject: Selinux Audit "Unmatched Entries"? Message-ID: <4A715E9A.8050304@gmail.com> Waht does all this mean from logwatch, What are in plain speak unmatched entries? --------------------- Selinux Audit Begin ------------------------ Number of audit daemon starts: 5 Number of audit daemon stops: 6 **Unmatched Entries** audit(1248863231.539:55834): auid=4294967295 ses=4294967295 subj=system_u:system_r:readahead_t:s0 op=remove rule key=(null) list=2 res=1 audit(1248863231.539:55835): audit_enabled=0 old=1 auid=4294967295 ses=4294967295 subj=system_u:system_r:readahead_t:s0 res=1 audit(1248865986.300:28653): auid=4294967295 ses=4294967295 subj=system_u:system_r:readahead_t:s0 op=remove rule key=(null) list=2 res=1 audit(1248865986.300:28654): audit_enabled=0 old=1 auid=4294967295 ses=4294967295 subj=system_u:system_r:readahead_t:s0 res=1 audit(1248867118.172:28695): auid=4294967295 ses=4294967295 subj=system_u:system_r:readahead_t:s0 op=remove rule key=(null) list=2 res=1 audit(1248867118.172:28696): audit_enabled=0 old=1 auid=4294967295 ses=4294967295 subj=system_u:system_r:readahead_t:s0 res=1 config change requested by pid=9598 auid=500 subj=unconfined_u:system_r:initrc_t:s0 audit(1248871767.418:3339) config changed, auid=500 pid=9598 subj=unconfined_u:system_r:initrc_t:s0 res=success ---------------------- Selinux Audit End ------------------------- -- Regards, Frank jabber | msn | skype: frankly3d http://www.frankly3d.com From domg472 at gmail.com Thu Jul 30 09:15:54 2009 From: domg472 at gmail.com (Dominick Grift) Date: Thu, 30 Jul 2009 11:15:54 +0200 Subject: Help with SELinux Policy for Usability Study In-Reply-To: <4A711BD8.2080709@ii.net> References: <4A711BD8.2080709@ii.net> Message-ID: <1248945354.14879.10.camel@notebook2.grift.internal> On Thu, 2009-07-30 at 12:04 +0800, Cliffe wrote: > So I am not sure why opera seams to be unconfined, or if removing the > permissive line was on the right track. Any advice? permissive domains can be used to troubleshoot/develop policy, without exposing the whole system. eventually, after you've completed the development of your policy , and before you deploy your policy you should remove the permissive domain. But in development stages a permissive domain makes it easier to debug your policy since everything is allowed but would be denials are logged. > Thank you, > > Cliffe. > > -- > 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: 197 bytes Desc: This is a digitally signed message part URL: From txtoth at gmail.com Thu Jul 30 14:00:57 2009 From: txtoth at gmail.com (Xavier Toth) Date: Thu, 30 Jul 2009 09:00:57 -0500 Subject: latest fc10 kernel and policy seem to be out of sync (kernel_service) Message-ID: With kernel-2.6.29.6-93.fc10 we are seeing errors in dmesg about kernel_service class not defined in policy. Looking at the selinux-policy source I find no definition of this class. Ted From dwalsh at redhat.com Thu Jul 30 14:05:52 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 30 Jul 2009 10:05:52 -0400 Subject: Selinux Audit "Unmatched Entries"? In-Reply-To: <4A715E9A.8050304@gmail.com> References: <4A715E9A.8050304@gmail.com> Message-ID: <4A71A8C0.7040403@redhat.com> On 07/30/2009 04:49 AM, Frank Murphy wrote: > Waht does all this mean from logwatch, > What are in plain speak unmatched entries? > > > --------------------- Selinux Audit Begin ------------------------ > > Number of audit daemon starts: 5 > > Number of audit daemon stops: 6 > > **Unmatched Entries** > audit(1248863231.539:55834): auid=4294967295 ses=4294967295 > subj=system_u:system_r:readahead_t:s0 op=remove rule key=(null) list=2 > res=1 > audit(1248863231.539:55835): audit_enabled=0 old=1 auid=4294967295 > ses=4294967295 subj=system_u:system_r:readahead_t:s0 res=1 > audit(1248865986.300:28653): auid=4294967295 ses=4294967295 > subj=system_u:system_r:readahead_t:s0 op=remove rule key=(null) list=2 > res=1 > audit(1248865986.300:28654): audit_enabled=0 old=1 auid=4294967295 > ses=4294967295 subj=system_u:system_r:readahead_t:s0 res=1 > audit(1248867118.172:28695): auid=4294967295 ses=4294967295 > subj=system_u:system_r:readahead_t:s0 op=remove rule key=(null) list=2 > res=1 > audit(1248867118.172:28696): audit_enabled=0 old=1 auid=4294967295 > ses=4294967295 subj=system_u:system_r:readahead_t:s0 res=1 > config change requested by pid=9598 auid=500 > subj=unconfined_u:system_r:initrc_t:s0 > audit(1248871767.418:3339) config changed, auid=500 pid=9598 > subj=unconfined_u:system_r:initrc_t:s0 res=success > > ---------------------- Selinux Audit End ------------------------- > These are audit messages, not SELinux AVC messages or any kind of SELinux message. From frankly3d at gmail.com Thu Jul 30 14:08:16 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Thu, 30 Jul 2009 15:08:16 +0100 Subject: Selinux Audit "Unmatched Entries"? In-Reply-To: <4A71A8C0.7040403@redhat.com> References: <4A715E9A.8050304@gmail.com> <4A71A8C0.7040403@redhat.com> Message-ID: <4A71A950.6020106@gmail.com> On 30/07/09 15:05, Daniel J Walsh wrote: > On 07/30/2009 04:49 AM, Frank Murphy wrote: >> Waht does all this mean from logwatch, >> What are in plain speak unmatched entries? >> >> --SNIP-- >> > These are audit messages, not SELinux AVC messages or any kind of SELinux message. They can be safely ignored then From dwalsh at redhat.com Thu Jul 30 14:09:39 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 30 Jul 2009 10:09:39 -0400 Subject: Help with SELinux Policy for Usability Study In-Reply-To: <1248945354.14879.10.camel@notebook2.grift.internal> References: <4A711BD8.2080709@ii.net> <1248945354.14879.10.camel@notebook2.grift.internal> Message-ID: <4A71A9A3.7040000@redhat.com> On 07/30/2009 05:15 AM, Dominick Grift wrote: > On Thu, 2009-07-30 at 12:04 +0800, Cliffe wrote: > >> So I am not sure why opera seams to be unconfined, or if removing the >> permissive line was on the right track. Any advice? > permissive domains can be used to troubleshoot/develop policy, without > exposing the whole system. > > eventually, after you've completed the development of your policy , and > before you deploy your policy you should remove the permissive domain. > > But in development stages a permissive domain makes it easier to debug > your policy since everything is allowed but would be denials are logged. > > >> Thank you, >> >> Cliffe. >> >> -- >> 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 Cliffe if you remove the permissive line from your te file, SELinux will enforce the policy, however opera will probably crash. We default to permissive domains when we are building new policy modules, to allow you to record what an application does, and use tools like audit2allow to generate allow rules. Sort of a learning mode. I would not have picked a tool like opera to build policy for, since it is very difficult to confine web browsers. They are too integrated into the system. You end up basically creating a usr role since the web browser tends to need to do everything the user can do. From cliffe at ii.net Thu Jul 30 14:17:07 2009 From: cliffe at ii.net (Cliffe) Date: Thu, 30 Jul 2009 22:17:07 +0800 Subject: Help with SELinux Policy for Usability Study In-Reply-To: <4A71A9A3.7040000@redhat.com> References: <4A711BD8.2080709@ii.net> <1248945354.14879.10.camel@notebook2.grift.internal> <4A71A9A3.7040000@redhat.com> Message-ID: <4A71AB63.2060303@ii.net> Daniel J Walsh wrote: > On 07/30/2009 05:15 AM, Dominick Grift wrote: > >> On Thu, 2009-07-30 at 12:04 +0800, Cliffe wrote: >> >> >>> So I am not sure why opera seams to be unconfined, or if removing the >>> permissive line was on the right track. Any advice? >>> >> permissive domains can be used to troubleshoot/develop policy, without >> exposing the whole system. >> >> eventually, after you've completed the development of your policy , and >> before you deploy your policy you should remove the permissive domain. >> >> But in development stages a permissive domain makes it easier to debug >> your policy since everything is allowed but would be denials are logged. >> >> >> >>> Thank you, >>> >>> Cliffe. >>> >>> -- >>> 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 >>> > Cliffe if you remove the permissive line from your te file, SELinux will enforce the policy, however opera will probably crash. > > We default to permissive domains when we are building new policy modules, to allow you to record what an application does, and use tools like audit2allow to generate allow rules. Sort of a learning mode. > > I would not have picked a tool like opera to build policy for, since it is very difficult to confine web browsers. They are too integrated into the system. You end up basically creating a usr role since the web browser tends to need to do everything the user can do. > Thanks Dan. I like your polgengui tool. It makes the process of creating SELinux policies less daunting. When it creates the .te .if and .fc files it says that the next step would be to put the system into permissive mode with setenforce 0. However, it should probably tell the user that the new policy will be in a permissive domain. I agree that creating a policy for opera is not easy, but it would be a good idea to restrict its actions where possible. My usability study will involve users using SELinux and your tool (I think it looks simpler than slide), as well as a couple of other systems. I'll let you know of the results when the study is complete later this year. Thanks, Cliffe. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Thu Jul 30 17:34:23 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 30 Jul 2009 13:34:23 -0400 Subject: Selinux Audit "Unmatched Entries"? In-Reply-To: <4A71A950.6020106@gmail.com> References: <4A715E9A.8050304@gmail.com> <4A71A8C0.7040403@redhat.com> <4A71A950.6020106@gmail.com> Message-ID: <4A71D99F.1090204@redhat.com> On 07/30/2009 10:08 AM, Frank Murphy wrote: > On 30/07/09 15:05, Daniel J Walsh wrote: >> On 07/30/2009 04:49 AM, Frank Murphy wrote: >>> Waht does all this mean from logwatch, >>> What are in plain speak unmatched entries? >>> >>> > --SNIP-- >>> >> These are audit messages, not SELinux AVC messages or any kind of >> SELinux message. > > They can be safely ignored then > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Yes these messages are the audit system telling you that readahead added an removed some rules to the audit system at boot time. I believe readahead now adds a rule to watch for all file opens at boot until it is finished, it then records the file opens and saves them, to reconfigure itself for the next boot, to be more efficient. Your mileage may vary. So I think whatever is searching for these rules should ignore them as expected. From cpardy at redhat.com Thu Jul 30 20:59:17 2009 From: cpardy at redhat.com (Christopher Pardy) Date: Thu, 30 Jul 2009 16:59:17 -0400 Subject: Help with SELinux Policy for Usability Study In-Reply-To: <4A71AB63.2060303@ii.net> References: <4A711BD8.2080709@ii.net> <1248945354.14879.10.camel@notebook2.grift.internal> <4A71A9A3.7040000@redhat.com> <4A71AB63.2060303@ii.net> Message-ID: <4A7209A5.80205@redhat.com> On 07/30/2009 10:17 AM, Cliffe wrote: > > > Daniel J Walsh wrote: >> On 07/30/2009 05:15 AM, Dominick Grift wrote: >> >>> On Thu, 2009-07-30 at 12:04 +0800, Cliffe wrote: >>> >>> >>>> So I am not sure why opera seams to be unconfined, or if removing the >>>> permissive line was on the right track. Any advice? >>>> >>> permissive domains can be used to troubleshoot/develop policy, without >>> exposing the whole system. >>> >>> eventually, after you've completed the development of your policy , and >>> before you deploy your policy you should remove the permissive domain. >>> >>> But in development stages a permissive domain makes it easier to debug >>> your policy since everything is allowed but would be denials are logged. >>> >>> >>> >>>> Thank you, >>>> >>>> Cliffe. >>>> >>>> -- >>>> 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 >>>> >> Cliffe if you remove the permissive line from your te file, SELinux will enforce the policy, however opera will probably crash. >> >> We default to permissive domains when we are building new policy modules, to allow you to record what an application does, and use tools like audit2allow to generate allow rules. Sort of a learning mode. >> >> I would not have picked a tool like opera to build policy for, since it is very difficult to confine web browsers. They are too integrated into the system. You end up basically creating a usr role since the web browser tends to need to do everything the user can do. >> > Thanks Dan. > > I like your polgengui tool. It makes the process of creating SELinux > policies less daunting. > > When it creates the .te .if and .fc files it says that the next step > would be to put the system into permissive mode with setenforce 0. > However, it should probably tell the user that the new policy will be in > a permissive domain. > > I agree that creating a policy for opera is not easy, but it would be a > good idea to restrict its actions where possible. > > My usability study will involve users using SELinux and your tool (I > think it looks simpler than slide), as well as a couple of other systems. > > I'll let you know of the results when the study is complete later this year. > > Thanks, > > Cliffe. > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Cliffe Please CC me any results you find as well as any issues with the gui tools as I'm revamping them for F12. Christopher Pardy From chepkov at yahoo.com Fri Jul 31 02:38:00 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Thu, 30 Jul 2009 19:38:00 -0700 (PDT) Subject: ausearch and terminal Message-ID: <252927.36750.qm@web36802.mail.mud.yahoo.com> Hi, I observe a very strange behavior of the ausearch utility. audit-1.7.7-6.el5_3.3 # cat /root/bin/autest.sh /sbin/ausearch -m avc| wc -l If I run it, I get expected results: # /root/bin/autest.sh 1563 But if I run it from cron, I get this in e-mail: 0 Why?? Sincerely yours, Vadym Chepkov From dwalsh at redhat.com Fri Jul 31 12:42:08 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 31 Jul 2009 08:42:08 -0400 Subject: ausearch and terminal In-Reply-To: <252927.36750.qm@web36802.mail.mud.yahoo.com> References: <252927.36750.qm@web36802.mail.mud.yahoo.com> Message-ID: <4A72E6A0.1080503@redhat.com> On 07/30/2009 10:38 PM, Vadym Chepkov wrote: > Hi, > > I observe a very strange behavior of the ausearch utility. > audit-1.7.7-6.el5_3.3 > > # cat /root/bin/autest.sh > /sbin/ausearch -m avc| wc -l > > If I run it, I get expected results: > > # /root/bin/autest.sh > 1563 > > But if I run it from cron, I get this in e-mail: > > > 0 > > Why?? > > Sincerely yours, > Vadym Chepkov > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Is cron being denied the ability to read the audit.log? Look for an AVC. From chepkov at yahoo.com Fri Jul 31 12:55:24 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Fri, 31 Jul 2009 05:55:24 -0700 (PDT) Subject: ausearch and terminal In-Reply-To: <4A72E6A0.1080503@redhat.com> Message-ID: <545007.19465.qm@web36802.mail.mud.yahoo.com> I figured it out, apparently you have to add switch --input-logs, when you run it from cron. Don't ask me why, I am puzzled myself. Sincerely yours, Vadym Chepkov --- On Fri, 7/31/09, Daniel J Walsh wrote: > From: Daniel J Walsh > Subject: Re: ausearch and terminal > To: "Vadym Chepkov" > Cc: "Fedora SELinux" > Date: Friday, July 31, 2009, 8:42 AM > On 07/30/2009 10:38 PM, Vadym Chepkov > wrote: > > Hi, > > > > I observe a very strange behavior of the ausearch > utility. > > audit-1.7.7-6.el5_3.3 > > > > # cat /root/bin/autest.sh? > > /sbin/ausearch -m avc| wc -l > > > > If I run it, I get expected results: > > > > # /root/bin/autest.sh > > 1563 > > > > But if I run it from cron, I get this in e-mail: > > > > > > 0 > > > > Why?? > > > > Sincerely yours, > >???Vadym Chepkov > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Is cron being denied the ability to read the > audit.log?? Look for an AVC. >