2019-01-16 18:46:06 +03:00
// SPDX-License-Identifier: GPL-2.0
/*
* SafeSetID Linux Security Module
*
* Author : Micah Morton < mortonm @ chromium . org >
*
* Copyright ( C ) 2018 The Chromium OS Authors .
*
* This program is free software ; you can redistribute it and / or modify
* it under the terms of the GNU General Public License version 2 , as
* published by the Free Software Foundation .
*
*/
# define pr_fmt(fmt) "SafeSetID: " fmt
# include <linux/lsm_hooks.h>
# include <linux/module.h>
# include <linux/ptrace.h>
# include <linux/sched/task_stack.h>
# include <linux/security.h>
2019-04-10 19:55:34 +03:00
# include "lsm.h"
2019-01-16 18:46:06 +03:00
/* Flag indicating whether initialization completed */
2021-06-09 02:09:29 +03:00
int safesetid_initialized __initdata ;
2019-01-16 18:46:06 +03:00
2020-07-16 22:52:01 +03:00
struct setid_ruleset __rcu * safesetid_setuid_rules ;
struct setid_ruleset __rcu * safesetid_setgid_rules ;
2019-01-16 18:46:06 +03:00
LSM: SafeSetID: rewrite userspace API to atomic updates
The current API of the SafeSetID LSM uses one write() per rule, and applies
each written rule instantly. This has several downsides:
- While a policy is being loaded, once a single parent-child pair has been
loaded, the parent is restricted to that specific child, even if
subsequent rules would allow transitions to other child UIDs. This means
that during policy loading, set*uid() can randomly fail.
- To replace the policy without rebooting, it is necessary to first flush
all old rules. This creates a time window in which no constraints are
placed on the use of CAP_SETUID.
- If we want to perform sanity checks on the final policy, this requires
that the policy isn't constructed in a piecemeal fashion without telling
the kernel when it's done.
Other kernel APIs - including things like the userns code and netfilter -
avoid this problem by performing updates atomically. Luckily, SafeSetID
hasn't landed in a stable (upstream) release yet, so maybe it's not too
late to completely change the API.
The new API for SafeSetID is: If you want to change the policy, open
"safesetid/whitelist_policy" and write the entire policy,
newline-delimited, in there.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:56:05 +03:00
/* Compute a decision for a transition from @src to @dst under @policy. */
2020-07-16 22:52:01 +03:00
enum sid_policy_type _setid_policy_lookup ( struct setid_ruleset * policy ,
kid_t src , kid_t dst )
2019-01-16 18:46:06 +03:00
{
2020-07-16 22:52:01 +03:00
struct setid_rule * rule ;
2019-04-10 19:55:34 +03:00
enum sid_policy_type result = SIDPOL_DEFAULT ;
2019-01-16 18:46:06 +03:00
2020-07-16 22:52:01 +03:00
if ( policy - > type = = UID ) {
hash_for_each_possible ( policy - > rules , rule , next , __kuid_val ( src . uid ) ) {
if ( ! uid_eq ( rule - > src_id . uid , src . uid ) )
continue ;
if ( uid_eq ( rule - > dst_id . uid , dst . uid ) )
return SIDPOL_ALLOWED ;
result = SIDPOL_CONSTRAINED ;
}
} else if ( policy - > type = = GID ) {
hash_for_each_possible ( policy - > rules , rule , next , __kgid_val ( src . gid ) ) {
if ( ! gid_eq ( rule - > src_id . gid , src . gid ) )
continue ;
if ( gid_eq ( rule - > dst_id . gid , dst . gid ) ) {
return SIDPOL_ALLOWED ;
}
result = SIDPOL_CONSTRAINED ;
}
} else {
/* Should not reach here, report the ID as contrainsted */
2019-04-10 19:55:34 +03:00
result = SIDPOL_CONSTRAINED ;
2019-01-16 18:46:06 +03:00
}
LSM: SafeSetID: rewrite userspace API to atomic updates
The current API of the SafeSetID LSM uses one write() per rule, and applies
each written rule instantly. This has several downsides:
- While a policy is being loaded, once a single parent-child pair has been
loaded, the parent is restricted to that specific child, even if
subsequent rules would allow transitions to other child UIDs. This means
that during policy loading, set*uid() can randomly fail.
- To replace the policy without rebooting, it is necessary to first flush
all old rules. This creates a time window in which no constraints are
placed on the use of CAP_SETUID.
- If we want to perform sanity checks on the final policy, this requires
that the policy isn't constructed in a piecemeal fashion without telling
the kernel when it's done.
Other kernel APIs - including things like the userns code and netfilter -
avoid this problem by performing updates atomically. Luckily, SafeSetID
hasn't landed in a stable (upstream) release yet, so maybe it's not too
late to completely change the API.
The new API for SafeSetID is: If you want to change the policy, open
"safesetid/whitelist_policy" and write the entire policy,
newline-delimited, in there.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:56:05 +03:00
return result ;
}
/*
* Compute a decision for a transition from @ src to @ dst under the active
* policy .
*/
2020-07-16 22:52:01 +03:00
static enum sid_policy_type setid_policy_lookup ( kid_t src , kid_t dst , enum setid_type new_type )
LSM: SafeSetID: rewrite userspace API to atomic updates
The current API of the SafeSetID LSM uses one write() per rule, and applies
each written rule instantly. This has several downsides:
- While a policy is being loaded, once a single parent-child pair has been
loaded, the parent is restricted to that specific child, even if
subsequent rules would allow transitions to other child UIDs. This means
that during policy loading, set*uid() can randomly fail.
- To replace the policy without rebooting, it is necessary to first flush
all old rules. This creates a time window in which no constraints are
placed on the use of CAP_SETUID.
- If we want to perform sanity checks on the final policy, this requires
that the policy isn't constructed in a piecemeal fashion without telling
the kernel when it's done.
Other kernel APIs - including things like the userns code and netfilter -
avoid this problem by performing updates atomically. Luckily, SafeSetID
hasn't landed in a stable (upstream) release yet, so maybe it's not too
late to completely change the API.
The new API for SafeSetID is: If you want to change the policy, open
"safesetid/whitelist_policy" and write the entire policy,
newline-delimited, in there.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:56:05 +03:00
{
enum sid_policy_type result = SIDPOL_DEFAULT ;
2020-07-16 22:52:01 +03:00
struct setid_ruleset * pol ;
LSM: SafeSetID: rewrite userspace API to atomic updates
The current API of the SafeSetID LSM uses one write() per rule, and applies
each written rule instantly. This has several downsides:
- While a policy is being loaded, once a single parent-child pair has been
loaded, the parent is restricted to that specific child, even if
subsequent rules would allow transitions to other child UIDs. This means
that during policy loading, set*uid() can randomly fail.
- To replace the policy without rebooting, it is necessary to first flush
all old rules. This creates a time window in which no constraints are
placed on the use of CAP_SETUID.
- If we want to perform sanity checks on the final policy, this requires
that the policy isn't constructed in a piecemeal fashion without telling
the kernel when it's done.
Other kernel APIs - including things like the userns code and netfilter -
avoid this problem by performing updates atomically. Luckily, SafeSetID
hasn't landed in a stable (upstream) release yet, so maybe it's not too
late to completely change the API.
The new API for SafeSetID is: If you want to change the policy, open
"safesetid/whitelist_policy" and write the entire policy,
newline-delimited, in there.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:56:05 +03:00
rcu_read_lock ( ) ;
2020-07-16 22:52:01 +03:00
if ( new_type = = UID )
pol = rcu_dereference ( safesetid_setuid_rules ) ;
else if ( new_type = = GID )
pol = rcu_dereference ( safesetid_setgid_rules ) ;
else { /* Should not reach here */
result = SIDPOL_CONSTRAINED ;
rcu_read_unlock ( ) ;
return result ;
}
if ( pol ) {
pol - > type = new_type ;
result = _setid_policy_lookup ( pol , src , dst ) ;
}
2019-01-16 18:46:06 +03:00
rcu_read_unlock ( ) ;
2019-04-10 19:55:34 +03:00
return result ;
2019-01-16 18:46:06 +03:00
}
static int safesetid_security_capable ( const struct cred * cred ,
struct user_namespace * ns ,
int cap ,
unsigned int opts )
{
2020-07-16 22:52:01 +03:00
/* We're only interested in CAP_SETUID and CAP_SETGID. */
if ( cap ! = CAP_SETUID & & cap ! = CAP_SETGID )
2019-04-10 19:55:41 +03:00
return 0 ;
/*
2022-06-09 01:27:27 +03:00
* If CAP_SET { U / G } ID is currently used for a setid or setgroups syscall , we
* want to let it go through here ; the real security check happens later , in
* the task_fix_set { u / g } id or task_fix_setgroups hooks .
2019-04-10 19:55:41 +03:00
*/
if ( ( opts & CAP_OPT_INSETID ) ! = 0 )
return 0 ;
2020-07-16 22:52:01 +03:00
switch ( cap ) {
case CAP_SETUID :
/*
* If no policy applies to this task , allow the use of CAP_SETUID for
* other purposes .
*/
2020-08-11 18:39:51 +03:00
if ( setid_policy_lookup ( ( kid_t ) { . uid = cred - > uid } , INVALID_ID , UID ) = = SIDPOL_DEFAULT )
2020-07-16 22:52:01 +03:00
return 0 ;
/*
* Reject use of CAP_SETUID for functionality other than calling
* set * uid ( ) ( e . g . setting up userns uid mappings ) .
*/
pr_warn ( " Operation requires CAP_SETUID, which is not available to UID %u for operations besides approved set*uid transitions \n " ,
__kuid_val ( cred - > uid ) ) ;
return - EPERM ;
case CAP_SETGID :
/*
* If no policy applies to this task , allow the use of CAP_SETGID for
* other purposes .
*/
2020-08-11 18:39:51 +03:00
if ( setid_policy_lookup ( ( kid_t ) { . gid = cred - > gid } , INVALID_ID , GID ) = = SIDPOL_DEFAULT )
2020-07-16 22:52:01 +03:00
return 0 ;
/*
* Reject use of CAP_SETUID for functionality other than calling
* set * gid ( ) ( e . g . setting up userns gid mappings ) .
*/
pr_warn ( " Operation requires CAP_SETGID, which is not available to GID %u for operations besides approved set*gid transitions \n " ,
__kuid_val ( cred - > uid ) ) ;
return - EPERM ;
default :
/* Error, the only capabilities were checking for is CAP_SETUID/GID */
2019-04-10 19:55:41 +03:00
return 0 ;
2020-07-16 22:52:01 +03:00
}
return 0 ;
2019-01-16 18:46:06 +03:00
}
LSM: SafeSetID: fix check for setresuid(new1, new2, new3)
With the old code, when a process with the (real,effective,saved) UID set
(1,1,1) calls setresuid(2,3,4), safesetid_task_fix_setuid() only checks
whether the transition 1->2 is permitted; the transitions 1->3 and 1->4 are
not checked. Fix this.
This is also a good opportunity to refactor safesetid_task_fix_setuid() to
be less verbose - having one branch per set*uid() syscall is unnecessary.
Note that this slightly changes semantics: The UID transition check for
UIDs that were not in the old cred struct is now always performed against
the policy of the RUID. I think that's more consistent anyway, since the
RUID is also the one that decides whether any policy is enforced at all.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:55:19 +03:00
/*
* Check whether a caller with old credentials @ old is allowed to switch to
2020-07-16 22:52:01 +03:00
* credentials that contain @ new_id .
LSM: SafeSetID: fix check for setresuid(new1, new2, new3)
With the old code, when a process with the (real,effective,saved) UID set
(1,1,1) calls setresuid(2,3,4), safesetid_task_fix_setuid() only checks
whether the transition 1->2 is permitted; the transitions 1->3 and 1->4 are
not checked. Fix this.
This is also a good opportunity to refactor safesetid_task_fix_setuid() to
be less verbose - having one branch per set*uid() syscall is unnecessary.
Note that this slightly changes semantics: The UID transition check for
UIDs that were not in the old cred struct is now always performed against
the policy of the RUID. I think that's more consistent anyway, since the
RUID is also the one that decides whether any policy is enforced at all.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:55:19 +03:00
*/
2020-07-16 22:52:01 +03:00
static bool id_permitted_for_cred ( const struct cred * old , kid_t new_id , enum setid_type new_type )
2019-01-16 18:46:06 +03:00
{
LSM: SafeSetID: fix check for setresuid(new1, new2, new3)
With the old code, when a process with the (real,effective,saved) UID set
(1,1,1) calls setresuid(2,3,4), safesetid_task_fix_setuid() only checks
whether the transition 1->2 is permitted; the transitions 1->3 and 1->4 are
not checked. Fix this.
This is also a good opportunity to refactor safesetid_task_fix_setuid() to
be less verbose - having one branch per set*uid() syscall is unnecessary.
Note that this slightly changes semantics: The UID transition check for
UIDs that were not in the old cred struct is now always performed against
the policy of the RUID. I think that's more consistent anyway, since the
RUID is also the one that decides whether any policy is enforced at all.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:55:19 +03:00
bool permitted ;
2020-07-16 22:52:01 +03:00
/* If our old creds already had this ID in it, it's fine. */
if ( new_type = = UID ) {
if ( uid_eq ( new_id . uid , old - > uid ) | | uid_eq ( new_id . uid , old - > euid ) | |
uid_eq ( new_id . uid , old - > suid ) )
return true ;
} else if ( new_type = = GID ) {
if ( gid_eq ( new_id . gid , old - > gid ) | | gid_eq ( new_id . gid , old - > egid ) | |
gid_eq ( new_id . gid , old - > sgid ) )
return true ;
} else /* Error, new_type is an invalid type */
return false ;
LSM: SafeSetID: fix check for setresuid(new1, new2, new3)
With the old code, when a process with the (real,effective,saved) UID set
(1,1,1) calls setresuid(2,3,4), safesetid_task_fix_setuid() only checks
whether the transition 1->2 is permitted; the transitions 1->3 and 1->4 are
not checked. Fix this.
This is also a good opportunity to refactor safesetid_task_fix_setuid() to
be less verbose - having one branch per set*uid() syscall is unnecessary.
Note that this slightly changes semantics: The UID transition check for
UIDs that were not in the old cred struct is now always performed against
the policy of the RUID. I think that's more consistent anyway, since the
RUID is also the one that decides whether any policy is enforced at all.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:55:19 +03:00
2019-01-16 18:46:06 +03:00
/*
LSM: SafeSetID: fix check for setresuid(new1, new2, new3)
With the old code, when a process with the (real,effective,saved) UID set
(1,1,1) calls setresuid(2,3,4), safesetid_task_fix_setuid() only checks
whether the transition 1->2 is permitted; the transitions 1->3 and 1->4 are
not checked. Fix this.
This is also a good opportunity to refactor safesetid_task_fix_setuid() to
be less verbose - having one branch per set*uid() syscall is unnecessary.
Note that this slightly changes semantics: The UID transition check for
UIDs that were not in the old cred struct is now always performed against
the policy of the RUID. I think that's more consistent anyway, since the
RUID is also the one that decides whether any policy is enforced at all.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:55:19 +03:00
* Transitions to new UIDs require a check against the policy of the old
* RUID .
2019-01-16 18:46:06 +03:00
*/
2019-04-10 19:55:34 +03:00
permitted =
2020-08-11 18:39:51 +03:00
setid_policy_lookup ( ( kid_t ) { . uid = old - > uid } , new_id , new_type ) ! = SIDPOL_CONSTRAINED ;
2020-07-16 22:52:01 +03:00
LSM: SafeSetID: fix check for setresuid(new1, new2, new3)
With the old code, when a process with the (real,effective,saved) UID set
(1,1,1) calls setresuid(2,3,4), safesetid_task_fix_setuid() only checks
whether the transition 1->2 is permitted; the transitions 1->3 and 1->4 are
not checked. Fix this.
This is also a good opportunity to refactor safesetid_task_fix_setuid() to
be less verbose - having one branch per set*uid() syscall is unnecessary.
Note that this slightly changes semantics: The UID transition check for
UIDs that were not in the old cred struct is now always performed against
the policy of the RUID. I think that's more consistent anyway, since the
RUID is also the one that decides whether any policy is enforced at all.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:55:19 +03:00
if ( ! permitted ) {
2020-07-16 22:52:01 +03:00
if ( new_type = = UID ) {
pr_warn ( " UID transition ((%d,%d,%d) -> %d) blocked \n " ,
__kuid_val ( old - > uid ) , __kuid_val ( old - > euid ) ,
__kuid_val ( old - > suid ) , __kuid_val ( new_id . uid ) ) ;
} else if ( new_type = = GID ) {
pr_warn ( " GID transition ((%d,%d,%d) -> %d) blocked \n " ,
__kgid_val ( old - > gid ) , __kgid_val ( old - > egid ) ,
__kgid_val ( old - > sgid ) , __kgid_val ( new_id . gid ) ) ;
} else /* Error, new_type is an invalid type */
return false ;
LSM: SafeSetID: fix check for setresuid(new1, new2, new3)
With the old code, when a process with the (real,effective,saved) UID set
(1,1,1) calls setresuid(2,3,4), safesetid_task_fix_setuid() only checks
whether the transition 1->2 is permitted; the transitions 1->3 and 1->4 are
not checked. Fix this.
This is also a good opportunity to refactor safesetid_task_fix_setuid() to
be less verbose - having one branch per set*uid() syscall is unnecessary.
Note that this slightly changes semantics: The UID transition check for
UIDs that were not in the old cred struct is now always performed against
the policy of the RUID. I think that's more consistent anyway, since the
RUID is also the one that decides whether any policy is enforced at all.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:55:19 +03:00
}
return permitted ;
2019-01-16 18:46:06 +03:00
}
/*
* Check whether there is either an exception for user under old cred struct to
* set * uid to user under new cred struct , or the UID transition is allowed ( by
* Linux set * uid rules ) even without CAP_SETUID .
*/
static int safesetid_task_fix_setuid ( struct cred * new ,
const struct cred * old ,
int flags )
{
LSM: SafeSetID: fix check for setresuid(new1, new2, new3)
With the old code, when a process with the (real,effective,saved) UID set
(1,1,1) calls setresuid(2,3,4), safesetid_task_fix_setuid() only checks
whether the transition 1->2 is permitted; the transitions 1->3 and 1->4 are
not checked. Fix this.
This is also a good opportunity to refactor safesetid_task_fix_setuid() to
be less verbose - having one branch per set*uid() syscall is unnecessary.
Note that this slightly changes semantics: The UID transition check for
UIDs that were not in the old cred struct is now always performed against
the policy of the RUID. I think that's more consistent anyway, since the
RUID is also the one that decides whether any policy is enforced at all.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:55:19 +03:00
/* Do nothing if there are no setuid restrictions for our old RUID. */
2020-08-11 18:39:51 +03:00
if ( setid_policy_lookup ( ( kid_t ) { . uid = old - > uid } , INVALID_ID , UID ) = = SIDPOL_DEFAULT )
2020-07-16 22:52:01 +03:00
return 0 ;
2020-08-11 18:39:51 +03:00
if ( id_permitted_for_cred ( old , ( kid_t ) { . uid = new - > uid } , UID ) & &
id_permitted_for_cred ( old , ( kid_t ) { . uid = new - > euid } , UID ) & &
id_permitted_for_cred ( old , ( kid_t ) { . uid = new - > suid } , UID ) & &
id_permitted_for_cred ( old , ( kid_t ) { . uid = new - > fsuid } , UID ) )
2020-07-16 22:52:01 +03:00
return 0 ;
/*
* Kill this process to avoid potential security vulnerabilities
* that could arise from a missing allowlist entry preventing a
* privileged process from dropping to a lesser - privileged one .
*/
force_sig ( SIGKILL ) ;
return - EACCES ;
}
static int safesetid_task_fix_setgid ( struct cred * new ,
const struct cred * old ,
int flags )
{
/* Do nothing if there are no setgid restrictions for our old RGID. */
2020-08-11 18:39:51 +03:00
if ( setid_policy_lookup ( ( kid_t ) { . gid = old - > gid } , INVALID_ID , GID ) = = SIDPOL_DEFAULT )
2019-01-16 18:46:06 +03:00
return 0 ;
2020-08-11 18:39:51 +03:00
if ( id_permitted_for_cred ( old , ( kid_t ) { . gid = new - > gid } , GID ) & &
id_permitted_for_cred ( old , ( kid_t ) { . gid = new - > egid } , GID ) & &
id_permitted_for_cred ( old , ( kid_t ) { . gid = new - > sgid } , GID ) & &
id_permitted_for_cred ( old , ( kid_t ) { . gid = new - > fsgid } , GID ) )
LSM: SafeSetID: fix check for setresuid(new1, new2, new3)
With the old code, when a process with the (real,effective,saved) UID set
(1,1,1) calls setresuid(2,3,4), safesetid_task_fix_setuid() only checks
whether the transition 1->2 is permitted; the transitions 1->3 and 1->4 are
not checked. Fix this.
This is also a good opportunity to refactor safesetid_task_fix_setuid() to
be less verbose - having one branch per set*uid() syscall is unnecessary.
Note that this slightly changes semantics: The UID transition check for
UIDs that were not in the old cred struct is now always performed against
the policy of the RUID. I think that's more consistent anyway, since the
RUID is also the one that decides whether any policy is enforced at all.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:55:19 +03:00
return 0 ;
/*
* Kill this process to avoid potential security vulnerabilities
2020-07-16 22:52:01 +03:00
* that could arise from a missing allowlist entry preventing a
LSM: SafeSetID: fix check for setresuid(new1, new2, new3)
With the old code, when a process with the (real,effective,saved) UID set
(1,1,1) calls setresuid(2,3,4), safesetid_task_fix_setuid() only checks
whether the transition 1->2 is permitted; the transitions 1->3 and 1->4 are
not checked. Fix this.
This is also a good opportunity to refactor safesetid_task_fix_setuid() to
be less verbose - having one branch per set*uid() syscall is unnecessary.
Note that this slightly changes semantics: The UID transition check for
UIDs that were not in the old cred struct is now always performed against
the policy of the RUID. I think that's more consistent anyway, since the
RUID is also the one that decides whether any policy is enforced at all.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:55:19 +03:00
* privileged process from dropping to a lesser - privileged one .
*/
force_sig ( SIGKILL ) ;
return - EACCES ;
2019-01-16 18:46:06 +03:00
}
2022-06-09 01:27:27 +03:00
static int safesetid_task_fix_setgroups ( struct cred * new , const struct cred * old )
{
int i ;
/* Do nothing if there are no setgid restrictions for our old RGID. */
if ( setid_policy_lookup ( ( kid_t ) { . gid = old - > gid } , INVALID_ID , GID ) = = SIDPOL_DEFAULT )
return 0 ;
get_group_info ( new - > group_info ) ;
for ( i = 0 ; i < new - > group_info - > ngroups ; i + + ) {
if ( ! id_permitted_for_cred ( old , ( kid_t ) { . gid = new - > group_info - > gid [ i ] } , GID ) ) {
put_group_info ( new - > group_info ) ;
/*
* Kill this process to avoid potential security vulnerabilities
* that could arise from a missing allowlist entry preventing a
* privileged process from dropping to a lesser - privileged one .
*/
force_sig ( SIGKILL ) ;
return - EACCES ;
}
}
put_group_info ( new - > group_info ) ;
return 0 ;
}
2019-01-16 18:46:06 +03:00
static struct security_hook_list safesetid_security_hooks [ ] = {
LSM_HOOK_INIT ( task_fix_setuid , safesetid_task_fix_setuid ) ,
2020-07-16 22:52:01 +03:00
LSM_HOOK_INIT ( task_fix_setgid , safesetid_task_fix_setgid ) ,
2022-06-09 01:27:27 +03:00
LSM_HOOK_INIT ( task_fix_setgroups , safesetid_task_fix_setgroups ) ,
2019-01-16 18:46:06 +03:00
LSM_HOOK_INIT ( capable , safesetid_security_capable )
} ;
static int __init safesetid_security_init ( void )
{
security_add_hooks ( safesetid_security_hooks ,
ARRAY_SIZE ( safesetid_security_hooks ) , " safesetid " ) ;
/* Report that SafeSetID successfully initialized */
safesetid_initialized = 1 ;
return 0 ;
}
DEFINE_LSM ( safesetid_security_init ) = {
. init = safesetid_security_init ,
2019-01-28 23:30:56 +03:00
. name = " safesetid " ,
2019-01-16 18:46:06 +03:00
} ;