Add a capability LSM module and route capability checks through the security stack

[zzj-5341]

Summary

This draft PR builds on top of the initial LSM framework and Yama migration and introduces capability authorization into the LSM stack.

The main goal is to stop open-coding capability checks across subsystems and instead route them through the security facade and the built-in LSM dispatch path.

After this change, the built-in LSM stack becomes:

• capability as the major authorization module
• yama as a minor ptrace restriction module

What this PR changes

Add a built-in capability LSM module

This PR introduces a dedicated capability module under kernel/src/security/lsm/modules/capability.rs.

The module provides capability-based authorization through the LSM framework instead of keeping the logic scattered across subsystem-local checks.

Extend the LSM framework for capability authorization

This PR expands the current framework with the hook surface needed by capability migration, including:

• capable
• bprm_check_security
• bprm_committed_creds
• inode_permission
• file_open
• inode_dac_override

It also adds the supporting context types and CapabilityReason so capability checks carry explicit semantic intent through the security layer.

Route capability checks through the security facade

This PR migrates several existing authorization paths to the LSM-backed capability interface, including:

• credential-changing paths
• ptrace and alien access integration
• namespace-related checks
• signal permission checks
• resource limit checks
• reboot authorization
• socket privilege checks
• capset
• trusted xattr access
• inode DAC override
• post-execve committed-creds hook plumbing

Update security regression coverage

This PR updates the security regression entry so capability-related tests run through the new LSM-based path.

Why

The initial LSM framework PR establishes the dispatch structure and migrates one narrow policy module, Yama.

This follow-up moves capability authorization into that same structure, which makes the security model more coherent:

• subsystem code describes security-sensitive operations through a common facade
• authorization decisions flow through one framework
• major and minor security modules can evolve within one stack instead of mixing framework and policy logic in unrelated subsystems

Validation

Validated in:

• /home/zzj/asterinas-cap-lsm-upstream-stacked
• branch: codex/capability-after-lsm-yama

Commands used:

source ~/.cargo/env
export VDSO_LIBRARY_DIR=$HOME/linux_vdso
git diff --check origin/lsm-framework-yama..HEAD
make run_kernel AUTO_TEST=test CONSOLE=hvc0

Result:

All general tests passed.

Scope of this draft

This draft intentionally focuses on:

• extending the LSM hook surface for capability authorization
• adding the capability module
• migrating capability call sites onto the LSM-backed security path
• updating the necessary security regression entry points

It intentionally does not include design documents or boot-only helper programs.

Follow-up work

• clean up newly introduced warnings
• decide whether boot-only capability regression helpers should land in this PR or separately
• further refine capability handling as user namespace support evolves
• decide whether more hooks should consume CapabilityReason more deeply