DEV Community: Rodrigo Vieira

SELinux and AppArmor

Rodrigo Vieira — Fri, 19 Apr 2019 15:48:29 +0000

They both are security related technologies classified as MAC - Mandatory Access Control. SELinux was created by NSA - National Security Agency, while AppArmor become popular after it has adopted by Ubuntu Linux.

The main idea here is to create mechanisms to extend the basic permission schema based on ugo/rwx. Among other things, they offer the ability to restrict access by system process to files, directories, network ports, etc.

AppArmor offers an autolearn mode, which is capable to know how a system should operate, while SELinux brings an enforcing mode by default since CentOS 6.

SELinux

SELinux stands for Security Enhanced Linux and it can operate in two modes:

enforcing: SELinux will deny access based on its policy rules, a set of guidelines that control its engine.
permissive: SELinux won't deny access, but denials will be logged for actions that would have been denied if running in enforcing mode.

You have the choice to completely disable SELinux, however, it is not recommended these days! It's better to learn how to take advantage of this excellent tool.

You can verify the current operation mode of SELInux using getenforce command, and you can change it by setenforce 0 - permissive mode - or setenforce 1 - enforcing mode. To persist this change across reboots you need to set the SELINUX variable in the /etc/selinux/config file.

To set SELINUX from or to disabled mode you will have to edit the above file and reboot your system.

As a common use case lets see how to change the SSH daemon port from 22 to 2222:

Make sure you have the policycoreutils-python package installed:

  yum install -y policycoreutils-python

Tell SELinux that port 2222 is allowed to be used by ssh process:

  # check all ports managed by SELinux
  selinux port -l

  # Customize ssh to run on port 2222/tcp
  semanage port -a -t ssh_port_t -p tcp 2222

  # check all customized ports managed by SELinux
  semanage -lC

Another common scenario is to change the default allowed DocumentRoot folder to be used by a web server. Lets add the /srv/www to the list of the allowed directories:

semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?"

The above command will grant apache read-only access to that directory and its contents.

Finally, to apply the pilicy, making the label change effective immediately):

restorecon -R -v /srv/www

If things are still not working as expected you can look for AVC string in /var/log/audit/audit.log file.

You can get more help at SELinux Official Documentation.

AppArmor

AppArmor uses profiles defined in text files instead of policy managed by commands. There are several of them provided out of the box. These profiles are available at /etc/apparmod.d.

You can check the AppArmor current status by running:

apparmor_status

To switch a profile between complain and enforce modes, like smbd profile, we can run:

aa-complain /etc/apparmor.d/usr.sbin.smbd
aa-enforce  /etc/apparmor.d/usr.sbin.smbd

The above commands also accept bash wildcards to change multiple profiles at once.

To entirely disable a profile, we just have to create a link to its file at /etc/apparmor.d/disable/ directory, like so:

sudo ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/

You can get more information for AppArmor in Ubuntu AppArmor Community Documentation.

Access Control List - ACL

Rodrigo Vieira — Fri, 19 Apr 2019 15:45:26 +0000

To improve the well known Linux permission schema ugo/rwx, allowing us to set distinct permission for different individual users or groups we can leverage the Access Control List - ACL.

Requirements

The filesystem where the files you want to set ACL are stored must be mounted with ACL support. You can check that by running:

mount /dev/xvda1 | grep attr
/dev/xvda1 on / type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

We can see the attr2 which indicates that this filesystem supports extended attributes - ACLs. If you don't see that option for your filesystem or if you see the noacl, you can fix it in /etc/fstab adding or removing the appropriated options, and remounting the filesystem:

mount /dev/xvda1 -o remount

You can't remount the root / filesystem. You have to reboot your machine to get new options enabled.

Using ACLs

Imagine that we have these two groups and 5 users:

devs: euler, colleen, eric
ops: rodrigo, jonas

And we have a project folder that devs have full acess to it:

groupadd dev
groupadd ops
useradd euler
useradd colleen
useradd rodrigo
useradd jonas
usermod -aG devs euler
usermod -aG devs colleen
usermod -aG devs eric
usermod -aG ops rodrigo
usermod -aG ops jonas

mkdir /var/projectX
touch /var/projectX/main.py

chown -R euler.devs /var/projectX
chmod -R 770  /var/projectX

But what if we want to grant write access to a user that is not in devs group?
We could create a new group that includes all necessary users, but it would get messy fast.

With ACLs we can grant individual users access to files and directories. Hence, to add write permission for jonas to main.py file:

setfacl -m u:jonas:rw /var/projectX/main.py
setfacl -m u:jonas:rx /var/projectX

Ok, jonas now has access to read and to enter in /var/projectX folder and also to write to main.py.

We can check for ACLs on a file by running getfacl command:


getfacl /var/projectX/main.py

getfacl: Removing leading '/' from absolute path names
# file: var/projectX/main.py
# owner: euler
# group: dev
user::rwx
user:jonas:rw-
group::rwx
mask::rwx
other::---

We can remove the above ACLs replacing -m for -x, or using -b to remove all ACLs from a file or directory:

setfacl -b /var/projectX

I hope you've learned a litte bit about Linux ACLs, you can learn more at Setting Access ACLs.

Why Encapsulate

Rodrigo Vieira — Fri, 19 Apr 2019 15:27:07 +0000

I'm pretty sure you can find enough material about encapsulation in the context of Object Oriented programming paradigm on the Internet. Thus, my approach here is to expose a simple PHP snippet for those are not used to encapsulation yet.

Let's say you have a wallet object and you want to impose some restrictions on its public interface. I mean, you want to guide how client code should use your wallet object.

Among other attributes and methods, let's keep our object as simple as we can and stay focused on encapsulation. For this reason, let's start with a $balance and a $limit attributes, besides two public methods, withdraw() and deposit(), and a private one, the setLimit() method.

class Wallet
{
    /**
     * Balance of the wallet
     *
     * @var float
     */
    private $balance;

    /**
     * Availabe limit for the wallet
     *
     * @var float
     */
    private $limit;

    /**
     * Creates a Wallet with a initial balance and a certain limit.
     * @param  float  $balance
     * @param  float  $limit
     */
    public function __construct(float $balance, float $limit = 0)
    {
        $this->limit = $this->setLimit($limit);

        if ($balance + $this->limit < 0) {
            throw new Exception("Can't create a wallet with balance under limit.");
        }

        $this->balance = $balance;
    }

    private function setLimit(float $limit)
    {
        return $this->limit = abs($limit);
    }

    /**
     * Increase balance
     * @param  float  $amount
     * @return float
     */
    public function deposit(float $amount)
    {
        return $this->balance += $amount;
    }

    /**
     * Decrease balance
     * @param  float $amount
     * @return float
     */
    public function withdraw(float $amount)
    {
        $amount = abs($amount);

        if ($this->balance + $this->limit - $amount < 0) {
            throw new Exception("Insuficient funds.");
        }

        return $this->balance -= $amount;
    }

    /**
     * A string representation for the wallet's balance
     * @return string
     */
    public function __toString()
    {
        return sprintf("Balance: $ %.2f", $this->balance);
    }
}

First, we don't want to allow client code to create Wallets with no balance, or with a balance under a certain limit. Thus we've defined this initial rules in the constructor method.

Next, we can't let the client code manipulate the balance of a wallet directly. This change must occur through one of the assessor methods, 'deposit()' or 'withdraw()'. For this reason, we've defined the $balance property as private.

We also want to ensure that the balance of a portfolio does not fall below the limit set in the builder. We can define this business rule in the withdraw() method.

Using the Wallet class

With our Wallet class defined, we can easily create a new wallet, specifying its initial balance and limit:

$my_wallet = new Wallet(200, 100);

Changes on $balance property are limited through deposit() and withdraw() methods:

$my_wallet->deposit(1450.25);
$my_wallet->withdraw(500.50);

We are able to see a nice string representation of a Wallet object just printing it, thanks to the __toString() magic method:

print($my_wallet);

Lastly, we are verifying for a limit violation when withdrawing or when creating a new Wallet object:

# Will throw an Exception: "Insuficient funds"
$my_wallet->withdraw(2000.00);

# Will throw an Exception: Can't create a wallet with balance under limit.
$other_wallet = new Wallet(-225.15, 150);

The main goal of encapsulation is to protect entire object data from being accessible to its clients. Our business rule about the limit is hidden from client code. We have blundled the data with the methods that operate on that data.

Interfaces and Abstract Classes

Rodrigo Vieira — Fri, 19 Apr 2019 15:20:10 +0000

For most people I've talked on my journey through software development, abstraction always brings the idea of code reuse. You might think about company and person objects, both have names, addresses, phone contacts, and so on. They both share common attributes and maybe even common behavior. You can define an abstract base class named Entity and then create two concrete classes, Person and Company, extended from Entity.

Let's take a step back, imagine basic PHP types, boolean, integer, float, objects and all the ways you are able to work with them. Everyone knows or at least should know, the expected behavior of those types. I mean, if you create an integer variable, you know what kind of value to expect and what kind of operations you can perform with it.

Every type has its own stable behavior.

A programming language cares itself about the unchangeable behavior of its essential types. The same idea applies when we are defining abstract classes and their concrete implementations.

Abstract Classes

When extending from other classes, we are creating new data types. The code snippets below define a new child class ArrayCache, which is a AbstractCache class. Thus, the child class is a specification that will inherit all of the parent's non-private properties and methods. The client code still expects them to behave exactly as their parent does:

abstract class AbstractCache
{
    abstract public function get(string $key)
    { }

    abstract public function set(string $key, $value)
    { }
}

class ArrayCache extends AbstractCache
{
    protected $items;

    public function get(string $key)
    {
        return $this->item[$key];
    }

    public function set(string $key, $value)
    {
        $this->item[$key] = $value;
    }
}

According to Liskov Substitution Principle, we can use these sub-types, without any special knowledge, only by reading the parent class public interface.

All concrete implementations from the same abstract base class should obey the abstract class interfaces. When using inheritance, it is our responsibility to respect the parent class interface. When working with inheritance, try to keep the hierarchy short, no more than three levels. Also, remember that if there is some code in the parent class that you are using from the client one as parent::method(), you must care about the returned values as well.

When we provide public methods we are saying: "With this data type you can do this and it will behave in this particular way."

You can think of abstraction as taking out unnecessary details to describe something in simpler terms in order to focus only on important aspects of the current context. Encapsulation plays the main role here, as a technique used to hide some state and behavior from the outside world. Client code can interact with it through its methods, but cannot access its state directly.

In other words:

A public interface is a set of rules, that defines the way in which we can interact with an object.

Interfaces

When you are trying to enforce the same behavior for different types, you may want to take advantage of Interfaces.

An interface in PHP can contain methods and constants, but can't contain any variables. All methods must be public and have no implementation. Also, an interface can be inherited from another by extends keyword. Even though classes can inherit from multiple interfaces, that can't implement two interfaces that share the same method names, it would cause ambiguity.

Hence, we usually use abstraction for code reuse when defining a hierarchy of data types. As for interfaces, its common use is to enforce certain behavior.

For instance, we want to make sure that those two types, Company and Person can be cached by providing its own key and its own value:

interface Cacheable
{
    public function getCacheKey();
    public function getCacheValue();
}

We have to create the Company class and the methods imposed by Cacheable interface:

class Company extends Entity implements Cacheable
{
    public function getCacheKey()
    {
        return 'company_' . $this->id;
    }

    public function getCacheValue()
    {
       return [
           'name' => $this->name,
           'phone' => $this->phone,
           'address' => $this->address,
           'foundation_date' => $this->foundation_date
       ];
    }
}

The same for Person class:

class Person extends Entity implements Cacheable
{
    public function getCacheKey()
    {
        return 'person_' . $this->id;
    }

    public function getCacheValue()
    {
       return [
           'name' => $this->name,
           'phone' => $this->phone,
           'address' => $this->address,
           'birth_date' => $this->birth_date
       ];
    }
}

With this inverted approach, all caching logic is encapsulated in a cacheable class. Every class must define its own rules, how it should be stored in the cache. The Cache class knows nothing about these details, it trusts Cacheable objects and calls their getCacheKey and getCacheData methods.

This blind trust is the main idea of using interfaces. We are establishing a contract that must be honored by both sides.

We can now redefine our ArrayCache like these:

class AbstractCache extends AbstractCache
{
    protected $items;

    abstract public function get(Cacheable $entity)
    {
        $key = $entity->getCacheKey();
        return $this->item[$key];
    }

    abstract public function set(Cacheable $entity, $value)
    {
        $key = $entity->getCacheKey();
        $data = $entity->getCacheValue();

        $this->item[$key] = $value;
    }
}

Keep in mind that interfaces don't define a new type, they describe an aspect of a type.