A word about sealert

The sealert command can be run both as a CLI or GUI program.  However, when you want to run it from the CLI, it is necessary to specify the path using the -a switch.

For example, here is the result if you run sealert from a TTY:

# sealert
could not attach to desktop process

On the other hand, if you specify the file to scan:

# sealert -a /var/log/audit/audit.log

You will get the expected result.  If any failures were in the logs, they will show up with an analysis, similar to:

--------------------------------------------------------------------------------

SELinux is preventing /opt/brother/Printers/mfcj485dw/cupswrapper/brcupsconfpt1 from execute access on the file /etc/ld.so.cache.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that brcupsconfpt1 should be allowed execute access on the ld.so.cache file 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:
# ausearch -c 'brcupsconfpt1' --raw | audit2allow -M my-brcupsconfpt1
# semodule -i my-brcupsconfpt1.pp


Additional Information:
Source Context                system_u:system_r:cupsd_t:s0-s0:c0.c1023
Target Context                unconfined_u:object_r:ld_so_cache_t:s0
Target Objects                /etc/ld.so.cache [ file ]
Source                        brcupsconfpt1
Source Path                   /opt/brother/Printers/mfcj485dw/cupswrapper/brcups
                              confpt1
Port                         
Host                         
Source RPM Packages           mfcj485dwlpr-1.0.0-0.i386
Target RPM Packages           glibc-2.17-157.el7_3.5.x86_64
                              glibc-2.17-157.el7_3.5.i686
Policy RPM                    selinux-policy-3.13.1-102.el7_3.16.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     SOMENAME
Platform                      Linux SOMENAME 3.10.0-514.26.2.el7.x86_64 #1 SMP
                              Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64
Alert Count                   20
First Seen                    2017-08-21 18:04:39 EDT
Last Seen                     2017-08-21 18:04:42 EDT
Local ID                      9851dcdd-6b59-4310-8e26-573219f32e7e

Raw Audit Messages
type=AVC msg=audit(1503353082.145:499): avc:  denied  { execute } for  pid=14664 comm="brmfcj485dwfilt" path="/etc/ld.so.cache" dev="dm-0" ino=146770715 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:ld_so_cache_t:s0 tclass=file


type=SYSCALL msg=audit(1503353082.145:499): arch=i386 syscall=lgetxattr per=400000 success=no exit=EACCES a0=0 a1=22671 a2=1 a3=2 items=0 ppid=14608 pid=14664 auid=4294967295 uid=4 gid=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) ses=4294967295 comm=brmfcj485dwfilt exe=/opt/brother/Printers/mfcj485dw/lpd/brmfcj485dwfilter subj=system_u:system_r:cupsd_t:s0-s0:c0.c1023 key=(null)

Hash: brcupsconfpt1,cupsd_t,ld_so_cache_t,file,execute

--------------------------------------------------------------------------------

Enabling the talk daemon on Fedora 20

well, it's been a few years and as technology changes, so does the methods used to configure a system.

I still use the talk program on a regular basis.  Here are the instructions for enabling it:

# yum install xinetd talk-server talk

# systemctl enable xinetd.service
# systemctl enable ntalk.service

At this poing, simply starting the xinetd and ntalk services does not seem to allow the talk program to function.  At the moment, the only solution I had was to reboot the system.  If someone has a better way, I would very much like to know.

# reboot

Talk should now work.  However, there is a chance that SELinux will deny it.  Check your logs:

# grep -i denied /var/log/audit/audit.log

If you do get a denial you will need to build a new policy.  Make sure you have the following utility installed: checkpolicy

# yum install checkpolicy

# grep in.ntalkd /var/log/audit/audit.log | audit2allow -M mypol

# semodule -i mypol.pp

That's it.

IBM DB2 connector - executable stack error

I ran into this issue following the installation of a new IBM DB2 connector library for use with PHP on an Apache server.

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/ibm_db2.so' - libdb2.so.1: cannot enable executable stack as shared object requires: Permission denied in Unknown on line 0

As it turns out, Dan Walsh already wrote up something about this on his blog in 2011:

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

Following his instructions, I've opted to clear the executable stack flag.  I've modified his one liner command to execute the 'clear' command on all the files found.  It would be tedious to change them one by one.

find /opt/ibm/db2/V9.7/lib64 -exec execstack -q {} \; -print 2> /dev/null | grep ^X | cut --delimiter=' ' -f2 | xargs -n 1 execstack -c

This fixed the problem.

Build an SELinux policy from an audit log

Often certain commands in linux will simply fail without any messages in /var/log/messages, or seemingly anywhere else... where we usually check. However, if you look at the selinux audit logs, sometimes the error messages are there. /var/log/audit/audit.log.

For example, every once in a while after a kernel update, I can't use the talk program. It simply says the connection is being refused by the other use. Since I already know Selinux is the culprit I grep the logs:

grep -i talkd /var/log/audit/audit.log

The result:

type=AVC msg=audit(1329155365.865:143): avc: denied { open } for pid=5631 comm="in.ntalkd" name="1" dev=devpts ino=4 scontext=system_u:system_r:ktalkd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file

type=SYSCALL msg=audit(1329155365.865:143): arch=c000003e syscall=2 success=no exit=-13 a0=7fffc83c0eb8 a1=101 a2=7fffc83c0ec3 a3=7fffc83c0690 items=0 ppid=5630 pid=5631 auid=4294967295 uid=99 gid=5 euid=99 suid=99 fsuid=99 egid=5 sgid=5 fsgid=5 tty=(none) ses=4294967295 comm="in.ntalkd" exe="/usr/sbin/in.ntalkd" subj=system_u:system_r:ktalkd_t:s0-s0:c0.c1023 key=(null)

Two entries showing that talk is denied. If you really want to authorize this process grep the tail end of the file and use audit2allow to generate a policy file that will allow this.

tail /var/log/audit/audit.log | grep '1329155365.865:143' | audit2allow -M talkpolicy

audit2allow generates a talkpolicy.pp file and will also give you instructions on how to activate it. That would be:

semodule -i talkpolicy.pp

This will take a minute or two and has effectively authorized the blocked program to run.

SeLinux HowTo: Change Context, Set SELinux booleans, Set permissive, enforced

Here is a very short 'Quick Reference' guide to manipulating some settings things with SELinux.

---

CHANGING SELINUX BOOLEANS

getsebool : Get's the values for various SELinux booleans.

Try:

1	# getsebool -a | grep httpd_can_network_connect

This should return the status of that particular variable, for example:

httpd_can_network_connect --> off
httpd_can_network_connect_db --> off
httpd_can_network_relay --> off

Of course you can specify the boolean directly without using grep if you know it's name:

1	# getsebool httpd_can_network_connect_db

setsebool Use this command to change the value of a SELinux boolean variable.  Example, the following will allow the httpd process to connect to a remote database server.

1	# setsebool -P httpd_can_network_connect_db on

The -P option stands for "persistent," meaning the changes will persist after a reboot.

---

ENABLING OR DISABLING SELINUX

getenforce : will return the current status for SELinux

setenforce : will temporarily enable/disable SELinux

In Fedora/Redhat modify the /etc/selinux/config file to make the changes to the enforcement policy permanent.

---

MODIFYING SELINUX CONTEXTS TEMPORARILY

It's easy to manipulate SELinux contexts with the chcon command.  For example if a process running as a particular user is not able to modify a file, check the context of that file by issuing the following command:

1

# ls -laZ

The Z option shows the SELinux context information for the files listed by the ls command.
For example, on Fedora / RedHat you might see the following contexts for the /var/log/httpd folder:

1	# ls -laZ /var/log/httpd

drwxr-xr-x  root root user_u:object_r:var_log_t  .
...
...

I created a new httpd log folder to increase the disk space available for logging; the SELinux context was by default set to:

drwxr-xr-x  root root system_u:object_r:file_t

Therefore the httpd process was unable to write new log files in this folder.  The context type was not set correctly to allow changes.  Changing the context type required issuing the following command to ensure it matched the old httpd directories' settings.

1	chcon -c -u user_u -t var_log_t /var/log/httpd

UPDATE (2017-08-23) (The -c option has been removed and is no longer required: http://lists.gnu.org/archive/html/bug-coreutils/2008-10/msg00076.html)

This will relabel the file and the process will now be able to access it directly as needed.

NOTE:  This is a temporary measure and only labels the file until the next reboot.  Read on for a permanent solution.

---

MODIFYING SELINUX CONTEXTS PERMANENTLY

To make persistant modifications to SELinux contexts you must add an entry to the SELinux file context database: /etc/selinux/targeted/contexts/files/file_contexts.local.  The semanage command will do just that.  The next step is to apply the change by running the restorecon command against the file to be modified.

First, add a new record for the file /var/log/httpd with the command:

1	# semanage fcontext -a -s user_u -t var_log_t /var/log/httpd

-a adds the file to /etc/selinux/targeted/contexts/files/file_contexts.local
-s specifies the SELinux user
-t specifies the SELinux type

This change has not yet been applied to the file and will only occur during the next reboot when the filesystem is relabeled.  However to execute the change now use the restorecon command:

1	# restorecon -v /var/log/httpd