-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Smalley wrote: > On Wed, 2008-03-26 at 09:46 +0100, Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> 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: >>>>> >>>>>> Stephen Smalley wrote: >>>>>> >>>>>>> On Mon, 2008-03-24 at 13:40 -0400, Joshua Brindle wrote: >>>>>>> >>>>>>> >>>>>>>> This implements user_transition in the toolchain. It should help on >>>>>>>> distro's like Ubuntu that can't use run_init due to the user not knowing >>>>>>>> the root password. It also seems like a more eloquent way to handle >>>>>>>> service restarts than assigning system_r to user accounts and having the >>>>>>>> daemons run as someuser:system_r:foo_t. >>>>>>>> >>>>>>>> >>>>>>> Yes, that's something that has been wanted in Fedora for quite some >>>>>>> time. >>>>>>> >>>>>>> The real issue with run_init isn't the re-authentication stage, as that >>>>>>> can always be disabled via pam config (and was just a weak form of >>>>>>> confirming user intent, not an authorization mechanism), but rather the >>>>>>> difficulty in transparently interposing it into all situations where >>>>>>> services get started/re-started. Only Gentoo seemed to have a good >>>>>>> story there. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> This has some issues in policy due to users not always being known in >>>>>>>> the policy (eg., semanage users). I hope Chris or Dan will be able to >>>>>>>> give some suggestions there. >>>>>>>> >>>>>>>> >>>>>>> I'm not sure why anyone needs to add users to policy via semanage users >>>>>>> given the base set of generic users and the ability to map Linux users >>>>>>> to them via seusers aka semanage login. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> The kernel patch (forthcoming after this is accepted) so far only >>>>>>>> implements the transition on process transitions. Later on I plan on >>>>>>>> doing a patch to expand role_transition to object classes (this is a >>>>>>>> change needed for policy rbac support to work). I suspect I'll do the >>>>>>>> same for user at that time. The question here is, do we think its worth >>>>>>>> it to do fine grained transitions like we did for range_trans? (I don't). >>>>>>>> >>>>>>>> >>>>>>> Offhand, I can't see a use for per-class user transitions, if that is >>>>>>> what you mean. >>>>>>> >>>>>>> I don't think per-class role transitions is really the fundamental >>>>>>> obstacle to enabling use of roles on objects - more thought is required >>>>>>> there. What will be fun there is role/type and user/range validation, >>>>>>> which presently gets to ignore everything that has object_r. >>>>>>> >>>>>>> >>>>>> 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. >>> >> I am not sure where this is going, but I believe that separation based >> on role in the home directory is a mistake. It assumes that the home >> directory will always be used by the same user with the same role. And >> will not work when you have a network file system that supports labels. >> >> In Red Hat I can login to people.redhat.com people.fedoraproject.com >> which I should use the guest_r. While logging into my laptop I would be >> unconfined_t and on test machines I might get staff_r or user_r. All of >> them would use the same homedirectory. So how would this work in this >> environment? > > That's an interesting question, and I know that in some operating > systems, roles are actually separate user accounts altogether. > > However, the mechanism being described here doesn't prevent you from > continuing to use a generic role (object_r or otherwise) on all files; > it just allows for people who want to apply distinct roles on files to > do so. > Well I guess I will be the first one to state that if this breaks the situation I stated above, I am not interested. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfr+LYACgkQrlYvE4MpobOpRQCfSma66Z5JG6CV1bfAbd2xMJf8 MA4AoJbRYBB6coyQnnvIdH8kw0eE3Erq =xtQ8 -----END PGP SIGNATURE----- -- 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.
