Bug 1286851 - ip netns exec needs more permissions
ip netns exec needs more permissions
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy (Show other bugs)
7.3
All Linux
high Severity high
: rc
: ---
Assigned To: Lukas Vrabec
Milos Malik
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-30 16:44 EST by Aleksandar Kostadinov
Modified: 2016-11-03 22:25 EDT (History)
7 users (show)

See Also:
Fixed In Version: selinux-policy-3.13.1-80.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-03 22:25:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aleksandar Kostadinov 2015-11-30 16:44:59 EST
Description of problem:
Trying to run a systemd service that calls `ip netns exec`. That fails:

> type=AVC msg=audit(1448915156.934:10947070): avc:  denied  { mounton } for  pid=25632 comm="ip" path="/" dev="dm-1" ino=128 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir
> 	Was caused by:
> 		Missing type enforcement (TE) allow rule.

To see why mount is needed, see "exec" section of
> man ip-netns

I think that running a service under a network namespace is important as systems like OpenStack do stuff inside different namespaces and one may need to interact with them. Also systemd native netns support might be useful by a directive under [Service] but that's anothe thing.

Version-Release number of selected component (if applicable):
selinux-policy-3.13.1-23.el7_1.18.noarch

How reproducible:
always

Steps to Reproduce:
1. create a selinux service calling ip netns
2. start it
3. see audit log/audit2why --all

Actual results:
FAIL

Expected results:
ip netns works fine

Additional info:

temporary fix:
> chcon -t bin_t /usr/sbin/ip

Here's the service file I'm using:
[Unit]
Description=Redsocks transparent SOCKS proxy redirector
After=network.target

[Service]
Type=forking
EnvironmentFile=/etc/default/redsocks
ExecStartPre=/usr/sbin/redsocks -t -c /etc/redsocks.conf
ExecStart=/usr/sbin/ip netns exec mynetns /usr/sbin/redsocks -c /etc/redsocks.conf
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target
Comment 1 Aleksandar Kostadinov 2015-11-30 17:46:59 EST
FYI, because the workaround will go away on `restorecon` or RPM upgrade, I've created a separate service type=simple, to execute `chcon ...`. I've added Requires=chcon.service under [Unit] section of my main service. Now upon running main service, systemd will first run my chcon service to fix permissions.

I don't know why chcon doesn't work in ExecStartPre. My wild guess is that systemd sets as context the context of the ExecStart executable so if it is not right from the beginning, everything fails.

Just for information to those who wonder before policy is officially fixed. Or maybe I should have imported a custom policy..
Comment 2 Lukas Vrabec 2016-06-14 08:13:53 EDT
Hi Aleksandar, 

Could you test your scenario in Permissive SELinux mode? 
(#setenforce 0)
And after tests could you attach all avcs? 
#ausearch -m AVC -ts recent 

Thank you.
Comment 5 Aleksandar Kostadinov 2016-06-14 14:56:32 EDT
Sorry, can't get the idea. Do you have a new policy I can try?
Comment 9 errata-xmlrpc 2016-11-03 22:25:36 EDT
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-2016-2283.html

Note You need to log in before you can comment on or make changes to this bug.