All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: bigeasy <bigeasy@linutronix.de>
Cc: tglx <tglx@linutronix.de>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	david <david@sigma-star.at>,
	Torben Hohn <torben.hohn@linutronix.de>
Subject: Re: [PATCH v2 0/4] ubifs: support authentication without hmac
Date: Fri, 3 Jul 2020 10:20:29 +0200 (CEST)	[thread overview]
Message-ID: <1352684131.86554.1593764429561.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <20200703081627.pifi4rwafza6ii7n@linutronix.de>

Sebastian,

----- Ursprüngliche Mail -----
>> > And that's what Torben implemented unless I'm missing something.
>> 
>> Torben implemented it the other way around, he allows mounting without
>> the HMAC if UBIFS mount is read-only.
>> This covers also the proposed use-case but as I stated it has issues with
>> remounting and makes the implementation more complicated than it should be.
>> 
>> That's why I proposed adding a new mount option like "keep_offline_signature" or
>> what name fits better. That gives us the following pros:
> 
> so you want an extra option instead of setting SB_RDONLY on RO mounts
> without the key and not allowing RW mounts in this case?

Yes.

>> 1. Makes the implementation super simple.
>>    If keep_offline_signature is set and rw mount requested, reject.
>>    RW remount can rejected very easily, store keep_offline_signature in the ubifs
>>    context.
>> 
>> 2. If the super block got already re-written, reject.
>>    You can check sub->hmac[] for being non-zero.
>>    That way we can give the user a decent error message in case they do stupid
>>    things.
> 
> re-written as in a prior RW mount with the key?

Yes.

>> 3. Userspace can verify whether the UBIFS fs is pristine by checking
>>    for the keep_offline_signature mount flag in /proc/self/mountinfo.
> 
> Could this information be dubious if the UBIFS was mounted RW once (with
> the key around) and then mounted RO,keep_offline_signature ? So you
> would have to only allow keep_offline_signature if your point (2) is
> true?

No. Because as soon you mount once RW the super block is re-written with
the provided HMAC. You can detect this and refuse the mount option.

Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2020-07-03  8:21 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-25 15:59 [PATCH 0/1] ubifs: support authentication without hmac Torben Hohn
2020-06-25 15:59 ` [PATCH 1/1] ubifs: support authentication, for ro mount, when no key is given Torben Hohn
2020-06-26  4:31   ` Sascha Hauer
2020-06-26  7:27     ` Torben Hohn
2020-06-26  7:53       ` Richard Weinberger
2020-06-26  8:10       ` Sascha Hauer
2020-06-26  9:39         ` Torben Hohn
2020-06-26  8:09 ` [PATCH 0/1] ubifs: support authentication without hmac Richard Weinberger
2020-06-29  6:46   ` Alexander Dahl
2020-06-29  7:04     ` Richard Weinberger
2020-06-29  7:48       ` Wolfgang Denk
2020-06-29  7:51         ` Richard Weinberger
2020-06-30  5:50           ` Wolfgang Denk
2020-06-30 13:36       ` Richard Weinberger
2020-06-30 14:36         ` Alexander Dahl
2020-06-26 11:29 ` [PATCH v2 0/4] " Torben Hohn
2020-06-26 11:29   ` [PATCH v2 1/4] ubifs: move #include "debug.h" above auth.c Torben Hohn
2020-06-26 11:29   ` [PATCH v2 2/4] ubifs: support authentication, for ro mount, when no key is given Torben Hohn
2020-06-26 11:29   ` [PATCH v2 3/4] ubifs: sprinkle ubifs_assert(c, !c->ro_mount) in hmac auth Torben Hohn
2020-06-26 11:29   ` [PATCH v2 4/4] ubifs: prevent remounting rw when no hmac key was given Torben Hohn
2020-06-26 12:27     ` Richard Weinberger
2020-06-29  8:53       ` Torben Hohn
2020-06-29 10:52         ` Richard Weinberger
2020-06-26 14:16   ` [PATCH v2 0/4] ubifs: support authentication without hmac Richard Weinberger
2020-06-26 14:36     ` Richard Weinberger
2020-06-29  9:13       ` Torben Hohn
2020-06-29  9:07     ` Torben Hohn
2020-06-29 10:46       ` Richard Weinberger
2020-07-02 14:40         ` Thomas Gleixner
2020-07-02 15:00           ` Richard Weinberger
2020-07-02 18:48             ` Thomas Gleixner
2020-07-02 19:03               ` Richard Weinberger
2020-07-03  8:16                 ` bigeasy
2020-07-03  8:20                   ` Richard Weinberger [this message]
2020-07-03  9:12                 ` Thomas Gleixner

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=1352684131.86554.1593764429561.JavaMail.zimbra@nod.at \
    --to=richard@nod.at \
    --cc=bigeasy@linutronix.de \
    --cc=david@sigma-star.at \
    --cc=linux-mtd@lists.infradead.org \
    --cc=s.hauer@pengutronix.de \
    --cc=tglx@linutronix.de \
    --cc=torben.hohn@linutronix.de \
    /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.