From: "Vladimir D. Seleznev" <vseleznv@altlinux.org> To: ALT Linux kernel packages development <devel-kernel@lists.altlinux.org> Subject: Re: [d-kernel] [PATCH] AltHa: nosuid handles capabilities as well Date: Thu, 28 Apr 2022 12:42:52 +0300 Message-ID: <YmphnLHk5K+81M9g@portlab> (raw) In-Reply-To: <20220426210944.zio64lx5gg3ayq52@altlinux.org> On Wed, Apr 27, 2022 at 12:09:44AM +0300, Vitaly Chikunov wrote: > Vladimir, > > On Tue, Apr 26, 2022 at 09:47:33AM +0000, Vladimir D. Seleznev wrote: > > Signed-off-by: Vladimir D. Seleznev <vseleznv@altlinux.org> > > --- > > Documentation/admin-guide/LSM/AltHa.rst | 6 ++-- > > security/altha/altha_lsm.c | 37 ++++++++++++++++++++----- > > 2 files changed, 33 insertions(+), 10 deletions(-) > > > > diff --git a/Documentation/admin-guide/LSM/AltHa.rst b/Documentation/admin-guide/LSM/AltHa.rst > > index be698709d3f0..beda40601c9e 100644 > > --- a/Documentation/admin-guide/LSM/AltHa.rst > > +++ b/Documentation/admin-guide/LSM/AltHa.rst > > @@ -3,7 +3,7 @@ AltHa > > ==== > > > > AltHa is a Linux Security Module currently has three userspace hardening options: > > - * ignore SUID on binaries (with exceptions possible); > > + * ignore SUID and setcaps on binaries (with exceptions possible); > > * prevent running selected script interpreters in interactive mode; > > * disable open file unlinking in selected dirs. > > * enable kiosk mode > > @@ -15,12 +15,12 @@ through sysctls in ``/proc/sys/kernel/altha``. > > > > NoSUID > > ============ > > -Modern Linux systems can be used with minimal (or even zero at least for OWL and ALT) usage of SUID programms, but in many cases in full-featured desktop or server systems there are plenty of them: uncounted and sometimes unnecessary. Privileged programms are always an attack surface, but mounting filesystems with ``nosuid`` flag doesn't provide enough granularity in SUID binaries management. This LSM module provides a single control point for all SUID binaries. When this submodule is enabled, SUID bits on all binaries except explicitly listed are system-wide ignored. > > +Modern Linux systems can be used with minimal (or even zero at least for OWL and ALT) usage of SUID programms, but in many cases in full-featured desktop or server systems there are plenty of them: uncounted and sometimes unnecessary. Privileged programms are always an attack surface, but mounting filesystems with ``nosuid`` flag doesn't provide enough granularity in SUID binaries management. This LSM module provides a single control point for all SUID and setcap binaries. When this submodule is enabled, SUID and setcap bits on all binaries except explicitly listed are system-wide ignored. > > > > Sysctl parameters and defaults: > > > > * ``kernel.altha.nosuid.enabled = 0``, set to 1 to enable > > -* ``kernel.altha.nosuid.exceptions =``, colon-separated list of enabled SUID binaries, for example: ``/bin/su:/usr/libexec/hasher-priv/hasher-priv`` > > +* ``kernel.altha.nosuid.exceptions =``, colon-separated list of enabled SUID and setcap binaries, for example: ``/bin/su:/usr/libexec/hasher-priv/hasher-priv`` > > > > RestrScript > > ============ > > diff --git a/security/altha/altha_lsm.c b/security/altha/altha_lsm.c > > index c670ad7ed458..5f0505a51644 100644 > > --- a/security/altha/altha_lsm.c > > +++ b/security/altha/altha_lsm.c > > @@ -11,6 +11,7 @@ > > > > #include <linux/lsm_hooks.h> > > #include <linux/cred.h> > > +#include <linux/capability.h> > > #include <linux/sysctl.h> > > #include <linux/binfmts.h> > > #include <linux/file.h> > > @@ -237,10 +238,20 @@ int is_olock_dir(struct inode *inode) > > return 0; > > } > > > > +static int has_any_caps(struct cred *cred) > > +{ > > + return !cap_isclear(cred->cap_permitted) || > > + !cap_isclear(cred->cap_effective); > > + > > + return 0; > > +} > > + > > /* Hooks */ > > static int altha_bprm_creds_from_file(struct linux_binprm *bprm, struct file * fi) > > { > > struct altha_list_struct *node; > > + int is_set_caps = 0; > > + char *set_uid_cap = "setuid"; > > /* when it's not a shebang issued script interpreter */ > > if (rstrscript_enabled && bprm->executable == bprm->interpreter) { > > char *path_p; > > @@ -267,11 +278,18 @@ static int altha_bprm_creds_from_file(struct linux_binprm *bprm, struct file * f > > up_read(&interpreters_sem); > > kfree(path_buffer); > > } > > - if (unlikely(nosuid_enabled && > > - !uid_eq(bprm->cred->uid, bprm->cred->euid))) { > > + if (nosuid_enabled) { > > char *path_p; > > char *path_buffer; > > uid_t cur_uid; > > + uid_t cur_euid = from_kuid(bprm->cred->user_ns, bprm->cred->euid); > > + /* Check for any caps for non-superuser. */ > > + if (cur_euid != (uid_t) 0 > > + && has_any_caps(bprm->cred)) { > > Логика этого не понятна. Было бы неплохо чтоб она была пояснена в > комментариях чтоб и простые люди могли её понять. > > Почему caps проверяются только для non-superuser? Ведь и superuser может > сбрасывать capabilities. У superuser может не быть каких-то capabilities > вплоть до никаких, кроме его uid 0. Следовательно, установка new > capabilities не должна зависеть от uid. Вероятно, сбрасывать caps следует и для процессов с euid == 0, а проверять для них их наличие полагаю излишним. > Далее, capabilities могут устанавливаться не все, но если в этой > проверке были обнаружены capabilities, то далее suid игнорируются > и не сбрасываются если они были. Что будет если установлены > одновременно и setcap, и suid? Не понял этой мысли, по коду caps проверяются только есть *не* был обнаружен suid. > Неплохо было бы, чтоб это все было пояснено в комментариях. Например, > почему не важно не сбрасывать suid при setcap. > > Thanks, > > > + is_set_caps = 1; > > + set_uid_cap = "setcap"; > > + } else if (uid_eq(bprm->cred->uid, bprm->cred->euid)) > > + return 0; > > > > path_buffer = kmalloc(PATH_MAX, GFP_KERNEL); > > if (!path_buffer) > > @@ -283,8 +301,8 @@ static int altha_bprm_creds_from_file(struct linux_binprm *bprm, struct file * f > > list_for_each_entry(node, &nosuid_exceptions_list, list) { > > if (strcmp(path_p, node->spath) == 0) { > > pr_notice_ratelimited > > - ("AltHa/NoSUID: %s permitted to setuid from %d\n", > > - bprm->filename, cur_uid); > > + ("AltHa/NoSUID: %s permitted to %s from %d\n", > > + bprm->filename, set_uid_cap, cur_uid); > > up_read(&nosuid_exceptions_sem); > > kfree(path_buffer); > > return 0; > > @@ -292,9 +310,14 @@ static int altha_bprm_creds_from_file(struct linux_binprm *bprm, struct file * f > > } > > up_read(&nosuid_exceptions_sem); > > pr_notice_ratelimited > > - ("AltHa/NoSUID: %s prevented to setuid from %d\n", > > - bprm->filename, cur_uid); > > - bprm->cred->euid = bprm->cred->uid; > > + ("AltHa/NoSUID: %s prevented to %s from %d\n", > > + bprm->filename, set_uid_cap, cur_uid); > > + if (is_set_caps) { > > + cap_clear(bprm->cred->cap_inheritable); > > + cap_clear(bprm->cred->cap_permitted); > > + cap_clear(bprm->cred->cap_effective); > > + } else > > + bprm->cred->euid = bprm->cred->uid; > > kfree(path_buffer); > > } > > return 0; > > -- > > 2.33.2 -- WBR, Vladimir D. Seleznev
next prev parent reply other threads:[~2022-04-28 9:42 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-26 9:47 [d-kernel] (без темы) Vladimir D. Seleznev 2022-04-26 9:47 ` [d-kernel] [PATCH] AltHa: nosuid handles capabilities as well Vladimir D. Seleznev 2022-04-26 21:09 ` Vitaly Chikunov 2022-04-28 9:42 ` Vladimir D. Seleznev [this message] 2022-04-28 22:18 ` Vitaly Chikunov 2022-04-28 23:24 ` Vladimir D. Seleznev 2022-04-29 0:04 ` Vitaly Chikunov 2022-04-26 19:23 ` [d-kernel] (без темы) " Vitaly Chikunov 2022-04-28 14:55 ` [d-kernel] [PATCH] " Vladimir D. Seleznev 2022-04-28 14:59 ` [d-kernel] AltHa Covers capabilities Vladimir D. Seleznev 2022-04-28 14:59 ` [d-kernel] [PATCH] AltHa: nosuid handles capabilities as well Vladimir D. Seleznev 2022-05-05 15:55 ` Vitaly Chikunov 2022-05-05 23:45 ` Vladimir D. Seleznev 2022-05-09 11:47 ` Vitaly Chikunov 2022-05-10 21:36 ` Vladimir D. Seleznev
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YmphnLHk5K+81M9g@portlab \ --to=vseleznv@altlinux.org \ --cc=devel-kernel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux kernel packages development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-kernel/0 devel-kernel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel-kernel devel-kernel/ http://lore.altlinux.org/devel-kernel \ devel-kernel@altlinux.org devel-kernel@altlinux.ru devel-kernel@altlinux.com public-inbox-index devel-kernel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git