linux-kernel - suggestions for capability checks in ldisc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <7483af43.c3b3.18ccd1a862a.Coremail.mengjingzi@iie.ac.cn>
Date: Wed, 3 Jan 2024 10:15:16 +0800 (GMT+08:00)
From: 孟敬姿 <mengjingzi@....ac.cn>
To: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, 
	pabeni@...hat.com
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: suggestions for capability checks in ldisc_open()

Hi! 

During our code review, we may have observed an inappropriate capability check in the ldisc_open() function. Currently, both CAP_SYS_ADMIN and CAP_SYS_TTY_CONFIG are checked at the entry point. We propose reconsidering using CAP_SYS_TTY_CONFIG alone for tty-related operations and adding a CAP_NET_ADMIN check for network-related operations. Here's our rationale for this suggestion:

(1) Functionality Under Protection: The privileged functions following the capability checks primarily involve tty operations, and according to the capability manual page[1], CAP_SYS_TTY_CONFIG is a more fitting capability(CAP_SYS_TTY_CONFIG: employ various privileged operations on virtual terminals).

(2) Caution with CAP_SYS_ADMIN: Developers tend to assume that CAP_SYS_ADMIN contains other capabilities, which may be the reason for the two capabilities examined here. But according to capability manual page[1], “Linux divides superuser into distinct units”, capabilities should be independent of each other. CAP_SYS_ASMIN is already overloaded and known as the new "root"[2], the manual page[1] also clearly states, “Don't choose CAP_SYS_ADMIN if you can possibly avoid it!”. Using a more specific capability helps to achieve least privilege.

(3) Network-Related Operations: ldisc_open() also engages in network-related functions, such as alloc_netdev(), netdev_priv(), and register_netdevice(). In similar scenarios, these network functions are typically protected by CAP_NET_ADMIN, for example in mkiss_open(). This consistency across the kernel can help maintain clarity and standardization.

This issue exists in several kernel versions and we have checked it on the latest stable release(Linux 6.6.9). 

Your insights and feedback on this proposed modification would be highly valuable. Thank you for your time and consideration.

Best regards,
Jingzi

reference:
[1] https://www.man7.org/linux/man-pages/man7/capabilities.7.html
[2] https://lwn.net/Articles/486306/