Configuration-integrity
Configuration-integrity is an automatic integrity verification of configuration files.
Overview
The main idea behind this feature is to protect configuration files from malicious modification in order to ensure the integrity of the system.
Configuration-integrity uses secure storage in order to store hashes of configuration files. This is needed in order to verify integrity of configuration files before application or modification.
The following configuration files are protected by the feature:
Static configuration files: - factory-config.cfg - safe-config.cfg - no-config.cfg
Running configuration file: - running-config.cfg
Startup configuration file: - startup-config.cfg
Static configuration files are handled in a simplified way, since these, even if modified, reset to their original state during boot. Their hashes will be added to secure storage once, during first boot, and the only occasion an update might be needed is when installing a branding package. These static files have implicit trust.
Branding package might have custom factory-config, safe-config and no-config files, and these would replace their standard counterparts. Since the default policy is to trust the branding package, no integrity verification is performed, only an update.
running-config’s integrity is updated upon configuration change through CLI or Web, or upon copying other config files into it.
CLI and Web changes simply update the integrity of the running-config, while copy command will first verify the source file that is being copied into the running-config. If integrity verification of the source succeeds, the copy is performed and the integrity information will be updated.
startup-config’s integrity information is updated either upon copy command, or when applying settings in the Web. Upon ‘copy’, the source file’s integrity will always be verified and an appropriate audit log entry will appear in the audit log. When applying settings through the Web, the integrity of the startup-config will be updated to reflect recent changes.
Backup/restore
WeOS can generate unlimited number of backups, but only 5 latest fingerprints will be stored in the secure storage, while older ones will be overwritten.
Restoring of any backup is possible but an alert will be issued in the audit log, unless the configuration that is being restored is one of the five latest backups generated by this device.
Default policy
The default policy is to always allow copying files and restoring backups even if their integrity isn’t intact, but an appropriate audit log entry will be issued to signal a potential threat.