lkml.org 
[lkml]   [2008]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [PATCH] cgroups: devices: add Documentation/ file
    Quoting Randy Dunlap (randy.dunlap@oracle.com):
    > On Thu, 27 Mar 2008 10:12:27 -0500 Serge E. Hallyn wrote:
    >
    > > Fill a Documentation/controllers/devices.txt file with a
    > > modified text from the patch description.
    > >
    > > Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
    > > ---
    > > Documentation/controllers/devices.txt | 48 +++++++++++++++++++++++++++++++++
    > > 1 files changed, 48 insertions(+), 0 deletions(-)
    > > create mode 100644 Documentation/controllers/devices.txt
    > >
    > > diff --git a/Documentation/controllers/devices.txt b/Documentation/controllers/devices.txt
    > > new file mode 100644
    > > index 0000000..a157f53
    > > --- /dev/null
    > > +++ b/Documentation/controllers/devices.txt
    > > @@ -0,0 +1,48 @@
    > > +Device Whitelist Controller
    > > +
    > > +1. Description:
    > > +
    >
    > ...
    >
    > > +The root device cgroup starts with rwm to 'all'. A child devices
    >
    > device's

    That's actually not right, but 'child device cgroup' does sound better.

    >
    > > +cgroup gets a copy of the parent. Administrators can then remove
    > > +devices from the whitelist or add new entries. A child cgroup can
    > > +never receive a device access which is denied its parent. However
    > > +when a device access is removed from a parent it will not also be
    > > +removed from the child(ren).
    > > +
    > > +2. User Interface
    > > +
    > ...
    > > +
    > > +3. Security
    > > +
    > > +Any task can move itself between cgroups. This of clearly won't
    >
    > s/of//

    Yup, oops.

    New patch attached. Thanks, Randy.

    -serge

    > > +suffice, but we can decide the best way to adequately restrict
    > > +movement as people get some experience with this. We may just want
    > > +to require CAP_SYS_ADMIN, which at least is a separate bit from
    > > +CAP_MKNOD. We may want to just refuse moving to a cgroup which
    > > +isn't a descendent of the current one. Or we may want to use
    > > +CAP_MAC_ADMIN, since we really are trying to lock down root.
    > > +
    > > +CAP_SYS_ADMIN is needed to modify the whitelist or move another
    > > +task to a new cgroup. (Again we'll probably want to change that).
    > > +
    > > +A cgroup may not be granted more permissions than the cgroup's
    > > +parent has.
    > > --
    >
    > ---
    > ~Randy


    From c5a7bd6599ebe47b8711ba66b1c41a81935a12af Mon Sep 17 00:00:00 2001
    From: Serge E. Hallyn <serue@us.ibm.com>
    Date: Thu, 27 Mar 2008 08:11:10 -0700
    Subject: [PATCH 1/1] cgroups: devices: add Documentation/ file

    Fill a Documentation/controllers/devices.txt file with a
    modified text from the patch description.

    Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
    ---
    Documentation/controllers/devices.txt | 48 +++++++++++++++++++++++++++++++++
    1 files changed, 48 insertions(+), 0 deletions(-)
    create mode 100644 Documentation/controllers/devices.txt

    diff --git a/Documentation/controllers/devices.txt b/Documentation/controllers/devices.txt
    new file mode 100644
    index 0000000..a157f53
    --- /dev/null
    +++ b/Documentation/controllers/devices.txt
    @@ -0,0 +1,48 @@
    +Device Whitelist Controller
    +
    +1. Description:
    +
    +Implement a cgroup to track and enforce open and mknod restrictions
    +on device files. A device cgroup associates a device access
    +whitelist with each cgroup. A whitelist entry has 4 fields.
    +'type' is a (all), c (char), or b (block). 'all' means it applies
    +to all types and all major and minor numbers. Major and minor are
    +either an integer or * for all. Access is a composition of r
    +(read), w (write), and m (mknod).
    +
    +The root device cgroup starts with rwm to 'all'. A child device
    +cgroup gets a copy of the parent. Administrators can then remove
    +devices from the whitelist or add new entries. A child cgroup can
    +never receive a device access which is denied its parent. However
    +when a device access is removed from a parent it will not also be
    +removed from the child(ren).
    +
    +2. User Interface
    +
    +An entry is added using devices.allow, and removed using
    +devices.deny. For instance
    +
    + echo 'c 1:3 mr' > /cgroups/1/devices.allow
    +
    +allows cgroup 1 to read and mknod the device usually known as
    +/dev/null. Doing
    +
    + echo a > /cgroups/1/devices.deny
    +
    +will remove the default 'a *:* mrw' entry.
    +
    +3. Security
    +
    +Any task can move itself between cgroups. This clearly won't
    +suffice, but we can decide the best way to adequately restrict
    +movement as people get some experience with this. We may just want
    +to require CAP_SYS_ADMIN, which at least is a separate bit from
    +CAP_MKNOD. We may want to just refuse moving to a cgroup which
    +isn't a descendent of the current one. Or we may want to use
    +CAP_MAC_ADMIN, since we really are trying to lock down root.
    +
    +CAP_SYS_ADMIN is needed to modify the whitelist or move another
    +task to a new cgroup. (Again we'll probably want to change that).
    +
    +A cgroup may not be granted more permissions than the cgroup's
    +parent has.
    --
    1.5.1


    \
     
     \ /
      Last update: 2008-03-27 18:39    [W:0.037 / U:30.232 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site