From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Serge Hallyn
<serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
Aristeu Rozanski <aris-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Subject: Re: Why does devices cgroup check for CAP_SYS_ADMIN explicitly?
Date: Tue, 06 Nov 2012 08:10:10 -0800 [thread overview]
Message-ID: <87sj8mogpp.fsf@xmission.com> (raw)
In-Reply-To: <20121106154320.GE30069-9pTldWuhBndy/B6EtB590w@public.gmane.org> (Tejun Heo's message of "Tue, 6 Nov 2012 07:43:20 -0800")
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:
> Hey, Eric.
>
> On Tue, Nov 06, 2012 at 07:34:07AM -0800, Eric W. Biederman wrote:
>> Having thought about this a little more I can give a definitive answer.
>>
>> Adding a process to the device control group is equivalent to calling
>> mknod, as it allows that process to open device nodes, or equivalently
>> not open device nodes. Therefore a capable check is absolutely
>> required.
>>
>> Without a capability check it would be possible to remove access to
>> /dev/console for a suid root application keeping it from reporting
>> attempts to hack it for example.
>
> You understand that the whole thing is gated by VFS permission check,
> right? I'm kinda lost what you're talking about.
mknod is gated by the vfs with a capability call.
open does not perform the CAP_MKNOD check.
Since the device cgroup prevents opening of device nodes adding
permission to access a new device node (update_access) is roughly
equivalent to mknod when the device cgroup does not exist.
To preserve the notion that only a privileged user can grant access to
device nodes we need a capability check. Especially since the device
cgroup is designed to limit processes with uid == 0.
Without a capability check a process with CAP_DAC_OVERRIDE can go
shopping for a device control group that happens to have the device it
wants to use.
Similary without a capability check a process with CAP_DAD_OVERRIDE can
add or remove any device node into a device control group.
I don't see how the device control group can limit uid == 0 with the
device control group without making the operations require a capability
you don't give to ever user who has uid == 0.
>> The generic cgroup check in attach_task_by_pid to see if you can move
>> another process into a cgroup needs to be a capability call and not a
>> test for uid == 0.
>>
>> static int attach_task_by_pid(struct cgroup *cgrp, u64 pid, bool threadgroup)
>> {
>> if (pid) {
>> tsk = find_task_by_vpid(pid);
>>
>> /*
>> * even if we're attaching all tasks in the thread group, we
>> * only need to check permissions on one of them.
>> */
>> tcred = __task_cred(tsk);
>> if (!uid_eq(cred->euid, GLOBAL_ROOT_UID) &&
>> ^^^^^^^^^^^^^^^
>> !uid_eq(cred->euid, tcred->uid) &&
>> !uid_eq(cred->euid, tcred->suid)) {
>> rcu_read_unlock();
>> ret = -EACCES;
>> goto out_unlock_cgroup;
>
> This one isn't gated by VFS so we need to add CAP check to this
> function. No?
correct. The check should read something like:
tcred = __task_cred(tsk);
if (!uid_eq(cred->euid, tcred->uid) &&
!uid_eq(cred->euid, tcred->suid) &&
!capable(CAP_SYS_ADMIN)) {
rcu_read_unlock();
ret = -EACCES;
goto out_unlock_cgroup;
Eric
next prev parent reply other threads:[~2012-11-06 16:10 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-06 2:38 Why does devices cgroup check for CAP_SYS_ADMIN explicitly? Tejun Heo
[not found] ` <20121106023845.GI19354-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-11-06 11:58 ` Eric W. Biederman
[not found] ` <877gpzrlir.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-11-06 14:48 ` Tejun Heo
2012-11-06 14:48 ` Tejun Heo
2012-11-06 15:01 ` Serge Hallyn
2012-11-06 15:06 ` Tejun Heo
[not found] ` <20121106150639.GB30069-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-11-06 15:30 ` Serge Hallyn
2012-11-06 15:41 ` Tejun Heo
2012-11-06 15:41 ` Tejun Heo
[not found] ` <20121106154105.GD30069-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-11-06 16:12 ` Aristeu Rozanski
2012-11-06 16:12 ` Aristeu Rozanski
2012-11-06 15:30 ` Serge Hallyn
2012-11-06 15:34 ` Eric W. Biederman
2012-11-06 15:34 ` Eric W. Biederman
[not found] ` <871ug6rbio.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-11-06 15:43 ` Tejun Heo
[not found] ` <20121106154320.GE30069-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-11-06 16:10 ` Eric W. Biederman
2012-11-06 16:10 ` Eric W. Biederman [this message]
[not found] ` <87sj8mogpp.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-11-06 16:52 ` Tejun Heo
[not found] ` <20121106165246.GF30069-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-11-06 17:31 ` Serge Hallyn
2012-11-06 17:31 ` Serge Hallyn
2012-11-06 17:38 ` Tejun Heo
[not found] ` <20121106173823.GK30069-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-11-06 17:41 ` Tejun Heo
[not found] ` <20121106174130.GL30069-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-11-06 18:02 ` Serge Hallyn
2012-11-06 18:08 ` Tejun Heo
2012-11-06 18:08 ` Tejun Heo
2012-11-06 18:02 ` Serge Hallyn
2012-11-06 18:12 ` Serge Hallyn
2012-11-06 18:12 ` Serge Hallyn
2012-11-06 18:16 ` Tejun Heo
[not found] ` <20121106181623.GO30069-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-11-06 18:25 ` Serge Hallyn
2012-11-06 18:16 ` Tejun Heo
2012-11-06 17:38 ` Tejun Heo
2012-11-06 15:45 ` Serge Hallyn
2012-11-06 15:45 ` Serge Hallyn
2012-11-06 15:06 ` Tejun Heo
2012-11-06 15:01 ` Serge Hallyn
-- strict thread matches above, loose matches on Subject: below --
2012-11-06 2:38 Tejun Heo
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=87sj8mogpp.fsf@xmission.com \
--to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
--cc=aris-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.