From: Ondrej Kozina <okozina@redhat.com>
To: dm-devel@redhat.com
Cc: Ondrej Kozina <okozina@redhat.com>,
mgrac@redhat.com, kas@fi.muni.cz, mbroz@redhat.com
Subject: [RFC PATCH v2 0/3] Allow user w/o CAP_SYS_ADMIN to submit ioctl commands into DM
Date: Fri, 25 May 2012 15:22:25 +0200 [thread overview]
Message-ID: <1337952148-20888-1-git-send-email-okozina@redhat.com> (raw)
In-Reply-To: <1335986033-15236-1-git-send-email-okozina@redhat.com>
Hi,
I would like to post new version of my previous RFC with a set of changes for
device-mapper that would enable user w/o CAP_SYS_ADMIN capability to create
and manage his own devices.
Changes in version No. 2:
^^^^^^^^^^^^^^^^^^^^^^^^
(*) No major:minor translation to dentry (inode) in kernel space. Supposing
userspace should resolve that.
(*) Load time parameter to enable security enhancements
(*) Supposing security is enabled, userspace should handle open file descriptors
and kernel checks whether the user is authorised to access the device
linked to the device node.
The rest of message is the same as in original RFC
Simple use cases:
^^^^^^^^^^^^^^^^
(1) Non-root user would be able to create dm-crypt device from USB stick
(assuming the user has permission to access backing device)
(2) You can create pool of storage space for virtual machines. VM managers
would be able to administrate the pool w/o root permissions:
.--------------. .----------------.
|_owner: VM 01_| |__owner: VM 02__|
| |
| |
.---------------------------------.
|____owner: VM manager____________|
Short Overview:
^^^^^^^^^^^^^^
(1) The first checkpoint that decides whether the user has an access right to
submit ioctl cmds into DM driver are actually the attributes on dentry of
/dev/mapper/control (through general perm., ACL, LSM checks).
(2) After the DM_DEV_CREATE ioctl, new block device will receive FSUID and
from the context on behalf of which we entered into kernel
(3) Whenever user asks to manipulate DM device he must pass the test whether
he's the owner of DM device or he has CAP_FOWNER capability.
(4) During the table creation process we check whether the user has right to
READ/WRITE the backing device, according to table mode. For that purpose
I added a new function into target_type interface - dm_security_fn.
With regards
O.
Ondrej Kozina (3):
Adds support for user-submitted ioctl commands
Adds support for security checks in the linear target
Adds support for security checks in the crypt target
drivers/md/Makefile | 2 +-
drivers/md/dm-crypt.c | 18 +++++-
drivers/md/dm-ioctl.c | 141 +++++++++++++++++++++++++++++++++++------
drivers/md/dm-linear.c | 19 +++++-
drivers/md/dm-security.c | 95 +++++++++++++++++++++++++++
drivers/md/dm-sysfs.c | 15 +++++
drivers/md/dm-table.c | 23 +++++++-
drivers/md/dm.c | 87 +++++++++++++++++++++++++
drivers/md/dm.h | 12 ++++
include/linux/device-mapper.h | 5 ++
10 files changed, 393 insertions(+), 24 deletions(-)
create mode 100644 drivers/md/dm-security.c
--
1.7.8.6
next prev parent reply other threads:[~2012-05-25 13:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-02 19:13 [RFC PATCH 0/4] Allow user w/o CAP_SYS_ADMIN to submit ioctl commands into DM okozina
2012-05-02 19:13 ` [RFC PATCH 1/4] Adds support for user-submitted ioctl commands okozina
2012-05-02 19:13 ` [RFC PATCH 2/4] Adds support for the dentry lookup from path or major:minor couple during target security check okozina
2012-05-02 19:13 ` [RFC PATCH 3/4] Adds support for security checks in the linear target okozina
2012-05-02 19:13 ` [RFC PATCH 4/4] Adds support for security checks in the crypt target okozina
2012-05-25 13:22 ` Ondrej Kozina [this message]
2012-05-25 13:22 ` [RFC PATCH v2 1/3] Adds support for user-submitted ioctl commands Ondrej Kozina
2012-05-25 13:22 ` [RFC PATCH v2 2/3] Adds support for security checks in the linear target Ondrej Kozina
2012-05-25 13:22 ` [RFC PATCH v2 3/3] Adds support for security checks in the crypt target Ondrej Kozina
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=1337952148-20888-1-git-send-email-okozina@redhat.com \
--to=okozina@redhat.com \
--cc=dm-devel@redhat.com \
--cc=kas@fi.muni.cz \
--cc=mbroz@redhat.com \
--cc=mgrac@redhat.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;
as well as URLs for NNTP newsgroup(s).