Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965306AbbGHQii (ORCPT ); Wed, 8 Jul 2015 12:38:38 -0400 Received: from smtp104.biz.mail.bf1.yahoo.com ([98.139.221.63]:41654 "EHLO smtp104.biz.mail.bf1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934518AbbGHQib (ORCPT ); Wed, 8 Jul 2015 12:38:31 -0400 X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: URJ3NScVM1n8hdv.8AGkjkfmSCXQl_MNka8GI_A8_bYZOrX gM096Tex9oxMaLv6zrqflww9T.0Ju3XBiFt8GyOGb_jY1g2g6xztqhIP23zN AW7lo273vs8mmvHNF16zCF7pgvKMdVKWcy.hrhwAtr4ywdGinnVw9unuR6uh OeQiW02OBfylAmkbbWmIIoIzbJa3jYsu2hlu7XpDAeHYtFOAkQLwH9H8X4w3 vWTnCYDVswgpT3pOWhK1M0l60dw6DUxD.NnG55wntLjxbn33PlRvJBl4U3FA ynIp4tX4fFkJOPcDjbr7CxQi5VbGd6AG1zgen_g83EjmcB.9wVS3AHXobqig XiBSu9ngIDW0JWjeyFdb8PIItx30bweRYVe4PRUM6g3hRt3wYvO0OG2CWcaF fbjgLwYe52Bs50cdQBwJVJ7S0AjNAVxVui1xYOBmmJVklzEzJuSVr4jfT.L0 mn_nJaXiiTpWFdovgmYtzUsrsAgyBeuM5osSrZhPa138chzR2jQ30MuTShJI - X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- Message-ID: <559D5201.6060400@schaufler-ca.com> Date: Wed, 08 Jul 2015 09:38:25 -0700 From: Casey Schaufler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Smalley , Paul Osmialowski , Paul Moore , James Morris , "Serge E. Hallyn" , Kees Cook , Tetsuo Handa , Neil Brown , Mark Rustad , Greg Kroah-Hartman , Daniel Mack , David Herrmann , Djalal Harouni , Shuah Khan , Al Viro , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org CC: Karol Lewandowski , Lukasz Skalski Subject: Re: [RFC 4/8] lsm: smack: smack callbacks for kdbus security hooks References: <1436351110-5902-1-git-send-email-p.osmialowsk@samsung.com> <1436351110-5902-5-git-send-email-p.osmialowsk@samsung.com> <559D28DE.4070406@tycho.nsa.gov> In-Reply-To: <559D28DE.4070406@tycho.nsa.gov> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4767 Lines: 137 On 7/8/2015 6:42 AM, Stephen Smalley wrote: > On 07/08/2015 06:25 AM, Paul Osmialowski wrote: >> This adds implementation of three smack callbacks sitting behind kdbus >> security hooks as proposed by Karol Lewandowski. >> >> Originates from: >> >> git://git.infradead.org/users/pcmoore/selinux (branch: working-kdbus) >> commit: fc3505d058c001fe72a6f66b833e0be5b2d118f3 >> >> https://github.com/lmctl/linux.git (branch: kdbus-lsm-v4.for-systemd-v212) >> commit: 103c26fd27d1ec8c32d85dd3d85681f936ac66fb >> >> Signed-off-by: Karol Lewandowski >> Signed-off-by: Paul Osmialowski >> --- >> security/smack/smack_lsm.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 68 insertions(+) >> >> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c >> index a143328..033b756 100644 >> --- a/security/smack/smack_lsm.c >> +++ b/security/smack/smack_lsm.c >> @@ -41,6 +41,7 @@ >> #include >> #include >> #include >> +#include >> #include "smack.h" >> >> #define TRANS_TRUE "TRUE" >> @@ -3336,6 +3337,69 @@ static int smack_setprocattr(struct task_struct *p, char *name, >> } >> >> /** >> + * smack_kdbus_connect - Set the security blob for a KDBus connection >> + * @conn: the connection >> + * @secctx: smack label >> + * @seclen: smack label length >> + * >> + * Returns 0 >> + */ >> +static int smack_kdbus_connect(struct kdbus_conn *conn, >> + const char *secctx, u32 seclen) >> +{ >> + struct smack_known *skp; >> + >> + if (secctx && seclen > 0) >> + skp = smk_import_entry(secctx, seclen); >> + else >> + skp = smk_of_current(); >> + conn->security = skp; >> + >> + return 0; >> +} >> + >> +/** >> + * smack_kdbus_conn_free - Clear the security blob for a KDBus connection >> + * @conn: the connection >> + * >> + * Clears the blob pointer >> + */ >> +static void smack_kdbus_conn_free(struct kdbus_conn *conn) >> +{ >> + conn->security = NULL; >> +} >> + >> +/** >> + * smack_kdbus_talk - Smack access on KDBus >> + * @src: source kdbus connection >> + * @dst: destination kdbus connection >> + * >> + * Return 0 if a subject with the smack of sock could access >> + * an object with the smack of other, otherwise an error code >> + */ >> +static int smack_kdbus_talk(const struct kdbus_conn *src, >> + const struct kdbus_conn *dst) >> +{ >> + struct smk_audit_info ad; >> + struct smack_known *sskp = src->security; >> + struct smack_known *dskp = dst->security; >> + int ret; >> + >> + BUG_ON(sskp == NULL); >> + BUG_ON(dskp == NULL); >> + >> + if (smack_privileged(CAP_MAC_OVERRIDE)) >> + return 0; >> + >> + smk_ad_init(&ad, __func__, LSM_AUDIT_DATA_NONE); >> + >> + ret = smk_access(sskp, dskp, MAY_WRITE, &ad); >> + if (ret) >> + return ret; >> + return 0; >> +} >> + >> +/** >> * smack_unix_stream_connect - Smack access on UDS >> * @sock: one sock >> * @other: the other sock >> @@ -4393,6 +4457,10 @@ struct security_hook_list smack_hooks[] = { >> LSM_HOOK_INIT(inode_notifysecctx, smack_inode_notifysecctx), >> LSM_HOOK_INIT(inode_setsecctx, smack_inode_setsecctx), >> LSM_HOOK_INIT(inode_getsecctx, smack_inode_getsecctx), >> + >> + LSM_HOOK_INIT(kdbus_connect, smack_kdbus_connect), >> + LSM_HOOK_INIT(kdbus_conn_free, smack_kdbus_conn_free), >> + LSM_HOOK_INIT(kdbus_talk, smack_kdbus_talk), >> }; > If Smack only truly needs 3 hooks, then it begs the question of why > there are so many other hooks defined. Are the other hooks just to > support finer-grained distinctions, or is Smack's coverage incomplete? I haven't been following kdbus closely for a while, but the original intent for Smack and kdbus was that it Smack controls would be on the objects involved, and that to accomplish that only a small number of hooks would be necessary. After all, Smack uses fewer hooks than SELinux on other things. I do agree that without a user there is no point in having hooks. If SELinux requires the other hooks we might want to hold off on asking for the hooks until the SELinux implementation is exposed. I also think that AppArmor should be examined as a potential user of the hooks, just to make sure the hooks aren't excessively oriented toward subject/object based security modules. > > -- > 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/