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

[Tim Gardner]

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