Re: [PATCH v2] devtmpfs: mount with noexec and nosuid

[Alan Cox]

On Tue, 20 Nov 2012 16:41:27 -0800
Kees Cook <keescook@xxxxxxxxxxxx> wrote:

> On Tue, Nov 20, 2012 at 4:24 PM, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
> >> > You just broke my bullshitometer
> >> >
> >> > It's a single syscall from your init binary, its microseconds.
> >>
> >> Whatever, I still see it as a needless inefficiency.
> >
> > As opposed to adding permanent kernel code and having to change the
> > setting by recompilation, and not being able to deploy this with older
> > kernels.
> 
> Some organizations only support their single "current" kernel, and
> always move forward.

This is not GNOME. Your specific organisational choices are not the sole
decider.

> I'm not interested in those things.

This is not GNOME. 

> that this clear lack of security best-practice (W^X) in the kernel
> isn't the place to fix it, I'll move on. There are still legacy video
> drivers and things that can't operate with this configuration, but the
> kernel mounting devtmpfs shouldn't _require_ userspace to clean up
> after a buggy kernel.

The kernel is not "buggy". It merely has defaults you don't personally
like. They are configurable via userspace. Policy belongs in userspace.

> > Wrong. Big time wrong. A page is 4096 bytes, your change is probably
> > about 8. So 1 in 512 builds will see an extra page of kernel space used
> > assuming an even distribution. For each of those users the moment they've
> > had a few page faults your solution is *less* efficient, and the moment
> > they've paged one page because of having less memory your solution has
> > become vastly less efficient.
> 
> My patch doesn't change the code size there after the most recent
> change to use a constant value again, so the only change I can see
> would be if someone built with /proc/config.gz which would show the
> new config.

So in actual fact going by distro choices its worse than I thought 8)

> Heh, I support your dig at GNOME, but refute this being a "specific
> personal need". Best-practices are clear here. The only reason the
> kernel hasn't been doing it is fear of breaking legacy video drivers.

Thats not true. Nor is it a case of "Not doing". This feature has been
supported for over ten years. We also support more flexible alternatives
like using SELinux, Smack or AppArmor for it. Right now I can do no exec
for /dev except for specific files entirely by security rules.

> Security is layers, and is never perfect. We already do a fair bit of
> process confinement, but this change seemed to be clear low-hanging
> fruit.

It's not a bad idea - but its a single userspace syscall in your init
code. Has been for over a decade.

> > We don't need extra confusion Kconfig options, we don't need extra kernel
> > code combinations to fail to maintain. Your patch offers *NO* feature
> > advantages over the existing kernel.
> 
> I disagree. It allows a system builder to opt-in to correcting a
> kernel flaw introduced by the need to support legacy devices in the
> case where an initramfs isn't used.

Thats a fiction you invented. It's completely irrelevant to most systems
and its already long supported. I think doing that mount in Chrome is
sensible. I think doing it in userspace as we've supported for over a
decade is rather smarter than kernel hacks. You don't have to pee in
other people's ponds that way or achieve consensus you can just go do
what you need.

> I don't understand why you're so violently opposed to letting an
> arguably flawed constant get fixed. I'm not even asking for this to be
> on by default.

Because its a pointless option. It adds nothing but an extra Kconfig
option for everyone. It's a complete waste. Policy belongs in user space.

Fix your userspace. It can't be *that* hard to add a mount call to a
chromium init. It's hardly rocket science. That gives you what you want,
avoids more configuration options, and doesn't mess up compatibility or
add confusing interactions for those users already using more flexible
security options than your mount.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/