kernel/linux.git/security/tomoyo/common.c, branch v6.19.12

tomoyo: use better patterns for procfs in learning mode

2025-01-30T15:27:44+00:00

Commit 08ae2487b202 ("tomoyo: automatically use patterns for several situations in learning mode") replaced only $PID part of procfs pathname with \$ pattern. But it turned out that we need to also replace $TID part and $FD part to make this functionality useful for e.g. /bin/lsof . Signed-off-by: Tetsuo Handa

tomoyo: automatically use patterns for several situations in learning mode

2025-01-06T12:25:00+00:00

The "file_pattern" keyword was used for automatically recording patternized pathnames when using the learning mode. This keyword was removed in TOMOYO 2.4 because it is impossible to predefine all possible pathname patterns. However, since the numeric part of proc:/$PID/ , pipe:[$INO] and socket:[$INO] has no meaning except $PID == 1, automatically replacing the numeric part with \$ pattern helps reducing frequency of restarting the learning mode due to hitting the quota. Since replacing one digit with \$ pattern requires enlarging string buffer, and several programs access only $PID == 1, replace only two or more digits with \$ pattern. Signed-off-by: Tetsuo Handa

tomoyo: don't emit warning in tomoyo_write_control()

2024-12-16T10:41:29+00:00

syzbot is reporting too large allocation warning at tomoyo_write_control(), for one can write a very very long line without new line character. To fix this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE, for practically a valid line should be always shorter than 32KB where the "too small to fail" memory-allocation rule applies. One might try to write a valid line that is longer than 32KB, but such request will likely fail with -ENOMEM. Therefore, I feel that separately returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant. There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE. Reported-by: syzbot+7536f77535e5210a5c76@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7536f77535e5210a5c76 Reported-by: Leo Stone Closes: https://lkml.kernel.org/r/20241216021459.178759-2-leocstone@gmail.com Signed-off-by: Tetsuo Handa

tomoyo: revert CONFIG_SECURITY_TOMOYO_LKM support

2024-10-04T15:41:22+00:00

This patch reverts two TOMOYO patches that were merged into Linus' tree during the v6.12 merge window: 8b985bbfabbe ("tomoyo: allow building as a loadable LSM module") 268225a1de1a ("tomoyo: preparation step for building as a loadable LSM module") Together these two patches introduced the CONFIG_SECURITY_TOMOYO_LKM Kconfig build option which enabled a TOMOYO specific dynamic LSM loading mechanism (see the original commits for more details). Unfortunately, this approach was widely rejected by the LSM community as well as some members of the general kernel community. Objections included concerns over setting a bad precedent regarding individual LSMs managing their LSM callback registrations as well as general kernel symbol exporting practices. With little to no support for the CONFIG_SECURITY_TOMOYO_LKM approach outside of Tetsuo, and multiple objections, we need to revert these changes. Link: https://lore.kernel.org/all/0c4b443a-9c72-4800-97e8-a3816b6a9ae2@I-love.SAKURA.ne.jp Link: https://lore.kernel.org/all/CAHC9VhR=QjdoHG3wJgHFJkKYBg7vkQH2MpffgVzQ0tAByo_wRg@mail.gmail.com Acked-by: John Johansen Signed-off-by: Paul Moore

tomoyo: allow building as a loadable LSM module

2024-09-24T13:35:30+00:00

One of concerns for enabling TOMOYO in prebuilt kernels is that distributor wants to avoid bloating kernel packages. Although boot-time kernel command line options allows selecting built-in LSMs to enable, file size increase of vmlinux and memory footprint increase of vmlinux caused by builtin-but- not-enabled LSMs remains. If it becomes possible to make LSMs dynamically appendable after boot using loadable kernel modules, these problems will go away. Another of concerns for enabling TOMOYO in prebuilt kernels is that who can provide support when distributor cannot provide support. Due to "those who compiled kernel code is expected to provide support for that kernel code" spell, TOMOYO is failing to get enabled in Fedora distribution [1]. The point of loadable kernel module is to share the workload. If it becomes possible to make LSMs dynamically appendable after boot using loadable kernel modules, as with people can use device drivers not supported by distributors but provided by third party device vendors, we can break this spell and can lower the barrier for using TOMOYO. This patch is intended for demonstrating that there is nothing difficult for supporting TOMOYO-like loadable LSM modules. For now we need to live with a mixture of built-in part and loadable part because fully loadable LSM modules are not supported since Linux 2.6.24 [2] and number of LSMs which can reserve static call slots is determined at compile time in Linux 6.12. Major changes in this patch are described below. There are no behavior changes as long as TOMOYO is built into vmlinux. Add CONFIG_SECURITY_TOMOYO_LKM as "bool" instead of changing CONFIG_SECURITY_TOMOYO from "bool" to "tristate", for something went wrong with how Makefile is evaluated if I choose "tristate". Add proxy.c for serving as a bridge between vmlinux and tomoyo.ko . Move callback functions from init.c to proxy.c when building as a loadable LSM module. init.c is built-in part and remains for reserving static call slots. proxy.c contains module's init function and tells init.c location of callback functions, making it possible to use static call for tomoyo.ko . By deferring initialization of "struct tomoyo_task" until tomoyo.ko is loaded, threads created between init.c reserved LSM hooks and proxy.c updates LSM hooks will have NULL "struct tomoyo_task" instances. Assuming that tomoyo.ko is loaded by the moment when the global init process starts, initialize "struct tomoyo_task" instance for current thread as a kernel thread when tomoyo_task(current) is called for the first time. There is a hack for exporting currently not-exported functions. This hack will be removed after all relevant functions are exported. Link: https://bugzilla.redhat.com/show_bug.cgi?id=542986 [1] Link: https://lkml.kernel.org/r/caafb609-8bef-4840-a080-81537356fc60@I-love.SAKURA.ne.jp [2] Signed-off-by: Tetsuo Handa

tomoyo: update project links

2024-06-03T13:43:11+00:00

TOMOYO project has moved to SourceForge.net . Signed-off-by: Tetsuo Handa

tomoyo: fix UAF write bug in tomoyo_write_control()

2024-03-01T19:14:00+00:00

Since tomoyo_write_control() updates head->write_buf when write() of long lines is requested, we need to fetch head->write_buf after head->io_sem is held. Otherwise, concurrent write() requests can cause use-after-free-write and double-free problems. Reported-by: Sam Sun Closes: https://lkml.kernel.org/r/CAEkJfYNDspuGxYx5kym8Lvp--D36CMDUErg4rxfWFJuPbbji8g@mail.gmail.com Fixes: bd03a3e4c9a9 ("TOMOYO: Add policy namespace support.") Cc: # Linux 3.1+ Signed-off-by: Tetsuo Handa Signed-off-by: Linus Torvalds

tomoyo: add format attributes to functions

2023-07-23T12:25:28+00:00

Format attributes on functions taking format string can help compilers detect argument type or count mismatches. Please the compiler when building with W=1: security/tomoyo/audit.c: In function ‘tomoyo_init_log’: security/tomoyo/audit.c:290:9: error: function ‘tomoyo_init_log’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format] 290 | vsnprintf(buf + pos, len - pos, fmt, args); | ^~~~~~~~~ security/tomoyo/audit.c: In function ‘tomoyo_write_log2’: security/tomoyo/audit.c:376:9: error: function ‘tomoyo_write_log2’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format] 376 | buf = tomoyo_init_log(r, len, fmt, args); | ^~~ security/tomoyo/common.c: In function ‘tomoyo_addprintf’: security/tomoyo/common.c:193:9: error: function ‘tomoyo_addprintf’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format] 193 | vsnprintf(buffer + pos, len - pos - 1, fmt, args); | ^~~~~~~~~ Signed-off-by: Christian Göttsche Signed-off-by: Tetsuo Handa

tomoyo: replace tomoyo_round2() with kmalloc_size_roundup()

2023-03-01T14:46:12+00:00

It seems tomoyo has had its own implementation of what kmalloc_size_roundup() does today. Remove the function tomoyo_round2() and replace it with kmalloc_size_roundup(). It provides more accurate results and doesn't contain a while loop. Signed-off-by: Vlastimil Babka Signed-off-by: Tetsuo Handa

tomoyo: use vsnprintf() properly

2022-08-21T15:50:42+00:00

Idiomatic way to find how much space sprintf output would take is len = snprintf(NULL, 0, ...) + 1; Once upon a time there'd been libc implementations that blew chunks on that and somebody had come up with the following "cute" trick: len = snprintf((char *) &len, 1, ...) + 1; for doing the same. However, that's unidiomatic, harder to follow *and* any such libc implementation would violate both C99 and POSIX (since 2001). IOW, this kludge is best buried along with such libc implementations, nevermind getting cargo-culted into newer code. Our vsnprintf() does not suffer that braindamage, TYVM. Acked-by: Tetsuo Handa Signed-off-by: Al Viro