public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Emelyanov <xemul@openvz.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: Greg KH <greg@kroah.com>, "Serge E. Hallyn" <serue@us.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Paul Menage <menage@google.com>,
	Sukadev Bhattiprolu <sukadev@us.ibm.com>
Subject: Re: [PATCH 0/9] Devices accessibility control group (v4)
Date: Fri, 07 Mar 2008 11:54:46 +0300	[thread overview]
Message-ID: <47D102D6.8070702@openvz.org> (raw)
In-Reply-To: <20080307084245.GA5004@ucw.cz>

Pavel Machek wrote:
> On Thu 2008-03-06 11:36:22, Pavel Emelyanov wrote:
>> Greg KH wrote:
>>> 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.
> 
> And you may still take out mknod capability...

Sure we can. In that case we can pre-create only alowed devices for a container
and be happy, but this is not a flexible way of doing things. The main problem is
that udev will stop working in such a container. Patching one is not an option
either, for the reasons I have described before.

Many virtualization functionality we're submitting can be achieved via proper
userpace modifications, but we want to be able to run old software (from old
and even historic distributions) inside containers, so we have to make this
at the kernel level.

Thanks,
Pavel

      reply	other threads:[~2008-03-07  9:07 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-05 17:23 [PATCH 0/9] Devices accessibility control group (v4) Pavel Emelyanov
2008-03-05 17:25 ` [PATCH 1/9] Avoid magic constants in drivers/base/map.c Pavel Emelyanov
2008-03-05 17:28 ` [PATCH 2/9] Cleanup the get_gendisk() a bit Pavel Emelyanov
2008-03-05 17:32 ` [PATCH 3/9] Add a mode on the struct probe Pavel Emelyanov
2008-03-05 17:34 ` [PATCH 4/9] Make kobj_lookup() return the mapping's permissions Pavel Emelyanov
2008-03-05 17:37 ` [PATCH 5/9] Make use of permissions, returned by kobj_lookup Pavel Emelyanov
2008-03-06  1:13   ` Andrew Morton
2008-03-06  8:48     ` Pavel Emelyanov
2008-03-07  9:22     ` Pavel Emelyanov
2008-03-07  9:35       ` Andrew Morton
2008-03-07  9:52         ` Pavel Emelyanov
2008-03-07 15:59           ` Greg KH
2008-03-07 16:38             ` Pavel Emelyanov
2008-03-07 17:01               ` Greg KH
2008-03-07 17:08                 ` Al Viro
2008-03-07 17:35                 ` Serge E. Hallyn
2008-03-07 17:57                   ` Casey Schaufler
2008-03-07 18:30                     ` Serge E. Hallyn
2008-03-07 19:46                       ` Stephen Smalley
2008-03-07 20:57                         ` Casey Schaufler
2008-03-07 21:32                           ` Serge E. Hallyn
2008-03-07 18:14                   ` Greg KH
2008-03-07 18:50                     ` Serge E. Hallyn
2008-03-08  6:04                       ` Greg KH
2008-03-08 21:47                         ` Serge E. Hallyn
2008-03-09  3:15                           ` Greg KH
2008-03-10 20:35                             ` Serge E. Hallyn
2008-03-11  9:57                 ` Pavel Emelyanov
2008-03-11 17:36                   ` Greg KH
2008-03-12  8:26                     ` Pavel Emelyanov
2008-03-12 13:09                       ` Serge E. Hallyn
2008-03-12 13:18                         ` Stephen Smalley
2008-03-12 13:27                           ` Stephen Smalley
2008-03-12 14:18                             ` Serge E. Hallyn
2008-03-12 14:15                           ` Serge E. Hallyn
2008-03-12 16:21                           ` Casey Schaufler
2008-03-12 13:36                         ` Pavel Emelyanov
2008-03-05 17:40 ` [PATCH 6/9] Extend the drivers/base/map.c functionality Pavel Emelyanov
2008-03-05 17:43 ` [PATCH 7/9] Provide functions to manipulate char device mappings Pavel Emelyanov
2008-03-05 17:46 ` [PATCH 8/9] Provide functions to manipulate block " Pavel Emelyanov
2008-03-05 17:47 ` [PATCH 9/9] Devices accessibility control group itself Pavel Emelyanov
2008-03-06  2:02   ` Greg KH
2008-03-06  1:55 ` [PATCH 0/9] Devices accessibility control group (v4) Greg KH
2008-03-06  3:15   ` Serge E. Hallyn
2008-03-06  4:34     ` Greg KH
2008-03-06  8:36       ` Pavel Emelyanov
2008-03-07  4:58         ` Greg KH
2008-03-07  8:42         ` Pavel Machek
2008-03-07  8:54           ` Pavel Emelyanov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47D102D6.8070702@openvz.org \
    --to=xemul@openvz.org \
    --cc=akpm@linux-foundation.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=menage@google.com \
    --cc=pavel@ucw.cz \
    --cc=serue@us.ibm.com \
    --cc=sukadev@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox