From: Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
To: Aristeu Rozanski <aris-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
Serge Hallyn
<serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Subject: Re: [PATCH] device_cgroup: do not use rule acceptance function to validate access
Date: Tue, 15 Apr 2014 10:57:52 -0500 [thread overview]
Message-ID: <20140415155752.GC5184@sergelap> (raw)
In-Reply-To: <20140414144736.GS29214-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Quoting Aristeu Rozanski (aris-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
> may_access() is currently used to validate both new exceptions from children
> groups and to check if an access is allowed. This not only makes it hard to
> understand and maintain, but it's also incorrect.
Heh, well one might argue that may_access() was more approriate at
__devcgroup_check_permission(), should remain simpler, and parent_has_perm()
should be the wrapper doing the extra bits. That would be easier to
read imo.
In what you have here, you end up duplicating the
list_for_each_entry_rcu. I think you should at least have a common
fn for that.
I don't want to sound pedantic, but since the point of this patch is
that simplicity/ease-of-reading would have prevented the bug ... :)
> It currently allows one to:
>
> # mkdir new_group
> # cd new_group
> # echo $$ >tasks
> # echo "c 1:3 w" >devices.deny
> # echo >/dev/null
> # echo $?
> 0
>
> This patch implements the device file access check separately and fixes
> the issue.
>
> This is broken since c39a2a3018f8065cb5ea38b0314c1bbedb2cfa0d
>
> After review, this should be considered for stable series.
Definately.
> Signed-off-by: Aristeu Rozanski <aris-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
I *think* it's ok, and I appreciate you finding and fixing the bug, but
I don't think the result is as easy to read as it could be, so if you
don't mind I'd like to wait for a new version to ack. If you disagree
with me, let me know and I'll re-read and (presumably) ack.
> diff --git a/security/device_cgroup.c b/security/device_cgroup.c
> index 8365909..d390d21 100644
> --- a/security/device_cgroup.c
> +++ b/security/device_cgroup.c
> @@ -704,21 +704,35 @@ static int __devcgroup_check_permission(short type, u32 major, u32 minor,
> short access)
> {
> struct dev_cgroup *dev_cgroup;
> - struct dev_exception_item ex;
> - int rc;
> -
> - memset(&ex, 0, sizeof(ex));
> - ex.type = type;
> - ex.major = major;
> - ex.minor = minor;
> - ex.access = access;
> + struct dev_exception_item *ex;
> + enum devcg_behavior behavior;
> + bool match = false;
>
> rcu_read_lock();
> dev_cgroup = task_devcgroup(current);
> - rc = may_access(dev_cgroup, &ex, dev_cgroup->behavior);
> + behavior = dev_cgroup->behavior;
> + list_for_each_entry_rcu(ex, &dev_cgroup->exceptions, list) {
> + if (type == DEV_BLOCK && !(ex->type & DEV_BLOCK))
> + continue;
> + if (type == DEV_CHAR && !(ex->type & DEV_CHAR))
> + continue;
> + if (ex->major != ~0 && major != ex->major)
> + continue;
> + if (ex->minor != ~0 && minor != ex->minor)
> + continue;
> + if (access & (~ex->access))
> + continue;
> + match = true;
> + break;
> + }
> rcu_read_unlock();
>
> - if (!rc)
> + if (behavior == DEVCG_DEFAULT_ALLOW && match)
> + /* access matches a rule to disallow access */
> + return -EPERM;
> +
> + if (behavior == DEVCG_DEFAULT_DENY && !match)
> + /* no exceptions found, default action is to deny access */
> return -EPERM;
>
> return 0;
next prev parent reply other threads:[~2014-04-15 15:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-14 14:47 [PATCH] device_cgroup: do not use rule acceptance function to validate access Aristeu Rozanski
[not found] ` <20140414144736.GS29214-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-04-14 18:03 ` Tejun Heo
[not found] ` <20140414180323.GC15249-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2014-04-14 18:16 ` Aristeu Rozanski
[not found] ` <20140414181611.GU29214-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-04-14 19:07 ` Tejun Heo
2014-04-15 15:57 ` Serge Hallyn [this message]
2014-04-15 16:53 ` Aristeu Rozanski
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=20140415155752.GC5184@sergelap \
--to=serge.hallyn-gewih/nmzzlqt0dzr+alfa@public.gmane.org \
--cc=aris-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lizefan-hv44wF8Li93QT0dZR+AlfA@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.