From patchwork Tue Aug 30 17:31:39 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Casey Schaufler X-Patchwork-Id: 9305733 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A1B56607D2 for ; Tue, 30 Aug 2016 17:31:51 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 91AA428CDD for ; Tue, 30 Aug 2016 17:31:51 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8673F28CE2; Tue, 30 Aug 2016 17:31:51 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AC01728CE0 for ; Tue, 30 Aug 2016 17:31:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932745AbcH3Rbo (ORCPT ); Tue, 30 Aug 2016 13:31:44 -0400 Received: from nm9-vm0.bullet.mail.bf1.yahoo.com ([98.139.213.154]:50215 "EHLO nm9-vm0.bullet.mail.bf1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932744AbcH3Rbl (ORCPT ); Tue, 30 Aug 2016 13:31:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1472578300; bh=bhHW9EafeX0jJBuHYuzTTvANx4Dto7ytXYrqtetNOpA=; h=To:Cc:From:Subject:Date:From:Subject; b=hyZMZR0m5ZvHBwiu0CZKJBKGlVxtsMyWX0vhqkcoOq5IXO1yAxFTyLgYbx4hXDwwixklBzXs+ryd4hZdgUCbsQbc6ZZDzzA4q08Bw3BIHjBrbgL1BWyu24ka2mz3HHEN7d3OYFIRBIuWuUGZ3ZCeApSpIQGmumlifhl0F2wRghCW2pcC5Vi7fj4A1QfRFK6AIqW/69uleonpOt2EW+XJ6hgpefdcReJUJr2BWeiG3gGrEHeM3vB4HWgWzA/LXyaaYBWI1EzXzfgusiD5VFCmQs6ma/HMdybE9h+plBc+vGr57K58i+NJUSu9gwebJ82xEWea+VggXukUCXoSqoajYw== Received: from [98.139.215.141] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 30 Aug 2016 17:31:40 -0000 Received: from [68.142.230.74] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 30 Aug 2016 17:31:40 -0000 Received: from [127.0.0.1] by smtp231.mail.bf1.yahoo.com with NNFMP; 30 Aug 2016 17:31:40 -0000 X-Yahoo-Newman-Id: 399274.42239.bm@smtp231.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 9sz1SUYVM1nqWOUvYrXKjqJcFQjSwPI9KNRGOT0oYpK_4gU QoMbaM2KJ1T2k6bIY5ly5W1dlcRASYldYru4Khpk7dsnshKMibaQrfqiHiBB eUPwd0E.Gon0Aq2Fw7hk7JZstD30MslpY.fn91pMC7ZOESGhT8cQxxXBMFZg PR7W19VrRjybGgw6sY.V9UmkXhPF7xOSZrSq923cDlJZYPtMLtNp.mvmFJyS hUfecI3MD0Y.4STXCk1SG8xzFUpMMAxsIaPSUYEcKAFhKzqrTY1oKM5_q9qX A72DWbKC3_67zwMlmwK1l2cmEfKw3NXxHiK5iZQ81w0Vg9Kh4LE_eUGvxjLp fBeLFtTuRuwFqJASEXBfZRvLTU0BGVLHrcY_UP4CqQ0f_RJzOLZDM_Rqa9en hj37z1ktdMZMb44FSfD9ad1Hs3kQLrXpRotEzv.kiLEzBTZx5bFkvyWp2Djw MC2Mc2nt70lkABEchE7DhEvFD2IhP4sCXiB7hoe1.kPqccabww0I2aQyzl8B ZXRA8Q7QPnRKtjvABtP4o2.VhJxS1znDfY4gvF.V.74CfS1NqA12NlZyR3Uy b6kuuTlOVlMpX X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- To: =?UTF-8?Q?Rafa=c5=82_Krypa?= , LSM Cc: James Morris From: Casey Schaufler Subject: [PATCH] Smack: Signal delivery as an append operation Message-ID: <1c93a03b-9388-c365-19cf-d7da92fb035d@schaufler-ca.com> Date: Tue, 30 Aug 2016 10:31:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: X-Virus-Scanned: ClamAV using ClamSMTP Subject: [PATCH] Smack: Signal delivery as an append operation Under a strict subject/object security policy delivering a signal or delivering network IPC could be considered either a write or an append operation. The original choice to make both write operations leads to an issue where IPC delivery is desired under policy, but delivery of signals is not. This patch provides the option of making signal delivery an append operation, allowing Smack rules that deny signal delivery while allowing IPC. This was requested for Tizen. Signed-off-by: Casey Schaufler --- security/smack/Kconfig | 12 ++++++++++++ security/smack/smack.h | 10 ++++++++++ security/smack/smack_lsm.c | 14 +++++++------- 3 files changed, 29 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/security/smack/Kconfig b/security/smack/Kconfig index 271adae..83b8ddc 100644 --- a/security/smack/Kconfig +++ b/security/smack/Kconfig @@ -40,3 +40,15 @@ config SECURITY_SMACK_NETFILTER This enables security marking of network packets using Smack labels. If you are unsure how to answer this question, answer N. + +config SECURITY_SMACK_APPEND_SIGNALS + bool "Treat delivering signals as an append operation" + depends on SECURITY_SMACK + default n + help + Sending a signal has been treated as a write operation to the + receiving process. If this option is selected, the delivery + will be an append operation instead. This makes it possible + to differentiate between delivering a network packet and + delivering a signal in the Smack rules. + If you are unsure how to answer this question, answer N. diff --git a/security/smack/smack.h b/security/smack/smack.h index 26e58f1..51fd301 100644 --- a/security/smack/smack.h +++ b/security/smack/smack.h @@ -256,6 +256,16 @@ enum { #define MAY_LOCK 0x00002000 /* Locks should be writes, but ... */ #define MAY_BRINGUP 0x00004000 /* Report use of this rule */ +/* + * The policy for delivering signals is configurable. + * It is usually "write", but can be "append". + */ +#ifdef CONFIG_SECURITY_SMACK_APPEND_SIGNALS +#define MAY_DELIVER MAY_APPEND /* Signal delivery requires append */ +#else +#define MAY_DELIVER MAY_WRITE /* Signal delivery requires write */ +#endif + #define SMACK_BRINGUP_ALLOW 1 /* Allow bringup mode */ #define SMACK_UNCONFINED_SUBJECT 2 /* Allow unconfined label */ #define SMACK_UNCONFINED_OBJECT 3 /* Allow unconfined label */ diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c index 87a9741..caec225 100644 --- a/security/smack/smack_lsm.c +++ b/security/smack/smack_lsm.c @@ -1857,14 +1857,14 @@ static int smack_file_send_sigiotask(struct task_struct *tsk, /* we don't log here as rc can be overriden */ skp = file->f_security; - rc = smk_access(skp, tkp, MAY_WRITE, NULL); - rc = smk_bu_note("sigiotask", skp, tkp, MAY_WRITE, rc); + rc = smk_access(skp, tkp, MAY_DELIVER, NULL); + rc = smk_bu_note("sigiotask", skp, tkp, MAY_DELIVER, rc); if (rc != 0 && has_capability(tsk, CAP_MAC_OVERRIDE)) rc = 0; smk_ad_init(&ad, __func__, LSM_AUDIT_DATA_TASK); smk_ad_setfield_u_tsk(&ad, tsk); - smack_log(skp->smk_known, tkp->smk_known, MAY_WRITE, rc, &ad); + smack_log(skp->smk_known, tkp->smk_known, MAY_DELIVER, rc, &ad); return rc; } @@ -2265,8 +2265,8 @@ static int smack_task_kill(struct task_struct *p, struct siginfo *info, * can write the receiver. */ if (secid == 0) { - rc = smk_curacc(tkp, MAY_WRITE, &ad); - rc = smk_bu_task(p, MAY_WRITE, rc); + rc = smk_curacc(tkp, MAY_DELIVER, &ad); + rc = smk_bu_task(p, MAY_DELIVER, rc); return rc; } /* @@ -2275,8 +2275,8 @@ static int smack_task_kill(struct task_struct *p, struct siginfo *info, * we can't take privilege into account. */ skp = smack_from_secid(secid); - rc = smk_access(skp, tkp, MAY_WRITE, &ad); - rc = smk_bu_note("USB signal", skp, tkp, MAY_WRITE, rc); + rc = smk_access(skp, tkp, MAY_DELIVER, &ad); + rc = smk_bu_note("USB signal", skp, tkp, MAY_DELIVER, rc); return rc; }