| Message ID | 20200626112907.13201-1-torben.hohn@linutronix.de |
|---|---|
| Headers | show |
| Series | ubifs: support authentication without hmac | expand |
Torben, ----- Ursprüngliche Mail ----- > Von: "Torben Hohn" <torben.hohn@linutronix.de> > An: "richard" <richard@nod.at> > CC: "bigeasy" <bigeasy@linutronix.de>, "tglx" <tglx@linutronix.de>, "linux-mtd" <linux-mtd@lists.infradead.org>, "Sascha > Hauer" <s.hauer@pengutronix.de> > Gesendet: Freitag, 26. Juni 2020 13:29:03 > Betreff: [PATCH v2 0/4] ubifs: support authentication without hmac > This PQ adds support for ubifs authentication without HMAC, > which obviously only works for a read-only mount. > > ubiblock and dm-verity are not supported by u-boot, and > the kernel on the target is loaded by u-boot out of the RFS. > > This is a first try to implement this. > It boots fine, and the WARN_ON is not triggered. > > I plan to update the docs also, but i would like to have > some positive comments on this before. > > Changes since v1: > > - apply comments from Sascha an revert the > ubifs_authicated_(read|write) stuff. > Use ubifs_assert(c, !c->ro_mount) instead. > - Prevent remount rw, when hmac-less authentication is used > - add missing check, for ro mode, when no auth_key_name is specified. I didn't dig deep into the code so far, I'm still checking the concept. Your approach works only on pristine offline signed images from mkfs.ubifs. So, if somebody does this, it won't work: $ keyctl padd logon ubifs:authfs @s < secret.key $ mount -t ubifs /dev/ubi0_0 /mnt/ -o auth_hash_name=sha256,auth_key=ubifs:authfs ... change the fs ... $ umount /mnt $ mount -t ubifs /dev/ubi0_0 /mnt/ -o auth_hash_name=sha256,ro 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. 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. Thanks, //richard
----- Ursprüngliche Mail ----- > I didn't dig deep into the code so far, I'm still checking the concept. > > Your approach works only on pristine offline signed images from mkfs.ubifs. > So, if somebody does this, it won't work: > > $ keyctl padd logon ubifs:authfs @s < secret.key > $ mount -t ubifs /dev/ubi0_0 /mnt/ -o > auth_hash_name=sha256,auth_key=ubifs:authfs > > ... change the fs ... > > $ umount /mnt > $ mount -t ubifs /dev/ubi0_0 /mnt/ -o auth_hash_name=sha256,ro > > 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. > > 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. Or we change the feature from "ro mount without hmac" to "keep offline sign key and imply ro mount". IOW adding a new mount option such as "auth_keep_offlinekey". If mounted with this option UBIFS will not look for a hmac and enforce read-only mode. Hmm? Thanks, //richard
On Fri, Jun 26, 2020 at 04:16:51PM +0200, Richard Weinberger wrote: > Torben, > > ----- Ursprüngliche Mail ----- > > Von: "Torben Hohn" <torben.hohn@linutronix.de> > > An: "richard" <richard@nod.at> > > CC: "bigeasy" <bigeasy@linutronix.de>, "tglx" <tglx@linutronix.de>, "linux-mtd" <linux-mtd@lists.infradead.org>, "Sascha > > Hauer" <s.hauer@pengutronix.de> > > Gesendet: Freitag, 26. Juni 2020 13:29:03 > > Betreff: [PATCH v2 0/4] ubifs: support authentication without hmac > > > This PQ adds support for ubifs authentication without HMAC, > > which obviously only works for a read-only mount. > > > > ubiblock and dm-verity are not supported by u-boot, and > > the kernel on the target is loaded by u-boot out of the RFS. > > > > This is a first try to implement this. > > It boots fine, and the WARN_ON is not triggered. > > > > I plan to update the docs also, but i would like to have > > some positive comments on this before. > > > > Changes since v1: > > > > - apply comments from Sascha an revert the > > ubifs_authicated_(read|write) stuff. > > Use ubifs_assert(c, !c->ro_mount) instead. > > - Prevent remount rw, when hmac-less authentication is used > > - add missing check, for ro mode, when no auth_key_name is specified. > > I didn't dig deep into the code so far, I'm still checking the concept. > > Your approach works only on pristine offline signed images from mkfs.ubifs. > So, if somebody does this, it won't work: > > $ keyctl padd logon ubifs:authfs @s < secret.key > $ mount -t ubifs /dev/ubi0_0 /mnt/ -o auth_hash_name=sha256,auth_key=ubifs:authfs > > ... change the fs ... > > $ umount /mnt > $ mount -t ubifs /dev/ubi0_0 /mnt/ -o auth_hash_name=sha256,ro > > 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. 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 When its not possible to store a secret on the h/w then the only option we have is asymmetric sigatures, with the private key never being on the device. This obviously means, that the device is not able to write to RFS. > > Thanks, > //richard
On Fri, Jun 26, 2020 at 04:36:26PM +0200, Richard Weinberger wrote: > ----- Ursprüngliche Mail ----- > > I didn't dig deep into the code so far, I'm still checking the concept. > > > > Your approach works only on pristine offline signed images from mkfs.ubifs. > > So, if somebody does this, it won't work: > > > > $ keyctl padd logon ubifs:authfs @s < secret.key > > $ mount -t ubifs /dev/ubi0_0 /mnt/ -o > > auth_hash_name=sha256,auth_key=ubifs:authfs > > > > ... change the fs ... > > > > $ umount /mnt > > $ mount -t ubifs /dev/ubi0_0 /mnt/ -o auth_hash_name=sha256,ro > > > > 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. > > > > 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. > > Or we change the feature from "ro mount without hmac" to "keep offline sign key and imply ro mount". > IOW adding a new mount option such as "auth_keep_offlinekey". If mounted with this option > UBIFS will not look for a hmac and enforce read-only mode. Thats just another name for the same feature. But it indeed seems to make the implications clearer. And it porbably also makes the code easier to read. > > Hmm? > > Thanks, > //richard
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
Richard Weinberger <richard@nod.at> writes: > 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. I don't think so. The desired mode is to prevent RW mounts for a factory signed image which implies the prevention of rewriting the superblock. This is not a conveniance feature, it's a strict security feature. Once the thing has been changed from the factory generated state it's invalid no matter what. If a developer shoots himself in the foot with that, no big deal. He got what he asked for :) Thanks, tglx
----- Ursprüngliche Mail ----- > Von: "tglx" <tglx@linutronix.de> > An: "richard" <richard@nod.at>, "Torben Hohn" <torben.hohn@linutronix.de> > CC: "bigeasy" <bigeasy@linutronix.de>, "linux-mtd" <linux-mtd@lists.infradead.org>, "Sascha Hauer" > <s.hauer@pengutronix.de>, "david" <david@sigma-star.at> > Gesendet: Donnerstag, 2. Juli 2020 16:40:24 > Betreff: Re: [PATCH v2 0/4] ubifs: support authentication without hmac > Richard Weinberger <richard@nod.at> writes: >> 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. > > I don't think so. The desired mode is to prevent RW mounts for a factory > signed image which implies the prevention of rewriting the superblock. This is exactly what I'm asking for. Keep the factory signed super block and imply read-only mode. Thanks, //richard
Richard Weinberger <richard@nod.at> writes: > ----- Ursprüngliche Mail ----- >> Von: "tglx" <tglx@linutronix.de> >> An: "richard" <richard@nod.at>, "Torben Hohn" <torben.hohn@linutronix.de> >> CC: "bigeasy" <bigeasy@linutronix.de>, "linux-mtd" <linux-mtd@lists.infradead.org>, "Sascha Hauer" >> <s.hauer@pengutronix.de>, "david" <david@sigma-star.at> >> Gesendet: Donnerstag, 2. Juli 2020 16:40:24 >> Betreff: Re: [PATCH v2 0/4] ubifs: support authentication without hmac > >> Richard Weinberger <richard@nod.at> writes: >>> 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. >> >> I don't think so. The desired mode is to prevent RW mounts for a factory >> signed image which implies the prevention of rewriting the superblock. > > This is exactly what I'm asking for. > Keep the factory signed super block and imply read-only mode. And that's what Torben implemented unless I'm missing something. Thanks, tglx
----- Ursprüngliche Mail ----- >>>> 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. >>> >>> I don't think so. The desired mode is to prevent RW mounts for a factory >>> signed image which implies the prevention of rewriting the superblock. >> >> This is exactly what I'm asking for. >> Keep the factory signed super block and imply read-only mode. > > 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: 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. 3. Userspace can verify whether the UBIFS fs is pristine by checking for the keep_offline_signature mount flag in /proc/self/mountinfo. Thanks, //richard
On 2020-07-02 21:03:54 [+0200], Richard Weinberger wrote: > ----- Ursprüngliche Mail ----- > >>>> 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. > >>> > >>> I don't think so. The desired mode is to prevent RW mounts for a factory > >>> signed image which implies the prevention of rewriting the superblock. > >> > >> This is exactly what I'm asking for. > >> Keep the factory signed super block and imply read-only mode. > > > > 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? > 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? > 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? > Thanks, > //richard Sebastian
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
Richard Weinberger <richard@nod.at> writes: >> 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: > > 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. > > 3. Userspace can verify whether the UBIFS fs is pristine by checking > for the keep_offline_signature mount flag in /proc/self/mountinfo. Works for me.