Bug 689165

Summary: SELinux is preventing running shorewall helper tool
Product: [Fedora] Fedora Reporter: Lubos Stanek <lubek>
Component: shorewallAssignee: Jonathan Underwood <jonathan.underwood>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 14CC: flyingboxcutter, jonathan.underwood, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-03-21 11:25:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Lubos Stanek 2011-03-20 01:21:14 UTC
Description of problem:
Shorewall cannot start without running the helper tool providing parameters.

Version-Release number of selected component (if applicable):
shorewall-4.4.17-2.fc14

How reproducible:
Start shorewall.
If the file /set/shorewall/params exists, shorewall cannot start.
  
Actual results:
/var/log/messages:
...shorewall[1348]: Compiling...
...shorewall[1348]: Processing /etc/shorewall/params ...
...shorewall[1348]: Can't exec "/usr/share/shorewall//getparams": Operation denied at /usr/share/shorewall/Shorewall/Config.pm line 2867.
...shorewall[1348]:    ERROR: Processing of /etc/shorewal/params failed
...logger: ERROR:Shorewall start failed

/var/log/audit/audit.log:
type=AVC msg=audit(1300569655.824:417): avc:  denied  { execute } for  pid=11673 comm="perl" name="getparams" dev=sda2 ino=136575 scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
type=SYSCALL msg=audit(1300569655.824:417): arch=40000003 syscall=11 success=no exit=-13 a0=a4950c0 a1=a495000 a2=9cb3658 a3=2719c4 items=0 ppid=11671 pid=11673 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="perl" exe="/usr/bin/perl" subj=unconfined_u:system_r:shorewall_t:s0 key=(null)

#ls -Z /usr/share/shorewall/
-rw-r--r--. root root system_u:object_r:usr_t:s0       action.template
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       compiler.pl
drwxr-xr-x. root root system_u:object_r:usr_t:s0       configfiles
-rw-r--r--. root root system_u:object_r:bin_t:s0       configpath
lrwxrwxrwx. root root system_u:object_r:usr_t:s0       functions -> lib.base
-rwxr-xr-x. root root system_u:object_r:usr_t:s0       getparams
-rw-r--r--. root root system_u:object_r:usr_t:s0       helpers
-rw-r--r--. root root system_u:object_r:usr_t:s0       lib.base
...

Expected results:
Shorewall gets parameters and starts.

Additional info:
Is anybody testing updates these days?

Comment 1 Jonathan Underwood 2011-03-20 09:45:35 UTC
(In reply to comment #0)
> Description of problem:
> Shorewall cannot start without running the helper tool providing parameters.
> 
> Version-Release number of selected component (if applicable):
> shorewall-4.4.17-2.fc14
> 
> How reproducible:
> Start shorewall.
> If the file /set/shorewall/params exists, shorewall cannot start.
> 
> Actual results:
> /var/log/messages:
> ...shorewall[1348]: Compiling...
> ...shorewall[1348]: Processing /etc/shorewall/params ...
> ...shorewall[1348]: Can't exec "/usr/share/shorewall//getparams": Operation
> denied at /usr/share/shorewall/Shorewall/Config.pm line 2867.
> ...shorewall[1348]:    ERROR: Processing of /etc/shorewal/params failed
> ...logger: ERROR:Shorewall start failed
> 
> /var/log/audit/audit.log:
> type=AVC msg=audit(1300569655.824:417): avc:  denied  { execute } for 
> pid=11673 comm="perl" name="getparams" dev=sda2 ino=136575
> scontext=unconfined_u:system_r:shorewall_t:s0
> tcontext=system_u:object_r:usr_t:s0 tclass=file
> type=SYSCALL msg=audit(1300569655.824:417): arch=40000003 syscall=11 success=no
> exit=-13 a0=a4950c0 a1=a495000 a2=9cb3658 a3=2719c4 items=0 ppid=11671
> pid=11673 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=1 comm="perl" exe="/usr/bin/perl"
> subj=unconfined_u:system_r:shorewall_t:s0 key=(null)
> 
> #ls -Z /usr/share/shorewall/
> -rw-r--r--. root root system_u:object_r:usr_t:s0       action.template
> -rwxr-xr-x. root root system_u:object_r:bin_t:s0       compiler.pl
> drwxr-xr-x. root root system_u:object_r:usr_t:s0       configfiles
> -rw-r--r--. root root system_u:object_r:bin_t:s0       configpath
> lrwxrwxrwx. root root system_u:object_r:usr_t:s0       functions -> lib.base
> -rwxr-xr-x. root root system_u:object_r:usr_t:s0       getparams
> -rw-r--r--. root root system_u:object_r:usr_t:s0       helpers
> -rw-r--r--. root root system_u:object_r:usr_t:s0       lib.base
> ...
> 
> Expected results:
> Shorewall gets parameters and starts.
> 

Thanks for the report, I'll look into it.

> Additional info:
> Is anybody testing updates these days?

Well, clearly YOU didn't. This update sat in updates-testing for the required number of days before being pushed to stable, and so you had opportunity to test and provide feedback.

Comment 2 Jonathan Underwood 2011-03-20 09:56:58 UTC
I can't actually reproduce this myself. Can you provide the output of 

rpm -qa | grep selinux


CC'ing Miroslav - I think this requires a modification to the SElinux policy for shorewall.

Comment 3 Lubos Stanek 2011-03-20 17:51:27 UTC
I am running with testing version of the SELinux policy due to the bug #685429:
selinux-policy-3.9.7-35.f14.noarch
selinux-policy-targeted-3.9.7-35.f14.noarch

The policy does not enable execution of the file /usr/share/shorewall/getparams as it is visible in the ls output.
The execution of this support file is not enabled in older policy or in the development version either.
And generally it is not permitted to execute files in the data directories under SELinux.

I am not testing Fedora, I am trying to make the machine to run with it right now. I am sorry that I was not faster to do this at the time you made the new package.
Whenever I encounter an issue, I try to report it. Although the Fedora enterprise bug handling is very annoying for me.

Comment 4 Jonathan Underwood 2011-03-20 21:20:33 UTC
I've sent a mail to the upstream developers asking them to consider moving executable files out of /usr/share/shorewall and into /usr/libexec/shorewall.

In the meantime I suggest using audit2allow to generate a module to make things work.

When I get a bit of time I'll look into making a patch to move executables to /usr/libexec unless upstream gets there first.

Comment 5 Miroslav Grepl 2011-03-21 07:46:40 UTC
chcon -t bin_t /usr/share/shorewall/getparams

should fix this issue for now.

Comment 6 Lubos Stanek 2011-03-21 11:25:30 UTC
The issue is fixed using the latest policy (selinux-policy-3.9.7-37.fc14)
Thanks for your work.

Comment 7 Miroslav Grepl 2011-03-21 11:28:57 UTC
(In reply to comment #6)
> The issue is fixed using the latest policy (selinux-policy-3.9.7-37.fc14)
> Thanks for your work

Lubos, 
thanks for testing. Could you update the karma.

https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-37.fc14

Comment 8 Jonathan Underwood 2011-03-22 23:19:07 UTC
*** Bug 689857 has been marked as a duplicate of this bug. ***