Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp710751pxb; Wed, 20 Jan 2021 19:32:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJxRIPddDDMMB26lcVWDbfHMiunOFOuWeE+bYtUgdKJj9piY1cXaHVsMDuMeiovmZozNU+2u X-Received: by 2002:a17:906:a48:: with SMTP id x8mr7793364ejf.444.1611199945587; Wed, 20 Jan 2021 19:32:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611199945; cv=none; d=google.com; s=arc-20160816; b=FrHUArsf4r+Fq8RTMMojcR6jCUxxZgmJUpJMY82x16yQAw2729pAkdurTsqDo4USrJ Gk+PxS6/SoQVNDeqnTV/oo2vzGWwUpmVgB4ohZQpfU0YQcsFNYQsjv2dfNqL/7Qu5A+z hvMYKlolJuGrT6WbUY0l0AO5sMRBhQre3wS3Hnm+3zd4epC3eDZkM8OocsRjAwA33XFw oyy85MTa5/9VfnD7OCPVyv6/7QLwk1zXy0/kY58XaCIdrBVuKD6R0GERMMKbqiuEwegN hDBYYHXE2pEq07wrYKmswW3uzm9NrPL0eO8TCmwEt762jQUnDOuOag5EyQzqSzkH/PH2 huPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:mime-version:user-agent:message-id :in-reply-to:date:references:cc:to:from; bh=21dkrd8VMs8etloFn8PLobKs6/vGLe1QqWBSjMwmTXY=; b=MA9YxeYBnK2zygGycVoorFhhKmkuByl2PdmC+ZrtcpjhzKxRY3ojdaNs6rt+wh9e4E 9ViCnm0h36IjGuxpqEOLYDEWYy0H6BN57XTJyXeUZ93YBi3EG2Bp4QzWZQk+wrMMGvfx tp8bze6374NLcWdsKuhkD/UdPfeXacZ2OEfHzdn1J/YJxj6pvc6SxdFXSuLzfU4KKiUi VpzP8TXYR3njZ+1uKm0h7gKliIdGkznjkMkQgxxrl5ipAjFYFR6tOI64nQsX0Vlb+DJb SzEil7Cdd6Q1b4r/TDbo1VknZ+1SD6C3qmDXiLqbHa/Cd6WUNzufuthRlLx84LD7HK4s H0/w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b12si1440098edq.456.2021.01.20.19.32.02; Wed, 20 Jan 2021 19:32:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404834AbhATX4Y (ORCPT + 99 others); Wed, 20 Jan 2021 18:56:24 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:51732 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730489AbhATVkE (ORCPT ); Wed, 20 Jan 2021 16:40:04 -0500 Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l2LC9-0034Ap-3R; Wed, 20 Jan 2021 14:39:17 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l2LC7-00GWBM-Sq; Wed, 20 Jan 2021 14:39:16 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: linux-security-module@vger.kernel.org Cc: Andy Lutomirski , Kees Cook , James Morris , John Johansen , apparmor@lists.ubuntu.com, , Linus Torvalds References: <87lfcn5mfz.fsf@x220.int.ebiederm.org> Date: Wed, 20 Jan 2021 15:38:05 -0600 In-Reply-To: <87lfcn5mfz.fsf@x220.int.ebiederm.org> (Eric W. Biederman's message of "Wed, 20 Jan 2021 15:26:56 -0600") Message-ID: <87eeif5lxe.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1l2LC7-00GWBM-Sq;;;mid=<87eeif5lxe.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19JxT8+vqmhKq7/a7+VJ6sST9427zsCsPM= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa01.xmission.com X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,TR_Symld_Words,T_TM2_M_HEADER_IN_MSG,XMSubLong autolearn=disabled version=3.4.2 X-Spam-Virus: No X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * 0.7 XMSubLong Long Subject * 1.5 TR_Symld_Words too many words that have symbols inside * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;linux-security-module@vger.kernel.org X-Spam-Relay-Country: X-Spam-Timing: total 654 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 4.4 (0.7%), b_tie_ro: 3.0 (0.5%), parse: 1.40 (0.2%), extract_message_metadata: 13 (2.0%), get_uri_detail_list: 4.7 (0.7%), tests_pri_-1000: 10 (1.6%), tests_pri_-950: 1.02 (0.2%), tests_pri_-900: 0.80 (0.1%), tests_pri_-90: 89 (13.6%), check_bayes: 87 (13.4%), b_tokenize: 12 (1.9%), b_tok_get_all: 12 (1.8%), b_comp_prob: 3.5 (0.5%), b_tok_touch_all: 57 (8.7%), b_finish: 0.75 (0.1%), tests_pri_0: 524 (80.1%), check_dkim_signature: 0.46 (0.1%), check_dkim_adsp: 2.3 (0.4%), poll_dns_idle: 1.02 (0.2%), tests_pri_10: 1.68 (0.3%), tests_pri_500: 5 (0.8%), rewrite_mail: 0.00 (0.0%) Subject: Re: [RFC][PATCH] apparmor: Enforce progressively tighter permissions for no_new_privs X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This should now Cc the correct email address for James Morris. ebiederm@xmission.com (Eric W. Biederman) writes: > The current understanding of apparmor with respect to no_new_privs is at > odds with how no_new_privs is implemented and understood by the rest of > the kernel. > > The documentation of no_new_privs states: >> With ``no_new_privs`` set, ``execve()`` promises not to grant the >> privilege to do anything that could not have been done without the >> execve call. > > And reading through the kernel except for apparmor that description > matches what is implemented. > > There are two major divergences of apparmor from this definition: > - proc_setattr enforces limitations when no_new_privs are set. > - the limitation is enforced from the apparent time when no_new_privs is > set instead of guaranteeing that each execve has progressively more > narrow permissions. > > The code in apparmor that attempts to discover the apparmor label at the > point where no_new_privs is set is not robust. The capture happens a > long time after no_new_privs is set. > > Capturing the label at the point where no_new_privs is set is > practically impossible to implement robustly. Today the rule is struct > cred can only be changed by it's current task. Today > SECCOMP_FILTER_FLAG_TSYNC sets no_new_privs from another thread. A > robust implementation would require changing something fundamental in > how creds are managed for SECCOMP_FILTER_FLAG_TSYNC to be able to > capture the cred at the point it is set. > > Futhermore given the consistent documentation and how everything else > implements no_new_privs, not having the permissions get progressively > tighter is a footgun aimed at userspace. I fully expect it to break any > security sensitive software that uses no_new_privs and was not > deliberately designed and tested against apparmor. > > Avoid the questionable and hard to fix implementation and the > potential to confuse userspace by having no_new_privs enforce > progressinvely tighter permissions. > > Fixes: 9fcf78cca198 ("apparmor: update domain transitions that are subsets of confinement at nnp") > Signed-off-by: Eric W. Biederman > --- > > I came accross this while examining the places cred_guard_mutex is > used and trying to find a way to make those code paths less insane. > > If it would be more pallatable I would not mind removing the > task_no_new_privs test entirely from aa_change_hat and aa_change_profile > as those are not part of exec, so arguably no_new_privs should not care > about them at all. > > Can we please get rid of the huge semantic wart and pain in the implementation? > > security/apparmor/domain.c | 39 ++++---------------------------- > security/apparmor/include/task.h | 4 ---- > security/apparmor/task.c | 7 ------ > 3 files changed, 4 insertions(+), 46 deletions(-) > > diff --git a/security/apparmor/domain.c b/security/apparmor/domain.c > index f919ebd042fd..8f77059bf890 100644 > --- a/security/apparmor/domain.c > +++ b/security/apparmor/domain.c > @@ -869,17 +869,6 @@ int apparmor_bprm_creds_for_exec(struct linux_binprm *bprm) > > label = aa_get_newest_label(cred_label(bprm->cred)); > > - /* > - * Detect no new privs being set, and store the label it > - * occurred under. Ideally this would happen when nnp > - * is set but there isn't a good way to do that yet. > - * > - * Testing for unconfined must be done before the subset test > - */ > - if ((bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS) && !unconfined(label) && > - !ctx->nnp) > - ctx->nnp = aa_get_label(label); > - > /* buffer freed below, name is pointer into buffer */ > buffer = aa_get_buffer(false); > if (!buffer) { > @@ -915,7 +904,7 @@ int apparmor_bprm_creds_for_exec(struct linux_binprm *bprm) > */ > if ((bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS) && > !unconfined(label) && > - !aa_label_is_unconfined_subset(new, ctx->nnp)) { > + !aa_label_is_unconfined_subset(new, label)) { > error = -EPERM; > info = "no new privs"; > goto audit; > @@ -1158,16 +1147,6 @@ int aa_change_hat(const char *hats[], int count, u64 token, int flags) > label = aa_get_newest_cred_label(cred); > previous = aa_get_newest_label(ctx->previous); > > - /* > - * Detect no new privs being set, and store the label it > - * occurred under. Ideally this would happen when nnp > - * is set but there isn't a good way to do that yet. > - * > - * Testing for unconfined must be done before the subset test > - */ > - if (task_no_new_privs(current) && !unconfined(label) && !ctx->nnp) > - ctx->nnp = aa_get_label(label); > - > if (unconfined(label)) { > info = "unconfined can not change_hat"; > error = -EPERM; > @@ -1193,7 +1172,7 @@ int aa_change_hat(const char *hats[], int count, u64 token, int flags) > * reduce restrictions. > */ > if (task_no_new_privs(current) && !unconfined(label) && > - !aa_label_is_unconfined_subset(new, ctx->nnp)) { > + !aa_label_is_unconfined_subset(new, label)) { > /* not an apparmor denial per se, so don't log it */ > AA_DEBUG("no_new_privs - change_hat denied"); > error = -EPERM; > @@ -1214,7 +1193,7 @@ int aa_change_hat(const char *hats[], int count, u64 token, int flags) > * reduce restrictions. > */ > if (task_no_new_privs(current) && !unconfined(label) && > - !aa_label_is_unconfined_subset(previous, ctx->nnp)) { > + !aa_label_is_unconfined_subset(previous, label)) { > /* not an apparmor denial per se, so don't log it */ > AA_DEBUG("no_new_privs - change_hat denied"); > error = -EPERM; > @@ -1303,16 +1282,6 @@ int aa_change_profile(const char *fqname, int flags) > > label = aa_get_current_label(); > > - /* > - * Detect no new privs being set, and store the label it > - * occurred under. Ideally this would happen when nnp > - * is set but there isn't a good way to do that yet. > - * > - * Testing for unconfined must be done before the subset test > - */ > - if (task_no_new_privs(current) && !unconfined(label) && !ctx->nnp) > - ctx->nnp = aa_get_label(label); > - > if (!fqname || !*fqname) { > aa_put_label(label); > AA_DEBUG("no profile name"); > @@ -1409,7 +1378,7 @@ int aa_change_profile(const char *fqname, int flags) > * reduce restrictions. > */ > if (task_no_new_privs(current) && !unconfined(label) && > - !aa_label_is_unconfined_subset(new, ctx->nnp)) { > + !aa_label_is_unconfined_subset(new, label)) { > /* not an apparmor denial per se, so don't log it */ > AA_DEBUG("no_new_privs - change_hat denied"); > error = -EPERM; > diff --git a/security/apparmor/include/task.h b/security/apparmor/include/task.h > index f13d12373b25..8a9c258e2018 100644 > --- a/security/apparmor/include/task.h > +++ b/security/apparmor/include/task.h > @@ -17,13 +17,11 @@ static inline struct aa_task_ctx *task_ctx(struct task_struct *task) > > /* > * struct aa_task_ctx - information for current task label change > - * @nnp: snapshot of label at time of no_new_privs > * @onexec: profile to transition to on next exec (MAY BE NULL) > * @previous: profile the task may return to (MAY BE NULL) > * @token: magic value the task must know for returning to @previous_profile > */ > struct aa_task_ctx { > - struct aa_label *nnp; > struct aa_label *onexec; > struct aa_label *previous; > u64 token; > @@ -42,7 +40,6 @@ struct aa_label *aa_get_task_label(struct task_struct *task); > static inline void aa_free_task_ctx(struct aa_task_ctx *ctx) > { > if (ctx) { > - aa_put_label(ctx->nnp); > aa_put_label(ctx->previous); > aa_put_label(ctx->onexec); > } > @@ -57,7 +54,6 @@ static inline void aa_dup_task_ctx(struct aa_task_ctx *new, > const struct aa_task_ctx *old) > { > *new = *old; > - aa_get_label(new->nnp); > aa_get_label(new->previous); > aa_get_label(new->onexec); > } > diff --git a/security/apparmor/task.c b/security/apparmor/task.c > index d17130ee6795..4b9ec370a171 100644 > --- a/security/apparmor/task.c > +++ b/security/apparmor/task.c > @@ -41,7 +41,6 @@ struct aa_label *aa_get_task_label(struct task_struct *task) > int aa_replace_current_label(struct aa_label *label) > { > struct aa_label *old = aa_current_raw_label(); > - struct aa_task_ctx *ctx = task_ctx(current); > struct cred *new; > > AA_BUG(!label); > @@ -56,12 +55,6 @@ int aa_replace_current_label(struct aa_label *label) > if (!new) > return -ENOMEM; > > - if (ctx->nnp && label_is_stale(ctx->nnp)) { > - struct aa_label *tmp = ctx->nnp; > - > - ctx->nnp = aa_get_newest_label(tmp); > - aa_put_label(tmp); > - } > if (unconfined(label) || (labels_ns(old) != labels_ns(label))) > /* > * if switching to unconfined or a different label namespace