[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 4/3] x86/ldt: allow to disable modify_ldt at runtime

On Sat, Jul 25, 2015 at 6:03 AM, Willy Tarreau <w@xxxxxx> wrote:
> On Sat, Jul 25, 2015 at 09:50:52AM +0200, Willy Tarreau wrote:
>> On Fri, Jul 24, 2015 at 11:44:52PM -0700, Andy Lutomirski wrote:
>> > I'm all for it, but I think it should be hard-disablable in config,
>> > too, for the -tiny people.
>> I totally agree.
>> > If we add a runtime disable, let's do a
>> > separate patch, and you and Kees can fight over how general it should
>> > be.
>> Initially I was thinking about changing it for a 3-state option but
>> that would prevent X86_16BIT from being hard-disablable, so I'll do
>> something completely separate.
> So here comes the proposed patch. It adds a default setting for the
> sysctl when the option is not hard-disabled (eg: distros not wanting
> to take risks with legacy apps). It suggests to leave the option off.
> In case a syscall is blocked, a printk_ratelimited() is called with
> relevant info (program name, pid, uid) so that the admin can decide
> whether it's a legitimate call or not. Eg:
>   Denied a call to modify_ldt() from a.out[1736] (uid: 100). Adjust sysctl if 
> this was not an exploit attempt.
> I personally think it completes well your series, hence the 4/3 numbering.
> Feel free to adopt it if you cycle another round and if you're OK with it
> of course.
> CCing Kees as well.

This patch looks reasonable, but I'd prefer a tri-state (enable,
disable, hard-disable). I do something like this for Yama's ptrace
zero to max_scope range (which "pins" to max_scope if set):



Kees Cook
Chrome OS Security

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.