# Customize security services

Customization is supported for memory and SEPolicy. For a large-size trusted application, you can customize the memory regions.

## Customize memory

To customize memory, this feature is available to licensed users with authorized access. If you have access, see [Qualcomm Linux Security Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-70030-11A/customize-fru.html).

## Customize SEPolicy

Qualcomm SEPolicy depends on the upstream SEPolicy. Therefore, the upstream SEPolicy’s make system is used for building and customizing the SEPolicy.

Any customization to upstream code must be stored in the [patches](https://github.com/quic-yocto/meta-qcom-hwe/tree/kirkstone/dynamic-layers/selinux/recipes-security/sepolicy/patches) directory as a path to the upstream code. You can find the upstream code at [SELinuxProject/refpolicy](https://github.com/SELinuxProject/refpolicy/).

The Qualcomm code is configured to the monolithic SEPolicy mode and SELinux types as targeted. To modify the SEPolicy mode and the SELinux types, do the following:

> 
> 
> - To change the SELinux type and mode, you can edit the [Qualcomm base file](https://github.com/quic-yocto/meta-qcom-distro/blob/kirkstone/conf/distro/include/qcom-base.inc).
> - To add the SEPolicy patches, add it to the [patches folder](https://github.com/quic-yocto/meta-qcom-hwe/tree/kirkstone/dynamic-layers/selinux/recipes-security/sepolicy/patches) and update the respective selinux\_type bbappend files (`refpolicy-targeted.bbappend` or `refpolicy-mls.bbappend`), which aren’t set by default. Add selinux enablement code in distro and then edit PREFERRED\_PROVIDER\_virtual/refpolicy.

### Compile SEPolicy

1. To compile the SEPolicy, run the following commands:

export SHELL=/bin/bash
        Copy to clipboard
2. Set up the build environment. For instructions, see [Qualcomm Linux Build Guide](https://docs.qualcomm.com/bundle/publicresource/topics/80-70030-254/github_workflow_unregistered_users.html).
3. Based on the SELinux type, compile only the SEPolicy with `bitbake  refpolicy-mls` or `bitbake  refpolicy-targeted`.

bitbake <recipe_file_name>
        Copy to clipboard

### Modify and build

You can also modify and build incrementally.

The audit2allow and research tools on Ubuntu 18 or 20 don’t support policy version33. The policy version33 is supported from Ubuntu 23. If you aren’t using Ubuntu 23, you can use a docker setup or a virtual machine to run audit2allow.

### Install docker

The following command is used to install docker on Ubuntu with an earlier version.

sudo docker pull ubuntu:23.04
    sudo docker run -ti --rm ubuntu /bin/bash
    apt-get update
    apt-get -y install policycoreutils
    apt-get install -y policycoreutils-python-utils
    Copy to clipboard

Then run audit2allow on this shell .

Pull the policy version33 from the target `/etc/selinux/mls/policy/policy.33`. This policy is also available in the build tree. Use the mountbind or docker copy commands to share the policy with the docker.

### Capture denials

If the command prompt doesn’t change when `policy.33` is pulled from
the `target /build`, and if `denials.txt` is a file capturing the denials,
use the following command:

audit2allow -i denials.txt -p policy.33
    Copy to clipboard

### Command not found

If this command isn’t found, then use the following command to install the required package:

sudo apt install policycoreutils-python-utils
    Copy to clipboard

## Provision replay protected memory block

Replay protected memory block (RPMB) provisioning is a one time process for the lifetime of the device and it’s irreversible.

- Provision RPMB for secure boot devices:

> 
> 
> - RPMB is automatically provisioned with production keys during the secure boot process.
>     - Don’t provision RPMB before enabling secure boot.
>     - Don’t follow any explicit steps to provision RPMB for secure boot devices.
- Provision RPMB for non-secure boot devices:

> 
> 
> - You can provision RPMB with test keys for testing and exercising certain use cases to observe the functionality similar to secure boot devices. Example use cases include:
> 
> 
> 
> > 
> > 
> > - Secure file system (SFS) file version information and anti-rollback protection
> >         - Trusted application anti-rollback protection
> > 
> > 
> > 
> > Caution
> > 
> > 
> > Secure boot can’t be enabled on a device once RPMB is provisioned with test keys.
>     - To provision RPMB with test key, see [Verify RPMB provisioning status](https://docs.qualcomm.com/doc/80-70030-11/topic/bring-up.html#section-bringup-check-rpmb-provision-status-label)

## Next steps

- For common logging and debugging techniques, see [Debug Qualcomm TEE and secure devices](https://docs.qualcomm.com/doc/80-70030-11/topic/debug.html#debug).
- To learn how to develop and run trusted and client applications, and for sample code and examples, see [Develop trusted and client applications](https://docs.qualcomm.com/doc/80-70030-11/topic/develop_lru.html#develop-lru).

Last Published: Jun 25, 2026

[Previous Topic
Install or upgrade SoftSKU feature packs](https://docs.qualcomm.com/bundle/publicresource/80-70030-11/topics/upgrade-qualcomm-wes-feature-pack.md) [Next Topic
Debug Qualcomm TEE and secure devices](https://docs.qualcomm.com/bundle/publicresource/80-70030-11/topics/debug.md)