Amazon Linux 2027 已进入公开预览。根据公告摘要，它基于 AL2023，采用 Linux 7.1 内核，并将 SELinux 默认设置为 enforcing（强制执行）模式。对开发团队来说，最值得提前验证的不是版本号，而是一个实际变化：在 AL2023 permissive 模式下能运行的应用，到了 enforcing 模式下可能失败。

这不是“升级后再修几个配置”的小问题。部署目录、文件标签、服务访问路径，都可能成为迁移测试的一部分。

permissive 能跑，不代表 enforcing 能过

SELinux 在传统 Unix 权限之外增加了一层访问控制。文件的属主、属组和权限位都正确，并不意味着进程一定能访问它。

两种模式的区别直接影响兼容性：

• Permissive：记录策略违规，但通常不阻止相关操作。
• Enforcing：执行策略限制，违规操作会被拒绝。

因此，“应用在旧环境通过测试”只能说明它在那里能够运行，不能证明它符合新环境的 SELinux 策略。自定义部署目录、服务读取非标准路径下的文件，以及写入缓存或上传目录，都是可以优先检查的场景；这些是实践建议，不是公告列出的已知问题。

还要注意：遇到 Permission denied 时，不要立刻认定是 SELinux。普通文件权限、挂载选项和服务自身配置，也可能导致同样的错误。

在预览实例上建立一条可复现的排查链

可以这样实践：创建隔离的 Amazon Linux 2027 预览实例，部署与当前生产环境相同的应用，然后执行启动、健康检查和关键读写流程。不要直接把生产主机当作试验场。

下面的命令用于检查模式和审计记录。假设系统已有 getenforce、sestatus 和 ausearch，且当前账号可以使用 sudo；若命令不存在，应先按预览版本的软件包文档安装对应工具。

# 1. 确认当前 SELinux 模式及状态
getenforce
sestatus

# 2. 手动复现应用启动或请求失败后，检查最近的拒绝记录
sudo ausearch -m AVC,USER_AVC -ts recent -i

AVC 记录可以帮助定位被拒绝的操作。排查时，把记录时间与应用日志对齐，重点看：

• 哪个进程发起了访问；
• 访问的是哪个文件或其他资源；
• 被拒绝的是读取、写入、执行，还是其他操作；
• 进程和目标资源分别带有什么 SELinux 上下文。

没有查询到记录，也不能立即排除 SELinux：还需要确认审计配置、日志时间范围，以及是否真正复现了失败。

如果怀疑部署文件的标签不正确，可以先查看上下文，再预览恢复默认标签的影响。运行前，将示例路径替换为真实应用目录：

APP_DIR=/opt/myapp

# 查看目录及其内容的 SELinux 上下文
ls -ldZ "$APP_DIR"
ls -lZ "$APP_DIR"

# 仅预览哪些标签会被调整，不修改文件
sudo restorecon -nRv "$APP_DIR"

这里的 -n 很重要：它让检查保持为预演。restorecon 依据已有标签规则工作；如果应用使用自定义路径，恢复默认标签不一定能得到服务需要的类型。

修复策略，不要把关闭 SELinux 当成迁移方案

发现拒绝记录后，应先区分原因：文件标签错误、部署路径不符合服务策略，还是应用确实需要额外权限。

可以采用这样的处理顺序：

1. 检查普通文件权限和服务配置，避免误判。
2. 对照 SELinux 拒绝记录确认具体访问行为。
3. 优先修正部署路径、文件标签或已有策略配置。
4. 确有必要时，再评估范围最小的自定义策略。

不要把所有审计记录直接转换成允许规则。日志可能包含错误配置触发的访问，也可能包含应用根本不应拥有的权限。自动放行会让“程序终于能跑”掩盖新的安全问题。

同样，切换到 permissive 可以作为受控测试中的对比手段，但不应成为正式迁移的默认答案。否则，新版本默认 enforcing 带来的安全边界也就被撤掉了。

现在适合验证，不适合押注迁移时间表

公告没有给出 AL2023 的支持结束日期、Amazon Linux 2027 的正式发布日期，也没有公布原地迁移路径。这意味着不能仅凭公开预览，就推导出生产升级窗口或原地升级方案。

更稳妥的准备方式是：

• 用独立预览实例验证应用和部署脚本；
• 在 enforcing 模式下覆盖启动、读写和异常恢复流程；
• 把必要的标签或策略调整纳入版本控制；
• 保留当前环境，并验证流量切回流程；
• 等正式发布、支持周期和迁移说明明确后，再安排生产切换。

这次预览最有价值的用途，是把过去 permissive 模式下隐藏的策略问题提前暴露出来。越早在测试环境修复，越少在生产切换时靠临时放宽权限救火。

English version

Amazon Linux 2027 Preview: Prepare for SELinux Enforcement Before You Migrate

Amazon Linux 2027 has entered public preview. According to the announcement summary, it builds on AL2023, uses Linux kernel 7.1, and enables SELinux enforcing mode by default. For application teams, the important change is not the version number: software that runs under AL2023’s permissive mode may fail when SELinux starts enforcing policy.

That makes deployment paths, file labels, and service access patterns part of migration testing—not merely post-upgrade cleanup.

Running in permissive mode is not a policy compatibility test

SELinux adds access controls beyond traditional Unix ownership and permission bits. A process can be denied access even when the file’s owner, group, and mode appear correct.

The two modes behave differently:

• Permissive records policy violations but generally allows the operations to proceed.
• Enforcing applies policy restrictions and blocks disallowed operations.

Passing tests in the old environment therefore does not establish compatibility with the new SELinux policy. Custom installation directories, services reading files outside standard locations, and writable cache or upload directories are sensible places to start testing. These are practical examples, not problems specifically identified in the announcement.

Also, do not assume every Permission denied message comes from SELinux. Ordinary file permissions, mount options, and application configuration can produce similar symptoms.

Build a repeatable investigation on a preview instance

A practical approach is to deploy your existing application on an isolated Amazon Linux 2027 preview instance, then exercise startup, health checks, and important read/write operations. Keep production hosts out of the experiment.

The following commands check SELinux status and audit records. They assume getenforce, sestatus, and ausearch are installed and that your account can use sudo. If a command is missing, consult the preview release’s package documentation before installing the relevant tools.

# 1. Check the current SELinux mode and status
getenforce
sestatus

# 2. Reproduce the application failure, then inspect recent denials
sudo ausearch -m AVC,USER_AVC -ts recent -i

AVC records help identify denied operations. Correlate their timestamps with application logs and check:

• Which process attempted access;
• Which file or other resource it accessed;
• Whether the denied operation was a read, write, execution, or something else;
• The SELinux contexts of both the process and the target resource.

An empty result does not immediately rule out SELinux. Verify the audit setup, the query’s time range, and whether you actually reproduced the failure.

If incorrect file labels are a possible cause, inspect the contexts and preview what restoring default labels would change. Replace the example path with your actual application directory before running:

APP_DIR=/opt/myapp

# Inspect SELinux contexts on the directory and its contents
ls -ldZ "$APP_DIR"
ls -lZ "$APP_DIR"

# Preview label changes without modifying files
sudo restorecon -nRv "$APP_DIR"

The -n option keeps this a dry run. restorecon follows existing labeling rules; for a custom application path, restoring the default label may not assign the type your service needs.

Fix the access model instead of disabling enforcement

After finding a denial, determine whether it comes from an incorrect label, an unsuitable deployment path, or a genuine requirement for additional permissions.

A useful sequence is:

1. Check ordinary permissions and service configuration.
2. Confirm the specific operation in the SELinux denial record.
3. Prefer correcting deployment paths, labels, or existing policy settings.
4. Consider a narrowly scoped custom policy only when necessary.

Do not turn every audit record into an allow rule. Logs can include access caused by misconfiguration or permissions the application should never receive. Automatically allowing everything can replace a visible failure with an invisible security problem.

Temporarily using permissive mode may help with controlled comparison testing, but it should not become the default migration solution. Doing so removes the security boundary that the new enforcing default is intended to provide.

Validate now; wait for a concrete production migration plan

The announcement provides no AL2023 end-of-support date, no Amazon Linux 2027 general availability date, and no announced in-place migration path. Public preview alone is not enough to establish a production upgrade deadline or an in-place upgrade procedure.

For now:

• Validate applications and deployment scripts on separate preview instances.
• Test startup, read/write operations, and recovery with enforcement enabled.
• Keep required labeling and policy changes under version control.
• Preserve the existing environment and test switching traffic back.
• Schedule production migration after release, support, and migration guidance become clear.

The preview is an opportunity to uncover policy issues that permissive mode previously concealed. Resolve them in testing rather than relaxing permissions under pressure during a production cutover.

English SEO description

Amazon Linux 2027 enters public preview with SELinux enforcing by default. Learn how to test applications, inspect denials, and prepare for migration.