[SRU][F][J][aws][cherry-pick] dev file system is mounted without nosuid on aws

[Dave Chiluk]

I tested the 5.15 kernel change and it looks good.  I don't have an
easy way to test the 5.4 kernel.

It booted fine on AWS, and /dev came up with nosuid, and noexec.  I
checked dmesg for the corresponding devtmpfs messages that get spit
out by the kernel, and they were there.  That implies to me that I was
still booting initramfs-less.

This is definitely a security issue, how large of one is debatable.

I did also notice that /dev/hugepages is also mounted without nosuid
or noexec.  That appears to be getting mounted via
/lib/systemd/system/dev-hugepages.mount though, and upstream systemd
does not seem to be doing anything with that
https://github.com/systemd/systemd/blob/main/units/dev-hugepages.mount
.  I don't think this is as much of an issue, but I've been wrong
before.

Dave.

On Fri, Oct 7, 2022 at 12:01 PM Tim Gardner <tim.gardner at canonical.com> wrote:
>
> Marking it as a security ticket at this point seems a little compulsive
> given the fix has been in the kernel for awhile. Anyways, here are some
> test kernels at (1). Sources at (2) and (3).
>
> rtg
>
> (1) - https://kernel.ubuntu.com/~rtg/DEVTMPFS_SAFE-lp1991975/
> (2) - git://git.launchpad.net/~timg-tpi/ubuntu/+source/linux/+git/focal
> focal-DEVTMPFS_SAFE-lp1991975
> (3) - git://git.launchpad.net/~timg-tpi/ubuntu/+source/linux/+git/jammy
> jammy-DEVTMPFS_SAFE-lp1991975
>
> On 10/7/22 09:16, Dave Chiluk wrote:
> > The security team asked that I mark it as a Security ticket late last
> > night until they have a better chance to review it.
> >
> > The text of the bug basically comes down to this.  The dev file system
> > is mounted without nosuid or noexec when on aws.  This is because the
> > aws images boot via an initramfs-less mechanism.  This causes the
> > default in-kernel init to be run.  This mounts dev without the
> > required options.  When systemd starts it does not re-mount /dev with
> > the proper options like
> > it probably should.  The few userspace workarounds I tried failed.
> > The proper fix as I see it is really this kernel commit.
> >
> > This was discovered when running
> > https://github.com/dev-sec/ansible-collection-hardening
> > and
> > https://github.com/dev-sec/linux-baseline
> >
> > The reason this matters is that without nosuid and noexec people could
> > use /dev to escalate privileges.  One possible scenario might include
> > using containers. I'm sure the security team probably can come up with
> > even scarier scenarios.  Either way it's best practice to have those
> > mount options set.
> >
> > I was hoping to do some testing of this today, but from what I
> > remember building the aws specific kernels is not straightforward and
> > a bunch of you have hand-built scripts to make that happen.  If you
> > supply/wiki-fy instructions for building the aws kernel, I'll try to
> > do some actual testing today.  Really testing is pretty simple once
> > you have a kernel built in that you boot it and check for nosuid and
> > noexec on /dev.
> >
> > Dave.
> >
> >
> > Dave.
> >
> > On Fri, Oct 7, 2022 at 8:25 AM Tim Gardner <tim.gardner at canonical.com> wrote:
> >>
> >> On 10/7/22 07:17, Tim Gardner wrote:
> >>> On 10/6/22 17:03, Dave Chiluk wrote:
> >>>> Please cherry-pick 28f0c335d from Linus's tree.  It was applied to
> >>>> 5.17.  Please take care to set DEVTMPFS_SAFE=y in the config file.
> >>>>
> >>>> This is a security regression from when aws instances started booting
> >>>> initramfs-less.  Any other kernel that is booting initramfs-less will
> >>>> likely hit this as well.
> >>>>
> >>>> For machines that have an initramfs this is not an issue as the
> >>>> initramfs:main/init mounts devtmpfs with the correct options.
> >>>>
> >>>> I mostly only care about focal and jammy -aws kernels (which I suspect
> >>>> are both 5.15. It applies cleanly to 5.15, and should be a
> >>>> straightforward backport to any others that you deem appropriate.
> >>>>
> >>>> I welcome discussion as to the necessity of this as /dev is still
> >>>> owned by root:root.  Regardless, it's definitely not best security
> >>>> practice, and I'm sure someone smarter than me can figure out a way to
> >>>> exploit it.
> >>>>
> >>>> WARNING: I also haven't tested this yet as I do not know how to build
> >>>> a -aws flavored kernel and would really appreciate instructions on how
> >>>> to do so (building any other flavor likely won't be able to reproduce
> >>>> since it'll require the initramfs for boot).  I also wanted to get
> >>>> this out to you as a lot of you are in Europe and can respond while
> >>>> I'm sleeping.
> >>>>
> >>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975
> >>>>
> >>>> Thanks,
> >>>> Dave Chiluk.
> >>>> p.s. Hey folks it's been far too long, let's get a beer next time you
> >>>> are in my neck of the woods!
> >>>>
> >>>
> >>> Hi Dave - that doesn't seem to be a valid LP bug number.
> >>>
> >>
> >> Or maybe its marked private ? At any rate, I can't see it.
> >>
> >> rtg
> >>
> >> --
> >> -----------
> >> Tim Gardner
> >> Canonical, Inc
>
>
> --
> -----------
> Tim Gardner
> Canonical, Inc