RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 621499 - SELinux is preventing /usr/bin/ncftool "relabelto" access on system-config-firewall.augnew
Summary: SELinux is preventing /usr/bin/ncftool "relabelto" access on system-config-fi...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
URL:
Whiteboard: setroubleshoot_trace_hash:71fceceb082...
: 602464 (view as bug list)
Depends On: 616166
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-05 10:07 UTC by Milos Malik
Modified: 2012-10-15 15:15 UTC (History)
7 users (show)

Fixed In Version: selinux-policy-3.7.19-37.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 616166
Environment:
Last Closed: 2010-11-10 21:36:02 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
AVCs found during testing (15.76 KB, text/plain)
2010-08-05 10:09 UTC, Milos Malik
no flags Details
avc's still remaining with selinux-policy-3.7.19-36 (3.98 KB, text/plain)
2010-08-06 18:41 UTC, Laine Stump
no flags Details
AVCs found after test modification (7.54 KB, text/plain)
2010-08-10 14:22 UTC, Milos Malik
no flags Details
AVCs still remaining with selinux-policy-3.7.19-37.el6.noarch (5.55 KB, text/plain)
2010-08-11 02:13 UTC, Laine Stump
no flags Details
AVCs still remaining with ncftool_read_user_content set to on (3.49 KB, text/plain)
2010-08-11 14:26 UTC, Laine Stump
no flags Details

Description Milos Malik 2010-08-05 10:07:04 UTC
+++ This bug was initially created as a clone of Bug #616166 +++


Summary:

SELinux is preventing /usr/bin/ncftool "relabelto" access on
system-config-firewall.augnew.

Detailed Description:

[ncftool has a permissive type (ncftool_t). This access was not denied.]

SELinux denied access requested by ncftool. It is not expected that this access
is required by ncftool and this access may signal an intrusion attempt. It is
also possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug
report.

Additional Information:

Source Context                unconfined_u:unconfined_r:ncftool_t:s0-s0:c0.c1023
Target Context                system_u:object_r:system_conf_t:s0
Target Objects                system-config-firewall.augnew [ file ]
Source                        ncftool
Source Path                   /usr/bin/ncftool
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           netcf-0.1.6-1.fc13
Target RPM Packages           
Policy RPM                    selinux-policy-3.7.19-33.fc13
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     (removed)
Platform                      Linux (removed) 2.6.33.6-147.fc13.x86_64 #1 SMP
                              Tue Jul 6 22:32:17 UTC 2010 x86_64 x86_64
Alert Count                   1
First Seen                    Mon 19 Jul 2010 02:58:52 PM EDT
Last Seen                     Mon 19 Jul 2010 02:58:52 PM EDT
Local ID                      6f0bf08b-f094-49df-b7e5-b28c0465366f
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1279565932.101:29404): avc:  denied  { relabelto } for  pid=4073 comm="ncftool" name="system-config-firewall.augnew" dev=sda1 ino=14185414 scontext=unconfined_u:unconfined_r:ncftool_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_conf_t:s0 tclass=file

node=(removed) type=SYSCALL msg=audit(1279565932.101:29404): arch=c000003e syscall=189 success=yes exit=0 a0=846ff0 a1=3150a15689 a2=956e30 a3=23 items=0 ppid=4039 pid=4073 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=232 comm="ncftool" exe="/usr/bin/ncftool" subj=unconfined_u:unconfined_r:ncftool_t:s0-s0:c0.c1023 key=(null)



Hash String generated from  catchall,ncftool,ncftool_t,system_conf_t,file,relabelto
audit2allow suggests:

#============= ncftool_t ==============
allow ncftool_t system_conf_t:file relabelto;

Comment 1 Milos Malik 2010-08-05 10:07:46 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

Comment 2 Milos Malik 2010-08-05 10:09:30 UTC
Created attachment 436790 [details]
AVCs found during testing

Comment 4 RHEL Program Management 2010-08-05 10:27:52 UTC
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. **

Comment 5 Miroslav Grepl 2010-08-05 11:05:46 UTC
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"

Comment 6 Milos Malik 2010-08-05 13:18:59 UTC
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

Comment 7 Laine Stump 2010-08-05 14:55:55 UTC
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

Comment 8 Laine Stump 2010-08-05 15:01:33 UTC
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.

Comment 9 Daniel Walsh 2010-08-05 19:55:44 UTC
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.

Comment 10 Miroslav Grepl 2010-08-06 09:35:29 UTC
I was finally able to reproduce it. 

Dan, 
you are right. We need to add

optional_policy(`
 iptables_initrc_domtrans(ncftool_t)
')

Comment 11 Miroslav Grepl 2010-08-06 13:19:22 UTC
Laine,
could you test ncftool stuff with selinux-policy-3.7.19-36.el6. The packages are available from brew.

Thanks.

Comment 12 Laine Stump 2010-08-06 18:34:53 UTC
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)

Comment 13 Laine Stump 2010-08-06 18:41:02 UTC
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.

Comment 14 Laine Stump 2010-08-06 18:44:44 UTC
*** Bug 602464 has been marked as a duplicate of this bug. ***

Comment 15 Miroslav Grepl 2010-08-09 10:18:26 UTC
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.

Comment 16 Miroslav Grepl 2010-08-09 10:43:18 UTC
> 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.

Comment 17 Laine Stump 2010-08-09 21:53:46 UTC
> 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.

Comment 18 Laine Stump 2010-08-09 21:57:24 UTC
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

Comment 19 Miroslav Grepl 2010-08-10 09:31:16 UTC
'/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?

Comment 20 Daniel Walsh 2010-08-10 12:14:02 UTC
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)

Comment 21 Miroslav Grepl 2010-08-10 12:50:59 UTC
(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.

Comment 22 Laine Stump 2010-08-10 13:51:54 UTC
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?

Comment 23 Laine Stump 2010-08-10 13:55:40 UTC
(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).

Comment 24 Laine Stump 2010-08-10 14:14:52 UTC
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...

Comment 25 Milos Malik 2010-08-10 14:20:56 UTC
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)

Comment 26 Milos Malik 2010-08-10 14:22:09 UTC
Created attachment 437898 [details]
AVCs found after test modification

Comment 27 Miroslav Grepl 2010-08-10 18:15:29 UTC
Fixed in selinux-policy-3.7.19-37.el6.noarch

Comment 28 Laine Stump 2010-08-11 02:13:39 UTC
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.

Comment 29 Miroslav Grepl 2010-08-11 07:12:18 UTC
Turn on 'ncftool_read_user_content' boolean.


# setsebool -P ncftool_read_user_content on

Comment 30 Laine Stump 2010-08-11 14:26:40 UTC
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 ;-)

Comment 31 Cole Robinson 2010-08-11 14:58:37 UTC
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.

Comment 33 Miroslav Grepl 2010-08-12 08:39:57 UTC
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.

Comment 35 Laine Stump 2010-08-12 15:17:41 UTC
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.

Comment 36 Daniel Walsh 2010-08-12 15:28:35 UTC
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?

Comment 37 Daniel Walsh 2010-08-12 15:52:00 UTC
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?

Comment 38 Laine Stump 2010-08-12 17:01:45 UTC
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.

Comment 39 Miroslav Grepl 2010-08-13 08:35:24 UTC
Removing the transition.

Comment 40 Miroslav Grepl 2010-08-13 09:06:51 UTC
Fixed in selinux-policy-3.7.19-39.el6.noarch. Available from brew.

Comment 41 Laine Stump 2010-08-13 13:13:23 UTC
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!

Comment 42 Miroslav Grepl 2010-08-13 13:19:44 UTC
Thanks for testing.

Comment 44 releng-rhel@redhat.com 2010-11-10 21:36:02 UTC
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.


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