SEAPATH follows the applicable cybersecurity guidelines defined by the ANSSI in the ANSSI-BP-028 document . Several mechanisms have been taken into account in order to guarantee system’s 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.


The Debian version of SEAPATH follows the version 2 of the document : ANSSI-BP-028 v2 

A compliance matrix listing all the tests done on SEAPATH and their relation to the requirements is available at the end of each test report on the CI. You can find weekly test reports here:

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.

  • Done: SEAPATH complies with this requirement. Tests are run with cukinia to ensure that future development don't break this compliance. (Some requirements 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. However, some specific parts of the requirement are done, and tests exists for it.

R1Choosing and configuring the hardwareMIEThe hardware chosen to run SEAPATH must comply with
Note that all modern x86 machines are already compatible. The ANSSI has not released a similar Document for ARM machines.
User applicable
R2Configuring the BIOS/UEFIMIThe BIOS must be configured according to the document applicable
R3Activating the UEFI secure bootMISEAPATH is compatible with Secure Boot and support preload keys.
No test exists currectly
User applicable
R4Replacing of preloaded keysMIEHWe 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
R5Configuring a password on the bootloaderMIGrub password can be configured in ansible inventory.Done
R6Protecting the kernel command line parameters and the initramfsMIEHCurrently, neither the kernel nor the initramfs are protected by secure boot.Not Done
R7Activating the IOMMUMIEIOMMU must be activated in force mode.
Non-regression tests must be performed to ensure that this is compatible with SEAPATH features
Not Done
R8Configuring the memory optionsMIThe options are present on SEAPATH.
The related test checks that the CPU has no known vulnerabilities
R9Configuring the kernel optionsMIThe kernel options are presentDone
R10Disabling kernel modules loadingMIEThe 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
R11Configuration option of the Yama LSMMIThe kernel parameter security=yama is present.
The sysctl is configured to 2
R12IPv4 configuration optionsMIIPV4 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
R13Disabling IPv6MIIPV6 is not used on SEAPATH. It is disabled in the kernel parameters.Done
R14File system configuration optionsMIThe recommended options are present on SEAPATH.Done
R15Compile options for memory managementMIEHWe 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
R16Compile options for kernel data structureMIEHThis recommendation implies recompiling the kernel. The work is the same as R15.Not Done
R17Compile options for the memory allocatorMIEHThis recommendation implies recompiling the kernel. The work is the same as R15.Not Done
R18Compile options for the management of kernel modulesMIEHThis recommendation implies recompiling the kernel. The work is the same as R15.Not Done
R19Compile options for abnormal situationsMIEHThis recommendation implies recompiling the kernel. The work is the same as R15.Not Done
R20Compile options for kernel security functionsMIEHThe Debian kernel used by SEAPATH is already compiled with these options.
TODO : Add a test for this
R21Compile options for the compiler pluginsMIEHThis recommendation implies recompiling the kernel. The work is the same as R15.Not Done
R22Compile options of the IP stackMIEHThis recommendation implies recompiling the kernel. The work is the same as R15.Not Done
R23Compile options for various kernel behaviorsMIEHThis recommendation implies recompiling the kernel. The work is the same as R15.Not Done
R24Compile options for 32 bit architecturesMIEHThis recommendation targets 32 bits x86 machines. Currently, SEAPATH is not tested on such hardware.Not Done
R25Compile options for x86_64 bit architecturesMIEHThis recommendation implies recompiling the kernel. The work is the same as R15.Not Done
R26Compile options for ARM architecturesMIEHThis recommendation targets ARM based processor. Currently, SEAPATH is not tested on such hardware.Not Done
R27Compile options for ARM 64 bit architecturesMIEHThis recommendation targets ARM based processor. Currently, SEAPATH is not tested on such hardware.Not Done
R28Typical partitioningMICurrently, only /boot and / are separated.Not Done
R29Access restrictions on /bootMIE/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
R30Removing the unused user accountsMThere are no unused accounts on SEAPATHDone
R31User password strengthMThe passwords used on SEAPATH must follow
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
R32Configuring a timeout on local user sessionsMIThe bash timeout is set to 300s.Done
R33Ensuring the imputability of administration actionsMIOnly sudo commands are logged.Not Done
R34Disabling the service accountsMINo additionnal accounts can be opened by a service on SEAPATH.Done
R35Uniqueness and exclusivity of service accountsMINot all services have a dedicated account.Not Done
R36Changing the default value of UMASKMIEUMASK is set to the desired value.Done
R37Using Mandatory Access Control featuresMIESEAPATH uses Apparmor, the MAC solution of Debian.Done
R38Creating a group dedicated to the use of sudoMIEThe group « privileged » is used for sudo usage.
If a PAM authentification is implemented by the end user, privileged users must also use this group.
R39Sudo configuration guidelinesMIAll desired options are implemented and tested.Done
R40Using unprivileged users as target for sudo commandsMINo command targets root.Done
R41Limiting the number of commands requiring the use of the EXEC directiveMIE

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

R42Banishing the negations in sudo policieMINo negation is present in the sudoer filesDone
R43Defining the arguments in sudo specificationsMI

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

R44Editing files securely with sudoMINo 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
R45Activating AppArmor security profilesMIEAll AppArmor profiles are present, but no test exists for it.Done
R46Activating SELinux with the targeted policyMIEHDebian uses AppArmor instead of SELinuxNot Applicable
R47Containing the unprivileged interactive usersMIEHDebian uses AppArmor instead of SELinuxNot Applicable
R48Setting up the SELinux variablesMIEHDebian uses AppArmor instead of SELinuxNot Applicable
R49Uninstalling SELinux Policy Debugging ToolsMIEHDebian uses AppArmor instead of SELinuxNot Applicable
R50Limiting the rights to access sensitive files and directoriesMIThis principle is followed natively by Debian.
TODO : Write a list of sensitive directories and test that they have the correct access rights.
R51Changing the secrets and access rights as soon as possibleMIESEAPATH is meant to be entirely functional once the installation and configuration is completed.
TODO : Is it possible to write a test for that ?
R52Securing access for named sockets and pipesMISEAPATH comply with this recommendation, but the test is difficult to write.
TODO : write a test for that
R53Avoiding files or directories without a known user or groupMAll files and directory have a known user and groupDone
R54Setting the sticky bit on the writable directoriesMThe sticky bit is set for all writable directoriesDone
R55Dedicating temporary directories to usersMIAll users and services have a dedicated temporary directory.Done
R56Avoiding using executables with setuid and setgid rightsMNo executables added by the SEAPATH project have the setuid or setgid rights. This recommendation is not applicable to Debian native executables.Done
R57Avoiding using executables with setuid root and setgid root rightsMIESome executables still have root setuid and setgid.Not Done
R58Installing only strictly necessary packagesMA list of necessary packages is described in the testing process. A test verifies that no additionnal packages are installed.Done
R59Using only official package repositoriesMOnly Debian repository are used by default.
The end user can add its own mirror during the Ansible configuration.
R60Using hardened package repositoriesMIEDebian don't use hardened packages repositoriesNot Applicable
R61Updating regularly the systemMSEAPATH provides an update system. On Debian, apt updates are used.
Refer to this page for more information
User applicable
R62Disabling the non-necessary servicesMA list of necessary services is described in the testing process. A test verify that no additionnal services are started.Done
R63Disabling non-essential features of servicesMIWe must take the list of services done in R62 and limit the functionnalities of all services to the minimum required.Not Done
R64Configuring the privileges of the servicesMIEA 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
R65Partitioning the servicesMIEMany 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
R66Hardening the partitioning componentsMIEHThis 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
R67Secure remote authentication with PAMMIThe 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
R68Protecting the stored passwordsMThe password storage must follow
Tests verify that the initial and generated passwords complies.
R69Securing access to remote user databasesMISimilar to R69, this part must be configured by the end user after selecting the remote login software.User applicable
R70Separating the system accounts and directory administratorMIThe 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
R71Implementing a logging systemMIESEAPATH uses journald for local logs and syslog-ng for remote logs.
These systems doesn’t fully comply with the recommendation.
Partially done
R72Implementing dedicated service activity journalsMIESEAPATH uses systemd that complies with this requirement.Done
R73Logging the system activity with auditdMIEAuditd is installed and configured.Done
R74Hardening the local messaging serviceMISEAPATH don’t have any messaging serviceNot Applicable
R75Configuring aliases for service accountsMISEAPATH don’t have any messaging serviceNot Applicable
R76Sealing and checking files integrityMIEHWe must install intrusion monitoring toolsNot Done
R77Protecting the sealing databaseMIEHThe sealing database is generally protected by intrusion monitoring tools.Not Done
R78Partitioning the network servicesMIEIt is the goal of SEAPATH to isolate services on virtual machines (or containers).
However, some services remains not isolated and it will be very complicated to isolate some (eg : snmp, ceph, ssh ...)
Not Done
R79Hardening and monitoring the exposed servicesMINetwork services are already hardened by systemD. However, this recommendation doesn’t precise a limit to the hardening.
A list of the hardening measure of systemd must be done and made available to SEAPATH integrators
Partially done
R80Minimizing the attack surface of network servicesMAll network sockets listen on a dedicated interface.Done

  • No labels