lkml.org 
[lkml]   [2011]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] System Wide Capability Bounding Set
    From
    On Tue, Feb 1, 2011 at 1:26 PM, Serge E. Hallyn
    <serge.hallyn@canonical.com> wrote:
    > Quoting Eric Paris (eparis@redhat.com):
    >> What are we thinking?  Any suggestions how to do what we need other than
    >>
    >> global bounding such that  pP' = gbset & (fI | pI)
    >
    > That should be sufficient for what you want.
    >
    > I would however like to hear whether Andrew has had any other ideas
    > given the broader picture.
    >

    I think I now see what you are after.

    You want some sort of transient TCB that can lock all of the doors you
    care to lock and then run the whole system in a partially crippled
    sandbox.

    I have some concerns about how you know you have truly locked down the
    system and question the viability of a VM that doesn't virtualize IO
    too, but presumably you have some way to protect the storage of the
    kernel binary and initrd that cannot be overcome, and protections from
    DMA etc. being used by the guest to to overwrite kernel memory.

    In this case, I would like to suggest what you need is a user
    configurable state for kernel threads to launch helper programs - a
    kernel side equivalent to Sergey's wrapper idea. I continue to
    dislike the global bounding set idea, but I would support a base
    credential set for this kthread launcher. I'd include pI, bset, and
    securebits and uid as something your initrd could initialize away from
    their default values for kernel launched helper binaries. I'd prefer
    it if you allowed the regular capability convolution rules to apply
    and propagate this bounding set for all kernel launched binaries, and
    also add the relevant code to init to enforce your desired bounding
    set for init parented processes.

    This way you will both meet your current needs and also maintain
    support for a capability managed 'raw' kernel experience with no
    asynchronous capability manipulation system-wide.

    Cheers

    Andrew


    >> Or an interface in which I can force things out of the bset and pI of
    >> other tasks?  Possibly the interface could be specific to the "khelper"
    >> thread?
    >
    > No no no no no :)
    >
    > thanks,
    > -serge
    >
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-02-02 05:05    [W:0.025 / U:125.212 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site