SEAPATH follows the applicable cybersecurity guidelines defined by the ANSSI in the ANSSI-BP-028028v2.0 document. Several mechanisms have been taken into account in order considered to guarantee system’s the system security:
- System hardening
- Disk encryption
- Secrets storage and protection
- Process isolation
- Privileges management policy
- Connection encryption
- User authentication process
Yocto Project
The Yocto version of SEAPATH follows an earlier version of the ANSSI-BP-028 document: ANSSI-BP-028 v1.2.
The compatibility matrix can be found after the build in build/security/traceability-matrix_seapath-guest-efi-image_ANSSINT28.adoc.
TODO: Write an explanation on the current state of each requirements on Yocto. This should be automatically done when merging the cukinia test of Yocto and Debian.
Debian
The Debian version of SEAPATH follows the version 2 of the document : ANSSI-BP-028 v2
Below are two detailed lists of all recommendations, their current state on SEAPATH Yocto and Debian and a small explanation of the work done or to be done.
- Done: SEAPATH complies with this requirement. Tests are run with cukinia to ensure that future development don't break this compliance. (Some recommendations are done, but no tests exist for them. When it is so, it is explicitly written in the table below.)
- Not Done: SEAPATH doesn't comply with this requirement. A small description of the work to do is given.
- Not applicable: This requirement has no sense to be applied on SEAPATH.
- User applicable: This requirement cannot be fulfilled by SEAPATH and must be ensured by the end user/SEAPATH integrator.
- Partially done: This requirement is not done in SEAPATH. Either only specific parts of the requirement are done and tested, or the requirement is not properly tested for now.
Yocto Project
A compliance A compliance matrix listing all the tests done on SEAPATH and their relation to the requirements recommendations is available at the end of each test report on the CI. You can find weekly test reports here: https://github.com/seapath/ci/tree/reports-PRmain/docs/reports/PR-main
Below is a detailed list of all requirements, their current state on SEAPATH and a small explanation on the work done or to be done.
...
| Subject | Level | Explanations | State | |
| R1 | 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 |
| R2 | 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 |
| R3 | Activating the UEFI secure boot | MI | SEAPATH is compatible with Secure Boot and support preload keys. | User applicable |
| R4 | 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 |
| R5 | Configuring a password on the bootloader | MI | Grub password can be configured at build time. There is no test for that. TODO | Done |
| R6 | 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 |
| R7 | Activating the IOMMU | MIE | TODO: add iommu=force in kernel parameter + add cukinia test | Not Done |
| R8 | 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 |
| R9 | Configuring the kernel options | MI | The kernel options are present | Done |
| R10 | Disabling kernel modules loading | MIE | Module loading is disabled after boot | Done |
| R11 | Configuration option of the Yama LSM | MI | The kernel parameter security=yama is present. The sysctl is configured to 2 | Done |
| R12 | 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 |
| R13 | 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 |
| R14 | File system configuration options | MI | The recommended options are present on SEAPATH. | Done |
| R15 | Compile options for memory management | MIEH | We have access to the kernel config. TODO
| Not Done |
| R16 | Compile options for kernel data structure | MIEH | We have access to the kernel config.
| Not Done |
| R17 | Compile options for the memory allocator | MIEH | We have access to the kernel config.
| Not Done |
| R18 | 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 |
| R19 | Compile options for abnormal situations | MIEH | We have access to the kernel config.
| Not Done |
| R20 | Compile options for kernel security functions | MIEH | The recommended configs are present. TODO : Add test | Done |
| R21 | Compile options for the compiler plugins | MIEH | The recommended configs are present. TODO : Add test | Done |
| R22 | 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 |
| R23 | 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 |
| R24 | Compile options for 32-bit architectures | MIEH | This recommendation targets 32-bit x86 machines. Currently, SEAPATH is not supported on such hardware. | Not Applicable |
| R25 | 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 |
| R26 | Compile options for ARM architectures | MIEH | This recommendation targets ARM based processor. Currently, SEAPATH is not supported on such hardware. | Not Applicable |
| R27 | Compile options for ARM 64 bit architectures | MIEH | This recommendation targets ARM based processor. Currently, SEAPATH is not supported on such hardware. | Not Applicable |
| R28 | Typical partitioning | MI | Not all partitions are correctly separated. On SEAPATH Yocto the rootfs is mounted as read only, so there is some separation and mount which make no sense.
TODO
Add test to check there is no executable on /var. Mount points tests must be added. | Partially done |
| R29 | 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 |
| R30 | Removing the unused user accounts | M | There are no unused accounts on SEAPATH | Done |
| R31 | User password strength | M | The passwords used on SEAPATH must follow https://www.ssi.gouv.fr/mots-de-passe/ 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 |
| R32 | Configuring a timeout on local user sessions | MI | The timeout for bash and ssh is set to 300s | Done |
| R33 | Ensuring the imputability of administration actions | MI | Only sudo commands are logged. TODO Setup auditd as it is done on SEAPATH Debian | Not Done |
| R34 | Disabling the service accounts | MI | No additional accounts can be opened by a service on SEAPATH. | Done |
| R35 | 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:
TODO Root services to changed are:
| Not Done |
| R36 | Changing the default value of UMASK | MIE | UMASK is set to the desired value. | Done |
| R37 | Using Mandatory Access Control features | MIE | No MAC feature is implemented on SEAPATH Yocto. | Not Done |
| R38 | 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 |
| R39 | Sudo configuration guidelines | MI | All desired options are implemented and tested. | Done |
| R40 | 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 |
| R41 | 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 |
| R42 | 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 |
| R43 | 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 |
| R44 | 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 |
| R45 | Activating AppArmor security profiles | MIE | AppArmor is not installed on SEAPATH Yocto | Not Done |
| R46 | Activating SELinux with the targeted policy | MIEH | SELinux is not installed on SEAPATH Yocto | Not Done |
| R47 | Containing the unprivileged interactive users | MIEH | SELinux is not installed on SEAPATH Yocto | Not Done |
| R48 | Setting up the SELinux variables | MIEH | SELinux is not installed on SEAPATH Yocto | Not Done |
| R49 | Uninstalling SELinux Policy Debugging Tools | MIEH | SELinux is not installed on SEAPATH Yocto | Not Done |
| R50 | 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 |
| R51 | 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 |
| R52 | 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 |
| R53 | 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 |
| R54 | Setting the sticky bit on the writable directories | M | The sticky bit is set for all writable directories | Done |
| R55 | Dedicating temporary directories to users | MI | The variable TMPDIR must be set and a test must be added for that. TODO | Not Done |
| R56 | 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 |
| R57 | 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 |
| R58 | 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 |
| R59 | Using only official package repositories | M | SEAPATH uses official meta recipes and thus official repositories. | Done |
| R60 | 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 |
| R61 | 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 |
| R62 | 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 |
| R63 | 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 |
| R64 | Configuring the privileges of the services | MIE | Currently, only libvirtd and syslog-ng are configured. | Partially done |
| R65 | Partitioning the services | MIE | Many services are already hardened, but not all. | Not Done |
| R66 | Hardening the partitioning components | MIEH | This means hardening KVM/QEMU and SystemD. | Partially done |
| R67 | 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 |
| R68 | Protecting the stored passwords | M | The password storage must follow https://www.ssi.gouv.fr/mots-de-passe/. TODO We use sha512, but we can change to use yescrypt (not required but recommended) | Done |
| R69 | Securing access to remote user databases | MI | Same as R67 | User applicable |
| R70 | 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 |
| R71 | 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 |
| R72 | Implementing dedicated service activity journals | MIE | SEAPATH uses systemd that complies with this requirement. | Done |
| R73 | 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 |
| R74 | Hardening the local messaging service | MI | SEAPATH doesn’t have any messaging services | Not Applicable |
| R75 | Configuring aliases for service accounts | MI | SEAPATH doesn’t have any messaging services | Not Applicable |
| R76 | Sealing and checking files integrity | MIEH | We must install intrusion monitoring tools TODO setup dm-verity | Not Done |
| R77 | 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 |
| R78 | Partitioning the network services | MIE | It is the goal of SEAPATH to isolate services on virtual machines (or containers). | Not Done |
| R79 | 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 |
| R80 | 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 |
Debian
...
A compliance matrix listing all the tests done on SEAPATH and their relation to the recommendations is available at the end of each test report on the CI. You can find weekly test reports here: https://github.com/seapath/ci/tree/reports-PRdebian-main/docs/reports/PR-debian-main
| Subject | Level | Explanations | State | |
| R1 | 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 |
| R2 | 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 |
| R3 | Activating the UEFI secure boot | MI | SEAPATH is compatible with Secure Boot and support preload keys. | User applicable |
| R4 | 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 |
| R5 | Configuring a password on the bootloader | MI | Grub password can be configured in ansible inventory. | Done |
| R6 | Protecting the kernel command line parameters and the initramfs | MIEH | Currently, neither the kernel nor the initramfs are protected by secure boot. | Not Done |
| R7 | 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 |
| R8 | 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 |
| R9 | Configuring the kernel options | MI | The kernel options are present | Done |
| R10 | 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 |
| R11 | Configuration option of the Yama LSM | MI | The kernel parameter security=yama is present. The sysctl is configured to 2 | Done |
| R12 | 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 |
| R13 | Disabling IPv6 | MI | IPV6 is not used on SEAPATH. It is disabled in the kernel parameters. | Done |
| R14 | File system configuration options | MI | The recommended options are present on SEAPATH. | Done |
| R15 | 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 |
| R16 | Compile options for kernel data structure | MIEH | This recommendation implies recompiling the kernel. The work is the same as R15. | Not Done |
| R17 | Compile options for the memory allocator | MIEH | This recommendation implies recompiling the kernel. The work is the same as R15. | Not Done |
| R18 | Compile options for the management of kernel modules | MIEH | This recommendation implies recompiling the kernel. The work is the same as R15. | Not Done |
| R19 | Compile options for abnormal situations | MIEH | This recommendation implies recompiling the kernel. The work is the same as R15. | Not Done |
| R20 | 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 |
| R21 | Compile options for the compiler plugins | MIEH | This recommendation implies recompiling the kernel. The work is the same as R15. | Not Done |
| R22 | Compile options of the IP stack | MIEH | This recommendation implies recompiling the kernel. The work is the same as R15. | Not Done |
| R23 | Compile options for various kernel behaviors | MIEH | This recommendation implies recompiling the kernel. The work is the same as R15. | Not Done |
| R24 | Compile options for 32 bit architectures | MIEH | This recommendation targets 32 bits x86 machines. Currently, SEAPATH is not supported on such hardware. | Not Applicable |
| R25 | Compile options for x86_64 bit architectures | MIEH | This recommendation implies recompiling the kernel. The work is the same as R15. | Not Done |
| R26 | Compile options for ARM architectures | MIEH | This recommendation targets ARM based processor. Currently, SEAPATH is not supported on such hardware. | Not Applicable |
| R27 | Compile options for ARM 64 bit architectures | MIEH | This recommendation targets ARM based processor. Currently, SEAPATH is not supported on such hardware. | Not Applicable |
| R28 | Typical partitioning | MI | Currently, only /boot and / are separated. | Not Done |
| R29 | 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 |
| R30 | Removing the unused user accounts | M | There are no unused accounts on SEAPATH | Done |
| R31 | 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 |
| R32 | Configuring a timeout on local user sessions | MI | The bash timeout is set to 300s. | Done |
| R33 | Ensuring the imputability of administration actions | MI | Only sudo commands are logged. | Not Done |
| R34 | Disabling the service accounts | MI | No additionnal accounts can be opened by a service on SEAPATH. | Done |
| R35 | 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 |
| R36 | Changing the default value of UMASK | MIE | UMASK is set to the desired value. | Done |
| R37 | Using Mandatory Access Control features | MIE | SEAPATH uses Apparmor, the MAC solution of Debian. | Done |
| R38 | 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 |
| R39 | Sudo configuration guidelines | MI | All desired options are implemented and tested. | Done |
| R40 | Using unprivileged users as target for sudo commands | MI | No command targets root. | Done |
| R41 | 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.
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. | Done |
| R42 | Banishing the negations in sudo policie | MI | No negation is present in the sudoer files | Done |
| R43 | Defining the arguments in sudo specifications | MI | When possible, all commands allowed to run with sudo must define specific arguments.
The remarks are the same for R41. TODO | Done |
| R44 | 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 |
| R45 | Activating AppArmor security profiles | MIE | All AppArmor profiles are present, but no test exists for it. | Done |
| R46 | Activating SELinux with the targeted policy | MIEH | Debian uses AppArmor instead of SELinux | Not Applicable |
| R47 | Containing the unprivileged interactive users | MIEH | Debian uses AppArmor instead of SELinux | Not Applicable |
| R48 | Setting up the SELinux variables | MIEH | Debian uses AppArmor instead of SELinux | Not Applicable |
| R49 | Uninstalling SELinux Policy Debugging Tools | MIEH | Debian uses AppArmor instead of SELinux | Not Applicable |
| R50 | 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 |
| R51 | 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 |
| R52 | 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 |
| R53 | Avoiding files or directories without a known user or group | M | All files and directory have a known user and group | Done |
| R54 | Setting the sticky bit on the writable directories | M | The sticky bit is set for all writable directories | Done |
| R55 | Dedicating temporary directories to users | MI | All users and services have a dedicated temporary directory. | Done |
| R56 | 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 |
| R57 | Avoiding using executables with setuid root and setgid root rights | MIE | Some executables still have root setuid and setgid. | Not Done |
| R58 | 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 |
| R59 | 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 |
| R60 | Using hardened package repositories | MIE | Debian don't use hardened packages repositories | Not Applicable |
| R61 | Updating regularly the system | M | SEAPATH provides an update system. On Debian, apt updates are used. Refer to this page for more information https://wiki.lfenergy.org/display/SEAP/IT+tooling | User applicable |
| R62 | 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 |
| R63 | 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 |
| R64 | 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 |
| R65 | 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 |
| R66 | 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 |
| R67 | 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 |
| R68 | 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 |
| R69 | 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 |
| R70 | 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 |
| R71 | 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 |
| R72 | Implementing dedicated service activity journals | MIE | SEAPATH uses systemd that complies with this requirement. | Done |
| R73 | Logging the system activity with auditd | MIE | Auditd is installed and configured. | Done |
| R74 | Hardening the local messaging service | MI | SEAPATH doesn’t have any messaging services | Not Applicable |
| R75 | Configuring aliases for service accounts | MI | SEAPATH doesn’t have any messaging services | Not Applicable |
| R76 | Sealing and checking files integrity | MIEH | We must install intrusion monitoring tools | Not Done |
| R77 | Protecting the sealing database | MIEH | The sealing database is generally protected by intrusion monitoring tools. | Not Done |
| R78 | 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 |
| R79 | Hardening and monitoring the exposed services | MI | Network services are already hardened by systemD. However, this recommendation doesn’t precise 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 |
| R80 | 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 |