Back to top

This topic describes how third-party vendors can create their own containers using SEAMS. The SE for Android Management Service (SEAMS) provides controlled access to the SELinux policy engine. SEAMS is used by the Knox container, and is also available to third-party vendors to secure their own container solutions. For security considerations, the domains for third-party Workspace containers have been defined by Samsung and are activated on-demand when the container app is first invoked.

Creating a SEAMS container

To secure apps using SE for Android containers using SEAMS:

  1. Use createSEContainer API to create a Knox container and secure a containerID.
  2. Use addAppToContainer to add the necessary apps into the container. Depending on whether the apps are important apps or just supporting apps, they can use apptype generic_secured or generic_trusted respectively.
  3. In order to remove apps from the container, use removeAppFromContainer API.
  4. If they want to remove the container, they need to remove all apps in the container using removeAppFromContainer and then use removeSEContainer to actually remove the container.
  5. In order to get information related to APIs, use getPackageNamefromSEContainer, getAllSEContainerIDs, getContainerIDfromPackageName, and so on.

Active SE for Android protection for third-party containers

In order to use this API, the MDM should work with Samsung to define the requirements for the SE for Android domain-based protection. Once the requirements are established, Samsung implements the feature for the MDM. A FOTA upgrade is required to use this feature once development is complete.

seams.addAppToContainer (packageName, certificate, containerID, appType);
// Use GENERIC_SECURED_APPTYPE = 3 for container app
// Use GENERIC_TRUSTED_APPTYPE = 4 for the app that can communicate with container app
seams.removeAppFromContainer(packageName, certificate);

Create SEAMS Workspace with clipboard protection

Currently any information copied into the clipboard while inside an app installed in a SEAMS Workspace (either generic container or Good container) can be copied outside of the container. This ability poses a security risk since data inside the container can be exported out of the container very easily. The Knox Workspace already provides the ability to control the isolation of the clipboard across the container’s boundary; starting with the Knox 2.6 release, this feature exposes the same controls to the SEAMS containers.

Currently, apps within generic / Good secontainer share the user 0 clipboard. This means the data copied into the clipboard can be seen by any app on the device including Knox Workspace (default MDM policy supports shared clipboard). Clipboard isolation for generic/Good secontainer has been added to prevent this data leakage.

You can add clipboard isolation for a generic/Good secontainer to prevent clipboard data leakage.

Previously any data copied to the clipboard by an app inside a SEAMS container was accessible by any app on the mobile device. To provide customers the ability to prevent this data from being leaked outside of the container through the clipboard, a new API allows customers to use an MDM solution to select the clipboard mode for SEAMS containers.

In the Knox 2.6 initial release of this feature, the default state of the clipboard remains the same as the legacy behavior — the clipboard will not be isolated for SEAMS containers. This default behavior is meant to allow existing deployments to retain their existing expected behavior, while MDM solutions add support for the new APIs to view and control clipboard state. After one year (approximately the Knox 2.8 release timeframe), this feature will be updated to switch to a default secure state where the clipboard of SEAMS containers will be isolated from other apps unless an MDM is used to change the clipboard state. During this one year period, MDM vendors are encouraged to add support for this feature and then inform their customers to decide on an acceptable clipboard policy for SEAMS containers for existing and/or future deployments. Customers should then test their clipboard preferences prior to deploying Knox 2.8-based devices. If a customer fails to follow these steps and deploys both Knox 2.6-2.7 devices and Knox 2.8+ devices with SEAMS containers, without making the appropriate MDM selection for the clipboard isolation mode, then the default behavior for old devices will be different than their new devices, which could cause end-user confusion or frustration.

Clipboard modes

  • CLIPBOARD_ENABLED_BIDIRECTIONAL — data copied to the clipboard while in a SEAMS container can be accessed outside of the container. Data copied to the clipboard outside of SEAMS can be accessed inside the SEAMS container.
  • CLIPBOARD_DISABLED_BIDIRECTIONAL — data copied to the clipboard while in a SEAMS container can NOT be accessed outside of the container. Data copied to the clipboard outside of SEAMS can NOT be accessed inside the SEAMS container.


  • To use this feature, the customer IT dept must create a generic/Good secontainer
  • The IT admin should have added some apps (typically enterprise apps) as secured apptype into the newly created secontainer.
  • In this scenario, when the customer company employee wants to copy some text/url/image from one secured app and paste it into another secured app, they should be allowed to do so.
  • At the same time, the copied data should not be visible to non-container applications to protect the data.

API usage

SEAMS seams = SEAMS.getInstance(context);
try {
    // replace SE Linux policy
    seams.setSEContainerClipboardMode(int containerID, int mode);
} catch (SecurityException e) {
    Log.e(TAG, "SecurityException: " + e);

Enable SE container clipboard isolation

This feature is disabled by default and can be enabled by calling the following APIs:

  • boolean isShareClipboardDataToOwnerAllowed (ContextInfo cxtInfo)
  • boolean allowShareClipboardDataToOwner(ContextInfo cxtInfo, boolean value)

Is this page helpful?