Rules for allowing read from /proc/<pid of program>/
Can you provide more details? "systemd" is a name of a package which contains multiple programs.
Which executable program is using proc:/\$/ ?
Did you confirm that that executable program is using only proc:/\$/ (and not using proc:/self/ )?
/proc/self/ is once converted to /proc/$pid/ by the pathname resolution routine inside the kernel, and TOMOYO converts back from "$pid" to "self" if the $pid matches getpid() value (please see ccs_get_local_path() in security/ccsecurity/realpath.c ).
Therefore, if a $pid is used for checking permission, I think that that executable program started scanning other processes (e.g. parents or children).
Sure, here are some examples from my audit log:
TOMOYO
Fork
#2020/10/23 03:34:29# profile=3 mode=enforcing granted=no (global-pid=6534) task={ pid=6534 ppid=6530 uid=0 gid=0 euid=0 egid=0 suid=0 sgid=0 fsuid=0 fsgid=0 type!=execute_handler } path1={ uid=0 gid=0 ino=39403 major=0 minor=22 perm=0444 type=file } path1.parent={ uid=0 gid=0 ino=39401 perm=0555 }
<kernel> /lib/systemd/systemd /lib/systemd/system-generators/systemd-bless-boot-generator
file read proc:/6534/status
#2020/10/23 03:34:29# profile=3 mode=enforcing granted=no (global-pid=6536) task={ pid=6536 ppid=6530 uid=0 gid=0 euid=0 egid=0 suid=0 sgid=0 fsuid=0 fsgid=0 type!=execute_handler } path1={ uid=0 gid=0 ino=35063 major=0 minor=22 perm=0444 type=file } path1.parent={ uid=0 gid=0 ino=35062 perm=0555 }
<kernel> /lib/systemd/systemd /lib/systemd/system-generators/systemd-cryptsetup-generator
file read proc:/6536/stat
#2020/10/23 03:34:29# profile=3 mode=enforcing granted=no (global-pid=6536) task={ pid=6536 ppid=6530 uid=0 gid=0 euid=0 egid=0 suid=0 sgid=0 fsuid=0 fsgid=0 type!=execute_handler } path1={ uid=0 gid=0 ino=35064 major=0 minor=22 perm=0444 type=file } path1.parent={ uid=0 gid=0 ino=35062 perm=0555 }
<kernel> /lib/systemd/systemd /lib/systemd/system-generators/systemd-cryptsetup-generator
file read proc:/6536/status
#2020/10/23 03:34:29# profile=3 mode=enforcing granted=no (global-pid=6539) task={ pid=6539 ppid=6530 uid=0 gid=0 euid=0 egid=0 suid=0 sgid=0 fsuid=0 fsgid=0 type!=execute_handler } path1={ uid=0 gid=0 ino=37991 major=0 minor=22 perm=0444 type=file } path1.parent={ uid=0 gid=0 ino=37990 perm=0555 }
<kernel> /lib/systemd/systemd /lib/systemd/system-generators/systemd-getty-generator
file read proc:/6539/stat
#2020/10/23 03:34:29# profile=3 mode=enforcing granted=no (global-pid=6539) task={ pid=6539 ppid=6530 uid=0 gid=0 euid=0 egid=0 suid=0 sgid=0 fsuid=0 fsgid=0 type!=execute_handler } path1={ uid=0 gid=0 ino=37992 major=0 minor=22 perm=0444 type=file } path1.parent={ uid=0 gid=0 ino=37990 perm=0555 }
<kernel> /lib/systemd/systemd /lib/systemd/system-generators/systemd-getty-generator
file read proc:/6539/status
#2020/10/23 03:34:29# profile=3 mode=enforcing granted=no (global-pid=6537) task={ pid=6537 ppid=6530 uid=0 gid=0 euid=0 egid=0 suid=0 sgid=0 fsuid=0 fsgid=0 type!=execute_handler } path1={ uid=0 gid=0 ino=33057 major=0 minor=22 perm=0444 type=file } path1.parent={ uid=0 gid=0 ino=33056 perm=0555 }
<kernel> /lib/systemd/systemd /lib/systemd/system-generators/systemd-debug-generator
file read proc:/6537/stat
#2020/10/23 03:34:29# profile=3 mode=enforcing granted=no (global-pid=6540) task={ pid=6540 ppid=6530 uid=0 gid=0 euid=0 egid=0 suid=0 sgid=0 fsuid=0 fsgid=0 type!=execute_handler } path1={ uid=0 gid=0 ino=32496 major=0 minor=22 perm=0444 type=file } path1.parent={ uid=0 gid=0 ino=32495 perm=0555 }
<kernel> /lib/systemd/systemd /lib/systemd/system-generators/systemd-gpt-auto-generator
file read proc:/6540/stat
#2020/10/23 03:34:29# profile=3 mode=enforcing granted=no (global-pid=6540) task={ pid=6540 ppid=6530 uid=0 gid=0 euid=0 egid=0 suid=0 sgid=0 fsuid=0 fsgid=0 type!=execute_handler } path1={ uid=0 gid=0 ino=32497 major=0 minor=22 perm=0444 type=file } path1.parent={ uid=0 gid=0 ino=32495 perm=0555 }
<kernel> /lib/systemd/systemd /lib/systemd/system-generators/systemd-gpt-auto-generator
file read proc:/6540/status
#2020/10/23 03:34:29# profile=3 mode=enforcing granted=no (global-pid=6537) task={ pid=6537 ppid=6530 uid=0 gid=0 euid=0 egid=0 suid=0 sgid=0 fsuid=0 fsgid=0 type!=execute_handler } path1={ uid=0 gid=0 ino=33058 major=0 minor=22 perm=0444 type=file } path1.parent={ uid=0 gid=0 ino=33056 perm=0555 }
<kernel> /lib/systemd/systemd /lib/systemd/system-generators/systemd-debug-generator
file read proc:/6537/status
#2020/10/23 03:34:29# profile=3 mode=enforcing granted=no (global-pid=6547) task={ pid=6547 ppid=6530 uid=0 gid=0 euid=0 egid=0 suid=0 sgid=0 fsuid=0 fsgid=0 type!=execute_handler } path1={ uid=0 gid=0 ino=39405 major=0 minor=22 perm=0444 type=file } path1.parent={ uid=0 gid=0 ino=39404 perm=0555 }
<kernel> /lib/systemd/systemd /lib/systemd/system-generators/systemd-veritysetup-generator
file read proc:/6547/stat
#2020/10/23 04:12:30# profile=3 mode=enforcing granted=no (global-pid=35758) task={ pid=35758 ppid=1 uid=193 gid=193 euid=193 egid=193 suid=193 sgid=193 fsuid=193 fsgid=193 type!=execute_handler } path1={ uid=193 gid=193 ino=72364 major=0 minor=22 perm=0444 type=file } path1.parent={ uid=193 gid=193 ino=71154 perm=0555 }
<kernel> /lib/systemd/systemd /lib/systemd/systemd-resolved
file read proc:/35758/stat
#2020/10/23 04:12:30# profile=3 mode=enforcing granted=no (global-pid=35758) task={ pid=35758 ppid=1 uid=193 gid=193 euid=193 egid=193 suid=193 sgid=193 fsuid=193 fsgid=193 type!=execute_handler } path1={ uid=193 gid=193 ino=68468 major=0 minor=22 perm=0444 type=file } path1.parent={ uid=193 gid=193 ino=71154 perm=0555 }
<kernel> /lib/systemd/systemd /lib/systemd/systemd-resolved
file read proc:/35758/status
The issue seems to only hit systemd utilities afaict from the log.
Well, in Linux 5.8, tomoyo_get_local_path() was updated to use proc_pid_ns(sb) instead of sb->s_fs_info.
Will you try below diff?
--- a/security/ccsecurity/realpath.c (revision 6821)
+++ b/security/ccsecurity/realpath.c (working copy)
@@ -12,6 +12,9 @@
#include <linux/nsproxy.h>
#include <linux/mnt_namespace.h>
#endif
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 8, 0)
+#include <linux/proc_fs.h>
+#endif
/***** SECTION1: Constants definition *****/
@@ -379,8 +382,16 @@
if (sb->s_magic == PROC_SUPER_MAGIC && *pos == '/') {
char *ep;
const pid_t pid = (pid_t) simple_strtoul(pos + 1, &ep, 10);
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 25)
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 8, 0)
if (*ep == '/' && pid && pid ==
+ task_tgid_nr_ns(current, proc_pid_ns(sb))) {
+ pos = ep - 5;
+ if (pos < buffer)
+ goto out;
+ memmove(pos, "/self", 5);
+ }
+#elif LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 25)
+ if (*ep == '/' && pid && pid ==
task_tgid_nr_ns(current, sb->s_fs_info)) {
pos = ep - 5;
if (pos < buffer)
That seems to work. Thanks!
That seems to work. Thanks!
That seems to work. Thanks!
Kernel: 5.8.10 amd64 CCSecurity: 1.8.7+ 2020/08/20
It appears to me that newer systemd versions are accessing /proc/<getpid()>/ directly instead of via the /proc/self symlink. Is there anyway for me to permit only for the /proc entry of the requesting process instead of a blanket file read proc:/\$/* rule?