From: Richard Weinberger <richard@nod.at>
To: Torben Hohn <torben.hohn@linutronix.de>
Cc: bigeasy <bigeasy@linutronix.de>,
linux-mtd <linux-mtd@lists.infradead.org>,
tglx <tglx@linutronix.de>, david <david@sigma-star.at>,
Sascha Hauer <s.hauer@pengutronix.de>
Subject: Re: [PATCH v2 0/4] ubifs: support authentication without hmac
Date: Mon, 29 Jun 2020 12:46:52 +0200 (CEST) [thread overview]
Message-ID: <1031805083.71374.1593427612787.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <20200629090734.GB17241@linutronix.de>
Torben,
----- Ursprüngliche Mail -----
>> The ro mount will fail because UBIFS is no longer able to verify the super block
>> using the system key ring. It was overwritten by they ubifs:authfs key.
>
> Yes. But that is the intended behaviour.
> If the filesystem has been changed, it must not be mounted again.
In your use case.
> I would rather like to make it impossible to mount the filesystem in rw
> mode, because this is an attack scenario. It would refuse to mount upon
> reboot. Making it possible to remount root rw, with a fresh key is
> nice for development, but its not desired in production.
>
>
>>
>> A possible solution is keeping a copy of the offline sign key forever in the fs.
>> But I'm not sure whether this is wise.
>
> Heh ? you mean the private key. NO
No, I used bad wording. :-)
The superblock is signed by the offline key. As soon you switch to the new key
the super block is rewritten and can no longer verified this key.
Instead of rewriting the idea was keeping a copy.
Anyway, like said in the other mail, I think if we change the feature to
"keep offline sign key and imply ro mount" things will be more smooth with less corner
cases.
Thanks,
//richard
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-06-29 10:48 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 [this message]
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
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=1031805083.71374.1593427612787.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).