Bug 635904 - SELinux is preventing /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/tnslsnr access to a leaked /dev/pts/2 file descriptor.
Summary: SELinux is preventing /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Spacewalk
Classification: Community
Component: Server
Version: 1.1
Hardware: i386
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jan Pazdziora (Red Hat)
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard: setroubleshoot_trace_hash:f370d26fff6...
Depends On:
Blocks: space15
TreeView+ depends on / blocked
 
Reported: 2010-09-21 00:44 UTC by Frank Ybanez
Modified: 2011-05-12 10:28 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-05-12 10:28:21 UTC
Embargoed:


Attachments (Terms of Use)

Description Frank Ybanez 2010-09-21 00:44:18 UTC
Summary:

SELinux is preventing
/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/tnslsnr access to a
leaked /dev/pts/2 file descriptor.

Detailed Description:

[tnslsnr has a permissive type (oracle_tnslsnr_t). This access was not denied.]

SELinux denied access requested by the tnslsnr command. It looks like this is
either a leaked descriptor or tnslsnr output was redirected to a file it is not
allowed to access. Leaks usually can be ignored since SELinux is just closing
the leak and reporting the error. The application does not use the descriptor,
so it will run properly. If this is a redirection, you will not get output in
the /dev/pts/2. You should generate a bugzilla on selinux-policy, and it will
get routed to the appropriate package. You can safely ignore this avc.

Allowing Access:

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

Additional Information:

Source Context                unconfined_u:system_r:oracle_tnslsnr_t:s0
Target Context                unconfined_u:object_r:user_devpts_t:s0
Target Objects                /dev/pts/2 [ chr_file ]
Source                        tnslsnr
Source Path                   /usr/lib/oracle/xe/app/oracle/product/10.2.0/serve
                              r/bin/tnslsnr
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           oracle-xe-univ-10.2.0.1-1.0
Target RPM Packages           
Policy RPM                    selinux-policy-3.7.19-54.fc13
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   leaks
Host Name                     (removed)
Platform                      Linux (removed) 2.6.34.6-54.fc13.i686.PAE #1 SMP
                              Sun Sep 5 17:33:43 UTC 2010 i686 i686
Alert Count                   1
First Seen                    Mon 20 Sep 2010 04:10:56 PM MST
Last Seen                     Mon 20 Sep 2010 04:10:56 PM MST
Local ID                      496f099e-da6f-4bdc-8efe-f7c71b4049da
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1285024256.174:76): avc:  denied  { append } for  pid=4039 comm="tnslsnr" path="/dev/pts/2" dev=devpts ino=5 scontext=unconfined_u:system_r:oracle_tnslsnr_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file

node=(removed) type=SYSCALL msg=audit(1285024256.174:76): arch=40000003 syscall=11 per=400000 success=yes exit=0 a0=88dd180 a1=88dd150 a2=88dd220 a3=88dd150 items=0 ppid=1 pid=4039 auid=500 uid=250 gid=250 euid=250 suid=250 fsuid=250 egid=250 sgid=250 fsgid=250 tty=(none) ses=1 comm="tnslsnr" exe="/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/tnslsnr" subj=unconfined_u:system_r:oracle_tnslsnr_t:s0 key=(null)



Hash String generated from  leaks,tnslsnr,oracle_tnslsnr_t,user_devpts_t,chr_file,append
audit2allow suggests:

#============= oracle_tnslsnr_t ==============
allow oracle_tnslsnr_t user_devpts_t:chr_file append;

Comment 1 Jan Pazdziora (Red Hat) 2010-10-04 16:38:00 UTC
Taking.

Frank,

does this AVC denial happen during installation / configuration of the Oracle XE,
or when you further install Spacewalk, or perhaps when rebooting the system?

Thank you for clarification,

Jan

Comment 2 Frank Ybanez 2010-10-04 18:02:09 UTC
It appears to definitely be doing this upon reboot. It also may have occurred during the installation/configuration as well.

Comment 3 Jan Pazdziora (Red Hat) 2010-10-27 08:32:00 UTC
Mass-aligning under space12, so that we don't lose track of this bugzilla. This however does not mean that we plan (will be able to) address this bug in Spacewalk 1.2.

Comment 4 Jan Pazdziora (Red Hat) 2010-11-19 16:04:39 UTC
Mass-moving to space13.

Comment 5 Jan Pazdziora (Red Hat) 2010-11-25 07:26:45 UTC
(In reply to comment #2)
> It appears to definitely be doing this upon reboot. It also may have occurred
> during the installation/configuration as well.

Alright, this is however important distinction. Do you really have two AVC denials in the audit.log?

Comment 6 Miroslav Suchý 2011-04-11 07:33:14 UTC
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.

Comment 7 Miroslav Suchý 2011-04-11 07:37:05 UTC
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.

Comment 8 Jan Pazdziora (Red Hat) 2011-05-12 10:28:21 UTC
We don't seem to have more details about how many AVCs there were.

No similar report found, closing now.


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