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/

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/

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/

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

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

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/

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/

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/

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/

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/