Axis is planning to introduce signing of ACAP applications as default and remove root-privileged access in future AXIS OS releases.

In upcoming AXIS OS releases, Axis will introduce additional security measures in AXIS OS and ACAP applications. Starting from AXIS OS 12.0, it will only be possible to install signed ACAP applications in Axis devices by default and the ability for root-privileged access will be removed.

New functionality will first be introduced on the AXIS OS active track. Over time the added functionality will be enabled by default in the firmware but include the ability to disable for specific use cases and development purposes. From AXIS OS 12.0 it will no longer be possible to disable certain functionality. See the preliminary release schedule available in this guide for more details on how functionality is planned to be introduced over time.

Removal of root-privileged access

The removal of root-privileged access in AXIS OS 12.0 will ensure proper protection of data, its confidentiality, and the integrity of ACAP applications and system services. There will be no possibility for any human user or ACAP application to utilize root-privileges.

The removal of root-privileged access will affect ACAP applications that are using "root" for the user and group, or applications that are dependent on root-privileged access. Changes will be gradually introduced on the AXIS OS active track to give ACAP application developers time to adapt applications that are not developed using dynamic user and group as recommended in ACAP User and Group. The ability to disable certain functionality will be included in the AXIS OS Long-term support (LTS) track 2024, which will be supported until 2029.

ACAP application signing

By signing an ACAP application you can ensure that the content of the application is not tampered with between the release and installation on the Axis device. ACAP application signing is a building block towards secure software delivery that could also be mandatorily enforced in the future through legislation such as the E.U. Cybersecurity Resilience Act, E.U. Radio Equipment Directive and Executive Order 14028. During the ACAP application signing process, a signature is added at the end of the application package. The signature is verified by the Axis device when installing the ACAP application as part of the overall secure software delivery architecture. 

From AXIS OS 12.0 users will only be able to install signed ACAP applications in Axis devices by default. Installation of unsigned ACAP applications will only be possible if a device is actively configured to accept unsigned ACAP applications. Configuring a device to accept unsigned ACAP applications will lower the device security, but can be useful during development or if you develop and run your own ACAP application. Running unsigned ACAP applications is not recommended.

Any ACAP applications (signed or unsigned) already installed on a device being upgraded to AXIS OS 12.0 will not be affected by this change and will continue to work as before.

What is changing in AXIS OS 12.0

In AXIS OS 12.0 the following changes will be fully implemented:

  • ACAP applications will not be able to run with the root-user and its privileges.
  • ACAP applications will not be able to access filesystem resources or functionality requiring root-privileges.
  • ACAP Install- and Uninstall-script will not be able to run with root-privileges.
  • A user that may be named “root”, created upon first installation will no longer have root-privileges.
  • SSH users will no longer have root privileges.
  • Axis devices will only accept installation of signed ACAP applications by default. Devices can be configured to accept unsigned ACAP applications after lowering the device security through settings change. ACAP applications already installed on an Axis device being upgraded to AXIS OS 12.0 will not be affected.
Scenario


ACAP application 
is signed

ACAP application is running without root-privileges

ACAP application 
is signed

ACAP application is running with root-privileges

ACAP application 
is not signed

ACAP application is running without root-privileges

ACAP application 
is not signed

ACAP application is running with root-privileges

Device upgrade from AXIS OS X 
to AXIS OS 12
                  ✔The upgrade to AXIS OS 12.0 is successful but affected ACAP applications will not start.                            ✔The upgrade to AXIS OS 12.0 is successful but affected ACAP applications will not start or will be de-installed including all their data.
New device installation 
AXIS OS 12
                  ✔Not possible to install ACAP application.

The user needs to toggle the parameter to allow the installation of unsigned ACAP applications. 

This lowers the security level of the device.

Not possible to install ACAP application.

Release schedule

This schedule is preliminary and both timing and included features are subject to change as work progresses.

AXIS OS 11.2 (January 2023)

  • ACAP signing can be enabled through parameter.
     

AXIS OS 11.5 (June 2023)

  • VAPIX/Web Access: The user “root” is an ordinary administrator.
  • ACAP Privileges: Root privileges can be disabled.
     

AXIS OS 11.6 (September 2023)

  • SSH Access: Root user access can be disabled.
     

AXIS OS 11.8 ( January 2024)

  • SSH Access: Root user access is disabled by default but can be enabled.
  • ACAP Privileges: Root privileges is disabled by default but can be enabled.


Note that the parameter settings as outlined above only apply to factory defaulted Axis devices. Upgrading from any previous AXIS OS version to AXIS OS 11.8 and later will not result in the default parameters and their setting taking effect. The user is required to toggle the parameter after upgrading.
 

AXIS OS LTS 2024 (September 2024)

AXIS OS LTS 2024 is supported from 2024 until 2029. Can be used as a stop-gap solution until an ACAP application is fully adapted. The release for AXIS OS LTS 2024 is the last AXIS OS 11 Active track release, AXIS OS 11.11.

  • SSH Access: Root-privileged access is disabled by default but can be enabled.
  • ACAP Privileges: Root-privileges are disabled by default but can be enabled.
     

AXIS OS 12.0 (September 2024)

  • SSH Access: Root-privileged access removed and cannot be re-enabled. 
  • ACAP Privileges: ACAP applications cannot run with root-privileges.
  • Signed ACAP applications are mandatory in factory defaulted state unless disabled through settings change. Running unsigned ACAP applications is not recommended.
     

Considerations for upcoming AXIS OS releases

VAPIX/Web interface

User privileges over VAPIX will go unchanged since any admin account will be able to perform all configuration-related tasks as of today. It is recommended to create dedicated admin-accounts or operator/viewer accounts and avoid using the current root account as outlined in the AXIS OS Hardening Guide. All features will still be accessible and configurable through the web interface of the device.

SSH

Using root-privileges over SSH will not be available anymore resulting in less-privileges when logging in through SSH. Using the product web interface to toggle allowance of root-privileged SSH access is available from AXIS OS 11.6 but this setting will be removed in AXIS OS 12.

Toggle allowance of root-privileged SSH access Using the product web interface to toggle allowance of root-privileged SSH access is available from AXIS OS 11.6.

Creating a “root”-user

It will still be possible to create a user named “root”, but the user will only have administrator privileges. Previously, the initial username was hardcoded to be "root". With AXIS OS 11.6, this limitation has been lifted and now allows for user-defined naming of the initial user.

Creating a user-defined initial user Previously, the initial username was hardcoded to be "root". With AXIS OS 11.6, this limitation has been lifted and now allows for user-defined naming of the initial user.

ACAP application development

ACAP applications will not be allowed to run with root-privileges but will be required to define a user with limited privileges. Privileges can be expanded through explicit definition in ACAP manifest. For future-proofing your ACAP application and for additional security, we recommend that you specify it to run as a generated dynamic user in the manifest.json schema. A static named user will still be supported in AXIS OS 12.0, but the option may be removed at a later point.

Recommended testing for ACAP applications

Starting from AXIS OS 11.5 (June 2023), it will be possible to test your ACAP applications with root-privileged access removed. Testing can be performed by toggling ‘allow root-privileged apps' in the product web interface. Please check the VAPIX Library for instructions on how to use the toggle. By testing this functionality, you can ensure that your applications during installation and beyond work as expected with root-privileged access removed. Please refer to the feedback and support section at the end of this guide if you have any questions or feedback.

Toggle allowance of root access in web interface Using the product web interface to toggle allowance of root-privileged apps is available from AXIS OS 11.5.

Signing ACAP applications

Users will only be able to install signed ACAP applications in Axis devices by default in AXIS OS 12. To allow the installation of unsigned ACAP applications, a parameter needs to be toggled. Note that this lowers device security. Signing an ACAP application ensures that a signature is added at the end of the application package. The signature is verified by the device when installing the ACAP application as part of the overall secure software delivery architecture.

ACAP applications already installed on a device

Any signed or unsigned ACAP applications already installed on an Axis device will continue to work as before even if the device is upgraded to an AXIS OS 12 version. If a device is reset to factory default in AXIS OS 12 and an unsigned ACAP application needs to be installed on the device, the parameter needs to be toggled to allow for that. Note that this would lower the device security as it will not be possible to differentiate signed ACAP application from unsigned ACAP applications on a device once installed.

Installing unsigned ACAP applications

It will be possible to allow installation of unsigned ACAP applications by actively configuring a device to accept unsigned applications through the web interface of the device or using a VAPIX API (Available from AXIS OS 11.2). AXIS Device Manager and AXIS Device Manager Extend can be used to configure several products at the same time. Allowing installation of unsigned applications can be useful during development and testing. It is also an option if you develop your own ACAP application, or if you need to install an unsigned ACAP application from a vendor you trust for a specific use case. Once you are done with testing and have installed an unsigned ACAP application as needed, it is recommended that you configure your device to only allow installation of signed ACAP applications again. Any installed unsigned ACAP applications will continue to work even if you configure a device to not allow installation of unsigned ACAP applications.

Toggle in web interface Using the product web interface to toggle allowance of unsigned ACAP applications is available from AXIS OS 11.2.

FAQ

How do I change the user my ACAP application runs as?

If you are currently running your application as the root user, there are two ways to move away from that:

  • Remove the section acapPackageConf > setup > user entirely from the manifest. This will lead to a unique user (so called dynamic user) being generated for your application during installation. This option is preferable from a security perspective but requires that you state the groups the application user needs to belong to and the D-Bus rights it needs, in the manifest. (This will be made simpler in the future).
  • Change the user and group to "sdk" users in the manifest, in the section: acapPackageConf > setup > user. Please refer to our documentation at ACAP User and Group for detailed instructions on when and how to use "sdk" user
     

See the schema documentation for more information about available fields in manifest.json. If you still use package.conf instead of manifest.json you should simply change the user and group to "sdk" in that file. 

What will happen if I toggle off the "Allow root privileged apps" toggle?

You will not be able to install an ACAP application that runs as root or belongs to the root group (or certain other privileged users and groups). Install or uninstall scripts will no longer run as root. However, any installed applications running with root privileges will continue to work. This can, in some cases, mean that uninstallation will fail since an application might have an uninstall script that only works properly when running as root. To prevent that you should uninstall that application before unsetting the toggle, and install it again. The toggle is a temporary feature meant to help ensure that applications run properly without root. It will be removed in AXIS OS 12.0 and from then on it will be a hard requirement that applications run without root privileges.

How can I call VAPIX APIs from an ACAP application running as a non-root user?

See VAPIX access for ACAP applications in the ACAP SDK documentation. Please note that this feature was introduced in AXIS OS 11.6 as a beta feature. Follow the potential changes in our release notes and documentation.

What use cases can calling VAPIX from an ACAP application support?

Any use-case supported by VAPIX itself. See the VAPIX documentation. You will get admin-level access so all APIs will be available to use.

What happens if I upgrade to an application running as non-root but there are saved files on the system that are owned by root?

If the files were saved to the "localdata" directory belonging to the application, the owner of the files will be automatically changed to the right user during the upgrade process. If the files were saved to some other location, the ACAP framework will have no knowledge of those files and cannot automatically handle them. In that case, some other solution has to be found, depending on the specific circumstances.

What will be the behavior in AXIS OS 11.8 with regards to the "AllowRoot" setting if I upgrade from a previous AXIS OS version?

If you upgrade to 11.8 from an earlier version of AXIS OS, the previous setting will be kept. If the upgrade is from an AXIS OS version that doesn't have the setting, the behavior will be to set "AllowRoot" to true. The motivation for this is that upgrades should never be broken, even if you have applications installed that require root access. The new default of disallowing root privileges will only take effect in case of a new installation or a factory default.

How can I set up a reverse proxy without root privileges?

In previous versions, setting up a reverse proxy required a post-install script with root privileges. This method is no longer permitted. Starting with version 11.8 (featuring Manifest schema v1.5.0), we have introduced support for configuring a reverse proxy via the manifest file. 

For detailed instructions, please refer to our documentation at ACAP Development: Manifest Schema Field Descriptions v1.5.0.  You can also find an example manifest file to guide you through the setup process at ACAP Native SDK Examples Repository.

Feedback and support