Greg KH wrote:
quoted text
> On Wed, Mar 05, 2008 at 09:15:25PM -0600, Serge E. Hallyn wrote:
>> Quoting Greg KH (greg@kroah.com):
>>> On Wed, Mar 05, 2008 at 08:23:35PM +0300, Pavel Emelyanov wrote:
>>>> Changes from v3:
>>>> * Ported on 2.6.25-rc3-mm1;
>>>> * Re-splitted into smaller pieces;
>>>> * Added more comments to tricky places.
>>>>
>>>> This controller allows to tune the devices accessibility by tasks,
>>>> i.e. grant full access for /dev/null, /dev/zero etc, grant read-only
>>>> access to IDE devices and completely hide SCSI disks.
>>>  From within the kernel itself?  The kernel should not be keeping track
>>> of the mode of devices, that's what the filesystem holding /dev is for.
>>> Those modes change all the time depending on the device plugged in, and
>>> the user using the "console".  Why should the kernel need to worry about
>>> any of this?
>> These are distinct from the permissions on device files.  No matter what
>> the permissions on the device files, a task in a devcg cgroup which
>> isn't allowed write to chardev 4:64 will not be able to write to
>> /dev/ttyS0.
> 
> Then why not do that from userspace with a different /dev, or with a
> LSM?

Different dev is not suitable, since task may still call mknod to
create device it needs and use it. This is not about comfortable
use, this is about security.

LSM approach was proposed, but that required some API to configure
the permissions. This API done via control groups, so there were no
difference between this approach and that. Except for this one doesn't
create one more level of filtering at the top of kobject lookup and
thus is simpler and faster.

quoted text
>> The purpose is to prevent a root task from granting itself access to
>> certain devices.  Without this, the only option currently is to take
>> CAP_MKNOD out of the capability bounding set for a container and make
>> sure that /dev is set up right (and enforce nodev for mounts).  In
>> itself that doesn't sound so bad and it was my preference at first,
> 
> that would be my preference as well.

That approach relies on a proper user space setup inside a container, 
but this creates security holes, since container user may ignore all
these "requirements".

quoted text
>> but the argument is that things like udev should be able to run in a
>> container, and will object about not being able to create devices.
> 
> No reason you can't modify udev to do something like this.  At the

Sure we _can_ modify udev, but the problem is that users of virtualisation
solutions often (very often) use old software (e.g. set up some out-dated
distribution inside a container), so trick with modified udev simply won't
work in many cases.

quoted text
> worse, just disable udev warning messages, that is pretty trivial to do.
> 
> This really makes it seem like this kernel change is not needed at all.
> 
>>>> Tasks still can call mknod to create device files, regardless of
>>>> whether the particular device is visible or accessible, but they
>>>> may not be able to open it later.
>>>>
>>>> This one hides under CONFIG_CGROUP_DEVS option.
>>>>
>>>> To play with it - run a standard procedure:
>>>>
>>>>  # mount -t container none /cont/devs -o devices
>>>>  # mkdir /cont/devs/0
>>>>  # echo -n $$ > /cont/devs/0/tasks
>>> What is /cont/ for?
>> cgroups used to be called containers, so 'cont' is presumably shorthand
>> for container.
>>
>>>> and tune device permissions.
>>> How is this done?
>>>
>>> Why would the kernel care about this stuff?
>> Because there is no way for userspace to restrict a root process in a
>> container from accessing whatever devices it wants.
> 
> LSM does this quite well today, why reinvent the wheel and put wierd
> hooks in other parts of the kernel that do not need them at all?

These are not hooks actually. I just made kobj_map-s per-group.

quoted text
> thanks,
> 
> greg k-h
> 

Thanks,
Pavel
--
unsubscribe notice
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/