| Message ID | 3f5a7bc467d221543444a268dd1a1fe0@paul-moore.com (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Paul Moore |
| Headers | show |
| Series | [GIT,PULL] lsm/lsm-pr-20240105 | expand |
On Fri, 5 Jan 2024 at 15:21, Paul Moore <paul@paul-moore.com> wrote: > > The hightlights of the LSM pull > request are below, but before we get to that I want to mention that I > expect you will hit merge conflicts in the arch-specific syscall > tables as well as in the doc userspace-api documentation index. Some > of these conflicts exist in your tree now (syscall tables), with some > others likely depending on what is submitted from linux-next and the > order in which you merge things. All of the conflicts that I've seen > have been rather trivial and easily resolved, but I wanted to give you > a heads-up; if you want me to resolve any of these let me know. The tooling header file updates by the LSM tree were particularly annoying. Not because the conflicts were hard per se, but because you had done the header files wrong in the first place. Your version of the tooling header files just didn't match the real ones, as you had added your new system calls at the end mindlessly, without noticing that others had *not* done so, so all your tooling header system call number additions were just the wrong numbers entirely. I fixed it up, but it added an extra layer of "this is just annoying". You'd have been better off not touching the tooling headers at all, rather than touch them incorrectly. Linus
The pull request you sent on Fri, 05 Jan 2024 18:21:18 -0500:
> https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git tags/lsm-pr-20240105
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/063a7ce32ddc2c4f2404b0dfd29e60e3dbcdffac
Thank you!
On Tue, Jan 9, 2024 at 4:08 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Fri, 5 Jan 2024 at 15:21, Paul Moore <paul@paul-moore.com> wrote: > > > > The hightlights of the LSM pull > > request are below, but before we get to that I want to mention that I > > expect you will hit merge conflicts in the arch-specific syscall > > tables as well as in the doc userspace-api documentation index. Some > > of these conflicts exist in your tree now (syscall tables), with some > > others likely depending on what is submitted from linux-next and the > > order in which you merge things. All of the conflicts that I've seen > > have been rather trivial and easily resolved, but I wanted to give you > > a heads-up; if you want me to resolve any of these let me know. > > The tooling header file updates by the LSM tree were particularly annoying. > > Not because the conflicts were hard per se, but because you had done > the header files wrong in the first place. > > Your version of the tooling header files just didn't match the real > ones, as you had added your new system calls at the end mindlessly, > without noticing that others had *not* done so, so all your tooling > header system call number additions were just the wrong numbers > entirely. > > I fixed it up, but it added an extra layer of "this is just annoying". > You'd have been better off not touching the tooling headers at all, > rather than touch them incorrectly. Thanks for pulling the changes, I'm sorry the syscall table entries for the LSM syscalls were not how you want to see them, but I'm more than a little confused as to what exactly we did wrong here. A more detailed explanation would be helpful; if there is a doc somewhere that explains the process, feel free to just drop a pointer. I did provide a note in the pull request that based on linux-next there were likely to be some conflicts in the syscall tables, but that was evidently not sufficient, or we just added the syscall tables the wrong way. Your reply makes me believe we added the syscalls to the arch tables the wrong way, but looking at your merge commit and the files themselves (no helpful comments) I don't see anything obvious. Quickly scanning the kernel docs doesn't reveal anything related either, although I might be missing it. The patches also didn't get any comments regarding the syscall tables during review, and aside from the numbering conflicts in linux-next, there were no comments along the lines of "you need to do it this way" there either. I want to do things The Right Way the next time around, but I need some help to understand what that is ... ?
On Wed, 10 Jan 2024 at 11:54, Paul Moore <paul@paul-moore.com> wrote: > > Thanks for pulling the changes, I'm sorry the syscall table entries > for the LSM syscalls were not how you want to see them, but I'm more > than a little confused as to what exactly we did wrong here. Look at commit 5f42375904b0 ("LSM: wireup Linux Security Module syscalls") and notice for example this: --- a/arch/x86/entry/syscalls/syscall_64.tbl +++ b/arch/x86/entry/syscalls/syscall_64.tbl @@ -378,6 +378,9 @@ 454 common futex_wake sys_futex_wake 455 common futex_wait sys_futex_wait 456 common futex_requeue sys_futex_requeue +457 common lsm_get_self_attr sys_lsm_get_self_attr +458 common lsm_set_self_attr sys_lsm_set_self_attr +459 common lsm_list_modules sys_lsm_list_modules Ok, fine - you added your new system calls to the end of the table. Sure, I ended up having to fix them up because the "end of the table" was different by the time I merged your tree, but that wasn't the problem. The problem is here - in the same commit: --- a/tools/perf/arch/x86/entry/syscalls/syscall_64.tbl +++ b/tools/perf/arch/x86/entry/syscalls/syscall_64.tbl @@ -375,6 +375,9 @@ 451 common cachestat sys_cachestat 452 common fchmodat2 sys_fchmodat2 453 64 map_shadow_stack sys_map_shadow_stack +454 common lsm_get_self_attr sys_lsm_get_self_attr +455 common lsm_set_self_attr sys_lsm_set_self_attr +456 common lsm_list_modules sys_lsm_list_modules note how you updated the tools copy WITH THE WRONG NUMBERS! You just added them at the end of the table again, and just incremented the numbers, but that was complete nonsense, because the numbers didn't actually match the real system call numbers, because that tools table hadn't been updated for new system calls - because it hadn't needed them. Yeah, our tooling header duplication is annoying, but the old situation where the tooling just used various kernel headers directly and would randomly break when kernel changes were made was even worse. End result: avoid touching the tooling headers - and if you have to, you need to *think* about it. Linus
On Wed, Jan 10, 2024 at 3:22 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Wed, 10 Jan 2024 at 11:54, Paul Moore <paul@paul-moore.com> wrote: > > > > Thanks for pulling the changes, I'm sorry the syscall table entries > > for the LSM syscalls were not how you want to see them, but I'm more > > than a little confused as to what exactly we did wrong here. > > Look at commit 5f42375904b0 ("LSM: wireup Linux Security Module > syscalls") and notice for example this: > > --- a/arch/x86/entry/syscalls/syscall_64.tbl > +++ b/arch/x86/entry/syscalls/syscall_64.tbl > @@ -378,6 +378,9 @@ > 454 common futex_wake sys_futex_wake > 455 common futex_wait sys_futex_wait > 456 common futex_requeue sys_futex_requeue > +457 common lsm_get_self_attr sys_lsm_get_self_attr > +458 common lsm_set_self_attr sys_lsm_set_self_attr > +459 common lsm_list_modules sys_lsm_list_modules > > Ok, fine - you added your new system calls to the end of the table. > Sure, I ended up having to fix them up because the "end of the table" > was different by the time I merged your tree, but that wasn't the > problem. > > The problem is here - in the same commit: > > --- a/tools/perf/arch/x86/entry/syscalls/syscall_64.tbl > +++ b/tools/perf/arch/x86/entry/syscalls/syscall_64.tbl > @@ -375,6 +375,9 @@ > 451 common cachestat sys_cachestat > 452 common fchmodat2 sys_fchmodat2 > 453 64 map_shadow_stack sys_map_shadow_stack > +454 common lsm_get_self_attr sys_lsm_get_self_attr > +455 common lsm_set_self_attr sys_lsm_set_self_attr > +456 common lsm_list_modules sys_lsm_list_modules > > note how you updated the tools copy WITH THE WRONG NUMBERS! > > You just added them at the end of the table again, and just > incremented the numbers, but that was complete nonsense, because the > numbers didn't actually match the real system call numbers, because > that tools table hadn't been updated for new system calls - because it > hadn't needed them. > > Yeah, our tooling header duplication is annoying, but the old > situation where the tooling just used various kernel headers directly > and would randomly break when kernel changes were made was even worse. > > End result: avoid touching the tooling headers - and if you have to, > you need to *think* about it. Thanks for the explanation, when I read your comment about "tools" I was thinking of whatever tooling transforms the arch/**/*.tbl file and not the tools/perf directory. I should have caught the tools/perf mismatch when reviewing the patches from Casey, but I didn't, I'm sorry. My guess is that my mind was just in the "use the next three numbers" due to the lack of syscall number sync across architectures, but who knows. My mistake, I'll make sure it doesn't happen again.
On 1/10/2024 12:58 PM, Paul Moore wrote: > On Wed, Jan 10, 2024 at 3:22 PM Linus Torvalds > <torvalds@linux-foundation.org> wrote: >> On Wed, 10 Jan 2024 at 11:54, Paul Moore <paul@paul-moore.com> wrote: >>> Thanks for pulling the changes, I'm sorry the syscall table entries >>> for the LSM syscalls were not how you want to see them, but I'm more >>> than a little confused as to what exactly we did wrong here. >> Look at commit 5f42375904b0 ("LSM: wireup Linux Security Module >> syscalls") and notice for example this: >> >> --- a/arch/x86/entry/syscalls/syscall_64.tbl >> +++ b/arch/x86/entry/syscalls/syscall_64.tbl >> @@ -378,6 +378,9 @@ >> 454 common futex_wake sys_futex_wake >> 455 common futex_wait sys_futex_wait >> 456 common futex_requeue sys_futex_requeue >> +457 common lsm_get_self_attr sys_lsm_get_self_attr >> +458 common lsm_set_self_attr sys_lsm_set_self_attr >> +459 common lsm_list_modules sys_lsm_list_modules >> >> Ok, fine - you added your new system calls to the end of the table. >> Sure, I ended up having to fix them up because the "end of the table" >> was different by the time I merged your tree, but that wasn't the >> problem. >> >> The problem is here - in the same commit: >> >> --- a/tools/perf/arch/x86/entry/syscalls/syscall_64.tbl >> +++ b/tools/perf/arch/x86/entry/syscalls/syscall_64.tbl >> @@ -375,6 +375,9 @@ >> 451 common cachestat sys_cachestat >> 452 common fchmodat2 sys_fchmodat2 >> 453 64 map_shadow_stack sys_map_shadow_stack >> +454 common lsm_get_self_attr sys_lsm_get_self_attr >> +455 common lsm_set_self_attr sys_lsm_set_self_attr >> +456 common lsm_list_modules sys_lsm_list_modules >> >> note how you updated the tools copy WITH THE WRONG NUMBERS! >> >> You just added them at the end of the table again, and just >> incremented the numbers, but that was complete nonsense, because the >> numbers didn't actually match the real system call numbers, because >> that tools table hadn't been updated for new system calls - because it >> hadn't needed them. >> >> Yeah, our tooling header duplication is annoying, but the old >> situation where the tooling just used various kernel headers directly >> and would randomly break when kernel changes were made was even worse. >> >> End result: avoid touching the tooling headers - and if you have to, >> you need to *think* about it. > Thanks for the explanation, when I read your comment about "tools" I > was thinking of whatever tooling transforms the arch/**/*.tbl file and > not the tools/perf directory. I should have caught the tools/perf > mismatch when reviewing the patches from Casey, but I didn't, I'm > sorry. My guess is that my mind was just in the "use the next three > numbers" due to the lack of syscall number sync across architectures, > but who knows. My mistake, I'll make sure it doesn't happen again. No, It's my mistake. I could have asked for help when I found my head spinning from the syscall numbering scheme and its various implications. I will have a look at how it might be improved. Sorry to have mucked it up, and thank you for the explanation.
Hi Linus, I realize this is a little early, but my network access is expected to be a little spotty the first half of next week so I wanted to get the Linux v6.8 pull requests out now. The hightlights of the LSM pull request are below, but before we get to that I want to mention that I expect you will hit merge conflicts in the arch-specific syscall tables as well as in the doc userspace-api documentation index. Some of these conflicts exist in your tree now (syscall tables), with some others likely depending on what is submitted from linux-next and the order in which you merge things. All of the conflicts that I've seen have been rather trivial and easily resolved, but I wanted to give you a heads-up; if you want me to resolve any of these let me know. * Add three new syscalls: lsm_list_modules(), lsm_get_self_attr(), and lsm_set_self_attr(). The first syscall simply lists the LSMs enabled, while the second and third get and set the current process' LSM attributes. Yes, these syscalls may provide similar functionality to what can be found under /proc or /sys, but they were designed to support multiple, simultaneaous (stacked) LSMs from the start as opposed to the current /proc based solutions which were created at a time when only one LSM was allowed to be active at a given time. We have spent considerable time discussing ways to extend the existing /proc interfaces to support multiple, simultaneaous LSMs and even our best ideas have been far too ugly to support as a kernel API; after +20 years in the kernel, I felt the LSM layer had established itself enough to justify a handful of syscalls. Support amongst the individual LSM developers has been nearly unanimous, with a single objection coming from Tetsuo (TOMOYO) as he is worried that the LSM_ID_XXX token concept will make it more difficult for out-of-tree LSMs to survive. Several members of the LSM community have demonstrated the ability for out-of-tree LSMs to continue to exist by picking high/unused LSM_ID values as well as pointing out that many kernel APIs rely on integer identifiers, e.g. syscalls (!), but unfortunately Tetsuo's objections remain. My personal opinion is that while I have no interest in penalizing out-of-tree LSMs, I'm not going to penalize in-tree development to support out-of-tree development, and I view this as a necessary step forward to support the push for expanded LSM stacking and reduce our reliance on /proc and /sys which has occassionally been problematic for some container users. Finally, we have included the linux-api folks on (all?) recent revisions of the patchset and addressed all of their concerns. * Add a new security_file_ioctl_compat() LSM hook to handle the 32-bit ioctls on 64-bit systems problem. This patch includes support for all of the existing LSMs which provide ioctl hooks, although it turns out only SELinux actually cares about the individual ioctls. It is worth noting that while Casey (Smack) and Tetsuo (TOMOYO) did not give explicit ACKs to this patch, they did both indicate they are okay with the changes. * Fix a potential memory leak in the CALIPSO code when IPv6 is disabled at boot. While it's good that we are fixing this, I doubt this is something users are seeing in the wild as you need to both disable IPv6 and then attempt to configure IPv6 labeled networking via NetLabel/CALIPSO; that just doesn't make much sense. Normally this would go through netdev, but Jakub asked me to take this patch and of all the trees I maintain, the LSM tree seemed like the best fit. * Update the LSM MAINTAINERS entry with additional information about our process docs, patchwork, bug reporting, etc. I also noticed that the Lockdown LSM is missing a dedicated MAINTAINERS entry so I've added that to the pull request. I've been working with one of the major Lockdown authors/contributors to see if they are willing to step up and assume a Lockdown maintainer role; hopefully that will happen soon, but in the meantime I'll continue to look after it. * Add a handful of mailmap entries for Serge Hallyn and myself. Thanks, -Paul -- The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86: Linux 6.7-rc1 (2023-11-12 16:19:07 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git tags/lsm-pr-20240105 for you to fetch changes up to f1bb47a31dff6d4b34fb14e99850860ee74bb003: lsm: new security_file_ioctl_compat() hook (2023-12-24 15:48:03 -0500) ---------------------------------------------------------------- lsm/stable-6.8 PR 20240105 ---------------------------------------------------------------- Alfred Piccioni (1): lsm: new security_file_ioctl_compat() hook Casey Schaufler (11): LSM: Identify modules by more than name LSM: Maintain a table of LSM attribute data proc: Use lsmids instead of lsm names for attrs LSM: syscalls for current process attributes LSM: Create lsm_list_modules system call LSM: wireup Linux Security Module syscalls LSM: Helpers for attribute names and filling lsm_ctx Smack: implement setselfattr and getselfattr hooks AppArmor: Add selfattr hooks SELinux: Add selfattr hooks LSM: selftests for Linux Security Module syscalls Gavrilov Ilia (1): calipso: fix memory leak in netlbl_calipso_add_pass() Mark Brown (1): lsm: Add a __counted_by() annotation to lsm_ctx.ctx Paul Moore (11): lsm: drop LSM_ID_IMA lsm: cleanup the size counters in security_getselfattr() lsm: correct error codes in security_getselfattr() lsm: consolidate buffer size handling into lsm_fill_user_ctx() lsm: align based on pointer length in lsm_fill_user_ctx() lsm: convert security_setselfattr() to use memdup_user() lsm: mark the lsm_id variables are marked as static mailmap: update/replace my old email addresses MAINTAINERS: update the LSM entry MAINTAINERS: add an entry for the lockdown LSM selftests: remove the LSM_ID_IMA check in lsm/lsm_list_modules_test Roberto Sassu (1): lsm: don't yet account for IMA in LSM_CONFIG_COUNT calculation Serge Hallyn (1): mailmap: add entries for Serge Hallyn's dead accounts .mailmap | 4 + Documentation/userspace-api/index.rst | 1 + Documentation/userspace-api/lsm.rst | 73 ++++++ MAINTAINERS | 17 +- arch/alpha/kernel/syscalls/syscall.tbl | 3 + arch/arm/tools/syscall.tbl | 3 + arch/arm64/include/asm/unistd.h | 2 +- arch/arm64/include/asm/unistd32.h | 6 + arch/m68k/kernel/syscalls/syscall.tbl | 3 + arch/microblaze/kernel/syscalls/syscall.tbl | 3 + arch/mips/kernel/syscalls/syscall_n32.tbl | 3 + arch/mips/kernel/syscalls/syscall_n64.tbl | 3 + arch/mips/kernel/syscalls/syscall_o32.tbl | 3 + arch/parisc/kernel/syscalls/syscall.tbl | 3 + arch/powerpc/kernel/syscalls/syscall.tbl | 3 + arch/s390/kernel/syscalls/syscall.tbl | 3 + arch/sh/kernel/syscalls/syscall.tbl | 3 + arch/sparc/kernel/syscalls/syscall.tbl | 3 + arch/x86/entry/syscalls/syscall_32.tbl | 3 + arch/x86/entry/syscalls/syscall_64.tbl | 3 + arch/xtensa/kernel/syscalls/syscall.tbl | 3 + fs/ioctl.c | 3 +- fs/proc/base.c | 29 +-- fs/proc/internal.h | 2 +- include/linux/lsm_hook_defs.h | 6 + include/linux/lsm_hooks.h | 17 +- include/linux/security.h | 56 ++++- include/linux/syscalls.h | 6 + include/uapi/asm-generic/unistd.h | 9 +- include/uapi/linux/lsm.h | 90 +++++++ kernel/sys_ni.c | 3 + net/netlabel/netlabel_calipso.c | 49 ++-- security/Makefile | 1 + security/apparmor/include/procattr.h | 2 +- security/apparmor/lsm.c | 90 ++++++- security/apparmor/procattr.c | 10 +- security/bpf/hooks.c | 9 +- security/commoncap.c | 8 +- security/landlock/cred.c | 2 +- security/landlock/fs.c | 2 +- security/landlock/net.c | 2 +- security/landlock/ptrace.c | 2 +- security/landlock/setup.c | 6 + security/landlock/setup.h | 1 + security/loadpin/loadpin.c | 9 +- security/lockdown/lockdown.c | 8 +- security/lsm_syscalls.c | 120 +++++++++ security/safesetid/lsm.c | 9 +- security/security.c | 273 +++++++++++++++- security/selinux/hooks.c | 173 ++++++++++--- security/smack/smack_lsm.c | 93 ++++++- security/tomoyo/tomoyo.c | 10 +- security/yama/yama_lsm.c | 8 +- .../perf/arch/mips/entry/syscalls/syscall_n64.tbl | 3 + tools/perf/arch/powerpc/entry/syscalls/syscall.tbl | 3 + tools/perf/arch/s390/entry/syscalls/syscall.tbl | 3 + tools/perf/arch/x86/entry/syscalls/syscall_64.tbl | 3 + tools/testing/selftests/Makefile | 1 + tools/testing/selftests/lsm/.gitignore | 1 + tools/testing/selftests/lsm/Makefile | 17 ++ tools/testing/selftests/lsm/common.c | 89 +++++++ tools/testing/selftests/lsm/common.h | 33 +++ tools/testing/selftests/lsm/config | 3 + .../testing/selftests/lsm/lsm_get_self_attr_test.c | 275 +++++++++++++++++ .../testing/selftests/lsm/lsm_list_modules_test.c | 137 ++++++++++ .../testing/selftests/lsm/lsm_set_self_attr_test.c | 74 ++++++ 66 files changed, 1776 insertions(+), 122 deletions(-) create mode 100644 Documentation/userspace-api/lsm.rst create mode 100644 include/uapi/linux/lsm.h create mode 100644 security/lsm_syscalls.c create mode 100644 tools/testing/selftests/lsm/.gitignore create mode 100644 tools/testing/selftests/lsm/Makefile create mode 100644 tools/testing/selftests/lsm/common.c create mode 100644 tools/testing/selftests/lsm/common.h create mode 100644 tools/testing/selftests/lsm/config create mode 100644 tools/testing/selftests/lsm/lsm_get_self_attr_test.c create mode 100644 tools/testing/selftests/lsm/lsm_list_modules_test.c create mode 100644 tools/testing/selftests/lsm/lsm_set_self_attr_test.c -- paul-moore.com