linux-toradex.git/kernel/cred.c, branch v6.11-rc7

cred: Use KMEM_CACHE() instead of kmem_cache_create()

2024-02-23T22:33:31+00:00

Commit 0a31bd5f2bbb ("KMEM_CACHE(): simplify slab cache creation")
introduces a new macro. Use the new KMEM_CACHE() macro instead of
direct kmem_cache_create() to simplify the creation of SLAB caches.

Signed-off-by: Kunwu Chan 
[PM: alignment fixes in both code and description]
Signed-off-by: Paul Moore

cred: get rid of CONFIG_DEBUG_CREDENTIALS

2023-12-15T22:19:48+00:00

This code is rarely (never?) enabled by distros, and it hasn't caught
anything in decades. Let's kill off this legacy debug code.

Suggested-by: Linus Torvalds 
Signed-off-by: Jens Axboe 
Signed-off-by: Linus Torvalds

cred: switch to using atomic_long_t

2023-12-15T22:08:46+00:00

There are multiple ways to grab references to credentials, and the only
protection we have against overflowing it is the memory required to do
so.

With memory sizes only moving in one direction, let's bump the reference
count to 64-bit and move it outside the realm of feasibly overflowing.

Signed-off-by: Jens Axboe 
Signed-off-by: Linus Torvalds

Merge tag 'lsm-pr-20231030' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm

2023-10-31T06:13:17+00:00

Pull LSM updates from Paul Moore:

 - Add new credential functions, get_cred_many() and put_cred_many() to
   save some atomic_t operations for a few operations.

   While not strictly LSM related, this patchset had been rotting on the
   mailing lists for some time and since the LSMs do care a lot about
   credentials I thought it reasonable to give this patch a home.

 - Five patches to constify different LSM hook parameters.

 - Fix a spelling mistake.

* tag 'lsm-pr-20231030' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm:
  lsm: fix a spelling mistake
  cred: add get_cred_many and put_cred_many
  lsm: constify 'sb' parameter in security_sb_kern_mount()
  lsm: constify 'bprm' parameter in security_bprm_committed_creds()
  lsm: constify 'bprm' parameter in security_bprm_committing_creds()
  lsm: constify 'file' parameter in security_bprm_creds_from_file()
  lsm: constify 'sb' parameter in security_quotactl()

groups: Convert group_info.usage to refcount_t

2023-09-29T18:28:39+00:00

atomic_t variables are currently used to implement reference counters
with the following properties:
 - counter is initialized to 1 using atomic_set()
 - a resource is freed upon counter reaching zero
 - once counter reaches zero, its further
   increments aren't allowed
 - counter schema uses basic atomic operations
   (set, inc, inc_not_zero, dec_and_test, etc.)

Such atomic variables should be converted to a newly provided
refcount_t type and API that prevents accidental counter overflows and
underflows. This is important since overflows and underflows can lead
to use-after-free situation and be exploitable.

The variable group_info.usage is used as pure reference counter.
Convert it to refcount_t and fix up the operations.

**Important note for maintainers:

Some functions from refcount_t API defined in refcount.h have different
memory ordering guarantees than their atomic counterparts. Please check
Documentation/core-api/refcount-vs-atomic.rst for more information.

Normally the differences should not matter since refcount_t provides
enough guarantees to satisfy the refcounting use cases, but in some
rare cases it might matter. Please double check that you don't have
some undocumented memory guarantees for this variable usage.

For the group_info.usage it might make a difference in following places:
 - put_group_info(): decrement in refcount_dec_and_test() only
   provides RELEASE ordering and ACQUIRE ordering on success vs. fully
   ordered atomic counterpart

Suggested-by: Kees Cook 
Signed-off-by: Elena Reshetova 
Reviewed-by: David Windsor 
Reviewed-by: Hans Liljestrand 
Link: https://lore.kernel.org/r/20230818041456.gonna.009-kees@kernel.org
Signed-off-by: Kees Cook

cred: add get_cred_many and put_cred_many

2023-09-21T23:29:30+00:00

Some of the frequent consumers of get_cred and put_cred operate on 2
references on the same creds back-to-back.

Switch them to doing the work in one go instead.

Signed-off-by: Mateusz Guzik 
[PM: removed changelog from commit description]
Signed-off-by: Paul Moore

cred: convert printks to pr_

2023-08-18T17:18:49+00:00

Use current logging style.

Link: https://lkml.kernel.org/r/20230625033452.GA22858@didi-ThinkCentre-M930t-N000
Signed-off-by: tiozhang 
Reviewed-by: Sergey Senozhatsky 
Cc: Greg Kroah-Hartman 
Cc: Joe Perches 
Cc: Kees Cook 
Cc: Luis Chamberlain 
Cc: Paulo Alcantara 
Cc: Weiping Zhang 
Signed-off-by: Andrew Morton

cred: Do not default to init_cred in prepare_kernel_cred()

2022-11-01T17:04:52+00:00

A common exploit pattern for ROP attacks is to abuse prepare_kernel_cred()
in order to construct escalated privileges[1]. Instead of providing a
short-hand argument (NULL) to the "daemon" argument to indicate using
init_cred as the base cred, require that "daemon" is always set to
an actual task. Replace all existing callers that were passing NULL
with &init_task.

Future attacks will need to have sufficiently powerful read/write
primitives to have found an appropriately privileged task and written it
to the ROP stack as an argument to succeed, which is similarly difficult
to the prior effort needed to escalate privileges before struct cred
existed: locate the current cred and overwrite the uid member.

This has the added benefit of meaning that prepare_kernel_cred() can no
longer exceed the privileges of the init task, which may have changed from
the original init_cred (e.g. dropping capabilities from the bounding set).

[1] https://google.com/search?q=commit_creds(prepare_kernel_cred(0))

Cc: "Eric W. Biederman" 
Cc: David Howells 
Cc: "Rafael J. Wysocki" 
Cc: Steve French 
Cc: Ronnie Sahlberg 
Cc: Shyam Prasad N 
Cc: Tom Talpey 
Cc: Namjae Jeon 
Cc: Trond Myklebust 
Cc: Anna Schumaker 
Cc: Chuck Lever 
Cc: Jeff Layton 
Cc: "David S. Miller" 
Cc: Eric Dumazet 
Cc: Jakub Kicinski 
Cc: Paolo Abeni 
Cc: "Michal Koutný" 
Cc: Peter Zijlstra 
Cc: linux-cifs@vger.kernel.org
Cc: samba-technical@lists.samba.org
Cc: linux-nfs@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Kees Cook 
Acked-by: Luis Chamberlain 
Reviewed-by: Sergey Senozhatsky 
Acked-by: Russ Weight 
Acked-by: Greg Kroah-Hartman 
Acked-by: Paulo Alcantara (SUSE) 
Link: https://lore.kernel.org/r/20221026232943.never.775-kees@kernel.org

x86: Mark __invalid_creds() __noreturn

2022-03-15T09:32:44+00:00

vmlinux.o: warning: objtool: ksys_unshare()+0x36c: unreachable instruction

0000 0000000000067040 :
...
0364    673a4:	4c 89 ef             	mov    %r13,%rdi
0367    673a7:	e8 00 00 00 00       	call   673ac 	673a8: R_X86_64_PLT32	__invalid_creds-0x4
036c    673ac:	e9 28 ff ff ff       	jmp    672d9 
0371    673b1:	41 bc f4 ff ff ff    	mov    $0xfffffff4,%r12d
0377    673b7:	e9 80 fd ff ff       	jmp    6713c 

Signed-off-by: Peter Zijlstra (Intel) 
Link: https://lkml.kernel.org/r/Yi9gOW9f1GGwwUD6@hirez.programming.kicks-ass.net

ucounts: Base set_cred_ucounts changes on the real user

2022-02-17T15:11:02+00:00

Michal Koutný  wrote:
> Tasks are associated to multiple users at once. Historically and as per
> setrlimit(2) RLIMIT_NPROC is enforce based on real user ID.
>
> The commit 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts")
> made the accounting structure "indexed" by euid and hence potentially
> account tasks differently.
>
> The effective user ID may be different e.g. for setuid programs but
> those are exec'd into already existing task (i.e. below limit), so
> different accounting is moot.
>
> Some special setresuid(2) users may notice the difference, justifying
> this fix.

I looked at cred->ucount and it is only used for rlimit operations
that were previously stored in cred->user.  Making the fact
cred->ucount can refer to a different user from cred->user a bug,
affecting all uses of cred->ulimit not just RLIMIT_NPROC.

Fix set_cred_ucounts to always use the real uid not the effective uid.

Further simplify set_cred_ucounts by noticing that set_cred_ucounts
somehow retained a draft version of the check to see if alloc_ucounts
was needed that checks the new->user and new->user_ns against the
current_real_cred().  Remove that draft version of the check.

All that matters for setting the cred->ucounts are the user_ns and uid
fields in the cred.

Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20220207121800.5079-4-mkoutny@suse.com
Link: https://lkml.kernel.org/r/20220216155832.680775-3-ebiederm@xmission.com
Reported-by: Michal Koutný 
Reviewed-by: Michal Koutný 
Fixes: 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts")
Signed-off-by: "Eric W. Biederman"