linux-kernel - Re: [PATCH 0/9] Devices accessibility control group (v4)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47D102D6.8070702@openvz.org>
Date:	Fri, 07 Mar 2008 11:54:46 +0300
From:	Pavel Emelyanov <xemul@...nvz.org>
To:	Pavel Machek <pavel@....cz>
CC:	Greg KH <greg@...ah.com>, "Serge E. Hallyn" <serue@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Paul Menage <menage@...gle.com>,
	Sukadev Bhattiprolu <sukadev@...ibm.com>
Subject: Re: [PATCH 0/9] Devices accessibility control group (v4)

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@...ah.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/