Linux-Integrity Archive on lore.kernel.org
 help / color / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Scott Branden <scott.branden@broadcom.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
	Christoph Hellwig <hch@infradead.org>,
	Luis Chamberlain <mcgrof@kernel.org>,
	viro@zeniv.linux.org.uk, gregkh@linuxfoundation.org,
	rafael@kernel.org, ebiederm@xmission.com, jeyu@kernel.org,
	jmorris@namei.org, paul@paul-moore.com,
	stephen.smalley.work@gmail.com, eparis@parisplace.org,
	nayna@linux.ibm.com, dan.carpenter@oracle.com,
	skhan@linuxfoundation.org, geert@linux-m68k.org,
	tglx@linutronix.de, bauerman@linux.ibm.com, dhowells@redhat.com,
	linux-integrity@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	kexec@lists.infradead.org, linux-security-module@vger.kernel.org,
	selinux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] fs: reduce export usage of kerne_read*() calls
Date: Fri, 22 May 2020 16:04:55 -0700
Message-ID: <202005221551.5CA1372@keescook> (raw)
In-Reply-To: <7525ca03-def7-dfe2-80a9-25270cb0ae05@broadcom.com>

On Fri, May 22, 2020 at 03:24:32PM -0700, Scott Branden wrote:
> On 2020-05-18 5:37 a.m., Mimi Zohar wrote:
> > On Sun, 2020-05-17 at 23:22 -0700, Christoph Hellwig wrote:
> > > On Fri, May 15, 2020 at 09:29:33PM +0000, Luis Chamberlain wrote:
> > > > On Wed, May 13, 2020 at 11:17:36AM -0700, Christoph Hellwig wrote:
> > > > > Can you also move kernel_read_* out of fs.h?  That header gets pulled
> > > > > in just about everywhere and doesn't really need function not related
> > > > > to the general fs interface.
> > > > Sure, where should I dump these?
> > > Maybe a new linux/kernel_read_file.h?  Bonus points for a small top
> > > of the file comment explaining the point of the interface, which I
> > > still don't get :)
> > Instead of rolling your own method of having the kernel read a file,
> > which requires call specific security hooks, this interface provides a
> > single generic set of pre and post security hooks.  The
> > kernel_read_file_id enumeration permits the security hook to
> > differentiate between callers.
> > 
> > To comply with secure and trusted boot concepts, a file cannot be
> > accessible to the caller until after it has been measured and/or the
> > integrity (hash/signature) appraised.
> > 
> > In some cases, the file was previously read twice, first to measure
> > and/or appraise the file and then read again into a buffer for
> > use.  This interface reads the file into a buffer once, calls the
> > generic post security hook, before providing the buffer to the caller.
> >   (Note using firmware pre-allocated memory might be an issue.)
> > 
> > Partial reading firmware will result in needing to pre-read the entire
> > file, most likely on the security pre hook.
> The entire file may be very large and not fit into a buffer.
> Hence one of the reasons for a partial read of the file.
> For security purposes, you need to change your code to limit the amount
> of data it reads into a buffer at one time to not consume or run out of much
> memory.

Hm? That's not how whole-file hashing works. :)

These hooks need to finish their hashing and policy checking before they
can allow the rest of the code to move forward. (That's why it's a
security hook.) If kernel memory utilization is the primary concern,
then sure, things could be rearranged to do partial read and update the
hash incrementally, but the entire file still needs to be locked,
entirely hashed by hook, then read by the caller, then unlocked and
released.

So, if you want to have partial file reads work, you'll need to
rearchitect the way this works to avoid regressing the security coverage
of these operations.

So, probably, the code will look something like:


file = kernel_open_file_for_reading(...)
	file = open...
	disallow_writes(file);
	while (processed < size-of-file) {
		buf = read(file, size...)
		security_file_read_partial(buf)
	}
	ret = security_file_read_finished(file);
	if (ret < 0) {
		allow_writes(file);
		return PTR_ERR(ret);
	}
	return file;

while (processed < size-of-file) {
	buf = read(file, size...)
	firmware_send_partial(buf);
}

kernel_close_file_for_reading(file)
	allow_writes(file);


-- 
Kees Cook

  reply index

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-13 15:21 Luis Chamberlain
2020-05-13 15:21 ` [PATCH 1/3] fs: unexport kernel_read_file() Luis Chamberlain
2020-05-13 15:21 ` [PATCH 2/3] security: add symbol namespace for reading file data Luis Chamberlain
2020-05-13 15:40   ` Eric W. Biederman
2020-05-13 16:09     ` Greg KH
2020-05-13 16:16     ` Luis Chamberlain
2020-05-13 16:26       ` Greg KH
2020-05-13 18:07       ` Josh Triplett
2020-05-13 15:21 ` [PATCH 3/3] fs: move kernel_read*() calls to its own symbol namespace Luis Chamberlain
2020-05-13 16:08   ` Greg KH
2020-05-13 18:17 ` [PATCH 0/3] fs: reduce export usage of kerne_read*() calls Christoph Hellwig
2020-05-15 21:29   ` Luis Chamberlain
2020-05-18  6:22     ` Christoph Hellwig
2020-05-18 12:37       ` Mimi Zohar
2020-05-18 15:21         ` Kees Cook
2020-05-22 22:24         ` Scott Branden
2020-05-22 23:04           ` Kees Cook [this message]
2020-05-22 23:25             ` Scott Branden
2020-05-24  2:52               ` 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=202005221551.5CA1372@keescook \
    --to=keescook@chromium.org \
    --cc=bauerman@linux.ibm.com \
    --cc=dan.carpenter@oracle.com \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=eparis@parisplace.org \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=jeyu@kernel.org \
    --cc=jmorris@namei.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=nayna@linux.ibm.com \
    --cc=paul@paul-moore.com \
    --cc=rafael@kernel.org \
    --cc=scott.branden@broadcom.com \
    --cc=selinux@vger.kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=stephen.smalley.work@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zohar@linux.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

Linux-Integrity Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-integrity/0 linux-integrity/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-integrity linux-integrity/ https://lore.kernel.org/linux-integrity \
		linux-integrity@vger.kernel.org
	public-inbox-index linux-integrity

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-integrity


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git