-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christopher J. PeBenito wrote: > On Mon, 2008-02-25 at 15:40 -0500, Joshua Brindle wrote: >> Stephen Smalley wrote: >>> On Mon, 2008-02-25 at 09:53 -0500, Joshua Brindle wrote: >>>> Daniel J Walsh wrote: >>>>> Stephen Smalley wrote: >>>>>> On Fri, 2008-02-15 at 15:17 -0500, Joshua Brindle wrote: >>>>>>> Stephen Smalley wrote: >>>>>>>> Crazy idea: Make "permissive" a special type attribute name, and >>>>>>>> mark types that should be permissive with that attribute via >>>>>>>> typeattribute. Then let the usual type attribute handling >>>>>>>> propagate it throughout. >>>>>>>> >>>>>>> Aaahhh! Here we got rid of those magic mls attributes and you >>>>>>> want to add more :) >>>>>>> >>>>>>> I'd much prefer a proper feature instead of special cased >>>>>>> attribute names, just me though. >>>>>> I'm not as convinced, so possibly others should chime in too. >>>>>> >>>>>> Type attributes are intended to indicate "properties" of types. It >>>>>> just happens that at present, the names and semantics of those >>>>>> properties are entirely defined within the policy configuration. >>>>>> But reserving some attribute names to have well-defined semantics >>>>>> encoded in the policy engine itself seems a natural extension, and >>>>>> we did do that in the original MLS implementation for trusted >>>>>> subjects (and I didn't view that as necessarily a bad thing). >>>>>> >>>>>> Introducing a new language primitive each time we want to mark a >>>>>> set of types for special handling by the policy engine logic seems >>>>>> less clean to me, even aside from implementation aspects. >>>>>> >>>>>> It also makes Eric's life a lot simpler ;) No need to modify >>>>>> checkpolicy or the policy module logic at all. A new kernel policy >>>>>> version would still be required, but we would get a side benefit >>>>>> from it in addition to permissive domains - preservation of type >>>>>> attribute names in the kernel policy. >>>>>> >>>> I understand. I want to note though, that the TE part of the SS has >>>> not had policy logic built into it, at least since I've been using >>>> SELinux. The old hardcoded attributes were part of the hardcoded MLS >>>> logic but we've even replaced that with a flexible system. >>>> >>>> I'm going to borrow a page from Chad's book here and say, during >>>> SELinux tutorials and classes we reiterate "types and attributes have >>>> no meaning other than what you give them in policy" say it over and >>>> over til it sink in.. Oh yea, and there is this one that does (d'oh). >>>> >>>>>>> The last time we got rid of magic attributes with new contraints, >>>>>>> maybe we need an 'unconstrain' :) >>>>> I tend to agree. I think we are making policy writing far to >>>>> complex, with additional semantics. >>>>> >>>> Eh? When was the last time you saw a user have to modify a constraint >>>> or mlsconstraint? Those additional semantics were to make the policy >>>> more flexible, the users almost never interact with them. >>> I think that's the point - here we want users to be able to >>> make existing domains permissive or introduce permissive >>> domains w/o having to write or modify a constraint at all. >>> >> It wouldn't require modifying a constraint any more than making >> something mls privileged currently does. >> >>> Also, this notion of permissive domains goes beyond the >>> existing security server interface. As I recall, it doesn't >>> just change what gets returned by security_compute_av() but >>> rather is something that the AVC queries (based on SID) on >>> the permission denied code path, like current enforcing mode. >>> >> Even better, that means we are using a magic attribute (part of the TE >> system) to change the behavior of the avc. AFAIK nothing in the policy >> really changes the avc behavior (right?). >> >> I don't want to stand in the way of this feature or anything, I'm just >> concerned about doing it in a hacky way vs. something more elegant. I'd >> like to hear others opinions, Chris? Todd? > > I don't like the magic attributes as permissive is a mechanism option. > It has no meaning in the policy, only in the enforcement. I'd really > prefer some other option in selinuxfs or a proc/pid/attr, but since that > doesn't seem to be an option, I'd rather have a policy primitive. > I would really rather just have it done. As we continue to talk about the feature 9 months after it was suggested. :^( Fedora 9 Beta 1 Freeze is March 4th... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfDLp4ACgkQrlYvE4MpobMKYwCgrCFKAhS95iqlZMcgE24VPVYQ nW4Anj97+OgRj2WQK+tYduuFipku1OrG =WLRn -----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.
