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
On Fri, 5 Jan 2024 at 15:21, Paul Moore <[email protected]> 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!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
On Tue, Jan 9, 2024 at 4:08 PM Linus Torvalds
<[email protected]> wrote:
> On Fri, 5 Jan 2024 at 15:21, Paul Moore <[email protected]> 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 ... ?
--
paul-moore.com
On Wed, 10 Jan 2024 at 11:54, Paul Moore <[email protected]> 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
<[email protected]> wrote:
>
> On Wed, 10 Jan 2024 at 11:54, Paul Moore <[email protected]> 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.
--
paul-moore.com
On 1/10/2024 12:58 PM, Paul Moore wrote:
> On Wed, Jan 10, 2024 at 3:22 PM Linus Torvalds
> <[email protected]> wrote:
>> On Wed, 10 Jan 2024 at 11:54, Paul Moore <[email protected]> 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.