Bug 195977 - Targeted policy blocking TFTP daemon LDAP access
Summary: Targeted policy blocking TFTP daemon LDAP access
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: tftp
Version: 5
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 192555
TreeView+ depends on / blocked
 
Reported: 2006-06-20 02:24 UTC by Ian Pilcher
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-03-28 20:04:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Suggested patch for when initgroups fails. (444 bytes, text/x-patch)
2006-06-22 11:30 UTC, Daniel Walsh
no flags Details

Description Ian Pilcher 2006-06-20 02:24:29 UTC
Description of problem:
Add the TFTP daemon /usr/sbin/in.tftpd to the list of programs that tries
to contact the LDAP server when nss_ldap is enabled.  Voluminous audit
messages available on request.

Version-Release number of selected component (if applicable):
selinux-policy-targeted-2.2.43-4.fc5

How reproducible:
100%

Steps to Reproduce:
1.  Enable nss_ldap
2.  Enable tftp
3.  Attempt to retrieve a file via tftp
4.  Watch attempt timeout
  
Actual results:
nss_ldap attempts to contact the LDAP server to get supplemental group
info for the 'nobody' user.  SELinux denies connection.

Expected results:
Policy should allow connection (or see workaround below).

Additional info:
Workaround is to add 'nobody' to nss_initgroups_ignoreusers line in
/etc/ldap.conf.

Comment 1 Daniel Walsh 2006-06-22 00:54:49 UTC
Does it work even with the denial.  IE If I just dontaudit the connection to
ldap will tftp still work?

Comment 2 Ian Pilcher 2006-06-22 01:47:28 UTC
(In reply to comment #1)
> Does it work even with the denial.  IE If I just dontaudit the connection to
> ldap will tftp still work?

Nope.  I was using it for PXE installations (does anyone use TFTP for anything
else?), and the system just sat there.  Once I added 'nobody' to
nss_initgroups_ignoreusers things started working again.  (Now there may an
argument that 'nobody' should be there by default; that's a question for the
nss_ldap guys.)

Comment 3 Daniel Walsh 2006-06-22 11:28:43 UTC
Yes I talked to him about this, but I believe we would have the same problem
with NIS.  So I think we need to allow the priv.  Just kind of scary that you
need to give all these privs to an app just so it can fail to find nobody.  We
could change tftp to not fail if initgroups fails...

I am reassiging to tftp, to stop it failing if the netgroups call fails.

Comment 4 Daniel Walsh 2006-06-22 11:30:41 UTC
Created attachment 131343 [details]
Suggested patch for when initgroups fails.

I think initgroups should fail over to using setgroups.  That way SELinux does
not need to add lots of access.

Comment 5 Ian Pilcher 2006-06-22 12:53:21 UTC
(In reply to comment #3)
> Yes I talked to him about this, but I believe we would have the same problem
> with NIS.  So I think we need to allow the priv.  Just kind of scary that you
> need to give all these privs to an app just so it can fail to find nobody.  We
> could change tftp to not fail if initgroups fails...
> 
> I am reassiging to tftp, to stop it failing if the netgroups call fails.

Wouldn't the same argument apply to other daemons?  xfs seems to be a fit the
bill -- bug #192555.  Personally, I find this whole thing of network groups for
local users to be a bit dicey -- something that should probably be off by default.

Comment 6 Joachim Selke 2006-08-22 14:51:24 UTC
I can confirm that this bug is fixed in selinux-policy-targeted-2.3.3-8.fc5.

Comment 7 Daniel Walsh 2007-03-28 20:04:45 UTC
Closing bugs



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