linux-stable.git/security/tomoyo, branch v6.8

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

exec: Check __FMODE_EXEC instead of in_execve for LSMs

2024-01-24T19:38:58+00:00

After commit 978ffcbf00d8 ("execve: open the executable file before
doing anything else"), current->in_execve was no longer in sync with the
open(). This broke AppArmor and TOMOYO which depend on this flag to
distinguish "open" operations from being "exec" operations.

Instead of moving around in_execve, switch to using __FMODE_EXEC, which
is where the "is this an exec?" intent is stored. Note that TOMOYO still
uses in_execve around cred handling.

Reported-by: Kevin Locke 
Closes: https://lore.kernel.org/all/ZbE4qn9_h14OqADK@kevinlocke.name
Suggested-by: Linus Torvalds 
Fixes: 978ffcbf00d8 ("execve: open the executable file before doing anything else")
Cc: Josh Triplett 
Cc: John Johansen 
Cc: Paul Moore 
Cc: James Morris 
Cc: Serge E. Hallyn 
Cc: Kentaro Takeda 
Cc: Tetsuo Handa 
Cc: Alexander Viro 
Cc: Christian Brauner 
Cc: Jan Kara 
Cc: Eric Biederman 
Cc: Andrew Morton 
Cc: Sebastian Andrzej Siewior 
Cc:  
Cc:  
Cc:  
Cc:  
Signed-off-by: Kees Cook 
Signed-off-by: Linus Torvalds

lsm: new security_file_ioctl_compat() hook

2023-12-24T20:48:03+00:00

Some ioctl commands do not require ioctl permission, but are routed to
other permissions such as FILE_GETATTR or FILE_SETATTR. This routing is
done by comparing the ioctl cmd to a set of 64-bit flags (FS_IOC_*).

However, if a 32-bit process is running on a 64-bit kernel, it emits
32-bit flags (FS_IOC32_*) for certain ioctl operations. These flags are
being checked erroneously, which leads to these ioctl operations being
routed to the ioctl permission, rather than the correct file
permissions.

This was also noted in a RED-PEN finding from a while back -
"/* RED-PEN how should LSM module know it's handling 32bit? */".

This patch introduces a new hook, security_file_ioctl_compat(), that is
called from the compat ioctl syscall. All current LSMs have been changed
to support this hook.

Reviewing the three places where we are currently using
security_file_ioctl(), it appears that only SELinux needs a dedicated
compat change; TOMOYO and SMACK appear to be functional without any
change.

Cc: stable@vger.kernel.org
Fixes: 0b24dcb7f2f7 ("Revert "selinux: simplify ioctl checking"")
Signed-off-by: Alfred Piccioni 
Reviewed-by: Stephen Smalley 
[PM: subject tweak, line length fixes, and alignment corrections]
Signed-off-by: Paul Moore

lsm: mark the lsm_id variables are marked as static

2023-11-13T03:54:42+00:00

As the kernel test robot helpfully reminded us, all of the lsm_id
instances defined inside the various LSMs should be marked as static.
The one exception is Landlock which uses its lsm_id variable across
multiple source files with an extern declaration in a header file.

Reported-by: kernel test robot 
Suggested-by: Casey Schaufler 
Reviewed-by: Casey Schaufler 
Signed-off-by: Paul Moore

LSM: Identify modules by more than name

2023-11-13T03:54:42+00:00

Create a struct lsm_id to contain identifying information about Linux
Security Modules (LSMs). At inception this contains the name of the
module and an identifier associated with the security module.  Change
the security_add_hooks() interface to use this structure.  Change the
individual modules to maintain their own struct lsm_id and pass it to
security_add_hooks().

The values are for LSM identifiers are defined in a new UAPI
header file linux/lsm.h. Each existing LSM has been updated to
include it's LSMID in the lsm_id.

The LSM ID values are sequential, with the oldest module
LSM_ID_CAPABILITY being the lowest value and the existing modules
numbered in the order they were included in the main line kernel.
This is an arbitrary convention for assigning the values, but
none better presents itself. The value 0 is defined as being invalid.
The values 1-99 are reserved for any special case uses which may
arise in the future. This may include attributes of the LSM
infrastructure itself, possibly related to namespacing or network
attribute management. A special range is identified for such attributes
to help reduce confusion for developers unfamiliar with LSMs.

LSM attribute values are defined for the attributes presented by
modules that are available today. As with the LSM IDs, The value 0
is defined as being invalid. The values 1-99 are reserved for any
special case uses which may arise in the future.

Cc: linux-security-module 
Signed-off-by: Casey Schaufler 
Reviewed-by: Kees Cook 
Reviewed-by: Serge Hallyn 
Reviewed-by: Mickael Salaun 
Reviewed-by: John Johansen 
Signed-off-by: Kees Cook 
Nacked-by: Tetsuo Handa 
[PM: forward ported beyond v6.6 due merge window changes]
Signed-off-by: Paul Moore

lsm: constify 'bprm' parameter in security_bprm_committed_creds()

2023-09-14T19:27:29+00:00

Three LSMs register the implementations for the 'bprm_committed_creds()'
hook: AppArmor, SELinux and tomoyo. Looking at the function
implementations we may observe that the 'bprm' parameter is not changing.

Mark the 'bprm' parameter of LSM hook security_bprm_committed_creds() as
'const' since it will not be changing in the LSM hook.

Signed-off-by: Khadija Kamran 
[PM: minor merge fuzzing due to other constification patches]
Signed-off-by: Paul Moore

tomoyo: remove unused function declaration

2023-08-13T13:07:15+00:00

The last usage of tomoyo_check_flags() has been removed by commit
57c2590fb7fd ("TOMOYO: Update profile structure."). Clean up its
residual declaration.

Signed-off-by: GONG, Ruiqi 
Signed-off-by: Tetsuo Handa

tomoyo: refactor deprecated strncpy

2023-08-05T10:55:10+00:00

`strncpy` is deprecated for use on NUL-terminated destination strings [1].

A suitable replacement is `strscpy` [2] due to the fact that it
guarantees NUL-termination on its destination buffer argument which is
_not_ the case for `strncpy`!

It should be noted that the destination buffer is zero-initialized and
had a max length of `sizeof(dest) - 1`. There is likely _not_ a bug
present in the current implementation. However, by switching to
`strscpy` we get the benefit of no longer needing the `- 1`'s from the
string copy invocations on top of `strscpy` being a safer interface all
together.

[1]: www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
[2]: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html

Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt 
Reviewed-by: Kees Cook 
Signed-off-by: Tetsuo Handa

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

mm/gup: remove vmas parameter from get_user_pages_remote()

2023-06-09T23:25:26+00:00

The only instances of get_user_pages_remote() invocations which used the
vmas parameter were for a single page which can instead simply look up the
VMA directly. In particular:-

- __update_ref_ctr() looked up the VMA but did nothing with it so we simply
  remove it.

- __access_remote_vm() was already using vma_lookup() when the original
  lookup failed so by doing the lookup directly this also de-duplicates the
  code.

We are able to perform these VMA operations as we already hold the
mmap_lock in order to be able to call get_user_pages_remote().

As part of this work we add get_user_page_vma_remote() which abstracts the
VMA lookup, error handling and decrementing the page reference count should
the VMA lookup fail.

This forms part of a broader set of patches intended to eliminate the vmas
parameter altogether.

[akpm@linux-foundation.org: avoid passing NULL to PTR_ERR]
Link: https://lkml.kernel.org/r/d20128c849ecdbf4dd01cc828fcec32127ed939a.1684350871.git.lstoakes@gmail.com
Signed-off-by: Lorenzo Stoakes 
Reviewed-by: Catalin Marinas  (for arm64)
Acked-by: David Hildenbrand 
Reviewed-by: Janosch Frank  (for s390)
Reviewed-by: Christoph Hellwig 
Cc: Christian König 
Cc: Dennis Dalessandro 
Cc: Greg Kroah-Hartman 
Cc: Jarkko Sakkinen 
Cc: Jason Gunthorpe 
Cc: Jens Axboe 
Cc: Matthew Wilcox (Oracle) 
Cc: Sakari Ailus 
Cc: Sean Christopherson 
Signed-off-by: Andrew Morton