Skip to main content

SELinux Monitoring

HexDroid platform provides a system daemon for Linux & Android (AOSP) devices, which will monitor SELinux issues that occur on device, and report them.

All reported issues are grouped, and displayed in HexDroid app so that they can be triaged, and get looked at by developers.

SELinux Reports Page

Setup​

Refer to Setup Page for integration steps.

Features​

Grouping​

HexDroid organizes SELinux violations into groups based on their similarity. This grouping process simplifies the triaging process for developers by consolidating multiple instances of the same issue into a single report.

Each group represents a unique SELinux violation type and provides the following key information:

  • Violation Details: For example: involved command, object names, security contexts, targeted class.
  • Occurrence Count: The total number of times this violation has occurred across your fleet.
  • Date Range: The first and last timestamps when this violation was observed, helping developers understand its timeline and frequency.

By aggregating and displaying this information in a centralized view, HexDroid makes it easier for development teams to identify recurring problems, prioritize fixes, and understand the broader impact of SELinux policy issues on your fleet.

Grouped SELinux report

Filtering​

To streamline the debugging and triaging process, HexDroid allows developers to filter and sort SELinux reports based on their state and other key attributes.

Each report can exist in one of the following states:

  • New: All freshly detected violations are initially assigned this state. These reports represent issues that have not yet been looked at by development team.
  • In Progress: Indicates that a developer is actively investigating or working on resolving the violation.
  • Ignored: Used for violations that are expected behavior and do not require any action.
  • Closed: Denotes that the violation has been fixed or is no longer relevant.

In addition to filtering by state, users can also refine their view by sorting reports based on:

  • Number of Occurrences: Prioritize violations that happen most frequently.
  • First Seen: Identify the oldest issues for a historical perspective or early debugging.
  • Last Seen: Highlight the most recent or ongoing issues that require immediate attention. Filter and SELinux reports

Instance details​

HexDroid provides an Instance Details view for each SELinux report, enabling users to dive deeper into individual occurrences of a violation.

This view displays a comprehensive list of all instances where the specific violation occurred, alongside detailed metadata for each instance

Users can view a chronological list of each reported instance of the violation. This includes specific timestamps and other associated details, offering a complete timeline of the issue.

Each violation instance is accompanied by metadata, which can be tailored to include any relevant key-value properties. This flexibility ensures that teams can track the exact details that matter most to their workflow.

The metadata allows developers to quickly identify patterns, such as whether an issue is isolated to certain devices, linked to specific software versions, or tied to a particular build type. This context is critical for efficient debugging and resolution.

SELinux Violation Instance Details with Metadata SELinux Violation Instance Details with Metadata

State​

Each SELinux report in HexDroid is assigned a state to help teams track the status of an issue throughout its lifecycle. States provide a clear indication of where a report stands in the debugging and resolution process, ensuring seamless collaboration and prioritization.

Developers can transition reports between these states as needed. This flexibility allows teams to manage the lifecycle of each report dynamically. For example:

  • A New report can be moved to In Progress when a developer starts investigating.
  • If the issue is resolved, it can transition directly from In Progress to Closed.
  • If the violation is determined to be non-critical, it can be moved to Ignored instead.

To provide additional context during state transitions, developers can leave comments.

Comments help document decisions, provide clarity for other team members, and ensure traceability. For instance:
SELinux report moves to ignored state
SELinux reports moves to closed state