From: ebiederm@xmission.com (Eric W. Biederman)
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Cc: Miklos Szeredi <miklos@szeredi.hu>,
Seth Forshee <seth.forshee@canonical.com>,
"Eric W . Biederman" <ebiederm@xmission.com>,
Dongsu Park <dongsu@kinvolk.io>, Alban Crequy <alban@kinvolk.io>,
"Serge E . Hallyn" <serge@hallyn.com>
Subject: Re: [PATCH v2 0/4] ima: unverifiable file signatures
Date: Mon, 26 Feb 2018 20:08:49 -0600 [thread overview]
Message-ID: <87k1uzw5e6.fsf@xmission.com> (raw)
In-Reply-To: <1519335184-17808-1-git-send-email-zohar@linux.vnet.ibm.com> (Mimi Zohar's message of "Thu, 22 Feb 2018 16:33:00 -0500")
Mimi Zohar <zohar@linux.vnet.ibm.com> writes:
> For local filesystems, the kernel prevents files being executed from
> being modified. With IMA-measurement enabled, the kernel also emits
> audit "time of measure, time of use" messages for files opened for
> read, and subsequently opened for write.
>
> Files on fuse are initially measured, appraised, and audited. Although
> the file data can change dynamically any time, making re-measuring,
> re-appraising, or re-auditing pointless, this patch set attempts to
> differentiate between unprivileged non-init root and privileged
> mounted fuse filesystems.
>
> This patch set addresses three different scenarios:
> - Unprivileged non-init root mounted fuse filesystems are untrusted.
> Signature verification should always fail and re-measuring,
> re-appraising, re-auditing files makes no sense.
>
> Always enabled.
>
> - For privileged mounted filesystems in a "secure" environment, with a
> correctly enforced security policy, which is willing to assume the
> inherent risk of specific fuse filesystems, it is reasonable to
> re-measure, re-appraise, and re-audit files.
>
> Enabled by default to prevent breaking existing systems.
>
> - Privileged mounted filesystems unwilling to assume the risks and
> prefers to fail safe.
>
> Enabled based on policy.
I really like the way the flags work in this patchset.
There is a lot of other nit-picking and bike-shedding I would like to
do. However those are details specific to IMA. So my opion really
doesn't count.
Those two flags set as you have them in the last patch make it possible
to slightly alter details of when they get set, that are in the perview
of filesystems without having too big a debate over them.
The changes I imagine most easily are:
In fuse_fill_super:
if (!fc->allow_other)
sb->s_iflags |= SB_I_UNTRUSTED_MOUNTER;
In sget_user_ns:
if (sb->s_user_ns != &init_user_ns)
sb->s_iflags |= SB_I_UNTRUSTED_MOUNTER;
My biggest nitpick is I would be inclined to flip the sense of the
unverifiable_sigs policy. By default not trust and trust only if
a special command line option was given. But I realize this could
run into backwards compatibility concerns. And it is IMA specific so
not really my call.
But the important part is what winds up in the core of ima. Baring
typo's I think you have something we can all live with.
So double check yourself and let's start getting this merged.
Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: linux-security-module@vger.kernel.org
Subject: [PATCH v2 0/4] ima: unverifiable file signatures
Date: Mon, 26 Feb 2018 20:08:49 -0600 [thread overview]
Message-ID: <87k1uzw5e6.fsf@xmission.com> (raw)
In-Reply-To: <1519335184-17808-1-git-send-email-zohar@linux.vnet.ibm.com> (Mimi Zohar's message of "Thu, 22 Feb 2018 16:33:00 -0500")
Mimi Zohar <zohar@linux.vnet.ibm.com> writes:
> For local filesystems, the kernel prevents files being executed from
> being modified. With IMA-measurement enabled, the kernel also emits
> audit "time of measure, time of use" messages for files opened for
> read, and subsequently opened for write.
>
> Files on fuse are initially measured, appraised, and audited. Although
> the file data can change dynamically any time, making re-measuring,
> re-appraising, or re-auditing pointless, this patch set attempts to
> differentiate between unprivileged non-init root and privileged
> mounted fuse filesystems.
>
> This patch set addresses three different scenarios:
> - Unprivileged non-init root mounted fuse filesystems are untrusted.
> Signature verification should always fail and re-measuring,
> re-appraising, re-auditing files makes no sense.
>
> Always enabled.
>
> - For privileged mounted filesystems in a "secure" environment, with a
> correctly enforced security policy, which is willing to assume the
> inherent risk of specific fuse filesystems, it is reasonable to
> re-measure, re-appraise, and re-audit files.
>
> Enabled by default to prevent breaking existing systems.
>
> - Privileged mounted filesystems unwilling to assume the risks and
> prefers to fail safe.
>
> Enabled based on policy.
I really like the way the flags work in this patchset.
There is a lot of other nit-picking and bike-shedding I would like to
do. However those are details specific to IMA. So my opion really
doesn't count.
Those two flags set as you have them in the last patch make it possible
to slightly alter details of when they get set, that are in the perview
of filesystems without having too big a debate over them.
The changes I imagine most easily are:
In fuse_fill_super:
if (!fc->allow_other)
sb->s_iflags |= SB_I_UNTRUSTED_MOUNTER;
In sget_user_ns:
if (sb->s_user_ns != &init_user_ns)
sb->s_iflags |= SB_I_UNTRUSTED_MOUNTER;
My biggest nitpick is I would be inclined to flip the sense of the
unverifiable_sigs policy. By default not trust and trust only if
a special command line option was given. But I realize this could
run into backwards compatibility concerns. And it is IMA specific so
not really my call.
But the important part is what winds up in the core of ima. Baring
typo's I think you have something we can all live with.
So double check yourself and let's start getting this merged.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-02-27 2:09 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-22 21:33 [PATCH v2 0/4] ima: unverifiable file signatures Mimi Zohar
2018-02-22 21:33 ` Mimi Zohar
2018-02-22 21:33 ` [PATCH v2 1/4] ima: fail file signature verification on non-init mounted filesystems Mimi Zohar
2018-02-22 21:33 ` Mimi Zohar
2018-02-27 1:47 ` Eric W. Biederman
2018-02-27 1:47 ` Eric W. Biederman
2018-02-27 15:33 ` Mimi Zohar
2018-02-27 15:33 ` Mimi Zohar
2018-02-27 15:33 ` Mimi Zohar
2018-02-22 21:33 ` [PATCH v2 2/4] ima: re-evaluate files on privileged " Mimi Zohar
2018-02-22 21:33 ` Mimi Zohar
2018-02-22 21:33 ` [PATCH v2 3/4] ima: fail signature verification based on policy Mimi Zohar
2018-02-22 21:33 ` Mimi Zohar
2018-02-27 22:35 ` Serge E. Hallyn
2018-02-27 22:35 ` Serge E. Hallyn
2018-02-28 11:38 ` Mimi Zohar
2018-02-28 11:38 ` Mimi Zohar
2018-02-28 11:38 ` Mimi Zohar
2018-02-28 15:30 ` Serge E. Hallyn
2018-02-28 15:30 ` Serge E. Hallyn
2018-02-28 15:30 ` Serge E. Hallyn
2018-03-02 21:10 ` Mimi Zohar
2018-03-02 21:10 ` Mimi Zohar
2018-03-02 21:10 ` Mimi Zohar
2018-02-22 21:33 ` [PATCH v2 4/4] fuse: define the filesystem as untrusted Mimi Zohar
2018-02-22 21:33 ` Mimi Zohar
2018-02-23 4:00 ` [PATCH v2 0/4] ima: unverifiable file signatures James Morris
2018-02-23 4:00 ` James Morris
2018-02-27 2:08 ` Eric W. Biederman [this message]
2018-02-27 2:08 ` Eric W. Biederman
2018-02-27 16:17 ` Mimi Zohar
2018-02-27 16:17 ` Mimi Zohar
2018-02-27 16:17 ` Mimi Zohar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k1uzw5e6.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.