On Wed, 2008-04-30 at 10:05 -0400, Stephen Smalley wrote: > On Wed, 2008-04-30 at 09:48 -0400, Christopher J. PeBenito wrote: > > On Tue, 2008-04-29 at 15:48 -0400, Stephen Smalley wrote: > > > On Tue, 2008-04-29 at 15:34 -0400, Christopher J. PeBenito wrote: > > > > On Tue, 2008-04-29 at 14:56 -0400, Stephen Smalley wrote: > > > > > On Tue, 2008-04-29 at 11:54 -0400, Christopher J. PeBenito wrote: > > > > > > Next we will be doing an experiment attempting to use the SELinux RBAC > > > > > > functionality to separate users instead of SELinux TE. What this means > > > > > > is that the role field will start being used more substantially than it > > > > > > currently is. In a nutshell, this means that all user objects will have > > > > > > the user's role rather than object_r. Then the separate types will be > > > > > > collapsed into one type where possible. This will result in per-role > > > > > > types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too > > > > > > (mozilla_t). > > [...] > > > > > > Unfortunately this necessitates some kernel and userspace changes: > > > > [...] > > > > > > Login programs and newrole will have to be changed to set the role on > > > > > > the terminal. > > > > > > > > > > Not if we get the security_compute_sid logic right and introduce > > > > > role_change rules analogous to the type_change rules. Then the existing > > > > > security_compute_relabel() calls by login programs and newrole will > > > > > return the desired context. > > > > > > > > I just assumed that userspace changes would be preferred since there > > > > doesn't necessarily have to be any logic in figuring out what role to > > > > set on the object, the app would just set whatever role was logging in > > > > (or the role being changed to, in the case of newrole). > > > > > > So under that approach, would userspace cease using > > > security_compute_relabel() altogether? As its only real use today is to > > > obtain a derived type, and you are eliminating those. > > > > > > I suppose that would be simpler. > > > > I didn't think of removing security_compute_relabel(). I figured it > > would stick around for compatibility. > > I think we already have to update the userland and policy in lock-step > if we are going to directly change the login programs and newrole to > directly set roles on the tty, as that will otherwise break. Or do you > intend to provide some way for userspace to detect that the new role > support is present in policy (and in the kernel, for that matter)? > > That btw might be an advantage to hiding the role determination behind > security_compute_relabel(), such that userspace doesn't have to change > at all and can seamlessly handle the transition from the old approach to > the new one. A good point. We could probably add in the user_transition support in at the same time as role_change and role_transition w/object classes. > Another issue btw is that when we start using roles on objects, then the > role-type relation has to be expanded to encompass all of the types that > might be assigned to files created by processes in that role rather than > only dealing with domains. Right. My current thinking is that it would be types that were previously per-role, since outside of home directories and /tmp directories, everything else would be object_r. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
