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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4b5ac92c.1086b.18ce7c58a95.Coremail.mengjingzi@iie.ac.cn>
Date: Mon, 8 Jan 2024 14:32:12 +0800 (GMT+08:00)
From: 孟敬姿 <mengjingzi@....ac.cn>
To: "Theodore Ts'o" <tytso@....edu>
Cc: gregkh@...uxfoundation.org, gpiccoli@...lia.com, 
	john.ogness@...utronix.de, keescook@...omium.org, 
	linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org, 
	pmladek@...e.com, rostedt@...dmis.org, senozhatsky@...omium.org, 
	tony.luck@...el.com
Subject: Re: [PATCH] cap_syslog: remove CAP_SYS_ADMIN when dmesg_restrict


On Fri 2024-01-05 09:49:44, Theodore Ts'o wrote:
&gt; It's unclear to me what goal you have in trying to mess with the
&gt; capability definitions?  Perhaps it might be useful if you were to
&gt; explicitly state your goals in these proposals?

Petr is right, we are trying to resolve the overlap problem of capability. 

Capability is about to separate superuser privileges into distinct units for 
finer-grained access control. It’s effective work requires the kernel to use 
proper capability for sensitive resources and the user programs to choose the 
right capability instead of ROOT to execute. And we want to promote the 
standardized use of capability.


&gt; So there isn't all that much upside in trying to retire CAP_SYS_ADMIN 

We are not going to retire CAP_SYS_ADMIN, but saying that CAP_SYSLOG is the
more appropriate capability when it comes to protecting syslog functionality. 
CAP_SYS_ADMIN is already overloaded, check out the link[1], narrowing down its 
definitions will facilitate the implementation of least privilege. This adjustment 
makes it clearer for a user program requiring syslog access to specify only the 
necessary capability, CAP_SYSLOG, instead of relying on the broader CAP_SYS_ADMIN.

&gt; What testing have you done to make sure that this is OK?

We booted the modified kernel and confirmed that CAP_SYS_ADMIN no longer has access 
to syslog when dmesg is set.

While certain user programs relying on CAP_SYS_ADMIN for syslog access might be impacted, 
they can adjust their capability configuration using the ‘setcap’ command. Decreasing the 
reliance on CAP_SYS_ADMIN across applications contributes to minimizing security risks in 
the system. Currently, it's uncertain if any such programs exist.


Best regrads,
Jingzi

[1]: https://lwn.net/Articles/486306/


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ