Hi All,
Maybe I did not use the correct keywords, but I am unable to find a
solution for this problem with google , or via the archives.
* I''ve been given a fc14 virtual machine.
* Upon reboot, shorewall is not running.
* If I do the following, shorewall starts OK.
o log in via the vmware console
o su root
o /sbin/shorewall start
* even though /etc/rc.local is out of favour I tried running
"/sbin/shorewall start" in /etc/rc.local, but shorewall is still
not starting on reboot.
/var/log/messages reports:
May 9 11:04:56 mclachlan1 shorewall[1445]: Compiling...
May 9 11:04:57 mclachlan1 shorewall[1445]: Processing /etc/shorewall/params ...
May 9 11:04:57 mclachlan1 shorewall[1445]: Can''t exec
"/usr/share/shorewall//getparams": Permission denied at /usr/share/sho
rewall/Shorewall/Config.pm line 2867.
May 9 11:04:57 mclachlan1 kernel: [ 14.943055] type=1400
audit(1304953497.367:4): avc: denied { execute } for pid=1461
comm="perl" name="getparams" dev=dm-0 ino=395957
scontext=system_u:system_r:shorewall_t:s0 tcontext=system_u:object_r:usr_t:s
0 tclass=file
May 9 11:04:57 mclachlan1 shorewall[1445]: ERROR: Processing of
/etc/shorewall/params failed
I don''t see why shorewall fails to start from /etc/rc.local, but starts
OK from the command line.
[ whoami from /etc/rc.local reports root. When starting from the command
line whoami reports root. ]
Any help would be greatly appreciated.
Thanks,
Don
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
On 5/9/11 10:30 AM, Donald McLachlan wrote:> > Hi All, > > Maybe I did not use the correct keywords, but I am unable to find a > solution for this problem with google , or via the archives. > > * I''ve been given a fc14 virtual machine. > * Upon reboot, shorewall is not running. > * If I do the following, shorewall starts OK. > o log in via the vmware console > o su root > o /sbin/shorewall start > * even though /etc/rc.local is out of favour I tried running > "/sbin/shorewall start" in /etc/rc.local, but shorewall is still > not starting on reboot. > > /var/log/messages reports: > > May 9 11:04:56 mclachlan1 shorewall[1445]: Compiling... > May 9 11:04:57 mclachlan1 shorewall[1445]: Processing /etc/shorewall/params ... > May 9 11:04:57 mclachlan1 shorewall[1445]: Can''t exec "/usr/share/shorewall//getparams": Permission denied at /usr/share/sho > rewall/Shorewall/Config.pm line 2867. > May 9 11:04:57 mclachlan1 kernel: [ 14.943055] type=1400 audit(1304953497.367:4): avc: denied { execute } for pid=1461 > comm="perl" name="getparams" dev=dm-0 ino=395957 scontext=system_u:system_r:shorewall_t:s0 tcontext=system_u:object_r:usr_t:s > 0 tclass=file > May 9 11:04:57 mclachlan1 shorewall[1445]: ERROR: Processing of /etc/shorewall/params failed > > > I don''t see why shorewall fails to start from /etc/rc.local, but starts > OK from the command line. > [ whoami from /etc/rc.local reports root. When starting from the command > line whoami reports root. ] > > Any help would be greatly appreciated.Hopefully someone who is SELinux-knowledgable will chime in here, but it looks to me as though running /usr/share/shorewall/getparams is not allowed in the init startup context. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> May 9 11:04:57 mclachlan1 kernel: [ 14.943055] type=1400 audit(1304953497.367:4): avc: denied { execute } for pid=1461 > comm="perl" name="getparams" dev=dm-0 ino=395957 scontext=system_u:system_r:shorewall_t:s0 tcontext=system_u:object_r:usr_t:s > 0 tclass=file >This is an error with the selinux policy in FC14 (the main reason I am *NOT* on FC14)! Run "restorecon -vF /usr/share/shorewall/getparams" and then check the selinux context with "ls -lasZ /usr/share/shorewall/getparams" - if it is still "usr_t" you could try and submit a bug with Fedora. As a temporary "solution" you could do this (as root): echo 0 > /selinux/enforce (this will briefly set your SELinux policy in passive mode) service shorewall start (or "/sbin/shorewall start") If, after this point, you do not get any errors then the problem is definitely with Fedora''s SELinux policy people. In any event, after you execute the above restore SELinux back in enforcing mode: echo 1 /selinux/enforce> I don''t see why shorewall fails to start from /etc/rc.local, but > starts OK from the command line. > [ whoami from /etc/rc.local reports root. When starting from the > command line whoami reports root. ]Because you are running the shell as a "privileged" user from SELinux''s point of view. If I were you I would also alert the SELinux mailing list (selinux@lists.fedoraproject.org).> Any help would be greatly appreciated.No worries! ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> Hopefully someone who is SELinux-knowledgable will chime in here, but it > looks to me as though running /usr/share/shorewall/getparams is not > allowed in the init startup context. >There are 2 possible reasons - mislabelling (which is the most common error), or an error with the SELinux policy (I have submitted quite a few bugs on those, particularly where shorewall is concerned as I use SELinux everywhere). If it is mislabelling, then the correct context should be restored after running "restorecon" and that will be visible with "ls -lasZ". If not, it is a bug, which needs to be submitted with Fedora (or alert the appropriate people dealing with this on the SELinux mailing list). ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
Mr Dash Four wrote:> >> May 9 11:04:57 mclachlan1 kernel: [ 14.943055] type=1400 >> audit(1304953497.367:4): avc: denied { execute } for pid=1461 >> comm="perl" name="getparams" dev=dm-0 ino=395957 >> scontext=system_u:system_r:shorewall_t:s0 >> tcontext=system_u:object_r:usr_t:s >> 0 tclass=file >> > This is an error with the selinux policy in FC14 (the main reason I am > *NOT* on FC14)! Run "restorecon -vF /usr/share/shorewall/getparams" > and then check the selinux context with "ls -lasZ > /usr/share/shorewall/getparams" - if it is still "usr_t" you could try > and submit a bug with Fedora. As a temporary "solution" you could do > this (as root):Yeah, I just checked what I have on one of my machines - the context is "bin_t" which is a context not constrained by any SELinux policies (a work-around I did a while ago to avoid this very bug when I tried to upgrade to FC14 and then backtracked to FC13) - definitely a bug and SELinux people definitely know about it! ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
Donald McLachlan
2011-May-09 18:20 UTC
Summary: shorewall not auto starting on fedora 14 on vmware
Thanks to teastep@shorewall.net and <mr.dash.four@googlemail.com> we are
up and running.
1) After running restorecon, ls -lasZ still reports usr_t - so it looks
like a Fedora/SELinux bug.
2) According to mr.dash.four@googlemail.com the fc14 and SELinux folks
are already aware of this, so I will not post a bug report.
3) but now that this topic has all the keywords, anybody facing the same
problem should be able to find this solution.
4) I solved this problem by editing /etc/rc.local to read as follows.
(Yes this does create a tiny security race condition, but that tiny race
condition is better than permanently disabling SELinux. :-)
[don@mclachlan1 ~]$ cat /etc/rc.local
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don''t
# want to do the full Sys V style init stuff.
touch /var/lock/subsys/local
# DGM 08/05/2011 - work around Fedora 14 / SELinux bug.
echo 0 > /selinux/enforce
/sbin/shorewall start
echo 1 > /selinux/enforce
Thanks again,
Don
On 09/05/2011 2:01 PM, Mr Dash Four wrote:>
> Mr Dash Four wrote:
>>> May 9 11:04:57 mclachlan1 kernel: [ 14.943055] type=1400
>>> audit(1304953497.367:4): avc: denied { execute } for pid=1461
>>> comm="perl" name="getparams" dev=dm-0
ino=395957
>>> scontext=system_u:system_r:shorewall_t:s0
>>> tcontext=system_u:object_r:usr_t:s
>>> 0 tclass=file
>>>
>> This is an error with the selinux policy in FC14 (the main reason I am
>> *NOT* on FC14)! Run "restorecon -vF
/usr/share/shorewall/getparams"
>> and then check the selinux context with "ls -lasZ
>> /usr/share/shorewall/getparams" - if it is still "usr_t"
you could try
>> and submit a bug with Fedora. As a temporary "solution" you
could do
>> this (as root):
> Yeah, I just checked what I have on one of my machines - the context is
> "bin_t" which is a context not constrained by any SELinux
policies (a
> work-around I did a while ago to avoid this very bug when I tried to
> upgrade to FC14 and then backtracked to FC13) - definitely a bug and
> SELinux people definitely know about it!
>
>
------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today. Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
Mr Dash Four
2011-May-09 18:34 UTC
Re: Summary: shorewall not auto starting on fedora 14 on vmware
> [don@mclachlan1 ~]$ cat /etc/rc.local > #!/bin/sh > # > # This script will be executed *after* all the other init scripts. > # You can put your own initialization stuff in here if you don''t > # want to do the full Sys V style init stuff. > > touch /var/lock/subsys/local > > # DGM 08/05/2011 - work around Fedora 14 / SELinux bug. > echo 0 > /selinux/enforce > /sbin/shorewall start > echo 1 > /selinux/enforce > > Thanks again, > DonApologies Don, there is a better and more permanent solution to this (this is what I have done - and alluded to, though not very clearly - in my last post): execute the following 2 statements as root: semanage fcontext -a -t bin_t /usr/share/shorewall/getparams restorecon -vF /usr/share/shorewall/getparams After this, the security context on getparams should have been amended from "usr_t" to "bit_t". To make sure of that execute "ls -lasZ /usr/share/shorewall/getparams" and you should clearly see the security context on this file as "bin_t". Once that is so, you don''t have to do anything else - no need to amend your rc.local. Apologies for not making this much clearer! ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
Simon Matter
2011-May-10 05:35 UTC
Re: Summary: shorewall not auto starting on fedora 14 on vmware
> > Thanks to teastep@shorewall.net and <mr.dash.four@googlemail.com> we are > up and running. > > 1) After running restorecon, ls -lasZ still reports usr_t - so it looks > like a Fedora/SELinux bug. > 2) According to mr.dash.four@googlemail.com the fc14 and SELinux folks > are already aware of this, so I will not post a bug report. > 3) but now that this topic has all the keywords, anybody facing the same > problem should be able to find this solution. > 4) I solved this problem by editing /etc/rc.local to read as follows. > (Yes this does create a tiny security race condition, but that tiny race > condition is better than permanently disabling SELinux. :-) > > [don@mclachlan1 ~]$ cat /etc/rc.local > #!/bin/sh > # > # This script will be executed *after* all the other init scripts. > # You can put your own initialization stuff in here if you don''t > # want to do the full Sys V style init stuff. > > touch /var/lock/subsys/local > > # DGM 08/05/2011 - work around Fedora 14 / SELinux bug. > echo 0 > /selinux/enforce > /sbin/shorewall start > echo 1 > /selinux/enforce >Just because I''m interested, is this with the official Fedora shorewall package? Isn''t this whole "bug" about the "don''t put executable code into /usr/share but /usr/lib[exec] instead" thing discussed recently on this list? At least I have changed my rpms for RHEL to use /usr/libexec and I think the Fedora maintainer did the same (but the package may not have been released yet). Regards, Simon> Thanks again, > Don > > > On 09/05/2011 2:01 PM, Mr Dash Four wrote: >> >> Mr Dash Four wrote: >>>> May 9 11:04:57 mclachlan1 kernel: [ 14.943055] type=1400 >>>> audit(1304953497.367:4): avc: denied { execute } for pid=1461 >>>> comm="perl" name="getparams" dev=dm-0 ino=395957 >>>> scontext=system_u:system_r:shorewall_t:s0 >>>> tcontext=system_u:object_r:usr_t:s >>>> 0 tclass=file >>>> >>> This is an error with the selinux policy in FC14 (the main reason I am >>> *NOT* on FC14)! Run "restorecon -vF /usr/share/shorewall/getparams" >>> and then check the selinux context with "ls -lasZ >>> /usr/share/shorewall/getparams" - if it is still "usr_t" you could try >>> and submit a bug with Fedora. As a temporary "solution" you could do >>> this (as root): >> Yeah, I just checked what I have on one of my machines - the context is >> "bin_t" which is a context not constrained by any SELinux policies (a >> work-around I did a while ago to avoid this very bug when I tried to >> upgrade to FC14 and then backtracked to FC13) - definitely a bug and >> SELinux people definitely know about it! >> >> ------------------------------------------------------------------------------ >> WhatsUp Gold - Download Free Network Management Software >> The most intuitive, comprehensive, and cost-effective network >> management toolset available today. Delivers lowest initial >> acquisition cost and overall TCO of any competing solution. >> http://p.sf.net/sfu/whatsupgold-sd >> _______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd_______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
Mr Dash Four
2011-May-10 10:51 UTC
Re: Summary: shorewall not auto starting on fedora 14 on vmware
> Just because I''m interested, is this with the official Fedora shorewall > package? Isn''t this whole "bug" about the "don''t put executable code into > /usr/share but /usr/lib[exec] instead" thing discussed recently on this > list? >No idea.> At least I have changed my rpms for RHEL to use /usr/libexec and I think > the Fedora maintainer did the same (but the package may not have been > released yet). >I agree with your point about lib(exec) - make sense, though getparams is not the only executable in that directory, the only problem, however, seems to be with this file. It is not for the first time either. I remember I had similar problems with ipset executing during shorewall start up (simply because of a wrong context assigned by the SELinux policy) - the bug was fixed, only to appear yet again as soon as FC14 was released. Since then I am maintaining my own (patched) version of the policy to avoid this king of headache on a regular basis. ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
Donald McLachlan
2011-May-10 12:11 UTC
Re: Summary: shorewall not auto starting on fedora 14 on vmware
Hi Simon, As far as I know this is a bog standard Fedora 14 install. I cannot comment on that recent discussion on this list because I just joined this list to yesterday in order to resolve this problem. Regards, Don On 10/05/2011 1:35 AM, Simon Matter wrote:>> Thanks to teastep@shorewall.net and<mr.dash.four@googlemail.com> we are >> up and running. >> >> 1) After running restorecon, ls -lasZ still reports usr_t - so it looks >> like a Fedora/SELinux bug. >> 2) According to mr.dash.four@googlemail.com the fc14 and SELinux folks >> are already aware of this, so I will not post a bug report. >> 3) but now that this topic has all the keywords, anybody facing the same >> problem should be able to find this solution. >> 4) I solved this problem by editing /etc/rc.local to read as follows. >> (Yes this does create a tiny security race condition, but that tiny race >> condition is better than permanently disabling SELinux. :-) >> >> [don@mclachlan1 ~]$ cat /etc/rc.local >> #!/bin/sh >> # >> # This script will be executed *after* all the other init scripts. >> # You can put your own initialization stuff in here if you don''t >> # want to do the full Sys V style init stuff. >> >> touch /var/lock/subsys/local >> >> # DGM 08/05/2011 - work around Fedora 14 / SELinux bug. >> echo 0> /selinux/enforce >> /sbin/shorewall start >> echo 1> /selinux/enforce >> > Just because I''m interested, is this with the official Fedora shorewall > package? Isn''t this whole "bug" about the "don''t put executable code into > /usr/share but /usr/lib[exec] instead" thing discussed recently on this > list? > At least I have changed my rpms for RHEL to use /usr/libexec and I think > the Fedora maintainer did the same (but the package may not have been > released yet). > > Regards, > Simon > >> Thanks again, >> Don >> >> >> On 09/05/2011 2:01 PM, Mr Dash Four wrote: >>> Mr Dash Four wrote: >>>>> May 9 11:04:57 mclachlan1 kernel: [ 14.943055] type=1400 >>>>> audit(1304953497.367:4): avc: denied { execute } for pid=1461 >>>>> comm="perl" name="getparams" dev=dm-0 ino=395957 >>>>> scontext=system_u:system_r:shorewall_t:s0 >>>>> tcontext=system_u:object_r:usr_t:s >>>>> 0 tclass=file >>>>> >>>> This is an error with the selinux policy in FC14 (the main reason I am >>>> *NOT* on FC14)! Run "restorecon -vF /usr/share/shorewall/getparams" >>>> and then check the selinux context with "ls -lasZ >>>> /usr/share/shorewall/getparams" - if it is still "usr_t" you could try >>>> and submit a bug with Fedora. As a temporary "solution" you could do >>>> this (as root): >>> Yeah, I just checked what I have on one of my machines - the context is >>> "bin_t" which is a context not constrained by any SELinux policies (a >>> work-around I did a while ago to avoid this very bug when I tried to >>> upgrade to FC14 and then backtracked to FC13) - definitely a bug and >>> SELinux people definitely know about it! >>> >>> ------------------------------------------------------------------------------ >>> WhatsUp Gold - Download Free Network Management Software >>> The most intuitive, comprehensive, and cost-effective network >>> management toolset available today. Delivers lowest initial >>> acquisition cost and overall TCO of any competing solution. >>> http://p.sf.net/sfu/whatsupgold-sd >>> _______________________________________________ >>> Shorewall-users mailing list >>> Shorewall-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> ------------------------------------------------------------------------------ >> WhatsUp Gold - Download Free Network Management Software >> The most intuitive, comprehensive, and cost-effective network >> management toolset available today. Delivers lowest initial >> acquisition cost and overall TCO of any competing solution. >> http://p.sf.net/sfu/whatsupgold-sd_______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> > > > ------------------------------------------------------------------------------ > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
Donald McLachlan
2011-May-10 12:38 UTC
Re: Summary: shorewall not auto starting on fedora 14 on vmware
I first edited /etc/rc.local and commented out my hack. I then did: [root@mclachlan1 don]# semanage fcontext -a -t bin_t /usr/share/shorewall/getparams [root@mclachlan1 don]# restorecon -vF /usr/share/shorewall/getparams restorecon reset /usr/share/shorewall/getparams context system_u:object_r:usr_t:s0->system_u:object_r:bin_t:s0 [root@mclachlan1 don]# ls -lasZ /usr/share/shorewall/getparams -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/share/shorewall/getparams [root@mclachlan1 don]# reboot and the system came up with shorewall running. This is a cleaner solution, especially if it still does not have to be redone after O/S upgrades, etc. Otherwise I prefer the simple rc.local hack. Anyway, now there are 2 documented "fixes". Thanks again, Don On 09/05/2011 2:34 PM, Mr Dash Four wrote:> >> [don@mclachlan1 ~]$ cat /etc/rc.local >> #!/bin/sh >> # >> # This script will be executed *after* all the other init scripts. >> # You can put your own initialization stuff in here if you don''t >> # want to do the full Sys V style init stuff. >> >> touch /var/lock/subsys/local >> >> # DGM 08/05/2011 - work around Fedora 14 / SELinux bug. >> echo 0 > /selinux/enforce >> /sbin/shorewall start >> echo 1 > /selinux/enforce >> >> Thanks again, >> Don > Apologies Don, there is a better and more permanent solution to this > (this is what I have done - and alluded to, though not very clearly - > in my last post): > > execute the following 2 statements as root: > > semanage fcontext -a -t bin_t /usr/share/shorewall/getparams > restorecon -vF /usr/share/shorewall/getparams > > After this, the security context on getparams should have been amended > from "usr_t" to "bit_t". To make sure of that execute "ls -lasZ > /usr/share/shorewall/getparams" and you should clearly see the > security context on this file as "bin_t". Once that is so, you don''t > have to do anything else - no need to amend your rc.local. > > Apologies for not making this much clearer! >------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
Mr Dash Four
2011-May-10 12:51 UTC
Re: Summary: shorewall not auto starting on fedora 14 on vmware
> This is a cleaner solution, especially if it still does not have to be > redone after O/S upgrades, etc. Otherwise I prefer the simple > rc.local hack.The *only* case when these changes *will* be lost is if you do a relabel on the entire file system (touch /.autorelabel and then reboot) - this will completely relabel your entire file system based on the installed SELinux policy and since this is a "custom" fix the changes you''ve just made will be lost. As long as you do not do that it will survive complete OS reinstall as well as shorewall upgrades (it will be lost if you remove shorewall and then install it though), so on that count you are pretty safe. Whether Fedora will fix this I do not know, but I have just finished my own version of the shorewall SELinux policy last night in light of this and have implemented the right context into the policy itself, so once installed even if I do a complete relabel of the file system the changes will stay as they are and nothing will be broken. ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
Tom Eastep
2011-May-10 14:06 UTC
Re: Summary: shorewall not auto starting on fedora 14 on vmware
On 5/10/11 3:51 AM, Mr Dash Four wrote:> I agree with your point about lib(exec) - make sense, though getparams > is not the only executable in that directory, the only problem, however, > seems to be with this file. It is not for the first time either. >The ability to relocate *all* of the executables in /usr/share/shorewall/ was released in 4.4.19. It''s now up to the distributions to make use of that ability. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
Mr Dash Four
2011-May-10 16:25 UTC
Re: Summary: shorewall not auto starting on fedora 14 on vmware
> The ability to relocate *all* of the executables in > /usr/share/shorewall/ was released in 4.4.19. It''s now up to the > distributions to make use of that ability. >The problem is not because of this file''s location, the problem is with 1) the wrong security context defined and assigned to this file (SELinux policy bug); and/or 2) shorewall security domain (shorewall_t) has not been granted the necessary privileges to access/execute its own files (getparams in this case), hence the error (SELinux policy bug). Either way - it is a policy bug, whichever way it is looked at. I could place getparams in /root for what I care, provided the right security policy is compiled and installed on that machine, I will not get an error and shorewall will be running properly! The same thing happened with ipset more than a year ago - shorewall could not execute properly because I was running ipset within /etc/shorewall/init and than triggered a security error preventing shorewall from starting. Why? Because some bright spark at Fedora thought that ipset does not form any part of the Netfilter group of domains and therefore should not be allowed to execute within the shorewall_t security domain. I took them months to correct that. The same is happening with getparams and I am just wondering how many months will pass before someone at Fedora decides to fix this. ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
Tom Eastep
2011-May-10 19:31 UTC
Re: Summary: shorewall not auto starting on fedora 14 on vmware
On May 10, 2011, at 9:25 AM, Mr Dash Four wrote:> >> The ability to relocate *all* of the executables in >> /usr/share/shorewall/ was released in 4.4.19. It''s now up to the >> distributions to make use of that ability. >> > The problem is not because of this file''s location, the problem is with...> am just wondering how many months will pass before someone at Fedora > decides to fix this. >I should have quoted more succinctly. I was reacting to your earlier statement that "... though getparams is not the only executable in that directory, ...". I was not implying that relocating the files would solve the SELinux issue. -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay