[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080313131818.GA9771@sergelap.austin.ibm.com>
Date: Thu, 13 Mar 2008 08:18:18 -0500
From: "Serge E. Hallyn" <serue@...ibm.com>
To: James Morris <jmorris@...ei.org>
Cc: "Serge E. Hallyn" <serue@...ibm.com>,
lkml <linux-kernel@...r.kernel.org>,
linux-security-module@...r.kernel.org, Greg KH <greg@...ah.com>,
Stephen Smalley <sds@...ch.ncsc.mil>,
Casey Schaufler <casey@...aufler-ca.com>,
Pavel Emelianov <xemul@...nvz.org>
Subject: Re: [RFC] cgroups: implement device whitelist lsm (v2)
Quoting James Morris (jmorris@...ei.org):
> On Wed, 12 Mar 2008, Serge E. Hallyn wrote:
>
> > +#ifdef CONFIG_SECURITY
> > +static struct security_operations devcgroup_security_ops = {
> > + .inode_mknod = devcgroup_inode_mknod,
> > + .inode_permission = devcgroup_inode_permission,
> > +
> > + .ptrace = cap_ptrace,
> > + .capget = cap_capget,
> > + .capset_check = cap_capset_check,
> > + .capset_set = cap_capset_set,
> > + .capable = cap_capable,
> > + .settime = cap_settime,
> > + .netlink_send = cap_netlink_send,
> > + .netlink_recv = cap_netlink_recv,
> > +
> > + .bprm_apply_creds = cap_bprm_apply_creds,
> > + .bprm_set_security = cap_bprm_set_security,
> > + .bprm_secureexec = cap_bprm_secureexec,
> > +
> > + .inode_setxattr = cap_inode_setxattr,
> > + .inode_removexattr = cap_inode_removexattr,
> > + .inode_need_killpriv = cap_inode_need_killpriv,
> > + .inode_killpriv = cap_inode_killpriv,
> > +
> > + .task_kill = cap_task_kill,
> > + .task_setscheduler = cap_task_setscheduler,
> > + .task_setioprio = cap_task_setioprio,
> > + .task_setnice = cap_task_setnice,
> > + .task_post_setuid = cap_task_post_setuid,
> > + .task_prctl = cap_task_prctl,
> > + .task_reparent_to_init = cap_task_reparent_to_init,
> > +
> > + .syslog = cap_syslog,
> > +
> > + .vm_enough_memory = cap_vm_enough_memory,
> > +};
>
> For lower overall complexity, why not just extend the capability LSM to
> include the devcgroup_ perms if CONFIG_CGROUP_DEV ?
That does make for a simpler implementation at this point, however if
any other such LSMs come along (as Casey seemed to think they would) the
end result could end up being horrible spaghetti code of dependencies
and interrelated configs.
But OTOH we went years with no such changes, so that's probably not a
particularly practical concern unless someone can cite specific upcoming
examples. So if noone objects I'll try that approach.
thanks,
-serge
--
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/
Powered by blists - more mailing lists