Bug 1209969

src/OVAL/oval_probe_ext.c

 555                         if (SEAP_close(ctx, pd->sd) != 0) {
 556                                 char errbuf[__ERRBUF_SIZE];
 557 
 558                                 protect_errno {
 559                                         oscap_dlprintf(DBG_E, "Can't close sd: %u, %s.\n", errno, strerror(errno));
 560                                         SEAP_msg_free(s_imsg);
 561                                         SEAP_msg_free(s_omsg);
 562                                 }
 563 
 564                                 if (strerror_r (errno, errbuf, sizeof errbuf - 1) != 0)
 565                                         oscap_seterr (OSCAP_EFAMILY_OVAL, "Unable to close probe sd");
 566                                 else
 567                                         oscap_seterr (OSCAP_EFAMILY_OVAL, errbuf);
 568 
 569                                 pd->sd = -1;
 570                                 return (-1);
 571                         }


src/XCCDF/xccdf_session.c

 758                 if (tmp_sess == NULL) {
 759                         oscap_seterr(OSCAP_EFAMILY_OSCAP, "Failed to create new OVAL agent session for: '%s'.", contents[idx]->href);
 760                         oval_definition_model_free(tmp_def_model);
 761                         return 2;
 762                 }

This is due to bug in openscap-selinux package.

type=AVC msg=audit(1428672795.077:70): avc:  denied  { read } for  pid=12363 comm="oscap" name="com.redhat.rhsa-all.xccdf.xml" dev="dm-0" ino=135840547 scontext=unconfined_u:unconfined_r:oscap_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
type=AVC msg=audit(1428672795.077:70): avc:  denied  { open } for  pid=12363 comm="oscap" path="/root/com.redhat.rhsa-all.xccdf.xml" dev="dm-0" ino=135840547 scontext=unconfined_u:unconfined_r:oscap_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file

As a workaround please remove openscap-selinux package.

I can confirm the AVC messages.

Putting SELinux into permissive resolves the issue.

~rp

Yep, but don't turn selinux off in production. Just keep openscap-selinux out until rhel-7.2.

Thanks for report Robin.

Simon,

Not a problem.  I'll continue to monitor the bug.  Do you want me to work with the SELinux team around this or do we already have a pretty good idea where the issue is?  

I am having a hard time understanding the errors because your tcontext is admin_home_t while my tcontext are sandbox_file_t.

[...]
type=AVC msg=audit(1428353905.837:1073): avc:  denied  { getattr } for  pid=18930 comm="oscap" path="/home/rprice/summit2015/com.redhat.rhsa-all.xccdf.xml" dev="sda1" ino=13238727 scontext=unconfined_u:unconfined_r:oscap_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:sandbox_file_t:s0:c481,c649 tclass=file
type=SYSCALL msg=audit(1428353905.837:1073): arch=c000003e syscall=4 success=yes exit=0 a0=7fffde118288 a1=7fffde1172d0 a2=7fffde1172d0 a3=7fffde117050 items=0 ppid=18923 pid=18930 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts4 ses=29 comm="oscap" exe="/usr/bin/oscap" subj=unconfined_u:unconfined_r:oscap_t:s0-s0:c0.c1023 key=(null)
[...]


This this a bug in oscap.te policy when invoking transitions?

This is bug in oscap.te. No need for official SELinux involvement. OpenSCAP and SELinux people hang out together. :)

I think that we should not confine 'oscap' scanner at all. It can read and write files in lot of different places like /home, /tmp, /usr and it should be probably confined only by a context of process which runs it. At the same time, probes could be confined so that they couldn't write to arbitrary files for cases when the scanner runs a malicious content.

Mirek, what do you think about it?

I agree.

openscap.git a827637ecbb661d1767236b413c1678d13184df6

*** Bug 1234336 has been marked as a duplicate of this bug. ***

Verified, regression tests passed as well.

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/RHEA-2015-2356.html