[lkml]   [2009]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 00/30] C/R OpenVZ/Virtuozzo style
    On Wed, 2009-04-15 at 00:49 +0400, Alexey Dobriyan wrote:
    > > Going back to my example of a subtree above: what sort of security
    > > issues you would have here, assuming all restart operations go via
    > > the usual security checks just like syscalls, and we take special
    > > care about values we allow as input, e.g. cpu debug registers etc ?
    > This is like asking if everything goes through correct security checks
    > how will you screw something up. Everything won't go via usual security
    > checks.
    > Just for giggles, writing exploit for localhost hole becomes easier --
    > you very effectively turn off all randomization kernel does because VMA
    > boundaries comes from disk.

    Alexey, I think there's a bit of a misunderstanding here. We're
    proposing that whatever gets done during the restart would not be able
    to elevate above the privilege level of the user doing the restart. For
    instance, a user would not be able to restart a suid application -- that
    would require privilege.

    In the same way, at checkpoint time, we should deny users the ability to
    checkpoint things that are privileged. We need to pay very close
    attention to the kernel interfaces that we use to ensure that all the
    normal security checks are observed, of course.

    There's no new hole. A restore operation is just a pieced-together set
    of operations that the user would have already been able to perform.

    Again, I think this stems from some of us that think that c/r should be
    used outside exclusively checkpointing whole containers. I think we'll
    find some expanded use for c/r on things that aren't strict system

    -- Dave

     \ /
      Last update: 2009-04-14 23:15    [W:0.021 / U:0.064 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site