From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933981AbcALClR (ORCPT ); Mon, 11 Jan 2016 21:41:17 -0500 Received: from mail-by2on0140.outbound.protection.outlook.com ([207.46.100.140]:42024 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932203AbcALClN (ORCPT ); Mon, 11 Jan 2016 21:41:13 -0500 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; mip-labs.com; dkim=none (message not signed) header.d=none;mip-labs.com; dmarc=none action=none header.from=juniper.net; To: David Howells CC: Mimi Zohar , James Morris , Marcel Holtmann , , , , Subject: Re: [PATCH] X.509: Partially revert patch to add validation against IMA MOK keyring In-Reply-To: <31702.1452564218@warthog.procyon.org.uk> References: <88773.1452562139@eng-mail01.juniper.net> <1452470153.2651.60.camel@linux.vnet.ibm.com> <2033.1452447990@warthog.procyon.org.uk> <1452432410.2651.40.camel@linux.vnet.ibm.com> <20160106134525.15633.73582.stgit@warthog.procyon.org.uk> <24185.1452126854@warthog.procyon.org.uk> <1452180676.2890.21.camel@linux.vnet.ibm.com> <3384.1452458018@warthog.procyon.org.uk> <27007.1452559481@warthog.procyon.org.uk> <31702.1452564218@warthog.procyon.org.uk> Comments: In-reply-to: David Howells message dated "Tue, 12 Jan 2016 02:03:38 +0000." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.5; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11FD020;1:fgw9gDXaruacgG6RbSYNUNHDUSrBkgrsWbmQL15R+bXgVH6xhGQwG9rcFM+BMxiIyQUKJnFZH4bKlzyzgMgZEJzBYEYuNX0V6OciYHP3l+vv+IxeMEFym/58uS05Pw2jBq8+4yHgX2ygwqxXa7Z017+zFghR3TM+XYY6OoECQsL9zN3EO5tn8IdNloYuub57CVVIDAzOmxz6UOmJFVSK2tcRIJWdFkjBBGe1w/5oCQmt3N6FmQ9Ly0wEbAV8FLiHc7J65nFyT43le3KqvOSo2D/8ABPxXx3Nd8KIREZdMP05Zl2lePWnMNKuYXtWegK2SEid0w0G8gmWPejtLbdcvVxo49kNvRHPFEGsKFE8hIiBhEWsS23NupVjiUty1ejxVqiU4lgwJPenahT0loBgmg== X-Forefront-Antispam-Report: CIP:66.129.239.19;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(164054003)(189002)(199003)(5001960100002)(189998001)(92566002)(5003600100002)(1220700001)(1096002)(53416004)(81156007)(50986999)(86362001)(586003)(93886004)(47776003)(6806005)(5003940100001)(11100500001)(50226001)(110136002)(2906002)(105596002)(77096005)(97736004)(4326007)(106466001)(69596002)(76176999)(117636001)(19580405001)(19580395003)(87936001)(76506005)(48376002)(50466002)(2950100001)(217873001)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BY2PR05MB064;H:p-emfe01b-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB064;2:CRodI0zqZ9Q8WO3PmK4arn0qRPk6TlENLkbKV/hV4YVskW9iCQ1jSefhp3j2vxRNdvUoaJ8mxpKv2+DyBPXFfpoTGZWDf8RG4eiWGadWz/JJlDh8kUV6RcY1vL8aYvKRJH/dQTWFziYOsQpUVCR+jA==;3:L7ygqSFpq5J3SJRHVB+kyjM+8obhTQ7mWcEVZXKZDzd7hXWJRzj1yBkFFKDfmQwLr1YGaq1em1zVjJBydFS57bfEaCuH73Coa0Pp+bckz71hvLrWt5UCyKKmzE7y/Ra1zwqILQ9Nyl0apxet9gppmCBC4dOn7tpj9UMfqbTfXBpliYOZ//xmSE9l+Dlod9Kk4ZnE8rGRiGuTZW+6BIq/0BRxJuOXhULUgZ++PTdGhwc=;25:ElBO47HEZReleL9x6YofiUgkB+mdqeouiqwkBJSPYgDpM+MRslgkSFPivA4pWq4waTmm0C8tCeVg2q14HMwismlU7m1R2LYrLb+W0TGL1ItPt72pZaDQEi2sw2iRnmEjB3XsAoHa57Qy85zuGq2ozHjM7HR4Ue34VIm6I6/iZcjTO04xoDctAjsaKfmXaSrnvJD71lY4al44Yg9e3/ehdc8px30i/U3WSb71Mo6rH4bqMWTh1KJqZKxZdnZJmW1F X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB064; X-MS-Office365-Filtering-Correlation-Id: 6390a2f4-f74c-4a84-fe7f-08d31af7ba51 X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB064;20:/O41pJaC5l8cXdKP3sXch0Cxl1hIaMobEPbAmd5GFS7DT7vUoi4Y/p7kUyKY6aGRZ2xLoDP+MNtJGPfn3zXyLfUznRt/kNS3H9glMPkVVd4UGcc7l9u95kkQcIXLMR+tbU3tqaVwmWdDFeRQmUTv/TQzKVpQKe1vS0RUsClFXXpXAOmuxSY2RIK+d3bgLA73y6JfUND7LRoFkphdkgu/HzW1/2ydkafJxan7u9I3mOBurVBghtYpZMTxZHVZfP8GFSSPQnVf4aP6v3h2Q8Bp5C6unM1GRfRBv5BeE7HznYmCkxadGLI4a5yqn7gsSmrt+VuFFJPe9knC2XZyHj72px9ZaLyUxzgBsbAdUM7aCueC56aShjKJrCczdoFl1qiCHcGWwNbNjTcH2H1N50PIpindFT9TatJjqkuXBVtEMSQ+GUS3Dm6Z1RU18OB/htDSDxpsbyps7bAa+nUxxYBbDMoLnweZ1FvE2EPuRilewVv9nyDoRl6DBKFrM8Xr0jeR;4:GqQWecfH+yAVR/lqTTrqeQXrl105ANNFb8Fdsi6PpXvx7GzI/lAWUtFnaIJGO/CVEJ8yEZqsn3pqbOw60kJ1/gxjoHAqD4lZ8TJ5+6+fiEuXlcLsjSxMZnXU7BhasYHKMglHAbnRWi6J//83Sf68Pyx4UPjRnQ6ucuSZbao0ha5NQBptW6kdHIvoY9P56GJ0ENvxhCi2pW2vf0a6CnPInYuYmtLU7lgMg8Oms5yzZZLY7pxpwFnXBX/W6D2q59Hh4Q4696pbbEctHRMBxu0ihiCetohiq8Y/1wT/sCXHyjz6WOlAQv2wT6b6LrNXYI2fnoG/hgJqQySHklMmOTTG6eUD9DvJL0gO8lqUw4JBORxcbF304JMPQ68KzbxYPcjNK9cPnCoPl5lem5oGDnGZU3JhUzfj3LwzlgMP8/ieI8TewCYwc7++qUShNEnQG27k X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(13017025)(13015025)(13018025)(8121501046)(520078)(3002001)(10201501046);SRVR:BY2PR05MB064;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB064; X-Forefront-PRVS: 081904387B X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BY2PR05MB064;23:zU5lp3oER99I3S8l2073JC+gnDIAsbpgD5PWCagOj6?= =?us-ascii?Q?IND2ykudIDlKtwasbj72BlCNynDiRZfNu5JLh9tkAvdzLNLffSDLzgMsPdvn?= =?us-ascii?Q?0g89elKISsNLshejY3KfPncSl+DKMnXWOkiuhS2aZ08iEglT+TQl3Qwjyg68?= =?us-ascii?Q?QzxeHF5jEefHGi+SxGBZQ2A/bevBtXcncnxwYkdvbIP7NabggxnvbpjSXyba?= =?us-ascii?Q?QNdZN4ahd7mDaoTbu1H8zZoP/yH+ILv0yUUibh/2NHVvBe2gNhBD/NJZ183k?= =?us-ascii?Q?oArY55YdPtnFDkKTAc6PIX4RHqworlvPnKyyXEE5E2swSvbrxZ4dyhUvdEjE?= =?us-ascii?Q?r5WI3IRIu2ETKFMtT1twVS9hLb38ITdb4a1D4TCQ7rpUspsZxoEVIrAoBHuq?= =?us-ascii?Q?e5NtyZIy/L7NptNmYWKWR75q5QftPs5/osyenUDCpOYsn6YxDumYX5+p9PV+?= =?us-ascii?Q?i6dkKbpciay7yhtvwVj5sRtZiSlGXGUkunUrln+p0t61OD+0cxqLtYRD72hr?= =?us-ascii?Q?Ki7aCfCPjjiMNX+TCqQIm0m3pvKOGGvi20j+BvzOa+cKGr4jRqcWznJQV0dX?= =?us-ascii?Q?gPIYYddFhb+rtRtr5TMVd7s37vGumq71TxPJy2sXBEcEWLiu2mLLW28jtKV/?= =?us-ascii?Q?HSj6zNOJ552jSPCMJzxGie5CJwAgGHBdxuDXKw22j+fLFzgN1C1BO5VQ9UR0?= =?us-ascii?Q?cJe3Aa2plEiqsfjPs0JWC7d8wWGb4gS5pZ2cLsQweK3y7+c8nmpbnlnkownK?= =?us-ascii?Q?Ncmc0RZ0T+IjfzA0J/aHlBd+o4AjVTf+f+MtRNrejyRpr3xSJJfVssaxJO+O?= =?us-ascii?Q?baSUGevjemSLCiDUc+y7Rfy9m8emLNiRXv87r5iTnjDWFIWRMlyVOgKz4fJ5?= =?us-ascii?Q?XW+HEwUUOHi2jLODwnwH2GEzQykHFTkqb8i0dxs+nUGjOlUpPigw7NR8kCbE?= =?us-ascii?Q?JubuB2a5lVlXR9N4Y+/IZQdkCXGu0p8emwQCqTcJRktXjePPoNSFRInLt5xA?= =?us-ascii?Q?z9vxP16bGT53ALby8W9Pk6s990QLTEwFMAq8TiTf2Kq06JL2K7bXbAt/zXP8?= =?us-ascii?Q?IkU2dZNh5iptWrBMMKL7h3Kkru?= X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB064;5:+Pd5ow6thByUAGpj49vQzA0hKE+3GSkXXB4OpPTlH4JK2wkaiLyI3/7raTjZyscPVdv4b1+wMmTc3TWHWKsACKulnst5nH/+vLPyzdpdZn9DuWMwyd2ZfcqIiLuINT/xWX/pcA2u+4AaIgOIDJ0LVg==;24:YK+yOohsIKYnIH4Yt/CsLVX4T36nCgPHeCoWGeoFVaNbGFQmUqWX0A41Zua5XaFJ0AN3u+ID9BqvDh8nAX8sGnKXnFUPx3VJlHbVdUbXHrE= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2016 02:26:07.0963 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.19];Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB064 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org David Howells writes: > Signing keys go in .ima only? Yes, that is the current intent... it is not yet clear to me if it should also be in play for any .evm keys or not. > It still doesn't clarify entirely why .ima_mok exists separately from > .system_keyring from a technical point of view. IMA is an optional subsystem. Having a keyring for it to use as needed seems more flexible to me than getting all of the .system_keyring stakeholders to agree to any new semantics that might be needed. Rules on how .system_keyring mature and are managed would seem to be something that has multiple stakeholders. If a .ima_mok exists, then we can partition the rules associated with .ima_mok additions and deletions to being a chain of trust that is used to authorize a given .ima key entry to be permitted to be used and not fight with other .system_keyring semantics. For example, keyctl clear %:.sysmtem_keyring locks out adding keys to the primary keystore. That may be exactly the correct thing to do to stop adding new LKM keys. While still allowing new keys to be added to the .ima_mok that can in turn only authorize the addition/deletion of .ima keys. With regard to a .blacklist keyring type, I have no objections to sharing a blacklist accross the system. Sometime soon I need to hunt down the [RFC PATCH 14/15] KEYS:... and figure out how the restriction functions are supposed to work. I appreciate the time you have taken to write a response to my message. I hope that I have managed to provide you have a better understanding of the goals of a multi-tenant IMA system... Thanks, -- Mark