Permission Teseter update sdk37

.gitignore

@@ -0,0 +1,3 @@
+.idea/
+*.iml
+.DS_Store

README.md

@@ -15,3 +15,5 @@ ioXt, tools related to the [internet of secure things alliance](https://www.ioxt
 
 The audience for this repo is OEMs working to obtain certifications that require test tools and artifacts. 
 
+SDK37 branch
+

niap-cc/Permissions/.agent/agent.yaml

@@ -0,0 +1,28 @@
+# 🤖 Multi-Agent Collaboration Configuration Draft (agent.yaml)
+
+This file is an idea sketch to facilitate "multi-window collaboration (distributed research via host and workers)" starting tomorrow.
+
+---
+
+## 💡 Communication Design: Discovery via Shared ID File
+
+Uses a common directory in the workspace (e.g., `xpermssion/`) accessible by all agents as a communication buffer.
+
+### 1. Role of Host (Orchestrator Agent)
+On startup, writes its own `Conversation ID` to a file.
+*   Write Destination: `xpermssion/active_parent_id.txt`
+
+### 2. Role of Worker (Research Agent)
+On startup, reads the shared file above.
+*   Sends `send_message` to the retrieved ID, notifying: "I (worker) have started. Please give instructions."
+
+---
+
+## 📋 Agent Role Definitions (Panel Classification Image)
+
+*   **Role: Permission_Host (Research Orchestrator)**
+    *   **Responsibilities**: Managing target list (CSV), allocating tasks to workers, and summarizing results into a comprehensive report.
+*   **Role: Permission_Worker_Zoekt (Search Specialist)**
+    *   **Responsibilities**: Running Zoekt for permissions specified by the host (running as parent agent avoids sandbox restrictions!), and notifying the host of occurrences in the source code.
+
+Let's launch multiple windows of this configuration tomorrow to begin verification!

niap-cc/Permissions/.agent/skills/permission-chk/SKILL.md

@@ -0,0 +1,93 @@
+# Permission Research Skill (SKILL.md)
+
+## Overview
+This skill is designed to execute a comprehensive investigation of Android permissions according to the defined procedure.
+It strictly follows `agent_and_report_plan.md` to avoid shortcut actions and creates evidence-based reports.
+
+## Available Tools
+- `run_command` (to execute zoekt searches)
+- `read_url_content` (to execute zoekt web searches - Recommended)
+- `view_file` (to inspect code)
+- `write_to_file` (to generate reports)
+- `send_message` (to report progress)
+
+## 🚫 Prohibited Actions & Code of Conduct (To Prevent Cutting Corners)
+
+You will act as a subagent (worker). The following actions are strictly prohibited, and failure to comply will result in the task being discarded:
+
+1. **Running `grep` or `find` via `run_command`**: Using these commands is prohibited in huge codebases like AOSP as it degrades performance. You MUST use `read_url_content` with the Zoekt Web Server (`http://localhost:6070/search?q=...`).
+2. **Invoking Subagents (`invoke_subagent`)**: Do not outsource the task to another agent. You must inspect all files yourself.
+3. **Asking Users for Questions/Approvals**: Do not block the task by asking the user questions when you are unsure during the investigation. If something is not found, record it as "not found", logically deduce and determine the evaluation, and complete the report.
+4. **Acting as the Host/Orchestrator Agent**: Do not issue instructions or demand actions from the user or the parent agent.
+
+## Workflow & Steps
+
+You must execute the following steps **in order**:
+
+### Step 1: Identify the Target
+Identify the target permission string (e.g., `android.permission.READ_CONTACTS`) from the specified CSV file or list.
+
+### Step 2: Report Start of Investigation (For Liveness Checks)
+Once the target permission is identified, report "Start of Investigation" to the parent agent before beginning intensive searches (Zoekt).
+- **Read File**: Retrieve the parent's Conversation ID from `xpermssion/active_parent_id.txt`.
+- **Send Message**: Use `send_message` to send "Start: [Permission Name]" to that ID.
+- **Purpose**: To track whether the agent is alive (not hung) during large batch processing.
+
+### Step 3: Fast Search via Zoekt
+Search the target permission string using `zoekt`.
+- Search Keyword Example: `android.permission.READ_CONTACTS` or `READ_CONTACTS`
+- Purpose: Identify the definition location (`AndroidManifest.xml`) and usage locations (such as `checkPermission` or `RequiresPermission`).
+- **Important**: To prevent timeouts, use `zoekt` instead of `find` or standard `grep`.
+
+### Step 4: Classify and Score Across 9 Categories
+Based on the found code, classify the permission into the following 9 categories:
+1. **Exclusion of Work-in-Progress (WIP)**
+2. **Isolation of Non-Phone Limits (Wear, Auto, TV, etc.)**
+3. **Identification of Feature Flag Control (Default Disabled)**
+4. **Identification of `BIND_*` Permissions**
+5. **Identification of DPC (Device Policy Controller) Permissions**
+6. **Whether It Applies Outside the Framework (e.g., Google Play)**
+7. **Corresponding CTS Tests**
+   - If corresponding tests exist, document the test name, test summary, user-level reproducibility, and the path to reproduce.
+8. **Reproduction Path Verification (Java code, Intent, Shell)**
+9. **Risk Level Assessment on Permission Granted (Level 0-5, Score 100-0)**
+   - **Level 0 (Score 100)**: Too dangerous to define, or already blocked in operation (e.g., AccessibilityService)
+   - **Level 1 (Score 10)**: Passwords, tokens, financial data
+   - **Level 2 (Score 7.5)**: Privacy (contacts, location, photos, etc.)
+   - **Level 3 (Score 5)**: PII (calendar, health data, etc.)
+   - **Level 4 (Score 2.5)**: Relatively harmless (app list, settings, etc.)
+   - **Level 5 (Score 0)**: Completely harmless
+   - The score must be determined using the **last number** from the table in `agent_and_report_plan.md`.
+
+### Step 5: Create Report
+Read `resources/report_template.md` and fill in the details to generate a report.
+- Destination Path: `xpermssion/permission-research/<Permission_Name>.md`
+- **Attach Evidence**: The unique "Verification Data" section is deprecated; consolidate all file links (file:///absolute_path#Lline_number), snippets, and reproduction methods inside **"8. Reproduction Path Verification"**.
+- If the permission is deemed highly utilized, list **at least 5 locations** where the permission is explicitly checked (e.g., via `if` conditions or explicit checking functions like `checkCallingOrSelfPermission`) in the actual source code (Java/C++, etc.). Prioritize execution code over configuration properties or manifest definitions.
+- For the reproduction method, clearly specify whether verification is possible using a **Public API**, **Non-Public/System API**, **ServiceManager / Binder IPC Call**, or **Shell Command**.
+
+### Step 6: Execute Self-Validation
+Verify if the generated report meets the criteria using the following command:
+```bash
+python3 .agent/skills/permission-chk/scripts/validate_report.py xpermssion/permission-research/<Permission_Name>.md
+```
+- If the validation fails, fix the report.
+
+### Step 7: Report to Parent Agent (🚨 Extremely Important)
+
+> [!IMPORTANT]
+> If this report (`send_message`) is not sent, the parent agent cannot recognize the completion of tasks when batch-processing a large number of permissions simultaneously, causing the entire system to collapse. Do not delay or wait for manual human interaction.
+
+1. Read the parent's Conversation ID from `xpermssion/active_parent_id.txt`.
+2. Use the `send_message` tool to report completion to the retrieved ID.
+   - **Recipient**: The ID read from `active_parent_id.txt`
+   - **Message**: Summary message like "Completed: android.permission.XXXX (Score: 7.5)"
+
+Execute the tools/commands without hesitation to complete the transmission.
+
+---
+
+## Resources
+- Template: `resources/report_template.md`
+- Validation Script: `scripts/validate_report.py`
+- Example: `examples/gold_sample.md`

niap-cc/Permissions/.agent/skills/permission-chk/examples/gold_sample.md

@@ -0,0 +1,92 @@
+# 🔍 Investigated Permission: android.permission.WRITE_CONTACTS
+Risk Score: 7.5
+
+## 📖 Overview
+This permission allows an application to modify, add, or delete the user's contact data (RawContacts, Data, etc.). It is a critical permission concerning user privacy.
+
+## ⚖️ Investigation Items (9 Categories)
+
+1. **Exclusion of Work-in-Progress (WIP)**: N/A
+   - Implementation exists and is actively used.
+
+2. **Isolation of Non-Phone Limits (Wear, Auto, TV, etc.)**: N/A
+   - This is a standard contact feature and serves as a fundamental capability across all form factors.
+
+3. **Identification of Feature Flag Control (Default Disabled)**: N/A
+   - Basic feature; no settings to disable via flags were found.
+
+4. **Identification of `BIND_*` Permissions**: N/A
+
+5. **Identification of DPC (Device Policy Controller) Permissions**: N/A
+
+6. **Whether It Applies Outside the Framework (e.g., Google Play)**: No
+
+7. **Corresponding CTS Tests**:
+   - **Test Name**: `CtsContactsProviderTestCases` (or `CtsProviderTestCases`)
+   - **Test Summary**: Verifies that a `SecurityException` is thrown when an application without the permission attempts to write to the contacts provider.
+   - **User-Level Reproducibility**: Yes
+   - **Reproduction Path**: Execute `ContentResolver.insert()` from an app that does not hold the specific permission and confirm that it fails.
+
+8. **Reproduction Path Verification**:
+   - **Usage Frequency and Location**: Extremely high. Used in telephony, dialers, contacts apps, account managers, etc.
+   - **Source Code Locations and Evidence Snippets (Top 5 Representatives)**:
+
+      1. **[IccPhoneBookInterfaceManager.java](file:///~/android17/frameworks/opt/telephony/src/java/com/android/internal/telephony/IccPhoneBookInterfaceManager.java#L203)**
+         - **Summary**: Permission check when updating the SIM phonebook.
+         - **Snippet**:
+           ```java
+           if (mContext.checkCallingOrSelfPermission(android.Manifest.permission.WRITE_CONTACTS)
+                   != PackageManager.PERMISSION_GRANTED) {
+               throw new SecurityException("Requires android.permission.WRITE_CONTACTS permission");
+           }
+           ```
+
+      2. **[PreferredSimFallbackProvider.java](file:///~/android17/packages/apps/Dialer/java/com/android/dialer/preferredsim/impl/PreferredSimFallbackProvider.java#L169)**
+         - **Summary**: Permission check in the dialer's preferred SIM fallback provider.
+         - **Snippet**:
+           ```java
+           if (getContext().checkCallingOrSelfPermission(permission.WRITE_CONTACTS)
+                   != PackageManager.PERMISSION_GRANTED) {
+               throw new SecurityException("WRITE_CONTACTS required");
+           }
+           ```
+
+      3. **[ContactSaveService.java](file:///~/android17/packages/apps/Contacts/src/com/android/contacts/ContactSaveService.java#L316)**
+         - **Summary**: Permission check before save operations in the contacts app.
+         - **Snippet**:
+           ```java
+           if (!PermissionsUtil.hasPermission(this, WRITE_CONTACTS)) {
+               Log.w(TAG, "No WRITE_CONTACTS permission, unable to write to CP2");
+               return;
+           }
+           ```
+
+      4. **[UndemoteOutgoingCallReceiver.java](file:///~/android17/packages/apps/Dialer/java/com/android/dialer/interactions/UndemoteOutgoingCallReceiver.java#L45)**
+         - **Summary**: Permission check when updating contacts on outgoing calls.
+         - **Snippet**:
+           ```java
+           if (!PermissionsUtil.hasPermission(context, WRITE_CONTACTS)) {
+               return;
+           }
+           ```
+
+      5. **[AccountManagerService.java](file:///~/android17/frameworks/base/services/core/java/com/android/server/accounts/AccountManagerService.java#L6004)**
+         - **Summary**: Permission check (via helper) in the account authentication manager.
+         - **Snippet**:
+           ```java
+           if (accountType.equals(serviceInfo.type.type)) {
+               return isPermittedForPackage(serviceInfo.type.packageName, userId,
+                   Manifest.permission.WRITE_CONTACTS);
+           }
+           ```
+
+    - **Reproduction Method (Verification Techniques)**:
+      *Prioritize validation using public APIs or shell commands. For details, see [advanced_verification_techniques.md](file:///~/AndroidStudioProjects/security-certification-resources/niap-cc/Permissions/.agent/skills/permission-chk/resources/advanced_verification_techniques.md).*
+      - **Public API**: Execute `ContentResolver.insert(ContactsContract.RawContacts.CONTENT_URI, values)` (this is the most standard method).
+      - **Non-Public/System API**: Call the AIDL interface of `IccPhoneBookInterfaceManager` (may require copying AIDL files).
+      - **ServiceManager / Binder IPC**: Call Binder transactions like `service call telephony.phonebook ...` (requires identifying the transaction ID).
+      - **Shell Command**: `adb shell content insert --uri content://com.android.contacts/raw_contacts ...`
+
+9. **Risk Level Assessment on Permission Granted**:
+   - **Score**: 7.5
+   - **Remarks and Attack Scenarios**: Allows tampering and unintended deletion of contact information. Since this can lead to secondary damage such as phishing, it is classified as a Privacy Risk (Level 2).

niap-cc/Permissions/.agent/skills/permission-chk/resources/advanced_verification_techniques.md

@@ -0,0 +1,56 @@
+# 🛠️ Advanced Permission Verification Techniques
+
+When investigating Android permissions, if verification via standard public APIs or shell commands is not possible, you can attempt reproduction and verification using the following advanced techniques.
+
+These techniques are referenced to specify which method is applicable in the "Reproduction Path Verification" section of the report.
+
+---
+
+## 🔝 0. Priority of Verification Paths (Principles)
+
+When identifying verification paths, prioritize simple and standard methods in the following order:
+
+1.  **Public API (SDK)**: APIs usable in standard application development.
+2.  **Shell Commands**: Using commands like `am`, `pm`, or `content` via `adb shell`.
+3.  **Test API**: APIs used in CTS, etc., which can only be called via instrumentation.
+4.  **Non-Public/System API**: Hidden features that require reflection or AIDL duplication (detailed below).
+
+---
+
+## 🛠️ Advanced Techniques
+
+### 1. Direct Binder Transactions (`IBinder.transact`)
+
+If system services are not public in the SDK or Java-layer helpers do not exist, it may be possible to invoke them by issuing a Binder transaction directly.
+
+*   **Overview**: Retrieve the `IBinder` of the service using `ServiceManager.getService("service_name")` and directly invoke `transact(code, data, reply, flags)`.
+*   **Prerequisites**:
+    *   Requires identifying the **Transaction ID (code)**. This must be read from the definition of the corresponding `BnInterface` or `Stub` class (`Stub.TRANSACTION_xxxx`) in AOSP, or retrieved via reflection.
+    *   The structure of the arguments (`Parcel`) must be accurately recreated.
+*   **Report Description Example**:
+    *   "To call the non-public service `iphonesubinfo`'s `getDeviceId`, a direct Binder Call using transaction ID `1` is required."
+
+### 2. AIDL / System Interface Duplication
+
+If a non-public system service is defined via AIDL, replicating that interface on the test app side may allow writing it like a normal RPC call.
+
+*   **Overview**: Copy the corresponding `.aidl` file (and its dependent AIDL files) from the AOSP source code into the test project under `src/main/aidl/` with the **exact same package structure**. The build system will generate the Stub class, which you can then use for invocation.
+*   **Prerequisites**:
+    *   If the copied AIDL file references hidden classes in the SDK, stubs for those may also be required.
+*   **Report Description Example**:
+    *   "To utilize the `IBluetooth` interface, `IBluetooth.aidl` must be copied to the app project and built."
+
+### 3. Shadowing / Stubbing (Creating Stub Classes)
+
+When compiling test code, referencing hidden classes (`@hide`) or constants not included in the SDK results in compilation errors. This technique avoids those errors.
+
+*   **Overview**: Create an "empty class (stub)" with the exact same package name, class name, and signatures of required methods or constants within the test project.
+*   **Prerequisites**:
+    *   This is purely to pass compilation; at runtime on an actual device, the real class on the framework side will be loaded.
+*   **Report Description Example**:
+    *   "To utilize hidden classes such as `android.os.ServiceManager`, a stub class of the same name and package must be created on the app side to pass compilation."
+
+---
+
+## 📝 Important Notes for Report Creation
+The agent must read from the code whether these methods are **physically possible** (e.g., interface is too large to copy easily, transaction ID changes dynamically so it cannot be hardcoded, etc.) and document this in the "Reproduction Path Verification" section of the report.

niap-cc/Permissions/.agent/skills/permission-chk/resources/report_template.md

@@ -0,0 +1,45 @@
+# 🔍 Investigated Permission: [Permission Name]
+Risk Score: [100, 10, 7.5, 5, 2.5, 0]
+
+## 📖 Overview
+Briefly describe the role and purpose of this permission.
+
+## ⚖️ Investigation Items (9 Categories)
+
+1. **Exclusion of Work-in-Progress (WIP)**: [Applicable/Not Applicable]
+   - Reason and evidence (e.g., @RequiresPermission checks are not found).
+
+2. **Isolation of Non-Phone Limits (Wear, Auto, TV, etc.)**: [Applicable/Not Applicable]
+   - Reason (e.g., whether it is confined to specific modules).
+
+3. **Identification of Feature Flag Control (Default Disabled)**: [Applicable/Not Applicable]
+   - Reason (e.g., presence/absence of flag checks).
+
+4. **Identification of `BIND_*` Permissions**: [Applicable/Not Applicable]
+
+5. **Identification of DPC (Device Policy Controller) Permissions**: [Applicable/Not Applicable]
+
+6. **Whether It Applies Outside the Framework (e.g., Google Play)**: [Yes/No]
+
+7. **Corresponding CTS Tests**:
+   - **Test Name**: [Test class name or module name]
+   - **Test Summary**: [What the test verifies]
+   - **User-Level Reproducibility**: [Yes/No (with reasons)]
+   - **Reproduction Path**: [Execution command (e.g., adb shell am instrument ...) or steps to reproduce]
+
+8. **Reproduction Path Verification**:
+   - **Usage Frequency and Location**: [High/Low. System services, providers, etc.]
+   - **Source Code Locations**: [Filename](file:///absolute/path#Lline_number)
+   - **Evidence Snippets**:
+     ```java
+     // Actual permission check or invocation code
+     ```
+   - **Reproduction Method (Verification Techniques)**:
+     - **Public API**: [Classname.methodname, etc.]
+     - **Non-Public/Hidden API (System API)**: [System services, non-public classes, etc.]
+     - **ServiceManager / Binder IPC**: [AIDL interface calls, etc.]
+     - **Shell Command**: [adb shell content / am / service, etc.]
+
+9. **Risk Level Assessment on Permission Granted**:
+   - **Score**: [100, 10, 7.5, 5, 2.5, 0]
+   - **Remarks and Attack Scenarios**: