Bug 621499
Summary: | SELinux is preventing /usr/bin/ncftool "relabelto" access on system-config-firewall.augnew | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Milos Malik <mmalik> |
Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Milos Malik <mmalik> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.0 | CC: | astokes, crobinso, dwalsh, laine, mcepl, mgrepl, syeghiay |
Target Milestone: | rc | Keywords: | RHELNAK |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | setroubleshoot_trace_hash:71fceceb0822ee8733d7aaa2e8608873c934437eea2db379565d030fb6c6ebf6 | ||
Fixed In Version: | selinux-policy-3.7.19-37.el6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | 616166 | Environment: | |
Last Closed: | 2010-11-10 21:36:02 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 616166 | ||
Bug Blocks: | |||
Attachments: |
Description
Milos Malik
2010-08-05 10:07:04 UTC
netcf-0.1.6-4.el6.i686 selinux-policy-minimum-3.7.19-35.el6.noarch selinux-policy-3.7.19-35.el6.noarch selinux-policy-targeted-3.7.19-35.el6.noarch selinux-policy-doc-3.7.19-35.el6.noarch selinux-policy-mls-3.7.19-35.el6.noarch Created attachment 436790 [details]
AVCs found during testing
This issue has been proposed when we are only considering blocker issues in the current Red Hat Enterprise Linux release. ** If you would still like this issue considered for the current release, ask your support representative to file as a blocker on your behalf. Otherwise ask that it be considered for the next Red Hat Enterprise Linux release. ** Laine, is ncftool supposed to start the iptables and manage iptables files? I am not able to reproduce it. The test contains the following "ncftool help" "ncftool dumpxml lo | tee ${OUTPUT_FILE}" "ncftool undefine lo" "ncftool define ${OUTPUT_FILE}" "ncftool ifdown lo" "ncftool ifup lo" "ncftool list" Here is a short reproducer: # rm /etc/sysconfig/system-config-firewall* rm: remove regular file `/etc/sysconfig/system-config-firewall'? y rm: remove regular file `/etc/sysconfig/system-config-firewall.old'? y # system-config-firewall-tui (click on: Enabled, OK, Yes) # date Thu Aug 5 15:17:14 CEST 2010 # ncftool ifdown lo Interface lo successfully brought down # ncftool ifup lo Interface lo successfully brought up # ausearch -m avc -ts 15:17:14 | wc -l 95 Miroslav, Yes, nctool will read the iptables rules file iff net.bridge.bridge-nf-call-iptables = 1 and it will modify the file if you define a bridge interface. Your system probably has this set to 0. Just do: sysctl -w net.bridge.bridge-nf-call-iptables=1 and you should be able to replicate the problems. For example, pass a file containing something like the following in a file (modify the MAC address to match your ethernet device) to "ncftool define": <interface type='bridge' name='br0'> <start mode='onboot'/> <protocol family='ipv4'> <dhcp/> </protocol> <bridge stp='on' delay='0'> <interface type='ethernet' name='eth0'> <mac address='00:22:15:59:62:97'/> </interface> </bridge> </interface> WARNING: This will remove your current eth0 configuration! Before you do this, you should do the following to save the original eth0 config: ncftool dumpxml eth0 >/tmp/eth0.xml When you're done testing, you will want to restore the original eth0 config: ncftool ifdown br0 ncftool undefine br0 ncftool define /tmp/eth0.xml ncftool ifup eth0 Another important note: for proper operation of ncftool, it is still necessary to disable NetworkManager (NM doesn't understand bridges). So do this before you run any ncftool commands: service NetworkManager stop Once you're done, and have removed any bridges/vlans from your config, you can restart it: service NetworkManager start BTW, this is closely related to Bug 602464. While you're fixing this one, I assume you'll get the other related selinux violations that are part of the same operation? Please update that bug accordingly (reassign to yourself if you like). (Disregard the discussion in the bug of the possibility of removing iptables modification code from netcf - that is a longer term discussion, while fixing the selinux policy is something that can be done right away.) Also, if you need someone to test a new selinux-policy package, please contact me - I'd be glad to give it a try for you. This looks like ncftools is executing /etc/init.d/iptables So we probably need optional_policy(` iptables_initrc_domtrans(ncftool_t) ') Which should handle most of the AVC messages. I was finally able to reproduce it. Dan, you are right. We need to add optional_policy(` iptables_initrc_domtrans(ncftool_t) ') Laine, could you test ncftool stuff with selinux-policy-3.7.19-36.el6. The packages are available from brew. Thanks. I'm still seeing that problem (and a few others) with selinux-policy-3.7.19-36. I just figured out that you may not be seeing them because netcf modifies /etc/sysconfig/iptables in a different manner if it detects that lokkit is available and in use (it uses lokkit). Also, if iptables has already been modified in a previous run, it doesn't attempt to do it again. To guarantee that netcf is making this modification through augeas, you should either move /usr/sbin/lokkit out of the way temporarily, or remove the following two lines from /etc/sysconfig/iptables prior to defining a bridge: #Firewall configuration written by system-config-firewall and also remove the line that netcf adds: -A FORWARD -m physdev --physdev-is-bridged -j ACCEPT So, to sum it up, to assure that you see this problem, do the following: 1) get your network config back to a non-bridged state (plain eth0 by itself) 2) remove the above two lines from /etc/iptables. 3) run: sysctl -w net.bridge.bridge-nf-call-iptables=1 4) run ncftool define br0.xml (where br0.xml is a file containing xml similar to that given in Comment 7. 5) After that, to see another occurrence of one of the AVCs, run: ncftool ifup br0 (of course during all of this you should have selinux set to permissive) Created attachment 437233 [details]
avc's still remaining with selinux-policy-3.7.19-36
Here is the list of AVCs that I find still existing when I follow the steps in the previous comment to force netcf's rewrite of /etc/sysconfig/iptables.
Note there are a couple of AVCs related to reading the config file (br0.xml). It's not really realistic to restrict what files ncftool can read - a user could create those files anywhere that's convenient, and probably just uses emacs or something to create the file. It's not realistic to expect them to set some specific label on this kind of scratch file. Note that sometimes.
I don't know what "dac_override" is all about, but whatever it is, netcf needs to do it.
*** Bug 602464 has been marked as a duplicate of this bug. *** allow ncftool_t self:capability dac_override; Can you execute auditctl -w /etc/shadow -p w Then regenerate this error and attach the output from ausearch -m avc -ts recent dac_override is usually caused by a file having the wrong ownership/permissions. Executing the above code will give us a path of the bad file/dir. ------------------------------- allow ncftool_t system_conf_t:file { write relabelto rename unlink }; I am also getting these AVC messages. I will fix it. > Note there are a couple of AVCs related to reading the config file (br0.xml).
> It's not really realistic to restrict what files ncftool can read - a user
> could create those files anywhere that's convenient, and probably just uses
> emacs or something to create the file. It's not realistic to expect them to set
> some specific label on this kind of scratch file. Note that sometimes.
Well, you are right. People can create those files anywhere. But we don't want to allow ncftool to read files with random SELinux types. People can always add their own policy to allow it.
> Well, you are right. People can create those files anywhere. But we don't
> want to allow ncftool to read files with random SELinux types.
Actually that's *exactly* what we want. These files are temporary files created manually by the user in some scratch location, used once, then discarded. To expect the user to have to understand how to add their own selinux policies (and perform that task) just to use this file once makes no sense.
BTW, exactly the same operation via libvirt's "virsh iface-define br0.xml" command works with no selinux violations. So, whatever policy virsh has to xml files, I'm guessing that's what is needed in ncftool for xml files.
In response to Comment 15: (note that I see for both /sbin/ifup and /sbin/ifdown, so I ran both commands) root@rhel6 /home/laine>ausearch -m avc -ts recent ---- time->Mon Aug 9 17:50:42 2010 type=SYSCALL msg=audit(1281390642.278:174): arch=c000003e syscall=59 success=no exit=-2 a0=7fffa628981b a1=7fffa6289b80 a2=7fffa6289e68 a3=8 items=0 ppid=17275 pid=17276 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=2 comm="ncftool" exe="/usr/bin/ncftool" subj=unconfined_u:unconfined_r:ncftool_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1281390642.278:174): avc: denied { dac_override } for pid=17276 comm="ncftool" capability=1 scontext=unconfined_u:unconfined_r:ncftool_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:ncftool_t:s0-s0:c0.c1023 tclass=capability ---- time->Mon Aug 9 17:52:09 2010 type=PATH msg=audit(1281390729.128:180): item=0 name="/home/laine/bin/ifdown" type=CWD msg=audit(1281390729.128:180): cwd="/home/laine" type=SYSCALL msg=audit(1281390729.128:180): arch=c000003e syscall=59 success=no exit=-2 a0=7fff3a2f003b a1=7fff3a2f03b0 a2=7fff3a2f0688 a3=8 items=1 ppid=17487 pid=17488 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=2 comm="ncftool" exe="/usr/bin/ncftool" subj=unconfined_u:unconfined_r:ncftool_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1281390729.128:180): avc: denied { dac_override } for pid=17488 comm="ncftool" capability=1 scontext=unconfined_u:unconfined_r:ncftool_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:ncftool_t:s0-s0:c0.c1023 tclass=capability root@rhel6 /home/laine> ---- time->Mon Aug 9 17:54:54 2010 type=PATH msg=audit(1281390894.260:181): item=0 name="/home/laine/bin/ifup" type=CWD msg=audit(1281390894.260:181): cwd="/home/laine" type=SYSCALL msg=audit(1281390894.260:181): arch=c000003e syscall=59 success=no exit=-2 a0=7fff6f3070eb a1=7fff6f307450 a2=7fff6f307738 a3=8 items=1 ppid=17632 pid=17633 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=2 comm="ncftool" exe="/usr/bin/ncftool" subj=unconfined_u:unconfined_r:ncftool_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1281390894.260:181): avc: denied { dac_override } for pid=17633 comm="ncftool" capability=1 scontext=unconfined_u:unconfined_r:ncftool_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:ncftool_t:s0-s0:c0.c1023 tclass=capability '/home/laine/bin/ifup' has permissions that root can not access. I think we could add tunable_policy(`ncftool_enable_homedirs',` allow ncftool_t self: capability dac_override; userdom_read_user_home_content_files(nfctool_t) ') tunable_policy(`nfctool_enable_homedirs && use_nfs_home_dirs',` fs_read_nfs_files(nfctool_t) fs_read_nfs_symlinks(nfctool_t) ') tunable_policy(`nfctool_enable_homedirs && use_samba_home_dirs',` fs_read_cifs_files(openvpn_t) fs_read_cifs_symlinks(openvpn_t) ') Dan, what do you think? I am not crazy about this, but If we add theat you should also allow reading of user_tmp_t. Maybe boolean should be ncftool_read_user_content allow ncftool_t self: capability dac_override; userdom_read_user_home_content_files(nfctool_t) userdom_read_user_tmp_files(ncftool_t) (In reply to comment #20) > I am not crazy about this, but If we add theat you should also allow reading of > user_tmp_t. > > Maybe boolean should be > > ncftool_read_user_content > allow ncftool_t self: capability dac_override; > userdom_read_user_home_content_files(nfctool_t) > userdom_read_user_tmp_files(ncftool_t) Sounds better. Wait a second! Something is strange here - there is no "/home/laine/bin/ifup". It's executing /sbin/ifup! Where is the reference to /home/laine/bin/ifup coming from? (By that, I mean that I see the "/home/laine/bin/ifup" in the AVC message, but that file doesn't exist on the system, and nobody is directly looking for it. /home/laine/bin *is* in $PATH, but netcf is running "ifup" (and ending up successfully running /sbin/ifup). When I again try the same commands that I used to gather the messages in Comment 18, I now only get the first of them, I don't get the messages about the (nonexistent) /home/laine/bin/ifup and /home/laine/bin/ifdown. No idea where those came from... I've slightly modified the /CoreOS/selinux-policy/Regression/bz593708-ncftool-cannot-read-files test. As a result I got 15 AVCs. With following policy module loaded everything works fine and no AVCs appear: policy_module(mypolicy,1.0) require { type ncftool_t; } netutils_domtrans(ncftool_t) Created attachment 437898 [details]
AVCs found after test modification
Fixed in selinux-policy-3.7.19-37.el6.noarch Created attachment 438056 [details]
AVCs still remaining with selinux-policy-3.7.19-37.el6.noarch
Unfortunately, with selinux-policy-3.7.19-37.el6.noarch installed, I still get several AVCs when I perform my basic test of:
ncftool ifdown br0
ncftool undefine br0
ncftool define ~laine/bin/eth0.xml
ncftool ifup eth0
(ie, removing a device from a bridge.)
What commands do you perform for a test?
This is *very* close, though.
Turn on 'ncftool_read_user_content' boolean. # setsebool -P ncftool_read_user_content on Created attachment 438200 [details]
AVCs still remaining with ncftool_read_user_content set to on
1) Even after I turn on ncftool_read_user_content, I still get 4 of the 6 previous AVCs - see the attachment.
2) Why should there be a boolean for this anyway? Reading xml files in the user's home directory, /tmp, or any random location is something that ncftool will *always* have to do, and it's mostly useless without it.
Again, as an example, look at the virsh program in libvirt - there is no "virsh_read_user_content" (or libvirt_read_user_content) sebool setting, and yet the command:
virsh iface-define ~laine/bin/br0.xml
(which performs the exact same library calls, but through libvirtd) runs with no selinux violations. ncftool's use of xml files is exactly identical to virsh's/libvirt's, and it should have the same permissions.
Alternately, please explain what is so bad about allowing ncftool to read a user-generated file and use it in a call to the netcf library, when libvirt's virsh does exactly the same thing with default selinux settings. (Don't think that you'll have an easy time convincing me, though ;-)
Disabling this behavior by default and hiding it behind a boolean seems like miserable behavior, and going to break things for nearly every potentional user of 'ncftool define'. These are the types of things that will make people just turn off selinux because they don't understand what is going wrong, why it's going wrong, or how to properly fix it (many ncftool users will be on text console only, so won't get to see setroubleshoot info). Granted I'm not a security expert, but making certain commands useless for a large portion of usecases doesn't seem helpful. ncftool is a root process, and it should stay out of /home. We do not want confined domains accessing files in the homedir (you can have lots of secret stuff there). But I know it can be used this way so we added a boolean for this case. I am also afraid to allow ncftool to read random SELinux types. ncftool must be run under root privileges so I don't think so enabling of boolean is a big problem (users, which use ncftool, modify the network configuration of a system). Also I am sure Dan will comment it. Aside from the discouragement factor that Cole mentions (very important), there is a problem of inconsistency, and inconsistency very often indicates a hack. "ncftool define br0.xml" and "virsh iface-define br0.xml" are essentially the same thing - both read a file of xml data, and call the netcf library with it, both must run as root. However, the way it is setup now, there is a special selinux boolean required to make the ncftool command work, but no similar selinux boolean exists for virsh. Why? What is different between these two programs? Before I can agree that adding this boolean is a reasonable idea, I need to at least see an answer to that question. I would hate for this new inconsistent boolean go into RHEL6.0 and then later be determined unnecessary - by the time there is a release of the OS, it can no longer be removed. Miroslav is it really necessary to transition from unconfined_t to ncftool_t? If we remove the transition, then it will work because it will run under unconfined_t. Does labeling get screwed up? After discussion on the #virt list, I think we should either remove the transition from unconfined_t to ncftool_t or just let ncftool_t read home content without the boolean. I believe this policy only exists to maintain file labels of net_conf_t. Miroslav is there any other reason for the transition? dwalsh recommended that I perform at test: chcon -t bin_t /usr/bin/ncftool (run ncftool commands that modify the files) restorecon -R -v /etc (to see if anything changed. I ran this test with selinux-policy-3.7.19-37.el6.noarch, since I hadn't had the chance to update to -38 yet. ncftool_read_user_content was set to "no". Also, I put /etc/sysconfig/iptables into a state that guaranteed ncftool would need to update it (and verified afterwards that it had). The results were that: 1) all commands completed with no AVCs, 2) restorecon reported no problems with the labels on any files in /etc. Removing the transition. Fixed in selinux-policy-3.7.19-39.el6.noarch. Available from brew. I have verified that there are no more AVCs with 3.7.19-39. I ran the test with and without NetworkManager installed, and forced the rewriting of /etc/sysconfig/iptables. When I was finished, I ran "restorecon -R -v /etc", and everything came up clean. Thanks! Thanks for testing. Red Hat Enterprise Linux 6.0 is now available and should resolve the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you. |