lkml.org 
[lkml]   [2011]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule
    On 6 Jun 2011 at 16:44, Ingo Molnar wrote:
    > * pageexec@freemail.hu <pageexec@freemail.hu> wrote:
    >
    > > > > Seriously. The whole patch series just seems annoying.
    > >
    > > what is annoying is your covering up of security fixes on grounds
    > > that you don't want to help script kiddies (a bullshit argument as
    > > it were) but at the same time question proactive security measures
    > > (one can debate the implementation, see my other mail) that would
    > > *actually* prevent the same kiddies from writing textbook exploits.
    >
    > You are mixing up several issues here, and rather unfairly so.

    but it's very simple logic Ingo. it goes like 'I am not willing to
    do A because it would help script kiddies but I'd rather do B that
    would help script kiddies'. with A = 'disclose security bugs' and
    B = 'keep the last roadblock that prevents full ASLR'.

    if someone's that worried about script kiddies as Linus claims to be
    (which i always called a BS argument, but let's accept here), he can't
    possibly argue for keeping the vsyscall page at a fixed address around,
    simple as that.

    and it is for security, no other reason, else you'd have to accept a patch
    that maps the vdso at a fixed address again or come up with some very
    convincing arguments why the vdso must stay randomized but the vsyscall
    page is fine at a fixed address (i guess neither is forthcoming but you
    guys can act in surprising ways, so i'm not placing any bets ;).

    > Firstly, see my other mail, there's an imperfect balance to be
    > found between statistical 'proactive' measures and the incentives
    > that remove the *real* bugs.

    i hope i replied to this already now to your satisfaction else feel free
    to elaboarte.

    > Secondly, *once* a real security bug has been found the correct
    > action is different from the considerations of proactive measures.

    as i said already, you're mixing up fixing bugs and fighting exploit
    techniques. apples vs. oranges.

    > How can you possibly draw equivalence between disclosure policies
    > and the handling of statistical security measures?

    see the simple logic above.



    \
     
     \ /
      Last update: 2011-06-06 21:05    [W:0.024 / U:32.420 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site