| Message ID | 20210507114048.138933-1-omosnace@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | lockdown,selinux: fix bogus SELinux lockdown permission checks | expand |
On 5/7/2021 4:40 AM, Ondrej Mosnacek wrote: > Commit 59438b46471a ("security,lockdown,selinux: implement SELinux > lockdown") added an implementation of the locked_down LSM hook to > SELinux, with the aim to restrict which domains are allowed to perform > operations that would breach lockdown. > > However, in several places the security_locked_down() hook is called in > situations where the current task isn't doing any action that would > directly breach lockdown, leading to SELinux checks that are basically > bogus. > > Since in most of these situations converting the callers such that > security_locked_down() is called in a context where the current task > would be meaningful for SELinux is impossible or very non-trivial (and > could lead to TOCTOU issues for the classic Lockdown LSM > implementation), fix this by adding a separate hook > security_locked_down_globally() This is a poor solution to the stated problem. Rather than adding a new hook you should add the task as a parameter to the existing hook and let the security modules do as they will based on its value. If the caller does not have an appropriate task it should pass NULL. The lockdown LSM can ignore the task value and SELinux can make its own decision based on the task value passed. > that is to be used in such situations > and convert all these problematic callers to call this hook instead. The > new hook is then left unimplemented in SELinux and in Lockdown LSM it is > backed by the same implementation as the locked_down hook. > > The callers migrated to the new hook are: > 1. arch/powerpc/xmon/xmon.c > Here the hook seems to be called from non-task context and is only > used for redacting some sensitive values from output sent to > userspace. > 2. fs/tracefs/inode.c:tracefs_create_file() > Here the call is used to prevent creating new tracefs entries when > the kernel is locked down. Assumes that locking down is one-way - > i.e. if the hook returns non-zero once, it will never return zero > again, thus no point in creating these files. > 3. kernel/trace/bpf_trace.c:bpf_probe_read_kernel{,_str}_common() > Called when a BPF program calls a helper that could leak kernel > memory. The task context is not relevant here, since the program > may very well be run in the context of a different task than the > consumer of the data. > See: https://bugzilla.redhat.com/show_bug.cgi?id=1955585 > 4. net/xfrm/xfrm_user.c:copy_to_user_*() > Here a cryptographic secret is redacted based on the value returned > from the hook. There are two possible actions that may lead here: > a) A netlink message XFRM_MSG_GETSA with NLM_F_DUMP set - here the > task context is relevant, since the dumped data is sent back to > the current task. > b) When deleting an SA via XFRM_MSG_DELSA, the dumped SAs are > broadcasted to tasks subscribed to XFRM events - here the > SELinux check is not meningful as the current task's creds do > not represent the tasks that could potentially see the secret. > It really doesn't seem worth it to try to preserve the check in the > a) case, since the eventual leak can be circumvented anyway via b), > plus there is no way for the task to indicate that it doesn't care > about the actual key value, so the check could generate a lot of > noise. > > Fixes: 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown") > Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> > --- > arch/powerpc/xmon/xmon.c | 4 ++-- > fs/tracefs/inode.c | 2 +- > include/linux/lsm_hook_defs.h | 1 + > include/linux/security.h | 5 +++++ > kernel/trace/bpf_trace.c | 4 ++-- > net/xfrm/xfrm_user.c | 2 +- > security/lockdown/lockdown.c | 1 + > security/security.c | 6 ++++++ > 8 files changed, 19 insertions(+), 6 deletions(-) > > diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c > index 3fe37495f63d..a4bad825d424 100644 > --- a/arch/powerpc/xmon/xmon.c > +++ b/arch/powerpc/xmon/xmon.c > @@ -298,7 +298,7 @@ static bool xmon_is_locked_down(void) > static bool lockdown; > > if (!lockdown) { > - lockdown = !!security_locked_down(LOCKDOWN_XMON_RW); > + lockdown = !!security_locked_down_globally(LOCKDOWN_XMON_RW); > if (lockdown) { > printf("xmon: Disabled due to kernel lockdown\n"); > xmon_is_ro = true; > @@ -306,7 +306,7 @@ static bool xmon_is_locked_down(void) > } > > if (!xmon_is_ro) { > - xmon_is_ro = !!security_locked_down(LOCKDOWN_XMON_WR); > + xmon_is_ro = !!security_locked_down_globally(LOCKDOWN_XMON_WR); > if (xmon_is_ro) > printf("xmon: Read-only due to kernel lockdown\n"); > } > diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c > index 4b83cbded559..07241435efec 100644 > --- a/fs/tracefs/inode.c > +++ b/fs/tracefs/inode.c > @@ -396,7 +396,7 @@ struct dentry *tracefs_create_file(const char *name, umode_t mode, > struct dentry *dentry; > struct inode *inode; > > - if (security_locked_down(LOCKDOWN_TRACEFS)) > + if (security_locked_down_globally(LOCKDOWN_TRACEFS)) > return NULL; > > if (!(mode & S_IFMT)) > diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h > index 477a597db013..d6e2a6b59277 100644 > --- a/include/linux/lsm_hook_defs.h > +++ b/include/linux/lsm_hook_defs.h > @@ -390,6 +390,7 @@ LSM_HOOK(void, LSM_RET_VOID, bpf_prog_free_security, struct bpf_prog_aux *aux) > #endif /* CONFIG_BPF_SYSCALL */ > > LSM_HOOK(int, 0, locked_down, enum lockdown_reason what) > +LSM_HOOK(int, 0, locked_down_globally, enum lockdown_reason what) > > #ifdef CONFIG_PERF_EVENTS > LSM_HOOK(int, 0, perf_event_open, struct perf_event_attr *attr, int type) > diff --git a/include/linux/security.h b/include/linux/security.h > index 8aeebd6646dc..e683dee84f46 100644 > --- a/include/linux/security.h > +++ b/include/linux/security.h > @@ -468,6 +468,7 @@ int security_inode_notifysecctx(struct inode *inode, void *ctx, u32 ctxlen); > int security_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen); > int security_inode_getsecctx(struct inode *inode, void **ctx, u32 *ctxlen); > int security_locked_down(enum lockdown_reason what); > +int security_locked_down_globally(enum lockdown_reason what); > #else /* CONFIG_SECURITY */ > > static inline int call_blocking_lsm_notifier(enum lsm_event event, void *data) > @@ -1329,6 +1330,10 @@ static inline int security_locked_down(enum lockdown_reason what) > { > return 0; > } > +static inline int security_locked_down_globally(enum lockdown_reason what) > +{ > + return 0; > +} > #endif /* CONFIG_SECURITY */ > > #if defined(CONFIG_SECURITY) && defined(CONFIG_WATCH_QUEUE) > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > index b0c45d923f0f..f43bca95b261 100644 > --- a/kernel/trace/bpf_trace.c > +++ b/kernel/trace/bpf_trace.c > @@ -215,7 +215,7 @@ const struct bpf_func_proto bpf_probe_read_user_str_proto = { > static __always_inline int > bpf_probe_read_kernel_common(void *dst, u32 size, const void *unsafe_ptr) > { > - int ret = security_locked_down(LOCKDOWN_BPF_READ); > + int ret = security_locked_down_globally(LOCKDOWN_BPF_READ); > > if (unlikely(ret < 0)) > goto fail; > @@ -246,7 +246,7 @@ const struct bpf_func_proto bpf_probe_read_kernel_proto = { > static __always_inline int > bpf_probe_read_kernel_str_common(void *dst, u32 size, const void *unsafe_ptr) > { > - int ret = security_locked_down(LOCKDOWN_BPF_READ); > + int ret = security_locked_down_globally(LOCKDOWN_BPF_READ); > > if (unlikely(ret < 0)) > goto fail; > diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c > index 5a0ef4361e43..5a56f74262d8 100644 > --- a/net/xfrm/xfrm_user.c > +++ b/net/xfrm/xfrm_user.c > @@ -851,7 +851,7 @@ static int copy_user_offload(struct xfrm_state_offload *xso, struct sk_buff *skb > static bool xfrm_redact(void) > { > return IS_ENABLED(CONFIG_SECURITY) && > - security_locked_down(LOCKDOWN_XFRM_SECRET); > + security_locked_down_globally(LOCKDOWN_XFRM_SECRET); > } > > static int copy_to_user_auth(struct xfrm_algo_auth *auth, struct sk_buff *skb) > diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c > index 87cbdc64d272..4ac172eaa4b7 100644 > --- a/security/lockdown/lockdown.c > +++ b/security/lockdown/lockdown.c > @@ -73,6 +73,7 @@ static int lockdown_is_locked_down(enum lockdown_reason what) > > static struct security_hook_list lockdown_hooks[] __lsm_ro_after_init = { > LSM_HOOK_INIT(locked_down, lockdown_is_locked_down), > + LSM_HOOK_INIT(locked_down_globally, lockdown_is_locked_down), > }; > > static int __init lockdown_lsm_init(void) > diff --git a/security/security.c b/security/security.c > index 5ac96b16f8fa..b9b990681ae9 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -2547,6 +2547,12 @@ int security_locked_down(enum lockdown_reason what) > } > EXPORT_SYMBOL(security_locked_down); > > +int security_locked_down_globally(enum lockdown_reason what) > +{ > + return call_int_hook(locked_down_globally, 0, what); > +} > +EXPORT_SYMBOL(security_locked_down_globally); > + > #ifdef CONFIG_PERF_EVENTS > int security_perf_event_open(struct perf_event_attr *attr, int type) > {
On Sat, May 8, 2021 at 12:17 AM Casey Schaufler <casey@schaufler-ca.com> wrote: > On 5/7/2021 4:40 AM, Ondrej Mosnacek wrote: > > Commit 59438b46471a ("security,lockdown,selinux: implement SELinux > > lockdown") added an implementation of the locked_down LSM hook to > > SELinux, with the aim to restrict which domains are allowed to perform > > operations that would breach lockdown. > > > > However, in several places the security_locked_down() hook is called in > > situations where the current task isn't doing any action that would > > directly breach lockdown, leading to SELinux checks that are basically > > bogus. > > > > Since in most of these situations converting the callers such that > > security_locked_down() is called in a context where the current task > > would be meaningful for SELinux is impossible or very non-trivial (and > > could lead to TOCTOU issues for the classic Lockdown LSM > > implementation), fix this by adding a separate hook > > security_locked_down_globally() > > This is a poor solution to the stated problem. Rather than adding > a new hook you should add the task as a parameter to the existing hook > and let the security modules do as they will based on its value. > If the caller does not have an appropriate task it should pass NULL. > The lockdown LSM can ignore the task value and SELinux can make its > own decision based on the task value passed. The problem with that approach is that all callers would then need to be updated and I intended to keep the patch small as I'd like it to go to stable kernels as well. But it does seem to be a better long-term solution - would it work for you (and whichever maintainer would be taking the patch(es)) if I just added another patch that refactors it to use the task parameter? -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.
On 5/12/2021 6:21 AM, Ondrej Mosnacek wrote: > On Sat, May 8, 2021 at 12:17 AM Casey Schaufler <casey@schaufler-ca.com> wrote: >> On 5/7/2021 4:40 AM, Ondrej Mosnacek wrote: >>> Commit 59438b46471a ("security,lockdown,selinux: implement SELinux >>> lockdown") added an implementation of the locked_down LSM hook to >>> SELinux, with the aim to restrict which domains are allowed to perform >>> operations that would breach lockdown. >>> >>> However, in several places the security_locked_down() hook is called in >>> situations where the current task isn't doing any action that would >>> directly breach lockdown, leading to SELinux checks that are basically >>> bogus. >>> >>> Since in most of these situations converting the callers such that >>> security_locked_down() is called in a context where the current task >>> would be meaningful for SELinux is impossible or very non-trivial (and >>> could lead to TOCTOU issues for the classic Lockdown LSM >>> implementation), fix this by adding a separate hook >>> security_locked_down_globally() >> This is a poor solution to the stated problem. Rather than adding >> a new hook you should add the task as a parameter to the existing hook >> and let the security modules do as they will based on its value. >> If the caller does not have an appropriate task it should pass NULL. >> The lockdown LSM can ignore the task value and SELinux can make its >> own decision based on the task value passed. > The problem with that approach is that all callers would then need to > be updated and I intended to keep the patch small as I'd like it to go > to stable kernels as well. > > But it does seem to be a better long-term solution - would it work for > you (and whichever maintainer would be taking the patch(es)) if I just > added another patch that refactors it to use the task parameter? I can't figure out what you're suggesting. Are you saying that you want to add a new hook *and* add the task parameter? > > -- > Ondrej Mosnacek > Software Engineer, Linux Security - SELinux kernel > Red Hat, Inc. >
On Wed, May 12, 2021 at 6:18 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > On 5/12/2021 6:21 AM, Ondrej Mosnacek wrote: > > On Sat, May 8, 2021 at 12:17 AM Casey Schaufler <casey@schaufler-ca.com> wrote: > >> On 5/7/2021 4:40 AM, Ondrej Mosnacek wrote: > >>> Commit 59438b46471a ("security,lockdown,selinux: implement SELinux > >>> lockdown") added an implementation of the locked_down LSM hook to > >>> SELinux, with the aim to restrict which domains are allowed to perform > >>> operations that would breach lockdown. > >>> > >>> However, in several places the security_locked_down() hook is called in > >>> situations where the current task isn't doing any action that would > >>> directly breach lockdown, leading to SELinux checks that are basically > >>> bogus. > >>> > >>> Since in most of these situations converting the callers such that > >>> security_locked_down() is called in a context where the current task > >>> would be meaningful for SELinux is impossible or very non-trivial (and > >>> could lead to TOCTOU issues for the classic Lockdown LSM > >>> implementation), fix this by adding a separate hook > >>> security_locked_down_globally() > >> This is a poor solution to the stated problem. Rather than adding > >> a new hook you should add the task as a parameter to the existing hook > >> and let the security modules do as they will based on its value. > >> If the caller does not have an appropriate task it should pass NULL. > >> The lockdown LSM can ignore the task value and SELinux can make its > >> own decision based on the task value passed. > > The problem with that approach is that all callers would then need to > > be updated and I intended to keep the patch small as I'd like it to go > > to stable kernels as well. > > > > But it does seem to be a better long-term solution - would it work for > > you (and whichever maintainer would be taking the patch(es)) if I just > > added another patch that refactors it to use the task parameter? > > I can't figure out what you're suggesting. Are you saying that you > want to add a new hook *and* add the task parameter? No, just to keep this patch as-is (and let it go to stable in this form) and post another (non-stable) patch on top of it that undoes the new hook and re-implements the fix using your suggestion. (Yeah, it'll look weird, but I'm not sure how better to handle such situation - I'm open to doing it whatever different way the maintainers prefer.) -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.
On 5/12/2021 9:44 AM, Ondrej Mosnacek wrote: > On Wed, May 12, 2021 at 6:18 PM Casey Schaufler <casey@schaufler-ca.com> wrote: >> On 5/12/2021 6:21 AM, Ondrej Mosnacek wrote: >>> On Sat, May 8, 2021 at 12:17 AM Casey Schaufler <casey@schaufler-ca.com> wrote: >>>> On 5/7/2021 4:40 AM, Ondrej Mosnacek wrote: >>>>> Commit 59438b46471a ("security,lockdown,selinux: implement SELinux >>>>> lockdown") added an implementation of the locked_down LSM hook to >>>>> SELinux, with the aim to restrict which domains are allowed to perform >>>>> operations that would breach lockdown. >>>>> >>>>> However, in several places the security_locked_down() hook is called in >>>>> situations where the current task isn't doing any action that would >>>>> directly breach lockdown, leading to SELinux checks that are basically >>>>> bogus. >>>>> >>>>> Since in most of these situations converting the callers such that >>>>> security_locked_down() is called in a context where the current task >>>>> would be meaningful for SELinux is impossible or very non-trivial (and >>>>> could lead to TOCTOU issues for the classic Lockdown LSM >>>>> implementation), fix this by adding a separate hook >>>>> security_locked_down_globally() >>>> This is a poor solution to the stated problem. Rather than adding >>>> a new hook you should add the task as a parameter to the existing hook >>>> and let the security modules do as they will based on its value. >>>> If the caller does not have an appropriate task it should pass NULL. >>>> The lockdown LSM can ignore the task value and SELinux can make its >>>> own decision based on the task value passed. >>> The problem with that approach is that all callers would then need to >>> be updated and I intended to keep the patch small as I'd like it to go >>> to stable kernels as well. >>> >>> But it does seem to be a better long-term solution - would it work for >>> you (and whichever maintainer would be taking the patch(es)) if I just >>> added another patch that refactors it to use the task parameter? >> I can't figure out what you're suggesting. Are you saying that you >> want to add a new hook *and* add the task parameter? > No, just to keep this patch as-is (and let it go to stable in this > form) and post another (non-stable) patch on top of it that undoes the > new hook and re-implements the fix using your suggestion. (Yeah, it'll > look weird, but I'm not sure how better to handle such situation - I'm > open to doing it whatever different way the maintainers prefer.) James gets to make the call on this one. If it was my call I would tell you to make the task parameter change and accept the backport pain. I think that as a security developer community we spend way too much time and effort trying to avoid being noticed in source trees.
On Wed, May 12, 2021 at 7:12 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > > On 5/12/2021 9:44 AM, Ondrej Mosnacek wrote: > > On Wed, May 12, 2021 at 6:18 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > >> On 5/12/2021 6:21 AM, Ondrej Mosnacek wrote: > >>> On Sat, May 8, 2021 at 12:17 AM Casey Schaufler <casey@schaufler-ca.com> wrote: > >>>> On 5/7/2021 4:40 AM, Ondrej Mosnacek wrote: > >>>>> Commit 59438b46471a ("security,lockdown,selinux: implement SELinux > >>>>> lockdown") added an implementation of the locked_down LSM hook to > >>>>> SELinux, with the aim to restrict which domains are allowed to perform > >>>>> operations that would breach lockdown. > >>>>> > >>>>> However, in several places the security_locked_down() hook is called in > >>>>> situations where the current task isn't doing any action that would > >>>>> directly breach lockdown, leading to SELinux checks that are basically > >>>>> bogus. > >>>>> > >>>>> Since in most of these situations converting the callers such that > >>>>> security_locked_down() is called in a context where the current task > >>>>> would be meaningful for SELinux is impossible or very non-trivial (and > >>>>> could lead to TOCTOU issues for the classic Lockdown LSM > >>>>> implementation), fix this by adding a separate hook > >>>>> security_locked_down_globally() > >>>> This is a poor solution to the stated problem. Rather than adding > >>>> a new hook you should add the task as a parameter to the existing hook > >>>> and let the security modules do as they will based on its value. > >>>> If the caller does not have an appropriate task it should pass NULL. > >>>> The lockdown LSM can ignore the task value and SELinux can make its > >>>> own decision based on the task value passed. > >>> The problem with that approach is that all callers would then need to > >>> be updated and I intended to keep the patch small as I'd like it to go > >>> to stable kernels as well. > >>> > >>> But it does seem to be a better long-term solution - would it work for > >>> you (and whichever maintainer would be taking the patch(es)) if I just > >>> added another patch that refactors it to use the task parameter? > >> I can't figure out what you're suggesting. Are you saying that you > >> want to add a new hook *and* add the task parameter? > > No, just to keep this patch as-is (and let it go to stable in this > > form) and post another (non-stable) patch on top of it that undoes the > > new hook and re-implements the fix using your suggestion. (Yeah, it'll > > look weird, but I'm not sure how better to handle such situation - I'm > > open to doing it whatever different way the maintainers prefer.) > > James gets to make the call on this one. If it was my call I would > tell you to make the task parameter change and accept the backport > pain. I think that as a security developer community we spend way too > much time and effort trying to avoid being noticed in source trees. Hm... actually, what about this attached patch? It switches to a single hook with a cred argument (I figured cred makes more sense than task_struct, since the rest of task_struct should be irrelevant for the LSM, anyway...) right from the start and keeps the original security_locked_down() function only as a simple wrapper around the main hook. At that point I think converting the other callers to call security_cred_locked_down() directly isn't really worth it, since the resulting calls would just be more verbose without much benefit. So I'm tempted to just leave the security_locked_down() helper as is, so that the more common pattern can be still achieved with a simpler call. What do you think? -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.
On 5/14/2021 8:12 AM, Ondrej Mosnacek wrote: > On Wed, May 12, 2021 at 7:12 PM Casey Schaufler <casey@schaufler-ca.com> wrote: >> On 5/12/2021 9:44 AM, Ondrej Mosnacek wrote: >>> On Wed, May 12, 2021 at 6:18 PM Casey Schaufler <casey@schaufler-ca.com> wrote: >>>> On 5/12/2021 6:21 AM, Ondrej Mosnacek wrote: >>>>> On Sat, May 8, 2021 at 12:17 AM Casey Schaufler <casey@schaufler-ca.com> wrote: >>>>>> On 5/7/2021 4:40 AM, Ondrej Mosnacek wrote: >>>>>>> Commit 59438b46471a ("security,lockdown,selinux: implement SELinux >>>>>>> lockdown") added an implementation of the locked_down LSM hook to >>>>>>> SELinux, with the aim to restrict which domains are allowed to perform >>>>>>> operations that would breach lockdown. >>>>>>> >>>>>>> However, in several places the security_locked_down() hook is called in >>>>>>> situations where the current task isn't doing any action that would >>>>>>> directly breach lockdown, leading to SELinux checks that are basically >>>>>>> bogus. >>>>>>> >>>>>>> Since in most of these situations converting the callers such that >>>>>>> security_locked_down() is called in a context where the current task >>>>>>> would be meaningful for SELinux is impossible or very non-trivial (and >>>>>>> could lead to TOCTOU issues for the classic Lockdown LSM >>>>>>> implementation), fix this by adding a separate hook >>>>>>> security_locked_down_globally() >>>>>> This is a poor solution to the stated problem. Rather than adding >>>>>> a new hook you should add the task as a parameter to the existing hook >>>>>> and let the security modules do as they will based on its value. >>>>>> If the caller does not have an appropriate task it should pass NULL. >>>>>> The lockdown LSM can ignore the task value and SELinux can make its >>>>>> own decision based on the task value passed. >>>>> The problem with that approach is that all callers would then need to >>>>> be updated and I intended to keep the patch small as I'd like it to go >>>>> to stable kernels as well. >>>>> >>>>> But it does seem to be a better long-term solution - would it work for >>>>> you (and whichever maintainer would be taking the patch(es)) if I just >>>>> added another patch that refactors it to use the task parameter? >>>> I can't figure out what you're suggesting. Are you saying that you >>>> want to add a new hook *and* add the task parameter? >>> No, just to keep this patch as-is (and let it go to stable in this >>> form) and post another (non-stable) patch on top of it that undoes the >>> new hook and re-implements the fix using your suggestion. (Yeah, it'll >>> look weird, but I'm not sure how better to handle such situation - I'm >>> open to doing it whatever different way the maintainers prefer.) >> James gets to make the call on this one. If it was my call I would >> tell you to make the task parameter change and accept the backport >> pain. I think that as a security developer community we spend way too >> much time and effort trying to avoid being noticed in source trees. > Hm... actually, what about this attached patch? It switches to a > single hook with a cred argument (I figured cred makes more sense than > task_struct, since the rest of task_struct should be irrelevant for > the LSM, anyway...) right from the start and keeps the original > security_locked_down() function only as a simple wrapper around the > main hook. > > At that point I think converting the other callers to call > security_cred_locked_down() directly isn't really worth it, since the > resulting calls would just be more verbose without much benefit. So > I'm tempted to just leave the security_locked_down() helper as is, so > that the more common pattern can be still achieved with a simpler > call. > > What do you think? It's still a bit kludgy, but a big improvement over the previous version. I wouldn't object to this approach. > > -- > Ondrej Mosnacek > Software Engineer, Linux Security - SELinux kernel > Red Hat, Inc.
On Sat, May 15, 2021 at 2:57 AM Casey Schaufler <casey@schaufler-ca.com> wrote: > On 5/14/2021 8:12 AM, Ondrej Mosnacek wrote: > > On Wed, May 12, 2021 at 7:12 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > >> On 5/12/2021 9:44 AM, Ondrej Mosnacek wrote: > >>> On Wed, May 12, 2021 at 6:18 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > >>>> On 5/12/2021 6:21 AM, Ondrej Mosnacek wrote: > >>>>> On Sat, May 8, 2021 at 12:17 AM Casey Schaufler <casey@schaufler-ca.com> wrote: > >>>>>> On 5/7/2021 4:40 AM, Ondrej Mosnacek wrote: > >>>>>>> Commit 59438b46471a ("security,lockdown,selinux: implement SELinux > >>>>>>> lockdown") added an implementation of the locked_down LSM hook to > >>>>>>> SELinux, with the aim to restrict which domains are allowed to perform > >>>>>>> operations that would breach lockdown. > >>>>>>> > >>>>>>> However, in several places the security_locked_down() hook is called in > >>>>>>> situations where the current task isn't doing any action that would > >>>>>>> directly breach lockdown, leading to SELinux checks that are basically > >>>>>>> bogus. > >>>>>>> > >>>>>>> Since in most of these situations converting the callers such that > >>>>>>> security_locked_down() is called in a context where the current task > >>>>>>> would be meaningful for SELinux is impossible or very non-trivial (and > >>>>>>> could lead to TOCTOU issues for the classic Lockdown LSM > >>>>>>> implementation), fix this by adding a separate hook > >>>>>>> security_locked_down_globally() > >>>>>> This is a poor solution to the stated problem. Rather than adding > >>>>>> a new hook you should add the task as a parameter to the existing hook > >>>>>> and let the security modules do as they will based on its value. > >>>>>> If the caller does not have an appropriate task it should pass NULL. > >>>>>> The lockdown LSM can ignore the task value and SELinux can make its > >>>>>> own decision based on the task value passed. > >>>>> The problem with that approach is that all callers would then need to > >>>>> be updated and I intended to keep the patch small as I'd like it to go > >>>>> to stable kernels as well. > >>>>> > >>>>> But it does seem to be a better long-term solution - would it work for > >>>>> you (and whichever maintainer would be taking the patch(es)) if I just > >>>>> added another patch that refactors it to use the task parameter? > >>>> I can't figure out what you're suggesting. Are you saying that you > >>>> want to add a new hook *and* add the task parameter? > >>> No, just to keep this patch as-is (and let it go to stable in this > >>> form) and post another (non-stable) patch on top of it that undoes the > >>> new hook and re-implements the fix using your suggestion. (Yeah, it'll > >>> look weird, but I'm not sure how better to handle such situation - I'm > >>> open to doing it whatever different way the maintainers prefer.) > >> James gets to make the call on this one. If it was my call I would > >> tell you to make the task parameter change and accept the backport > >> pain. I think that as a security developer community we spend way too > >> much time and effort trying to avoid being noticed in source trees. > > Hm... actually, what about this attached patch? It switches to a > > single hook with a cred argument (I figured cred makes more sense than > > task_struct, since the rest of task_struct should be irrelevant for > > the LSM, anyway...) right from the start and keeps the original > > security_locked_down() function only as a simple wrapper around the > > main hook. > > > > At that point I think converting the other callers to call > > security_cred_locked_down() directly isn't really worth it, since the > > resulting calls would just be more verbose without much benefit. So > > I'm tempted to just leave the security_locked_down() helper as is, so > > that the more common pattern can be still achieved with a simpler > > call. > > > > What do you think? > > It's still a bit kludgy, but a big improvement over the previous version. > I wouldn't object to this approach. Ok, thanks. I'll post it as a v2 then. -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c index 3fe37495f63d..a4bad825d424 100644 --- a/arch/powerpc/xmon/xmon.c +++ b/arch/powerpc/xmon/xmon.c @@ -298,7 +298,7 @@ static bool xmon_is_locked_down(void) static bool lockdown; if (!lockdown) { - lockdown = !!security_locked_down(LOCKDOWN_XMON_RW); + lockdown = !!security_locked_down_globally(LOCKDOWN_XMON_RW); if (lockdown) { printf("xmon: Disabled due to kernel lockdown\n"); xmon_is_ro = true; @@ -306,7 +306,7 @@ static bool xmon_is_locked_down(void) } if (!xmon_is_ro) { - xmon_is_ro = !!security_locked_down(LOCKDOWN_XMON_WR); + xmon_is_ro = !!security_locked_down_globally(LOCKDOWN_XMON_WR); if (xmon_is_ro) printf("xmon: Read-only due to kernel lockdown\n"); } diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c index 4b83cbded559..07241435efec 100644 --- a/fs/tracefs/inode.c +++ b/fs/tracefs/inode.c @@ -396,7 +396,7 @@ struct dentry *tracefs_create_file(const char *name, umode_t mode, struct dentry *dentry; struct inode *inode; - if (security_locked_down(LOCKDOWN_TRACEFS)) + if (security_locked_down_globally(LOCKDOWN_TRACEFS)) return NULL; if (!(mode & S_IFMT)) diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h index 477a597db013..d6e2a6b59277 100644 --- a/include/linux/lsm_hook_defs.h +++ b/include/linux/lsm_hook_defs.h @@ -390,6 +390,7 @@ LSM_HOOK(void, LSM_RET_VOID, bpf_prog_free_security, struct bpf_prog_aux *aux) #endif /* CONFIG_BPF_SYSCALL */ LSM_HOOK(int, 0, locked_down, enum lockdown_reason what) +LSM_HOOK(int, 0, locked_down_globally, enum lockdown_reason what) #ifdef CONFIG_PERF_EVENTS LSM_HOOK(int, 0, perf_event_open, struct perf_event_attr *attr, int type) diff --git a/include/linux/security.h b/include/linux/security.h index 8aeebd6646dc..e683dee84f46 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -468,6 +468,7 @@ int security_inode_notifysecctx(struct inode *inode, void *ctx, u32 ctxlen); int security_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen); int security_inode_getsecctx(struct inode *inode, void **ctx, u32 *ctxlen); int security_locked_down(enum lockdown_reason what); +int security_locked_down_globally(enum lockdown_reason what); #else /* CONFIG_SECURITY */ static inline int call_blocking_lsm_notifier(enum lsm_event event, void *data) @@ -1329,6 +1330,10 @@ static inline int security_locked_down(enum lockdown_reason what) { return 0; } +static inline int security_locked_down_globally(enum lockdown_reason what) +{ + return 0; +} #endif /* CONFIG_SECURITY */ #if defined(CONFIG_SECURITY) && defined(CONFIG_WATCH_QUEUE) diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index b0c45d923f0f..f43bca95b261 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -215,7 +215,7 @@ const struct bpf_func_proto bpf_probe_read_user_str_proto = { static __always_inline int bpf_probe_read_kernel_common(void *dst, u32 size, const void *unsafe_ptr) { - int ret = security_locked_down(LOCKDOWN_BPF_READ); + int ret = security_locked_down_globally(LOCKDOWN_BPF_READ); if (unlikely(ret < 0)) goto fail; @@ -246,7 +246,7 @@ const struct bpf_func_proto bpf_probe_read_kernel_proto = { static __always_inline int bpf_probe_read_kernel_str_common(void *dst, u32 size, const void *unsafe_ptr) { - int ret = security_locked_down(LOCKDOWN_BPF_READ); + int ret = security_locked_down_globally(LOCKDOWN_BPF_READ); if (unlikely(ret < 0)) goto fail; diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c index 5a0ef4361e43..5a56f74262d8 100644 --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -851,7 +851,7 @@ static int copy_user_offload(struct xfrm_state_offload *xso, struct sk_buff *skb static bool xfrm_redact(void) { return IS_ENABLED(CONFIG_SECURITY) && - security_locked_down(LOCKDOWN_XFRM_SECRET); + security_locked_down_globally(LOCKDOWN_XFRM_SECRET); } static int copy_to_user_auth(struct xfrm_algo_auth *auth, struct sk_buff *skb) diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c index 87cbdc64d272..4ac172eaa4b7 100644 --- a/security/lockdown/lockdown.c +++ b/security/lockdown/lockdown.c @@ -73,6 +73,7 @@ static int lockdown_is_locked_down(enum lockdown_reason what) static struct security_hook_list lockdown_hooks[] __lsm_ro_after_init = { LSM_HOOK_INIT(locked_down, lockdown_is_locked_down), + LSM_HOOK_INIT(locked_down_globally, lockdown_is_locked_down), }; static int __init lockdown_lsm_init(void) diff --git a/security/security.c b/security/security.c index 5ac96b16f8fa..b9b990681ae9 100644 --- a/security/security.c +++ b/security/security.c @@ -2547,6 +2547,12 @@ int security_locked_down(enum lockdown_reason what) } EXPORT_SYMBOL(security_locked_down); +int security_locked_down_globally(enum lockdown_reason what) +{ + return call_int_hook(locked_down_globally, 0, what); +} +EXPORT_SYMBOL(security_locked_down_globally); + #ifdef CONFIG_PERF_EVENTS int security_perf_event_open(struct perf_event_attr *attr, int type) {
Commit 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown") added an implementation of the locked_down LSM hook to SELinux, with the aim to restrict which domains are allowed to perform operations that would breach lockdown. However, in several places the security_locked_down() hook is called in situations where the current task isn't doing any action that would directly breach lockdown, leading to SELinux checks that are basically bogus. Since in most of these situations converting the callers such that security_locked_down() is called in a context where the current task would be meaningful for SELinux is impossible or very non-trivial (and could lead to TOCTOU issues for the classic Lockdown LSM implementation), fix this by adding a separate hook security_locked_down_globally() that is to be used in such situations and convert all these problematic callers to call this hook instead. The new hook is then left unimplemented in SELinux and in Lockdown LSM it is backed by the same implementation as the locked_down hook. The callers migrated to the new hook are: 1. arch/powerpc/xmon/xmon.c Here the hook seems to be called from non-task context and is only used for redacting some sensitive values from output sent to userspace. 2. fs/tracefs/inode.c:tracefs_create_file() Here the call is used to prevent creating new tracefs entries when the kernel is locked down. Assumes that locking down is one-way - i.e. if the hook returns non-zero once, it will never return zero again, thus no point in creating these files. 3. kernel/trace/bpf_trace.c:bpf_probe_read_kernel{,_str}_common() Called when a BPF program calls a helper that could leak kernel memory. The task context is not relevant here, since the program may very well be run in the context of a different task than the consumer of the data. See: https://bugzilla.redhat.com/show_bug.cgi?id=1955585 4. net/xfrm/xfrm_user.c:copy_to_user_*() Here a cryptographic secret is redacted based on the value returned from the hook. There are two possible actions that may lead here: a) A netlink message XFRM_MSG_GETSA with NLM_F_DUMP set - here the task context is relevant, since the dumped data is sent back to the current task. b) When deleting an SA via XFRM_MSG_DELSA, the dumped SAs are broadcasted to tasks subscribed to XFRM events - here the SELinux check is not meningful as the current task's creds do not represent the tasks that could potentially see the secret. It really doesn't seem worth it to try to preserve the check in the a) case, since the eventual leak can be circumvented anyway via b), plus there is no way for the task to indicate that it doesn't care about the actual key value, so the check could generate a lot of noise. Fixes: 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown") Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> --- arch/powerpc/xmon/xmon.c | 4 ++-- fs/tracefs/inode.c | 2 +- include/linux/lsm_hook_defs.h | 1 + include/linux/security.h | 5 +++++ kernel/trace/bpf_trace.c | 4 ++-- net/xfrm/xfrm_user.c | 2 +- security/lockdown/lockdown.c | 1 + security/security.c | 6 ++++++ 8 files changed, 19 insertions(+), 6 deletions(-)