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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 20 Nov 2012 16:41:27 -0800
From:	Kees Cook <keescook@...omium.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	ellyjones@...omium.org, Kay Sievers <kay@...y.org>,
	Roland Eggner <edvx1@...temanalysen.net>
Subject: Re: [PATCH v2] devtmpfs: mount with noexec and nosuid

On Tue, Nov 20, 2012 at 4:24 PM, Alan Cox <alan@...rguk.ukuu.org.uk> 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.

> Right now you can add one call to your user space and it just works, with
> old kernels, with new kernels, with Android etc. You think its *more
> efficient* to add permanently loaded kernel hacks.

I'm not interested in those things. That said, if it genuinely agreed
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.

> 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 can we put the crap about efficiency away please. This basically reads
> like
>
> "Mummy, the mount syscall looks complicated let me hack everyones kernel
>  with a crass extra Kconfig option because I'm crap"

I think you just switched from calling my code crap to calling me crap.

>> > You don't want to stop mmap with PROT_EXEC on /dev/mem as that breaks a
>> > load of stuff, you want to stop people adding stuff to that file system
>> > and executing it.
>>
>> Well, initially the latter, yes. But as it turns out, setting noexec
>> also stops PROT_EXEC on /dev/mem. Since the systems I'm building for
>> all use KMS, there's no need to execute regions of /dev/mem (e.g. VESA
>> BIOS init, etc).
>
> I have news for you: this is the upstream kernel, you specific personal
> needs should not define what is good design - this isn't GNOME.

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.

> If you block exec on anything but devices then all is happy. You could
> even block it on anything but specific devices. At that point you could
> get rid of the config option and make it more useful.

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.

> 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.

> NAK

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.

-Kees

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