Writing to stateful partition of a recovery USB stick

[ahas...@chromium.org]

Hi All,

I'm looking for a solution for a problem I have. In a few words I need to write a file into a Chrome OS recovery USB stick's stateful partition from user space. Basically I need to create a config file and put it in the stateful partition after the recovery image is created. You can think of it as the Chrome OS recovery utility being able to write a file into the stateful partition of the recovery image after it creates it.

However, the problem is I think since the recovery image was created in root, the uid and gid for the stateful partition are for root. When we insert the recovery USB in Chromebook, the OEM and stateful partitions are mounted as root. Hence, there is no write permission in the user space. For example, there would be no way to modify its content from Chrome. My question is, is mounting it as root really necessary? The USB drive is already mounted and why not allow write access in user space? Is there any way we can set the uid and gid of the recovery partition to root during recovery so we can set them as user space like chronos normally? Is there a security concern?

Am I misunderstanding anything here?

BTW, the stateful partition of the USB recovery seems to be ext2 as shown below:

/dev/sdb1 on /media/ahassani/85979eec-b0fc-4ecd-aeef-fc83e73c547e type ext2 (rw,nosuid,nodev,relatime,block_validity,barrier,user_xattr,acl,uhelper=udisks2)

/dev/sdb8 on /media/ahassani/OEM type ext4 (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2)

But the stateful partition on a device is ext4? Do we do any migration during chromeos-install?

Thanks,

- Amin

[Richard Barnette]

> On Apr 25, 2018, at 1:47 PM, ahas...@chromium.org wrote:
>
> Hi All,
>
> I'm looking for a solution for a problem I have. In a few words I need to write a file into a Chrome OS recovery USB stick's stateful partition from user space. Basically I need to create a config file and put it in the stateful partition after the recovery image is created. You can think of it as the Chrome OS recovery utility being able to write a file into the stateful partition of the recovery image after it creates it.
>
> However, the problem is I think since the recovery image was created in root, the uid and gid for the stateful partition are for root. When we insert the recovery USB in Chromebook, the OEM and stateful partitions are mounted as root. Hence, there is no write permission in the user space. For example, there would be no way to modify its content from Chrome. My question is, is mounting it as root really necessary? The USB drive is already mounted and why not allow write access in user space? Is there any way we can set the uid and gid of the recovery partition to root during recovery so we can set them as user space like chronos normally? Is there a security concern?
>

During recovery, chromeos-install will run as root, so there
shouldn't be any trouble reading from stateful, per se.

However the stateful partition isn't guaranteed to be mounted.
If there's content on the stateful partition to be installed
during recovery, that work has to be done at a particular
time. Look for the function install_stateful; any work to
read/install from stateful has to be done inside that function.

> Am I misunderstanding anything here?
>
> BTW, the stateful partition of the USB recovery seems to be ext2 as shown below:
>
> /dev/sdb1 on /media/ahassani/85979eec-b0fc-4ecd-aeef-fc83e73c547e type ext2 (rw,nosuid,nodev,relatime,block_validity,barrier,user_xattr,acl,uhelper=udisks2)
> /dev/sdb8 on /media/ahassani/OEM type ext4 (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2)
>
> But the stateful partition on a device is ext4? Do we do any migration during chromeos-install?
>

During chromeos-install, the stateful partition on the target
storage is created from scratch (with mkfs) as ext4.


> Thanks,
> - Amin
>
> --
> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>

[Mike Frysinger]

the person who initiates the mount doesn't matter to ext[234].  either way, in our current system, the kernel fs driver is going to be used, and it doesn't have support for uid=/gid= mount options.  which means it doesn't offer any way of overriding the root owned permissions.  so in this context, "mounting as root" and "mounting as non-root" is irrelevant.

if you're asking we chown the dirs/files to something else when we create the recovery image, then that's probably a hard no.

-mike

--

[ahas...@chromium.org]

On Wednesday, April 25, 2018 at 7:50:48 PM UTC-7, Mike Frysinger wrote:

the person who initiates the mount doesn't matter to ext[234].  either way, in our current system, the kernel fs driver is going to be used, and it doesn't have support for uid=/gid= mount options.  which means it doesn't offer any way of overriding the root owned permissions.  so in this context, "mounting as root" and "mounting as non-root" is irrelevant.

if you're asking we chown the dirs/files to something else when we create the recovery image, then that's probably a hard no.

Ok, I understand, What if we add a new directory with a non-root owner in the stateful partition when building the recovery image? Would it be any problem as long as we do not run any executable from that there?

Thanks,

- Amin

[Mike Frysinger]

On Sat, Apr 28, 2018 at 2:00 AM <ahas...@chromium.org> wrote:

On Wednesday, April 25, 2018 at 7:50:48 PM UTC-7, Mike Frysinger wrote:

the person who initiates the mount doesn't matter to ext[234].  either way, in our current system, the kernel fs driver is going to be used, and it doesn't have support for uid=/gid= mount options.  which means it doesn't offer any way of overriding the root owned permissions.  so in this context, "mounting as root" and "mounting as non-root" is irrelevant.

if you're asking we chown the dirs/files to something else when we create the recovery image, then that's probably a hard no.

Ok, I understand, What if we add a new directory with a non-root owner in the stateful partition when building the recovery image? Would it be any problem as long as we do not run any executable from that there?

the mount wouldn't be executable, so wouldn't matter even if you did try to run something :)

not to bikeshed, but do you have a suggestion for a name ?  i'd hesitate to use "tmp" or "log" because i could see people starting to use that for their own tmp/log purposes which we don't want.

[ahas...@chromium.org]

On Friday, April 27, 2018 at 12:28:21 PM UTC-7, Mike Frysinger wrote:

On Sat, Apr 28, 2018 at 2:00 AM <ahas...@chromium.org> wrote:

On Wednesday, April 25, 2018 at 7:50:48 PM UTC-7, Mike Frysinger wrote:

the person who initiates the mount doesn't matter to ext[234].  either way, in our current system, the kernel fs driver is going to be used, and it doesn't have support for uid=/gid= mount options.  which means it doesn't offer any way of overriding the root owned permissions.  so in this context, "mounting as root" and "mounting as non-root" is irrelevant.

if you're asking we chown the dirs/files to something else when we create the recovery image, then that's probably a hard no.

Ok, I understand, What if we add a new directory with a non-root owner in the stateful partition when building the recovery image? Would it be any problem as long as we do not run any executable from that there?

the mount wouldn't be executable, so wouldn't matter even if you did try to run something :)

not to bikeshed, but do you have a suggestion for a name ?  i'd hesitate to use "tmp" or "log" because i could see people starting to use that for their own tmp/log purposes which we don't want.

-mike

I was thinking something like usb-enrollment. Probably like unencrypted/usb-enrollment but I don't think it matters which directory it sits. Basically we would put a json config file in there that we will transfer to the stateful partition during recovery and use it during after reboot OOBE.

[Richard Barnette]

> On Apr 27, 2018, at 12:27 PM, Mike Frysinger <vap...@chromium.org> wrote:
>
> On Sat, Apr 28, 2018 at 2:00 AM <ahas...@chromium.org> wrote:
> On Wednesday, April 25, 2018 at 7:50:48 PM UTC-7, Mike Frysinger wrote:
> the person who initiates the mount doesn't matter to ext[234]. either way, in our current system, the kernel fs driver is going to be used, and it doesn't have support for uid=/gid= mount options. which means it doesn't offer any way of overriding the root owned permissions. so in this context, "mounting as root" and "mounting as non-root" is irrelevant.
>
> if you're asking we chown the dirs/files to something else when we create the recovery image, then that's probably a hard no.
> Ok, I understand, What if we add a new directory with a non-root owner in the stateful partition when building the recovery image? Would it be any problem as long as we do not run any executable from that there?
>
> the mount wouldn't be executable, so wouldn't matter even if you did try to run something :)
>
> not to bikeshed, but do you have a suggestion for a name ? i'd hesitate to use "tmp" or "log" because i could see people starting to use that for their own tmp/log purposes which we don't want.

"log" (or maybe "logs") is already taken. I agree that "tmp"
isn't much better, unless we're willing to allow it to accumulate
random gunk, which seems like a bad idea.