[RFC] cgroups: implement device whitelist lsm (v2) - Kernel

This is a discussion on [RFC] cgroups: implement device whitelist lsm (v2) - Kernel ; On Fri, Mar 14, 2008 at 6:58 AM, Serge E. Hallyn wrote: > James and Stephen agree with your LSM qualms. I suppose we could add > cgroups next to the lsm hooks. I suspect Paul Menage would complain > ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 31 of 31

Thread: [RFC] cgroups: implement device whitelist lsm (v2)

  1. Re: [RFC] cgroups: implement device whitelist lsm (v2)

    On Fri, Mar 14, 2008 at 6:58 AM, Serge E. Hallyn wrote:
    > James and Stephen agree with your LSM qualms. I suppose we could add
    > cgroups next to the lsm hooks. I suspect Paul Menage would complain
    > about that (Paul?),


    Depends on what you mean by "add cgroups to the LSM hooks". Could you
    expand on that?

    Paul
    --
    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/

  2. Re: [RFC] cgroups: implement device whitelist lsm (v2)

    Quoting Pavel Emelyanov (xemul@openvz.org):
    > Serge E. Hallyn wrote:
    > > Quoting Pavel Emelyanov (xemul@openvz.org):
    > >> Serge E. Hallyn wrote:
    > >>> Quoting James Morris (jmorris@namei.org):
    > >>>> On Thu, 13 Mar 2008, Serge E. Hallyn wrote:
    > >>>>
    > >>>>> Quoting James Morris (jmorris@namei.org):
    > >>>>>> On Thu, 13 Mar 2008, Serge E. Hallyn wrote:
    > >>>>>>
    > >>>>>>> True, but while this change simplifies the code a bit, the semantics
    > >>>>>>> seem more muddled - devcg will be enforcing when CONFIG_CGROUP_DEV=y
    > >>>>>>> and:
    > >>>>>>>
    > >>>>>>> SECURITY=n or
    > >>>>>>> rootplug is enabled
    > >>>>>>> capabilities is enabled
    > >>>>>>> smack is enabled
    > >>>>>>> selinux+capabilities is enabled
    > >>>>>> Well, this is how real systems are going to be deployed.
    > >>>>> Sorry, do you mean with capabilities?
    > >>>> Yes.
    > >>>>
    > >>>> All Fedora, RHEL, CentOS etc. ship with SELinux+capabilities. I can't
    > >>>> imagine not enabling them on other kernels.
    > >>>>
    > >>>>>> It becomes confusing, IMHO, if you have to change which secondary LSM you
    > >>>>>> stack with SELinux to enable a cgroup feature.
    > >>>>> So you're saying selinux without capabilities should still be able to
    > >>>>> use dev_cgroup? (Just making sure I understand right)
    > >>>> Nope, SELinux always stacks with capabilities, so havng the cgroup hooks
    > >>>> in capabilities makes sense (rather than having us change the secondary
    > >>>> stacking LSM just to enable a feature).
    > >>> Oh, ok.
    > >>>
    > >>> Will let the patch stand until Pavel and Greg comment then.
    > >> Well, I saw your previous patch, that was implemented as just another
    > >> LSM module and I liked it except for the LSM dependency.

    > >
    > > James and Stephen agree with your LSM qualms. I suppose we could add

    >
    > Thanks!
    >
    > > cgroups next to the lsm hooks. I suspect Paul Menage would complain
    > > about that (Paul?), and I do think it's silly as they are security
    > > questions, not group tracking questions, but if it's what people want
    > > I can send out a new patch next week.

    >
    > The way I see this is: cgroups provide a common way to group tasks
    > and an API for general configuration - that's the controller "face",
    > and it's up to the controller to decide where he turns his "back",
    > IOW where the hooks are placed. For the memory controller - they are
    > injected directly into the mm code. For this controller, I think it
    > would be OK to use LSM or about-LSM hooks.
    >
    > >> Since this version can happily work w/o LSM, I like it too

    > >
    > > In an earlier version I asked whether you had any experience with usual
    > > # rules per container. Do you have an idea? Right now the whitelist is
    > > a straight list we search through linearly. If # rules is generally
    > > tiny then I'm inclined to keep it that way...

    >
    > The # of rules usually has a linear dependency on the number of containers
    > (each of then has to have an access to /dev/null,zero,random at least), so
    > having 100 containers we will have to scan through a 300-entries list.


    Oh no, the rules are stored per-container, so it sounds like you're
    saying 3 entries per container?

    > I'd
    > vote for a hash table or a radix/binary/rb tree for that. Or any other way
    > for non-linear search you can provide


    I'm fine with that, but not for 3 rules

    -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/

  3. Re: [RFC] cgroups: implement device whitelist lsm (v2)

    Quoting Paul Menage (menage@google.com):
    > On Fri, Mar 14, 2008 at 7:05 AM, Serge E. Hallyn wrote:
    > > > > A task may only be moved to another devcgroup if it is moving to
    > > > > a direct descendent of its current devcgroup.
    > > >
    > > > What's the rationale for that?

    > >
    > > To prevent it escaping to laxer device permissions, which of course only
    > > makes sense if we do what you recommend above
    > >

    >
    > That makes it impossible for a root process to enter a child cgroup,
    > do something, and then go back to its own cgroup.


    Yes, but it can fire off a child in the child cgroup to do something,
    and go on on its own cgroup when the child finishes.

    > Why aren't the
    > existing cgroup security semantics sufficient?


    Because the point of this is to provide some restrictions to otherwise
    privileged users, and cgroups only provides dac-based permissions.

    But that doesn't mean that I'm not doing too much. I could just add a
    CAP_SYS_ADMIN or CAP_CONT_OVERRIDE+CAP_SYS_ADMIN check, and not restrict
    which cgroups a task can move to. Does that sound good?

    -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/

  4. Re: [RFC] cgroups: implement device whitelist lsm (v2)

    Quoting Paul Menage (menage@google.com):
    > On Fri, Mar 14, 2008 at 6:58 AM, Serge E. Hallyn wrote:
    > > James and Stephen agree with your LSM qualms. I suppose we could add
    > > cgroups next to the lsm hooks. I suspect Paul Menage would complain
    > > about that (Paul?),

    >
    > Depends on what you mean by "add cgroups to the LSM hooks". Could you
    > expand on that?


    cgroup hooks next to the lsm hooks. So in fs/namei.c where there are
    security_inode_permission() hooks, there would also be
    cgroup_inode_permission() hooks to let the devices cgroup mediate the
    access. Well, in permission(), probably not in exec_permission_lite()
    since that's probalby not a device access

    So far it looks like everyone likes that, so as long as you don't nack I
    guess that'll be the way to go.

    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/

  5. Re: [RFC] cgroups: implement device whitelist lsm (v2)

    [snip]

    >> The # of rules usually has a linear dependency on the number of containers
    >> (each of then has to have an access to /dev/null,zero,random at least), so
    >> having 100 containers we will have to scan through a 300-entries list.

    >
    > Oh no, the rules are stored per-container, so it sounds like you're
    > saying 3 entries per container?


    Oops I've missed that part

    >> I'd
    >> vote for a hash table or a radix/binary/rb tree for that. Or any other way
    >> for non-linear search you can provide

    >
    > I'm fine with that, but not for 3 rules


    So am I Anyway - if someday this will grow up to tens of entries turning
    it into a more scalable lookup would be easy.

    > -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/

  6. Re: [RFC] cgroups: implement device whitelist lsm (v2)

    [snip]

    >> My main question was why was that file in the kernel/ directory?
    >> Shouldn't that also be in the security/ directory?

    >
    > I'm using cgroups to track the tasks which should have their device
    > permissions restricted. Right now cgroups are all under kernel/.


    No. Memory cgroup is under mm/

    >> And to be honest, I didn't really look at it at all other than the
    >> diffstat to make sure you weren't messing with the kobj_map stuff
    >> anymore
    >>
    >> thanks,
    >>
    >> greg k-h
    >> --
    >> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
    >> the body of a message to majordomo@vger.kernel.org
    >> More majordomo info at http://vger.kernel.org/majordomo-info.html

    >


    --
    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/

  7. Re: [RFC] cgroups: implement device whitelist lsm (v2)

    Quoting Pavel Emelyanov (xemul@openvz.org):
    > [snip]
    >
    > >> My main question was why was that file in the kernel/ directory?
    > >> Shouldn't that also be in the security/ directory?

    > >
    > > I'm using cgroups to track the tasks which should have their device
    > > permissions restricted. Right now cgroups are all under kernel/.

    >
    > No. Memory cgroup is under mm/


    Ah.

    Guess it could all go under security/. Should it still go there even if
    we make it not use lsm?

    > >> And to be honest, I didn't really look at it at all other than the
    > >> diffstat to make sure you weren't messing with the kobj_map stuff
    > >> anymore
    > >>
    > >> thanks,
    > >>
    > >> greg k-h
    > >> --
    > >> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
    > >> the body of a message to majordomo@vger.kernel.org
    > >> More majordomo info at http://vger.kernel.org/majordomo-info.html

    > >

    --
    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/

  8. Re: [RFC] cgroups: implement device whitelist lsm (v2)

    Serge E. Hallyn wrote:
    > Quoting Pavel Emelyanov (xemul@openvz.org):
    >> [snip]
    >>
    >>>> My main question was why was that file in the kernel/ directory?
    >>>> Shouldn't that also be in the security/ directory?
    >>> I'm using cgroups to track the tasks which should have their device
    >>> permissions restricted. Right now cgroups are all under kernel/.

    >> No. Memory cgroup is under mm/

    >
    > Ah.
    >
    > Guess it could all go under security/. Should it still go there even if
    > we make it not use lsm?


    Sure it can - security/ is in obj-y regardless of whether the
    SECURITY itself is on or off

    >>>> And to be honest, I didn't really look at it at all other than the
    >>>> diffstat to make sure you weren't messing with the kobj_map stuff
    >>>> anymore
    >>>>
    >>>> thanks,
    >>>>
    >>>> greg k-h
    >>>> --
    >>>> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
    >>>> the body of a message to majordomo@vger.kernel.org
    >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html

    >


    --
    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/

  9. Re: [RFC] cgroups: implement device whitelist lsm (v2)


    On Fri, 2008-03-14 at 10:45 -0500, Serge E. Hallyn wrote:
    > Quoting Pavel Emelyanov (xemul@openvz.org):
    > > [snip]
    > >
    > > >> My main question was why was that file in the kernel/ directory?
    > > >> Shouldn't that also be in the security/ directory?
    > > >
    > > > I'm using cgroups to track the tasks which should have their device
    > > > permissions restricted. Right now cgroups are all under kernel/.

    > >
    > > No. Memory cgroup is under mm/

    >
    > Ah.
    >
    > Guess it could all go under security/. Should it still go there even if
    > we make it not use lsm?


    There is the precedent of the security/keys directory (security-related,
    but not using LSM - aside from calling LSM hooks for access checks and
    labeling of keys).

    --
    Stephen Smalley
    National Security Agency

    --
    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/

  10. Re: [RFC] cgroups: implement device whitelist lsm (v2)

    On Fri, Mar 14, 2008 at 10:35 PM, Serge E. Hallyn wrote:
    >
    > > Why aren't the
    > > existing cgroup security semantics sufficient?

    >
    > Because the point of this is to provide some restrictions to otherwise
    > privileged users, and cgroups only provides dac-based permissions.
    >
    > But that doesn't mean that I'm not doing too much. I could just add a
    > CAP_SYS_ADMIN or CAP_CONT_OVERRIDE+CAP_SYS_ADMIN check, and not restrict
    > which cgroups a task can move to. Does that sound good?


    Sounds reasonable.

    Paul
    --
    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/

  11. Re: [RFC] cgroups: implement device whitelist lsm (v2)

    On Fri, Mar 14, 2008 at 10:42 PM, Serge E. Hallyn wrote:
    >
    > cgroup hooks next to the lsm hooks. So in fs/namei.c where there are
    > security_inode_permission() hooks, there would also be
    > cgroup_inode_permission() hooks to let the devices cgroup mediate the
    > access. Well, in permission(), probably not in exec_permission_lite()
    > since that's probalby not a device access


    This would just be a device cgroup-specific thing, right? Nothing to
    do with the generic framework? If so, then that sounds fine (to me, at
    least).

    Paul
    --
    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/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2