Bug 211039 - xinetd integration with SELinux
xinetd integration with SELinux
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xinetd (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: James Antill
Brock Organ
:
Depends On: 209379
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-16 17:07 EDT by Irina Boverman
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version: beta2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-22 20:23:37 EST
Type: ---
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 Irina Boverman 2006-10-16 17:07:33 EDT
+++ This bug was initially created as a clone of Bug #209379 +++

Description of problem:

This problem was discussed in the LSPP conference call and on the
selinux and lspp mailing lists so I'm filing the bugzilla for
tracking purposes.  The issue was raised by Stephen Smalley and
according to Stephen, xinetd will run a service with different a
TE context that the service should have.
See:
https://www.redhat.com/archives/redhat-lspp/2006-October/msg00013.html

Version-Release number of selected component (if applicable):
I believe this is with Rawhide and perhaps FC6 and RHEL5.

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

From the mail:

On Tue, 2006-10-03 at 10:04 -0500, Loulwa Salem wrote:

>> xinetd
>> -------
>>      GW: anyone has problems with xinetd
>>      PM: there was a discussion on mailing list on the thread of sec id
>> 	reconciliation that I told steve about. Basically Stephen smalley had
>> 	some concerns about xinetd. I have not seen a reply from Steve.
>>      DW: what is this about?
>>      PM: Stephen smalley basically wanted to use, and I'm gonna make up a term
>> 	here, a hybrid context. he wasn't happy with blindly taking the ftp
>> 	context. I think we can handle that in user space so probably not a big
>> 	deal
>>      GW: so we'll keep discussing xinetd next week as well


To clarify, if xinetd simply runs the service in the peer context, then
the TE domain of the service won't be what we expect it to be, e.g.
instead of running gssftp (/usr/kerberos/sbin/ftpd) in ftpd_t, it would
end up running in the peer's domain (e.g. unconfined_t under targeted,
user_t under strict, or if we had a distinct domain for the ftp client,
whatever domain it would run in).

Looking back, I first raised this issue on redhat-lspp Sep 29 2005 (yes
2005) in response to earlier discussion of the xinetd patch, but
unfortunately lost track of it and didn't remember when the xinetd patch
finally resurfaced this year.  Sorry.

xinetd can ask the kernel what context it would normally run the service
in by default via security_compute_create(), and can adjust the MLS
component based on the peer context.
Comment 3 James Antill 2006-12-01 12:24:20 EST
This is fixed in RHEL-5:xinetd-2_3_14-9
Comment 4 James Antill 2006-12-06 10:24:20 EST
The exec fix is needed on top of this, so it's now fixed in
RHEL-5:xinetd-2_3_14-10_el5
Comment 5 RHEL Product and Program Management 2006-12-22 20:23:37 EST
A package has been built which should help 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.