From: russell@coker.com.au (Russell Coker) Date: Fri, 4 Mar 2011 21:57:11 +1100 Subject: [refpolicy] Further questions about configuring contexts differently for variant classes In-Reply-To: References: <4D667EBA.3060205@tresys.com> Message-ID: <201103042157.11995.russell@coker.com.au> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Fri, 4 Mar 2011, HarryCiao wrote: > > It certainly would be nice to have all objects get the role of their > > creator so we can bring role-based policy separations back using RBAC > > features and not rely on 1:1 user:role mapping + UBAC. > > 4. It seems that we used to have RBAC, then why we have to have dropped it? > 5. Does the "1:1 user:role mapping" mean the mapping from linux user to > selinux user, and the mapping from selinux user to the roles that he/she > could assume? 6. Any discussion email thread about how UBAC works and why > we would want "1:1 user:role mapping + UBAC"? The RBAC we used to have was based on the role for a process context being used to determine the set of domains used by processes that it may launch, and the domains used by those processes determined the types of files. So user_r process role gets user_t as the main domain which can write to user_home_t. staff_r process role gets staff_t as the domain and can write to staff_home_t. There were also domains like user_mozilla_t and staff_mozilla_t which do what you probably expect. But all files created by all of those processes had the role object_r. During the time that I've been working on SE Linux (since mid 2001) there has never been a role used for real files (as opposed to labels on /proc entries etc) other than object_r. The idea of giving objects the role of their creator relies on kernel code which AFAIK has never been written in the history of SE Linux (unless it happened to be in the very early versions). -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/