On Tue, 2008-03-25 at 09:52 -0400, Joshua Brindle wrote: > Christopher J. PeBenito wrote: > > On Tue, 2008-03-25 at 08:08 -0400, Stephen Smalley wrote: > > > >> On Tue, 2008-03-25 at 07:04 -0400, Joshua Brindle wrote: > >> > >>> Stephen Smalley wrote: > >>> > >>>> On Mon, 2008-03-24 at 16:27 -0400, Joshua Brindle wrote: > >>>> > > > > > >>>>> Ah, another thing. While going through the policyrep implementation the > >>>>> question of object_r came up. My thought is to start adding object_r > >>>>> magic into the toolchain (adding all types, etc) and eventually purge > >>>>> object_r from the kernel. at least one magic instance of object_r will > >>>>> be removed by object role_transitions, the others are really short > >>>>> circuits in the security server that can be removed after sufficient > >>>>> support is in the toolchain. What are your thoughts on that (for future > >>>>> reference)? > >>>>> > >>>>> > >>>> Well, the interesting question is what should the default role be in the > >>>> new context in security_compute_sid, if not object_r. Even aside from > >>>> the support for per-class role transitions. User defaults to the source > >>>> context, type defaults to the related object context, and MLS range > >>>> defaults to the low level of the source context. Role could be the > >>>> subject's role or the related object's role. > >>>> > >>>> > >>>> > >>> Good question. My original assumption was that we'd use the related > >>> object role. That would require that home directories be correctly > >>> labeled with the role of the user. If we start using the source role > >>> then things will quickly change from object_r to system_r, so maybe the > >>> policy should do that anyway. Chris, any opinions on this? > >>> > >> Yes, related object role would likely cause the least breakage. It > >> would preserve the existing default for existing filesystems (as they > >> already have object_r in the directory contexts), while allowing us to > >> switch over to the user's role for home directories upon a relabel or > >> new filesystem. Source role might create more conflicts, as we enforce > >> the role/type relationship for contexts and there might be a mismatch > >> between the creating process role and the parent directory type. > >> > > > > Using the related object role seems right to me too. > > > > The inconsistency of handling parts of the context is a little troubling > to me, half the context will be coming from the source and half from the > object container. If this doesn't bother anyone else I suppose I'll try > to ignore that OCD'ism of mine but I love it when the models we support > work pretty seamlessly together and this seems like artifacts of them > not doing that. It's a logical consequence of the individual models, which are indeed different. I don't believe we can or want to make them all the same. One thing that has come up previously though is that it would be convenient if we could specify the default inheritance behaviors in the policy configuration itself. -- Stephen Smalley National Security Agency -- 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.
