* Re: [GIT PULL] Security subsystem: Smack updates for v5.2
From: Linus Torvalds @ 2019-05-10 16:54 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: LSM List
In-Reply-To: <f7420347-a926-e923-9914-714ead9298ec@I-love.SAKURA.ne.jp>
On Fri, May 10, 2019 at 3:50 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> but I don't maintain a git tree for sending pull requests.
Any chance you would do so?
Anyway, I am not suggesting we change anything this merge window,
that's just too painful and would be too chaotic. But I'd love for
this to be sorted out by the next one, perhaps?
Linus
^ permalink raw reply
* Re: [PATCH 03/16] lib,treewide: add new match_string() helper/macro
From: andriy.shevchenko @ 2019-05-10 14:34 UTC (permalink / raw)
To: Ardelean, Alexandru
Cc: gregkh@linuxfoundation.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
linux-usb@vger.kernel.org, linux-mmc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, cgroups@vger.kernel.org,
intel-gfx@lists.freedesktop.org, linux-pm@vger.kernel.org,
linux-mm@kvack.org, linux-omap@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-security-module@vger.kernel.org,
devel@driverdev.osuosl.org, linux-integrity@vger.kernel.org,
linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-rpi-kernel@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
alsa-devel@alsa-project.org, linux-rockchip@lists.infradead.org,
linux-clk@vger.kernel.org, linux-pci@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-tegra@vger.kernel.org
In-Reply-To: <4df165bc4247e60aa4952fd55cb0c77e60712767.camel@analog.com>
On Fri, May 10, 2019 at 09:15:27AM +0000, Ardelean, Alexandru wrote:
> On Wed, 2019-05-08 at 16:22 +0300, Alexandru Ardelean wrote:
> > On Wed, 2019-05-08 at 15:18 +0200, Greg KH wrote:
> > > On Wed, May 08, 2019 at 04:11:28PM +0300, Andy Shevchenko wrote:
> > > > On Wed, May 08, 2019 at 02:28:29PM +0300, Alexandru Ardelean wrote:
> > > > Can you split include/linux/ change from the rest?
> > >
> > > That would break the build, why do you want it split out? This makes
> > > sense all as a single patch to me.
> > >
> >
> > Not really.
> > It would be just be the new match_string() helper/macro in a new commit.
> > And the conversions of the simple users of match_string() (the ones using
> > ARRAY_SIZE()) in another commit.
> >
>
> I should have asked in my previous reply.
> Leave this as-is or re-formulate in 2 patches ?
Depends on on what you would like to spend your time: collecting Acks for all
pieces in treewide patch or send new API first followed up by per driver /
module update in next cycle.
I also have no strong preference.
And I think it's good to add Heikki Krogerus to Cc list for both patch series,
since he is the author of sysfs variant and may have something to comment on
the rest.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk
From: Mimi Zohar @ 2019-05-10 11:49 UTC (permalink / raw)
To: Roberto Sassu, Rob Landley, viro
Cc: linux-security-module, linux-integrity, initramfs, linux-api,
linux-fsdevel, linux-kernel, zohar, silviu.vlasceanu,
dmitry.kasatkin, takondra, kamensky, hpa, arnd, james.w.mcmechan
In-Reply-To: <bf0d02fc-d6ce-ef1d-bb7d-7ca14432c6fd@huawei.com>
On Fri, 2019-05-10 at 08:56 +0200, Roberto Sassu wrote:
> On 5/9/2019 8:34 PM, Rob Landley wrote:
> > On 5/9/19 6:24 AM, Roberto Sassu wrote:
> >> The difference with another proposal
> >> (https://lore.kernel.org/patchwork/cover/888071/) is that xattrs can be
> >> included in an image without changing the image format, as opposed to
> >> defining a new one. As seen from the discussion, if a new format has to be
> >> defined, it should fix the issues of the existing format, which requires
> >> more time.
> >
> > So you've explicitly chosen _not_ to address Y2038 while you're there.
>
> Can you be more specific?
Right, this patch set avoids incrementing the CPIO magic number and
the resulting changes required (eg. increasing the timestamp field
size), by including a file with the security xattrs in the CPIO. In
either case, including the security xattrs in the initramfs header or
as a separate file, the initramfs, itself, needs to be signed.
Mimi
^ permalink raw reply
* Re: [GIT PULL] Security subsystem: Smack updates for v5.2
From: Tetsuo Handa @ 2019-05-10 10:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: LSM List
In-Reply-To: <CAHk-=wjjfZSxaivGyE0A3S2ZHCi=BVGdwG4++QVS80OTshBR1Q@mail.gmail.com>
Hello, Linus.
On 2019/05/10 5:02, Linus Torvalds wrote:
> Security subsystem guys: just send your pull requests to me directly.
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-tomoyo
contains 4 patches for this merge window
commit cff0e6c3ec3e6230 ("tomoyo: Add a kernel config option for fuzzing testing.")
commit ffd7af3def1985e0 ("tomoyo: Check address length before reading address family")
commit 5385195a7b57cb3d ("tomoyo: Change pathname calculation for read-only filesystems.")
commit 5c6b31e31adc31bd ("tomoyo: Don't emit WARNING: string while fuzzing testing.")
but I don't maintain a git tree for sending pull requests.
May I send these patches to you using below command line?
git format-patch -4
git send-email --to=you --cc=lsm-ml 000[1-4]-tomoyo-*.patch
^ permalink raw reply
* Re: [PATCH 03/16] lib,treewide: add new match_string() helper/macro
From: Ardelean, Alexandru @ 2019-05-10 9:15 UTC (permalink / raw)
To: andriy.shevchenko@linux.intel.com, gregkh@linuxfoundation.org
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-ide@vger.kernel.org, linux-usb@vger.kernel.org,
linux-mmc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
cgroups@vger.kernel.org, intel-gfx@lists.freedesktop.org,
linux-pm@vger.kernel.org, linux-mm@kvack.org,
linux-omap@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-security-module@vger.kernel.org, devel@driverdev.osuosl.org,
linux-integrity@vger.kernel.org, linux-fbdev@vger.kernel.org,
dri-devel@lists.freedesktop.org,
linux-rpi-kernel@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
alsa-devel@alsa-project.org, linux-rockchip@lists.infradead.org,
linux-clk@vger.kernel.org, linux-pci@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-tegra@vger.kernel.org
In-Reply-To: <b2440bc9485456a7a90a488c528997587b22088b.camel@analog.com>
On Wed, 2019-05-08 at 16:22 +0300, Alexandru Ardelean wrote:
> On Wed, 2019-05-08 at 15:18 +0200, Greg KH wrote:
> >
> >
> > On Wed, May 08, 2019 at 04:11:28PM +0300, Andy Shevchenko wrote:
> > > On Wed, May 08, 2019 at 02:28:29PM +0300, Alexandru Ardelean wrote:
> > > > This change re-introduces `match_string()` as a macro that uses
> > > > ARRAY_SIZE() to compute the size of the array.
> > > > The macro is added in all the places that do
> > > > `match_string(_a, ARRAY_SIZE(_a), s)`, since the change is pretty
> > > > straightforward.
> > >
> > > Can you split include/linux/ change from the rest?
> >
> > That would break the build, why do you want it split out? This makes
> > sense all as a single patch to me.
> >
>
> Not really.
> It would be just be the new match_string() helper/macro in a new commit.
> And the conversions of the simple users of match_string() (the ones using
> ARRAY_SIZE()) in another commit.
>
I should have asked in my previous reply.
Leave this as-is or re-formulate in 2 patches ?
No strong preference from my side.
Thanks
Alex
> Thanks
> Alex
>
> > thanks,
> >
> > greg k-h
^ permalink raw reply
* Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk
From: Roberto Sassu @ 2019-05-10 6:56 UTC (permalink / raw)
To: Rob Landley, viro
Cc: linux-security-module, linux-integrity, initramfs, linux-api,
linux-fsdevel, linux-kernel, zohar, silviu.vlasceanu,
dmitry.kasatkin, takondra, kamensky, hpa, arnd, james.w.mcmechan
In-Reply-To: <fca8e601-1144-1bb8-c007-518651f624a5@landley.net>
On 5/9/2019 8:34 PM, Rob Landley wrote:
> On 5/9/19 6:24 AM, Roberto Sassu wrote:
>> This patch set aims at solving the following use case: appraise files from
>> the initial ram disk. To do that, IMA checks the signature/hash from the
>> security.ima xattr. Unfortunately, this use case cannot be implemented
>> currently, as the CPIO format does not support xattrs.
>>
>> This proposal consists in marshaling pathnames and xattrs in a file called
>> .xattr-list. They are unmarshaled by the CPIO parser after all files have
>> been extracted.
>
> So it's in-band signalling that has a higher peak memory requirement.
This can be modified. Now I allocate the memory necessary for the path
and all xattrs of a file (max: .xattr-list size - 10 bytes). I could
process each xattr individually (max: 255 + 1 + 65536 bytes).
>> The difference with another proposal
>> (https://lore.kernel.org/patchwork/cover/888071/) is that xattrs can be
>> included in an image without changing the image format, as opposed to
>> defining a new one. As seen from the discussion, if a new format has to be
>> defined, it should fix the issues of the existing format, which requires
>> more time.
>
> So you've explicitly chosen _not_ to address Y2038 while you're there.
Can you be more specific?
Thanks
Roberto
> Rob
>
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI
^ permalink raw reply
* Re: [PATCH next] security: smack: fix sap undeclared error in smack_socket_sendmsg
From: Kefeng Wang @ 2019-05-10 1:01 UTC (permalink / raw)
To: Casey Schaufler, Tetsuo Handa, linux-security-module
In-Reply-To: <73cebc57-3947-c438-9316-0c64302e97e5@schaufler-ca.com>
On 2019/5/9 23:29, Casey Schaufler wrote:
> On 5/9/2019 5:46 AM, Kefeng Wang wrote:
>> If CONFIG_IPV6 is disabled, there is build error, fix it.
>>
>> security/smack/smack_lsm.c: In function ‘smack_socket_sendmsg’:
>> security/smack/smack_lsm.c:3698:7: error: ‘sap’ undeclared (first use in this function)
>> sap->sin6_family != AF_INET6)
>>
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>
> Thank you for your patch. This has already been fixed and
> will be in 5.2 when James sends the pull request.
ok ; )
>
>> ---
>> security/smack/smack_lsm.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
>> index b5b333d72637..ff5b7dc6816f 100644
>> --- a/security/smack/smack_lsm.c
>> +++ b/security/smack/smack_lsm.c
>> @@ -3693,6 +3693,7 @@ static int smack_socket_sendmsg(struct socket *sock, struct msghdr *msg,
>> return -EINVAL;
>> rc = smack_netlabel_send(sock->sk, sip);
>> break;
>> +#if IS_ENABLED(CONFIG_IPV6)
>> case AF_INET6:
>> if (msg->msg_namelen < SIN6_LEN_RFC2133 ||
>> sap->sin6_family != AF_INET6)
>> @@ -3707,6 +3708,7 @@ static int smack_socket_sendmsg(struct socket *sock, struct msghdr *msg,
>> rc = smk_ipv6_port_check(sock->sk, sap, SMK_SENDING);
>> #endif
>> break;
>> +#endif
>> }
>> return rc;
>> }
>
>
^ permalink raw reply
* Re: [PATCH v10 11/12] ima: Define ima-modsig template
From: Mimi Zohar @ 2019-05-09 23:01 UTC (permalink / raw)
To: Thiago Jung Bauermann, linux-integrity
Cc: linux-security-module, keyrings, linux-crypto, linuxppc-dev,
linux-doc, linux-kernel, Dmitry Kasatkin, James Morris,
Serge E. Hallyn, David Howells, David Woodhouse, Jessica Yu,
Herbert Xu, David S. Miller, Jonathan Corbet, AKASHI, Takahiro
In-Reply-To: <20190418035120.2354-12-bauerman@linux.ibm.com>
On Thu, 2019-04-18 at 00:51 -0300, Thiago Jung Bauermann wrote:
> Define new "d-modsig" template field which holds the digest that is
> expected to match the one contained in the modsig, and also new "modsig"
> template field which holds the appended file signature.
>
> Add a new "ima-modsig" defined template descriptor with the new fields as
> well as the ones from the "ima-sig" descriptor.
>
> Change ima_store_measurement() to accept a struct modsig * argument so that
> it can be passed along to the templates via struct ima_event_data.
>
> Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Thanks, Roberto. Just some thoughts inline below.
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
> ---
<snip>
> +/*
> + * Validating the appended signature included in the measurement list requires
> + * the file hash calculated without the appended signature (i.e., the 'd-modsig'
> + * field). Therefore, notify the user if they have the 'modsig' field but not
> + * the 'd-modsig' field in the template.
> + */
> +static void check_current_template_modsig(void)
> +{
> +#define MSG "template with 'modsig' field also needs 'd-modsig' field\n"
> + struct ima_template_desc *template;
> + bool has_modsig, has_dmodsig;
> + static bool checked;
> + int i;
> +
> + /* We only need to notify the user once. */
> + if (checked)
> + return;
> +
> + has_modsig = has_dmodsig = false;
> + template = ima_template_desc_current();
> + for (i = 0; i < template->num_fields; i++) {
> + if (!strcmp(template->fields[i]->field_id, "modsig"))
> + has_modsig = true;
> + else if (!strcmp(template->fields[i]->field_id, "d-modsig"))
> + has_dmodsig = true;
> + }
> +
> + if (has_modsig && !has_dmodsig)
> + pr_notice(MSG);
> +
> + checked = true;
> +#undef MSG
> +}
> +
There was some recent discussion about supporting per IMA policy rule
template formats. This feature will allow just the kexec kernel image
to require ima-modsig. When per policy rule template formats support
is upstreamed, this function will need to be updated.
<snip>
>
> @@ -389,3 +425,25 @@ int ima_eventsig_init(struct ima_event_data *event_data,
> return ima_write_template_field_data(xattr_value, event_data->xattr_len,
> DATA_FMT_HEX, field_data);
> }
> +
> +int ima_eventmodsig_init(struct ima_event_data *event_data,
> + struct ima_field_data *field_data)
> +{
> + const void *data;
> + u32 data_len;
> + int rc;
> +
> + if (!event_data->modsig)
> + return 0;
> +
> + /*
> + * The xattr_value for IMA_MODSIG is a runtime structure containing
> + * pointers. Get its raw data instead.
> + */
"xattr_value"? The comment needs some clarification.
Mimi
> + rc = ima_modsig_serialize(event_data->modsig, &data, &data_len);
> + if (rc)
> + return rc;
> +
> + return ima_write_template_field_data(data, data_len,
> + DATA_FMT_HEX, field_data);
> +}
^ permalink raw reply
* Re: [PATCH v10 09/12] ima: Implement support for module-style appended signatures
From: Mimi Zohar @ 2019-05-09 23:01 UTC (permalink / raw)
To: Thiago Jung Bauermann, linux-integrity
Cc: linux-security-module, keyrings, linux-crypto, linuxppc-dev,
linux-doc, linux-kernel, Dmitry Kasatkin, James Morris,
Serge E. Hallyn, David Howells, David Woodhouse, Jessica Yu,
Herbert Xu, David S. Miller, Jonathan Corbet, AKASHI, Takahiro
In-Reply-To: <20190418035120.2354-10-bauerman@linux.ibm.com>
Hi Thiago,
> diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
> index fca7a3f23321..a7a20a8c15c1 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -1144,6 +1144,12 @@ void ima_delete_rules(void)
> }
> }
>
> +#define __ima_hook_stringify(str) (#str),
> +
> +const char *const func_tokens[] = {
> + __ima_hooks(__ima_hook_stringify)
> +};
> +
> #ifdef CONFIG_IMA_READ_POLICY
> enum {
> mask_exec = 0, mask_write, mask_read, mask_append
> @@ -1156,12 +1162,6 @@ static const char *const mask_tokens[] = {
> "MAY_APPEND"
> };
>
> -#define __ima_hook_stringify(str) (#str),
> -
> -static const char *const func_tokens[] = {
> - __ima_hooks(__ima_hook_stringify)
> -};
> -
> void *ima_policy_start(struct seq_file *m, loff_t *pos)
> {
> loff_t l = *pos;
Is moving this something left over from previous versions or there is
a need for this change?
Other than this, the patch looks good.
Mimi
^ permalink raw reply
* Re: [GIT PULL] security subsytem: TPM changes for v5.2
From: James Morris @ 2019-05-09 22:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux List Kernel Mailing, LSM List
In-Reply-To: <CAHk-=whqzNFfeNOouBjH2GKMVgMi22fsNOaCgbUOnCPmKmEXeQ@mail.gmail.com>
On Thu, 9 May 2019, Linus Torvalds wrote:
> On Thu, May 9, 2019 at 10:23 AM James Morris <jmorris@namei.org> wrote:
> >
> > Bugfixes and new selftests for v5.1 features (partial reads in /dev/tpm0).
>
> What the heck is going on?
>
> I got all of these long ago in the "TPM fixes" branch for 5.1. One
> month ago, merge commit a556810d8e06.
>
> These are just rebased (!) copies of stuff I already have, and they should
>
> (a) never have been rebased in the first place
>
> (b) certainly not be re-sent to me as a new branch
>
> Please throw this branch away and make sure it really is dead and
> buried and never shows up again.
Yikes, ok.
> And take a moment to look at what happened and why this broken branch
> was duplicated and sent twice!
Could it be something I pulled in? I haven't used 'rebase' in many years.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [GIT PULL] Security subsystem: Smack updates for v5.2
From: pr-tracker-bot @ 2019-05-09 20:50 UTC (permalink / raw)
To: James Morris; +Cc: Linus Torvalds, linux-kernel, linux-security-module
In-Reply-To: <alpine.LRH.2.21.1905100325330.25349@namei.org>
The pull request you sent on Fri, 10 May 2019 03:28:49 +1000 (AEST):
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-smack
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/800c608c976c3f0a6d02ed7fbc600f1f6962ac73
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [GIT PULL] Security subsystem: integrity updates for v5.2
From: pr-tracker-bot @ 2019-05-09 20:50 UTC (permalink / raw)
To: James Morris; +Cc: Linus Torvalds, linux-kernel, linux-security-module
In-Reply-To: <alpine.LRH.2.21.1905100323410.25349@namei.org>
The pull request you sent on Fri, 10 May 2019 03:25:24 +1000 (AEST):
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-integrity
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7664cd6e3a0b2709f04c07435e96c7c85e7d7324
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [GIT PULL] Security subsystem: Smack updates for v5.2
From: Linus Torvalds @ 2019-05-09 20:02 UTC (permalink / raw)
To: James Morris; +Cc: Linux List Kernel Mailing, LSM List
In-Reply-To: <alpine.LRH.2.21.1905100325330.25349@namei.org>
On Thu, May 9, 2019 at 10:28 AM James Morris <jmorris@namei.org> wrote:
>
> From Casey: "There's one bug fix for IPv6 handling and two memory use
> improvements."
>
> Plus a couple of further bugfixes.
I'm going to stop pulling these silly security subsystem "contains
just about as many merges as regular commits" branches starting next
merge window.
Security subsystem guys: just send your pull requests to me directly.
The history is illegible with the completely random pulls in the
middle, and I'm having a hard time editing sane merge messages with
quotes from submaintainers mixed up with other quotes.
This subsystem isn't working. I'm already taking SElinux, audit and
apparmor updates directly from the submaintainers, I'd ratehr just
take the smack updates and the TPM ones that way too. Because this is
just adding confusion as things are now.
I've pulled this, just to not cause extra confusion this merge window,
so this is just a heads-up for the future.
Linus
^ permalink raw reply
* Re: [GIT PULL] security subsytem: TPM changes for v5.2
From: Linus Torvalds @ 2019-05-09 19:53 UTC (permalink / raw)
To: James Morris; +Cc: Linux List Kernel Mailing, LSM List
In-Reply-To: <alpine.LRH.2.21.1905100320110.25349@namei.org>
On Thu, May 9, 2019 at 10:23 AM James Morris <jmorris@namei.org> wrote:
>
> Bugfixes and new selftests for v5.1 features (partial reads in /dev/tpm0).
What the heck is going on?
I got all of these long ago in the "TPM fixes" branch for 5.1. One
month ago, merge commit a556810d8e06.
These are just rebased (!) copies of stuff I already have, and they should
(a) never have been rebased in the first place
(b) certainly not be re-sent to me as a new branch
Please throw this branch away and make sure it really is dead and
buried and never shows up again.
And take a moment to look at what happened and why this broken branch
was duplicated and sent twice!
Linus
^ permalink raw reply
* Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk
From: Rob Landley @ 2019-05-09 18:34 UTC (permalink / raw)
To: Roberto Sassu, viro
Cc: linux-security-module, linux-integrity, initramfs, linux-api,
linux-fsdevel, linux-kernel, zohar, silviu.vlasceanu,
dmitry.kasatkin, takondra, kamensky, hpa, arnd, james.w.mcmechan
In-Reply-To: <20190509112420.15671-1-roberto.sassu@huawei.com>
On 5/9/19 6:24 AM, Roberto Sassu wrote:
> This patch set aims at solving the following use case: appraise files from
> the initial ram disk. To do that, IMA checks the signature/hash from the
> security.ima xattr. Unfortunately, this use case cannot be implemented
> currently, as the CPIO format does not support xattrs.
>
> This proposal consists in marshaling pathnames and xattrs in a file called
> .xattr-list. They are unmarshaled by the CPIO parser after all files have
> been extracted.
So it's in-band signalling that has a higher peak memory requirement.
> The difference with another proposal
> (https://lore.kernel.org/patchwork/cover/888071/) is that xattrs can be
> included in an image without changing the image format, as opposed to
> defining a new one. As seen from the discussion, if a new format has to be
> defined, it should fix the issues of the existing format, which requires
> more time.
So you've explicitly chosen _not_ to address Y2038 while you're there.
Rob
^ permalink raw reply
* [GIT PULL] Security subsystem: Smack updates for v5.2
From: James Morris @ 2019-05-09 17:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-security-module
From Casey: "There's one bug fix for IPv6 handling and two memory use
improvements."
Plus a couple of further bugfixes.
The following changes since commit fe9fd2ef383c2f5883fcd3f7adce0de9ce2556ff:
Revert "security: inode: fix a missing check for securityfs_create_file" (2019-04-10 14:59:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-smack
for you to fetch changes up to 8d31a5c35ed179825a2145881ad7cd8f9907d94b:
Merge branch 'smack-for-5.2-b' of https://github.com/cschaufler/next-smack into next-smack (2019-05-06 20:24:51 -0700)
----------------------------------------------------------------
Casey Schaufler (3):
Smack: Create smack_rule cache to optimize memory usage
Smack: Fix IPv6 handling of 0 secmark
Smack: Fix kbuild reported build error
James Morris (3):
Merge branch 'smack-for-5.2' of https://github.com/cschaufler/next-smack into next-smack
Merge branch 'smack-for-5.2-b' of https://github.com/cschaufler/next-smack into next-smack
Merge branch 'smack-for-5.2-b' of https://github.com/cschaufler/next-smack into next-smack
Tetsuo Handa (1):
smack: Check address length before reading address family
Vishal Goel (1):
smack: removal of global rule list
security/smack/smack.h | 1 +
security/smack/smack_lsm.c | 34 +++++++++++++++++++++++-----
security/smack/smackfs.c | 55 ++++++++++++++--------------------------------
3 files changed, 45 insertions(+), 45 deletions(-)
^ permalink raw reply
* [GIT PULL] Security subsystem: integrity updates for v5.2
From: James Morris @ 2019-05-09 17:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-security-module
[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]
From Mimi:
"This pull request contains just three patches, the remainder are
either included in other pull requests (eg. audit, lockdown) or will
be upstreamed via other subsystems (eg. kselftests, Power). Included
in this pull request is one bug fix, one documentation update, and
extending the x86 IMA arch policy rules to coordinate the different
kernel module signature verification methods."
The following changes since commit fe9fd2ef383c2f5883fcd3f7adce0de9ce2556ff:
Revert "security: inode: fix a missing check for securityfs_create_file" (2019-04-10 14:59:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-integrity
for you to fetch changes up to 2bfebea90dd5e8c57ae1021a5d1bb6c1057eee6d:
Merge branch 'next-integrity-for-james' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity into next-integrity (2019-04-12 15:20:23 -0700)
----------------------------------------------------------------
James Morris (1):
Merge branch 'next-integrity-for-james' of git://git.kernel.org/.../zohar/linux-integrity into next-integrity
Mimi Zohar (2):
x86/ima: require signed kernel modules
x86/ima: add missing include
Petr Vorel (1):
doc/kernel-parameters.txt: Deprecate ima_appraise_tcb
Documentation/admin-guide/kernel-parameters.txt | 5 ++---
arch/x86/kernel/ima_arch.c | 10 +++++++++-
include/linux/module.h | 5 +++++
kernel/module.c | 5 +++++
4 files changed, 21 insertions(+), 4 deletions(-)
^ permalink raw reply
* [GIT PULL] security subsytem: TPM changes for v5.2
From: James Morris @ 2019-05-09 17:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-security-module
From Jarkko:
Bugfixes and new selftests for v5.1 features (partial reads in /dev/tpm0).
The following changes since commit 8d93e952fba216cd0811247f6360d97e0465d5fc:
LSM: lsm_hooks.h: fix documentation format (2019-03-26 16:46:22 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-tpm
for you to fetch changes up to a94e55b91c7d1494c1a4598178dc5f1d7dfe12aa:
Merge tag 'tpmdd-next-20190329' of git://git.infradead.org/users/jjs/linux-tpmdd into next-tpm (2019-03-29 11:39:20 -0700)
----------------------------------------------------------------
James Morris (1):
Merge tag 'tpmdd-next-20190329' of git://git.infradead.org/users/jjs/linux-tpmdd into next-tpm
Jarkko Sakkinen (2):
KEYS: trusted: allow trusted.ko to initialize w/o a TPM
tpm: turn on TPM on suspend for TPM 1.x
Tadeusz Struk (3):
selftests/tpm2: Open tpm dev in unbuffered mode
selftests/tpm2: Extend tests to cover partial reads
tpm: fix an invalid condition in tpm_common_poll
Yue Haibing (1):
tpm: Fix the type of the return value in calc_tpm2_event_size()
ndesaulniers@google.com (1):
KEYS: trusted: fix -Wvarags warning
drivers/char/tpm/eventlog/tpm2.c | 4 +-
drivers/char/tpm/tpm-dev-common.c | 9 ++++-
drivers/char/tpm/tpm-interface.c | 14 +++----
include/keys/trusted.h | 2 +-
security/keys/trusted.c | 32 +++++++++++----
tools/testing/selftests/tpm2/tpm2.py | 5 ++-
tools/testing/selftests/tpm2/tpm2_tests.py | 63 ++++++++++++++++++++++++++++++
7 files changed, 108 insertions(+), 21 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/4] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
From: Alexander Potapenko @ 2019-05-09 16:43 UTC (permalink / raw)
To: Kees Cook
Cc: Andrew Morton, Christoph Lameter, Laura Abbott, Linux-MM,
linux-security-module, Kernel Hardening, Masahiro Yamada,
James Morris, Serge E. Hallyn, Nick Desaulniers,
Kostya Serebryany, Dmitry Vyukov, Sandeep Patil, Randy Dunlap,
Jann Horn, Mark Rutland
In-Reply-To: <CAGXu5jKfxYfRQS+CouYZc8-BMEWR1U3kwshu4892pM0pmmACGw@mail.gmail.com>
From: Kees Cook <keescook@chromium.org>
Date: Wed, May 8, 2019 at 9:02 PM
To: Alexander Potapenko
Cc: Andrew Morton, Christoph Lameter, Kees Cook, Laura Abbott,
Linux-MM, linux-security-module, Kernel Hardening, Masahiro Yamada,
James Morris, Serge E. Hallyn, Nick Desaulniers, Kostya Serebryany,
Dmitry Vyukov, Sandeep Patil, Randy Dunlap, Jann Horn, Mark Rutland
> On Wed, May 8, 2019 at 8:38 AM Alexander Potapenko <glider@google.com> wrote:
> > The new options are needed to prevent possible information leaks and
> > make control-flow bugs that depend on uninitialized values more
> > deterministic.
>
> I like having this available on both alloc and free. This makes it
> much more configurable for the end users who can adapt to their work
> loads, etc.
>
> > Linux build with -j12, init_on_free=1: +24.42% sys time (st.err 0.52%)
> > [...]
> > Linux build with -j12, init_on_alloc=1: +0.57% sys time (st.err 0.40%)
>
> Any idea why there is such a massive difference here? This seems to
> high just for cache-locality effects of touching all the freed pages.
I've measured a single `make -j12` again under perf stat.
The numbers for init_on_alloc=1 were:
4936513177 cache-misses # 8.056 % of all
cache refs (44.44%)
61278262461 cache-references
(44.45%)
42844784 page-faults
1449630221347 L1-dcache-loads
(44.45%)
50569965485 L1-dcache-load-misses # 3.49% of all
L1-dcache hits (44.44%)
299987258588 L1-icache-load-misses
(44.44%)
1449857258648 dTLB-loads
(44.45%)
826292490 dTLB-load-misses # 0.06% of all
dTLB cache hits (44.44%)
22028472701 iTLB-loads
(44.44%)
858451905 iTLB-load-misses # 3.90% of all
iTLB cache hits (44.45%)
162.120107145 seconds time elapsed
, and for init_on_free=1:
6666716777 cache-misses # 10.862 % of all
cache refs (44.45%)
61378258434 cache-references
(44.46%)
42850913 page-faults
1449986416063 L1-dcache-loads
(44.45%)
51277338771 L1-dcache-load-misses # 3.54% of all
L1-dcache hits (44.45%)
298295905805 L1-icache-load-misses
(44.44%)
1450378031344 dTLB-loads
(44.43%)
807011341 dTLB-load-misses # 0.06% of all
dTLB cache hits (44.44%)
22044976638 iTLB-loads
(44.44%)
846377845 iTLB-load-misses # 3.84% of all
iTLB cache hits (44.45%)
164.427054893 seconds time elapsed
(note that we don't see the speed difference under perf)
init_on_free=1 causes 1.73B more cache misses than init_on_alloc=1.
If I'm understanding correctly, a cache miss costs 12-14 cycles on my
3GHz Skylake CPU, which can explain explain a 7-8-second difference
between the two modes.
But as I just realized this is both kernel and userspace, so while the
difference is almost correct for wall time (120s for init_on_alloc,
130s for init_on_free) this doesn't tell much about the time spent in
the kernel.
> --
> Kees Cook
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
^ permalink raw reply
* Re: [PATCH v10 08/12] ima: Factor xattr_verify() out of ima_appraise_measurement()
From: Mimi Zohar @ 2019-05-09 15:53 UTC (permalink / raw)
To: Thiago Jung Bauermann, linux-integrity
Cc: linux-security-module, keyrings, linux-crypto, linuxppc-dev,
linux-doc, linux-kernel, Dmitry Kasatkin, James Morris,
Serge E. Hallyn, David Howells, David Woodhouse, Jessica Yu,
Herbert Xu, David S. Miller, Jonathan Corbet, AKASHI, Takahiro
In-Reply-To: <20190418035120.2354-9-bauerman@linux.ibm.com>
On Thu, 2019-04-18 at 00:51 -0300, Thiago Jung Bauermann wrote:
> Verify xattr signature in a separate function so that the logic in
> ima_appraise_measurement() remains clear when it gains the ability to also
> verify an appended module signature.
>
> The code in the switch statement is unchanged except for having to
> dereference the status and cause variables (since they're now pointers),
> and fixing the style of a block comment to appease checkpatch.
>
> Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH v10 06/12] ima: Use designated initializers for struct ima_event_data
From: Mimi Zohar @ 2019-05-09 15:46 UTC (permalink / raw)
To: Thiago Jung Bauermann, linux-integrity
Cc: linux-security-module, keyrings, linux-crypto, linuxppc-dev,
linux-doc, linux-kernel, Dmitry Kasatkin, James Morris,
Serge E. Hallyn, David Howells, David Woodhouse, Jessica Yu,
Herbert Xu, David S. Miller, Jonathan Corbet, AKASHI, Takahiro
In-Reply-To: <20190418035120.2354-7-bauerman@linux.ibm.com>
On Thu, 2019-04-18 at 00:51 -0300, Thiago Jung Bauermann wrote:
> Designated initializers allow specifying only the members of the struct
> that need initialization. Non-mentioned members are initialized to zero.
>
> This makes the code a bit clearer (particularly in ima_add_boot_aggregate()
> and also allows adding a new member to the struct without having to update
> all struct initializations.
>
> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
> ---
> security/integrity/ima/ima_api.c | 11 +++++++----
> security/integrity/ima/ima_init.c | 4 ++--
> 2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
> index c7505fb122d4..0639d0631f2c 100644
> --- a/security/integrity/ima/ima_api.c
> +++ b/security/integrity/ima/ima_api.c
> @@ -133,8 +133,9 @@ void ima_add_violation(struct file *file, const unsigned char *filename,
> {
> struct ima_template_entry *entry;
> struct inode *inode = file_inode(file);
> - struct ima_event_data event_data = {iint, file, filename, NULL, 0,
> - cause};
> + struct ima_event_data event_data = { .iint = iint, .file = file,
> + .filename = filename,
> + .violation = cause };
> int violation = 1;
> int result;
>
> @@ -284,8 +285,10 @@ void ima_store_measurement(struct integrity_iint_cache *iint,
> int result = -ENOMEM;
> struct inode *inode = file_inode(file);
> struct ima_template_entry *entry;
> - struct ima_event_data event_data = {iint, file, filename, xattr_value,
> - xattr_len, NULL};
> + struct ima_event_data event_data = { .iint = iint, .file = file,
> + .filename = filename,
> + .xattr_value = xattr_value,
> + .xattr_len = xattr_len };
> int violation = 0;
>
> if (iint->measured_pcrs & (0x1 << pcr))
> diff --git a/security/integrity/ima/ima_init.c b/security/integrity/ima/ima_init.c
> index 6c9295449751..ef6c3a26296e 100644
> --- a/security/integrity/ima/ima_init.c
> +++ b/security/integrity/ima/ima_init.c
> @@ -49,8 +49,8 @@ static int __init ima_add_boot_aggregate(void)
> const char *audit_cause = "ENOMEM";
> struct ima_template_entry *entry;
> struct integrity_iint_cache tmp_iint, *iint = &tmp_iint;
> - struct ima_event_data event_data = {iint, NULL, boot_aggregate_name,
> - NULL, 0, NULL};
> + struct ima_event_data event_data = { .iint = iint,
> + .filename = boot_aggregate_name };
> int result = -ENOMEM;
> int violation = 0;
> struct {
^ permalink raw reply
* Re: [PATCH v10 02/12] PKCS#7: Refactor verify_pkcs7_signature()
From: Mimi Zohar @ 2019-05-09 15:42 UTC (permalink / raw)
To: Thiago Jung Bauermann, linux-integrity
Cc: linux-security-module, keyrings, linux-crypto, linuxppc-dev,
linux-doc, linux-kernel, Dmitry Kasatkin, James Morris,
Serge E. Hallyn, David Howells, David Woodhouse, Jessica Yu,
Herbert Xu, David S. Miller, Jonathan Corbet, AKASHI, Takahiro
In-Reply-To: <20190418035120.2354-3-bauerman@linux.ibm.com>
On Thu, 2019-04-18 at 00:51 -0300, Thiago Jung Bauermann wrote:
> IMA will need to verify a PKCS#7 signature which has already been parsed.
> For this reason, factor out the code which does that from
> verify_pkcs7_signature() into a new function which takes a struct
> pkcs7_message instead of a data buffer.
>
> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: "David S. Miller" <davem@davemloft.net>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH v10 03/12] PKCS#7: Introduce pkcs7_get_digest()
From: Mimi Zohar @ 2019-05-09 15:42 UTC (permalink / raw)
To: Thiago Jung Bauermann, linux-integrity
Cc: linux-security-module, keyrings, linux-crypto, linuxppc-dev,
linux-doc, linux-kernel, Dmitry Kasatkin, James Morris,
Serge E. Hallyn, David Howells, David Woodhouse, Jessica Yu,
Herbert Xu, David S. Miller, Jonathan Corbet, AKASHI, Takahiro
In-Reply-To: <20190418035120.2354-4-bauerman@linux.ibm.com>
On Thu, 2019-04-18 at 00:51 -0300, Thiago Jung Bauermann wrote:
> IMA will need to access the digest of the PKCS7 message (as calculated by
> the kernel) before the signature is verified, so introduce
> pkcs7_get_digest() for that purpose.
>
> Also, modify pkcs7_digest() to detect when the digest was already
> calculated so that it doesn't have to do redundant work. Verifying that
> sinfo->sig->digest isn't NULL is sufficient because both places which
> allocate sinfo->sig (pkcs7_parse_message() and pkcs7_note_signed_info())
> use kzalloc() so sig->digest is always initialized to zero.
>
> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: "David S. Miller" <davem@davemloft.net>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH v10 01/12] MODSIGN: Export module signature definitions
From: Mimi Zohar @ 2019-05-09 15:42 UTC (permalink / raw)
To: Thiago Jung Bauermann, linux-integrity
Cc: linux-security-module, keyrings, linux-crypto, linuxppc-dev,
linux-doc, linux-kernel, Dmitry Kasatkin, James Morris,
Serge E. Hallyn, David Howells, David Woodhouse, Jessica Yu,
Herbert Xu, David S. Miller, Jonathan Corbet, AKASHI, Takahiro
In-Reply-To: <20190418035120.2354-2-bauerman@linux.ibm.com>
On Thu, 2019-04-18 at 00:51 -0300, Thiago Jung Bauermann wrote:
> IMA will use the module_signature format for append signatures, so export
> the relevant definitions and factor out the code which verifies that the
> appended signature trailer is valid.
>
> Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can select it
> and be able to use mod_check_sig() without having to depend on either
> CONFIG_MODULE_SIG or CONFIG_MODULES.
>
> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> Cc: Jessica Yu <jeyu@kernel.org>
Just a couple minor questions/comments below.
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
> ---
< snip >
> diff --git a/init/Kconfig b/init/Kconfig
> index 4592bf7997c0..a71019553ee1 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1906,7 +1906,7 @@ config MODULE_SRCVERSION_ALL
> config MODULE_SIG
> bool "Module signature verification"
> depends on MODULES
> - select SYSTEM_DATA_VERIFICATION
> + select MODULE_SIG_FORMAT
> help
> Check modules for valid signatures upon load: the signature
> is simply appended to the module. For more information see
> @@ -2036,6 +2036,10 @@ config TRIM_UNUSED_KSYMS
>
> endif # MODULES
>
> +config MODULE_SIG_FORMAT
> + def_bool n
> + select SYSTEM_DATA_VERIFICATION
Normally Kconfigs, in the same file, are defined before they are used.
I'm not sure if that is required or just a convention.
> config MODULES_TREE_LOOKUP
> def_bool y
> depends on PERF_EVENTS || TRACING
> diff --git a/kernel/Makefile b/kernel/Makefile
> index 6c57e78817da..d2f2488f80ab 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -57,6 +57,7 @@ endif
> obj-$(CONFIG_UID16) += uid16.o
> obj-$(CONFIG_MODULES) += module.o
> obj-$(CONFIG_MODULE_SIG) += module_signing.o
> +obj-$(CONFIG_MODULE_SIG_FORMAT) += module_signature.o
> obj-$(CONFIG_KALLSYMS) += kallsyms.o
> obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
> obj-$(CONFIG_CRASH_CORE) += crash_core.o
> diff --git a/kernel/module.c b/kernel/module.c
> index 985caa467aef..326ddeb364dd 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -19,6 +19,7 @@
> #include <linux/export.h>
> #include <linux/extable.h>
> #include <linux/moduleloader.h>
> +#include <linux/module_signature.h>
> #include <linux/trace_events.h>
> #include <linux/init.h>
> #include <linux/kallsyms.h>
> diff --git a/kernel/module_signature.c b/kernel/module_signature.c
> new file mode 100644
> index 000000000000..6d5e59f27f55
> --- /dev/null
> +++ b/kernel/module_signature.c
> @@ -0,0 +1,45 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Module signature checker
> + *
> + * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowells@redhat.com)
> + */
> +
> +#include <linux/errno.h>
> +#include <linux/printk.h>
> +#include <linux/module_signature.h>
> +#include <asm/byteorder.h>
> +
> +/**
> + * mod_check_sig - check that the given signature is sane
> + *
> + * @ms: Signature to check.
> + * @file_len: Size of the file to which @ms is appended.
"name" is missing.
Mimi
> + */
^ permalink raw reply
* Re: [PATCH next] security: smack: fix sap undeclared error in smack_socket_sendmsg
From: Casey Schaufler @ 2019-05-09 15:29 UTC (permalink / raw)
To: Kefeng Wang, Tetsuo Handa, linux-security-module; +Cc: casey
In-Reply-To: <20190509124628.189228-1-wangkefeng.wang@huawei.com>
On 5/9/2019 5:46 AM, Kefeng Wang wrote:
> If CONFIG_IPV6 is disabled, there is build error, fix it.
>
> security/smack/smack_lsm.c: In function ‘smack_socket_sendmsg’:
> security/smack/smack_lsm.c:3698:7: error: ‘sap’ undeclared (first use in this function)
> sap->sin6_family != AF_INET6)
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Thank you for your patch. This has already been fixed and
will be in 5.2 when James sends the pull request.
> ---
> security/smack/smack_lsm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index b5b333d72637..ff5b7dc6816f 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -3693,6 +3693,7 @@ static int smack_socket_sendmsg(struct socket *sock, struct msghdr *msg,
> return -EINVAL;
> rc = smack_netlabel_send(sock->sk, sip);
> break;
> +#if IS_ENABLED(CONFIG_IPV6)
> case AF_INET6:
> if (msg->msg_namelen < SIN6_LEN_RFC2133 ||
> sap->sin6_family != AF_INET6)
> @@ -3707,6 +3708,7 @@ static int smack_socket_sendmsg(struct socket *sock, struct msghdr *msg,
> rc = smk_ipv6_port_check(sock->sk, sap, SMK_SENDING);
> #endif
> break;
> +#endif
> }
> return rc;
> }
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox