Creating SELinux Context Type in RHEL5

Latest response

Our environment is running RHEL 5 and there are still a handful of servers with SELinux set to permissive mode. I've been going through the audit logs and generating policy entries as needed, but I have run into a situation where the context type I need does not exist.

 

In order to determine what policies to generate, I've been comparing some of the AVC denial messages on my RHEL 5 boxes with some of the newer policies (CentOS 6.3 and Fedora 17) to find out if there are any entries to address the denials I'm getting. In many cases, the denials I'm getting are set to "dontaudit" in newer OS versions.

 

What I'm running up against now is the fact that we have VMWare Tools on a few servers and that is getting flagged. When I look at my CentOS system, there are several file contexts for VMWare-related files. In the RHEL 5 policies, however, these contexts do not exist, so I can't create file contexts using 'semanage' because the 'type' is not recognized.

 

How do I create a 'type' so that I can assign that type to a group of files on my server? I haven't been able to find much about this, so I thought I'd try posting something here.

 

Thanks in advance for any suggestions!

DC
Log in to join the conversation

Responses

rhn-engineering-dwalsh's picture Red Hat Pro 435 points
30 November 2012 8:24 PM

What AVC messages are you trying to fix?

DC Pro 539 points
30 November 2012 8:47 PM

I'm getting the following:

 

type=SYSCALL msg=audit(1354089926.966:15635): arch=c000003e syscall=59 success=yes exit=0 a0=b0da800 a1=b0d6e20 a2=b0d9b10 a3=8 items=0 ppid=31002 pid=31003 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ifconfig" exe="/sbin/ifconfig" subj=system_u:system_r:ifconfig_t:s0 key=(null)

 

type=AVC msg=audit(1354089926.966:15635): avc:  denied  { read write } for  pid=31003 comm="ifconfig" path="/var/run/vmware/vmum-guestagent.pid" dev=dm-0 ino=2754572 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file

 

type=AVC msg=audit(1354089926.966:15635): avc:  denied  { append } for  pid=31003 comm="ifconfig" path="/usr/share/vmum-ga/getInventoryErrors" dev=dm-0 ino=2726978 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
 

In newer versions of the file_contexts file, I see that there are types defined for vmware. On my RHEL 5 box, however, these types are not defined. I don't want to open up access for a given type to all of usr_t or file_t, so I would like to set a more appropriate context for these files in order to determine how I want the system to handle them (allow or not audit or what have you).

 

Thanks for the quick response.

rhn-engineering-dwalsh's picture Red Hat Pro 435 points
4 December 2012 3:30 AM

file_t indicates you have a file with no labels on it.  /var/run/vmware/vmumguestagent.pid does not have a label.

 

On my Fedora 18 box, matchpathcon /var/run/vmware/vmum-guestagent.pid
/var/run/vmware/vmum-guestagent.pid    system_u:object_r:vmware_host_pid_t:s0
 

 

Indicates that this pid file should be labeled vmware_host_pid_t.

 

It is probably best if you just delete the file/directory and let vmware recreate it with a label.

 

All of these AVC's look like leaked file descriptors.

 

http://danwalsh.livejournal.com/53603.html

 

ifconfig seems to be appending content into /usr/share/vmum-ga/getInventoryErrors, which might work if it was labeled var_log_t.

 

chcon -t var_log_t /usr/share/vmum-ga/getInventoryErrors

 

If this  eliminates the AVC ,you could make this permanent with the following command:

 

semanage fcontext -a -t var_log_t /usr/share/vmum-ga/getInventoryErrors

DC Pro 539 points
4 December 2012 6:26 PM

I suppose using var_log_t could work, though I'd prefer use the "vmware..._t" context if that is the most appropriate thing. I may be forced to use var_log_t, however, as the initial problem is that in RHEL5, there is no such thing as a "vmware..._t" context.

 

As for the "leaked file descriptors"....I hope to one day have a clue what that even means, but that will be a discussion for another day perhaps.

 

For now, I think I'll try using the var_log_t since I'm not familiar with how to creat a new context for the vmware files.

 

Thanks for the help!

rhn-engineering-dwalsh's picture Red Hat Pro 435 points
5 December 2012 7:52 PM

Dan, if you read my blog above it has a description of what is a leaked file descriptor...

 

Bottom line, when programmers write code that opens files or sockets it creates a file descriptor, by default these file descritors are leaked to all programs that are executed by the current program.  SELinux looks at each of these leaked file descriptors and determins if the new process is allowed to use them.  If not SELinux closes the descriptor and prints an ugly message in the log file.  Programmers can fix there code by "closing the file descriptors on exec", and then the problem goes away.

DC Pro 539 points
6 December 2012 12:22 AM

Thanks. I appreciate you taking the time to explain that. I know I have a long way to go and a whole lot to learn, so I certainly appreciate any time someone is willing to share knowledge.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.