Title: Consider setting dev.tty.ldisc_autoload=0 by default
Body:
Similar in spirit to #9194/#9288 — another Arch default that's a known, low-risk kernel hardening win Omarchy doesn't currently apply.
dev.tty.ldisc_autoload controls whether unprivileged processes can force the kernel to cold-load a TTY line-discipline module on demand, via the TIOCSETD ioctl. Arch ships this as 1 (CONFIG_LDISC_AUTOLOAD=y), so it's on by default on a fresh Omarchy install too.
This has a real history as a local-privilege-escalation surface: rarely-used, rarely-audited line-discipline modules have shipped real CVEs (e.g. n_hdlc / CVE-2017-2636, n_gsm / CVE-2023-6546). The kernel added this sysctl specifically so admins could close that path; KSPP (Kernel Self Protection Project) lists dev.tty.ldisc_autoload=0 in its Recommended Settings with no caveats.
I confirmed this is exploitable on a stock Omarchy 4.0.1 install: as a normal unprivileged user with no special capabilities, a TIOCSETD ioctl on /dev/ptmx forced the kernel to load a module (pps_ldisc, chosen as a benign test target) that wasn't previously resident. CONFIG_N_HDLC=m is present on this kernel, meaning the CVE-2017-2636 module is reachable through the same primitive.
Setting it to 0 only blocks the unprivileged, on-demand loading path — root/systemd/udev module loading at boot is unaffected (verified in drivers/tty/tty_ldisc.c: the check is gated behind !capable(CAP_SYS_MODULE)), so tools like btattach/ldattach/pppd (which run as root) keep working normally.
One honest caveat: a daemon that drops root privileges and then tries to attach a line discipline (the classic example is gpsd doing PPS timing via pps_ldisc) would break. The workaround is trivial — pre-load the needed module once via /etc/modules-load.d/, after which unprivileged TIOCSETD for that already-loaded module succeeds normally. Not a reason to hold this back, just worth knowing.
Proposed change, same shape as #9288:
etc/sysctl.d/99-omarchy-sysctl.conf:
# Stop unprivileged processes from autoloading obscure TTY line-discipline
# modules via TIOCSETD, a recurring local privilege-escalation surface
# (n_hdlc/CVE-2017-2636, n_gsm/CVE-2023-6546). Root, systemd and udev still
# autoload normally, so btattach/ldattach/pppd are unaffected.
dev.tty.ldisc_autoload=0
Plus a migration (matching the 1788139000.sh pattern from #9288) so existing installs get the runtime value applied immediately rather than waiting for reboot.
Note on sequencing: #9288 is still open and touches the same file/region, so whichever of these two lands second will need a small rebase — flagging so it doesn't cause merge friction.
Happy to open a PR for this if useful, similar to how #9288 was done for the kptr_restrict issue.
System info: Omarchy 4.0.1 (BUILD_ID 4.0.1), kernel 7.1.9-arch1-2
Title: Consider setting dev.tty.ldisc_autoload=0 by default
Body:
Similar in spirit to #9194/#9288 — another Arch default that's a known, low-risk kernel hardening win Omarchy doesn't currently apply.
dev.tty.ldisc_autoloadcontrols whether unprivileged processes can force the kernel to cold-load a TTY line-discipline module on demand, via theTIOCSETDioctl. Arch ships this as1(CONFIG_LDISC_AUTOLOAD=y), so it's on by default on a fresh Omarchy install too.This has a real history as a local-privilege-escalation surface: rarely-used, rarely-audited line-discipline modules have shipped real CVEs (e.g.
n_hdlc/ CVE-2017-2636,n_gsm/ CVE-2023-6546). The kernel added this sysctl specifically so admins could close that path; KSPP (Kernel Self Protection Project) listsdev.tty.ldisc_autoload=0in its Recommended Settings with no caveats.I confirmed this is exploitable on a stock Omarchy 4.0.1 install: as a normal unprivileged user with no special capabilities, a
TIOCSETDioctl on/dev/ptmxforced the kernel to load a module (pps_ldisc, chosen as a benign test target) that wasn't previously resident.CONFIG_N_HDLC=mis present on this kernel, meaning the CVE-2017-2636 module is reachable through the same primitive.Setting it to
0only blocks the unprivileged, on-demand loading path — root/systemd/udev module loading at boot is unaffected (verified indrivers/tty/tty_ldisc.c: the check is gated behind!capable(CAP_SYS_MODULE)), so tools likebtattach/ldattach/pppd(which run as root) keep working normally.One honest caveat: a daemon that drops root privileges and then tries to attach a line discipline (the classic example is
gpsddoing PPS timing viapps_ldisc) would break. The workaround is trivial — pre-load the needed module once via/etc/modules-load.d/, after which unprivilegedTIOCSETDfor that already-loaded module succeeds normally. Not a reason to hold this back, just worth knowing.Proposed change, same shape as #9288:
etc/sysctl.d/99-omarchy-sysctl.conf:Plus a migration (matching the
1788139000.shpattern from #9288) so existing installs get the runtime value applied immediately rather than waiting for reboot.Note on sequencing: #9288 is still open and touches the same file/region, so whichever of these two lands second will need a small rebase — flagging so it doesn't cause merge friction.
Happy to open a PR for this if useful, similar to how #9288 was done for the kptr_restrict issue.
System info: Omarchy 4.0.1 (BUILD_ID 4.0.1), kernel 7.1.9-arch1-2