Tag Archives: linux


Security-Enhanced Linux (SELinux) is a security architecture integrated into the 2.6.x kernel using the Linux Security Modules (LSM).

SELinux Overview

SELinux provides a flexible Mandatory Access Control (MAC) system built into the Linux kernel. Under standard Linux Discretionary Access Control (DAC), an application or process running as a user (UID or SUID) has the user’s permissions to objects such as files, sockets, and other processes. Running a MAC kernel protects the system from malicious or flawed applications that can damage or destroy the system.

SELinux defines the access and transition rights of every user, application, process, and file on the system. SELinux then governs the interactions of these entities using a security policy that specifies how strict or lenient a given Red Hat Enterprise Linux installation should be.

On a day-to-day basis, system users will be largely unaware of SELinux. Only system administrators need to consider how strict a policy to implement for their server environment. The policy can be as strict or as lenient as needed and is very finely detailed. This detail gives the SELinux kernel complete, granular control over the entire system.

The SELinux Decision Making Process

When a subject, (for example, an application), attempts to access an object (for example, a file), the policy enforcement server in the kernel checks an access vector cache (AVC), where subject and object permissions are cached. If a decision cannot be made based on data in the AVC, the request continues to the security server, which looks up the security context of the application and the file in a matrix. Permission is then granted or denied, with an avc: denied message detailed in /var/log/messages if permission is denied. The security context of subjects and objects is applied from the installed policy, which also provides the information to populate the security server’s matrix.

SELinux Decision Process

SELinux Operating Modes

Instead of running in enforcing mode, SELinux can run in permissive mode, where the AVC is checked and denials are logged, but SELinux does not enforce the policy. This can be useful for troubleshooting and for developing or fine-tuning SELinux policy.

The /selinux/ pseudo-file system contains commands that are most commonly used by the kernel subsystem. This type of file system is similar to the /proc/ pseudo-file system. Administrators and users do not normally need to manipulate this component.

There are two ways to configure SELinux under Red Hat Enterprise Linux: using the SELinux Administration Tool (system-config-selinux), or manually editing the
 primary configuration file (/etc/sysconfig/selinux).

The /etc/sysconfig/selinux contains a symbolic link to the actual configuration file, /etc/selinux/config.

SELinux Configuration

SELINUX=enforcing|permissive|disabled — Defines the top-level state of SELinux on a system.

  • enforcing — The SELinux security policy is enforced.
  • permissive — The SELinux system prints warnings but does not enforce policy.This is useful for debugging and troubleshooting purposes. In permissive mode, more denials are logged because subjects can continue with actions that would otherwise be denied in enforcing mode. For example, traversing a directory tree in permissive mode produces avc: denied messages for every directory level read. In enforcing mode, SELinux would have stopped the initial traversal and kept further denial messages from occurring.
  • disabled — SELinux is fully disabled. SELinux hooks are disengaged from the kernel and the pseudo-file system is unregistered.

SELINUXTYPE=targeted|strict — Specifies which policy SELinux should enforce.

  • targeted — Only targeted network daemons are protected.
  • strict — Full SELinux protection, for all daemons. Security contexts are defined for all subjects and objects, and every action is processed by the policy enforcement server.
'Coz sharing is caring

How to Test Sendmail From Command Line on Linux

What Is Sendmail?

sendmail is a very plain and simple MTA (Mail Transfer Agent), which implements the SMTP (Simple Mail Transfer Protocol) amongst others and can be used to transmit emails, typically on Linux. While there is a commercial version available which is called “Sendmail”, the sendmail we’re covering in this how-to article is the UNIX-based version of it, which comes with pretty much every Linux distribution as well as *BSD (FreeBSD, OpenBSD, and variants). Using the sendmail command might be the easiest way to send e-mails via Linux shell CLI (Command Line Interface), apart from mailx, which can be used in conjunction with sendmail to make it even easier to send and receive emails from the command line. Like the name already suggests, sendmail itself can only send emails and not store received ones in POP or IMAP mailboxes.

Where Is Sendmail And Its Configuration Files Located?

The first interesting information that we might need for testing sendmail is the path of the binary file that gets executed if we issue the command sendmail on our command line. To figure that out, we’ll use the which command as shown below:

[root@box ~]# which sendmail

The above output means that the full path to our sendmail command’s binary file is /usr/sbin/sendmail which you should note for the steps further below.

If you want to adjust the configuration files of sendmail, you can usually find them in the directory /etc/mail/on UNIX (FreeBSD, OpenBSD) and Linux (CentOS, Fedora, Debian, Ubuntu) systems. The main configuration file of sendmail is /etc/mail/sendmail.cf, however adjusting that is not part of this tutorial. A good place for more information is the manual page of sendmail, that you can view by running the command man sendmail. Now to the interesting part of this sendmail command line tutorial.

How to Test the Sendmail Command On Linux

To quickly test if the sendmail command is working correctly to then use it for example in shell scripts, via command line or even from PHP scripts (PHP supports sendmail to send emails from PHP scripts – you can set the sendmail path in your php.ini), you can issue the below command on your UNIX or Linux system:

echo "Subject: sendmail test" | sendmail -v my@email.com

my@email.com is obviously the e-mail address you want the test email to be sent to. This sendmail command line example will send a blank email with the subject “sendmail test” to my@email.com if the test is successful. You can also send longer e-mails containing a subject, body and additional headers if you want to, but just to test if sendmail works that’s usually not required. Still, here is how you can do that:

1.) Create a file called mail.txt (or anything you like) in ~/mail.txt with vim or nano or your preferred text editor

2.) Paste the following content to it, but of course adjusting the email addresses, as those are just sendmail command examples:

To: my@email.com
Subject: sendmail test two
From: me@myserver.com
And here goes the e-mail body, test test test..

3.) At last we send the e-mail template we just created with: sendmail -vt < ~/mail.txt

That’s it – you can now test sendmail from the command line and even send full e-mails including headers from Linux/UNIX shell. Below is an example of how the simple sendmail test could look like on a live system:

sendmail test

Sendmail And Spam

One thing I’d like to add is that due to the fact that PHP and other scripts can usually access the sendmail binaries, it can also be used to send out spam and phishing mails and that’s what can happen on shared servers where accounts were compromised through an outdated CMS or weak passwords. If you want to find out which script or POSIX user is sending the spam with sendmail, you can issue the below command and pay close attention to the output:

ps faux | grep sendmail

Sendmail Conclusion

While sendmail can pose a few risks on shared or insecure systems, it is a great lightweight MTA that can be used to send e-mails from shell scripts, PHP applications or even directly the command line. It also automatically negotiates STARTTLS for encrypted transmission of the emails if the remote SMTP server supports it, which is a useful security practice.

'Coz sharing is caring