| Message ID | 20240725054216.18587-1-laoar.shao@gmail.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | security/tomoyo: Prevent message flooding if no Tomoyo loader is present | expand |
Hello. On 2024/07/25 14:42, Yafang Shao wrote: > After upgrading our OS to Rocky Linux 9, we've noticed an abundance of > Tomoyo-related messages in the dmesg output, specifically indicating that > Mandatory Access Control is not being activated due to the absence of > /sbin/tomoyo-init. These messages repeatedly appear as systemd periodically > checks for Tomoyo, but since the loader does not exist, it triggers the > messages, as follows, TOMOYO requires zero modification of userspace programs (including systemd). That is, systemd is not checking for TOMOYO periodically. It is some other program that is executing /usr/lib/systemd/systemd (maybe as a container's init program), and TOMOYO is checking for /sbin/tomoyo-init when /usr/lib/systemd/systemd is executed. > While disabling Tomoyo is a straightforward solution to prevent the message > flooding, it's suboptimal as we're unsure if any system components rely on > its functionality. No userspace programs rely on TOMOYO's functionality (except TOMOYO's management tools including /sbin/tomoyo-init ). It is safe to disable TOMOYO. > A more elegant approach would be to modify the logging > mechanism to use pr_info_once() instead of the default one, which would > reduce the number of redundant messages without compromising the > functionality of the system. This change would ensure that the necessary > information is logged once, preventing the dmesg from being cluttered > with repetitive messages. The message your patch tries to limit typically appears when /usr/lib/systemd/systemd is executed from initramfs, for /sbin/tomoyo-init is installed inside the / filesystem which will be mounted by initramfs, and /sbin/tomoyo-init becomes ready to execute when initramfs transfers its execution to /usr/lib/systemd/systemd within the / filesystem. Therefore, this message is intended as a debug message that tells administrators that you might have forgotten to install TOMOYO's management tools. I didn't expect that administrators enable TOMOYO without installing TOMOYO's management tools. > Signed-off-by: Yafang Shao <laoar.shao@gmail.com> Thank you for a patch. But so far I don't think we need this change.
On Thu, Jul 25, 2024 at 2:34 PM Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote: > > Hello. > > On 2024/07/25 14:42, Yafang Shao wrote: > > After upgrading our OS to Rocky Linux 9, we've noticed an abundance of > > Tomoyo-related messages in the dmesg output, specifically indicating that > > Mandatory Access Control is not being activated due to the absence of > > /sbin/tomoyo-init. These messages repeatedly appear as systemd periodically > > checks for Tomoyo, but since the loader does not exist, it triggers the > > messages, as follows, > > TOMOYO requires zero modification of userspace programs (including systemd). > That is, systemd is not checking for TOMOYO periodically. It is some other > program that is executing /usr/lib/systemd/systemd (maybe as a container's > init program), and TOMOYO is checking for /sbin/tomoyo-init when > /usr/lib/systemd/systemd is executed. > > > While disabling Tomoyo is a straightforward solution to prevent the message > > flooding, it's suboptimal as we're unsure if any system components rely on > > its functionality. > > No userspace programs rely on TOMOYO's functionality (except TOMOYO's management > tools including /sbin/tomoyo-init ). It is safe to disable TOMOYO. Thanks for your explanation. I will disable it.
diff --git a/security/tomoyo/load_policy.c b/security/tomoyo/load_policy.c index 363b65be87ab..4e64b5678abf 100644 --- a/security/tomoyo/load_policy.c +++ b/security/tomoyo/load_policy.c @@ -41,8 +41,8 @@ static bool tomoyo_policy_loader_exists(void) if (!tomoyo_loader) tomoyo_loader = CONFIG_SECURITY_TOMOYO_POLICY_LOADER; if (kern_path(tomoyo_loader, LOOKUP_FOLLOW, &path)) { - pr_info("Not activating Mandatory Access Control as %s does not exist.\n", - tomoyo_loader); + pr_info_once("Not activating Mandatory Access Control as %s does not exist.\n", + tomoyo_loader); return false; } path_put(&path);
After upgrading our OS to Rocky Linux 9, we've noticed an abundance of Tomoyo-related messages in the dmesg output, specifically indicating that Mandatory Access Control is not being activated due to the absence of /sbin/tomoyo-init. These messages repeatedly appear as systemd periodically checks for Tomoyo, but since the loader does not exist, it triggers the messages, as follows, [2362655.988555] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist. [2362956.054826] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist. [2363256.123963] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist. [2363556.176985] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist. [2363856.239882] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist. [2364041.613547] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist. [2364155.298170] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist. [2364455.361375] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist. [2364755.411385] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist. [2364816.253043] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist. The tomoyo configs in our kernel config are as follows, CONFIG_SECURITY_TOMOYO=y CONFIG_SECURITY_TOMOYO_MAX_ACCEPT_ENTRY=2048 CONFIG_SECURITY_TOMOYO_MAX_AUDIT_LOG=1024 # CONFIG_SECURITY_TOMOYO_OMIT_USERSPACE_LOADER is not set CONFIG_SECURITY_TOMOYO_POLICY_LOADER="/sbin/tomoyo-init" CONFIG_SECURITY_TOMOYO_ACTIVATION_TRIGGER="/usr/lib/systemd/systemd" # CONFIG_SECURITY_TOMOYO_INSECURE_BUILTIN_SETTING is not set While disabling Tomoyo is a straightforward solution to prevent the message flooding, it's suboptimal as we're unsure if any system components rely on its functionality. A more elegant approach would be to modify the logging mechanism to use pr_info_once() instead of the default one, which would reduce the number of redundant messages without compromising the functionality of the system. This change would ensure that the necessary information is logged once, preventing the dmesg from being cluttered with repetitive messages. Signed-off-by: Yafang Shao <laoar.shao@gmail.com> --- security/tomoyo/load_policy.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)