SEAPATH and cybersecurity

Choosing and configuring the hardware

MIE

The hardware chosen to run SEAPATH must comply with https://cyber.gouv.fr/publications/recommandations-de-configuration-materielle-de-postes-clients-et-serveurs-x86
Note that all modern x86 machines are already compatible. The ANSSI has not released a similar Document for ARM machines.
Some tests exist for fallback, but many configurations must be done by the end user.

User applicable

Configuring the BIOS/UEFI

MI

The BIOS must be configured according to the document https://cyber.gouv.fr/publications/recommandations-de-configuration-materielle-de-postes-clients-et-serveurs-x86

User applicable

Activating the UEFI secure boot

MI

SEAPATH is compatible with Secure Boot and support preload keys.

User applicable

Replacing of preloaded keys

MIEH

Yocto provides secure boot functions. It is up to the end user to enable them and provide their keys.
Proper documentation should be added to the wiki. TODO

User applicable

Configuring a password on the bootloader

MI

Grub password can be configured at build time.
There is no test for that. TODO

Done

Protecting the kernel command line parameters and the initramfs

MIEH

 We have made an implementation for the Dunfell version of Yocto. This implementation does not work on the Kirkstone version and should be updated.

Not Done

Activating the IOMMU

MIE

TODO: add iommu=force in kernel parameter + add cukinia test

Not Done

Configuring the memory options

MI

SEAPATH does not implement every kernel parameters by default because it would degrade performance a lot. However, a test exists to check for any known vulnerability on the hardware that is running SEAPATH.
If a vulnerability is found, the end user must apply the related configuration manually.
This test is not launched on Yocto : TODO

Partially done

Configuring the kernel options

MI

The kernel options are present

Done

Disabling kernel modules loading

MIE

Module loading is disabled after boot

Done

Configuration option of the Yama LSM

MI

The kernel parameter security=yama is present.
The sysctl is configured to 2

Done

IPv4 configuration options

MI

IPV4 must comply to a certain list of sysctl configuration.
Some sysctl are natively enabled, but not all are tested correctly.
The rest of the sysctl must be activated by taking care of not breaking a SEAPATH feature. A reason must be explicitely given for the sysctl that cannot be activated.
TODO

Partially done

Disabling IPv6

MI

IPV6 can be disabled with one machine option in meta-seapath.
It is up to the user to choose if he needs it or not.

User applicable

File system configuration options

MI

The recommended options are present on SEAPATH.

Done

Compile options for memory management

MIEH

We have access to the kernel config.
These configs must be added and tested.

TODO

• CONFIG_DEBUG_FS=y -> n

• CONFIG_SCHED_STACK_END_CHECK=n -> y

• CONFIG_SECURITY_DMESG_RESTRICT=n -> y

Not Done

Compile options for kernel data structure

MIEH

We have access to the kernel config.
These configs must be added and tested.

TODO

• CONFIG_DEBUG_CREDENTIALS=n -> y

• CONFIG_DEBUG_NOTIFIERS=n -> y

• CONFIG_DEBUG_LIST=n -> y

• CONFIG_DEBUG_SG=n -> y

Not Done

Compile options for the memory allocator

MIEH

We have access to the kernel config.
These configs must be added and tested.
TODO

• CONFIG_SLAB_MERGE_DEFAULT=y -> n

Not Done

Compile options for the management of kernel modules

MIEH

We have access to the kernel config.
These configs must be added and tested.
TODO

Not Done

Compile options for abnormal situations

MIEH

We have access to the kernel config.
These configs must be added and tested.
TODO

• CONFIG_PANIC_ON_OOPS=n → y

• CONFIG_PANIC_TIMEOUT =0 → -1

Not Done

Compile options for kernel security functions

MIEH

The recommended configs are present.
TODO : Add test

Done

Compile options for the compiler plugins

MIEH

The recommended configs are present.
TODO : Add test

Done

Compile options of the IP stack

MIEH

The CONFIG_SYN_COOKIES option is set, but no test exists for it. TODO
The IPv6 can be disabled at build, but the kernel config is still present. This must be corrected TODO

Partially done

Compile options for various kernel behaviors

MIEH

The module disable kernel config is not present. We must verify that module loading is indeed mandatory. TODO
All other kernel configs are present, but no test exists for them. TODO

Partially done

Compile options for 32-bit architectures

MIEH

This recommendation targets 32-bit x86 machines. Currently, SEAPATH is not supported on such hardware.

Not Applicable

Compile options for x86_64 bit architectures

MIEH

We have access to the kernel config.
These configs must be added and tested.
Only CONFIG_IA32_EMULATION is enabled. Check if we have to support 32-bit binaries.
TODO

Not Done

Compile options for ARM architectures

MIEH

This recommendation targets ARM based processor. Currently, SEAPATH is not supported on such hardware.

Not Applicable

Compile options for ARM 64 bit architectures

MIEH

This recommendation targets ARM based processor. Currently, SEAPATH is not supported on such hardware.

Not Applicable

Typical partitioning

MI

Not all partitions are correctly separated.
The mount options must also be verified.

On SEAPATH Yocto the rootfs is mounted as read only, so there is some separation and mount which make no sense.

• / should be mounted with nodev because we use a devtmpfs

• /opt is empty, so no need to separate it

• /srv is empty, so no need to separate it

• /usr: due to the read-only, there is no need to separate /usr from /.

• /home is an overlay

• /var is not separate. As / root is mounted with ro option, it should be impossible to add executables or dev on it.

TODO

• noexec to /tmp

• hidepid=2 to /proc

• noexec,nosuid to /dev (not explicit in R28 but coherent with it)

• nodev,noexec,nosuid to /mnt/persistent, /var/lib/volatile, /home, /var/lib and /etc to respect /home and /var mount options

• nodev to /

Add test to check there is no executable on /var.

Mount points tests must be added.

Partially done

Access restrictions on /boot

MIE

/boot is not mounted by default, but can be with Ansible for certain tasks.
TODO : Add test
TODO mount /boot when cukinia

Partially done

Removing the unused user accounts

M

There are no unused accounts on SEAPATH

Done

User password strength

M

The passwords used on SEAPATH must follow https://www.ssi.gouv.fr/mots-de-passe/
Additional passwords added by PAM software must also follow this recommendation.
Tests exist to ensure that the root password is randomized at each boot.

For local user, rules are defined in login.defs and tested inside common_security_tests.d/hardening.conf.

TODO

Use yescrypt instead of SHA512 for password hash

User applicable

Configuring a timeout on local user sessions

MI

The timeout for bash and ssh is set to 300s

Done

Ensuring the imputability of administration actions

MI

Only sudo commands are logged.

TODO

Setup auditd as it is done on SEAPATH Debian

Not Done

Disabling the service accounts

MI

No additional accounts can be opened by a service on SEAPATH.

Done

Uniqueness and exclusivity of service accounts

MI

Some services are launched by the root user. We must create a user for these services.

Services which need to run as root:

• agetty

• dbus-daemon

• systemd (init)

• systemd-logind

• dbus-daemon

• systemd-journald

• systemd-udevd

TODO

Root services to changed are:

• ceph-crash

• snmptrapd

• libvirtd (difficult to run as a regular user)

• syslog-ng

• timemaster

• chronyd

• ptp4l

• phc2sys

• irqbalance

Not Done

Changing the default value of UMASK

MIE

UMASK is set to the desired value.

Done

Using Mandatory Access Control features

MIE

No MAC feature is implemented on SEAPATH Yocto.

Not Done

Creating a group dedicated to the use of sudo

MIE

The group "privileged" is used for sudo usage.
If PAM authentication is implemented by the end user, privileged users must also use this group.

Done

Sudo configuration guidelines

MI

All desired options are implemented and tested.

Done

Using unprivileged users as target for sudo commands

MI

Old groups and users are still present in the sudoer files.
The related tests don’t work.

Not Done

Limiting the number of commands requiring the use of the EXEC directive

MIE

Old groups and users are still present in the sudoer files.
The related tests don’t work.

Not Done

Banishing the negations in sudo policie

MI

Old groups and users are still present in the sudoer files.
The related tests don’t work.

Not Done

Defining the arguments in sudo specifications

MI

Old groups and users are still present in the sudoer files.
The related tests don’t work.

Not Done

Editing files securely with sudo

MI

No text editor must be launched with sudo privileges.
To modify the sudoers rules, the visudo command is installed on SEAPATH.
Note that sudo rules should not be changed after the initial configuration of SEAPATH

User applicable

Activating AppArmor security profiles

MIE

AppArmor is not installed on SEAPATH Yocto

Not Done

Activating SELinux with the targeted policy

MIEH

SELinux is not installed on SEAPATH Yocto

Not Done

Containing the unprivileged interactive users

MIEH

SELinux is not installed on SEAPATH Yocto

Not Done

Setting up the SELinux variables

MIEH

SELinux is not installed on SEAPATH Yocto

Not Done

Uninstalling SELinux Policy Debugging Tools

MIEH

SELinux is not installed on SEAPATH Yocto

Not Done

Limiting the rights to access sensitive files and directories

MI

All sensitive files have the proper permissions.
One test exists for all of those sensitive files

Done

Changing the secrets and access rights as soon as possible

MIE

SEAPATH is meant to be entirely functional once the installation and configuration are completed.
TODO : Is it possible to write a test for that?

Done

Securing access for named sockets and pipes

MI

Some tests exist for the open-vswitch user.
The necessary packages for a complete test are not installed (sockstat).
We must implement a mechanism to get these packages only for the test (binary, docker, systemd-sysext ?)

Partially done

Avoiding files or directories without a known user or group

M

All files and directories have a known user and group except `/var/spool/mail`.
It must be corrected and a test must be added.
TODO

Not Done

Setting the sticky bit on the writable directories

M

The sticky bit is set for all writable directories

Done

Dedicating temporary directories to users

MI

The variable TMPDIR must be set and a test must be added for that.
TODO

Not Done

Avoiding using executables with setuid and setgid rights

M

All executables that have setuid/setgid enabled are owned by root (Refer to R57)
No test exists for that. TODO

Partially done

Avoiding using executables with setuid root and setgid root rights

MIE

We have access to all package builds and configurations. Except for the sudo command, we should replace every binary that uses setuid/setgid either by a capability or by a sudo call.

Not Done

Installing only strictly necessary packages

M

All installed packages are listed when building the Yocto distribution. SEAPATH basic images comes with only the necessary packages, the end user can add some if he needs them.
We cannot write a test for that.

Done

Using only official package repositories

M

SEAPATH uses official meta recipes and thus official repositories.

Done

Using hardened package repositories

MIE

Yocto doesn’t have hardened package repositories, but we have compiled binaries with hardening options.

The hardening compiled flags are tested just after finishing the build if the SEAPATH option SEAPATH_SECCOMPILE_MANIFEST_SKIP is set to 0 (or not set) in seapath.conf.

Not Applicable

Updating regularly the system

M

SEAPATH provides an A/B update mechanism with atomic changes and automatic rollback in case of failure. Refer to the Ansible repository for more information.
https://github.com/seapath/ansible?tab=readme-ov-file#update-a-machine

User applicable

Disabling the non-necessary services

M

All installed services are listed when building the Yocto distribution. SEAPATH basic images comes with only the necessary services, the end user can add some if he needs them.
We cannot write a test for that.

Done

Disabling non-essential features of services

MI

All installed services features are listed when building the Yocto distribution. SEAPATH basic images comes with only necessary services features, the end user can add some if he needs them.
We cannot write a test for that.

Done

Configuring the privileges of the services

MIE

Currently, only libvirtd and syslog-ng are configured.

Partially done

Partitioning the services

MIE

Many services are already hardened, but not all.
A complete list of the services and their hardening must be established in order to harden the services that can be and justify why others cannot.
No tests exist.
TODO : Backport tests from Debian

Not Done

Hardening the partitioning components

MIEH

This means hardening KVM/QEMU and SystemD.
QEMU is already hardened by SystemD, but the recommendation does not give any limits or advice on its application.
Note : Deploying a VM on an isolated core drastically increases the hardening of KVM/QEMU.

Partially done

Secure remote authentication with PAM

MI

Yocto provides multiple LDAP configurations and packages. It is up to the end user to implement its authentication solution on SEAPATH

User applicable

Protecting the stored passwords

M

The password storage must follow https://www.ssi.gouv.fr/mots-de-passe/.
Tests verify that the initial and generated passwords comply.

TODO

We use sha512, but we can change to use yescrypt (not required but recommended)

Done

Securing access to remote user databases

MI

Same as R67

User applicable

Separating the system accounts and directory administrator

MI

SEAPATH do not have any directory user, it is the responsibility of the end user to implement this point.

User applicable

Implementing a logging system

MIE

SEAPATH uses journald for local logs and syslog-ng for remote logs.
These systems don’t fully comply with the recommendation.

Partially done

Implementing dedicated service activity journals

MIE

SEAPATH uses systemd that complies with this requirement.

Done

Logging the system activity with auditd

MIE

The previous version of the BP-28 proposed to disabled auditd or configure it. The choice was made to disable it.
To fulfill this requirement, we must :
- Remove old auditd tests and command line parameters.
- install and configure auditd (backport Debian configuration)
- Test that it doesn’t affect RT capabilities
- Add new cukinia tests (backport from Debian)

Not Done

Hardening the local messaging service

MI

SEAPATH doesn’t have any messaging services

Not Applicable

Configuring aliases for service accounts

MI

SEAPATH doesn’t have any messaging services

Not Applicable

Sealing and checking files integrity

MIEH

We must install intrusion monitoring tools

TODO

setup dm-verity

Not Done

Protecting the sealing database

MIEH

The sealing database is generally protected by intrusion monitoring tools.

It is built in if we use dm-verity

It can also be monitored by an external TPM

Not Done

Partitioning the network services

MIE

It is the goal of SEAPATH to isolate services on virtual machines (or containers).
However, some services remain not isolated and it will be very complicated to isolate some (eg : snmp, ceph, ssh ...)

Not Done

Hardening and monitoring the exposed services

MI

Network services are already hardened by systemD. However, this recommendation doesn’t specify a limit to the hardening.
A list of the hardening measures of systemd must be done and made available to SEAPATH integrators

Partially done

Minimizing the attack surface of network services

M

Like in R52, some packages necessary for a complete test are not installed (sockstat/ss).
We must implement a mechanism to get these packages only for the test (binary, docker, systemd-sysext ?)

Not Done

Choosing and configuring the hardware

MIE

The hardware chosen to run SEAPATH must comply with https://cyber.gouv.fr/publications/recommandations-de-configuration-materielle-de-postes-clients-et-serveurs-x86
Note that all modern x86 machines are already compatible. The ANSSI has not released a similar Document for ARM machines.

User applicable

Configuring the BIOS/UEFI

MI

The BIOS must be configured according to the document https://cyber.gouv.fr/publications/recommandations-de-configuration-materielle-de-postes-clients-et-serveurs-x86

User applicable

Activating the UEFI secure boot

MI

SEAPATH is compatible with Secure Boot and support preload keys.

User applicable

Replacing of preloaded keys

MIEH

We must replace the preload keys with ours. It implies :
- Generating a set of UEFI keys and storing them in a secure location, ideally a Hardware Security Module (HSM)
- Signing the kernel, Grub, all kernel modules and certain firmware files
- Integrate these newly signed files into build_debian_iso
- Sign all future kernel, Grub and kernel module updates
- Own APT repositories to store these new signed update files

Not Done

Configuring a password on the bootloader

MI

Grub password can be configured in ansible inventory.

Done

Protecting the kernel command line parameters and the initramfs

MIEH

Currently, neither the kernel nor the initramfs are protected by secure boot.

Not Done

Activating the IOMMU

MIE

IOMMU is currenctly activated in pass-through mode. It must be activated in force mode.
Non-regression tests must be performed to ensure that this is compatible with SEAPATH features

Not Done

Configuring the memory options

MI

SEAPATH does not activate every kernel parameters by default because it would degrade performance a lot. However a test exists to check for any known vulnerability on the hardware that is running SEAPATH.
If a vulnerability is found, the end user must apply the related configuration manually.

Done

Configuring the kernel options

MI

The kernel options are present

Done

Disabling kernel modules loading

MIE

The goal is to deactivate module loading once all desired modules are loaded.
The de-activation is simple to do, but we must think of a policy to detect that all desired modules are loaded.

Not Done

Configuration option of the Yama LSM

MI

The kernel parameter security=yama is present.
The sysctl is configured to 2

Done

IPv4 configuration options

MI

IPV4 must comply to a certain list of sysctl configuration.
Some sysctl are natively enabled, but not all are tested correctly.
The rest of the sysctl must be activated by taking care of not breaking a SEAPATH feature. A reason must be explicitely given for the sysctl that cannot be activated.

Partially done

Disabling IPv6

MI

IPV6 is not used on SEAPATH. It is disabled in the kernel parameters.

Done

File system configuration options

MI

The recommended options are present on SEAPATH.

Done

Compile options for memory management

MIEH

We have to recompile our own kernel. This implies:
- Following upstream corrections
- Managing our own UEFI keys
- Recompile and sign all Linux modules
- Manage our own APT repositories
This is a huge work to do, considering R4 already done.

Not Done

Compile options for kernel data structure

MIEH

This recommendation implies recompiling the kernel. The work is the same as R15.

Not Done

Compile options for the memory allocator

MIEH

This recommendation implies recompiling the kernel. The work is the same as R15.

Not Done

Compile options for the management of kernel modules

MIEH

This recommendation implies recompiling the kernel. The work is the same as R15.

Not Done

Compile options for abnormal situations

MIEH

This recommendation implies recompiling the kernel. The work is the same as R15.

Not Done

Compile options for kernel security functions

MIEH

The Debian kernel used by SEAPATH is already compiled with these options.
TODO : Add a test for this

Done

Compile options for the compiler plugins

MIEH

This recommendation implies recompiling the kernel. The work is the same as R15.

Not Done

Compile options of the IP stack

MIEH

This recommendation implies recompiling the kernel. The work is the same as R15.

Not Done

Compile options for various kernel behaviors

MIEH

This recommendation implies recompiling the kernel. The work is the same as R15.

Not Done

Compile options for 32 bit architectures

MIEH

This recommendation targets 32 bits x86 machines. Currently, SEAPATH is not supported on such hardware.

Not Applicable

Compile options for x86_64 bit architectures

MIEH

This recommendation implies recompiling the kernel. The work is the same as R15.

Not Done

Compile options for ARM architectures

MIEH

This recommendation targets ARM based processor. Currently, SEAPATH is not supported on such hardware.

Not Applicable

Compile options for ARM 64 bit architectures

MIEH

This recommendation targets ARM based processor. Currently, SEAPATH is not supported on such hardware.

Not Applicable

Typical partitioning

MI

Currently, only /boot and / are separated.

Not Done

Access restrictions on /boot

MIE

/boot is restricted to root, but is always mounted.
To fulfill this requirement, we must develop a mechanism that mount /boot only when needed and unmount it after that.
Note that cukinia launch tests on /boot and will need it to be mounted.

Not Done

Removing the unused user accounts

M

There are no unused accounts on SEAPATH

Done

User password strength

M

The passwords used on SEAPATH must follow https://www.ssi.gouv.fr/mots-de-passe/
The only password used on SEAPATH is define during the build of the Debian ISO.
Additionnal passwords added by PAM software must also follow this recommendation.

User applicable

Configuring a timeout on local user sessions

MI

The bash timeout is set to 300s.

Done

Ensuring the imputability of administration actions

MI

Only sudo commands are logged.

Not Done

Disabling the service accounts

MI

No additionnal accounts can be opened by a service on SEAPATH.

Done

Uniqueness and exclusivity of service accounts

MI

Some services are lauched by the root user, we must create a user for these services.

Not Done

Changing the default value of UMASK

MIE

UMASK is set to the desired value.

Done

Using Mandatory Access Control features

MIE

SEAPATH uses Apparmor, the MAC solution of Debian.

Done

Creating a group dedicated to the use of sudo

MIE

The group « privileged » is used for sudo usage.
If a PAM authentification is implemented by the end user, privileged users must also use this group.

Done

Sudo configuration guidelines

MI

All desired options are implemented and tested.

Done

Using unprivileged users as target for sudo commands

MI

No command targets root.

Done

Limiting the number of commands requiring the use of the EXEC directive

MIE

Commands allowed to run with sudo should not used the EXEC directive.
The are two exceptions currently in SEAPATH:

• Ansible user needs to spawn shells with root privilege.

• Admin user can run all commands as root

There is currently no specific policy to handle the ansible user after the initial configuration, but the end user could think about removing or deactivating the user when it is not needed.
The admin user should probably be split in many users regarding what they are supposed to do (observation only, handle VM, handle updates ...) TODO

Done

Banishing the negations in sudo policie

MI

No negation is present in the sudoer files

Done

Defining the arguments in sudo specifications

MI

When possible, all commands allowed to run with sudo must define specific arguments.
There are two exceptions currently in SEAPATH:

• Ansible user needs to access a shell with root privilege.

• Admin user can run all commands as root

The remarks are the same for R41. TODO

Done

Editing files securely with sudo

MI

No text editor must be launched with sudo privileges.
To modify the sudoers rules, the visudo command is installed on SEAPATH.
Note that sudo rules should not be changed after the initial configuration of SEAPATH

User applicable

Activating AppArmor security profiles

MIE

All AppArmor profiles are present, but no test exists for it.

Done

Activating SELinux with the targeted policy

MIEH

Debian uses AppArmor instead of SELinux

Not Applicable

Containing the unprivileged interactive users

MIEH

Debian uses AppArmor instead of SELinux

Not Applicable

Setting up the SELinux variables

MIEH

Debian uses AppArmor instead of SELinux

Not Applicable

Uninstalling SELinux Policy Debugging Tools

MIEH

Debian uses AppArmor instead of SELinux

Not Applicable

Limiting the rights to access sensitive files and directories

MI

This principle is followed natively by Debian.
TODO : Write a list of sensitive directories and test that they have the correct access rights.

Done

Changing the secrets and access rights as soon as possible

MIE

SEAPATH is meant to be entirely functional once the installation and configuration is completed.
TODO : Is it possible to write a test for that ?

Done

Securing access for named sockets and pipes

MI

SEAPATH comply with this recommendation, but the test is difficult to write.
TODO : write a test for that

Done

Avoiding files or directories without a known user or group

M

All files and directory have a known user and group

Done

Setting the sticky bit on the writable directories

M

The sticky bit is set for all writable directories

Done

Dedicating temporary directories to users

MI

All users and services have a dedicated temporary directory.

Done

Avoiding using executables with setuid and setgid rights

M

No executables added by the SEAPATH project have the setuid or setgid rights. This recommendation is not applicable to Debian native executables.

Done

Avoiding using executables with setuid root and setgid root rights

MIE

Some executables still have root setuid and setgid.

Not Done

Installing only strictly necessary packages

M

A list of necessary packages is described in the testing process. A test verifies that no additionnal packages are installed.

Done

Using only official package repositories

M

Only Debian repository are used by default.
The end user can add its own mirror during the Ansible configuration.

Done

Using hardened package repositories

MIE

Debian don't use hardened packages repositories

Not Applicable

Updating regularly the system

M

SEAPATH provides an update system. On Debian, apt updates are used.
Refer to this page for more information https://lf-energy.atlassian.net/wiki/display/SEAP/IT+tooling

User applicable

Disabling the non-necessary services

M

A list of necessary services is described in the testing process. A test verify that no additionnal services are started.

Done

Disabling non-essential features of services

MI

We must take the list of services done in R62 and limit the functionnalities of all services to the minimum required.

Not Done

Configuring the privileges of the services

MIE

A complete list of the services and their privileges must be established in order to restrict the services that can be and justify why others cannot.

Partially done

Partitioning the services

MIE

Many services are already hardened, but not all.
A complete list of the services and their hardening must be established in order to harden the services that can be and justify why others cannot.

Partially done

Hardening the partitioning components

MIEH

This means hardening docker, KVM/QEMU and SystemD.
QEMU is already hardened by SystemD, but the recommendation does not give any limits or advice on its application.
Docker is not hardened.

Not Done

Secure remote authentication with PAM

MI

The Kerberos protocol can be installed on SEAPATH during the build of the Debian ISO.
The choice and configuration of the software used to handle remote login must be made by the end user.

User applicable

Protecting the stored passwords

M

The password storage must follow https://www.ssi.gouv.fr/mots-de-passe/.
Tests verify that the initial and generated passwords complies.

Done

Securing access to remote user databases

MI

Similar to R67, this part must be configured by the end user after selecting the remote login software.

User applicable

Separating the system accounts and directory administrator

MI

The selection of the users and their rights is highly dependent of the final use case of SEAPATH.
Additionnal user can be created in ansible debian role. Their rights must be configured in the sudoers file.

User applicable

Implementing a logging system

MIE

SEAPATH uses journald for local logs and syslog-ng for remote logs.
These systems doesn’t fully comply with the recommendation.

Partially done

Implementing dedicated service activity journals

MIE

SEAPATH uses systemd that complies with this requirement.

Done

Logging the system activity with auditd

MIE

Auditd is installed and configured.

Done

Hardening the local messaging service

MI

SEAPATH doesn’t have any messaging services

Not Applicable

Configuring aliases for service accounts

MI

SEAPATH doesn’t have any messaging services

Not Applicable

Sealing and checking files integrity

MIEH

We must install intrusion monitoring tools

Not Done

Protecting the sealing database

MIEH

The sealing database is generally protected by intrusion monitoring tools.

Not Done

Partitioning the network services

MIE

It is the goal of SEAPATH to isolate services on virtual machines (or containers).
However, some services remain not isolated and it will be very complicated to isolate some (eg : snmp, ceph, ssh ...)

Not Done

Hardening and monitoring the exposed services

MI

Network services are already hardened by systemD. However, this recommendation doesn’t specify a limit to the hardening.
A list of the hardening measure of systemd must be done and made available to SEAPATH integrators

Partially done

Minimizing the attack surface of network services

M

All network sockets listen on a dedicated interface.
The only exception is conntrackd, that doesn't have such a feature and always listens on all interfaces.

Done