Bug 1099065

Summary:	missing -Es in command string in lockdown-whitelist.xml
Product:	Red Hat Enterprise Linux 7	Reporter:	Tomas Dolezal <todoleza>
Component:	firewalld	Assignee:	Thomas Woerner <twoerner>
Status:	CLOSED ERRATA	QA Contact:	Tomas Dolezal <todoleza>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	jpopelka, jscotka
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:	firewalld-0.3.9-8.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-05 13:23:12 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tomas Dolezal 2014-05-19 12:12:01 UTC

Description of problem:
lockdown-whitelist.xml contains commandline of python call without -Es arguments which were added during late development.

after updating the line '<command name="/usr/bin/python /usr/bin/firewall-config"/>' to contain -Es, nothing changes because userid of root is also allowed.

Please inspect why removing '<user id="0"/>' and adding '<command name="/usr/bin/python -Es /usr/bin/firewall-config"/>' does not work when I try to run #firewall-config and modify runtime configuration. lockdown rejection appears.


Version-Release number of selected component (if applicable):
firewalld-0.3.9-7.el7.noarch

How reproducible:
always

Steps to Reproduce:
<?xml version="1.0" encoding="utf-8"?>
<whitelist>
  <command name="/usr/bin/python /usr/bin/firewall-config"/>
  <command name="/usr/bin/python -Es /usr/bin/firewall-config"/>
  <selinux context="system_u:system_r:NetworkManager_t:s0"/>
  <selinux context="system_u:system_r:virtd_t:s0-s0:c0.c1023"/>
</whitelist>


#firewall-config
add runtime services -> ACCESS_DENIED

Expected results:
command lockdown works and is updated or removed

Additional info:

Comment 1 Jiri Popelka 2014-05-19 15:39:30 UTC

(In reply to Tomas Dolezal from comment #0)
> Description of problem:
> lockdown-whitelist.xml contains commandline of python call without -Es
> arguments which were added during late development.

yes,
https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=119d8d35b925caa3b0be9f298be2cf91623aab22

> after updating the line '<command name="/usr/bin/python
> /usr/bin/firewall-config"/>' to contain -Es, nothing changes because userid
> of root is also allowed.

You're not supposed to be running firewall-config as root.

> Please inspect why removing '<user id="0"/>' and adding '<command
> name="/usr/bin/python -Es /usr/bin/firewall-config"/>' does not work when I
> try to run #firewall-config and modify runtime configuration. lockdown
> rejection appears.

When I try to run firewall-config twice, once as root and once as ordinary user (jpopelka) then 'ps -aux | grep firewall-config' shows:

USER     ... COMMAND
root     ... /usr/bin/python -Es /bin/firewall-config
jpopelka ... /usr/bin/python -Es /usr/bin/firewall-config

You can see that for root there's /usr missing.
If you add also the '/usr/bin/python -Es /bin/firewall-config' command into lockdown-whitelist.xml it works.

I agree that we need to add the -Es into the lockdown-whitelist.xml, but it's low priority. That line was added with
https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=354e2dbe75bf657a0d2ebad6c7b5e510f0d141fc
so when a user turns lockdown on in firewall-config she's also able to turn it off with firewall-config.

Comment 2 Jiri Popelka 2014-05-19 15:40:55 UTC

Summary (for others):
Problem here is that when ordinary user turns lockdown on in firewall-config she's not able to turn it off again with firewall-config.
One needs to turn the lockdown off as root.

This problem concerns only firewall-config and doesn't influence lockdown feature as a whole - that works as expected.

Comment 7 errata-xmlrpc 2015-03-05 13:23:12 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0520.html