Created attachment 518354 [details] radiusd avcs Description of problem: AVCs attached. Yes, I plan on implementing a local rule to allow it. restorecon -Rv /var/tmp returns nothing. Version-Release number of selected component (if applicable): selinux-policy-3.9.7-42.fc14.noarch How reproducible: Always Steps to Reproduce: 1. Start radiusd service 2. Use radtest to connect with a bad username and password. Using a valid username and password does not cause the AVCs. Actual results: Everything looks normal from the user's point of view. The server admin has AVC messages. Expected results: No AVC messages.
Why is radiousd using /var/tmp instead of /var/run?
(In reply to comment #1) > Why is radiousd using /var/tmp instead of /var/run? I have no idea. That would be a question for the freeradius maintainer or upstream.
I'm not aware of any use of /var/tmp in radiusd. Not saying there isn't any, just that I'm not aware of any. I'm also curious how you came to the conclusion the path is /var/tmp? The AVC only identifies the directory being accessed as "tmp" without the path.
(In reply to comment #3) > I'm also curious how you came to the conclusion the path is /var/tmp? The AVC > only identifies the directory being accessed as "tmp" without the path. There were three entries in my /var/log/messages file. setroubleshoot: SELinux is preventing /usr/sbin/radiusd from read access on the directory /tmp. For complete SELinux messages. run sealert -l f1d98aed-e571-46a7-b60f-cc1499b12b5a setroubleshoot: SELinux is preventing /usr/sbin/radiusd from read access on the directory /var/tmp. For complete SELinux messages. run sealert -l f1d98aed-e571-46a7-b60f-cc1499b12b5a setroubleshoot: SELinux is preventing /usr/sbin/radiusd from read access on the directory /var/tmp. For complete SELinux messages. run sealert -l f1d98aed-e571-46a7-b60f-cc1499b12b5a $ sudo sealert -l f1d98aed-e571-46a7-b60f-cc1499b12b5a SELinux is preventing /usr/sbin/radiusd from read access on the directory /var/tmp. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that radiusd should be allowed read access on the tmp directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep radiusd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Dan: Why is the path information different in the sealert message from what appears in the AVC? Was setroubleshoot modified to lookup the inode at the moment the AVC fires? Do the various mktemp style entry points and shell utilities utilize /var/tmp by default? Michael: How are you running the service when you see this? Are you running radiusd via the service command or by any chance are you running from the command line? Possibly in debug mode? Do you have TMPDIR set anywhere in your environment when you execute radiusd? Are there any messages in /var/log/radiusd related to failed usage of tmp? So far I've only found one usage of /tmp and it's in the rlm_eap_tls configuration which specifies to openssl to use a directory in /tmp to validating certificates.
(In reply to comment #5) > Michael: > > How are you running the service when you see this? Are you running radiusd via > the service command or by any chance are you running from the command line? > Possibly in debug mode? I am using the service command. I do not have debug mode on. > Do you have TMPDIR set anywhere in your environment when you execute radiusd? No. > Are there any messages in /var/log/radiusd related to failed usage of tmp? No messages. My radius log is defaulting to /var/log/radius/radius.log. > So far I've only found one usage of /tmp and it's in the rlm_eap_tls > configuration which specifies to openssl to use a directory in /tmp to > validating certificates. I have freeradius pointing to my LDAP server that is using STARTTLS. I'm using a locally generated CA and freeradius is pointed to it. User authentication is working with both radtest and a Cisco router so I believe the LDAP connection is fine.
You didn't specify the platform in the bz, I need to know that to interpret the syscall number in the AVC.
For future reference: $ ausyscall 2 x86_64 open BTW, "ausyscall 2" on my i686 box said "fork" which was really confusing. Thank you for providing the platform. I think we'll have to run radiusd under GDB with a (conditional) break point set on open with a path containing "tmp" and get a backtrace because I don't see in the sources where this would be occuring. Of course radiusd is a large complex program which links with many libraries, all of which could be a culprit (so too could be configuration values in /etc/raddb).
If you can provide line numbers I can provide backtraces.
John Dennis, yes setroubleshoot does an slocate based on the name handed to it and attempts to match the inode. I know that code like script << _EOF blah _EOF cause bash to user /tmp, not sure about /var/tmp. I also know that some apps, maybe shell attempt to open files in /tmp, /var/tmp, /dev/shm based on the first one they are allowed to access. I can easily add policy to allow radius to use tmp_t labeled directories, I was really wondering if this was something setup by Michael to cause this or was something in base radius.
re comment #10 I do not believe there are any "here documents" in use by radiusd. The only use of /tmp I'm aware of is described in comment #5 and is a configuration option. However radiusd is a *very* complicated and extensible daemon. It's very hard to statically determine if and when /tmp or /var/tmp is legitimately used. This is compounded by the problem that admins can modify configuration values and even worse specify that perl, python, or shell scripts be executed in the context of radiusd (roughly equivalent to httpd's CGI). My first inclination is not to open an access in the SELinux policy until it's understood if this is intentional desired and well understood usage as opposed to undesired behaviour. What are your thoughts on this Dan?
Anyone should be able to reproduce this. The only config values I have changed are the ldap server address in the ldap module and added two clients to clients.conf. I don't have a custom init script or anything wild that would cause this.
Any chance it is using kerberos and the kerberos libraries are searching tmp for krb5 cache files? You can make radius permissive and see if we get any other avc's # semanage permissive -a radiusd_t Run your test. # semanage permissive -d radiusd_t will turn it off.
Reassigning to correct component, thanks for spamming me...
Daniel, I ran my test using your commands. This was the only AVC/syscall in the audit log: $ sudo grep radiusd /var/log/audit/audit.log type=AVC msg=audit(1314370480.607:36008): avc: denied { read } for pid=634 comm="radiusd" name="tmp" dev=dm-2 ino=149 scontext=unconfined_u:system_r:radiusd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=SYSCALL msg=audit(1314370480.607:36008): arch=c000003e syscall=2 success=yes exit=14 a0=31ac042938 a1=0 a2=1b6 a3=0 items=0 ppid=1 pid=634 auid=502 uid=95 gid=95 euid=95 suid=95 fsuid=95 egid=95 sgid=95 fsgid=95 tty=(none) ses=4900 comm="radiusd" exe="/usr/sbin/radiusd" subj=unconfined_u:system_r:radiusd_t:s0 key=(null)
Note, this same issue has been reported in RHEL 6 as bug 737495
selinux-policy-3.9.7-46.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-46.fc14
Package selinux-policy-3.9.7-46.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.9.7-46.fc14' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-14734 then log in and leave karma (feedback).
Created attachment 530340 [details] new radiusd avcs The radius server has been upgraded to F15 since the opening of this report. I updated to the F15 policy that is supposed to fix this. It is still not fixed. $ rpm -q selinux-policy selinux-policy-3.9.16-44.fc15.noarch After restarting radius and performing a login I see three messages in the syslog. I am attaching the log messages and AVCs.
(In reply to comment #19) > Created attachment 530340 [details] > new radiusd avcs > > The radius server has been upgraded to F15 since the opening of this report. I > updated to the F15 policy that is supposed to fix this. It is still not fixed. > > $ rpm -q selinux-policy > selinux-policy-3.9.16-44.fc15.noarch > > After restarting radius and performing a login I see three messages in the > syslog. I am attaching the log messages and AVCs. Fixed in selinux-policy-3.9.16-46.fc15.noarch You can dontaudit it for now using # grep radius /var/log/audit/audit.log |audit2allow -D -M mypol # semodule -i mypol.pp
selinux-policy-3.9.7-46.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.