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.
Created attachment 142437 [details] Combine local and remote contexts when using netlabel'd contexts Here's the latest patch to solve this problem. The config. stuff isn't used, if this is accepted I'll remove it and repost. It's also available in rpm form from: http://people.redhat.com/jantill/xinetd/
Fix checked into CVS.