(Remove link to SELinux/Troubleshooting/AVCMessages) |
mNo edit summary |
||
(5 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
* [[SELinux/Troubleshooting/AVCDecisions| Decision tree AVC Messages]] | * [[SELinux/Troubleshooting/AVCDecisions| Decision tree AVC Messages]] | ||
SELinux has three modes: | |||
* Enforcing | * Enforcing | ||
**This should be the default mode. | **This should be the default mode. | ||
Line 8: | Line 7: | ||
**The kernel will report Access Violations in the form of AVC messages but will allow the access. | **The kernel will report Access Violations in the form of AVC messages but will allow the access. | ||
**The kernel will also continue to create properly labeled files. | **The kernel will also continue to create properly labeled files. | ||
**There | **There are a couple of major differences with the way the kernel reports these avc messages. | ||
**# The kernel will only report the first access violation in permissive mode for a confined domain on a particular object, where as in enforcing mode, it will report each and every denied access. | **# The kernel will only report the first access violation in permissive mode for a confined domain on a particular object, where as in enforcing mode, it will report each and every denied access. | ||
**# You can get many additional AVC messages that would never have shown up in enforcing mode. For example if a confined domain was not allowed to read a directory or any of the files in it. In enforcing mode the directory access would be denied and one AVC message would be generated. In Permissive mode, the directory access would generate an AVC, and each file read would generate an AVC. | **# You can get many additional AVC messages that would never have shown up in enforcing mode. For example if a confined domain was not allowed to read a directory or any of the files in it. In enforcing mode the directory access would be denied and one AVC message would be generated. In Permissive mode, the directory access would generate an AVC, and each file read would generate an AVC. | ||
Line 22: | Line 21: | ||
* [[SELinux/ManagingFileContext| Managing File Context]] | * [[SELinux/ManagingFileContext| Managing File Context]] | ||
* cp vs. mv | * cp vs. mv | ||
**The cp command creates the new file | **The cp command creates the new file with either the context of the destination file, if it exists, or the security context of the destination directory. | ||
**The mv command attempts to maintain the security context of the file being moved. | **The mv command attempts to maintain the security context of the file being moved. | ||
**This can lead to some problems in file context. For example, in targeted policy, if you were to ''cp /etc/resolv.conf /tmp'' and do some editing of /tmp/resolv.conf. Then you moved resolv.conf back to /etc with the ''mv /tmp/resolv.conf /etc''. The file will end up with the tmp_t security context type instead of the net_conf_t type. Many domains will now not be able to read resolv.conf, resulting in failures. You can easily clear this up with ''restorecon /etc/resolv.conf''. | **This can lead to some problems in file context. For example, in targeted policy, if you were to ''cp /etc/resolv.conf /tmp'' and do some editing of /tmp/resolv.conf. Then you moved resolv.conf back to /etc with the ''mv /tmp/resolv.conf /etc''. The file will end up with the tmp_t security context type instead of the net_conf_t type. Many domains will now not be able to read resolv.conf, resulting in failures. You can easily clear this up with ''restorecon /etc/resolv.conf''. | ||
Line 33: | Line 32: | ||
*AVC Messages are missing | *AVC Messages are missing | ||
SELinux has some messages that it will not audit. There are dontaudit rules written in policy. Usually these are expected denials and they just cause the application to take a different code path. Sometimes these dontaudit rules might cover up a failure. | SELinux has some messages that it will not audit. There are dontaudit rules written in policy. Usually these are expected denials and they just cause the application to take a different code path. Sometimes these dontaudit rules might cover up a failure. | ||
Sometimes SELinux can block a processes access to a file without generating an error message, you can disable these dontaudit messages by executing | |||
* semodule -DB | |||
Read more about this at | |||
* http://danwalsh.livejournal.com/11673.html | |||
Interesting Reading on Setting up and examining Permissive and Unconfined domains. | |||
* http://danwalsh.livejournal.com/42394.html | |||
If you have other SELinux questions or problems go to #selinux on Freenode to get help or ask questions on selinux@lists.fedoraproject.org. | |||
A handy way of looking for articles on SELinux is to use "site:danwalsh.livejournal.com" in your google searches. | |||
For example google: | |||
confined domains site:danwalsh.livejournal.com | |||
*Man Pages | |||
All confined domains should now have an DOMAIN_selinux.8 man page which describes all of the SELinux labels, booleans, types associated with this domain. | |||
man named_selinux | |||
[[Category:SELinux]] |
Latest revision as of 16:28, 27 July 2020
SELinux has three modes:
- Enforcing
- This should be the default mode.
- The kernel is blocking all access unless they are explicitly allowed. All denied accesses are reported in the logging system as AVC (Access Vector Cache), unless policy writers have explicitly told the kernel to dontaudit the message.
- Permissive
- The kernel will report Access Violations in the form of AVC messages but will allow the access.
- The kernel will also continue to create properly labeled files.
- There are a couple of major differences with the way the kernel reports these avc messages.
- The kernel will only report the first access violation in permissive mode for a confined domain on a particular object, where as in enforcing mode, it will report each and every denied access.
- You can get many additional AVC messages that would never have shown up in enforcing mode. For example if a confined domain was not allowed to read a directory or any of the files in it. In enforcing mode the directory access would be denied and one AVC message would be generated. In Permissive mode, the directory access would generate an AVC, and each file read would generate an AVC.
- When reporting AVC Messages we would prefer that you report avc messages in Enforcing mode. But sometimes Permissive mode is necessary to get all the AVC Messages. You can boot the kernel in permissive mode with the enforcing=0 switch.
- You can use setenforce 0 to turn on permissive mode. setenforce 1 to turn on enforcing mode.
- Disabled
- Turns off SELinux enforcement entirely and also stops the creation of proper labels on the files.
- You should only disable SELinux if you do not intend to use it. You should use permissive mode when diagnosing a problem.
- If you want to disable SELinux, you need to edit /etc/selinux/config and change the SELINUX line to disabled. You will then need to reboot the machine, since SELinux is running within the kernel.
- If you wish to reenable SELinux you will need to relabel the entire file system.
- Managing File Context
- cp vs. mv
- The cp command creates the new file with either the context of the destination file, if it exists, or the security context of the destination directory.
- The mv command attempts to maintain the security context of the file being moved.
- This can lead to some problems in file context. For example, in targeted policy, if you were to cp /etc/resolv.conf /tmp and do some editing of /tmp/resolv.conf. Then you moved resolv.conf back to /etc with the mv /tmp/resolv.conf /etc. The file will end up with the tmp_t security context type instead of the net_conf_t type. Many domains will now not be able to read resolv.conf, resulting in failures. You can easily clear this up with restorecon /etc/resolv.conf.
- AVC Messages
- Sometimes the auditlog information is tough to read and understand; a lot of times I run audit2allow on it to clear up the output.
- Audit Daemon
- In Fedora Core 5/Rawhide the Audit system has moved some of the AVC messages to /var/log/audit/audit.log. Some AVC messages continue to show up in the /var/log/messages file though. Usually these show up when the audit daemon is not running.
- You can use the ausearch -m avc command to display the avc messages from the audit log. There are other useful commands such as -x to specify the executable. The -ts option allows you to specify the time you want to see messages afterwards.
- AVC Messages are missing
SELinux has some messages that it will not audit. There are dontaudit rules written in policy. Usually these are expected denials and they just cause the application to take a different code path. Sometimes these dontaudit rules might cover up a failure. Sometimes SELinux can block a processes access to a file without generating an error message, you can disable these dontaudit messages by executing
- semodule -DB
Read more about this at
Interesting Reading on Setting up and examining Permissive and Unconfined domains.
If you have other SELinux questions or problems go to #selinux on Freenode to get help or ask questions on selinux@lists.fedoraproject.org.
A handy way of looking for articles on SELinux is to use "site:danwalsh.livejournal.com" in your google searches.
For example google:
confined domains site:danwalsh.livejournal.com
- Man Pages
All confined domains should now have an DOMAIN_selinux.8 man page which describes all of the SELinux labels, booleans, types associated with this domain.
man named_selinux