Bug 730843 - SELinux is preventing /usr/sbin/radiusd from read access on the directory /var/tmp
Summary: SELinux is preventing /usr/sbin/radiusd from read access on the directory /va...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 14
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-15 22:05 UTC by Michael Cronenworth
Modified: 2011-10-30 00:34 UTC (History)
6 users (show)

Fixed In Version: selinux-policy-3.9.7-46.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-30 00:34:13 UTC


Attachments (Terms of Use)
radiusd avcs (3.21 KB, text/plain)
2011-08-15 22:05 UTC, Michael Cronenworth
no flags Details
new radiusd avcs (3.26 KB, text/plain)
2011-10-26 17:21 UTC, Michael Cronenworth
no flags Details

Description Michael Cronenworth 2011-08-15 22:05:28 UTC
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.

Comment 1 Daniel Walsh 2011-08-16 12:53:40 UTC
Why is radiousd using /var/tmp instead of /var/run?

Comment 2 Michael Cronenworth 2011-08-16 13:57:10 UTC
(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.

Comment 3 John Dennis 2011-08-16 15:12:13 UTC
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.

Comment 4 Michael Cronenworth 2011-08-16 15:36:59 UTC
(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

Comment 5 John Dennis 2011-08-16 16:26:33 UTC
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.

Comment 6 Michael Cronenworth 2011-08-16 16:45:07 UTC
(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.

Comment 7 John Dennis 2011-08-16 17:34:06 UTC
You didn't specify the platform in the bz, I need to know that to interpret the syscall number in the AVC.

Comment 8 John Dennis 2011-08-16 18:00:13 UTC
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).

Comment 9 Michael Cronenworth 2011-08-16 18:59:01 UTC
If you can provide line numbers I can provide backtraces.

Comment 10 Daniel Walsh 2011-08-17 12:53:19 UTC
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.

Comment 11 John Dennis 2011-08-17 13:31:56 UTC
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?

Comment 12 Michael Cronenworth 2011-08-17 13:49:30 UTC
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.

Comment 13 Daniel Walsh 2011-08-24 12:27:57 UTC
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.

Comment 14 Dominik 'Rathann' Mierzejewski 2011-08-24 16:12:23 UTC
Reassigning to correct component, thanks for spamming me...

Comment 15 Michael Cronenworth 2011-08-26 14:56:33 UTC
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)

Comment 16 John Dennis 2011-09-12 13:18:13 UTC
Note, this same issue has been reported in RHEL 6 as bug 737495

Comment 17 Fedora Update System 2011-10-20 11:58:15 UTC
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

Comment 18 Fedora Update System 2011-10-22 08:21:30 UTC
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).

Comment 19 Michael Cronenworth 2011-10-26 17:21:24 UTC
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.

Comment 20 Miroslav Grepl 2011-10-27 06:38:47 UTC
(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

Comment 21 Fedora Update System 2011-10-30 00:34:13 UTC
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.


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