linux-kernel - Re: [Security] proactive defense: using read-only memory

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20101117221443.GR13854@outflux.net>
Date:	Wed, 17 Nov 2010 14:14:43 -0800
From:	Kees Cook <kees.cook@...onical.com>
To:	Pavel Machek <pavel@....cz>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [Security] proactive defense: using read-only memory

Hi Pavel,

On Wed, Nov 17, 2010 at 11:00:54AM +0100, Pavel Machek wrote:
> > - Modules need to be correctly marked RO/NX. This patch exists[3], but is
> >   not in mainline. It needs to be in mainline.
> 
> Why not.

That was answered in another thread: basically, it was side-tracked, but
has been recently re-proposed.

> > - Pointers to function table also need to be marked read-only after
> >   they are set. An example of this is the security_ops table pointer. It
> >   gets set once at boot, and never changes again. These need to be handled
> >   so it isn't possible to just trivially reaim the entire security_ops
> >   table lookup somewhere else.
> 
> But there are too many of those. You can't block them all...

Well, I don't think "too many" is a good reason. And I think it is possible
to block them all if we're careful and diligent. Maybe I'm naive; we'll see.

> > - Entry points to set_kernel_text_rw() and similar need to be blockable.
> >   Having these symbols available make kernel memory modification trivial;
> 
> What prevents attacker to just inlining those functions in the
> exploit?

The goal is to make it harder for an attacker to create, change, or hide
kernel code in memory. If they're able to already execute arbitrary code,
then yes, it's doesn't change anything. But the point is to make it harder
to get to that point to start with.

> If you want protection domain inside kernel, perhaps you should take
> ukernel approach?

Someone might want to, but I'm not interested in that. It's not impossible
to make the existing kernel more resilient to attack.

-Kees

-- 
Kees Cook
Ubuntu Security Team
--
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/